Отказоустойчивость 99,999% своими руками

Доклад технического директора Айри.рф, Николая Мациевского, с профильной конференции FailoverConf.



Стоит начать с пояснений: что такое доступность 99,999%. Это сбои на сайте общей продолжительностью 1/100000 времени. В течение года это простой не более 5,2 минут. Если брать доступность 99,99% — это простой не более 4,4 минут в месяц. К сбоям и простоям сайта может относиться и слишком долгое время ответа (из-за нагрузки, отказа оборудования или программных ошибок).

Как на практике сейчас реализуется доступность сайта, что вы можете получить от хостинг-провайдеров? Для виртуального хостинга, самого дешевого, ситуация плачевна: редкие варианты обеспечивают доступность хотя бы 99,9%. В большинстве случаев сайт может «лежать» днями, и не всегда проблема только на стороне хостинг-провайдера. Прежде чем использовать виртуальных хостингом, еще раз подумайте: стоят ли сэкономленные 500 или 1000 рублей в месяц той головной боли, которую вы от него получите? К единственному плюсу виртуального хостинга (кроме цены) можно отнести отсутствие (невозможность) администрирования и настройки веб-сервера: вы получаете все окружение «из коробки».

Хорошими «рабочими лошадками» являются виртуальные серверы. Если у вас есть ресурсы на администрирование, нет большой нагрузки на диски вместе с большими объемами данных (виртуальный SSD сервер с большими дисками стоит иногда дороже собственного сервера), то это — ваш вариант. По доступности виртуальные хостинги уверенно держат планку 99,9%, иногда спускаясь до 99,5%. При этом при отказе со стороны хостинг-провайдера время простоя обычно измеряется часами, а не днями.

Оптимальным вариантом с точки зрения цена/качество будут выделенные (или собственные) серверы (по экономике собственные серверы всегда дешевле, но необходим бюджет на их закупку). Здесь при правильном выборе хостинг-провайдера возможна доступность 99,99% (простой не более 52 минут в год). К плюсам также стоит отнести полный контроль над аппаратными ресурсами, но минусом будет компетенция системного администратора в вашей команде. Но ни один из известных мне хостинг-провайдеров в России не дает SLA более 99% по размещению оборудования или выделенным серверам.

Следующим уровнем обеспечения доступности будут облака: в них уже заложена отказоустойчивость (которая транслируется почти пропорционально в цену). Они могут обеспечить SLA по доступности 99,9%, но по факту отгружают 99,99%. С точки зрения доступности облако не сильно лучше хорошего хостинг-провайдера: единственное отличие, что в случае отказа оборудования в облаке простой будет меньше (но как сократить простой сайта без использования облака, мы поговорим дальше).

Какие бывают сбои сайта?

Давайте, кратко пробежимся по основным причинам отказа сайта:

  • Сбои могут быть на стороне баз данных: исчерпание диска, поломка таблиц, потеря связи с сервером баз данных.
  • Часто сайты «лежат» (полностью или частично) из-за ошибок в конфигурации веб-серверов (нет прав на чтение, некорректная обработка запросов, недостаточный пул обработчиков и др.).
  • Еще чаще сайты отказывают в обслуживании из-за ошибки веб-приложения: некорректная обработка входных параметров, исчерпание ресурсов, логическая ошибка.
  • Не менее распространенная, но более сложная проблема: большая нагрузка. Даже идеально настроенный сайт на работающем оборудовании без программных сбоев может «сложиться» под большим потоком запросов (или DDoS-атакой).
  • И, наконец, лидер хит-парада — сбой оборудования. Когда «умерли» диски, или память, или материнская плата, или блок питания. Полный алес.

Что со всем этим делать?

Парадигма высокой доступности

Здоров не тот, кто не болеет, а тот, кто быстро лечится. Если перефразировать доктора Хауса «Everybody lies» — «Всё ложится». Вы не можете быть уверены ни в чем: каждый компонент вашей системы (сайта) может отказать по целому ряду причин. Для обеспечения высокой доступности вам помогут три основных правила:

  1. То, что упало, нужно очень быстро поднимать. Точек отказа, на самом деле, не так много: это оборудование, это код сайта, это база данных, это сетевой канал. Вы должны уметь заменить (починить) каждый из компонентов в кратчайшие сроки. Это обеспечит минимальное время простоя.
  2. Не должно быть единой точки отказа. Если что-то может отказать, то рано или поздно оно откажет (причем, по закону Паркинсона, откажет в самый неподходящий момент). Если изначально вы заложите двух-трехкратное дублирование каждого компонента в системе, то случится магия — ваши сайты будут работать «всегда».
  3. Тестирование и самодиагностика являются прикладными инструментами обеспечения высокой доступности. Перед выкладкой новой версии на рабочее окружение необходимо тщательное тестирование, каждый узел системы должен постоянно мониториться на предмет проблем: изнутри и(ли) снаружи. Чем больше вы отсечете ошибок на своей стороне, до касания с пользователями, тем надежнее будет система снаружи, во внешнем мире. При этом вам может казаться, что у вас «все ломается». Это заблуждение: тестирование и исправление (или очень быстрый откат изменений) — это единственный вариант обеспечения здоровья вашего сайта.

