Как работает глобальная балансировка нагрузки на услуги GSLB

СООБЩЕНИЕ ОТ Zevenet | 16 января 2018 г.

Обзор GSLB

В настоящее время высокая доступность ИТ-сервисов является обязательной, и именно поэтому компании и организации разрабатывают вычислительные системы, распределенные по всему миру, и размещают сервисы в более чем одном центре обработки данных, поскольку он предлагает следующие преимущества:

Отказоустойчивость: при сбое размещенной службы в центре обработки данных служба включается на любом из других доступных сайтов.
Автоматическое восстановление ЦОД: при сбое одного центра обработки данных служба автоматически перенаправляется на любой другой доступный центр обработки данных.
Балансировка нагрузки: трафик можно оптимизировать, распределяя нагрузку между всеми доступными сайтами, что увеличивает задержку и ускоряет доставку услуг.
Улучшенная задержка: трафик клиентского приложения напрямую с реального сервера, нет необходимости передавать все данные приложения через балансировщик нагрузки.

Принятие и внедрение ИТ-сервисов в облаке требует, чтобы метод, основанный на глобальной сети, был наилучшим вариантом для предоставления решений высокой доступности с географической привязкой. Это то, что мы называем Глобальная балансировка нагрузки на услуги or GSLB.

Когда использовать GSLB

Сервис GSLB рекомендуется использовать в следующих случаях:

Компании, которые размещают свои услуги в нескольких центрах обработки данных через WAN.
Компании, которым требуется создать высокую доступность услуг или центров обработки данных.
Интернет-провайдеры для создания входящих служб балансировки нагрузки, которые будут использоваться их пользователями.

Определенно, когда требуется разделить пользователей и трафик между серверами по всему миру без точек отказа, GSLB - правильное решение.

Как работает GSLB

GSLB механизм балансировки нагрузки при DNS протокол, это быстро и надежно, потому что он использует UDP Протокол и ответ клиента практически в режиме реального времени.

Например, в общем запросе DNS www.zvnlb.netклиент отправляет разрешение DNS-запроса на локально настроенные DNS-серверы (например, 8.8.8.8 и 8.8.4.4 ), а затем клиентская система случайным образом выбирает один из серверов для выполнения запроса и отправки запроса.

Выбранный DNS-сервер получает запрос от клиента (например, какой IP-адрес www.zvnlb.net? ) и локально настроенные DNS-серверы пытаются найти, кто отвечает за разрешение зоны DNS zvnlb.net.

DNS, используемый клиентом, 8.8.8.8 or 8.8.4.4 в этом случае обнаруживает, что ns1.zvnlb.net и ns2.zvnlb.net несут ответственность за разрешения зоны для zvnlb.net поэтому они отправляют DNS-запрос, полученный клиентом (например, какой IP-адрес www.zvnlb.net? ) к одному из них.

Один из серверов имен либо ns1.zvnlb.net or ns2.zvnlb.net получает запрос DNS от 8.8.8.8 or 8.8.4.4 и затем сервер имен, который получает запрос, проверяет доступные серверы для хоста www.zvnlb.net и он ответит на запрос DNS со списком доступных серверов приложений, чтобы обслуживать реальное приложение для хоста www.zvnlb.netследовательно, эта информация будет окончательно получена клиентом.

Теперь клиент случайным образом выберет один из серверов приложений из списка, полученного в запросе DNS, и отправит запрос непосредственно в приложение. http://www.zvnlb.net.

Серверы имен ns1.zvnlb.net (в нашем примере, расположенном во Франкфурте) и ns2.zvnlb.net (в нашем примере, расположенном в Торонто) постоянно проверяют состояние работоспособности реального приложения хоста www.zvnlb.net (192.235.113.3 и 194.23.52.21 в нашем случае). Если ns1.zvnlb.net or ns2.zvnlb.net обнаруживает любую проблему, проверяя состояние работоспособности некоторых из реальных серверов, затем недоступный сервер будет деактивирован на определенное время, а его IP-адрес не будет указан в запросах DNS, пока он снова не станет доступным.

Следующая диаграмма показывает описанный трафик DNS с возможностями GSLB.

DNS-трафик с функциями GSLB

Настройка GSLB для аварийного восстановления центров обработки данных

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

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

