О чем: делал кластер высокой готовности на двух нодах, с использованием heartbeat. Кластер под веб-сервер (apache, nginx, php, mysql). Здесь не инструкция о поднятии подобного кластера, а заметки по поводу использования кластерных файловых систем, то, чего не хватает в распространенных статьях и описание грабель, на которые наступил я.
Сначала то, чего не хватает в описании настройки drbd (http://www.opennet.ru/base/sys/drbd_setup.txt.html):
Настройка drbd, чтобы уменьшить файловую систему на существующем разделе — юзаем команду
Желаемый раздел выдаст сама drbd, указывается в килобайтах (например 1000K)
После запуска диска он будет выдавать в /proc/drbd примерно такое состояние
При вводе команды
будет изощренно ругаться типа
в старых статьях рекомендуется делать
но он не понимает таких простых и доступных ключей и в мане ничего нет о таком, а правильно делать так:
Тогда наступает счастье и он начинает синкать диск, что видно в /proc/drbd примерно так:
Теперь о glusterfs:
Замечательная файловая система… поначалу казалась, репликация мастер-мастер, куча примочек, которые можно комбинировать, и главное отличие от drbd — она одновременно на всех нодах примонтирована может быть.
Косяк номер 1, по утверждениям разработчиков, должен быть исправлен в версии 2.0.1 (не проверял точно ли исправлен) — использование раздела glusterfs для хранения базы mysql противопоказано! Mysql ставит блокировки на файлы базы и не снимает их сразу после завершения работы или, например, смерти ноды. А когда mysql со второй ноды пытается работать с этой базой, то вся нода начинает тупить по черному из-за процесса сервера glusterfsd и в результате кластер нифига не работоспособен.
Косяк номер 2 — производительность. Не скажу за другие конфигурации, но для реплицируемого раздела на две ноды, при конфигурации из примера на сайте гластера, производительность апача (на гластерном разделе лежит весь www) падает до 10 раз. Замер производился утилитой ab при количестве конкурирующих запросов 10. Путем долгих экпериментов с конфигами был выявлен наилучший конфиг клиента (это для моего случая, когда две ноды разделяют свои разделы). В примере подключались сначала оба раздела через сеть, потом объединялись в миррор, после чего на этот миррор применялись трансляторы кэша и тредов. При этом варианте производительность в 10 раз хуже, чем при прямой работе апача с дисками. Если конфиг переделать так: раздел текущей ноды цепляем через posix(также как сервер это делает), удаленный раздел как в примере через сеть, потом на удаленный раздел применяем кэш и потом в миррор собираем уже волюм кэша и локальный раздел. Треды только тормозят работу, чтение вперед результатов не дает, отложенная запись в моем примере нужна не была, так как запись очень редко имеет место быть. В указанной конфигурации потеря производительности относительно использования локального раздела всего около 50%. Но я из-за этого отказался от glusterfs в пользу второго раздела на drbd (первый был настроен под мускуль, а второй монтируется на второй ноде под апач). Также хочу заметить, что в тестах прямого чтения glusterfs практически не показывает разницы с локальными файловыми системами, а вот в моем случае… увы.
Сначала то, чего не хватает в описании настройки drbd (http://www.opennet.ru/base/sys/drbd_setup.txt.html):
Настройка drbd, чтобы уменьшить файловую систему на существующем разделе — юзаем команду
resize2fs <путь_к_разделу> <желаемый_размер>Желаемый раздел выдаст сама drbd, указывается в килобайтах (например 1000K)
После запуска диска он будет выдавать в /proc/drbd примерно такое состояние
cs:Connected st:Secondary/Secondary ds:Inconsistent/InconsistentПри вводе команды
drbdadm primary <имя_ресурса>будет изощренно ругаться типа
/dev/drbd1: State change failed: (-2) Refusing to be Primary without at least one UpToDate disk
Command 'drbdsetup /dev/drbd1 primary' terminated with exit code 17в старых статьях рекомендуется делать
drbdadm -- --do-what-I-say primary <имя_ресурса>но он не понимает таких простых и доступных ключей и в мане ничего нет о таком, а правильно делать так:
drbdadm -- --overwrite-data-of-peer primary <имя_ресурса>Тогда наступает счастье и он начинает синкать диск, что видно в /proc/drbd примерно так:
1: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---
ns:225808 nr:0 dw:0 dr:225808 al:0 bm:13 lo:0 pe:895 ua:0 ap:0
[>....................] sync'ed: 0.4% (71460/71676)M
finish: 0:27:25 speed: 44,444 (44,444) K/sec
resync: used:0/61 hits:111995 misses:14 starving:0 dirty:0 changed:14
act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0Теперь о glusterfs:
Замечательная файловая система… поначалу казалась, репликация мастер-мастер, куча примочек, которые можно комбинировать, и главное отличие от drbd — она одновременно на всех нодах примонтирована может быть.
Косяк номер 1, по утверждениям разработчиков, должен быть исправлен в версии 2.0.1 (не проверял точно ли исправлен) — использование раздела glusterfs для хранения базы mysql противопоказано! Mysql ставит блокировки на файлы базы и не снимает их сразу после завершения работы или, например, смерти ноды. А когда mysql со второй ноды пытается работать с этой базой, то вся нода начинает тупить по черному из-за процесса сервера glusterfsd и в результате кластер нифига не работоспособен.
Косяк номер 2 — производительность. Не скажу за другие конфигурации, но для реплицируемого раздела на две ноды, при конфигурации из примера на сайте гластера, производительность апача (на гластерном разделе лежит весь www) падает до 10 раз. Замер производился утилитой ab при количестве конкурирующих запросов 10. Путем долгих экпериментов с конфигами был выявлен наилучший конфиг клиента (это для моего случая, когда две ноды разделяют свои разделы). В примере подключались сначала оба раздела через сеть, потом объединялись в миррор, после чего на этот миррор применялись трансляторы кэша и тредов. При этом варианте производительность в 10 раз хуже, чем при прямой работе апача с дисками. Если конфиг переделать так: раздел текущей ноды цепляем через posix(также как сервер это делает), удаленный раздел как в примере через сеть, потом на удаленный раздел применяем кэш и потом в миррор собираем уже волюм кэша и локальный раздел. Треды только тормозят работу, чтение вперед результатов не дает, отложенная запись в моем примере нужна не была, так как запись очень редко имеет место быть. В указанной конфигурации потеря производительности относительно использования локального раздела всего около 50%. Но я из-за этого отказался от glusterfs в пользу второго раздела на drbd (первый был настроен под мускуль, а второй монтируется на второй ноде под апач). Также хочу заметить, что в тестах прямого чтения glusterfs практически не показывает разницы с локальными файловыми системами, а вот в моем случае… увы.