Зачастую перед IT-специалистами встает критически важная задача: обеспечить доступность базы 1С в режиме 24/7. Предположим, что база данных (СУБД) уже вынесена на отдельный надежный сервер, и за сохранность данных мы спокойны. Однако остается уязвимое звено — сам сервер приложений 1С. Если физический сервер или виртуальная машина с 1С "падает", бизнес останавливается. Разберем подробно, какие существуют практики для построения отказоустойчивой системы 1С и проанализируем несколько рабочих архитектурных подходов.
Первый и, пожалуй, самый классический инфраструктурный метод — это использование полной виртуализации на базе отказоустойчивых кластеров гипервизоров. Рассмотрим, как это работает.
Вместо того чтобы полагаться на механизмы платформы 1С, мы обеспечиваем надежность на уровне «железа» и системы виртуализации. Для этого нам потребуются:
Проанализируем механику: серверы 1С работают в виде виртуальных машин. Файлы этих машин лежат в отказоустойчивом хранилище SAN. Если один физический хост выходит из строя (сгорел блок питания, сломалась материнская плата), система виртуализации мгновенно перезапускает виртуальную машину с 1С на другом доступном физическом сервере. Простой составляет считанные минуты — ровно столько, сколько нужно ОС для загрузки. При этом настраивать сложные кластеры внутри самой 1С не требуется.
Если бюджет ограничен или аппаратная виртуализация недоступна, рассмотрим использование встроенных возможностей платформы 1С. Платформа 8.3 обладает развитыми механизмами обеспечения отказоустойчивости.
Для создания простейшей надежной конфигурации нам потребуется минимум два сервера 1С. Мы можем объединить их в группу кластеров или настроить единый отказоустойчивый кластер. Главный вопрос — как клиентские приложения узнают, куда подключаться, если основной сервер недоступен? Разберем решение.
В настройках подключения информационной базы мы можем указать несколько адресов серверов через запятую в параметре Srvr. Посмотрим на пример строки подключения:
Srvr="Server1C_Main,Server1C_Reserve";
Ref="MainBaseDB";
Как только клиент (толстый или тонкий) пытается подключиться, он обращается к первому серверу из списка. Если Server1C_Main не отвечает, платформа автоматически пытается установить соединение с Server1C_Reserve. Таким образом, мы получаем базовую отказоустойчивость при входе в систему.
Технологии не стоят на месте, и современные версии платформы (начиная с 8.3.14) позволяют настроить всё гораздо изящнее в рамках одного кластера.
Рассмотрим запуск центрального сервера (менеджера кластера rmngr) в режиме репликации. На втором (резервном) сервере поднимается служба, которая постоянно синхронизирует реестр кластера с основным сервером. В случае аварии резервный менеджер берет управление на себя без участия администратора.
Далее настроим уровни отказоустойчивости в свойствах кластера:
Также настоятельно рекомендуем использовать настройку «Резервирование рабочих процессов». Кластер заранее поднимет фоновые процессы на резервном узле, что позволит мгновенно перекинуть нагрузку без пикового потребления ресурсов процессора при аварийном переключении сотен пользователей.
Если пользователи работают через веб-клиент или интеграция идет через HTTP-сервисы, использование параметра Srvr="A,B" не поможет. Веб-сервер (Apache или IIS) должен знать, куда отправлять трафик. Выясним, как решить эту проблему.
Лучшей практикой является использование программного балансировщика нагрузки. Построим схему:
Балансировщик постоянно выполняет проверку работоспособности серверов 1С (Health Check). Как только основной кластер 1С перестает отвечать по нужному порту, HAProxy прозрачно перенаправляет трафик на резервный узел.
При дублировании инфраструктуры часто возникает проблема переплаты за серверные и клиентские лицензии 1С. Проанализируем способы оптимизации:
Для программных лицензий: Выделите службу лицензирования (сервер лицензий 1С) в отдельную легковесную виртуальную машину. Она потребляет минимум системных ресурсов и практически никогда не дает сбоев. В случае падения рабочего сервера 1С, резервный сервер просто обратится к этому же серверу лицензирования.
Для аппаратных ключей (USB): Используйте сетевые концентраторы с технологией USB-over-IP. Ключи физически вставляются в отдельный хаб, подключенный к локальной сети. И основной, и резервный серверы 1С могут обращаться к ключам по сети. Если основной сервер выйдет из строя, резервный подхватит лицензии.
Сохранение временных файлов: Сеансовые данные реплицируются средствами самой платформы. Но как быть с тяжелыми отчетами или файлами, генерируемыми в фоновых заданиях? Для гарантии их доступности настройте использование внешнего хранилища (общие сетевые папки CIFS/NFS). Если сервер упадет в момент формирования отчета, резервный узел без проблем получит доступ к уже сформированным временным файлам из сетевой шары.
Таким образом, комбинируя штатные механизмы платформы с современными инфраструктурными решениями, мы можем создать надежный 1С-сервис, готовый работать 24/7 и прозрачно переносить любые аппаратные сбои.