Мы развернули два балансировщика нагрузки Zevenet в двух дата-центрах во Франкфурте. 159.89.7.124 и торонто 159.203.12.35 и у нас есть веб-сервис, который отвечает на хост DNS www.zvnlb.net, настроенный в Центр обработки данных 1 и Центр обработки данных 2, Проект этой архитектуры позволит отправлять весь трафик клиентов на Центр обработки данных 1 но если это не удается, то перенаправляет клиентов на Центр обработки данных 2.

Для достижения этой конфигурации следуйте процедуре ниже.

Подключитесь к веб-панели Zevenet в Центр обработки данных 1 (Франкфурт для нашего случая), нажмите в главном меню GSLB модуль и создать новый - в нашем примере будет называться DNS1-Франкфурт в виртуальном порту 53.

создать ферму GSLB в одном центре обработки данных

После создания фермы, пожалуйста, отредактируйте ее и перейдите на вкладку Зоны и создайте зону DNS, которой будет управлять модуль GSLB, в этом случае zvnlb.net, следующим образом:

Создайте зону GSLB в первом центре обработки данных

После создания этой зоны выполните первую конфигурацию, как показано ниже:

Зона редактирования GSLB в первом дата-центре

Обратите внимание, что ns1 и ns2 серверы имен отвечают за разрешение DNS для зоны zvnlb.net (в нашем случае один сервис GSLB во Франкфурте и другой в Торонто).

Затем подключитесь к веб-панели Zevenet в центре обработки данных 2, в главном меню выберите GSLB и создать новый - в нашем случае будет называться DNS2-Торонто в виртуальном порту 53.

создать ферму GSLB во втором центре обработки данных DR

Отредактируйте новую ферму GSLB и перейдите на вкладку Зонысоздайте здесь зону DNS, которая будет управляться этой службой GSLB для zvnlb.net следующим образом:

настроить зону GSLB во втором дата-центре

После создания этой новой зоны, пожалуйста, сделайте первую конфигурацию следующим образом:

Зона редактирования GSLB в Торонто

Как и в случае с GSLB в Центр обработки данных 1, серверы имен n1 и n2 будет указывать на услуги GSLB в обоих Центр обработки данных 1 и Центр обработки данных 2, Соответственно.

Затем нажмите на вкладке Услуги и создать новый сервис, например webpriority:

создать сервис GSLB с приоритетом

Выберите Алгоритм вариант Приоритет: подключение всегда к самому первому доступному и настройте сервис следующим образом:

GSLB редактировать приоритет обслуживания

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

Обратите внимание, что если Ферма Страж не настроен для применения какой-либо проверки работоспособности, служба GSLB использует значение по умолчанию check_tcp на порт TCP, определенный в поле проверки работоспособности в конфигурации службы.

Чтобы включить новый сервис, перейдите в созданную зону (zvnlb.net в нашем случае) и создаем новый Ресурс, Затем создайте его, выбрав новый Сервис как показано ниже.

GSLB использует приоритет обслуживания

Наконец, сохраните изменения. Эту конфигурацию необходимо применить в обоих дата-центрах.

На данный момент, хозяин www.zvnlb.net управляется модулем GSLB в приоритет режим, поэтому весь трафик будет отправлен на Центр обработки данных 1 а затем, в случае сбоя, трафик будет перенаправлен на другой доступный Центр обработки данных 2.

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

Применяя этот метод, мы могли бы добавить столько центров обработки данных, сколько необходимо, включая новые серверы имен со службой GSLB.

Следующий запрос DNS показывает конфигурацию серверов имен для zvnlb.net и разрешение DNS для хоста www.zvnlb.net.

user@client:# host -t ns zvnlb.net
zvnlb.net name server ns2.zvnlb.net.
zvnlb.net name server ns1.zvnlb.net.

Оба сервера имен используют виртуальные IP-адреса, настроенные в фермах GSLB.

Теперь используйте текущие DNS-серверы для разрешения хоста (например, WWW) в этой зоне:

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211

Как показано, на данный момент хост 188.166.230.211 является активным реальным узлом приложения в Центр обработки данных 1, Как только хост недоступен (например, служба http в 188.166.230.211 не работает) разрешение DNS изменится, как показано ниже.

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

Как только сервер приложений выходит из строя, разрешение DNS изменит хост на Центр обработки данных 2, Однажды хозяин в Центр обработки данных 1 до отказа будет применен автоматически.

Настройка GSLB для активно-активных центров обработки данных

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

