В нашем блоге мы неоднократно рассказывали о построении инфраструктуры провайдера облачных сервисов и о том, как облегчаем пользователям взаимодействие с ней.
Сегодня мы расскажем о том, как на основе различных продуктов реализовывали в системе функцию управления 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-проект и побайтово сравнивать результат выполнения запроса.
- В итоге мы сравнили реализации продукта на Java и .Net и выявили следующие различия в них:
- Кодирование с помощью AES и подсчеты хэш-сум в .Net реализовано удобнее и интуитивно понятней. Не нужно городить громоздких конструкций с кучей обновлений Сipher.
- Байтовые операции в .Net заполняют строку слева-направо, что приводит к некоторой мешанине и необходимости «обертывать» эти операции.
- В Java есть контейнер Map — очень гибкая вещь, которая может быть как хэш-таблицей так и списком и деревом.
Как это работает
В итоге схема работы выглядит следующим образом: клиент в панели управления 1cloud вносит нужные изменения, что инициирует создание задачи. Она поступает к специальному обработчику, а затем через REST API отправляется серверу управления DNS, где уже и осуществляются итоговые действия:
Также мы поработали над упрощением взаимодействия пользователя с интерфейсом на самом первом этапе. Чтобы создать зону, ему нужно вбить домен и IP-адрес, после чего автоматически будет создана зона с записями SOA, NS (на серверы ns01.1cloud.ru и ns02.1cloud.ru) и A:
Далее можно создать для зоны любую новую запись, заполнив несложную форму:
Заключение
Запуск новой системы управления DNS состоялся совсем недавно, и у нас есть определенные планы по ее доработке в будущем.
Также у нас есть еще много планов по оптимизации инфраструктуры и повышению удобства ее использования. Среди них, например, автоматизация задач по установке и восстановлению данных из бэкапов, внедрение модели оплаты только за потребленные ресурсы (pay as you go) и развертывание системы автомасштабирования инфраструктуры при достижении пиковой нагрузки на текущие серверы пользователей.
На сегодня все, спасибо за внимание. Будем рады ответить на вопросы в комментариях. Подписывайтесь на наш блог — в следующих постах мы продолжим рассказывать о различных аспектах построения и оптимизации облачной инфраструктуры.
ссылка на оригинал статьи http://habrahabr.ru/post/261139/
Добавить комментарий