Работа 1С в режиме 24/7 с http-сервисами

https://www.google.com/search?q=%D0%B1%D0%B0%D0%BB%D0%B0%D0%BD%D1%81%D0%B8%D1%80%D0%BE%D0%­B2%D0%BA%D0%B0+http+%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%­BE%D0%B2+iis

У 1С в любой момент отлетела лицензия от малейшего чиха и всё, приехали..
Написать сервис на каком-нибудь go + redis, туда выгружать данные, которые нужно отдавать вовне.

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

1. Кластеризация сервера 1С и балансировка нагрузки

Используйте функционал кластеризации 1С:Предприятие и настройте балансировку нагрузки. Разделение ролей (бэкэнд-серверы, серверы фоновых заданий, серверы приложений) позволит более гибко управлять нагрузкой и обновлениями.
Организуйте несколько серверов приложений 1С (S1, S2, и т.д.), которые будут обрабатывать запросы параллельно и, при необходимости, переключаться между друг другом. Это позволит обновлять один сервер, пока остальные остаются доступными.
Балансировщик нагрузки (например, Nginx или встроенный балансировщик в IIS) распределит трафик между серверами и перенаправит запросы в случае отказа.

2. Режим горячего резервирования (HA)

Реализуйте Failover Cluster для 1С-серверов. Настройка горячего резервирования позволит активному серверу передавать управление резервному при сбое или обновлении.
Включите мониторинг приложений для автоматического обнаружения проблем и переключения на другой узел, если текущий сервер теряет доступность.

3. Масштабируемость HTTP-сервисов (IIS):

Разверните несколько узлов IIS, чтобы каждый мог обрабатывать запросы независимо, сохраняя общий доступ к базе данных. В случае обновления можно отключить один из узлов IIS из баланса нагрузки для установки обновлений.
Включите IIS Web Farm для распределения нагрузки между серверами и обеспечения автоматического переподключения при отказах.

4. MS SQL Server: Always On Availability Groups

Настройте Always On Availability Groups для базы данных MS SQL. Это позволит создать несколько реплик базы данных (основную и вторичную), и при обновлении первичной реплики система сможет автоматически переключиться на вторичную.
Используйте синхронный режим для реплик в пределах ЦОД для минимизации потерь данных и для высокой скорости отклика запросов.

5. Виртуальная инфраструктура (Proxmox): миграция и HA

Proxmox поддерживает HA-кластер и живую миграцию VM между физическими узлами. Настройте резервирование Proxmox, чтобы при необходимости мигрировать VM на другой физический сервер без перерывов.
С учетом 10 Гб локальной сети между узлами Proxmox, миграция будет происходить быстро и практически незаметно для конечных пользователей.

6. Обновления и технические работы без остановок

Для обновлений можно использовать подход "rolling update" — обновлять один узел кластера или балансировщика нагрузки за раз, остальные узлы продолжают работу.
Используйте режим обслуживания для одного из серверов, чтобы временно исключить его из кластера или балансировщика на время обновления, а затем снова вернуть его в строй.

7. Мониторинг и управление отказоустойчивостью

Настройте мониторинг инфраструктуры (например, Zabbix или Grafana с Prometheus) для отслеживания загрузки, времени отклика, состояния каждого компонента системы.
Определите пороговые значения для триггеров, чтобы система уведомляла о любых просадках или возможных отказах.

Схема работы:

1. Пользовательский запрос поступает на балансировщик (Nginx/IIS) и распределяется на доступные узлы IIS.
2. IIS передает запрос в кластер 1С, распределяющий нагрузку между серверами 1С.
3. Серверы 1С обрабатывают запросы, используя доступ к Always On Availability Group SQL-сервера.
4. В случае отказа любого из компонентов (серверов 1С, SQL, IIS), трафик автоматически перенаправляется на резервные узлы.

Такая архитектура обеспечит круглосуточную доступность с возможностью регулярного обновления системы, минимальными задержками отклика и высокой отказоустойчивостью.

Временные интервалы зависят от объема данных, конфигурации, железа и как пойдет.

Предположим такая инфраструктура и три подхода на выбор:

Серверы 1С - для параллельного кластера требуется минимум два сервера приложений в каждом кластере (основной и параллельный), что в сумме дает четыре сервера.
Конфигурация каждого сервера:
CPU: 8-16 ядер.
RAM: 32-64 ГБ.
Диск: SSD или NVMe объемом 500 ГБ и более.

Серверы баз данных (MS SQL) - настроенные в режиме Always On Availability Groups, чтобы обеспечить высокую доступность и репликацию данных.
Конфигурация:
CPU: 16-32 ядер.
RAM: 128 ГБ и выше.
Диск: высокопроизводительное NVMe-хранилище объемом 500 ГБ и более.

