Создание отказоустойчивого сервера 1С 8,3
Если два физических сервера win 2016, с установленной платформой +сервер 1С 8,3,10, отдельно server SQL 2014
На одном из низ развернута база и опубликована в инет. Оба сервера удаленные друг от друга, смотрять в инет.
Вопрос: как объединить этих два физических сервера в одно целое, чтобы при потери связи с первым - можно было продолжать в реальном времени работать с вторым.
Объединить оба ір серверов думаю через отдельное доменное имя. Т.е. для конечного пользователя будет доступ представлен по имени типа server1c.com/base1.
Теперь, если пропадает связь с первым (пропал инет, электричество, умер и т.д..) пользователь автоматически переключается на второй, где актуальная информация в базе sql.
Подскажите в какую сторону рыть чтобы все это связать?
На одном из низ развернута база и опубликована в инет. Оба сервера удаленные друг от друга, смотрять в инет.
Вопрос: как объединить этих два физических сервера в одно целое, чтобы при потери связи с первым - можно было продолжать в реальном времени работать с вторым.
Объединить оба ір серверов думаю через отдельное доменное имя. Т.е. для конечного пользователя будет доступ представлен по имени типа server1c.com/base1.
Теперь, если пропадает связь с первым (пропал инет, электричество, умер и т.д..) пользователь автоматически переключается на второй, где актуальная информация в базе sql.
Подскажите в какую сторону рыть чтобы все это связать?
По теме из базы знаний
- Таблицы серверов (как просто выбрать сервер)
- Распознавание и загрузка сканов в 1С "одним нажатием". УПД, ТОРГ-12, накладные, счета, номенклатура, заказы и т.д.
- Как настроить сервер 1С по умолчанию для ПРОФ лицензии после 10.09.2019
- Настройка отказоустойчивого кластера 1C + PostgreSQL (etcd+patroni+haproxy) на Centos 8
- Экосистема 1С:Предприятие: вчера, сегодня, завтра
Найденные решения
В принципе можно. Т.е. в dns вносите две записи с разными ip для my1s.mydomain.ru .
Про приоритеты не знаю ...
Думается что выйдет не очень.
Почему?
Скорее всего dns-зону mydomain.ru держите не вы, а регистратор вашего домена.
Поэтому "настроить приоритеты" на чужом сервере не выйдет.
Во всяком случае в web-морде управления dns-зоной регистратора домена я такого не видел.
За всех конечно не скажу, сам работал давно с ru-center и reg.ru.
+ (!!!) типовые dns-сервера не проверяют доступность и не корректируют свой алгорим в соответствии с этим.
В общем, т.к. dns-сервер не ваш, то у вас не получится ничего кроме обычного roundrobin-алгоритма (.
Т.е. dns-сервер будет вам попеременнке подсовывать то один ip, то другой, при этом (!!!) не проверяя доступность сервера, а просто основываясь на загруженности dns.
Для клиента это будет выглядеть так:
1. Обращается к my1s.mydomain.ru.
DNS-сервер резолвит запрос в ip-перврго офиса (он среди записей dns-зоны указан первым) и возвращает клиенту.
Клиент пытается коннектится на 217.74.109.205.
Ждет какой то таймаут и выдает сообщение - облом.
2. Пользователь снова запускает клиента.
Предположим dns-сервер при повторном обращении выдаст вам втрой ip (тот что 87.250.250.242).
Тогда клиент запустится и подключится ко второму серверу.
Как вы понима, даже при таком благоприятном стечении обстоятельств будет весьма заметная задержка.
На самом деле выйдет еще хуже. Roundrobin-алгоритм может сначала несколько раз вернуть вам первый ip и только потом второй (он ведь основывается не на доступности).
Резюме:
Почему Dynamyc DNS это единственное решение?
1. Dynamic DNS для того и предназначен, чтобы быстро пересопоставляьт ip.Не зря вам привел ссылку из вики (Динамический DNS — технология, позволяющая информации на DNS-сервере обновляться в реальном времени и по желанию в автоматическом режиме).
2. dyndns-клиент как раз и позволит вам организовать какой угодно сложный алгоритм проверки доступности ваших серверов. Используйте command line-версию dyndns-клиента и напишите (batch/power shell и т.д.)-скрипт.
3. Еси вы хотите чтобы клиенты все таки коннектились на my1s.mydomain.ru, просто сделайте запись в dns-зоне, перенаправляющую на my1s.dyndnsdomain..com и ониничего не заметят :)
Про приоритеты не знаю ...
Думается что выйдет не очень.
Почему?
Скорее всего dns-зону mydomain.ru держите не вы, а регистратор вашего домена.
Поэтому "настроить приоритеты" на чужом сервере не выйдет.
Во всяком случае в web-морде управления dns-зоной регистратора домена я такого не видел.
За всех конечно не скажу, сам работал давно с ru-center и reg.ru.
+ (!!!) типовые dns-сервера не проверяют доступность и не корректируют свой алгорим в соответствии с этим.
В общем, т.к. dns-сервер не ваш, то у вас не получится ничего кроме обычного roundrobin-алгоритма (.
Т.е. dns-сервер будет вам попеременнке подсовывать то один ip, то другой, при этом (!!!) не проверяя доступность сервера, а просто основываясь на загруженности dns.
Для клиента это будет выглядеть так:
1. Обращается к my1s.mydomain.ru.
DNS-сервер резолвит запрос в ip-перврго офиса (он среди записей dns-зоны указан первым) и возвращает клиенту.
Клиент пытается коннектится на 217.74.109.205.
Ждет какой то таймаут и выдает сообщение - облом.
2. Пользователь снова запускает клиента.
Предположим dns-сервер при повторном обращении выдаст вам втрой ip (тот что 87.250.250.242).
Тогда клиент запустится и подключится ко второму серверу.
Как вы понима, даже при таком благоприятном стечении обстоятельств будет весьма заметная задержка.
На самом деле выйдет еще хуже. Roundrobin-алгоритм может сначала несколько раз вернуть вам первый ip и только потом второй (он ведь основывается не на доступности).
Резюме:
Почему Dynamyc DNS это единственное решение?
1. Dynamic DNS для того и предназначен, чтобы быстро пересопоставляьт ip.Не зря вам привел ссылку из вики (Динамический DNS — технология, позволяющая информации на DNS-сервере обновляться в реальном времени и по желанию в автоматическом режиме).
2. dyndns-клиент как раз и позволит вам организовать какой угодно сложный алгоритм проверки доступности ваших серверов. Используйте command line-версию dyndns-клиента и напишите (batch/power shell и т.д.)-скрипт.
3. Еси вы хотите чтобы клиенты все таки коннектились на my1s.mydomain.ru, просто сделайте запись в dns-зоне, перенаправляющую на my1s.dyndnsdomain..com и ониничего не заметят :)
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Думаю, нужно:
1) у клиентов устанавливать центральный кластер 1с .
2) разворачиваем отказоустойчивый кластер MS SQL Server 2012 на Windows Server 2012R2 для новичков,
3) по рисунку, прикрепил. У клиентов устанавливаем активный кластер 1с, который переключает каналы 1с т.е. с одного резервного на другой. Смотри пункт 1) и .
это правильно.
Думаю, нужно:
1) у клиентов устанавливать центральный кластер 1с .
2) разворачиваем отказоустойчивый кластер MS SQL Server 2012 на Windows Server 2012R2 для новичков,
3) по рисунку, прикрепил. У клиентов устанавливаем активный кластер 1с, который переключает каналы 1с т.е. с одного резервного на другой. Смотри пункт 1) и .
Объединить оба ір серверов думаю через отдельное доменное имя. Т.е. для конечного пользователя будет доступ представлен по имени типа server1c.com/base1.
это правильно.
Прикрепленные файлы:
(15)Провайдер провайдеру - рознь. То что я видел на порядок лучше и надежнее того что можно сваять на паре серверов. Опять же, на 1СФреш свет клином не сошелся, можно и виртуалку арендовать. Опять же, если не брать во внимание только 1СФреш, то в облаке работают очень многие крупные организации. Да, нужно считать что будет выгоднее, но не всегда расчёты в пользу своих серверов, особенно если учитывать стоимость аренды помещений и счетов за электроэнергию, и прочие "мелочи".
(1)
Ещё можно реализовать при помощи железа от Cisco или "Континент". Они умеют следить и управлять переключениями доступного оборудования. Конкретно модели не скажу, т.к. продуктовая линейка у них меняется.
Чем удобно - без разницы, где физически стоят сервера (помещение, здание, город).
По замечаниям, если в разных местах.
Есть такое понятие, как туннелирование каналов или VPN как внутри провайдера так и ! между провайдерами, его тоже можно использовать.
P.S. Имхо, у меня бывший коллега сопровождает сервера в одной виртуальной сети, при этом физически сервера стоят 3-шт США, 2 - Франция, 1-шт Англия, 1 шт - Австралия. И всё работает, все доступно. На случай физического отключения питания и отсутствия автостарта более 10 мин. есть "быстрые ноги", которые придут и жмакнут кнопочку "Вкл.".
Большинство велосипедов уже изобретено (с)
Вопрос: как объединить этих два физических сервера в одно целое, чтобы при потери связи с первым - можно было продолжать в реальном времени работать с вторым.
Ещё можно реализовать при помощи железа от Cisco или "Континент". Они умеют следить и управлять переключениями доступного оборудования. Конкретно модели не скажу, т.к. продуктовая линейка у них меняется.
Чем удобно - без разницы, где физически стоят сервера (помещение, здание, город).
По замечаниям, если в разных местах.
Есть такое понятие, как туннелирование каналов или VPN как внутри провайдера так и ! между провайдерами, его тоже можно использовать.
P.S. Имхо, у меня бывший коллега сопровождает сервера в одной виртуальной сети, при этом физически сервера стоят 3-шт США, 2 - Франция, 1-шт Англия, 1 шт - Австралия. И всё работает, все доступно. На случай физического отключения питания и отсутствия автостарта более 10 мин. есть "быстрые ноги", которые придут и жмакнут кнопочку "Вкл.".
Большинство велосипедов уже изобретено (с)
Выброшенные деньги на один сервер 1С... Надежности в плане отказа интернет вы не добьетесь установкой второго серевра 1С!
Узкое место не 1С сервер , а SQL, ибо именно там лежат данные! Поэтому нужно либо полное дублирование, то есть второй SQL с репликацией данных по инету.
И тогда при отказе сегмента с одним SQL, вы будете иметь возможность работать с другим сервером данных...
При наличии 1 SQL для надежности интернет работы достаточно одного 1С сервера физически находящегося рядом с SQL , а лучше на том же физическом компе что SQL (можно и на отдельном мощном сервере рядом с сервером SQL, если денег немеряно).
Узкое место не 1С сервер , а SQL, ибо именно там лежат данные! Поэтому нужно либо полное дублирование, то есть второй SQL с репликацией данных по инету.
И тогда при отказе сегмента с одним SQL, вы будете иметь возможность работать с другим сервером данных...
При наличии 1 SQL для надежности интернет работы достаточно одного 1С сервера физически находящегося рядом с SQL , а лучше на том же физическом компе что SQL (можно и на отдельном мощном сервере рядом с сервером SQL, если денег немеряно).
(5)
Да, я это понимаю, что данные на sql и их нужно как дублировать на второй сервер.. Но что-то вся картинка не складывается..
Как сделать автоматическое копирование данных одной базы первого sql на второй?
Если даные будут копировать на лету, нужен ли кластер серверов 1С? или просто сделать две базы даных 1С, которые будут на разных серверах с одной и той же информацией?
е на том же физическом компе что SQL (м
Да, я это понимаю, что данные на sql и их нужно как дублировать на второй сервер.. Но что-то вся картинка не складывается..
Как сделать автоматическое копирование данных одной базы первого sql на второй?
Если даные будут копировать на лету, нужен ли кластер серверов 1С? или просто сделать две базы даных 1С, которые будут на разных серверах с одной и той же информацией?
(7) группа доступности always-on или кластер, оба варианта требуют поднятия отказоусточивого кластера (минимум 2 сервера + вотчер), а к ним еще AD + VPN между серверами, ну и если у вас +-100мб\с интернет, этот вариант смысла нет рассматривать
Что группа, что кластер имеют единую точку входа, т.е. вы подрубаетесь к db.mydomain.local а он уже ведет на активную ноду.
В целом такое решение довольно тормозное, если сравнивать 1С + MSSQL на одной машине, да и в целом нормальная конфигурация выйдет довольно дорого, проще взять облако.
Что группа, что кластер имеют единую точку входа, т.е. вы подрубаетесь к db.mydomain.local а он уже ведет на активную ноду.
В целом такое решение довольно тормозное, если сравнивать 1С + MSSQL на одной машине, да и в целом нормальная конфигурация выйдет довольно дорого, проще взять облако.
(5)
Предложение о размещении сервера приложений и сервера СУБД на одном сервере прямо противоречит рекомендациям 1С (да и многих других). Если, конечно, мы говорим про более-менее приличное число пользователей.
(1) Кластеризация/резервирование, как вам верно написали, должна касаться не только сервера 1С, но и сервера БД и всего другого оборудования.
Конечно, если речь идет о более-менее нагруженном решении с приличным числом пользователей. Но в этом случае сервер сам по себе не будет самым слабым звеном и так просто и быстро не умрет (если, конечно, не из отходов сделан). Скорее подвести может именно электричество (инвестируйте в хорошие UPS) или подключение к сети Интернет (инвестируйте в резервирование канала и хорошее сетевое оборудование).
А если решение на небольшое число пользователей, то может лучше все-так хостинг/облако? И пусть у провайдеров голова болит.:)
При наличии 1 SQL для надежности интернет работы достаточно одного 1С сервера физически находящегося рядом с SQL , а лучше на том же физическом компе что SQL (можно и на отдельном мощном сервере рядом с сервером SQL, если денег немеряно).
Предложение о размещении сервера приложений и сервера СУБД на одном сервере прямо противоречит рекомендациям 1С (да и многих других). Если, конечно, мы говорим про более-менее приличное число пользователей.
(1) Кластеризация/резервирование, как вам верно написали, должна касаться не только сервера 1С, но и сервера БД и всего другого оборудования.
Конечно, если речь идет о более-менее нагруженном решении с приличным числом пользователей. Но в этом случае сервер сам по себе не будет самым слабым звеном и так просто и быстро не умрет (если, конечно, не из отходов сделан). Скорее подвести может именно электричество (инвестируйте в хорошие UPS) или подключение к сети Интернет (инвестируйте в резервирование канала и хорошее сетевое оборудование).
А если решение на небольшое число пользователей, то может лучше все-так хостинг/облако? И пусть у провайдеров голова болит.:)
(25) Если вы имеете под "приличным" от 100 пользователей (меньшее количество у нас прекрасно себя чувствует на 1), то возможно 2 физических сервера (если средства позволяют), но подчеркиваю Физических.
Ни в коем разе не связываться с виртуализацией, ибо будет только гораздо хуже.
Ни в коем разе не связываться с виртуализацией, ибо будет только гораздо хуже.
Ну тут решений может быть много, но для начала нужно правильно организовать сеть. Вам нужно поднять VPN тоннель между этими серверами, естественно, что будет лучше, если они будут в одном домене. Отказоустойчивый кластер 1С, как написано выше, при низкой скорости связи получить не сможете, но. Вы можете попробовать решить проблему на стороне SQL, с помощью механик теневого копирования. В этом случае, при падении одного сервера будет аналогичный сервер, но опять же не абсолютная копия. Проблема в том, что из-за большой удаленности этих машин их синхронизация будет проблематична даже при гигабитном канале, поскольку на участке сети между вашими серверами может быть какой нибудь глючный шлюз, что в свою очередь изуродует всю вашу задумку, со всеми вытекающими.
Отказоустойчивый - это мечта. Правильнее говорить - высокодоступные, ибо реализовать полную отказоустойчивость невозможно. Если расстояние большое, то нужно поднимать два высокодступных сервера и фигачить обмены между ними. Просто тут есть одна большая гадость, которая все вам испортит - большое расстояние = куча промежуточных шлюзов = потери пакетов и т.д.
Но. Если расстояние не большое, то есть вариант реализовать между ними EOIP тоннель по внутреннему каналу провайдера с максимально возможной скоростью, тогда их будет можно запихивать в кластер. Есть условия, которые сильно влияют на решение.
Отказоустойчивый - это мечта. Правильнее говорить - высокодоступные, ибо реализовать полную отказоустойчивость невозможно. Если расстояние большое, то нужно поднимать два высокодступных сервера и фигачить обмены между ними. Просто тут есть одна большая гадость, которая все вам испортит - большое расстояние = куча промежуточных шлюзов = потери пакетов и т.д.
Но. Если расстояние не большое, то есть вариант реализовать между ними EOIP тоннель по внутреннему каналу провайдера с максимально возможной скоростью, тогда их будет можно запихивать в кластер. Есть условия, которые сильно влияют на решение.
Как все все глобально замыслили ... кластеры, шмастеры ...
И самое главное все это не будет работать если у вас для надежносте сервера разнесены по разным офисам
Не совсем понял сколько у вас серверов (то ли 2, то ли 4), но суть идеи одна и таже:
1. Предположим у вас всего два сервера.
На каждом сервере поднимаете MSSQL+Сервер 1С (все вместе на одном).
Заливаете базу, настраиваете в базе РИБ (полная синхронизация) и гоняете выгрузки между базами при помощи Resylio Sync (он же в девичестве btsync)
И дальше синхронизируйте свои два сервера хоть в одной локалке одного офиса, хоть через Интернет в разных офисах.
2. Если ваши сервера в разных офисах (вы специально территориально разнесли их для надежности/защиты от сбоя электропитания/и т.д.) и вы хотите чтобы ваши клиенты всегда коннектились на одно dns-имя (например my1s.mydomain.ru) и не заморачивались его изменением если какой то сервер 1С упадет, то идете в сторону Dynamic DNS (.
Зачем ? Dynamic DNS позволяет очень быстро сопоставить dns-имени другой ip-адрес
Для этого на одном из хороших DynDNS-сервисов покупаете аккаунт.
В одном из офисов (предположим его адрес 217.74.109.205) настраиваете автоматический запуск dyndns-клиента. Этот клиент будетвсе врем сигналить в dyndns-сервис что "домену my1s.dyndnsdomaimcom соответствует ip-адрес предположим его адрес 217.74.109.205".
Во втором офисе (предположим его адрес 87.250.250.242) создаете скрипт, который делает следующее - постоянно пингует первый сервер и в случае его недоступности запускает dyndns-клиента.
Получается что если в первом офисе отключат электричество, то первый сервер будет недоступен.
Сервер во втором офисе просекет это и запустит dyndns-клиента, который свяжет имя my1s.dyndnsdomaim.com с новым ip-адресом, т.е. адресом второго офиса (87.250.250.242).
А клиенты ... они как подключались, так и будут подключаться к my1s.dyndnsdomaim.com
P.S. Сервер во втором офисе не перестает пинговать первый офис. При восстановлении связи, но гасит dyndns-клиент во втором офисе (в первом он и так стартанет автоматически после восстановления электропитания)
И самое главное все это не будет работать если у вас для надежносте сервера разнесены по разным офисам
Не совсем понял сколько у вас серверов (то ли 2, то ли 4), но суть идеи одна и таже:
1. Предположим у вас всего два сервера.
На каждом сервере поднимаете MSSQL+Сервер 1С (все вместе на одном).
Заливаете базу, настраиваете в базе РИБ (полная синхронизация) и гоняете выгрузки между базами при помощи Resylio Sync (он же в девичестве btsync)
И дальше синхронизируйте свои два сервера хоть в одной локалке одного офиса, хоть через Интернет в разных офисах.
2. Если ваши сервера в разных офисах (вы специально территориально разнесли их для надежности/защиты от сбоя электропитания/и т.д.) и вы хотите чтобы ваши клиенты всегда коннектились на одно dns-имя (например my1s.mydomain.ru) и не заморачивались его изменением если какой то сервер 1С упадет, то идете в сторону Dynamic DNS (.
Зачем ? Dynamic DNS позволяет очень быстро сопоставить dns-имени другой ip-адрес
Для этого на одном из хороших DynDNS-сервисов покупаете аккаунт.
В одном из офисов (предположим его адрес 217.74.109.205) настраиваете автоматический запуск dyndns-клиента. Этот клиент будетвсе врем сигналить в dyndns-сервис что "домену my1s.dyndnsdomaimcom соответствует ip-адрес предположим его адрес 217.74.109.205".
Во втором офисе (предположим его адрес 87.250.250.242) создаете скрипт, который делает следующее - постоянно пингует первый сервер и в случае его недоступности запускает dyndns-клиента.
Получается что если в первом офисе отключат электричество, то первый сервер будет недоступен.
Сервер во втором офисе просекет это и запустит dyndns-клиента, который свяжет имя my1s.dyndnsdomaim.com с новым ip-адресом, т.е. адресом второго офиса (87.250.250.242).
А клиенты ... они как подключались, так и будут подключаться к my1s.dyndnsdomaim.com
P.S. Сервер во втором офисе не перестает пинговать первый офис. При восстановлении связи, но гасит dyndns-клиент во втором офисе (в первом он и так стартанет автоматически после восстановления электропитания)
(21)
А нельзя ли в качестве DynDNS-сервисов использовать реальный домен, где указать реальные ІР + приоритет? Не будет ли автоматически происходить переключение на второй по приоритету сервер, если пропадет связь с первым с более высоким приоритетом?
Dynamic DNS
А нельзя ли в качестве DynDNS-сервисов использовать реальный домен, где указать реальные ІР + приоритет? Не будет ли автоматически происходить переключение на второй по приоритету сервер, если пропадет связь с первым с более высоким приоритетом?
В принципе можно. Т.е. в dns вносите две записи с разными ip для my1s.mydomain.ru .
Про приоритеты не знаю ...
Думается что выйдет не очень.
Почему?
Скорее всего dns-зону mydomain.ru держите не вы, а регистратор вашего домена.
Поэтому "настроить приоритеты" на чужом сервере не выйдет.
Во всяком случае в web-морде управления dns-зоной регистратора домена я такого не видел.
За всех конечно не скажу, сам работал давно с ru-center и reg.ru.
+ (!!!) типовые dns-сервера не проверяют доступность и не корректируют свой алгорим в соответствии с этим.
В общем, т.к. dns-сервер не ваш, то у вас не получится ничего кроме обычного roundrobin-алгоритма (.
Т.е. dns-сервер будет вам попеременнке подсовывать то один ip, то другой, при этом (!!!) не проверяя доступность сервера, а просто основываясь на загруженности dns.
Для клиента это будет выглядеть так:
1. Обращается к my1s.mydomain.ru.
DNS-сервер резолвит запрос в ip-перврго офиса (он среди записей dns-зоны указан первым) и возвращает клиенту.
Клиент пытается коннектится на 217.74.109.205.
Ждет какой то таймаут и выдает сообщение - облом.
2. Пользователь снова запускает клиента.
Предположим dns-сервер при повторном обращении выдаст вам втрой ip (тот что 87.250.250.242).
Тогда клиент запустится и подключится ко второму серверу.
Как вы понима, даже при таком благоприятном стечении обстоятельств будет весьма заметная задержка.
На самом деле выйдет еще хуже. Roundrobin-алгоритм может сначала несколько раз вернуть вам первый ip и только потом второй (он ведь основывается не на доступности).
Резюме:
Почему Dynamyc DNS это единственное решение?
1. Dynamic DNS для того и предназначен, чтобы быстро пересопоставляьт ip.Не зря вам привел ссылку из вики (Динамический DNS — технология, позволяющая информации на DNS-сервере обновляться в реальном времени и по желанию в автоматическом режиме).
2. dyndns-клиент как раз и позволит вам организовать какой угодно сложный алгоритм проверки доступности ваших серверов. Используйте command line-версию dyndns-клиента и напишите (batch/power shell и т.д.)-скрипт.
3. Еси вы хотите чтобы клиенты все таки коннектились на my1s.mydomain.ru, просто сделайте запись в dns-зоне, перенаправляющую на my1s.dyndnsdomain..com и ониничего не заметят :)
Про приоритеты не знаю ...
Думается что выйдет не очень.
Почему?
Скорее всего dns-зону mydomain.ru держите не вы, а регистратор вашего домена.
Поэтому "настроить приоритеты" на чужом сервере не выйдет.
Во всяком случае в web-морде управления dns-зоной регистратора домена я такого не видел.
За всех конечно не скажу, сам работал давно с ru-center и reg.ru.
+ (!!!) типовые dns-сервера не проверяют доступность и не корректируют свой алгорим в соответствии с этим.
В общем, т.к. dns-сервер не ваш, то у вас не получится ничего кроме обычного roundrobin-алгоритма (.
Т.е. dns-сервер будет вам попеременнке подсовывать то один ip, то другой, при этом (!!!) не проверяя доступность сервера, а просто основываясь на загруженности dns.
Для клиента это будет выглядеть так:
1. Обращается к my1s.mydomain.ru.
DNS-сервер резолвит запрос в ip-перврго офиса (он среди записей dns-зоны указан первым) и возвращает клиенту.
Клиент пытается коннектится на 217.74.109.205.
Ждет какой то таймаут и выдает сообщение - облом.
2. Пользователь снова запускает клиента.
Предположим dns-сервер при повторном обращении выдаст вам втрой ip (тот что 87.250.250.242).
Тогда клиент запустится и подключится ко второму серверу.
Как вы понима, даже при таком благоприятном стечении обстоятельств будет весьма заметная задержка.
На самом деле выйдет еще хуже. Roundrobin-алгоритм может сначала несколько раз вернуть вам первый ip и только потом второй (он ведь основывается не на доступности).
Резюме:
Почему Dynamyc DNS это единственное решение?
1. Dynamic DNS для того и предназначен, чтобы быстро пересопоставляьт ip.Не зря вам привел ссылку из вики (Динамический DNS — технология, позволяющая информации на DNS-сервере обновляться в реальном времени и по желанию в автоматическом режиме).
2. dyndns-клиент как раз и позволит вам организовать какой угодно сложный алгоритм проверки доступности ваших серверов. Используйте command line-версию dyndns-клиента и напишите (batch/power shell и т.д.)-скрипт.
3. Еси вы хотите чтобы клиенты все таки коннектились на my1s.mydomain.ru, просто сделайте запись в dns-зоне, перенаправляющую на my1s.dyndnsdomain..com и ониничего не заметят :)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот