Помогли клиенту перейти на новые серверы PostgreSQL и сэкономить на лицензиях

Содержание кейса:
Наш клиент — компания Аспект. Клиент производит игрушки, и продаёт их оптом и в розницу.
Учёт ведут в программах 1С:Розница, 1С:Управление торговлей 11, 1С:Бухгалтерия и КАМИН:Расчёт заработной платы.
У клиента несколько информационных баз 1С разного объёма — 30–400 ГБ и с разным количеством пользователей — 20–90.
С программами 1С в компании работают в серверном режиме: есть пул серверов на Windows Server, сервер 1С и сервер с системой управления базами данных — СУБД MS SQL.
Клиент обратился с проблемой
Купить лицензии «Майкрософт» сейчас проблематично, поэтому нужно быть заменить СУБД MS SQL на другое программное обеспечение.
Для перехода выбрали бесплатные версии PostgreSQL и «Линукс», что позволило сэкономить на лицензиях. Для перехода нужно было установить операционную систему и перенести информационные базы 1С.
Что мы сделали
Помогли клиенту выбрать операционную систему — Ubuntu Server 22.04 LTS. Эту ОС выбрали, потому что система активно поддерживается разработчиками, в интернете есть масса информации по подключению, настройке и работе с Ubuntu. К тому же, клиент уже использовал серверы на этой операционной системе для других задач.
Перенесли информационные базы с MS SQL на серверы PostgreSQL
Сначала на новые серверы поставили ту же платформу, что была раньше — 8.3.17.1851. Позже обновили платформу 1С — до свежего релиза 8.3.21.1624.
-
Были два варианта для системы управления базами данных:
- Сборка PostgreSQL 14.5-3.1C от 1С
-
Сборка от команды Postgres Professional PostgreSQL 1C-15.1.
Выбрали этот вариант. Его удобнее устанавливать, можно почти автоматически настроить СУБД под аппаратное обеспечение сервера.
Сначала решили настроить изолированные сервер 1С и сервер СУБД — так у клиента было до переноса.
- Для сервера 1С определили аппаратное оснащение: выбрали 12 CPU, максимально доступное для ПРОФ лицензии 1С, 64 ГБ ОЗУ и 150 ГБ дискового пространства. Этого должно было хватить для операционной системы, сервера 1С, кэша и журналов регистрации.
- Для СУБД выделили 16 CPU, 64 ГБ ОЗУ, 30 ГБ под системный раздел и 300 ГБ накопителя, чтобы дальше можно было расширить файловую систему для новых информационных баз.
При переносе столкнулись с проблемой
Изначально была информация, что база данных у клиента 30 ГБ, оказалось — 250. При переносе сначала база помещается во временную папку сервера 1С, а уже потом в СУБД.
Так сделать не получалось, потому что на системном диске сервера 1С не хватало места.
-
Проблему решили так:
- временно добавили ещё один жёсткий диск на сервер 1С
- переписали юнит запуска службы 1С и перенаправили папку TEMP на временный диск
- загрузили ДТ и отмонтировали диск. То есть это пространство на диске мы не используем постоянно, а добавляем лишь когда загружаем или выгружаем данные — это происходит редко
Следующая проблема, с которой мы столкнулись — «исторический опыт», который был у клиента при работе с Майкрософт. Если сотрудникам нужно было создать новую базу или копию текущей, они просто добавляли новый диск и на нём размещали базу.
На PostgreSQL так не получается — каждый кластер сервера инициализируется в одну директорию. Разделить кластер по разным дискам прямым способом невозможно.
-
Предложили два варианта, чтобы решить эту проблему:
-
Установить на одном сервере несколько копий СУБД, каждая копия бы работала на своём порте и с отдельным каталогом баз.
При этом пришлось бы вручную настраивать каждый экземпляр сервера — необходимое количество памяти, доступных процессов и так далее. Отказоустойчивость тоже была бы ниже — при отключении сервера стали недоступны все информационные базы. -
Для каждой информационной базы создавать отдельный сервер.
Этот вариант проще реализовать и поддерживать, поэтому выбрали его.
-
Шаблон для новой базы сотрудники создавали по одной схеме:
- выбирали количество процессоров и памяти под нужные мощности
- добавляли диск нужного размера под базу данных
- указывали имя и адрес сервера
- добавляли диск в систему и запускал кластер с минимальными настройками.
Так как процесс был повторяющимся, мы написали скрипт — всё происходит автоматически и с минимальными затратами времени. Пользователю остаётся только ввести имя и ip-адрес сервера. Остальное система делает автоматически.
У клиента была ещё одна проблема
Программные лицензии 1С при установке «запоминают» параметры сервера, на котором они установлены: объём памяти, количество процессоров и так далее. Если сервер 1С «мигрировал» внутри системы виртуализации, эти параметры могут измениться — тогда придётся заново активировать программные лицензии, в это время работать в 1С не получится.
Мы предложили такое решение: разместить отдельный сервер 1С со статическими характеристиками, который раздавал лицензии. Для этого мы развернули ещё один виртуальный сервер 1С и добавили его в кластер к основному серверу. Так отдельный сервер 1С отвечает за выдачу лицензий и при этом его параметры никогда не изменяются.
На все работы у нас ушло 10 часов.
Какой результат получил клиент
- перешли на серверы PostgreSQL — они проще в обслуживании и поддержке, дешевле, чем MS SQL
- сократили время на создание новой копии для базы — автоматический скрипт делает всё сам, пользователю остаётся только ввести имя и адрес сервера
- лицензии перестали «слетать» — работа стала проще и стабильнее
Что дальше
Дальше планируем расширить мощности кластера сервера 1С и внедрить туда ещё один сервер 1С, чтобы обрабатывать клиентские запросы.
- поможем подобрать оборудование для работы
- перенесём информационные базы на серверы
- по договору администрирования серверов ежемесячно следим за программным обеспечением и нагрузкой на серверы, настраиваем программы под оборудование, контролируем резервное копирование
Автор статьи
