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.
Post #31
2.31K