Для этого есть третий ДЦ, в котором хранятся резервные копии + мониторится работа основных дата-центров.
При падении одного из основных ДЦ разбором ситуации и решением кто главный будет заниматься сервер в ДЦ с резервными копиями (в кластер он не входит).
Если метирит падает в ДЦ с резервными копиями — то копии накрываются, равно как и система мониторинга-управления. При этом основные дата-центры и клиентские ресурсы продолжают работать.
Мониторинг будет восстанавливаться на новой площадке, резервные копии пойдут делаться и накапливаться заново.
Чем происходит переключение режимов работы DRBD? Что за софт принимает решения?
Происходит скриптом переноса виртуалки, никаких решений не принимается — при команде на миграцию диск переводится в мастер-мастер, по окончании — в мастер-слейв, никакой логики.
если рухнет питание на master'е и часть записей MySQL окажется в кэше виртуалки, то мы на Slave'е, который станет Master'ом через несколько секунд, получим капусту вместо данных и далеко не факт, что mysql repair сможет нам помочь
мы получим не совсем капусту — ситуация будет аналогичная выключению питания на сервере и потом его загрузки, базы данных это спокойно переживают. Для MyISAM repair TABLE помогает хорошо, за много лет работы исключений пока не видел, в особо неудачной ситуации — всегда есть резервная копия. Для InnoDB ведется лог транзакций и максимум что теряется — транзакции, которые еще не скинуты на диск, обычно это несколько секунд до выключения. База потом сама восстанавливается из лога транзакций при включении. Клиентам по умолчанию везде ставится InnoDB, так что MyISAM и встречается-то редко.
Ни слова про репликацию БД и про кластеризацию роли 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 не обязателен. Он может быть полезен при риске одновременного выключения питания на серверах — чтобы в случае потери первого сервера и отключении питания на втором данные остались целыми. Например если сервера стоят в одной стойке, выключилось электричество и мастер потом не включился — в этом случае на запасном сервере будут потеряны несколько последних операций записи.
В нашем случае вероятность такого сценария стремится к нулю — сервера расположены в двух независимых, территориально удалённых дата-центрах (Москва и Санкт-Петербург). Если произойдет что-то такое что отключится электричество одновременно в обоих ДЦ и при этом в обоих одновременно не сработают резервные системы электроснабжения — это какая-то глобальная катастрофа и, вероятно, дата-центров уже нет. Тут никакой режим уже не поможет и если кому-то данные еще потребуются — они будут восстанавливаться из резервной копии в третьем дата-центре.
В случае отключения питания только на одном из серверов ничего страшного не происходит:
— при отключении питания на мастере всё уже принято резервным сервером, положено в свою память и будет записано на диск.
— при отключении питания на резервном сервере просто проводится ресинхронизация дисков. За счет использования контрольных сумм канал синхронизация проходит быстро — со скоростью чтения локальных дисков на проверку и передачу только изменившихся данных.
Анонс делается по протоколу BGP, хорошее описание маршрутизации в целом и BGP в частности сделано в цикле «Сети для самых маленьких», вот конкретно про BGP habrahabr.ru/post/184350/ но рекомендую начать сначала.
Непосредственно анонсирование довольно простое — несколько строк в настройках маршрутизатора или кликов мышкой, но сначала лучше понять принцип работы протокола и систему настройки маршрутизатора — это может занять некоторое время.
Кроме того вам нужно будет арендовать блок адресов, возможно номер автономной системы у какого-то LIR и заключить договор с оператором связи, который согласится установить с вами BGP-сессию, это делает далеко не каждый дата-центр и в большинстве случаев за это берется дополнительная оплата, дополнительно к оплате аренды/размещения сервера.
+ еще стоимость железа на котором эти терабайты работают
да, в данном случае оно старое и уже было куплено, но вложения в него уже сделаны + железо вполне можно продать: и место на складе занимать не будет и совесть спокойна (что не выкинули, а оно продолжает работать). К вырученным деньгам добавить те же $1500/Тб и думаю вполне можно купить новое, более эффективное хранилище.
ускорить получится если разместить журнал на ssd, тогда в теории скорость будет ограничиваться примерно так:
min( ssd, client_server_bandwidth, server_server_bandwidth/(replic_count-1) ) и задержки max(client_server + ssd, client_server+max(server_server))
В основном это веб и разнообразные виртуальные серверы (тоже веб, 1С-ки, форексы и т.п.), в мегабайтах они создают небольшую нагрузку. Например вот прямо сейчас нагрузка на запись гуляет в промежутке между 1 и 14Мбайт/сек. Очень кратковременно поднимается до 30Мбайт/сек, это без учета сжатия — это несколько сотен VDS и несколько тысяч сайтов. Тут больше в ios-ах нагрузка — 300-1000, но иопсы вполне распределяются между серверами и параллелятся. TCP-соединение о очередь запросов на синхронизацию у каждого сервера своя и тут они друг друга не тормозят.
Когда гигабита перестанет хватать — можно расширить каналы до 10Гбит или разнести оборудование в еще несколько дата-центров.
Т.е. на данный момент проблема не актуальна, на будущее принципиальные пути решения предусмотрены.
Да, хорошо должна заработать следующая схема:
1. на всех ваших серверах настраиваете маршрутизацию FailoverIP внутрь tinc-сети
2. Подключаете виртуальку которой нужно назначаить этот IP внутрь tinc-сети.
Тогда сеть будет работать если работает сервер на котором виртуалка и сервер на котором назначен failover ip (всё равно один это сервер или разные). Дальше остается только следить за тем чтобы виртуалка не поднялась на двух хостах одновременно — тут может возникнуть неопределенность маршрутизации внутри tinc.
Если я правильно понял, то у вас своя подсеть PI адресов? (PI — provider independent)
Почти, PI уже не раздают, так что формально это PA, но технически это ничем не отличается — так же своя автономная система, собственная маршрутизация и т.п.
Да, я тоже настраиваю всё автоматом через шаблоны ansible — примерно одно и то же.
Для BGP нужно иметь свою автономку, нам сейчас не по карману это предприятие, поэтому извратился как мог )).
Да вообще организация отказоустойчивости штука очень дорогая как в плане оборудования, так и в плане администрирования — потому я и решил делать это массовым, чтобы клиент пришел ко мне и не парился сам по поводу всей этой обвязки. Получается не только проще, но и дешевле чем всё тоже самое самостоятельно городить. Кроме того по сетке в 256 адресов на каждый проект это очень расточительно в условиях их нехватки. У меня вот наоборот — сетка есть, но адреса экономятся. Все кому нет технической необходимости в прямом IP работают за балансировщиком + прозрачные шлюзы для FTP и SSH и проброс отдельных портов по мере надобности. Так что одной /24 сетки должно хватить надолго. Максимум планируется еще одна — для резерва.
Хотели через failover IP, но проблема в том, что он маршрутизируется только на основной IP адрес сервера, а web-proxy у нас висят на вторичных адресах
Согласен, что игнорирование плохо, но падения в этом случае — очень хорошо.
В любом случае моя обработка таких ошибок заключается в
panic(errors.New(«Can't parse variable to int: » + a)) и дальше если случится — по стеку понять где эта ошибка и разбираться почему она случилась.
Ровно так же могла бы упасть и синтаксическая конструкция, только короче.
вот как раз в erlang или в примере как было бы хорошо есть вариант выбора что является нормальным поведением, а что — нет.
Например если я получаю строку из каких-то внутренних ресурсов я рассчитываю что она будет содержать число и работаю так как будето это число. Если там оказалось что-то другое — это ошибка и надо падать.
В случае если это входной параметры через API например — там можно было бы уже проверить явно есть ли ошибка и если есть — выдать код ошибки что такой-то парметр не правильный ну или поправить (по ситуации).
Сейчас в golang возможности выбирать нет — нужно обратавать всё.
Кстати да — интересно было бы посмотреть на сравнение — чем за свою стоимость ScaleIO лучше/хуже бесплатного ceph или ceph с коммерческой поддержкой. Вот ваш коллега AlBelyaev пишет что Крок внедряет и ceph в том числе habrahabr.ru/company/croc/blog/244085/
Заголовок спойлера
Тот же Ceph может стать отличной альтернативой для небольших офисов и может работать прямо на самих гипервизорах, если поставить в них побольше дисков. Таким образом можно соединить гипервихзор с СХД и существенно сэкономить на оборудовании. Но, конечно же, это все требует достаточно тонкой первоначальной настройки и сайзинга. В большой инсталляции может стать основой хранения данных, причем по скорости сравнимой с mid-range, hi-end массивами при правильной настройке. Не даром ведь их используют многие крупные провайдеры облачных услуг.
С ошибками — скорее нет. По поводу ошибок мне больше нравится подход erlang — чуть что не так — проблемная часть сразу падает и, если надо, перезапускается супервизором.
Общая система получается надёжной и код избавлен от рутинной обработки ошибок если ты их не ждешь.
Для примера тот же открытие файла
{ok, Handle} = file:open(...)
если всё ок — продолжаем работать.
Если не ок — сравнение не проходит и процесс падает целиком.
для игнорирования ошибки
{_, Handle} = file:open(...)
Для обработки ошибки
{Status, Handle} = file:open(...)
case Status of
...
end;
т.е. было бы прекрасно и в go писать что-то вроде:
file, nil := os.Open(...)
и если код ошибки вдруг не nil — падать в панику.
Аналогично для выражений в строку эти двойные возвраты мешаются, т.е. нельзя написать например
Если бы был способ при возврате ошибок или неожидаемого значения сразу падать — это значительно бы сократило и улучшило читаемость кода. Например удобно вот так:
символ _ может быть только один — он используется в качестве возвращаемого значения если остальные параметры совпадают.
вместо nil может быть константа для сравнения на равенство, выражение — для сравнения по значению или интерфейс для проверки соответствия интерфейсу.
Если что-то не совпало — сразу паника по поводу несовпадения условий.
Угу, мы оба ошились. Я случайно посчитал 4ТБ вместо 12, а вы 14 вместо 6.
Если 4 диска по 2Тб, то это всё же получается в сумме 8Тб, с учетом RAID5 — 6ТБ.
Т.е. правильная стоимость за 4 диска по 2Тб в RAID5 получается $9432.
Никак на бюджетное антикризисное решение не похоже.
Ceph тут мне кажется более бюджетным. В простом варианте использование бесплатно.
Коммерческая поддержка 24*7 стоит $13500/в год за 64Тб ёмкости.
Т.е. некритичные данные вроде тестировщиков и разработчиков можно располагать просто бесплатно.
При использовании для важных данных их поддержка получается заметно дешевле, чем ScaleIO.
Xen на самом деле тоже рассматривал, но бегло — он тоже работает на модифицированном ядре (тоже это как OpenVZ), т.е. все те же проблемы с доп. модулями. При исследовании методом гугления никаких явных преимуществ Xen перед KVM не нашел — в обоих есть аппаратная виртуализация, в обоих паравиртуализация (в Xen вроде чуть лучше). К тому же я знаком с компанией Redhat со школьной скамьи, в процессе многих лет убеждаюсь в том что этот дистрибутив (точнее клон — centos) работает очень стабильно, настройки выполняются понятно и т.п., на серверах стоит cenos где kvm родной. Т.е. в итоге решил что изучение новой технологии и еще несколько месяцев на эксперименты того не стоят — они уже не так сильно отличаются между собой как всё остальное.
mGRE работает в Linux из коробки, в centos 6.3 и выше точно, скорее всего в других тоже — версии старее не пробовал. Единственное упоминание которое я видел это geektimes.ru/post/48276/ дальше всё путем экспериментов и предположений как это должно быть.
Уходить собирался уже давно из соображений что нужно переезжать на собственное оборудование (в долговременной перспективе на мощном железе это выгоднее) + непонятная ситуация с санкциями (а вдруг я германия откажется мои платежи принимать) + одновременное отключение интернета в двух дата-центрах этим летом. Готовиться к переезду начал примерно год-полтора назад. Подобрал и протестировал дата-центры, купил сервера и тут доллар с евро каааак скакнут. Я сразу понял что правильно готовился и завершил переезд в Россию на праздниках, когда нагрузка поменьше.
При падении одного из основных ДЦ разбором ситуации и решением кто главный будет заниматься сервер в ДЦ с резервными копиями (в кластер он не входит).
Если метирит падает в ДЦ с резервными копиями — то копии накрываются, равно как и система мониторинга-управления. При этом основные дата-центры и клиентские ресурсы продолжают работать.
Мониторинг будет восстанавливаться на новой площадке, резервные копии пойдут делаться и накапливаться заново.
Происходит скриптом переноса виртуалки, никаких решений не принимается — при команде на миграцию диск переводится в мастер-мастер, по окончании — в мастер-слейв, никакой логики.
мы получим не совсем капусту — ситуация будет аналогичная выключению питания на сервере и потом его загрузки, базы данных это спокойно переживают. Для MyISAM repair TABLE помогает хорошо, за много лет работы исключений пока не видел, в особо неудачной ситуации — всегда есть резервная копия. Для InnoDB ведется лог транзакций и максимум что теряется — транзакции, которые еще не скинуты на диск, обычно это несколько секунд до выключения. База потом сама восстанавливается из лога транзакций при включении. Клиентам по умолчанию везде ставится InnoDB, так что MyISAM и встречается-то редко.
Вся прелесть в том, что ни на уровне клиента ни на уровне провайдера не нужно настраивать репликацию базы, синхронизацию файлов, поддерживать одинаковые настройки ПО и т.п. Она (репликация) делается сразу на уровне виртуальной машины, независимо от внутренней операционной системы и ПО. Программы внутри сервера клиента могут ничего не знать о репликации, отказоустойчивости и т.п.
Большую часть времени DRBD работает в режиме Master-Slave, protocol B. На время переезда режим переключается на Master-Master, protocol C и сразу после переезда виртуальной машины переключается обратно.
В режиме C добавляются задержки на запись, которые ввиду расстояния между серверами и так относительно большие (10-40мс). В типичных проектах процент записи небольшой относительно чтения + запись кешируется внутри виртуальной машины и на скорость работы конечного ПО это почти не влияет. Однако задержки его еще больше смысла не имеет.
Протокол C обязателен к применению при работе в режиме Master-Master, когда данные изменяются на обоих серверах, чтобы не получить кашу и DRBD переключается на этот протокол на время миграции виртуальной машины между серверами.
При Master-Slave протокол C не обязателен. Он может быть полезен при риске одновременного выключения питания на серверах — чтобы в случае потери первого сервера и отключении питания на втором данные остались целыми. Например если сервера стоят в одной стойке, выключилось электричество и мастер потом не включился — в этом случае на запасном сервере будут потеряны несколько последних операций записи.
В нашем случае вероятность такого сценария стремится к нулю — сервера расположены в двух независимых, территориально удалённых дата-центрах (Москва и Санкт-Петербург). Если произойдет что-то такое что отключится электричество одновременно в обоих ДЦ и при этом в обоих одновременно не сработают резервные системы электроснабжения — это какая-то глобальная катастрофа и, вероятно, дата-центров уже нет. Тут никакой режим уже не поможет и если кому-то данные еще потребуются — они будут восстанавливаться из резервной копии в третьем дата-центре.
В случае отключения питания только на одном из серверов ничего страшного не происходит:
— при отключении питания на мастере всё уже принято резервным сервером, положено в свою память и будет записано на диск.
— при отключении питания на резервном сервере просто проводится ресинхронизация дисков. За счет использования контрольных сумм канал синхронизация проходит быстро — со скоростью чтения локальных дисков на проверку и передачу только изменившихся данных.
Непосредственно анонсирование довольно простое — несколько строк в настройках маршрутизатора или кликов мышкой, но сначала лучше понять принцип работы протокола и систему настройки маршрутизатора — это может занять некоторое время.
Кроме того вам нужно будет арендовать блок адресов, возможно номер автономной системы у какого-то LIR и заключить договор с оператором связи, который согласится установить с вами BGP-сессию, это делает далеко не каждый дата-центр и в большинстве случаев за это берется дополнительная оплата, дополнительно к оплате аренды/размещения сервера.
да, в данном случае оно старое и уже было куплено, но вложения в него уже сделаны + железо вполне можно продать: и место на складе занимать не будет и совесть спокойна (что не выкинули, а оно продолжает работать). К вырученным деньгам добавить те же $1500/Тб и думаю вполне можно купить новое, более эффективное хранилище.
min( ssd, client_server_bandwidth, server_server_bandwidth/(replic_count-1) ) и задержки max(client_server + ssd, client_server+max(server_server))
Когда гигабита перестанет хватать — можно расширить каналы до 10Гбит или разнести оборудование в еще несколько дата-центров.
Т.е. на данный момент проблема не актуальна, на будущее принципиальные пути решения предусмотрены.
1. на всех ваших серверах настраиваете маршрутизацию FailoverIP внутрь tinc-сети
2. Подключаете виртуальку которой нужно назначаить этот IP внутрь tinc-сети.
Тогда сеть будет работать если работает сервер на котором виртуалка и сервер на котором назначен failover ip (всё равно один это сервер или разные). Дальше остается только следить за тем чтобы виртуалка не поднялась на двух хостах одновременно — тут может возникнуть неопределенность маршрутизации внутри tinc.
Почти, PI уже не раздают, так что формально это PA, но технически это ничем не отличается — так же своя автономная система, собственная маршрутизация и т.п.
Да, я тоже настраиваю всё автоматом через шаблоны ansible — примерно одно и то же.
Да вообще организация отказоустойчивости штука очень дорогая как в плане оборудования, так и в плане администрирования — потому я и решил делать это массовым, чтобы клиент пришел ко мне и не парился сам по поводу всей этой обвязки. Получается не только проще, но и дешевле чем всё тоже самое самостоятельно городить. Кроме того по сетке в 256 адресов на каждый проект это очень расточительно в условиях их нехватки. У меня вот наоборот — сетка есть, но адреса экономятся. Все кому нет технической необходимости в прямом IP работают за балансировщиком + прозрачные шлюзы для FTP и SSH и проброс отдельных портов по мере надобности. Так что одной /24 сетки должно хватить надолго. Максимум планируется еще одна — для резерва.
Посмотрите habrahabr.ru/post/231175/ думаю это поможет.
В любом случае моя обработка таких ошибок заключается в
panic(errors.New(«Can't parse variable to int: » + a)) и дальше если случится — по стеку понять где эта ошибка и разбираться почему она случилась.
Ровно так же могла бы упасть и синтаксическая конструкция, только короче.
Обертки — да, оберток уже много :)
Например если я получаю строку из каких-то внутренних ресурсов я рассчитываю что она будет содержать число и работаю так как будето это число. Если там оказалось что-то другое — это ошибка и надо падать.
В случае если это входной параметры через API например — там можно было бы уже проверить явно есть ли ошибка и если есть — выдать код ошибки что такой-то парметр не правильный ну или поправить (по ситуации).
Сейчас в golang возможности выбирать нет — нужно обратавать всё.
С ошибками — скорее нет. По поводу ошибок мне больше нравится подход erlang — чуть что не так — проблемная часть сразу падает и, если надо, перезапускается супервизором.
Общая система получается надёжной и код избавлен от рутинной обработки ошибок если ты их не ждешь.
Для примера тот же открытие файла
если всё ок — продолжаем работать.
Если не ок — сравнение не проходит и процесс падает целиком.
для игнорирования ошибки
Для обработки ошибки
т.е. было бы прекрасно и в go писать что-то вроде:
и если код ошибки вдруг не nil — падать в панику.
Аналогично для выражений в строку эти двойные возвраты мешаются, т.е. нельзя написать например
надо писать
Если бы был способ при возврате ошибок или неожидаемого значения сразу падать — это значительно бы сократило и улучшило читаемость кода. Например удобно вот так:
символ _ может быть только один — он используется в качестве возвращаемого значения если остальные параметры совпадают.
вместо nil может быть константа для сравнения на равенство, выражение — для сравнения по значению или интерфейс для проверки соответствия интерфейсу.
Если что-то не совпало — сразу паника по поводу несовпадения условий.
Если 4 диска по 2Тб, то это всё же получается в сумме 8Тб, с учетом RAID5 — 6ТБ.
Т.е. правильная стоимость за 4 диска по 2Тб в RAID5 получается $9432.
Никак на бюджетное антикризисное решение не похоже.
Коммерческая поддержка 24*7 стоит $13500/в год за 64Тб ёмкости.
Т.е. некритичные данные вроде тестировщиков и разработчиков можно располагать просто бесплатно.
При использовании для важных данных их поддержка получается заметно дешевле, чем ScaleIO.
Т.е. за лицензию на каждый 1U сервер с 4-я 2Тб дисками нужно будет заплатить $6288?
mGRE работает в Linux из коробки, в centos 6.3 и выше точно, скорее всего в других тоже — версии старее не пробовал. Единственное упоминание которое я видел это geektimes.ru/post/48276/ дальше всё путем экспериментов и предположений как это должно быть.
Уходить собирался уже давно из соображений что нужно переезжать на собственное оборудование (в долговременной перспективе на мощном железе это выгоднее) + непонятная ситуация с санкциями (а вдруг я германия откажется мои платежи принимать) + одновременное отключение интернета в двух дата-центрах этим летом. Готовиться к переезду начал примерно год-полтора назад. Подобрал и протестировал дата-центры, купил сервера и тут доллар с евро каааак скакнут. Я сразу понял что правильно готовился и завершил переезд в Россию на праздниках, когда нагрузка поменьше.