«ИТ-Град» предоставил Русской православной церкви облачные услуги для проекта Prihod.ru

С 2014 года на базе проекта Prihod.ru по благословению Святейшего Патриарха Московского и всея Руси Кирилла под руководством Синодального информационного отдела реализуется один из самых масштабных интернет-проектов Русской Православной Церкви «Единая карта храмов и монастырей», в котором принимают участие все епархии (основные крупные административные единицы Церкви).

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

Как все начиналось

Миссия Prihod.ru — расширить и повысить качество присутствия Русской Православной Церкви в веб-пространстве. Это огромный комплекс задач, которые условно можно разделить на три группы:

• Разработка и поддержка аппаратно-программной части;
• Обучение далеких от IT пользователей работе в сети Интернет;
• Планирование развития проекта и реализация партнерских программ.

Помимо исключительно «айтишных» задач мы решали и множество других. Например, важным условием была изначальная оптимизация расходов, поскольку проект некоммерческий и ограничен собственными средствами учредителя.Михаил Садиров, SMART technologies: На тестирование мультивендорных решений есть спрос

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

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

Взгляд в облака и первая проба

На тот момент (2011 г.) облачные технологии в России не были достаточно развиты и доступны, поэтому мы переехали в более комфортный по ценам и качеству европейский дата-центр. Там собрали небольшую кластерную структуру из нескольких серверов разной конфигурации в зависимости от решаемых каждой машиной задач. Несколько лет схема успешно работала, да и сейчас остается в рабочем состоянии для сокращения расходов на содержание старой версии проекта. И еще для организации резервного копирования. Технически этого решения какое-то время было достаточно, неудобства возникали лишь при выходе из строя жестких дисков (иногда сразу двух в RAID-10).

Так мы впервые близко подошли к облачным технологиям.

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

• Максимальная гибкость в плане управления ресурсами и инфраструктурой;
• Большой задел по производительности и потенциально полезным возможностям;
• Высокие показатели доступности и надежности;
• Разумное сочетание цены и качества.

Мы не запрашивали конкретные цифры доступности, и нам было непринципиально число «девяток» дата-центра. На выбор влияло разумное сочетание скорости восстановления сервиса после сбоя и стоимости поддержки.

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

К тому времени у нас сформировалась классическая инфраструктура веб-проекта: сервер БД и сервер с сайтом. Производительности Amazon хватало на то, чтобы выделять достаточно ресурсов серверам и не думать о кластерах распределения нагрузки, а надежность площадки обеспечивала высокую доступность. Все это нас устраивало, и от нового хостинга ожидалось примерно то же самое.

Подводные камни переезда

После тщательного отбора большинство российских облаков отпали по разным причинам — чаще всего не хватало мощности под наши запросы или предлагаемые решения работали нестабильно. Оставив двух кандидатов, одним из которых был «ИТ-ГРАД», мы сначала сделали выбор в пользу другого облачного хостинга. Свою роль сыграла кажущаяся тяжеловесность альтернативного решения «ИТ-ГРАД» и ориентация на enterprise. Тогда нам это показалось избыточным.

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

1. «Подъем» новых серверов, перенос данных.
2. Настройка проксирования со старой площадки на новую.
3. Перевод доменных имен на новые адреса (наш проект использует несколько сотен доменных имен, большая часть которых принадлежит клиентам).

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

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

Потеряв изрядно времени и денег, мы вернулись к решению «ИТ-ГРАД». Сбор всех этих «граблей» по крайней мере выявил наиболее критичные места проекта. В общем, мы уже знали, на что следует смотреть, и быстро прогнали необходимые тесты:

• Скорость канала между «ИТ-ГРАД» и «Амазоном» измеряли с помощью iperf;
• Скорость доступа со всего мира — загрузкой большого файла с разных площадок и ping-admin;
• Скорость чтения/записи — time dd и time cat;
• Скорость процессорных ядер и общее быстродействие — перетащили сайт на аналогичную амазоновской конфигурацию и смотрели average/iowaits, время отклика в Zabbix на одном из своих хостингов; графики быстродействия — в ping-admin.

Приятно удивило явное преимущество «ИТ-ГРАД» в несколько раз по сравнению с тем же Amazon. Скорость дискового ввода-вывода, производительность процессорных ядер, скорость сети — все было выше. В итоге сумма поддержки виртуальной инфраструктуры оказалась ниже расчетной (и много ниже амазоновской).

Подведем итоги

Тяжеловесность окружения «ИТ-ГРАД», о которой мы упоминали, оказалась несколько преувеличенной: для надежной работы нагруженной системы приходится использовать довольно сложные системы виртуализации и непростое оборудование. Со временем их применение себя оправдывает, так как простейшие проблемы (вроде выхода из строя пары модулей памяти или дисков) никак не сказываются на работе сервиса. Увы, мы поняли это не сразу — сначала пришлось позаниматься буйной перепиской с технической поддержкой нашего прошлого хостера.

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

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

И не забывайте про «береженого Бог бережет»: делайте своевременные бэкапы и планируйте заранее варианты восстановления. С таким подходом не прогадаете, а скорость и количественные показатели при выборе можно банально измерить.