☰

Балансировка нагрузки DNS с проверками работоспособности

tag-icon • tag-icon domain-name-system load-balancing
Балансировка нагрузки DNS с проверками работоспособности

У меня тут проблема.

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

Эти экземпляры используют (очевидно) private.

Мы не можем использовать решение балансировки нагрузки на основе VIP, поскольку этот облачный провайдер не допускает использования частных IP-адресов между регионами, поэтому NLB здесь не подходит.

Нам нужен DNS-сервер (ну, на самом деле, два, по крайней мере) с возможностями проверки работоспособности записи A. Позвольте мне привести пример:

  1. Услуга:
  • Сервер A - Регион 1 - IP 10.1.1.100
  • Сервер B - Регион 2 - IP 172.26.1.100
  1. Балансировщики DNS (использующие одну и ту же базу данных записей и конфигурации):
  • DNS A - Регион 1 - IP 10.1.1.50
  • DNS B - Регион 2 - IP 172.26.1.50
  • DNS-запись 1: any.local - 10.1.1.50
  • DNS-запись 2: any.local - 172.26.1.50
  1. Клиенты:
  • Клиент A - Любой регион - Любой IP
  1. Сценарий А:
  • У клиента A как DNS A, так и DNS B настроены в качестве DNS-серверов.
  • Клиент A запрашивает any.local на DNS-сервере A
  • Сервер A не в сети
  • DNS-сервер A имеет внутренние проверки работоспособности, обнаруживает его и отвечает IP-адресом сервера B (172.26.1.50)
  • TTL устанавливается равным 0 (нулю) или чему-то столь же низкому, чтобы избежать кэширования.
  1. Сценарий Б:
  • У клиента A как DNS A, так и DNS B настроены в качестве DNS-серверов.
  • Клиент A запрашивает any.local, DNS-сервер A не работает, поэтому DNS-сервер B отвечает
  • Сервер B не в сети
  • DNS-сервер B имеет внутренние проверки работоспособности, обнаруживает его и отвечает IP-адресом сервера A (10.1.1.100)
  • TTL устанавливается равным 0 (нулю) или чему-то столь же низкому, чтобы избежать кэширования.

По сути: DNS-сервер, проверяющий работоспособность IP-адресов DNS-записей.

С уважением.

решение1

У клиента A как DNS A, так и DNS B настроены в качестве DNS-серверов.

эм, вы направляетесь в мир боли, имея машину, использующую несколько DNS-серверов, настроенных с разными разделенными данными. Вам действительно нужно будет построить свой собственный разрешенный стек на хосте мониторинга, чтобы получить предсказуемое поведение.

Способ мониторинга этой службы без разделения DNS:

service.example.com.  CNAME region1_service.example.com.
service.example.com.  CNAME region2_service.example.com.
region1_service.example.com. A 10.1.1.50
region2_service.example.com. A 172.26.1.50

И следите за каждым из:

  • service.example.com
  • region1_service.example.com
  • region2_service.example.com

Альтернативно ваш агент по мониторингуможетподдержка установки явных адресов - так что вы можете отдельно контролировать каждый экземпляр. Но тогда у вас есть сложность с отметкой сбоя на ОБОИХ узлах, что гораздо серьезнее, чем сбой на одном из узлов.

Вам также следует проверить, КАК ваш клиент мониторинга реализует rrDNS. Время обнаружения отказа при соблюдении правил составляет ~5 минут, но браузеры применяют порог около 10 секунд для первоначального подключения и <1 секунды для последующих запросов.

решение2

В конце концов, для этого ЕСТЬ решения. Это, по сути, то, что предоставляет GSLB, есть много коммерческих решений.

Если вы хотите сделать это с определенной простотой и открытым исходным кодом, вы можете использовать PowerDNS с записями LUA в кластере PowerDNS.

Связанный контент