​​1С, Linux и виртуализация

Буквально на днях коллега попросил рассказать нас как мы работаем с на платформе виртуализации Proxmox.

В основе нашей инфраструктуры лежит Linux и контейнерная виртуализация LXC, что позволяет приложениям работать без потерь производительности, как будто они работают непосредственно на железе.

Центром всей этой системы является сервер 1С:Предприятия, который лицензируется отдельно на каждый запущенный экземпляр, стоимость лицензии составляет 95 000 руб., что не располагает к маневрам по разделению серверов и т.п.

Но не стоит сбрасывать со счетом Сервер-Мини за 15 500 руб. разрешающий пять сеансов к расположенным на нем информационным базам. Его можно использовать для вынесения на него ресурсоемких баз с малым количеством пользователей (например, ЗуП) или служебных баз для выполнения разного рода обменов и прочего регламента.

В любом случае сервер 1С – это центр вашей инфраструктуры и ему следует уделить особое внимание. Начнем с лицензирования, при нахождении сервера 1С в контейнере он учитывает ядра и сетевые карты контейнера, но диски и объем оперативной памяти берет от хоста.

При изменении количества ядер сервер посчитает что вы заменили процессор и попросит повторную активацию лицензии. При этом изменять объем памяти и перемещать машину между хранилищами вы можете без проблем, главное, чтобы параметры хоста при этом не изменились.

Сколько места выделить под контейнер? Много не нужно, там будет храниться серверный кеш, индексы и журналы, не считая временных файлов. Все это можно посмотреть на живой базе. Если не знаете – 1,5 – 2 размера ИБ, в случае чего всегда сможете откорректировать.

Следующий важный компонент – СУБД, мы используем бесплатную версию PostgreSQL от компании PostgresPRO. Также можно использовать сборку от 1С, но версия от PostgresPRO имеет репозиторий и получает обновления, что является более предпочтительным.

Ведущие специалисты по Postgres для 1С, такие как Антон Дорошкевич, рекомендуют выделять под одну базу один контейнер. И в этом есть смысл.

Во-первых, вы можете выделить каждой базе собственный набор ресурсов, за которые ей не придется конкурировать. Во-вторых, вы можете настроить сервер СУБД с учетом реальных потребностей конкретной базы, а не искать компромисс между различными базами с различным характером использования.

Как минимум разнесите на разные сервера СУБД различные конфигурации 1С, Бухгалтерию на один, Зарплату на второй, Торговлю на третий.

В этих целях следует создать готовый шаблон контейнера с уже установленной СУДБ и быстро разворачивать экземпляры по необходимости.

Основной тип подключения к базам – тонкий клиент, он отлично работает не только в локальной сети, но и из удаленных расположений через VPN. Забудьте про терминалы как страшный сон, в этом сценарии они не дают никаких преимуществ, только лишнюю головную боль.

Третий компонент – веб-сервер для публикации баз или веб-сервисов. Это дополнительный способ доступа и разворачивается он также по принципу: одна база – один веб-сервер, веб-сервисы публикуются отдельно.

Для него точно также имеет смысл создать готовый шаблон и разворачивать по необходимости. Это позволяет также использовать одноразовые веб-сервера, например, чтобы предоставить доступ внешнему пользователю (скажем, аудитору). После чего такой контейнер просто удаляется.

Что из этой схемы бекапится? В первую очередь сервер СУБД, частота выбирается исходя из допустимой потери информации. Потеря СУБД – потеря всех расположенных на них информационных баз 1С.

Сервер 1С не хранит никакой пользовательской информации и его потеря не так критична, бекапим сугубо в целях быстрого восстановления работы системы при авариях.

Веб-сервера можно не бекапить совсем, развернуть новый сервер из шаблона и заново опубликовать базу скорее всего будет быстрее, чем восстановление резервной копии.

Исключение – сервера работающий наружу, с сертификатами и прочими настройками безопасности. Опять же единственная цель бекапа – быстрое развертывание.