Серверы IIS - необходимо 2-4 узла для параллельной обработки запросов и балансировки нагрузки.
Конфигурация:
CPU: 4-8 ядер.
RAM: 16-32 ГБ.
Диск: SSD объемом 100 ГБ.

Серверы виртуализации (Proxmox) - для размещения виртуальных машин 1С, SQL и IIS с поддержкой высокой доступности.
Конфигурация каждого узла:
CPU: 16-32 ядер.
RAM: 128-256 ГБ.
Диск: SSD или NVMe на 1 ТБ и более.

Подходы (архитектура):

1. Создается параллельный кластер 1С с новой версией платформы, который работает вместе с текущим (подробнее: Blue-Green Deployment). После настройки и синхронизации данных с основной базой данных, переключение трафика на новый кластер позволяет обновить систему без остановок.
Процесс:
Настраивается второй кластер с новой версией 1С (приложение и IIS).
Базы данных синхронизируются, например, через SQL Always On Availability Group, чтобы параллельный кластер имел актуальные данные.
После тестирования нового кластера балансировщик переключает трафик на него, после чего старый кластер можно отключить.
Временные интервалы:
Развертывание параллельного кластера занимает от 2 до 6 часов, но этот процесс можно выполнить заранее.
Репликация данных в режиме Always On происходит в реальном времени.
Само переключение занимает 10-30 минут.

2. Обновление с дублирующим контуром (Ночное обновление)
Тут используется тестовый сервер, на котором проводится подготовка и тестирование обновлений. Само обновление выполняется ночью на основном кластере, чтобы минимизировать простой.
Процесс:
На тестовом сервере проводится тестирование обновлений.
В ночное время текущий кластер отключается и обновляется, а затем запускается обновленная версия.
Отключение и обновление кластера (платформа, конфигурация, перезапуск) занимают от 2 до 4 часов.
Временные интервалы:
Подготовка и тестирование занимают от 1 до 3 часов.
Сам процесс обновления с остановкой кластера — от 2 до 4 часов, если сделано заранее.

3. Мультикластерная архитектура. Включает несколько кластеров 1С, каждый из которых работает с общей базой данных, с применением технологий репликации данных. Это позволяет обновлять один кластер, пока другой продолжает обрабатывать запросы.
Процесс:
На начальном этапе разворачиваются два кластера 1С с поддержкой синхронизации данных (например, с использованием SQL Always On).
Обновление проходит поэтапно, при этом отключается и обновляется только один кластер, в то время как другой продолжает работу.
Временные интервалы:
Настройка занимает больше времени (от 6 до 12 часов для всей системы), однако дальнейшее обновление каждого кластера будет занимать 1-2 часа.

***
Малый объем данных (до 100 ГБ): базу можно поддерживать на серверах с 8 ядрами CPU и 32 ГБ RAM. Рекомендуется использовать один кластер с регулярным ночным обновлением.

Средний объем данных (от 100 до 500 ГБ): потребуется кластеризация с SQL Always On и распределение серверов приложений, IIS и балансировщиков. Это обеспечит высокую отказоустойчивость и производительность.

Крупный объем данных (от 500 ГБ): для поддержания скорости и отказоустойчивости потребуется мультикластерная архитектура или Blue-Green Deployment с высокой мощностью серверов и отказоустойчивым хранилищем.

1. Изначально финансовых ограничений не предусматривалось, на эту тему можно отдельную статью написать, т.к. есть разные подходы, чтобы оптимизировать затраты на лицензии, Вообще в кластере с несколькими серверами приложений лицензия на сервер платформы обычно нужна только для одного основного серверного узла, который управляет кластером, а остальные серверы в роли серверов рабочих процессов используют лицензии этого основного узла. Еще вариант, можно использовать редакцию корп.

2. Тоже отдельная тема. Примерно делается это так:
Создается копия основного кластера 1С с актуальной базой данных через репликацию SQL. Синхронизация и обновление данных временно приостанавливается, после чего на резервный кластер устанавливается новая версия платформы и обновляется конфигурация. После успешного обновления резервный кластер становится основным. Балансировщик направляет пользователей на него. Бывший основной кластер обновляется и снова синхронизируется, становясь резервным.

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

Если низкая нагрузка действительно приходится на определенные ночные часы, то временная работа на двух серверах не скажется на качестве обслуживания. По завершении обновления первый кластер возвращается в строй, и затем обновляется второй кластер, сохраняя 24/7 доступность без полной остановки системы.