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

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

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

Что такое Jet9

Мы назвали сервис «Отказоустойчивый хостинг сайтов с географической оптимизацией». Не смотря на многословность, это отражает меньшую часть возможностей, но самую заметную.

Основные функции Jet9: повышенная отказоустойчивость, интегрированная CDN/ADN, гарантированное выделение ресурсов в широком диапазоне. Все это в одном готовом решении, без необходимости заказчику самостоятельно организовывать взаимодействие большого стека компонентов и менять архитектуру сайта. В результате это обеспечивает стабильную быструю работу сайта с минимумом простоев или деградации работы. Решение ориентировано на веб-проекты, у которых такие требования уже возникли, но реализовать и поддерживать их самостоятельно слишком сложно или слишком дорого.

Частная инсталляция платформы (Private Jet9) предназначена для проектов малого и среднего масштаба, которым для работы требуется от нескольких серверов до нескольких сотен. Веб-хостинг (PaaS Jet9) предоставляет как минимальные тарифы для небольших сайтов с невысокой посещаемостью, так и большие тарифы, составляющие практически все ресурсы мощного сервера, для ресурсоемких сайтов с высокой нагрузкой — до нескольких сотен запросов в секунду и сотни тысяч пользователей в сутки.

В качестве аппаратного обеспечения для веб-хостинга Jet9 используются стандартные серверы TrueVirtual V8 и TrueVirtual T4 с сетевым хранилищем и локальным SSD-кэшем.

При разработке использованы несколько ноу-хау и patent pending изобретений, но основной труд заключается в большом объеме исследований, кропотливой инженерной работе по соединению множества компонентов и их доработке, программировании недостающих узлов, а также в долгом тестировании поведения в различных комбинациях условий, документированию всего на всех этапах и составлении регламентов на штатные и аварийные процедуры.

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

Веб-окружение

Панели управления и веб-стеки

В качестве пользовательского интерфейса можно использовать панели управления, предназначенные для shared веб-хостинга. Сейчас используется панель управления ISPManager 5. Для автоматизированного деплоя доступны SSH, SFTP, FTPS.

Веб-окружение в настоящий момент соответствует общепринятому LAMP набору: Linux, Apache, Mysql, PHP. Кроме обычных CGI, можно запускать FastCGI-приложения (perl, python). То есть все, что доступно на обычном веб-хостинге. В Private Jet9 есть возможность использовать серверы приложений Unicorn, Thin и Puma для Ruby on Rails, Tomcat и Jetty для Java/JavaEE, WSGI-приложения на Python, базы PostgreSQL, MongoDB, CouchDB. Но в веб-хостинге на текущем этапе тестирования эти стеки недоступны, только LAMP.

Учет ресурсов и изоляция нагрузки

Когда-то давно мы делали учет ресурсов и изоляцию клиентов хостинга на FreeBSD 4.1. Приходилось добавлять множество патчей и в ядро, и в apache, и в некоторые системные утилиты. Про это можно было бы много написать. А сейчас получается коротко: cgroup на разные классы памяти, на процессор, на дисковые операции; rlimit на процессы и открытые файлы. Каждый пользователь имеет собственный экземпляр apache, что упрощает организацию привелегий пользователей для работы веб-сервера и скриптов, и упрощает контроль расхода ресурсов.

Доделки ядра требуются только для более гибкого контроля прав доступа и дополнительной изоляции пользователей, и используются только для веб-хостинга Jet9.

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

Резервные копии

Резервные копии сохраняются в независимую систему долговременного архивного хранения, расположенную в третьем географически удаленном дата-центре. Инкрементальное копирование выполняется каждые сутки. Используются копии файловой системы через rsync. Снэпшоты блочного устройства не используются из-за того, что при повреждениях мета-данных файловой системы, окажутся поврежденными и реплика в кластере, и резервная копия.

