Когда перед нами стал вопрос снижения стоимости серверных 1С, мы начали искать пути экономии без потери качества. И одним из самых очевидных решений стало использование свободно распространяемого ПО, которое по характеристикам не уступает платному. Так наш выбор пал на SQL сервер Postgre, официально интегрированный с продуктами 1С. А приятным бонусом для нас стало импортозамещение, которое мы при прочих равных всегда поддерживаем.
Выбор решения и архитектура
Чтобы упростить переход с MS SQL на базе ОС Windows 2016 Server, мы решили использовать SQL сервер Postgre, представленный на сайте 1С, релиз 11.5-19.1C, и при этом остаться на хорошо знакомой нам Windows 2016. Это решение позволяет более быстро осуществить переход, т.к. администрировать Windows системы нам привычнее, есть масса наработок для резервного копирования и мониторинга производительности. А еще такой подход позволил объективно сравнить показатели производительности 1С на PostgreSQL по сравнению с MS SQL, так как в обоих случаях использовались идентичные по производительности сервера с одинаковыми настройками ОС.
Для тестирования системы мы взяли сервера со следующими параметрами:
Роль | Конфигурация |
---|---|
Сервер БД MS SQL | 10 vCPU 50 RAM |
Сервер предприятия 1C | 6 vCPU 20 RAM |
Сервер БД PostgreSQL | 10 vCPU 50 RAM |
Установка и настройка
Скачать дистрибутив можно с сайта релизов 1С. Установка Postgre происходит типовым способом, сервер устанавливается как сервис. Обратите внимание на путь к расположению инстанса, конечная папка назначения и будет именем инстанса (по умолчанию data), не рекомендуем оставлять путь по умолчанию, для каталога данных лучше использовать отдельный диск, отличный от системного.
Далее указываете порт подключения (по умолчанию 5432), задаете пароль для суперпользователя инстанса с логином postgres. При установке требуется, чтобы была запущена служба “Вторичный вход в систему”, а также выданы права к каталогу данных для NETWORK SERVICE .
Тюнинг настроек мы производили в соответствии с ресурсами сервера и с учетом рекомендаций из различных источников – мы изучили официальную документацию, тематические форумы, чаты в Телеграм, видеоматериалы.
PostgreSQL, как и MS SQL, позволяет запуск нескольких инстансов (экземпляров) на одном сервере. Этот функционал полезен в различных ситуациях, одна из популярнейших утилит резервного копирования БД Postgre – pg_probackup, позволяющая выполнять полное и журнальное бекапирование, обеспечивать валидацию данных, восстановление на произвольный момент времени. Она выполняет бекап полностью всего инстанса, а не отдельных баз, поэтому использование нескольких инстансов для различных баз или групп баз позволит настроить индивидуальные планы резервного копирования, исключит простой баз других инстансов в случае необходимости восстановления единичного инстанса. Также обычный перезапуск службы, например, для изменения конфигурации затронет только единичный инстанс.
Настройка производится стандартными утилитами initdb.exe и pg_ctl.exe, новая инсталляция Postgre SQL не требуется, пример использования:
"c:\Program Files\PostgreSQL\11.5-19.1C\bin\initdb.exe" --encoding=UTF8 -U "postgres" -D "d:\DataFolder\InstansName"
После этого необходимо зарегистрировать службу:
"c:\Program Files\PostgreSQL\11.5-19.1C\bin\pg_ctl.exe" register -N "OriginalName-5433" -U "NT AUTHORITY\NetworkService" -D "d:\DataFolder\InstansName"
Команды выполняются из командного файла или строки с привилегиями администратора.
Результат:
Изменяем в postgresql.conf параметр port = 5432 (стандартный) на другой, например, 5433. При необходимости меняем параметры авторизации службы “OriginalName-5433” и стартуем. На сервере предприятия при создании базы указываем имя хоста сервера и порт в следующем формате – “hostname port 5433”
После этого можем зайти в графический клиент управления Pgadmin 4, настраиваем подключение к серверу по порту 5433 и проверяем успешное создание базы.
Резервное копирование и обслуживание
Для резервного копирования мы выбрали утилиту pg_probackup, так как она обеспечивает нужный нам сценарий резервного копирования. Резервное копирование и обслуживание баз, в отличие от MS SQL, не имеет графического интерфейса, в котором можно настроить Maintenance plan (План обслуживания). Все команды выполняются из командной строки планировщиком заданий Windows. Мы настроили и протестировали архивирование журналов предзаписи (WAL) и создание полных копий 1 раз в сутки с планом хранения в течение 2х недель.
Два бекапа – всегда лучше, чем один, поэтому полные бекапы баз и журналы WAL синхронизируются с облачным объектным хранилищем. С этой задачей нам помогла успешно справится свободно распространяемая утилита Rclone, которая позволяет копировать, переносить, синхронизировать файлы между различными типами хранилищ, обеспечивая высокую скорость за счет многопоточности и гарантируя доставку валидных данных за счет алгоритма хеширования MD5.
Обслуживание инстанса или отдельных баз, как правило, заключается в ежедневном сборе мусора и анализе данных с помощью VACUUM, запускать который желательно перед началом рабочего дня. Для запуска из командного файла по шедулеру требуется учесть настройку авторизации, без которой командный файл не отработает, так как будет ждать ввода пароля. В каталоге %APPDATA%\postgresql\ необходимо создать файл pgpass.conf, формат записей, которые необходимо создать для всех баз <сервер>: <порт>: <база>: <имя>: <пароль>, например, localhost:5432:Dbname:postgres:password. В командной строке обслуживания указываем опцию – w, и авторизация будет использовать данные из конфига.
Пример:
"c:\Program Files\PostgreSQL\11.5-19.1C\bin\psql.exe" -d Dbname -U postgres -w -c "VACUUM FREEZE VERBOSE ANALYZE;"
Тестирование
Ну вот мы и готовы приступить к тестированию. Для этого мы выбрали достаточно высоконагруженную базу 1С из прод среды размером около 40 ГБ, в которой ежедневно более 500 подключений одновременно. Загрузка базы в формате DT подготовила нам первый сюрприз – она не залилась полностью, мы убедились в том, что те ошибки, которые прощает разработчикам MS SQL, в PostgreSQL вылазят наружу и требуют более тщательного подхода к написанию кода и организации хранения данных. Мы призвали на помощь наших разработчиков 1С. Они проанализировали ошибки и нашли причину – виной всему оказалось хранение в базе крупных и даже очень крупных объектов, таких как архивы, медиа-файлы и документы. Пришлось выполнить доработки в прод базе – ограничить максимальный объем вложений. Теперь вместо крупных вложений хранятся ссылки на них (ссылки на портал компании или другие облачные хранилища, такие как Google Disk). Автотесты, которые предусмотрены в нашей базе, также не прошли сразу по причине различия правил сортировки, и снова наши разработчики 1С оказались на высоте и удачно устранили все сложности.
После доработок базы приступили к тестированию производительности на PostgreSQL и MS SQL. APDEX показал примерно одинаковые результаты на MS SQL 0.862/0.877 на Postgre 0.898/0.895. Также мы протестировали время бекапирования и восстановления, MS SQL примерно в 1.5 -2 раза превосходит по скорости таких операций, но при объеме данной базы вилка по времени не значительна. Поэтому мы сделали вывод, что использование PostgreSQL вполне оправдано.
Переход
Каким бы тщательным ни было тестирование, переход на использование новых стандартов всегда торжественно тревожен. Ни один синтетический тест не сравнится с реальной нагрузкой, которую создают практически все сотрудники нашей компании, работая в базе и открывая по несколько сеансов одновременно. Мы еще раз все тщательно проверили, взвесили все риски, детально составили план деплоя и план отката, если что-то пойдет не так. И вот однажды поздним вечером, когда все граждане уже мирно спали, наша команда приступила к переезду.
На следующее утро никто не заметил наших усилий и перемен, база работала также стабильно. На сегодняшний день она уже больше месяца функционирует на PostgreSQL. Так мы убедились, что PostgreSQL под управлением Windows 2016 Server хорошо справился с обеспечением необходимой производительности. Мы начинали проект с базовым набором знаний в PostgreSQL, в результате мы получили реальные пруфы и прокачали скиллы. Следующим этапом снижения стоимости содержания серверных баз 1С мы планируем использование Linux серверов. Таким образом мы исключим необходимость оплаты лицензий Windows.