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

Сегодня мы расскажем о том, как на основе различных продуктов реализовывали в системе функцию управления DNS.

В предыдущих сериях

• How-to: Как строится инфраструктура хостинг-провайдера
• Редизайн сайта хостинг-провайдера: ошибки и решения
• Как облегчить клиентам хостинга создание частных сетей и виртуальных серверов: Опыт проекта 1cloud
• How-to: Как API улучшает инфраструктуру хостинг-провайдера
• How-to: Автоматизация бухгалтерских задач хостинг-провайдера
• Высокая производительность и хостинг-инфраструктура: Опыт проекта 1cloud
• Рука на пульсе: как мы создавали систему отслеживания нагрузки на серверы пользователей
• Управление дисковым пространством сервера на лету: опыт 1cloud

В чем проблема

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

До недавнего времени в системе 1cloud не было возможности непосредственного редактирования записей — пользователи должны были написать заявку в службу поддержки, которая затем исполнялась инженерами. Минусы такого подхода очевидны — весь процесс сложнее и занимает больше времени, кроме того результат достигается не сразу, а лишь когда заявка будет выполнена.

При этом для пользователей, которые не разбираются в ИТ, процесс управления DNS-записями является довольно сложным делом, и не все знают, какие данные нужно предоставить для создания записи (их уточнение опять же сказывается на увеличении времени обработки заявки).

Реализация или почему не BIND

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

В результате, чтобы BIND нормально работал, его нужно «допиливать» под нужды конкретной организации, что далеко не всегда является хорошим вариантом по целому ряду причин (возможные ошибки, сложность поддержки и т.д.).

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

Соответственно, столкнувшись с необходимостью организовать управление DNS, провайдеры услуг часто начинают рассматривать альтернативы BIND. Мы также изучили несколько продуктов (например, PowerDNS, Knot, NSD) и обнаружили, что ни в одном из них нет всех необходимых нам возможностей и они, так же как и BIND требуют доработок в области управления. Еще одним выявленным минусом доступных open source-решений оказалась их уязвимость к Chinese Water Turtle атакам, когда идет лавина запросов, которые не могут быть обслужены из основного кеша и уходят в бэкенд.

Стало очевидно, что необходимо посмотреть в сторону коммерческого ПО из этой области. Мы остановили свой выбор на продукте ANS Carrier-Grade DNS Appliance (он пока не является коммерчески доступным, но мы можем поделиться контактами представителей этой компании). Нас, в частности, привлекли следующие его плюсы:

• Эта система нацелена как раз на операторов IaaS, PaaS, SaaS, операторов дата-центров и хостинговые компании.
• Из первого пункта вытекает более высокая производительность (используется специальная версионная база данных) и простота масштабирования инфраструктуры, диагностики и управления.
• Изменения в конфигурации зон и изменение ресурсных записей не приводит к перерыву в обслуживании.
• Поддержка очень большого количества зон и ресурсных записей в них
• Статистика запросов к каждой зоне.
• Журналирование всех DNS запросов без пенальти по производительности, с удобным поиском по журналу.
• Наличие шаблонов конфигураций и данных зон.
• Поддержка со стороны разработчиков.

У данного продукта также есть API (Python, Java), что вообще тоже является плюсом, однако в нашем случае все оказалось чуть сложнее — нам нужен был открытый интерфейс на C#. Пришлось своими силами портировать проприетарный протокол, а затем «обернуть» получившуюся реализацию в REST API.

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

1. В итоге мы сравнили реализации продукта на Java и .Net и выявили следующие различия в них:
2. Кодирование с помощью AES и подсчеты хэш-сум в .Net реализовано удобнее и интуитивно понятней. Не нужно городить громоздких конструкций с кучей обновлений Сipher.
3. Байтовые операции в .Net заполняют строку слева-направо, что приводит к некоторой мешанине и необходимости «обертывать» эти операции.
4. В Java есть контейнер Map — очень гибкая вещь, которая может быть как хэш-таблицей так и списком и деревом.

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

В итоге схема работы выглядит следующим образом: клиент в панели управления 1cloud вносит нужные изменения, что инициирует создание задачи. Она поступает к специальному обработчику, а затем через REST API отправляется серверу управления DNS, где уже и осуществляются итоговые действия:



Также мы поработали над упрощением взаимодействия пользователя с интерфейсом на самом первом этапе. Чтобы создать зону, ему нужно вбить домен и IP-адрес, после чего автоматически будет создана зона с записями SOA, NS (на серверы ns01.1cloud.ru и ns02.1cloud.ru) и A:



Далее можно создать для зоны любую новую запись, заполнив несложную форму:

Заключение

Запуск новой системы управления DNS состоялся совсем недавно, и у нас есть определенные планы по ее доработке в будущем.

Также у нас есть еще много планов по оптимизации инфраструктуры и повышению удобства ее использования. Среди них, например, автоматизация задач по установке и восстановлению данных из бэкапов, внедрение модели оплаты только за потребленные ресурсы (pay as you go) и развертывание системы автомасштабирования инфраструктуры при достижении пиковой нагрузки на текущие серверы пользователей.

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