Два месяца назад мы начали публичное бета-тестирование веб-хостинга на платформе 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 или выделенные серверы аналогичной мощности.

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