TGViewer
Антон Дорошкевич | маяк в мире 1С и СУБД Антон Дорошкевич | маяк в мире 1С и СУБД @explorer1c · 2.02K subscribers
Post #31 2.31K
1️⃣🔤 Неправильные подходы к отказоустойчивости кластера 1С со стороны клиентского подключения

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

Сценарий будет очень простым: есть два боевых сервера 1С, оба центральные + сервер 1С с ТНФ - Сервис лицензирования - Назначать (будем называть его Сервером лицензирования, хоть это и неправильно), хотим из них сделать отказоустойчивый кластер 1С.
Уровень отказоустойчивости в кластере = 1.

▫️Первый вариант - DNS.
Берём и прописываем IP адреса обоих Центральных серверов 1С под одним DNS-именем.
Например: Server1c - 192.168.0.1, 192.168.0.2
И соответственно в стартере 1С прописываем: Srvr="server1c";Ref="erp";

Казалось бы - всё прекрасно, и действительно - всё работает!
НО, до того момента пока "живы" оба наших Центральных сервера 1С,
Когда же выйдет из строя или просто станет недоступен по сети один из серверов, то пользователи начнут в случайном порядке получать ошибки работы в 1С (кто в ней уже был) и ошибки входа в 1С.
Так как DNS не анализирует доступность IP адресов, а просто выдаёт их по запросу в случайном порядке, а операционная система берёт первый из выданных адресов и пытается обратиться по нему, не пытаясь перебирать эти адреса.

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

▫️Второй вариант - разные proxy (nginx, haproxy, citrix и т.д.).
Тут в целом очень похоже на первый вариант, но немного сложнее.
Сложность в том что proxy подменяют IP адреса наших Центральных серверов 1С своим IP адресом.
И мы получаем, что клиент 1С общается с сервером 1С не по прямому IP что помимо задержек в общении может приводить вообще к неработоспособности 1С с очень "волшебными" ошибками сетевой недоступности серверов 1С.

Основная мысль в том, что не надо ничем заменять встроенную в Лучшую в мире платформу 1С отказоустойчивость!

А как же тогда правильно делать отказоустойчивость со стороны клиентского подключения?

Всё очень просто - нужно в адресе базы указать два наших центральных сервера: Srvr="server1c-1,server1c-2";Ref="erp";
При такой настройке сам клиент 1С, будет им Тонкий или Толстый клиент, либо Веб-браузер обратится сначала к server1c-1 для подключения и если он недоступен, то к server1c-2.

❗️При этом это не означает, что теперь все клиенты будут работать на server1c-1, просто сами подключения будут приниматься этим сервером и дальше уже назначаться на рабочие сервера и процессы согласно механике кластера 1С.

Напоминаю, что резервная копия канала есть в MAX.
MAX Антон Дорошкевич | маяк в мире 1С и СУБД Только интересные технические подробности, кейсы, тесты, а также анонсы выступлений на мероприятиях Никакой "воды" и рекламы Вся информация в этом канале - эт…
  • 👍 48
  • 🔥 17
  • ❤ 5
  • 😱 2
  • 👌 1
More from @explorer1c
  1. Sep 21, 2026Можно ли сделать поведение PostgreSQL в отношении потребления памяти процессами более жест…
  2. Sep 11, 2026Сегодня ровно год первому сообщению в канале! Огромное спасибо всем вам! Честно - было оче…
  3. Sep 9, 2026Теперь на багборде можно легко и быстро сравнить версии платформы по изменениям! Уверен чт…
  4. Sep 7, 2026Начнём...)
  5. Sep 2, 2026Как собрать для анализа запроса все временные таблицы с их содержимым? Все мы хорошо знаем…
  6. Aug 26, 2026Небольшой анонс поездок и мероприятий с моим участием: 08-10/09 - Обучение по кластеру 1с…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →