Обеспечение непрерывности бизнеса и отказоустойчивости ИТ-инфраструктуры — одна из важнейших задач для любой растущей компании. Особенно остро этот вопрос встает в розничной торговле, где даже небольшой простой кассовой зоны ведет к прямым финансовым и репутационным потерям. Классический подход к построению отказоустойчивых кластеров (High Availability) требует значительного парка оборудования: минимум 5–6 серверов для распределения ролей СУБД, серверов приложений 1С и серверов лицензирования. Однако далеко не каждый бизнес готов к таким капиталовложениям.
В этой статье мы подробно проанализируем, как организовать надежную и отказоустойчивую работу связки «1С:Предприятие + MS SQL Server», имея в распоряжении всего два физических сервера. Мы разберем по шагам несколько рабочих архитектурных сценариев, оценим их плюсы и минусы, а также предложим оптимальное решение для розничной сети.
Прежде чем переходить к технической реализации, давайте проанализируем ситуацию. У нас есть работающий сервер «все в одном» (1С + SQL + Терминальный сервер/Веб-сервер). Мы приобретаем второй аналогичный сервер, который планируем разместить на другой физической площадке (например, в другом офисе или дата-центре), чтобы обезопасить систему от локальных проблем с электропитанием и провайдерами связи.
При проектировании системы на двух узлах мы неизбежно сталкиваемся со следующими технологическими вызовами:
Рассмотрим четыре практических сценария решения этих задач.
Многие системные администраторы считают, что для развертывания технологии высокой доступности Always On Availability Groups в MS SQL Server обязательно требуется полноценный трехузловой кластер. На самом деле, Microsoft SQL Server позволяет развернуть полноценную отказоустойчивую СУБД силами всего двух серверов.
Для реализации этого сценария мы выполним следующие шаги:
При выходе из строя основного сервера СУБД, кластер автоматически переключит роль ведущего узла на второй сервер. База данных продолжит работу без потери транзакций.
Если мы не хотим усложнять администрирование операционных систем настройкой кластеров SQL и 1С, отличным решением класса Disaster Recovery (аварийное восстановление) является репликация на уровне гипервизора. Этот подход имеет колоссальное преимущество с точки зрения стоимости лицензирования 1С.
Разберем данный подход по шагам:
Важнейший нюанс лицензирования 1С: Программные лицензии 1С привязываются к ключевым параметрам системы (имя компьютера, SID операционной системы, объем ОЗУ, количество ядер процессора, MAC-адрес сетевой карты). Поскольку на втором сервере развернут точно такой же гипервизор, виртуальная машина запустится на нем с абсолютно идентичными виртуальными параметрами (UUID, MAC, характеристики процессора). Это значит, что программные лицензии 1С не «слетят», и нам не придется покупать второй дорогостоящий комплект лицензий!
В случае аппаратной аварии первого сервера системный администратор может запустить реплику виртуальной машины на втором сервере вручную или с помощью простого скрипта всего за 3–5 минут.
Если перед нами стоит задача обеспечить одновременную работу серверов 1С в режиме распределения нагрузки и горячего резервирования, мы можем настроить кластер платформы 1С:Предприятие 8.3 на двух узлах.
Проанализируем настройки, которые необходимо выполнить в консоли администрирования кластера 1С:
Количество центральных серверов = Уровень отказоустойчивости + 1
Стоит учитывать, что для такой схемы потребуется покупка дополнительного комплекта серверных лицензий 1С, так как службы 1С будут запущены на двух физических операционных системах одновременно.
Когда мы обеспечили резервирование серверов, встает вопрос: как перенаправить тонкие клиенты или веб-клиенты на работающий сервер? Поскольку наши торговые точки работают через веб-сервер, мы можем использовать технологии балансировки трафика.
Рассмотрим два популярных метода:
https://trade.company.ru/ut). В настройках DNS-сервера указываем короткое время жизни записи (TTL = 60 секунд). Скрипт мониторинга непрерывно проверяет доступность первого сервера. Если он падает, скрипт автоматически меняет IP-адрес для записи trade.company.ru на IP-адрес второго сервера. Клиенты переподключатся к рабочей ноде в течение одной-двух минут.
upstream 1c_cluster {
server 192.168.1.10:80 max_fails=3 fail_timeout=10s;
server 192.168.2.10:80 backup;
}
server {
listen 80;
server_name trade.company.ru;
location / {
proxy_pass http://1c_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
В этой конфигурации Nginx направляет весь трафик на основной сервер (192.168.1.10). Если он перестает отвечать на запросы, Nginx мгновенно и незаметно для пользователей переключает весь трафик на резервный сервер (192.168.2.10, помеченный как backup).
Даже если мы построим идеальный отказоустойчивый кластер из двух серверов, у розничной торговли остается еще одна критическая точка отказа — интернет-канал на самой торговой точке. Если в магазине отключат интернет, кассы все равно не смогут связаться с центральным сервером по веб-интерфейсу, и продажи остановятся.
Поэтому самым надежным и профессиональным решением для розницы является переход на гибридный (автономный) режим работы:
При такой архитектуре кассиры пробивают чеки локально. Продажи идут без задержек, печать чеков на ККМ происходит мгновенно. Если падает интернет на точке или отключается центральный сервер, магазин продолжает полноценно торговать в автономном режиме. Как только связь восстанавливается, накопленные чеки и отчеты о продажах автоматически выгружаются в центральную систему «1С:Управление торговлей».
Использование гибридной схемы в сочетании с репликацией виртуальных машин (Сценарий 2) гарантирует бизнесу практически 100% защиту от простоев кассовой зоны при минимальных затратах на ИТ-инфраструктуру.