Как реализовать почти мгновенное переключение сайта между площадками, когда одна упала

    image

    Бывает, сайты падают из-за отказа площадки хостера, каналов и так далее. Я 7 лет работаю в хостинге, и часто вижу такие проблемы.

    Пару лет назад я понял, что услуга резервной площадки (без доработки их сайта или сервиса) очень важна клиентам. Теоретически тут всё просто:
    1. Иметь копию всех данных в другом дата-центре.
    2. При сбое переключать работу на резервный ДЦ.

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

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

    Основное
    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-анонса расходится за несколько секунд. По миру возможно дольше, но всё равно быстрее и более надёжно, чем VDS.
    Есть возможность отключить трафик из полуработающего дата-центра, связь с которым у системы потеряна, но который виден для части сети интернет.

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

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

    Способ виртуализации
    Были рассматрены варианты:
    LXC, OpenVZ, KVM, Hyper-V

    Выбор сделан в пользу KVM, т.к. он предоставляет наибольшую свободу действий.

    LXC
    Достоинства:
    Прост в установке, работает на стандартном ядре Linux без модицикаций. Позволяет выполнять базовую изоляцию контейнеров.
    Нет потерь производительности на виртуализацию.

    Недостатки:
    Слабый уровень изоляции.
    Нет живой миграции между серверами
    Внутри контейнера возможен запуск только Linux систем. Даже внутри Linux систем есть ограничения по функциональности модулей ядра.

    OpenVZ
    Достоинства:
    Нет потерь производительности на виртуализацию
    Есть живая миграция

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

    KVM
    Достоинства:
    Работает без модификации ядра системы
    Есть живая миграция
    Можно подключать оборудование напрямую к виртуальной машине (диски, usb-устройства и т.п.)

    Недостатки:
    Потери производительности на аппаратную виртуализацию

    Hyper-V
    Достоинства:
    Хорошая интеграция с Windows
    Есть живая миграция

    Недостатки:
    Не поддерживаются необходимые возможности из ОС Linux: кеширование на SSD, репликация локальных дисков, подключение удаленное подключение к консоли VDS для клиента.

    Выбор внутренней сети
    Задача — обеспечить внутреннюю сеть, с адресацией, независимой от внешней сети и расположения внутреннего сервера. Необходима возможность быстрого переключения потока трафика к серверу при изменении его физического расположения (переезд VDS). Возможность произвольной маршрутизации до каждого конкретного сервера (т.е. сервер переезжает без смены 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. Дальше обычно ничего не падает.
    Поделиться публикацией
    Комментарии 45
      +2
      Отлично, просто отлично.

      Чтобы было идеально, надо добавить примеров конфигурации, ну как в вашем посте про GRE в шесть строк.

      А ещё хорошо бы описать не просто одну универсальную систему, а диапазон возможностей, например:

      • HA для самых маленьких — lsyncd и репликация баз данных
      • HA на вырост — DNS, tinc, LXC
      • HA почти как у взрослых дядь — mGRE, KVM и всё-всё-всё.


      Так может целая книжка получиться.
        +1
        С BGP есть более хитрый вариант, если есть /23
        Можно с одной точки анонсировать /23 всю, а с другой — /24, входящую в неё. Тогда в штатной ситуации трафик будет переть туда, где горит /24 (могу ошибаться, давненько с этим не работал уже), а при падении этого маршрута — туда, откуда светится /23. Ну или наоборот.

        Тогда нагрузка будет перещелкиваться автоматом.
          +1
          А, ну и да, вариант для бедных — floating ip у hetzner, который можно таскать между их разными гермозонами (а они уже по всей Германии раскиданы и почти не зависят друг от друга).
          А его уже можно по ipip куда нужно притаскивать (или просто трафик для нужного протокола проксировать).
            +1
            Был опыт как раз с их failover IP, для начала очень удобная штука. Пару раз даже приходилось переключать.
            Про дата-центры я тоже думал что они не зависят друг от друга и поддержка так говорила.

            Потом в один прекрасный день (этим летом) у них сломалась центральная железка и интернет упал в обоих «независимых» дата-центрах, собственно поэтому дата-центры теперь вообще от разных компаний и в разных городах.
              +1
              У них некоторые ДЦ независимее от других, чем другие хД
              Там смотреть надо, в каком городе железка стоит.
              Какой-нибудь RZ15 и RZ16 наверняка зависят от одной железки. RZ1 и RZ24 — вряд ли.
            0
            Сейчас переключение BGP происходит похожим образом: одна сеть анонсируется одновременно в двух дата-центрах. Если один дата-центр падает/выключается — весь трафик направляется в оставшийся. Входящий трафик, пришедший «не в тот» дата-центр маршрутизируется в «правильный» уже по внутренней сети, обратный ответ уходит напрямую.

            Виртуальные сервера могут одновременно работать в обоих дата-центрах (половина в одном, половина — в другом).
              0
              Если канал внутренней сети достаточно широк и надёжен — почему бы и нет.
            0
            А почему падал Ceph, можете поделиться? Не праздный интерес, тоже хотим себе сделать резервную площадку на его фундаменте…
              +1
              Это было несколько лет назад, так что в деталях могу ошибаться и ситуация могла поменяться.

              Он у меня ломался два раза.
              1. Один раз совсем, когда я его мучал в режиме: подключить ноду/отключить ноду/подключить ноду/отключить ноду несколько раз подряд прямо в процессе репликации, при этом что-то делал с rbd-образами и включал/выключал мониторы. В какой-то момент часть данных сказала «я не знаю где нахожусь, откуда реплицироваться и т.п.».

              Второй раз уже в обычном режиме, сломалась клиентская часть — просто работал с rbd-образами: создавал, удалял, блокировал, разблокировал и пришел к такому состоянию когда с конкретно этим образом сделать уже ничего нельзя — он подвис на хост-системах где монтировался. Т.е. можно например подмонтировать его на другой ноде, но не на первой. Первую надо ребутить целиком.
              0
              А если не секрет, насколько сильно у вас отличается производительность Ceph от производительности «голых дисков»? У меня на тестовой площадке удалось выжать примерно 50% на random write 4k. На чтение было порядка 200%.
                +1
                Сейчас ceph не используется.

                В теории — если операции записи идут одна за другой (т.е. рандомно, но в один поток) — 50% вполне хорошо, больше и не будет просто из устройства ceph (клиент передает данные на первый сервер, первый сервер пишет у себя и синхронно передает оставшимся ко количеству реплик, об успешной записи клиент получает подтверждение когда все реплики записаны).
                Если писать параллельно — много писателей, много хранилищь, то думаю выжать можно много — добавляйте дисков (серверов) и нагрузка будет распределяться и суммарная скорость будет увеличиваться почти кратно количеству серверов — мониторы в работе не участвуют, клиенты сами распределяют нагрузку по всем серверам.
                  0
                  ускорить получится если разместить журнал на ssd, тогда в теории скорость будет ограничиваться примерно так:
                  min( ssd, client_server_bandwidth, server_server_bandwidth/(replic_count-1) ) и задержки max(client_server + ssd, client_server+max(server_server))
                    0
                    Я не знаю, у меня не получилось увидеть существенного улучшения при переноса журнала на SSD. Выросла процентов на 20 производительность на запись, да и только. А стоимость в несколько раз подскочила.
                    Я подозреваю, что это связано с тем, что запись в журнал происходит с флагом O_DIRECT, а на диск — буферизованно. Как известно, SSD диски обладают достаточно случайной задержкой на запись, по крайней мере десктопные точно.
                    Инктанк сами признают, что журнал OSD — это большое зло, и разрабатывают другие модели хранения данных, типа LevelDB. Надеюсь, у них это получится…
                0
                Получилось некоторое подобие географического кластера. Все очень грамотно продумано, воспользуюсь вашей инструкцией и сделаю что-то подобное со своим DO + (нужно что-то подбирать).
                  0
                  Какая у вас ширина канала между площадками? Как вы осуществляете первоначальную синхронизацию?
                    +1
                    между площадками негарантированный гигабит
                    первоначально создаются два LVM-тома и дальше обычная drbd-синхронизация. Поскольку данные с обеих сторон изначально одинаковые (нули для чистого диска или клон одного и того же шаблона) — синхронизация проходит за несколько минут для диска в 10Гб, нагрузки ни на диски ни на канал при этом не создается.

                    Так же на будущее опробована начальная синхронизация сразу методом записи правильных метаданных. Поскольку начальное содержимое дисков одинаковое — это допускается и занимает несколько секунд уже для любых объёмов. Пока не применяется, т.к. первый способ проще и никаких неудобств на данный момент не доставляет.
                      +1
                      Видимо, у вас очень нетребовательные к записи проекты, и их очень немного… честно говоря, я даже в пределах локалки не представляю, как на гигабите организовать нормальное распределённое хранилище (точнее, представляю: по опыту никак, ибо потолок на запись в 120 МБ\с всё портит).
                        0
                        В основном это веб и разнообразные виртуальные серверы (тоже веб, 1С-ки, форексы и т.п.), в мегабайтах они создают небольшую нагрузку. Например вот прямо сейчас нагрузка на запись гуляет в промежутке между 1 и 14Мбайт/сек. Очень кратковременно поднимается до 30Мбайт/сек, это без учета сжатия — это несколько сотен VDS и несколько тысяч сайтов. Тут больше в ios-ах нагрузка — 300-1000, но иопсы вполне распределяются между серверами и параллелятся. TCP-соединение о очередь запросов на синхронизацию у каждого сервера своя и тут они друг друга не тормозят.

                        Когда гигабита перестанет хватать — можно расширить каналы до 10Гбит или разнести оборудование в еще несколько дата-центров.

                        Т.е. на данный момент проблема не актуальна, на будущее принципиальные пути решения предусмотрены.
                    0
                    Почему в качестве платформы для виртуализации не рассматривали Citrix Xenserver?
                    mGRE — это же CISCO фича (multipoint vpn)? Или я чего то недопонял? Если недопонял, то чем поднимали mGRE (Есть какие нибудь ссылки почитать)? В гугле все ссылки по слову mGRE выдают CISCO DMVPN

                    Насчёт Немецкого хостинга — почему ушли с него? (из Хетцнера ушли?)
                      0
                      из Хетцнера ушли?

                      присоединяюсь к вопросу
                        +2
                        Xen на самом деле тоже рассматривал, но бегло — он тоже работает на модифицированном ядре (тоже это как OpenVZ), т.е. все те же проблемы с доп. модулями. При исследовании методом гугления никаких явных преимуществ Xen перед KVM не нашел — в обоих есть аппаратная виртуализация, в обоих паравиртуализация (в Xen вроде чуть лучше). К тому же я знаком с компанией Redhat со школьной скамьи, в процессе многих лет убеждаюсь в том что этот дистрибутив (точнее клон — centos) работает очень стабильно, настройки выполняются понятно и т.п., на серверах стоит cenos где kvm родной. Т.е. в итоге решил что изучение новой технологии и еще несколько месяцев на эксперименты того не стоят — они уже не так сильно отличаются между собой как всё остальное.

                        mGRE работает в Linux из коробки, в centos 6.3 и выше точно, скорее всего в других тоже — версии старее не пробовал. Единственное упоминание которое я видел это geektimes.ru/post/48276/ дальше всё путем экспериментов и предположений как это должно быть.

                        Уходить собирался уже давно из соображений что нужно переезжать на собственное оборудование (в долговременной перспективе на мощном железе это выгоднее) + непонятная ситуация с санкциями (а вдруг я германия откажется мои платежи принимать) + одновременное отключение интернета в двух дата-центрах этим летом. Готовиться к переезду начал примерно год-полтора назад. Подобрал и протестировал дата-центры, купил сервера и тут доллар с евро каааак скакнут. Я сразу понял что правильно готовился и завершил переезд в Россию на праздниках, когда нагрузка поменьше.
                          0
                          Понял. Спасибо за развёрнутый ответ.
                          Если я правильно понял, то у вас своя подсеть PI адресов? (PI — provider independent).

                          Мысли по тематики статьи близки. Поделюсь своими «наработками».
                          Сервера для сайта
                          У нас есть несколько серверов для хостинга (основной и зеркала) и остальные сервера для бекэнда.
                          Пока «зеркалится» руками, путём одновременного деплоя проекта сервера. Каждый гипервизор для самого сайта имеет одинаковый набор VM с тождественными настройками (настраиваю через puppet).
                          Виртаулизация
                          Так же упор сделал на виртуальные машины, но выбрал Xenserver, т.к. с ним достаточно давно общаюсь. Пробовал KVM, но не понравилось.
                          VPN
                          Сеть VPN построена на tinc+quagga(zebra+ospf)+dhcp. Всё настраивается с помощью puppet, практически на полном автомате (нужно только добавить хост в группу на форемане и прописать адрес в манифесте).
                          В связи с особенностями настройки сети на Xenserver было принято решение использовать одну vm-роутер на каждом гипервизоре. Bare-metal хосты(не гипервизоры) являются отдельными точками VPN сети, но т.к. это конечные узлы, то они не анонсируют свои маршруты, в отличии от роутеров. За каждым vm-роутером своя подсеть(/24), хосты за роутерами получают адреса по dhcp, все маршруты раздаются по ospf. Первоначальное решение было втыкать tinc на каждый хост, но после нескольких сетевых лагов, из-за клонирования хостов, отказался от этого и вывел VPN на роутеры. Для BGP нужно иметь свою автономку, нам сейчас не по карману это предприятие, поэтому извратился как мог )).

                          Ну вот в общих чертах как то так. Конечно переключение у нас не быстрое, но некоторое резервирование сделано. Переключаем через DNS. Хотели через failover IP, но проблема в том, что он маршрутизируется только на основной IP адрес сервера, а web-proxy у нас висят на вторичных адресах. Тут я упёрся в сложности настройки сети на самом xenserver. Не всё так просто там как кажется с первого взгляда. Я смог сделать DNAT, но это сломало нам GeoIP опознавание. Пока что воюю с этой проблемой.

                          ЗЫ: спасибо за ссылочку про mGRE — очень хорошая вещь на самом деле. Я думал это чисто цискина примочка, в своё время с циской работал, очень понравилось.
                            0
                            Если я правильно понял, то у вас своя подсеть PI адресов? (PI — provider independent)

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

                            Да, я тоже настраиваю всё автоматом через шаблоны ansible — примерно одно и то же.

                            Для BGP нужно иметь свою автономку, нам сейчас не по карману это предприятие, поэтому извратился как мог )).

                            Да вообще организация отказоустойчивости штука очень дорогая как в плане оборудования, так и в плане администрирования — потому я и решил делать это массовым, чтобы клиент пришел ко мне и не парился сам по поводу всей этой обвязки. Получается не только проще, но и дешевле чем всё тоже самое самостоятельно городить. Кроме того по сетке в 256 адресов на каждый проект это очень расточительно в условиях их нехватки. У меня вот наоборот — сетка есть, но адреса экономятся. Все кому нет технической необходимости в прямом IP работают за балансировщиком + прозрачные шлюзы для FTP и SSH и проброс отдельных портов по мере надобности. Так что одной /24 сетки должно хватить надолго. Максимум планируется еще одна — для резерва.

                            Хотели через failover IP, но проблема в том, что он маршрутизируется только на основной IP адрес сервера, а web-proxy у нас висят на вторичных адресах

                            Посмотрите habrahabr.ru/post/231175/ думаю это поможет.
                              0
                              Да, хорошо должна заработать следующая схема:
                              1. на всех ваших серверах настраиваете маршрутизацию FailoverIP внутрь tinc-сети
                              2. Подключаете виртуальку которой нужно назначаить этот IP внутрь tinc-сети.

                              Тогда сеть будет работать если работает сервер на котором виртуалка и сервер на котором назначен failover ip (всё равно один это сервер или разные). Дальше остается только следить за тем чтобы виртуалка не поднялась на двух хостах одновременно — тут может возникнуть неопределенность маршрутизации внутри tinc.
                                0
                                Спасибо за подсказку.
                                Буду думать, но «в лоб» не поможет.
                                Xenserver конфигурит сеть своими скриптами. И, например, при создании машины или при добавлении/удалении сетевого интерфейса сеть реинициализируется. Я руками могу добавить маршрут, но после очередной реинициализации он сброситься. А если добавить маршрут в конфиг хоста на Xenserver, то это примениться на все хосты пула, что мне не нужно. Так то если руками маршрут добавить всё работает.
                              0
                              .
                                0
                                ?
                                  0
                                  Ошибся, сорри
                            0
                            отличная «шпоры» для тех, кто начал задумываться о серьёзный вопросах масштабирования/отказоустойчивости. возьму на заметку.
                              0
                              Дорогой автор, Вы могли бы дать ссылку, где можно почитать об описываемой Вами технологии «Анонс собственной сети адресов»?
                              Для «новичка» — что это такое, как это делается?.. Спасибо!
                                0
                                Анонс делается по протоколу BGP, хорошее описание маршрутизации в целом и BGP в частности сделано в цикле «Сети для самых маленьких», вот конкретно про BGP habrahabr.ru/post/184350/ но рекомендую начать сначала.

                                Непосредственно анонсирование довольно простое — несколько строк в настройках маршрутизатора или кликов мышкой, но сначала лучше понять принцип работы протокола и систему настройки маршрутизатора — это может занять некоторое время.
                                Кроме того вам нужно будет арендовать блок адресов, возможно номер автономной системы у какого-то LIR и заключить договор с оператором связи, который согласится установить с вами BGP-сессию, это делает далеко не каждый дата-центр и в большинстве случаев за это берется дополнительная оплата, дополнительно к оплате аренды/размещения сервера.
                                  0
                                  Спасибо большое!!!
                                0
                                Ни слова про репликацию БД и про кластеризацию роли Master'а, с переездом или в MM режиме. А ведь база есть практически у всех. Так же не видел описания того работает ли DRBD в MM режиме или переключение мастера чем-то управляется.
                                Почему в DRBD взяли Protocol B, а не C?
                                  0
                                  не ту кнопку нажал, ответ чуть ниже получился.
                                  0
                                  Ни слова про репликацию БД и про кластеризацию роли Master'а, с переездом или в MM режиме. А ведь база есть практически у всех

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

                                  Так же не видел описания того работает ли DRBD в MM режиме или переключение мастера чем-то управляется.

                                  Большую часть времени DRBD работает в режиме Master-Slave, protocol B. На время переезда режим переключается на Master-Master, protocol C и сразу после переезда виртуальной машины переключается обратно.

                                  Почему в DRBD взяли Protocol B, а не C?

                                  В режиме C добавляются задержки на запись, которые ввиду расстояния между серверами и так относительно большие (10-40мс). В типичных проектах процент записи небольшой относительно чтения + запись кешируется внутри виртуальной машины и на скорость работы конечного ПО это почти не влияет. Однако задержки его еще больше смысла не имеет.

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

                                  При Master-Slave протокол C не обязателен. Он может быть полезен при риске одновременного выключения питания на серверах — чтобы в случае потери первого сервера и отключении питания на втором данные остались целыми. Например если сервера стоят в одной стойке, выключилось электричество и мастер потом не включился — в этом случае на запасном сервере будут потеряны несколько последних операций записи.

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

                                  В случае отключения питания только на одном из серверов ничего страшного не происходит:
                                  — при отключении питания на мастере всё уже принято резервным сервером, положено в свою память и будет записано на диск.
                                  — при отключении питания на резервном сервере просто проводится ресинхронизация дисков. За счет использования контрольных сумм канал синхронизация проходит быстро — со скоростью чтения локальных дисков на проверку и передачу только изменившихся данных.
                                    0
                                    Про базу понял. Я думал мы на другом уровне работаем (внутри VM).

                                    Чем происходит переключение режимов работы DRBD? Что за софт принимает решения?

                                    Вообще-то, если рухнет питание на master'е и часть записей MySQL окажется в кэше виртуалки, то мы на Slave'е, который станет Master'ом через несколько секунд, получим капусту вместо данных и далеко не факт, что mysql repair сможет нам помочь. Разве что у нас везде работает Direct-IO и мы не встрянем в такую ситуацию.
                                      0
                                      Чем происходит переключение режимов работы DRBD? Что за софт принимает решения?

                                      Происходит скриптом переноса виртуалки, никаких решений не принимается — при команде на миграцию диск переводится в мастер-мастер, по окончании — в мастер-слейв, никакой логики.

                                      если рухнет питание на master'е и часть записей MySQL окажется в кэше виртуалки, то мы на Slave'е, который станет Master'ом через несколько секунд, получим капусту вместо данных и далеко не факт, что mysql repair сможет нам помочь

                                      мы получим не совсем капусту — ситуация будет аналогичная выключению питания на сервере и потом его загрузки, базы данных это спокойно переживают. Для MyISAM repair TABLE помогает хорошо, за много лет работы исключений пока не видел, в особо неудачной ситуации — всегда есть резервная копия. Для InnoDB ведется лог транзакций и максимум что теряется — транзакции, которые еще не скинуты на диск, обычно это несколько секунд до выключения. База потом сама восстанавливается из лога транзакций при включении. Клиентам по умолчанию везде ставится InnoDB, так что MyISAM и встречается-то редко.
                                        0
                                        Т.е. если Master упал по причине того что на ДЦ упал метеорит, то ни какая автоматика не включит Slave в работу? Нужно ручное вмешательство?

                                        База потом сама восстанавливается из лога транзакций при включении
                                        А где гарантия что лог-транзакций консистентен? И дело даже не в наличии лога и его целостности а в том что, что commit в базу не означает что данные дошли до физического диска и миновали в т.ч. его кэш.
                                          0
                                          Для этого есть третий ДЦ, в котором хранятся резервные копии + мониторится работа основных дата-центров.

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

                                          Мониторинг будет восстанавливаться на новой площадке, резервные копии пойдут делаться и накапливаться заново.
                                            0
                                            Так а решение о переключении принимает автоматика? Скрипты или там Pacemaker или же человек дергает рубильник, видя, что все плохо?
                                              0
                                              На данный момент решение принимает человек на основе данных мониторинга и оповещений.
                                              Автоматика в процессе поиска — она должна соответствовать тем же принципам, что и всё остальное — простое, понятное и предсказуемое в работе, заменяемое, отключаемое (т.е. в случае неожиданностей можно отключить автоматику и всё продолжит работать). Архитектурно она предусмотрена и будет работать в ДЦ с резервными копиями.

                                              Если готовая не найдётся — будет писаться своя.
                                                0
                                                Спасибо, будет интересно послушать про этот процесс. Если после поисков опишите результат — буду благодарен :)
                                            0
                                            За целостность лога транзакций отвечает ПО базы данных — тут ничего нового с точки зрения хостинга не придумать. В MySQL есть настройка как часто его скидывать на диск. Если изменения скидываются на диск в обход кеша — на физических серверах дополнительного кеширования не происходит — всё сразу уходит на диски. Правильность записи в журнал (т.е. что данные записаны в правильном порядке) могут контролироваться внутри VDS через системные вызовы вроде barrier.

                                            По поводу кеша — да, то что было в кеше базы данных и не выброшено на диск — будет потеряно. Обычно в базах есть настройка с какой периодичностью сбрасывать данные на диск. Например MySQL-InnoDB сбрасывает данные на диск сразу или раз в секунду, в зависимости от dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

                                            Операции с диском внутри VDS синхронны — т.е. дополнительного кеширования в память тут не добавляется. Когда VDS пишет на свой диск синхронно (например при сбросе лога на диск), то ответ «ок» он получает в момент когда данные уже сохранены локально + получены резервным сервером.
                                      0
                                      А Вы все это делаете для какого хостера, если не секрет?
                                        0
                                        Не секрет — www.f1f2.ru, собственно у меня в профиле написано.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое