Надеюсь, вы сможете помочь. Спасибо заранее.
У меня есть Azure Private DNS на Azure, который подключен к 4 Vnet в 2 регионах. Я читал, что могу поместить 2 IP в одну A Record (например, A Record Name sql.midomain.local IP1 192.168.1.1 / 192.168.2.1).
Я ожидал, что если VM IP1 выключен, клиент может разрешиться на IP2, но этого не произошло. Когда я делаю ping для "sql.domain.local", он всегда разрешается на IP1, несмотря на то, что эта VM выключена.
Мне это нужно, потому что мне нужна большая устойчивость: если экземпляр SQL1 в регионе 1 отключен, клиент все равно подключается к реплицированной виртуальной машине в регионе 2. Внутренний балансировщик нагрузки в Azure поддерживает это, но я не хочу назначать публичный IP-адрес своим SQL-серверам для использования внешнего балансировщика нагрузки.
Есть идеи, как этого добиться?
PD: Важно знать, что все Vnet могут достичь друг друга через пиринг vnet. Я могу достичь любой VM в любой vnet.
решение1
Я читал, что можно поместить 2 IP-адреса в одну запись A.
Нет, вы можете создать несколько записей A (или CNAME, TXT, MX) с одинаковым именем и разными значениями.
Я ожидал, что если VM IP1 выключен, клиент может разрешить IP2, но этого не произошло. Когда я делаю ping для "sql.domain.local", он всегда разрешается IP1, несмотря на то, что эта VM выключена
Когда для данного имени представлено несколько адресов, клиентдолженпопробуйте их по очереди. Это описано вЗапрос на предложение 1794. Ping — это диагностический инструмент низкого уровня; мне нужно будет провести значительное исследование, чтобы определить, является ли поведение здесь преднамеренным, анахроничным или просто дефектным.
Браузеры работают совершенно по-разному - Round Robin DNS (rrDNS) - очень эффективный инструмент для поддержки высокой доступности служб HTTP[s]. Но это потому, что они реализуют обнаружение сбоев с помощьюмногоболее короткие тайм-ауты (<1 секунды), чем у других клиентов TCP. Конфигурации TCP по умолчанию в большинстве операционных систем имеют тайм-аут обнаружения сбоя 5 минут или более. Это также предполагает, что клиент TCP должным образом соответствует RFC. По моему опыту, Java (или, возможно, код приложения, работающий поверх Java) не обрабатывает разрешение DNS, как ожидалось.
Дорогостоящая альтернатива предоставления доступа HA для внешних клиентов — многопутевой протокол TCP. IME с 2 разными провайдерами, обнаружение/переключение при отказе занимало не менее 3 минут, а иногда и вовсе не происходило.
Хотя это отличное решение для обеспечения высокой доступности для внешних клиентов, я бы не стал использовать rrDNS как средство обеспечения высокой доступности для соединений между узлами внутри данной инфраструктуры.
но я не хочу указывать публичный IP на моих SQL-серверах для использования внешней балансировки нагрузки
Не выставлять свои серверы СУБД на публичный адрес разумно. Это не значит, что вы не можете подключить их другими способами. Действительно, если у вас есть транзакционные данные на вашей СУБД, то вы действительно,ДЕЙСТВИТЕЛЬНОнеобходимо обеспечить связь между узлами базы данных. Если это доступно через пиринг vnet и ваше приложение не поддерживает встроенную возможность клиента HA, взгляните на haproxy или ProxySQL.
С другой стороны, вы можете обнаружить, что ваше приложение несколько чувствительно к задержке между сервером приложений и СУБД (например, при использовании тривиального ORM). В этом случае разрешение серверу приложений в расположении «A» подключаться к СУБД в расположении «B» НЕ будет желательным — здесь rrDNS для изолированных стеков может частично решить проблему, но вам также нужно подумать об управлении сеансами и репликации данных во время отказоустойчивости/возврата к исходному состоянию.
решение2
Когда я выполняю ping для «sql.domain.local», он всегда разрешается в IP1, несмотря на то, что эта виртуальная машина выключена.
Это естественно, поскольку операционная система кэширует разрешенный IP-адрес на время TTL, указанное DNS-сервером.
DNS имеет механизм циклического перебора, который меняет ответ каждый раз, когда клиент запрашивает его напрямую с этого сервера, но он не был разработан для сценариев отказоустойчивости, подобных вашему. Я не знаю о вашей среде, но в целом я бы рекомендовал использовать обратный прокси-сервер.