Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
С BGP есть более хитрый вариант, если есть /23
Можно с одной точки анонсировать /23 всю, а с другой — /24, входящую в неё. Тогда в штатной ситуации трафик будет переть туда, где горит /24 (могу ошибаться, давненько с этим не работал уже), а при падении этого маршрута — туда, откуда светится /23. Ну или наоборот.
Тогда нагрузка будет перещелкиваться автоматом.
Можно с одной точки анонсировать /23 всю, а с другой — /24, входящую в неё. Тогда в штатной ситуации трафик будет переть туда, где горит /24 (могу ошибаться, давненько с этим не работал уже), а при падении этого маршрута — туда, откуда светится /23. Ну или наоборот.
Тогда нагрузка будет перещелкиваться автоматом.
А, ну и да, вариант для бедных — floating ip у hetzner, который можно таскать между их разными гермозонами (а они уже по всей Германии раскиданы и почти не зависят друг от друга).
А его уже можно по ipip куда нужно притаскивать (или просто трафик для нужного протокола проксировать).
А его уже можно по ipip куда нужно притаскивать (или просто трафик для нужного протокола проксировать).
Был опыт как раз с их failover IP, для начала очень удобная штука. Пару раз даже приходилось переключать.
Про дата-центры я тоже думал что они не зависят друг от друга и поддержка так говорила.
Потом в один прекрасный день (этим летом) у них сломалась центральная железка и интернет упал в обоих «независимых» дата-центрах, собственно поэтому дата-центры теперь вообще от разных компаний и в разных городах.
Про дата-центры я тоже думал что они не зависят друг от друга и поддержка так говорила.
Потом в один прекрасный день (этим летом) у них сломалась центральная железка и интернет упал в обоих «независимых» дата-центрах, собственно поэтому дата-центры теперь вообще от разных компаний и в разных городах.
Сейчас переключение BGP происходит похожим образом: одна сеть анонсируется одновременно в двух дата-центрах. Если один дата-центр падает/выключается — весь трафик направляется в оставшийся. Входящий трафик, пришедший «не в тот» дата-центр маршрутизируется в «правильный» уже по внутренней сети, обратный ответ уходит напрямую.
Виртуальные сервера могут одновременно работать в обоих дата-центрах (половина в одном, половина — в другом).
Виртуальные сервера могут одновременно работать в обоих дата-центрах (половина в одном, половина — в другом).
А почему падал Ceph, можете поделиться? Не праздный интерес, тоже хотим себе сделать резервную площадку на его фундаменте…
Это было несколько лет назад, так что в деталях могу ошибаться и ситуация могла поменяться.
Он у меня ломался два раза.
1. Один раз совсем, когда я его мучал в режиме: подключить ноду/отключить ноду/подключить ноду/отключить ноду несколько раз подряд прямо в процессе репликации, при этом что-то делал с rbd-образами и включал/выключал мониторы. В какой-то момент часть данных сказала «я не знаю где нахожусь, откуда реплицироваться и т.п.».
Второй раз уже в обычном режиме, сломалась клиентская часть — просто работал с rbd-образами: создавал, удалял, блокировал, разблокировал и пришел к такому состоянию когда с конкретно этим образом сделать уже ничего нельзя — он подвис на хост-системах где монтировался. Т.е. можно например подмонтировать его на другой ноде, но не на первой. Первую надо ребутить целиком.
Он у меня ломался два раза.
1. Один раз совсем, когда я его мучал в режиме: подключить ноду/отключить ноду/подключить ноду/отключить ноду несколько раз подряд прямо в процессе репликации, при этом что-то делал с rbd-образами и включал/выключал мониторы. В какой-то момент часть данных сказала «я не знаю где нахожусь, откуда реплицироваться и т.п.».
Второй раз уже в обычном режиме, сломалась клиентская часть — просто работал с rbd-образами: создавал, удалял, блокировал, разблокировал и пришел к такому состоянию когда с конкретно этим образом сделать уже ничего нельзя — он подвис на хост-системах где монтировался. Т.е. можно например подмонтировать его на другой ноде, но не на первой. Первую надо ребутить целиком.
А если не секрет, насколько сильно у вас отличается производительность Ceph от производительности «голых дисков»? У меня на тестовой площадке удалось выжать примерно 50% на random write 4k. На чтение было порядка 200%.
Сейчас ceph не используется.
В теории — если операции записи идут одна за другой (т.е. рандомно, но в один поток) — 50% вполне хорошо, больше и не будет просто из устройства ceph (клиент передает данные на первый сервер, первый сервер пишет у себя и синхронно передает оставшимся ко количеству реплик, об успешной записи клиент получает подтверждение когда все реплики записаны).
Если писать параллельно — много писателей, много хранилищь, то думаю выжать можно много — добавляйте дисков (серверов) и нагрузка будет распределяться и суммарная скорость будет увеличиваться почти кратно количеству серверов — мониторы в работе не участвуют, клиенты сами распределяют нагрузку по всем серверам.
В теории — если операции записи идут одна за другой (т.е. рандомно, но в один поток) — 50% вполне хорошо, больше и не будет просто из устройства ceph (клиент передает данные на первый сервер, первый сервер пишет у себя и синхронно передает оставшимся ко количеству реплик, об успешной записи клиент получает подтверждение когда все реплики записаны).
Если писать параллельно — много писателей, много хранилищь, то думаю выжать можно много — добавляйте дисков (серверов) и нагрузка будет распределяться и суммарная скорость будет увеличиваться почти кратно количеству серверов — мониторы в работе не участвуют, клиенты сами распределяют нагрузку по всем серверам.
ускорить получится если разместить журнал на ssd, тогда в теории скорость будет ограничиваться примерно так:
min( ssd, client_server_bandwidth, server_server_bandwidth/(replic_count-1) ) и задержки max(client_server + ssd, client_server+max(server_server))
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. Надеюсь, у них это получится…
Я подозреваю, что это связано с тем, что запись в журнал происходит с флагом O_DIRECT, а на диск — буферизованно. Как известно, SSD диски обладают достаточно случайной задержкой на запись, по крайней мере десктопные точно.
Инктанк сами признают, что журнал OSD — это большое зло, и разрабатывают другие модели хранения данных, типа LevelDB. Надеюсь, у них это получится…
Получилось некоторое подобие географического кластера. Все очень грамотно продумано, воспользуюсь вашей инструкцией и сделаю что-то подобное со своим DO + (нужно что-то подбирать).
Какая у вас ширина канала между площадками? Как вы осуществляете первоначальную синхронизацию?
между площадками негарантированный гигабит
первоначально создаются два LVM-тома и дальше обычная drbd-синхронизация. Поскольку данные с обеих сторон изначально одинаковые (нули для чистого диска или клон одного и того же шаблона) — синхронизация проходит за несколько минут для диска в 10Гб, нагрузки ни на диски ни на канал при этом не создается.
Так же на будущее опробована начальная синхронизация сразу методом записи правильных метаданных. Поскольку начальное содержимое дисков одинаковое — это допускается и занимает несколько секунд уже для любых объёмов. Пока не применяется, т.к. первый способ проще и никаких неудобств на данный момент не доставляет.
первоначально создаются два LVM-тома и дальше обычная drbd-синхронизация. Поскольку данные с обеих сторон изначально одинаковые (нули для чистого диска или клон одного и того же шаблона) — синхронизация проходит за несколько минут для диска в 10Гб, нагрузки ни на диски ни на канал при этом не создается.
Так же на будущее опробована начальная синхронизация сразу методом записи правильных метаданных. Поскольку начальное содержимое дисков одинаковое — это допускается и занимает несколько секунд уже для любых объёмов. Пока не применяется, т.к. первый способ проще и никаких неудобств на данный момент не доставляет.
Видимо, у вас очень нетребовательные к записи проекты, и их очень немного… честно говоря, я даже в пределах локалки не представляю, как на гигабите организовать нормальное распределённое хранилище (точнее, представляю: по опыту никак, ибо потолок на запись в 120 МБ\с всё портит).
В основном это веб и разнообразные виртуальные серверы (тоже веб, 1С-ки, форексы и т.п.), в мегабайтах они создают небольшую нагрузку. Например вот прямо сейчас нагрузка на запись гуляет в промежутке между 1 и 14Мбайт/сек. Очень кратковременно поднимается до 30Мбайт/сек, это без учета сжатия — это несколько сотен VDS и несколько тысяч сайтов. Тут больше в ios-ах нагрузка — 300-1000, но иопсы вполне распределяются между серверами и параллелятся. TCP-соединение о очередь запросов на синхронизацию у каждого сервера своя и тут они друг друга не тормозят.
Когда гигабита перестанет хватать — можно расширить каналы до 10Гбит или разнести оборудование в еще несколько дата-центров.
Т.е. на данный момент проблема не актуальна, на будущее принципиальные пути решения предусмотрены.
Когда гигабита перестанет хватать — можно расширить каналы до 10Гбит или разнести оборудование в еще несколько дата-центров.
Т.е. на данный момент проблема не актуальна, на будущее принципиальные пути решения предусмотрены.
Почему в качестве платформы для виртуализации не рассматривали Citrix Xenserver?
mGRE — это же CISCO фича (multipoint vpn)? Или я чего то недопонял? Если недопонял, то чем поднимали mGRE (Есть какие нибудь ссылки почитать)? В гугле все ссылки по слову mGRE выдают CISCO DMVPN
Насчёт Немецкого хостинга — почему ушли с него? (из Хетцнера ушли?)
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/ дальше всё путем экспериментов и предположений как это должно быть.
Уходить собирался уже давно из соображений что нужно переезжать на собственное оборудование (в долговременной перспективе на мощном железе это выгоднее) + непонятная ситуация с санкциями (а вдруг я германия откажется мои платежи принимать) + одновременное отключение интернета в двух дата-центрах этим летом. Готовиться к переезду начал примерно год-полтора назад. Подобрал и протестировал дата-центры, купил сервера и тут доллар с евро каааак скакнут. Я сразу понял что правильно готовился и завершил переезд в Россию на праздниках, когда нагрузка поменьше.
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).
Мысли по тематики статьи близки. Поделюсь своими «наработками».
Сервера для сайта
У нас есть несколько серверов для хостинга (основной и зеркала) и остальные сервера для бекэнда.
Пока «зеркалится» руками, путём одновременного деплоя проекта сервера. Каждый гипервизор для самого сайта имеет одинаковый набор 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.
1. на всех ваших серверах настраиваете маршрутизацию FailoverIP внутрь tinc-сети
2. Подключаете виртуальку которой нужно назначаить этот IP внутрь tinc-сети.
Тогда сеть будет работать если работает сервер на котором виртуалка и сервер на котором назначен failover ip (всё равно один это сервер или разные). Дальше остается только следить за тем чтобы виртуалка не поднялась на двух хостах одновременно — тут может возникнуть неопределенность маршрутизации внутри tinc.
Спасибо за подсказку.
Буду думать, но «в лоб» не поможет.
Xenserver конфигурит сеть своими скриптами. И, например, при создании машины или при добавлении/удалении сетевого интерфейса сеть реинициализируется. Я руками могу добавить маршрут, но после очередной реинициализации он сброситься. А если добавить маршрут в конфиг хоста на Xenserver, то это примениться на все хосты пула, что мне не нужно. Так то если руками маршрут добавить всё работает.
Буду думать, но «в лоб» не поможет.
Xenserver конфигурит сеть своими скриптами. И, например, при создании машины или при добавлении/удалении сетевого интерфейса сеть реинициализируется. Я руками могу добавить маршрут, но после очередной реинициализации он сброситься. А если добавить маршрут в конфиг хоста на Xenserver, то это примениться на все хосты пула, что мне не нужно. Так то если руками маршрут добавить всё работает.
.
отличная «шпоры» для тех, кто начал задумываться о серьёзный вопросах масштабирования/отказоустойчивости. возьму на заметку.
Дорогой автор, Вы могли бы дать ссылку, где можно почитать об описываемой Вами технологии «Анонс собственной сети адресов»?
Для «новичка» — что это такое, как это делается?.. Спасибо!
Для «новичка» — что это такое, как это делается?.. Спасибо!
Анонс делается по протоколу BGP, хорошее описание маршрутизации в целом и BGP в частности сделано в цикле «Сети для самых маленьких», вот конкретно про BGP habrahabr.ru/post/184350/ но рекомендую начать сначала.
Непосредственно анонсирование довольно простое — несколько строк в настройках маршрутизатора или кликов мышкой, но сначала лучше понять принцип работы протокола и систему настройки маршрутизатора — это может занять некоторое время.
Кроме того вам нужно будет арендовать блок адресов, возможно номер автономной системы у какого-то LIR и заключить договор с оператором связи, который согласится установить с вами BGP-сессию, это делает далеко не каждый дата-центр и в большинстве случаев за это берется дополнительная оплата, дополнительно к оплате аренды/размещения сервера.
Непосредственно анонсирование довольно простое — несколько строк в настройках маршрутизатора или кликов мышкой, но сначала лучше понять принцип работы протокола и систему настройки маршрутизатора — это может занять некоторое время.
Кроме того вам нужно будет арендовать блок адресов, возможно номер автономной системы у какого-то LIR и заключить договор с оператором связи, который согласится установить с вами BGP-сессию, это делает далеко не каждый дата-центр и в большинстве случаев за это берется дополнительная оплата, дополнительно к оплате аренды/размещения сервера.
Ни слова про репликацию БД и про кластеризацию роли Master'а, с переездом или в MM режиме. А ведь база есть практически у всех. Так же не видел описания того работает ли DRBD в MM режиме или переключение мастера чем-то управляется.
Почему в DRBD взяли Protocol B, а не C?
Почему в 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 сможет нам помочь. Разве что у нас везде работает 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 пишет на свой диск синхронно (например при сбросе лога на диск), то ответ «ок» он получает в момент когда данные уже сохранены локально + получены резервным сервером.
По поводу кеша — да, то что было в кеше базы данных и не выброшено на диск — будет потеряно. Обычно в базах есть настройка с какой периодичностью сбрасывать данные на диск. Например MySQL-InnoDB сбрасывает данные на диск сразу или раз в секунду, в зависимости от dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit
Операции с диском внутри VDS синхронны — т.е. дополнительного кеширования в память тут не добавляется. Когда VDS пишет на свой диск синхронно (например при сбросе лога на диск), то ответ «ок» он получает в момент когда данные уже сохранены локально + получены резервным сервером.
А Вы все это делаете для какого хостера, если не секрет?
Не секрет — www.f1f2.ru, собственно у меня в профиле написано.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как реализовать почти мгновенное переключение сайта между площадками, когда одна упала