| Предыдущая версия справа и слева
Предыдущая версия
Следующая версия
|
Предыдущая версия
|
drbd_theory [2013/05/30 11:18]
metallic |
drbd_theory [2022/03/25 17:00] (текущий)
|
| Существует три протокола синхронизации DRBD-устройств. Синхронный "C", когда запись считается завершенной только если оба узла сообщили об успешном выполнении операции. Асинхронный "A", когда запись выполнилась на локальном узле, а на удаленный узел данные только отправлены. И промежуточный вариант "B", когда запись выполнилась на локальном узле, а удаленный узел подтвердил получение данных(но не запись их!). | Существует три протокола синхронизации DRBD-устройств. Синхронный "C", когда запись считается завершенной только если оба узла сообщили об успешном выполнении операции. Асинхронный "A", когда запись выполнилась на локальном узле, а на удаленный узел данные только отправлены. И промежуточный вариант "B", когда запись выполнилась на локальном узле, а удаленный узел подтвердил получение данных(но не запись их!). |
| |
| Работает DRBD на уровне ядра (как подгружаемый модуль). В качестве транспортного уровня используется протокол TCP 4 или 6 версии без шифрования и аутентификации. Также поддерживается некоторый экзотический протокол SuperSockets с низкими задержками, но он поддерживается только очень редким спецефическим оборудованием, в общем по факту этого протокола нет и о нем в большинстве случаев можно не думать :-) Целостность передаваемых данных по каналам связи может контролироваться с помощью контрольных сумм, например md5. | Работает DRBD на уровне ядра (как подгружаемый модуль). В качестве транспортного уровня используется протокол TCP 4 или 6 версии без шифрования и аутентификации. Наличие на пути канала связи маршрутизаторов не рекомендуется из-за больших задержек и низкой производительности. Также поддерживается некоторый экзотический протокол SuperSockets с низкими задержками, но он поддерживается только очень редким спецефическим оборудованием, в общем по факту этого протокола нет и о нем в большинстве случаев можно не думать :-) Целостность передаваемых данных по каналам связи может контролироваться с помощью контрольных сумм, например md5. |
| |
| Основная единица, с которой оперирует DRBD - ресурс. Серсурсом в данном контексте называется одно DRBD-устройство, у которого есть имя и номер(а также ряд других настроек, все это задается в конфигурационном файле). Имя ресурса используется при выполнении административных операций с помощью утилит администрирования, а номер(может начинаться с 0) - это порядковый номер DRBD-устройства /dev/drbd//X//. | Основная единица, с которой оперирует DRBD - ресурс. Рерсурсом в данном контексте называется одно DRBD-устройство, у которого есть имя и номер(а также ряд других настроек, все это задается в конфигурационном файле). Имя ресурса используется при выполнении административных операций с помощью утилит администрирования, а номер(может начинаться с 0) - это порядковый номер DRBD-устройства /dev/drbd//X//. |
| |
| Оба узла в нормальном режиме всегда имеют актуальную локальную копию ресурсов, т.к. при записе на мастере, данные тут же отображаются на слейве(в случае протокола С), но возможны ситуации, когда слейв был недоступен, а в этот момент выполнялась запись на мастер, тогда происходит рассинхронизация ресурсов. В таком случае ресурс на слейве получает статус Outdated. После восстановления связи, будет выполнена синхнронизация между мастером и слейвом. | Оба узла в нормальном режиме всегда имеют актуальную локальную копию ресурсов, т.к. при записе на мастере, данные тут же отображаются на слейве(в случае протокола С), но возможны ситуации, когда слейв был недоступен, а в этот момент выполнялась запись на мастер, тогда происходит рассинхронизация ресурсов. В таком случае ресурс на слейве получает статус Outdated. После восстановления связи, будет выполнена синхнронизация между мастером и слейвом. |
| В случае использования в качестве транспорта TCP, крайне желательно, даже настоятельно рекомендуется, соединять узлы между собой прямым соединением, т.е. без промежуточного свитча(кросс-кабелем). Это нужно для того, чтобы исключить дополнительную точку отказа на транспортном уровне, т.к. подобные сбои приносят большие проблемы(об этом ниже). Часто на практике используют резервирование каналов(linux bonding в режиме master/backup). | В случае использования в качестве транспорта TCP, крайне желательно, даже настоятельно рекомендуется, соединять узлы между собой прямым соединением, т.е. без промежуточного свитча(кросс-кабелем). Это нужно для того, чтобы исключить дополнительную точку отказа на транспортном уровне, т.к. подобные сбои приносят большие проблемы(об этом ниже). Часто на практике используют резервирование каналов(linux bonding в режиме master/backup). |
| |
| В случае потери канала связи, по которому происходит синхронизация и при этом используется система управления кластером, либо по другим причинам, например человекческий фактор, может сложиться такая ситуация, когда оба узла переходят в режим мастер, но при этом не синхронизируются друг с другом, потому что потеряна связь, в результате чего у каждого узла получается своя модифицированная версия данных, которую уже невозможно синхронизировать, это явление называется **split brain**. DRBD имеет возможность автоматически уведомлять администратора, в случае возникновения такой ситуации. | В случае потери канала связи, по которому происходит синхронизация и при этом используется система управления кластером, либо по другим причинам, например человекческий фактор, может сложиться такая ситуация, когда оба узла переходят в режим мастер, но при этом не синхронизируются друг с другом, потому что потеряна связь, в результате чего у каждого узла получается своя модифицированная версия данных, которую уже невозможно синхронизировать, это явление называется **split brain**. После восстановления связи между узлами, узел, который обнаружил **split brain** переходит в режим StandAlone. DRBD имеет возможность автоматически уведомлять администратора, в случае возникновения такой ситуации. |
| |
| Решить эту проблему можно либо вручную, либо в автоматическом режиме. В ручном режиме администратор сам выбирает из двух узлов жертву, т.е. узел, на котором изменения будут потеряны и он станет слейвом, после чего синхронизирует изменения с мастера. Как уже упоминалось, существует автоматический режим, который отключен по умолчанию. Существует три алгоритма автоматического решения проблемы **split brain**: | Решить эту проблему можно либо вручную, либо в автоматическом режиме. В ручном режиме администратор сам выбирает из двух узлов жертву, т.е. узел, на котором изменения будут потеряны и он станет слейвом, после чего синхронизирует изменения с мастера. Как уже упоминалось, существует автоматический режим, который отключен по умолчанию. Существует три алгоритма автоматического решения проблемы **split brain**: |
| * **Discarding modifications made on the “younger” primary** - в этом режиме, после восстановления связи между нодами, изменения будут отвергнуты на узле, который стал мастером последним, т.е. который был мастер меньшее кол-во времени. | * **Discarding modifications made on the “younger” primary** - в этом режиме, после восстановления связи между узлами, изменения будут отвергнуты на узле, который стал мастером последним, т.е. который был мастер меньшее кол-во времени. |
| * **Discarding modifications made on the “older” primary** - все наоборот, после восстановления связи, в качестве жертвы будет выбран узел, который стал матером первым. | * **Discarding modifications made on the “older” primary** - все наоборот, после восстановления связи, в качестве жертвы будет выбран узел, который стал матером первым. |
| * **Graceful recovery from split brain if one host has had no intermediate changes** - это более "интуитивный" режим, если среди узлов есть такой, на котором не было сделано никаких изменения на DRBD-устройстве, то он выбирается в качестве жертвы и на него выполняется синхронизация. Однако, такой сценарий крайне маловероятен, т.к. при монтировании файловой системы с устройства, даже в режиме только для чтения, устройство уже будет иметь изменения. | * **Graceful recovery from split brain if one host has had no intermediate changes** - это более "интуитивный" режим, если среди узлов есть такой, на котором не было сделано никаких изменения на DRBD-устройстве, то он выбирается в качестве жертвы и на него выполняется синхронизация. Однако, такой сценарий крайне маловероятен, т.к. при монтировании файловой системы с устройства, даже в режиме только для чтения, устройство уже будет иметь изменения. |
| | |
| Выбор режима восстановления **split brain** зависит от конкретных приложений, которые работают поверх DRBD. Для некоторых может быть приемлемо потерять некотоые изменения, а для некоторых нет, например финансовые базы данных, в этом случае должен использоваться только ручной режим или вообще не использоваться DRBD. | Выбор режима восстановления **split brain** зависит от конкретных приложений, которые работают поверх DRBD. Для некоторых может быть приемлемо потерять некотоые изменения, а для некоторых нет, например финансовые базы данных, в этом случае должен использоваться только ручной режим или вообще не использоваться DRBD. |
