Бывает, сайты падают из-за отказа площадки хостера, каналов и так далее. Я 7 лет работаю в , и часто вижу такие проблемы.
Пару лет назад я понял, что услуга резервной площадки (без доработки их сайта или сервиса) очень важна клиентам. Теоретически тут всё просто:
1. Иметь копию всех данных в другом дата-центре.
2. При сбое переключать работу на резервный ДЦ.
На практике система пережила 2 полные технические реорганизации (сохранение основных идей со сменой значительной части инструментария), 3 переезда на новое оборудование, 1 переезд между поставщиками услуг (переезд из немецкого дата-центра в два российских). На исследование поведения разных систем в реальных условиях под клиентской нагрузкой ушло 2 года.
Итак, даже если применяет кластерное решение для размещения клиентских — подавляющее большинство существующих кластерных решений рассчитаны на работу в пределах одного ЦОД, либо внутри одной сложной системы поломка которой ведет к остановке всего кластера.
Основное
1. Репликация — с локальных дисков через drbd БЕЗ drbd-proxy
2. Переключение между дата-центрами через анонсирование собственной сети IP-адресов, без их смены для доменов
3. Отдельная резервная копия (обычная копия, не реплика) + мониторинг в третьем дата-центре
4. Виртуализация на основе гипервизова (в данном случае — KVM)
5. Внутренняя сеть L3 с динамической маршрутизацией, IPSEC mGRE OSPF
6. Организация из простых составных компонентов, каждый из которых можно временно отключить или заменить.
7. Принцип отсутствия «самой надежной системы»
8. Неустранимая точка отказа
Ниже будет описана причина именно таких решений
Требования к системе
1. Запуск клиентского сервиса без доработок (т.е. запуск проектов, не рассчитанных на кластеризацию)
2. Возможность продолжать работу после единичного сбоя оборудования вплоть до отключения одного любого дата-центра.
3. Восстановление работы сервисов клиента в течение 15 минут после фатального сбоя, допускается потеря данных за 1 минуту до сбоя.
4. Возможность восстановления данных при потере любых двух дата-центров.
5. Обслуживание/замена собственного оборудования и поставщиков услуг без простоя сервисов клиента.
Хранение данных
Оптимальным выбран вариант работы DRBD без proxy, сжатие трафика идет одновременно с шифрованием средствами ipsec. В режиме синхронизации B и локальном кешировании данных внутри виртуальных машин задержки в 10-12 мс (пинг между дата-центрами Москва — Санкт-Петербург) никак на скорости работы не сказываются, к тому же это задержка только на запись, чтение происход с локального диска быстро.
Исследовались 4 варианта:
1, 2. Ceph в вариантах rbd (блочные устройства) и CephFS (распределенная файловая система)
3. XtremeFS
4. DRBD
5. DRBD with DRBD-Proxy
Общее для Ceph
Достоинства:
Удобное масштабирование пропускной способности. Простое добавление емкости, автоматическое распределение/перераспределение данных по серверам.
Недостатки:
Работает в пределах одного ЦОД, при двух далёких ЦОД надо два кластера и репликация между ними. Плохо работает на небольшом количестве дисков (проверки целостности данных подвешивают текущие дисковые операции). Только синхронная репликация.
Диагностика развалившегося кластера — занятие сложное. Нужно или очень долго ломать и чинить эту систему или иметь контракт на быструю поддержку с разработчиками.
При обновлении кластера есть критический момент — перезапуск среднего в кворуме монитора. Если в этот момент что-то пойдет не так — кластер остановится и потом его нужно будет собирать вручную.
Ceph FS
Предполагалось использовать как единую файловую систему для хранения всех данных LXC/OpenVZ-контейнеров.
Достоинства:
Возможность создания моментальных снимков файловой системы. Размер файловой системы и отдельных файлов может быть больше размера локального диска. Все данные одновременно доступны на всех физических серверах.
Недостатки:
На каждую операцию открытия файла сервер должен обратиться к серверу метаданных, проверить существует ли файл, где его искать и т.п. Кеширования метаданных не предусмотрено. Сайты начинают работать медленнее и это заметно глазами. Локальное кеширование не реализовано.
Разработчики предупреждают, что система еще не готова и важные данные в ней лучше не хранить.
Ceph RDB
Предполагаемое использование — по одному блочному устройству на контейнер.
Достоинства:
Удобное создание моментальных снимков, клонирования образов (в формате второй версии). Размер образа может быть больше размера локального диска. Локальные операции кешируются средствами операционной системы хоста/контейнера. Нет задержек на часто повторяющиеся чтения мелких файлов.
XtremeFS
Достоинства:
Заявлена поддержка репликации на больших расстояниях, в т.ч. работа в offline, умеет поддерживать частичные реплики.
Недостатки:
При тестах показала себя очень медленной и дальше не исследовалась. По ощущениям презназначена для распределенного хранения массива данных/документов/дисктрибутивов чтобы например в каждом офисе была своя копия и не предназначена для активно изменяющихся файлов — таких как базы данных или образы виртуальных серверов.
DRBD
Достоинства:
Репликация блочных устройств. Чтение с локальных дисков. Возможность работать автономно, без кластера. Естественное хранение данных — при проблемах с DRBD можно подключиться к устройству напрямую и работать с ним. Несколько режимов синхронности.
Недостатки:
Каждый образ может синхронизироваться только между двумя серверами (есть возможность репликации на 3-4 сервера, но при переключении мастер-сервера предвидятся сложности с распределением метаданных между серверами + кратно снижается пропускная способность).
Размер устройства не может превышать размер локального диска.
DRBD with DRBD-Proxy
Специальная платная добавка к DRBD для репликации на большие расстояния
Достоинства:
1. Хорошо сжимает трафик, в 2-10 раз относительно работы без сжатия.
2. Большой локальный буфер для принятия операций записи и их постепенной отправки на удаленный сервер без торможения операций на основном (в режиме асинхронной репликации).
3. Вменяемая, поддержка, вполне быстрые ответы в некоторое время (видимо если в рабочие часы попасть)
Недостатки:
Сразу при запуске наткнулся на баг, который уже исправлен но исправление еще не опубликовано — прислали отдельно собранный бинарник с исправлением.
В тестах проявил себя крайне нестабильно — простейший тест случайной записью с большой скоростью вешал прокси-сервис так, что приходилось перезагружать весь сервер, а не только прокси.
Время от времени уходит в spinlock и тупо жрёт всё процессорное ядро
Переключение трафика между дата-центрами
Рассматривалось два варианта:
1. Переключение через изменение записей на DNS-серверах
2. Путем анонса собственной сети IP-адресов из двух дата-центров
Оптимальным выбран анонс своей сети через BGP.
Изменение записей на DNS-серверах
Достоинства:
Простота реализации
По пингу можно понять в какой дата-центр приходит трафик
Недостатки:
Часть клиентов не готова делегировать свои домены на чужие DNS-сервера.
Долгое время переключения — кеширование DNS часто осуществляется более агрессивно, чем указано в TTL и даже при TTL в 5-15 минут через час всё еще кто-то будет ломиться на прежний сервер. А отдельные сканеры — даже через несколько дней.
Невозможно сохранение IP-адреса клиентских серверов при переезде между дата-центрами.
При полупотере связи с дата-центром dns-сервера могут начать отдавать разные ip-адреса и переключение произойдет только частично.
Анонс собственной сети адресов
Достоинства:
Быстрое гарантированное переключение трафика между дата-центрами. При тестах внутри Москвы изменение BGP-анонса расходится за несколько секунд. По миру возможно дольше, но всё равно быстрее и более надёжно, чем .
Есть возможность отключить трафик из полуработающего дата-центра, связь с которым у системы потеряна, но который виден для части сети интернет.
Недостатки:
Усложняется настройка внутренней маршрутизации. Переключение отдельных ресурсов системы возможно только частичное — трафик будет приходить в тот дата-центр который ближе к клиента, а уходить из того дата-центра где запущен виртуальный сервер.
Резервная копия в третьем дата-центре
Вполне реальна ситуация потери данных в двух дата-центрах, например программная ошибка, по которой синхронно удалились данные на основном и резервном сервере. Или сбой оборудования на основном сервере в то время, пока на резервном проводятся работы или ресинхронизация данных.
Для таких случаев в третьем дата-центре поставлен сервер, который исключен из общей системы кластера. Всё что он умеет — вести мониторинг и хранить резервные копии.
Способ виртуализации
Были рассматрены варианты:
LXC, OpenVZ, KVM, Hyper-V
Выбор сделан в пользу KVM, т.к. он предоставляет наибольшую свободу действий.
LXC
Достоинства:
Прост в установке, работает на стандартном ядре Linux без модицикаций. Позволяет выполнять базовую изоляцию контейнеров.
Нет потерь производительности на виртуализацию.
Недостатки:
Слабый уровень изоляции.
Нет живой миграции между серверами
Внутри контейнера возможен запуск только Linux систем. Даже внутри Linux систем есть ограничения по функциональности модулей ядра.
OpenVZ
Достоинства:
Нет потерь производительности на виртуализацию
Есть живая миграция
Недостатки:
Работает на модифицированном ядре, нужно вручную заниматься сборкой дополнительных модулей и, возможно, иметь проблемы совместимости из-за нестандартного для них окружения.
Внутри контейнера работает только Linux. Даже внутри Linux систем есть ограничения по функциональности модулей ядра.
KVM
Достоинства:
Работает без модификации ядра системы
Есть живая миграция
Можно подключать оборудование напрямую к виртуальной машине (диски, usb-устройства и т.п.)
Недостатки:
Потери производительности на аппаратную виртуализацию
Hyper-V
Достоинства:
Хорошая интеграция с Windows
Есть живая миграция
Недостатки:
Не поддерживаются необходимые возможности из ОС Linux: кеширование на SSD, репликация локальных дисков, подключение удаленное подключение к консоли для клиента.
Выбор внутренней сети
Задача — обеспечить внутреннюю сеть, с адресацией, независимой от внешней сети и расположения внутреннего сервера. Необходима возможность быстрого переключения потока трафика к серверу при изменении его физического расположения (переезд ). Возможность произвольной маршрутизации до каждого конкретного сервера (т.е. сервер переезжает без смены IP-адреса). Желательна возможность организации полносвязной сети между дата-центрами. Желательна защита трафика.
Изначально использовался вариант tinc и полносвязная L2 сеть. Это самый простой в настройке и относительно гибкий вариант. Но не всегда предсказуемый. После ряда экспериментов по маршрутизации пришел к выводу что маршрутизация на уровне L3 как раз то, что нужно — предсказуемо, управляемо, быстро. Внутри внутренней сети работает динамическая маршрутизация через OSPF, маршрут прописывается для каждого приватного IP-адреса. Т.е. все маршрутизаторы знают через какой из них есть выход к каждому конкретному серверу.
В случае с L2 сетью таблицы были бы примерно такими же, но менее прозрачными, т.к. спрятаны внутри ПО, а не в стандартных маршрутных таблицах ядра.
При необходимости (в случае проблем с OSPF) при росте количества маршрутов эта система легко заменяется на полностью статическое прописывание маршрутов через собственные службы.
Рассматриваемые варианты:
OpenVPN, L2 tinc, GRE, mGRE
Выбран вариант mGRE. L2 трафик и мультикаст на данный момент не нужны. При необходимости есть возможность добавления мультикаста через ПО на нодах, необходимости в L2 трафике нет. Отсутствие шифрование компенсировалось настройкой IPSEC на трафик между узлами. IPSEC-же по совместительству его еще и сжимать будет.
При настройке в реальных условиях выяснилась интересная особенность — не смотря на полное отключение фильтрации в дата-центре — его оборудование смотрит внутрь GRE-протокола и анализирует что там внутри. При этом удаляются пакеты с OSPF-трафиком и происходит дополнительная задержка в 2мс. Так что IPSEC оказался нужен не только для абстрактного шифрования, но и для работоспособности системы в принципе.
Специалисты дата-центра задали вопрос поставщику оборудования почему происходит такая фильтрация, но ответа пока (вот уже 1-2 месяца) не получили.
OpenVPN
Достоинства
Уже знаком. Хорошо работает. Умеет работать в L2/L3 режимах.
Недостатки:
Работает по связи точка-точка или звезда. Для организации полносвязной сети нужно будет поддерживать большое количество туннелей.
Tinc
Достоинства:
Изначально умеет организовывать полносвязную L2-сеть между произвольным количеством точек. Прост в настройке. Использовал его около 1-2 лет в предыдущей версии системы, до переезда серверов в Россию.
Недостатки:
Неопределенность маршрутизации если возникает ситуация, когда в сети появляются два компьютера с одинаковым MAC (например split-brain в кластере). Задержка в определении смены расположения сервера при переезде около 10-30 секунд.
Гоняет L2 трафик, а на практике нужен L3.
GRE
Достоинства:
Работает в ядре. Просто настраивается. Можно гонять L2-трафик.
Недостатки:
Нет шифрования
Нужно поддерживать большое количество интерфейсов
mGRE
Достоинства:
Работает в ядре. Просто настраивается. Создается mesh-сеть с использование только одного туннельного интерфейса, простое добавление соседей.
Недостатки:
Нет шифрования. Не умеет работать с L2-трафиком, нет мультикаста из коробки.
Использование готовых кластерных решений, принцип отсутствия «самого надежного поставщика/железки/программы»
При эксплуатации надежного дискового хранилища cephfs/cephrbd у меня получалось их сломать так, что для починки требовалось вмешательство разработчиков. В течение нескольких дней я получил нужные консультации через IRC-канал и по ходу диагностики стало понятно что самостоятельно диагностировать и поправить такую проблему почти нереально — нужно глубокое знание устройства системы и большой опыт таких диагностик. Кроме того при поломке такой системы кластер перестает работать в принципе, что недопустимо даже если есть контракт на поддержку. Кроме того контракты на круглосуточную быструю поддержку в любых подобных продуктах очень дорогие и это сразу поставит крест на массовости решения, т.к. не получится продавать дёшево то что купил за дорого.
Аналогично с любым поставщиком надежности, внутренности которого закрыты или не изучены на глубину естественного понимания каждой детали. При построении кластера делалась оглядка на то что каждый компонент системы в аварийной ситуации можно выключить если он перестанет работать как должен и чем-то заменить, хотябы временно, с потерей части функционала но при сохранении работы клиентских сервисов в целом.
DRBD-можно выключить, можно вообще удалить и подключаться к LVM-томам напрямую. Перестанет работать синхронизация между нодами и будет невозможна живая миграция. Для аварийной ситуации, пока будет чиниться поломка в drbd (вероятно метаданные или конфиги или откат версий ПО) это приемлимо. При затягивании проблемы возможна репликация через rsync, снэпшоты LVM, lvmsync и т.п.
KVM — системы никогда не обновляются одновременно. При сбое на одном сервере все клиентские сервисы продолжат работать на резервном пока идут ремонтные работы. Все клиентские сервисы уводятся с ноды перед началом работ.
Третий дата-центр с мониторингом и резервными копиями. При потере резервных копий их временно можно заменить LVM-снэпшотами на основных узлах системы. При потере мониторинга система и все клиентские сервисы будут продожать работать. При этом сломается функция автопочинки сломавшихся ресурсов. На данный момент это допускаемый компромисс. При необходимости эта система тоже может быть задублирована.
Внутренняя VPN-сеть с динамической маршрутизацией. При поломке этой сети возможно перемещение всех ресурсов в один дата-центр и работа без VPN-сети.
Публичная сеть IP-адресов. На данный момент это компромисс и является единой точкой отказа. В случае если по какой-то причине блок адресов перестанет работать (забыли заплатить, закрылась контора которая этот блок выдала, отобрали в связи с оптимизацией адресного пространства). Доступ к клиентским ресурсам будет потерян. Тут делается допуск на то что подобные вещи обычно не происходят неожиданно и будет время на подготовку к потере блока. В случае если блок адресов всё же потеряется неожиданно — есть резервный вариант взять блок адресов у дата-цетров. Работа клиентских ресурсов может быть восстановлена в течение 1-2 дней — в основном это время на согласование и настройку блока адресов дата-центром, работа непосредственно кластера от этого не зависит и нужно будет только обновить DNS-записи доменов.
В дальнейшем эта точка отказа тоже может быть устранена путем получения второго блока адресов через другую компанию.
Дата-центр
На практике в дата-центрах иногда отключают электричество и интернет, несмотря на все системы резервирования. Иногда ломаются самые надёжные железки и падает интернет одновременно в нескольких дата-центрах, которые работали через эту железку, работа дата-центров останавливается гос. органами в ходе следственных мероприятий и т.п. Это то что было испытано на собственном опыте в российских и зарубежных дата-ценрах.
В итоговой версии эти проблемы тоже приняты в расчет: основная система располагается в двух независимых дата-центрах, расположенных в разных субъектах РФ: Москва и Санкт-Петербург. Дата-центры используют независимые друг от друга каналы связи, никак не связаны между собой юридически и не имеют никаких особых согласований/взаимодействий вроде общих маршрутизаторов.
Неустранимая точка отказа
Такая система позволяет оградить конечного клиента от любых одиночных отказов в любых системах и некоторых кратных отказах, кроме существования работы самого поставщика услуги. Этот риск клиенту неизбежно приходится принимать при пользовании чужой инфраструктурой, альтернативой является построение и поддержка собственной аналогичной системы.
Что получилось
1. Клиент приходит и говорит: не хочу падать.
2. Никакая адаптация проекта в большинстве случаев не нужна, но нужно встать на наши сервера. Как правило, нам дают доступ к , мы сами всё делаем силами поддержки.
3. Даем клиенту тестовый адрес для доступа к серверу. Клиент проверяет что всё работает так как он привык, исправляем мелкие неточности. Аппаратная виртуализация позволяет точно скопировать любой проект вместе с существующей операционной системой, программами и настройками, без необходимости повторять настройки на новом сервере и риска что-то забыть на прежнем.
4. Переключаем без перерыва, самая долгая часть – новые IP-адреса. При переносе сайтов получается сделать переезд с перерывом в несколько минут.
5. Заключается договор на , выставляется счет на оплату. Для небольшого типового проекта стоит это 4500 в месяц (это и , и поддержка, и дублирование).
6. Дальше обычно ничего не падает.
Автор: rekby
