HA-кластер, файловые системы, реплицируемые по сети

    О чем: делал кластер высокой готовности на двух нодах, с использованием heartbeat. Кластер под веб-сервер (apache, nginx, php, mysql). Здесь не инструкция о поднятии подобного кластера, а заметки по поводу использования кластерных файловых систем, то, чего не хватает в распространенных статьях и описание грабель, на которые наступил я.

    Сначала то, чего не хватает в описании настройки 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 практически не показывает разницы с локальными файловыми системами, а вот в моем случае… увы.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 9

      0
      А как у DRBD со стабильностью?
        0
        Прекрасно со стабильностью
          0
          Работает стабильно, правда у меня пока не под нагрузкой, только тесты. Завтра должен войти в строй. Единственное, на что пока наступил — при разрыве соединения между нодами получается brain-split, и после восстановления связи он тупо стоит и ждет пока ты ему ручками скажешь кто же из них главный даже если изменений за это время не было. Наверное можно в конфиге накрутить что-нибудь, сейчас буду смотреть в эту сторону
            0
            Интересует как раз момент дисконнекта и выхода ноды из строя
              0
              Несколько секунд пока hertbeat сообразит, что нода пропала, потом быстро монтирует себе этот раздел и запускает что там надо запустить после. У меня два диска, один под базу на первой ноде, второй под данные апача и нжинкса на второй. В конфиге ресурсов хертбита прописано:
              node1 х.х.х.65 drbddisk::db_store Filesystem::/dev/drbd0::/mnt/db_store::ext3::defaults mysqld
              node2 х.х.х.66 drbddisk::data Filesystem::/dev/drbd1::/mnt/cluster::ext3::defaults httpd nginx vsftpd
              Соответственно если вторая падает, то все это поднимется на первой. Лаг, как я уже говорил — несколько секунд.
          0
          А как изменилась ситуация через пару лет?
            0
            Все работает стабильно :) сейчас планируется переезд к другому хостинг-провайдеру, на другие сервера. Из изменений конфигурации только увеличиваю размеры разделов.
              0
              так и сидите на drdb?
              больше с глустером не игрались?
                0
                Слышал, что в новых версиях гластера проблема (с мускулем описанная) решена, но перелопачивать рабочий кластер, понятное дело, не стоит.

          Only users with full accounts can post comments. Log in, please.