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

Недавно я протестировал DNS-сервисы высокой готовности TZO-HA фирмы Tzolkin.

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

Tzolkin разработала географически распределенную систему с высокой избыточностью для мониторинга веб-сайтов на уровне протоколов — и не только с помощью отправки пакетов. Мониторинг осуществляется из множества мест по всему миру, что позволяет уменьшить количество ложных результатов из-за сбоев в маршрутизации от провайдера к провайдеру. Как администратор сайтов со стажем могу сказать, что это действительно снижает количество получаемых предупреждений. За три недели тестирования системы Tzolkin я получал уведомления только в том случае, если что-то действительно не сработало (и потом, когда ситуация, приведшая к ошибке, была устранена).

В ходе продолжительного тестирования услуг TZO-HA я нашел, что графический интерфейс системы управления на базе браузера очень прост в использовании, и все конфигурации работали как ожидалось и своевременно. Таким образом, DNS-сервис Tzolkin — это недорогой и безвредный способ построить безопасную сеть с высокой надежностью или географической балансировкой нагрузки. В самом деле, трудно придумать другой относительно нерискованный способ поэкспериментировать с опциями высокой готовности — никакого дополнительного оборудования для этого не нужно, а услуги для начала будут стоит лишь 99,5 долл. в месяц.

Азы TZO-HA

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

Согласно спецификации разработчика, максимальное время перенаправления запросов к серверу составляет две с половиной, но обычно — одну минуту. За это время обнаруживается сбоя, изменяются записи DNS и информация пропускается через другие DNS-серверы. При тестировании я наблюдал, что для преодоления отказа обычно требовалось от 30 до 90 секунд. Большинство других решений требуют не менее 5 минут.

Одним из больших преимуществ TZO-HA является географическое балансирование нагрузки, которое выполняется через систему TZO-GEO.

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

Когда входящий DNS-запрос поступает в DNS-инфраструктуру TZO, в которой задействовано N серверов или IP-адресов, IP-адрес источника DNS-запроса сопоставляется с базой данных IP-адресов, позволяющей установить географические долготу и широту источника запроса. Затем в течение миллисекунд TZO-GEO вычисляет, какие из задействованных серверов расположены ближе источнику запроса.

Балансировать нагрузку можно также с учетом производительности серверов, основываясь на измеренном времени прохождения контрольного трафика. Если оно превышает определенный порог, значит, производительность сервера снижена. Этот инструмент можно комбинировать с географической балансировкой нагрузки, используя параметр VDV (Variable Distance Vector — вектор переменного расстояния). Когда производительность сервера снижается, сервис TZO искусственно меняет его географическую привязку таким образом, чтобы уменьшить число направляемых к нему запросов. Благодаря этой функции серверы, производительность которых снижается, по-прежнему могут участвовать в схеме балансирования нагрузки, но не так активно, как другие.

Чтобы протестировать TZO-HA и TZO-GEO, я создал два блога на базе платформы Wordpress с двумя разными IP-адресами, открытыми для внешнего доступа. Блоги должны были чуть различаться, чтобы я мог выяснить, какие запросы обработал каждый из них. Сервисы TZO работают таким образом, что пытаются загрузить выбранный вами файл (обычно малый текстовый файл только для чтения), находящийся на вашем веб-сервере, с помощью различных разбросанных по всему миру серверов с заданным интервалом времени. Если какой-то сервер не отвечает на запрос или отвечает медленно, то TZO в ответ выполняет заранее сконфигурированное балансирование нагрузки.

Таким образом, первый шаг внедрения услуг TZO — это создание и назначение файла, который будет задействован для мониторинга. Я использовал выбор по умолчанию (autofailover.html) и поместил этот небольшой текстовый файл в корневой каталог веб-сервера. Система TZO пыталась затем загрузить этот текстовый файл с каждого из моих тестовых серверов. Если загрузка не удавалась или время отклика было большим, то TZO считала это репрезентативным показателем общей производительности веб-сервера и начинала применять правила балансирования нагрузки и преодоления отказа.

Я сконфигурировал TZO-HA на несколько различных режимов преодоления отказа для двух моих серверов. (Вы можете сконфигурировать ее и для трех серверов.) Мой первый тест включал режим Failover-Stay over, когда сервер 1 обрабатывает все запросы, пока не откажет, после чего все запросы идут на сервер 2, пока и с его стороны не последует отказ. Я попробовал также режим Failover-Switch back, который аналогичен Failover-Stay over за тем исключением, что в этом случае сразу после того, как сервер 1 снова включается в работу, запросы вновь направляются к нему.

Есть также режим Successive Server Failover (который я не тестировал) для конфигураций с тремя серверами.

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

Что выяснилось

На вкладке Monitoring можно задать, сколько времени должно истечь, чтобы сервер считался неработающим или пребывающим в состоянии сниженной производительности. Этот интервал я задал в 30 секунд, а интервалы Detect Failing и Detect Passing — в 20 секунд. В результате я пришел к выводу, что настройки лучше всего регулировать исходя из текущей нагрузки на серверах.

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

После отключения сервера 1 уведомление по почте пришло меньше чем через минуту. (Когда я снова включил этот сервер, то так же быстро получил новое уведомление.) Предусмотрены и другие опции уведомления о нарушениях разной степени серьезности, причем их можно посылать на разные адреса. Должен заметить, что возможность быстро получать предупреждение о любых изменениях в записях DNS очень важна в силу увеличивающегося числа краж доменов.