Comments 45
Отлично, просто отлично.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если готовая не найдётся — будет писаться своя.
Спасибо, будет интересно послушать про этот процесс. Если после поисков опишите результат — буду благодарен :)
За целостность лога транзакций отвечает ПО базы данных — тут ничего нового с точки зрения хостинга не придумать. В 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 пишет на свой диск синхронно (например при сбросе лога на диск), то ответ «ок» он получает в момент когда данные уже сохранены локально + получены резервным сервером.
Only those users with full accounts are able to leave comments. Log in, please.