Два месяца назад мы начали публичное бета-тестирование веб-хостинга на платформе Jet9. За это время с помощью участников тестирования мы проверили работу подсистем платформы: отказоустойчивого кластера, CDN и веб-акселераторов, окружения веб-хостинга сайтов, и получили оценки по взаимодействию пользователей с платформой. В одних случаях подтвердились ожидаемые результаты, в других случаях обнаружились искомые недостатки. Одновременно с этим мы оптимизировали среду веб-хостинга для типовых PHP/MySQL-сайтов и усовершенствовали работу пользовательских контейнеров.Неделю назад тестирование завершилось, мы подвели итоги и теперь предоставляем хостинг Jet9 в рабочем режиме c обеспечением для клиентов всех услуг и заявленных SLA.
Результаты тестирования
Устройство Jet9 мы в общих чертах описали в статье Тестируем Jet9 — отказоустойчивый хостинг сайтов с географической оптимизацией. Платформа состоит из трех слоев:
- фронтенды — географически распределенная сеть веб-акселераторов
- бэкенды — рабочее окружение веб-хостинга сайтов и приложений
- отказоустойчивые кластеры с узлами в разных дата-центрах
В упрощенном виде схема выглядит так:
Фронтенды распределены по России и другим странам мира. Каждый фронтенд обслуживает ближайших к нему посетителей сайта и отдает данные либо из кэша веб-акселератора, либо выполняет запрос на бэкенд, обслуживающий сайт.
На бэкендах располагаются пользовательские веб-контейнеры с одним или несколькими сайтами. Веб-контейнеру выделены ресурсы сервера в соответствии с тарифом, внутри него работают принадлежащие пользователю Apache, MySQL, PostgreSQL или другие приложения.
Бэкенды работают на кластерах высокой доступности по схеме мастер-бэкап, где каждый из узлов кластера находится в отдельном независимом дата-центре. Узлы кластера имеют общую сетевую связность (HA SLA Стандарт) или располагаются в разных автономных системах (HA SLA Бизнес и HA SLA Корпоративный).
В отдельности эти подсистемы мы используем для работы внутренних сервисов TrueVDS, предоставляем клиентам в виде услуги, например, Виртуальные серверы высокой доступности или внедрили и обслуживаем в проектах заказчиков. В Jet9 все три подсистемы были доработаны и интегрированы в одну платформу. Управление ими и их взаимодействие выполняется автоматически как в штатном режиме, так и при авариях. Владельцу сайта или разработчику приложения не требуется разбираться в том, как все это реализовано внутри, как это нужно настраивать и обслуживать. Поэтому тестирование преследовало две цели: оценить удобство работы с хостингом для обычных пользователей, и испытать собранную платформу в штатном и аварийных режимах.
Удобство работы с хостингом для обычных пользователей
В качестве панели управления по умолчанию мы взяли популярную и знакомую многим ISPManager 5. С помощью плагинов мы интегрировали ее с нашей платформой и предоставили пользователям привычный веб-интерфейс управления сайтами. Вся сложная механика по настройке веб-контейнера, работе кластера, размещению и настройке сайта в CDN, скрыта стандартной формой добавления сайта, состоящей из поля с именем домена и кнопки «Добавить». Для типовых PHP-сайтов на 1C-Битрикс, UMI.CMS, Wordpress, Drupal и т.п. никаких дополнительных действий больше и не требуется.
Так как для пользователей система внешне ничем не отличается от обычного хостинга, то никаких сложностей и дополнительных вопросов при тестировании не возникало. Сайт создавался и размещался обычным образом. Работа CDN и веб-акслелераторов была прозрачной как для администратора сайта, так и для посетителей. Но недостатки все-таки нашлись — были упущены некоторые детали в высылаемых письмах, например, отсутствовали данные для доступа по FTP, и трудно находилась информация об используемых DNS-серверах. Недостающую информацию добавили в шаблоны писем и вписали в FAQ. Как можно судить по текущему объему FAQ, большого числа вопросов пока не возникло, и затруднений у пользователей работа с сайтами не вызывала.
Испытание работы платформы
Кластеры высокой доступности реализованы на связке Pacemaker, Corosync и DRBD. Эту схему мы используем уже давно и достаточно хорошо изучили ее поведение в различных ситуациях. Для кластеров наличие или отсутствие фронтендов безразлично, логика их работы от этого не зависит. Но для работы фронтендов существенно то, что бэкенды размещены на кластерах мастер-бэкап — следовательно, фронтенд должен правильно передавать запросы на нужный бэкенд, и уметь правильно реагировать, если бэкенд переместился с мастера на бэкап.
Поэтому мы проводили испытания работы платформы и в штатном режиме, и при имитации аварий в кластере и на фронтендах. Также изучили поведение системы на реальных нештатных ситуациях — при пропадании канала между дата-центрами и при деградации связи по одному из направлений аплинка.
Взаимодействие подсистем в штатном режиме
В штатном режиме существует три вида процессов, в которых участвуют все слои платформы:
- создание и удаление пользовательских аккаунтов
- создание и удаление сайтов
- обслуживание запросов к сайтам
В этих процессах можно выделить отдельные операции для подсистем:
- Создание аккаунта
- Бэкенд
- Создание пользовательского веб-контейнера с выделенными ресурсами и изоляцией от других контейнеров
- Формирование веб-окружения по выбранному пресету (например, LAMP)
- Бэкенд
- Добавление сайта
- Бэкенд
- Создание окружения сайта в пользовательском веб-контейнере
- Генерация DNS-зоны с записями для гео-акселерации
- Регистрация веб-контейнера сайта (discovery) в бэкенде
- Фронтенды
- Назначение фронтендов, которые будут обслуживать данный сайт
- Размещение DNS-зоны домена
- Привязывание на фронтенде домена к мастеру и бэкапу кластера
- Бэкенд
- Запрос к сайту
- Фронтенды
- Отдача посетителю контента с наиболее близкого к нему фронтенда
- Определение режима работы бэкенда и направление запроса к мастеру или бэкапу в зависимости от их доступности
- Бэкенд
- Направление запроса к сайту в веб-контейнер пользователя
- Фронтенды
Перед публичным тестированием мы проводили внутренее тестирование, во время которого большинство недочетов уже было устранено. Но участники бета-тестирования помогли нам обнаружить еще два бага: один у нас, другой — у некоторых доменных регистраторов.
У нас баг проявлялся при привязывании домена к фронтендам, когда при гонке условий операция отмечалась как выполненная, хотя домен еще не был привязан. На работе уже привязанных доменов эта ошибка не сказывалась и возникала достаточно редко — только при подключении сайта. Благодаря пользователям, которые в первые дни тестирования разместили по несколько десятков доменов, эту ошибку удалось быстро обнаружить и устранить. Других ошибок в работе платформы не нашлось.
Баг у регистраторов возникает в процессе делегирования домена на новые серверы, при верификации зоны и DNS-серверов. В нашей схеме для повышения надежности каждый DNS-сервер имел несколько A-записей. Одни регистраторы при верификации делегирования корректно обрабатывали такую схему именования и завершали делегирование без ошибок. Другие регистраторы отказывались делегировать домен, заявляя о неправильной конфигурации. Вероятно, они при проверке берут только первую из нескольких A-записей и, если она окажется одинаковой для всех серверов, считают это ошибкой. Хотя этот баг в проверке DNS-серверов регистратором, но чтобы упростить жизнь клиентам таких регистраторов, нам пришлось использовать старую схему именования серверов — с единственной A-записью.
Реакция на различные типы аварий
Мы испытывали реакцию платформы на следующие типы аварий:
- Обесточивание основного сервера
- Сбой во внутренней маршрутизации дата-центра основного сервера
- Частичные сбои в маршрутизации аплинка
- Сбои на канале связи между мастером и бэкапом кластера
- Выход из строя резервного сервера
- Выход из строя одного из фронтендов
От платформы в этом случае требуется определить, действительно ли возникла проблема, требуется ли на нее какая-то реакция, и, если проблема существует, изменить топологию для устранения проблемы. При аварии мастера кластера требуется не только миграция бэкенда на резервный сервер, но и реконфигурация фронтендов для перенаправления запросов на новый бэкенд.
Все указанные ситуации были отработаны корректно, восстановление работы выполнялось в регламентное время — до полутора минут в самых сложных случаях. Для интернет-сервисов, собранных на мастер-бэкап кластере без фронтендов, даже при оптимально выбранном решении по организации работы DNS и IP-маршрутизации, выход мастера из строя может привести хоть и не к полному прекращению обслуживания, но к ощутимой деградации качества работы длительностью около часа. Добавление слоя фронтендов в платформе Jet9, кроме прочего, уменьшило время деградации сервиса при авариях до нескольких минут.
Усовершенствование среды веб-хостинга
Одновременно с бета-тестированием платформы Jet9, мы усовершенствовали используемые в ней пользовательские веб-контейнеры. Кроме гарантированных ресурсов и изоляции нагрузки между пользователями, мы реализовали возможность полностью управлять используемым в контейнере программным обеспечением:
- Использовать собственные httpd и mysqld
- Выбирать произвольные версии программ (поддерживаемые и обновляемые нами)
- PHP 5.2, 5.3, 5.4, 5.6, 7RC2
- MySQl5.6, MariaDB 10.0, Percona 5.6
- PostgreSQL 8.4, 9.4
- Настраивать Apache на уровне httpd.conf
- включение и выключение модулей
- тюнинг числа httpd-процессов, fcgi-процессов
- Включать, выключать или настраивать модули PHP
- Настраивать конфигурацию MySQL-сервера
Кроме всего прочего, это позволило нам оптимизировать на максимальную производительность веб-окружение для требовательных к ресурсам CMS на PHP.
Ввод сервиса в рабочий режим
Публичное бета-тестирование подтвердило корректность работы платформы Jet9 и обнаружило несколько недочетов. Огромное спасибо участникам тестирования за помощь! После усовершенствования работы веб-контейнеров и устранения выявленных недочетов, веб-хостинг Jet9 c 7 сентября введен в рабочую эксплуатацию и теперь мы принимаем заказы.
Кроме хостинга на отказоустойчивом кластере, мы добавили также тарифы хостинга обычного уровня надежности (Стандартный Сервер). Они тоже работают на оптимизированных и администрируемых нами веб-контейнерах с гарантированными ресурсами и масштабированием, и интегрированы с сетью географической оптимизации и веб-акселераторов. Но за счет более простой конфигурации и отсутствия двойного горячего резервирования оборудования, ее стоимость получается намного меньше и соответствует средним по рынку ценам на VPS или выделенные серверы аналогичной мощности.
Еще раз выражаем благодарность всем участникам тестирования и напоминаем, что для получения скидок за участие в тестировании достаточно указать в комментариях к оформленному заказу логин, использованный во время тестирования, или выслать эту информацию письмом в поддержку.