Комментарии 12
Для проектов, где обязательно требуется репликация через SAN-фабрику по Fibre Channel, мы сейчас дописываем соответствующее решение, но пока оно не готово
1. Есть сроки? Когда решение будет готово, это будет просто обновление ПО, или потребуются какие-либо доп.карты/порты/лицензии?
2. Предложение: добавить возможность создавать маппинги заранее, но чтобы для роли Secondary они были неактивными. Тогда для переключения потребуется только переключить роль, а маппинги «переедут» сами.
Спасибо за комментарий.
- Есть сроки? Когда решение будет готово, это будет просто обновление ПО, или потребуются какие-либо доп.карты/порты/лицензии?
Срок — этот год. Надеюсь третий квартал. Устанавливаться будет вместе со штатным обновлением. Будет входить в туже лицензию, где есть репликация. То есть те у кого уже есть лицензия на реплики этот функционал получат автоматом.
Предложение: добавить возможность создавать маппинги заранее, но чтобы для роли Secondary они были неактивными. Тогда для переключения потребуется только переключить роль, а маппинги «переедут» сами.
Изначально так и хотели, но были технические нюансы, поэтому быстро сделать не смогли. Но в следующий релиз реплик обязательно добавим, это решаемая задача.
Для справки: corosync + pacemaker переключают 4 ресурса по 6Тб примерно за 30 секунд автоматически, если мастер недоступен. Каждый ресурс переключается 5-8 секунд и доступен сразу после переключения.
Stack: corosync
Current DC: s1-san9 (version 1.1.18-11.el7.centos-2b07d5c5a9) - partition with quorum
Last updated: Tue Jun 18 09:00:31 2019
Last change: Wed Mar 27 11:18:52 2019 by root via cibadmin on san-10
2 nodes configured
24 resources configured
Node san-10: online
ping_gateway (ocf::pacemaker:ping): Started
drbd_r3 (ocf::linbit:drbd): Slave
drbd_r0 (ocf::linbit:drbd): Slave
stonith_san-9 (stonith:rcd_serial): Started
drbd_r2 (ocf::linbit:drbd): Slave
drbd_r1 (ocf::linbit:drbd): Slave
Node san-9: online
iscsi_lun_r3 (ocf::heartbeat:iSCSILogicalUnit): Started
drbd_r2 (ocf::linbit:drbd): Master
ping_gateway (ocf::pacemaker:ping): Started
stonith_san-10 (stonith:rcd_serial): Started
ip_r0 (ocf::heartbeat:IPaddr2): Started
iscsi_target_r0 (ocf::heartbeat:iSCSITarget): Started
iscsi_target_r1 (ocf::heartbeat:iSCSITarget): Started
ip_r3 (ocf::heartbeat:IPaddr2): Started
iscsi_target_r3 (ocf::heartbeat:iSCSITarget): Started
ip_r2 (ocf::heartbeat:IPaddr2): Started
iscsi_target_r2 (ocf::heartbeat:iSCSITarget): Started
ip_r1 (ocf::heartbeat:IPaddr2): Started
drbd_r0 (ocf::linbit:drbd): Master
drbd_r1 (ocf::linbit:drbd): Master
iscsi_lun_r0 (ocf::heartbeat:iSCSILogicalUnit): Started
drbd_r3 (ocf::linbit:drbd): Master
iscsi_lun_r1 (ocf::heartbeat:iSCSILogicalUnit): Started
iscsi_lun_r2 (ocf::heartbeat:iSCSILogicalUnit): Started
No inactive resources
Node Attributes:
* Node san-10:
+ pingd : 1
* Node san-9:
+ master-drbd_r0 : 10000
+ master-drbd_r1 : 10000
+ master-drbd_r2 : 10000
+ master-drbd_r3 : 10000
+ pingd : 1
Migration Summary:
* Node san-9:
* Node san-10:За 3 с половиной года было более десятка переключений по разным причинам, в том числе и по питанию — ни разу не потеряли ни байта.
Что такого в вашем, не имеющем аналогов, решении, чего нельзя сделать на raid10 + drbd + corosync?
Пропажа связи между узлами к split-brain состоянию напрямую не ведёт.
При отсутствии связи с primary узлом secondary узел можно сделать primary только вручную (с предупреждением большими красными буквами, конечно).
Если таким рукотворным способом всё-же было вызвано состояние split-brain, то разрешается это принудительным перезаписыванием данных выбранного узла и повторной синхронизацией, тоже вручную.
По поводу аварийного переключения на secondary — я правильно понял, что админ должен узнать о проблеме, доползти до компа, открыть веб-морду или приложение, увидеть что там отвалилось и руками переключить? И всё это занимает в идеале около трёх минут при наличии админа, уже сидящего за компом?
Спасибо, но нет, вы не правильно поняли :-). Админу сидеть и смотреть в монитор необязательно, СХД имеет штатные средства мониторинга, которые оповещают о всех серьезных событиях в том числе и о проблемах с репликацией. Оповещения можно настроить через электронную почту и/или SNMP. Также дополнительно есть MIB-ы для Zabbix.
Для справки: corosync + pacemaker переключают 4 ресурса по 6Тб примерно за 30 секунд автоматически, если мастер недоступен. Каждый ресурс переключается 5-8 секунд и доступен сразу после переключения.
Репликация в нашем случае — это простое средство катастрофоустойчивости предназначенное для ручного переключения нагрузки в случае аварии. Для автоматического переключения предусмотрен метрокластер, о котором мы напишем в следующей статье
За 3 с половиной года было более десятка переключений по разным причинам, в том числе и по питанию — ни разу не потеряли ни байта.
Что такого в вашем, не имеющем аналогов, решении, чего нельзя сделать на raid10 + drbd + corosync?
С чего вы взяли, что наша реализация репликации не имеет аналогов? Обычная работающая и простая в использовании реплика, не более. Сделать может каждый если очень захочет.
- Как работает синхронная репликация при включенных кэшах на хранилках (кэши в оперативке контроллеров, а не на SSD каком-нибудь)? Хост получит подтверждение, как только на обоих хранилищах кэши среплицируются? Или как?
- Как отреагирует хост, с которого льются данные на СХД, на падение реплики? Подвисанием записи, так как с реплики не приходят подтверждения? Какой таймаут ожидания ответа реплики?
- Пускай случилась какая-то беда — рассинхрон, да еще и основная хранилка померла. Предупредит ли реплика, что на ней неактуальные данные, если ее попытаться сделать Мастером?
Спасибо за интересные вопросы! По пунктам.
Как работает синхронная репликация при включенных кэшах на хранилках (кэши в оперативке контроллеров, а не на SSD каком-нибудь)? Хост получит подтверждение, как только на обоих хранилищах кэши среплицируются? Или как?
Синхронная репликация работает одинаково, что с включенным RAM-кэшом СХД, что с выключенным, поскольку не имеет к нему никакого отношения. Специального оповещения хосту также не нужно. Хосту приходят данные уже подтвержденные всеми участниками реплики, т.к. они записываются (точнее становятся доступными для хоста) только после подтверждения и в момент когда хост начинает работать с записанными данными они уже идентичны данным на остальных участниках реплики.
Как отреагирует хост, с которого льются данные на СХД, на падение реплики? Подвисанием записи, так как с реплики не приходят подтверждения? Какой таймаут ожидания ответа реплики?
В плохом случае: хост будет пытаться лить данные пока не поймет, что блочное устройство недоступно, оно отключится по тайм-ауту от хостовой ОС и запись прекратится.
В хорошем случае: если в течение установленного тайм-аута блочное устройство опять станет доступным (администратор или метрокластер переключил secondary на primary), то ничего не произойдет, подвиснет ненадолго и дальше продолжит записывать данные.
Как вы поняли, тайм-ауты устанавливаются в настройках ОС.
Пускай случилась какая-то беда — рассинхрон, да еще и основная хранилка померла. Предупредит ли реплика, что на ней неактуальные данные, если ее попытаться сделать Мастером?
Репликация работает с блочным устройством и "ничего не знает" о том, насколько актуальны данные в файловой системе ОС хоста.
Если из-за ошибки случился split-brain, то данные принудительно перезаписываются вручную администратором с того узла, который он считает актуальным.
Если у нас просто "разъехались" данные из-за обрыва канала между СХД, то после того, как канал станет доступным, данные автоматически синхронизируются и приоритетным узлом будет primary.
Синхронная репликация работает одинаково, что с включенным RAM-кэшом СХД, что с выключенным, поскольку не имеет к нему никакого отношения.
Не о том был вопрос. Попробуем снова. Когда есть кэш в оперативке контроллера СХД (пока одна хранилка без реплики), хосту прилетает подтверждение об удачной записи, как только данные попали в кэш, на диск они попадут несколько позже (но хосту уже на это пофиг). Когда есть реплика (но нет кэша), хосту прилетит подтверждение об удачной записи, когда данные запишутся на диски на обоих хранилках. А когда хост получит подтверждение о записи, если есть и реплика и кэши? Вижу такой вариант: хост -> кэш мастера -> кэш реплики -> подтверждение записи -> отложенная запись на диски мастера/реплики. Но тогда вы должны были реализовать репликацию кэшей хранилок. Вряд ли это так, и вы забыли об этом похвастаться? Тогда как?
Репликация работает с блочным устройством и «ничего не знает» о том, насколько актуальны данные в файловой системе ОС хоста.
Снова не про то. По вашим скриншотам видно, что реплика понимает, на сколько процентов она совпадает с оригиналом/мастером. Так вот, если процесс синхронизации еще не закончен (не важно по какой причина произошел рассинхрон) и умирает мастер, админа предупредят, что реплику до мастера поднимать не следует, это грозит потерей данных?
Не о том был вопрос. Попробуем снова. Когда есть кэш в оперативке контроллера СХД (пока одна хранилка без реплики), хосту прилетает подтверждение об удачной записи, как только данные попали в кэш, на диск они попадут несколько позже (но хосту уже на это пофиг). Когда есть реплика (но нет кэша), хосту прилетит подтверждение об удачной записи, когда данные запишутся на диски на обоих хранилках. А когда хост получит подтверждение о записи, если есть и реплика и кэши? Вижу такой вариант: хост -> кэш мастера -> кэш реплики -> подтверждение записи -> отложенная запись на диски мастера/реплики. Но тогда вы должны были реализовать репликацию кэшей хранилок. Вряд ли это так, и вы забыли об этом похвастаться? Тогда как?
RAM-кэш на СХД работает сам по себе и никак не "отчитывается" хосту. Тот механизм, который вы описываете (подтверждение записи хосту) актуален для кэша внутри хоста (т.е. оперативной памяти самого хоста).
В случае RAM-кэша СХД, хосту ничего не прилетает, поскольку он не участвует в подтверждении транзакций записи. Подтверждение таких транзакций происходит внутри СХД. Опишу эту схему подробнее.
Как только данные попали в кэш СХД, то сразу же (без записи на диск СХД, то есть находясь в кэше) транзакция подтверждается внутри СХД на всех контроллерах (для синхронизации используется внутренний интерконнект на базе PCI) и с данными можно работать хосту (то есть хост эти данные уже видит), хотя они крутятся в кэше СХД и по настоящему не записаны ещё на диски.
Что произойдет если в этот момент СХД упадет, например, из-за отключения электричества (а ИБП допустим нет)? При этом не важно есть реплика или нет. На этот случай предусмотрена батарейка внутри контроллера СХД (BBU). Она будет держать питание (около 10 минут) RAM-кэша и загрузчика (внутреннего диска, на котором установлена ОС контроллера и есть ещё свободное место) для того, чтобы данные из кэша упали на загрузчик (не на диски СХД, т. к. они уже обесточены, а именно на загрузчик). За это время данные упадут на загрузчик (то есть данные из кэша останутся сохранены) и СХД выключится полностью.
Когда СХД включат обратно, при загрузке система увидит, что есть подтвержденные транзакции, но они не записаны на диск и автоматом полезет за ними в кэш. Там она их само собой не найдет и потом второй путь у СХД — это специально отведенная область на загрузчике, куда как раз скидываются данные в случае подобных отказов. СХД сбросит эти данные на диски и потом уже загрузится окончательно. Таким образом с данными будет все в порядке.
Теперь представим что у нас есть синхронная репликация. Что от этого меняется? В общем-то ничего :-), просто количество контроллеров увеличилось. Пример.
На СХД 1 идет транзакция записи и попадает в RAM-кэш. Перед тем как СХД "разрешит" хосту увидеть эти данные записанными она должна подтвердить их на всех контроллерах СХД (без этого смысл синхронной реплики теряется). СХД1 подтвердила запись в кэш у себя и ждет когда эта же транзакция подтвердится на СХД2. СХД2 само собой подтвердит запись чуть позже, т.к. до неё ещё надо пройти по каналу реплики (именно поэтому каналы должны быть серьезные), но независимо от того, как долго СХД2 будет подтверждать запись, пока она этого не сделает, хост который пишет на СХД1 данных этих не увидит.
Таким образом нет нужды что либо сообщать хосту, он видит данные, которые подтверждены всеми участниками реплики, а если они кем либо не подтверждены, то эти данные для хоста "не существуют".
Снова не про то. По вашим скриншотам видно, что реплика понимает, на сколько процентов она совпадает с оригиналом/мастером. Так вот, если процесс синхронизации еще не закончен (не важно по какой причина произошел рассинхрон) и умирает мастер, админа предупредят, что реплику до мастера поднимать не следует, это грозит потерей данных?
Если по какой-либо причине, в процессе синхронизации умирает мастер, то статус реплики переходит в "неконсистентный". Если нужно срочно поднимать инфраструктуру с резервной СХД, то при попытке примапить LUN с резеврной СХД из неконсистентой репилки админу скажут, что "ты не прав, написано же неконсистентно! :-)" и это действие будет заблокировано. Из этой ситуации есть два выхода.
1)Если мастер собирается подниматься и это время можно подождать, то лучше подождать, т.к. там априори более свежие данные. При поднятии мастера данные автоматом досинхронизируются.
2)Если мастер "уничтожен" и на него больше нет надежды, то резервную СХД нужно мягко ребутнуть ИЛИ перезапустить службы репликации в меню служб (первое надежнее). При перезапуске СХД автоматически восстановит консистентность реплики и LUN с резервной СХД можно будет мапить, но само собой данные в ней будут только те, что успели синхронизироваться.
Web интерфейс к DRBD?
AERODISK Engine: Катастрофоустойчивость. Часть 1