Прикладные решения

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

Про синхронизацию (репликацию) базы данных (мастер-мастер), я надеюсь, уже сказано достаточно много, не буду на ней останавливаться. Для синхронизации файлов отлично подойдет Dropbox (для небольших проектов) или любая утилита на основе rsync (bsync, csync, lsync). Важно настроить двустороннюю синхронизацию или обрабатывать рассинхронизацию файлов при сбое основного узла (и переключении на резервный). Для синхронизации конфигураций можно использовать Salt, для синхронизации приложений отлично подойдет ваш системный менеджер пакетов (для CentOS это yum).

Важный момент: при обеспечении синхронизации отдельным блоком идет синхронизация кэшей сайта. Самым лучшим вариантом будет такая архитектура, которая будет стабильно работать в отсутствии кэшей («холодный» старт), тогда отдельно синхронизировать кэши не нужно. Если синхронизация кэшей все же требуется, то на нее нужно будет собрать отдельное внимание (из-за большой плотности события записи/удаления).

Выделенный тестовый узел, где у вас все будет регулярно ломаться (и, желательно, ломаться максимально часто — чтобы обеспечить 100% доступность основного сайта) должен быть идентичным основному узлу (сайту). Те же файлы в синхронизации, та же конфигурация, максимально актуальные данные в базе (без обратной репликации), почти те же ресурсные емкости (чтобы тестировать и на нагрузку в том числе). Чем тщательнее вы подойдете к процессу тестирования и обновления сайта через тестовый узел (а не поиск ошибок на рабочем сайте), тем большую доступность сможете обеспечить. Уже с уровня выделенного сервера человеческие ошибки вносят решающую роль в работоспособность сайта. По уровню ошибок можно ориентироваться на Amazon, где сбой происходит 1 раз на 100 000 выкладок (0,001%).

Балансировка нагрузки или в случае сбоя надежнее (для устранения единой точки отказа) выполнять на уровне DNS (самое бюджетное решение). Настройка триггеров, которые после нескольких верификаций недоступности сайта (из нескольких географических точек в течение нескольких последовательных проверок — например, 2 проверки с интервалом в минуту или 3 проверки с интервалом в 30 секунд) смогут переключать публичный IP адрес сайта на резервный узел, на практике, сможет обеспечить простой не более 15 минут для большинства (80-90%) пользователей. Время жизни DNS (TTL) при этом — 3 минуты. Это будет работать не для всех пользователей (не все кэширующие DNS-серверы корректно учитывают минимальный TTL), но гарантирует высокую доступность «почти для всех».

Для дальнейшего уменьшения времени простоя рабочим решением будет только IP Anycast и протоколы BGP/BFD, они позволяют настроить переключение между основным и резервными узлами (балансировщиками) в течение 30-60 секунд «почти для всех» пользователей.

Выбирая хостинг провайдера, нужно ориентироваться на его фактическую доступность. Возможно построить отказоустойчивый сайт на базе ненадежного хостинга, но это займет очень много времени (и количество простоев может быть значительным). По результатам тестирования Айри.рф лишь два провайдера в России могут обеспечить доступность 99,99% по итогам года при аренде или размещении оборудования — это Selectel и Digital Networks.

Важной составляющей построения отказоустойчивого сайта будет решение по самодиагностике/самолечению узла. Можно начать с триггеров на известные форсмажоры — например, отказ базы, падение канала подключения, исчерпания ресурсов — и по мере появления новых ситуаций настраивать отработку в автоматическом режиме. Чем меньше вы оставите места для «человеческого» фактора, тем надежнее будет система. Для углубления в эту тему, рекомендую ознакомиться со статьями на тему Autonomic Computing.

И в конце — самое «вкусное». Сколько на практике будет стоить вам высокая доступность вашего сайта? Во-первых, стоимость оборудование нужно будет удвоить (или утроить — если вы сделаете «честный» тестовый узел, а не разместите его на резервном, или у вас каждый сайт будет иметь отдельный тестовый узел, а не использовать общие мощности всех сайтов). Также нужно будет больше времени на тестирование как сайта до публикации, так и сайта во время работы — примерно в два раза. И больше усилия на обучение / повышение компетенции сотрудников, примерно на 10-20%. Дополнительно, если 15 минут простоя — это слишком много, то придется озадачиться собственный автономной системой (AS) и блоком IP адресов, чтобы полноценно использовать протоколы BGP/BFD. Ориентировочно, это будет стоить как 1-2 дополнительных сервера.

Реорганизация процесса разработки / обслуживания сайта позволит поднять его доступность на порядок (до 99,99%) даже в случае использования DNS-балансировки при отказах. Если требуется «5 девяток», то потребуется собственная AS (или аренда IP Failover — для исключения единой точки отказа на уровне IP адреса — например, Айри.рф).