Если допустимый простой меньше времени восстановления единственного сервера приложений, рассматривают кластер 1С из двух рабочих узлов. При отказе такого сервера пользователи теряют доступ до восстановления сервиса или переключения на резервный узел. Восстановление базы из копии требуется только при отказе или повреждении слоя СУБД и данных.
Речь идет о двух серверах приложений. СУБД размещается отдельно или уже существует. Два узла уменьшают риск простоя из-за отказа рабочего сервера, но не защищают единственную СУБД, хранилище, сеть и питание.
Инструкция посвящена конкретной схеме из двух рабочих серверов 1С: подготовке узлов, регистрации, резервированию сервисов и испытанию отказа. Общая архитектура высокой доступности разобрана в руководстве по настройке отказоустойчивого кластера серверов 1С.
Что дает кластер и от чего он не защищает
Отказ сервера приложений, СУБД и инфраструктуры приводит к разным сценариям восстановления.
Отказоустойчивость системы на 1С складывается из трех независимых слоев:
Слой приложения. Кластер объединяет рабочие серверы 1С и распределяет между ними сервисы и соединения. Продолжение сеансов при отказе появляется после настройки уровня отказоустойчивости, резервирования центральных серверов и сервисов, корректной строки соединения и проверки лицензий.
Слой данных. Кластер серверов 1С обращается к СУБД, но не реплицирует и не резервирует базу. Отказоустойчивость данных настраивают средствами СУБД и инфраструктуры хранения.
Слой инфраструктуры. Виртуализация, хранилище, сеть, питание. Это отдельная задача со своими механизмами.
Два сервера приложений при одном сервере базы данных закрывают только один слой из трех. Это не отказоустойчивая система целиком.
Кластер не заменяет резервное копирование. Число серверов приложений не защищает от ошибочного удаления, некорректной обработки или логического повреждения данных.
Схема из двух серверов: как она устроена
В клиент-серверном варианте путь выглядит так: клиент обращается к основному или резервному адресу центрального сервера, тот направляет сеанс к рабочему процессу узла A или B, а рабочий процесс взаимодействует с общей СУБД.
На двух физических или виртуальных узлах устанавливают серверную часть платформы, затем регистрируют оба рабочих сервера в одном кластере. Если схема должна переживать отказ любого узла, оба подготавливают к роли центрального и резервируют сервисы кластера.
СУБД размещают отдельно. Она может работать на третьем сервере или в собственном кластере. Оба сервера приложений обращаются к одной логической базе, но ее репликация и резервирование не входят в пару узлов 1С.
Серверный адрес информационной базы указывает на центральный сервер кластера. Для отказоустойчивости в строке соединения задают список основного и резервных адресов, иначе отказ единственного адреса может остановить новые подключения.
Два рабочих сервера позволяют распределять нагрузку. Переключение при отказе подтверждают только после настройки центральной роли, сервисов, уровня отказоустойчивости и аварийного теста.
Требования к оборудованию под оба узла
До закупки рассчитайте ресурсы каждого узла в деградированном режиме, когда второй сервер недоступен.
Соразмерность узлов. Ключевое требование. При отказе одного сервера оставшийся принимает всю нагрузку целиком. Если конфигурации подобраны так, что каждый узел работает у предела, после отказа система формально жива, а фактически не справляется. Закладывайте запас: один узел должен вытягивать полную рабочую нагрузку с приемлемым откликом.
Процессор и память. Считаются по числу одновременно работающих пользователей и характеру операций. Тяжелые регламентные задачи — закрытие периода, формирование отчетности — дают пиковую нагрузку, которую тоже нужно учесть.
Для сеансовых и временных данных нужен накопитель с задержкой и IOPS, подтвержденными нагрузочным тестом. Основные требования к хранению базы рассчитывают для СУБД.
Сеть влияет на каждый вызов между рабочими процессами и СУБД. Ее задержку, пропускную способность и потери проверяют под штатной и аварийной нагрузкой, а для инфраструктурной отказоустойчивости резервируют коммутаторы, интерфейсы и пути.
Требования к отдельному узлу базы данных считают отдельно с учетом объема базы и профиля запросов, конфигурации собраны в разделе серверов СУБД под 1С.
Подготовка перед развертыванием
Перед установкой подготовьте нагрузочный профиль, версии компонентов, сеть, лицензии и план отката.
Оценка нагрузки. Сколько пользователей работает одновременно в пик, какой объем базы, какие регламентные операции выполняются и когда. Без этих цифр конфигурация подбирается наугад.
До включения узлов в один кластер приведите серверные компоненты к одной поддерживаемой версии и зафиксируйте ее в плане развертывания и отката.
Синхронизируйте часы узлов и систем журналирования с согласованными источниками времени, иначе события из разных журналов нельзя надежно выстроить в одну последовательность.
Сетевая связность. Узлы должны видеть друг друга и сервер базы данных, нужные порты должны быть открыты. Если между ними стоит межсетевой экран, правила настраивают заранее.
До закупки проверьте серверные и клиентские лицензии 1С, размещение сервиса лицензирования и лицензии СУБД для аварийного режима. Оставшийся центральный сервер должен легально обслужить требуемое число сеансов.
Порядок развертывания кластера
Выполняйте этапы последовательно и проверяйте результат каждого шага.
1. Установите серверную часть платформы на оба узла. Проверьте самостоятельную работу каждого рабочего сервера и доступ к СУБД.
2. Зарегистрируйте оба узла в кластере, подготовьте их к роли центрального сервера и задайте основной и резервный адреса в строке соединения.
3. Настройте требования назначения функциональности, размещение менеджеров, рабочих процессов и резервирование сервисов.
4. Проверьте фактическое значение параметра «Уровень отказоустойчивости» в целевом релизе и задайте уровень 1, если два рабочих сервера должны пережить отказ одного.
5. Проведите нагрузочный тест в штатном режиме, затем переходите к контролируемому отказу.
Не переходите к следующему этапу, пока текущий результат не подтвержден и не записан в протоколе развертывания.
Проверка отказа: обязательный этап
Без контролируемого отказа нельзя подтвердить переход центральной роли, доступность резервного адреса, продолжение сеансов и запас производительности второго узла.
Схема отказоустойчивости, которую никогда не проверяли — это предположение, а не факт. Проверять нужно контролируемо, в спланированное окно, до ввода в промышленную эксплуатацию.
Создайте рабочую нагрузку, отключите один узел и измерьте время переключения, доступность новых и текущих сеансов, действия пользователей и загрузку оставшегося сервера.
Платформа стремится продолжить сеансы за счет резервирования сервисов и сеансовых данных. Фактическое поведение зависит от места отказа, текущей операции и клиента, поэтому его фиксируют на тесте и не превращают в обещание SLA.
Уровень отказоустойчивости имеет ресурсную цену из-за синхронизации. Его задают по допустимому числу отказов, а не на максимальное значение без расчета.
Результат проверки фиксируют: сколько заняло переключение, что потребовалось от пользователей, как повела себя производительность. Эти цифры пригодятся при реальной аварии.
Эксплуатация кластера: мониторинг, резервные копии и документация
Работа не заканчивается запуском кластера.
Мониторинг. Состояние обоих узлов, число активных сеансов, распределение нагрузки, доступность сервера базы данных. Без мониторинга отказ одного узла может остаться незамеченным до момента, когда откажет второй.
Резервное копирование. Кластер его не заменяет. Копии базы делаются с той же регулярностью, что и раньше, и проверяются на восстановление. Схемы резервирования для учетных систем — от копий до дублирующего узла — собраны в разделе резервирования для 1С.
Лицензирование проверяют до запуска. В эксплуатации контролируют срок действия, размещение сервиса лицензирования и возможность обслуживания аварийного числа сеансов.
Документация. Схема, роли узлов, порядок действий при отказе, контакты ответственных. В момент аварии это экономит время.
Чек-лист перед вводом в работу
Перед вводом схемы в работу выполните четыре проверки.
1. Конфигурации узлов рассчитаны на деградированный режим, а лицензии покрывают его.
2. Центральные адреса, версии, время и резервирование сервисов проверены.
3. Нагрузочный и аварийный тесты проведены, фактическое время восстановления зафиксировано.
4. Для СУБД и инфраструктуры определены механизмы защиты и допустимый простой: кластер или репликация СУБД, резервирование хранилища, сети, гипервизоров и питания, мониторинг и проверяемые копии.
Эти пункты предотвращают ложный вывод, что два сервера приложений устраняют все точки отказа.
Соразмерные рабочие узлы, резервирование для 1С и отдельный сервер базы данных входят в расчет серверов для 1С, который подтверждают нагрузочным и аварийным тестом.