Ротация архивов делается по мультицикловой схеме, которая обеспечивает прореживание старых копий таким образом, чтобы сохранялись в меньшем числе старые копии, и в большем числе новые копии. То есть при хранении семи архивов, в нем будет копии примерно следующих возрастов: 1 год, 6 месяцев, 3 месяца, 1 месяц, 6 дней, 2 дня, 1 день.

Отказоустойчивый кластер

Каждый веб-бэкенд работает поверх HA кластера с реплицируемым хранилищем. В двух независимых дата-центрах имеются две стороны кластера — мастер и бэкап. В один момент времени работать может только одна из сторон — либо мастер, либо бэкап. В качестве политики работы сторон кластера для веб-хостинга принят запрет на split brain — ситуацию, когда работают одновременно и мастер, и бэкап. Эта политика является следствием принятого требования обеспечить последовательную консистентность. Для частных инсталляций могут использоваться и другие политики, разрешающие split brain, для того, чтобы обеспечить максимальную доступность сервиса даже ценой рассогласованности данных.

На каждой стороне кластера находится собственное хранилище, с которым ведется вся работа, и изменения которого реплицируются в реальном времени в другой дата-центр, в другую availability zone — с мастера на бэкап. Для нас это более удобный вариант, чем альтернатива — общее хранилище, распределенное в обоих дата-центрах. Организация кластера на реплицируемом хранилище, в целом, намного сложнее, чем на общем хранилище, но при этом дает существенное преимущество — ниже требования к латентности связи между дата-центрами, существенно ниже требования к полосе, и как следствие, возможность построения более производительных систем. Сейчас у нас используется три дата-центра, два из которых имеют прямое соединение, и оба связаны с третьим через интернет. Используются HA кластеры и на парах мастер-бэкап, связанных через прямое соединение, и на парах, связанных через интернет.

Когда мы начинали использовать pacemaker для внутренних служб, для него использовался heartbeat и мы самостоятельно вводили дополнительные механизмы арбитража для защиты от сплитбрейна. В Jet9 мы перешли на pacemaker и corosync с кворумом. Pacemaker — хороший мощный продукт, но у него, имеется множество неудобств и особенностей, которые усложняют его использование с большим числом кластеров и на ненадежных или сложных сетях. Поэтому у нас был разработан собственный контроллер кластеров, лучше подготовленный для решения наших задач. Сейчас он еще слишком мало обкатан и для продакшен мы продолжаем использовать pacemaker.

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

В веб-хостинге Jet9 локальное хранилище использует быстрый SSD + bcache с writeback для кэширования.

Географическая оптимизация

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

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

Дополнительное преимущество перед зарубежными сервисами — нормальное покрытие в России. То есть ближайшее к Тюмени зеркало находится не в Голландии, а в Екатеринбурге. Для тестовой инсталляции Jet9 используется небольшая сеть — Великобритания, Москва, Санкт-Петербург и Новосибирск. В продакшене к ним добавляются Ростов-на-Дону, Самара, Екатеринбург, Голландия. Пока плохо поддается вопрос с Дальним Востоком — большой дисбаланс в стоимости связи и населенности, экономически не оправдано, но мы будем продолжать.

Для географической балансировки используется гибридная схема — DNS anycast плюс расчет скорости и дистанций на DNS-серверах. В качестве reverse proxy используется Squid и, дополнительно для SSL, Nginx.

Тестирование

Основная задача данного тестирования для нас — найти проблемы в работе API для управления доменами на фронтендах и бэкендах, в интеграции ISPManager с нашим веб-окружением на бэкендах, и в интеграции ISPManager с веб-акселераторами и гео-балансировкой на фронтендах. Планируемый срок тестирования: 1 — 2 месяца.

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

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

Участникам тестирования будет предоставлена дополнительная скидка 10% в течение 2 лет на все продукты Jet9 — и на веб-хостинг, и на лицензии для частных инсталляций.

Чтобы присоединиться к тестированию достаточно зарегистрировать заказ на jet9.ru с требуемым объемом ресурсов и своими реквизитами. Отдельно писать про тестирование не нужно, сейчас все заявки автоматом оформляются как тестовые.

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