В таких случаях, пожалуйста, используйте метод обмена для вашей службы GSLB, который называется Круглая Робин Балансировка Нагрузки как показано в примере для новой службы под названием Web:

создать сервис GSLB с общими и активно-активными дата-центрами

Теперь добавьте его в зону zvnlb.net и изменить конфигурацию ресурса WWW следующим образом:

создать ресурс DNS для сервиса GSLB с циклическим перебором

Сохраните изменения и перезапустите ферму, если потребуется.

Чтобы проверить это, попробуйте разрешить хост www.zvnlb.net и результат будет выглядеть так, как показано на рисунке:

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211
Name:	www.zvnlb.net
Address: 139.59.186.84

Обратите внимание, что преобразователь DNS возвращает оба сервера приложений, а не один, как в случае аварийного восстановления.

После сбоя хоста разрешение DNS изменится автоматически. Смотрите ниже, что происходит.

root@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

Недоступный сервер приложений деактивируется из списка ответов DNS.

Как только хозяин 188.166.230.211 снова доступен, он будет включен обратно в разрешение DNS.

Делегирование зоны в сервисе Zevenet GSLB

В случае публичной зоны (например, zvnlb.net), который предоставляет службу GSLB в качестве преобразователя серверов имен, который должен распознаваться общедоступными DNS-серверами для такого домена, тогда необходимо зарегистрировать общедоступный IP-адрес, используемый службой GSLB, в регистраторе вашего домена (например, NameCheap, Goddady или других) . Следующая ссылка объясняет, как зарегистрировать IP-адреса GSLB в качестве серверов имен в процедуре регистратора доменов.

Зарегистрируйте хост как NameServer

Следуя данной процедуре, вы должны зарегистрироваться ns1.zvnlb.net и ns2.zvnlb.net с заданными IP-адресами.

Создание выделенной подзоны для GSLB

На всякий случай, если невозможно делегировать разрешение DNS службе GSLB Zevenet, можно выполнить конфигурацию, описанную ниже. В следующем примере показано, как построить подзона для zvnlb.net это указывает на NameServers этой новой подзоны в сервисе GSLB.

Узел 1 (например ns1.zvnlb.net с IP 162.243.5.109) и расширение Узел 2 (например ns2.zvnlb.net с IP 178.62.233.104) настроены ли серверы имен и предлагают ли сервисы разрешения DNS для зоны zvnlb.netэта зона находится под общедоступной службой DNS Bind9, и мы хотим предложить возможности GSLB для некоторых узлов нашей инфраструктуры, поэтому мы решили создать подзону DNS cluster.zvnlb.net и настроить для этого фермы 2 GSLB, такие как DNS-серверы имен.

Мы создали подзону для нашего домена cluster.zvnlb.net в наших DNS-серверах Bind9:

Создайте DNS-подзону bind9

Теперь следуйте разделу Делегирование зоны в сервисе Zevenet GSLB , чтобы сохранить 159.89.7.124 и 159.203.12.35 в нашем примере в качестве распознанных серверов имен для зоны cluster.zvnlb.net общедоступными DNS-серверами.

Затем вы можете применить конфигурацию, как описано для домена zvnlb.net в разделе выше Настройка GSLB для аварийного восстановления центров обработки данных.

Указание хоста в нашем собственном DNS, на который ссылается сервис GSLB

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

Для достижения этой конфигурации нам нужно только создать новый Ресурс в зоне DNS, которая не поддерживает параметры GSLB (например, zevenet.io управляется Bind9) как Каноническое имя or CNAME как показано ниже:

Создание CNAME в зоне GSLB

Как только изменение будет применено, www.zevenet.io будет указывать на www.zvnlb.net, но если разрешение хоста www.zvnlb.net меняется потом автоматически www.zevenet.io также изменится

Обратите внимание, что этот пример выполняется на DNS-сервере Bind9, но канонические имена или CNAMES - это конфигурации хоста DNS, поддерживаемые любой реализацией службы DNS-сервера.

Это простое объяснение показывает, что службу GSLB можно использовать, даже если наша текущая служба DNS не предлагает возможности GSLB, а просто перенаправляет разрешение данного хоста в зоне, отличной от GSLB, службе GSLB в Zevenet Load Balancer.

Поделись:

Документация в соответствии с условиями GNU Free Documentation License.

Была ли эта статья полезна?

Статьи по теме