Е. Б. ВЕСНА, Д. Ю. ОКУНЕВ
Национальный исследовательский ядерный университет «МИФИ»
ОПЫТ ВНЕДРЕНИЯ ОТКАЗОУСТОЙЧИВОГО
WEB-КЛАСТЕРА ДЛЯ ПОРТАЛА ПРИЁМНОЙ КОМИССИИ НИЯУ МИФИ
Использование отказоустойчивых кластеров позволяет избежать продолжительного времени в отказе обслуживания при различных аварийных ситуациях. Подобные технологии могут быть востребованными для критически важных сервисов.
Были изучены различные варианты реализации отказоустойчивости для web-ресурса в рамках требований по проекту. Одним из требований по проекту была обязательная сертификация Федеральной Службы по Техническому и Экспортному Контролю (ФСТЭК), что ограничивало список разрешённого программного обеспечения (ПО). В результате многие механизмы для обеспечения отказоустойчивости были реализованы с нуля.
По системной части по проекту «Приёмная комиссия» требовалось выполнить несколько этапов:
ñРеализовать web-платформу для сайта
ñРеализовать отказоустойчивость
ñРеализовать балансировку нагрузки и провести оптимизацию работы web-кластера
ñРеализовать необходимые меры безопасности
Реализация простейшей web-платформы является хорошо изученной проблемой, и на ней не будем заострять внимание.
Отказоустойчивость кластера реализована на базе избыточности сервера. Для реализации отказоустойчивости кластера необходимо реплицировать 3 вида данных:
ñФайлы
ñБазы данных (БД)
ñАктивные сессии PHP
Для репликации файловых данных использовалось одновременно два механизма. Для репликации конфигурационных файлов использовалась комбинация inotify и rsync, а для файлов сайта OCFS2 over DRBD. Основным преимуществом механизма inotify+rsync является безотказная доступность файлов, что необходимо для конфигурационных файлов, чтобы система сохраняла свою работоспособность. Данный механизм был выбран как наиболее быстросрабатывающий механизм репликации без риска недоступности файлов. С другой стороны OCFS2 over DRBD гарантирует мгновенную синхронность и лучше подходит для синхронизации файлов сайта. Данная система была выбрана как самая надёжная и производительная система среди поставляемых в стандартном репозитории сертифицированной ФСТЭК операционной системы (ОС).
В ходе продолжения разработки сайта выяснилось, что процедура «svn cleanup» выполняется недопустимо долго на данном OCFS2-разделе, если имеется достаточно большое количество директорий. Для решения этой проблемы была оптимизирована работа реплицируемого раздела, а также написан механизм, альтернативный «svn cleanup»
Далее, для репликации БД с учётом ограничений на разрешённое ПО, использовался обычный механизм MySQL-репликации master-slave. Схема master-master не использовалась в связи с потенциальными проблемами из-за пересечений id и прочих причин рассинхронизации. Для отказоустойчивой работы в режиме master-slave был реализован набор скриптов, обрабатывающий всевозможные события (прерывание связности между узлами, отключение электропитания и т. п.).
Для репликации активных сессий использовался memcached с резервным backend в MySQL. В предлагаемой версии memcached в стандартном репозитории сертифицированной ФСТЭК ОС плохо обрабатывались события, когда терялась связность с другим узлом, в результате чего данные о сессиях были продублированы в MySQL-таблицу.
После того, как была запущена репликация, было необходимо настроить автоматическую «подмену» сервера в случае его недоступности, что и было реализовано на базе протокола VRRP.
Далее было необходимо реализовать балансировку нагрузки и провести необходимую оптимизацию web-кластера. Для балансировки нагрузки использовалась система на базе DNS-rr. Для оптимизации web-кластера проводилось нагрузочное тестирование и профилирование работы всей системы. Наиболее слабым местом оказались дисковые операции, поэтому большинство оптимизаций были ориентированы на их сокращение. Были изучены различные возможности ускорения работы реплицируемой файловой системы, но достаточно эффективного решения не было найдено. Опробованы различные механизмы кеширования файловых операций, добавлен кеширующий frontend для web-сервиса. Последним этапом было необходимо обезопасить данный web-кластер.
Для этого:
ñВсё сообщение (кроме ssh) между узлами кластера производилось поверх ipsec.
ñFirewall был настроен по принципу whitelist.
ñПроведены очевидные правки конфигурационных файлов по ужесточению доступа, например, в sshd_config были прописаны конкретные группы, которым можно использовать ssh, а специальным пользователям (которые авторизуются только по ключам) была запрещена авторизация по паролю.
ñВсе приложения были поделены на группы, для каждой из которых было создано своё chroot-окружение.
ñРазработчикам был дан доступ только к chroot-окружению, в котором работает web-сервис
Внедрение отказоустойчивого web-кластера для портала Приёмной комиссии было осуществлено во время приёмной компании в НИЯУ МИФИ в июне-августе 2011-го года.
