← На главную

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

Анализируем фундамент: Дисковая подсистема и RAID

Прежде чем приступать к программным кластерам, разберем ситуацию с физическими носителями. В рассматриваемом случае «отвалился» RAID, что привело к переустановке системы. Важно понимать: не все RAID-массивы одинаково полезны для отказоустойчивости.

Проанализируем основные типы массивов для 1С:

1. RAID 0 (Stripe): Категорически запрещен. Он увеличивает скорость, но при выходе из строя любого диска данные теряются полностью.
2. RAID 1 (Mirror): Хороший вариант для системных дисков. Зеркалирование обеспечивает выживаемость при вылете одного накопителя.
3. RAID 5: Часто используется, но мы крайне не рекомендуем его для высоконагруженных баз 1С. При выходе одного диска массив переходит в режим деградации, и скорость записи падает катастрофически. Кроме того, процесс восстановления (rebuild) создает огромную нагрузку, при которой часто вылетает второй диск.
4. RAID 10 (1+0): Оптимальный выбор. Мы получаем и высокую скорость (как в RAID 0), и надежность (как в RAID 1). Для 50 пользователей это «золотой стандарт».

Выясним причину долгого восстановления в исходном примере: скорее всего, отсутствовал Hot Spare (диск горячей замены) или мониторинг состояния массива. Настроим систему так, чтобы при отказе одного диска запасной подхватывал нагрузку автоматически.

Разбираем кластер серверов 1С и сервер лицензирования

Автор темы столкнулся с вопросом: зачем в схемах отказоустойчивости выделяют отдельный сервер лицензий? Разберем по шагам логику работы кластера 1С.

Когда мы создаем кластер из двух рабочих серверов (Центральный и Резервный), платформа позволяет настроить Уровень отказоустойчивости. Рассмотрим это подробнее:

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

Почему нужен отдельный сервер лицензирования?

Программные лицензии 1С привязываются к ключевым параметрам сервера (процессор, материнская плата, BIOS). Если лицензия активирована на «Компьютере 1», и он сгорает, то «Компьютер 2» не сможет использовать эти лицензии. Чтобы решить эту проблему, мы создаем Сервис лицензирования на отдельном узле (часто это легкая виртуальная машина). Этот сервис занимается только раздачей лицензий всем рабочим серверам кластера. Таким образом, работоспособность лицензий не зависит от состояния конкретного рабочего сервера, на котором выполняется код 1С.

Настройка отказоустойчивости СУБД: MS SQL Server и PostgreSQL

Перейдем к самому важному — сохранности базы данных. Простого копирования файлов недостаточно. Рассмотрим два основных сценария:

Сценарий 1: MS SQL Server Always On

Для Microsoft SQL Server мы рекомендуем технологию Always On Availability Groups. Посмотрим на алгоритм работы:

• Создаем два сервера SQL.
• Настраиваем синхронную репликацию данных.
• Создаем «Слушатель» (Listener) — это виртуальный IP-адрес, к которому подключается сервер 1С.
• Если основной сервер БД падает, Слушатель мгновенно перенаправляет трафик на второй сервер.

Сценарий 2: PostgreSQL и Patroni

Если мы используем Linux и Postgres, то простая Master-Slave репликация требует ручного переключения, что увеличивает время простоя. Для автоматизации мы применим связку Patroni + etcd + HAProxy.

Проанализируем ситуацию: Patroni следит за состоянием Postgres. Если Master-сервер становится недоступен, Patroni выбирает новую «главную» реплику, а HAProxy переключает на нее сервер 1С. Лаг репликации в такой схеме обычно составляет менее 1 секунды, что практически незаметно для пользователей.

Практические советы по бюджетной отказоустойчивости

Если бюджет ограничен и мы не можем позволить себе полноценный кластер, рассмотрим вариант «холодного» или «теплого» резерва:

1. Создаем зеркало системы: На втором сервере должно быть заранее установлено всё необходимое ПО (ОС, SQL, Сервер 1С).
2. Настраиваем бэкапы: Помимо ежедневных копий, обязательно настроим бэкап Transaction Log (лога транзакций) каждые 15–30 минут. Это позволит восстановить базу в случае аварии с минимальными потерями данных.
3. Сетевое хранилище (NAS): Используем его исключительно для хранения бэкапов. Размещать на нем «живую» базу данных через SMB-протокол — плохая идея из-за высоких задержек сети (latency).

Использование виртуализации

Рассмотрим современный подход — гипервизоры (VMware, Hyper-V, Proxmox). Вместо того чтобы городить сложные кластеры внутри ОС, мы можем настроить High Availability (HA) на уровне виртуализации.

Если физическое железо сервера выходит из строя, гипервизор просто перезапускает виртуальную машину с 1С на другом живом физическом сервере. Время простоя сокращается до 2–3 минут (время загрузки ОС), что для многих компаний на 50 пользователей является вполне приемлемым результатом без необходимости покупки дорогостоящих лицензий на SQL Enterprise.

Подведем итог: для построения надежной системы на 50 пользователей мы рекомендуем использовать RAID 10 на серверах, настроить кластер 1С с уровнем отказоустойчивости 1 и выделить сервис лицензирования. В качестве СУБД оптимально использовать MS SQL с технологией Always On или PostgreSQL под управлением Patroni. Не забывайте про регулярную проверку возможности восстановления из бэкапов — это последняя линия обороны вашего бизнеса.