Шаг 1. Анализ текущей архитектуры 1С
Первым шагом стоит проанализировать текущую архитектуру 1С и оценить, какие узлы (сервисы) требуют дублирования для обеспечения отказоустойчивости. Обычно система 1С состоит из:- сервера СУБД (MSSQL или Postgres);
- сервера приложений (1С предприятие);
- системы клиентского доступа через web или сервис удаленных рабочих столов (RDP);
- обслуживающих сервисов ИТ-инфраструктуры.
Шаг 2. Оценка предельно допустимого времени простоя (RTO)
На втором шаге необходимо оценить предельно допустимое время простоя (RTO — Recovery Time Objective). В зависимости от этого выбирается подходящее решение. Если требования к RTO у бизнеса стоят максимально жесткие, то помимо кластеризации вышеуказанных сервисов, необходимо реализовать разнесение инфраструктуры 1С между двумя независимыми площадками. Даже если используется высококачественный дата-центр, может произойти непредвиденная ситуация. Например, серьезный пожар, попадание беспилотника или остановка работы ДЦ правоохранительными органами в рамках следственно-оперативных действий. Территориальное распределение данных можно выполнить тремя принципами:| Резервное копирование данных | Это позволит в случае длительной остановки основной ИТ-инфраструктуры за несколько дней построить с нуля новую и получить доступ к данным компании. |
| “Холодное” резервирование | Перенос данных в формате репликации, что позволяет обеспечить полноценный доступ к сервисам в течение суток. |
| “Горячее” резервирование | Полная кластеризация всех сервисов, позволяющая переключиться на резервную структуру в течение считанных минут. |
Как достигается резервирование?
С первым вариантом все понятно: согласовывается формат резервных копий, настраивается их автоматическое выполнение и система мониторинга, которая контролирует создание бэкапов. В случае наступления форс-мажора, требуется развернуть новую ИТ-структуру и подгрузить в нее данные из резервных копий. Для этого требуется значительное время и высокая компетенция специалистов. Зато расходы на эксплуатацию резервной площадки будут минимальные.
Вариант с “холодными” резервированием заметно сложнее. Для его реализации требуется создать ИТ-структуру аналогичную основной и обеспечить репликацию данных между двумя площадками. В случае применения виртуализации возможна настройка репликации виртуальных машин. В случае наступления долгосрочного сбоя основной площадки, резервная структура запускается, перенастраивается сетевая связанность, тестируется, после чего она готова к подключению пользователей. Так как данные уже загружены, все указанные процессы происходят гораздо быстрее и требуют меньшего уровня компетенции от ИТ-отдела. Стоимость такой реализации выше, чем первого, но все равно достигается серьезная экономия на RAM и CPU, канале связи между площадками, т.к. резервная структура не активна.
Самая отказоустойчивая и быстрая реализация резервирования — это “горячее” резервирование всей ИТ-структуры. Такое подход обеспечивает доступ всех пользователей к данным в течение считанных минут. Далее рассмотрим схему реализации подобной структуры.
Этапы реализации отказоустойчивости 1C на территориально разнесенных площадках
Начинать построение подобной системы необходимо с организации сетевой связности между площадками. Рекомендуется иметь единую подсеть, что упростит настройку кластеризации. Если подсети не могут быть объединены, они должны быть маршрутизируемыми. Для синхронной репликация данных потребуется высокоскоростной канал не менее 1 Гбит/с низкими задержками (желательно выделенное волокно, т.к. любые VPN на маршруте — это серьезные задержки).
Вторая задача, которую предстоит решить — это организация интернет канала с единым адресом для входа между разными площадками. Для web-подключений 1С можно использовать HAProxy. Это решение позволит корректно обрабатывать недоступность основного адреса. Для тонких клиентов потребуется указывать два адреса подключения — основной и резервный.
Рисунок 1 – Схема работы подключений через HAProxy.
