GlusterFS, опыт новой версии

    Всем привет.

    В прошлый раз (Взрослеем с GlusterFS) я описывал как настроить для своих нужд GlusterFS 3.0.x. Недавно мы сделали апгрейд GlusterFS до 3.2.х., и так как между этими версиями обнаружилось масса различий в настройке, то решил описать процесс для общего ИТ разума.

    Сразу оговорюсь, что переход на новую версию был обусловлен глюками старой.
    Дело было после очередных сбоев Амазоновских EBS. Диск на втором мастере деградировал и мы выключили сервис на время исправления проблем бравыми инженерами AWS. После того как все пришло в норму, мы пытались включить второй мастер в обратно схему, но происходило непоправимое и все клиенты попросту подвисали и сетевые диски банально не отвечали. В клиентах нашлись ошибки, долгое гугление которых привело к “намекам” на форумах, что такие подвисания исправили в новых версиях, что было воспринято и радостно и грустно одновременно:) Пришлось обновляться.

    Первое, что стало понятно, это — наши конфиги от старых версий не подойдут, более того они теперь не нужны и все настраивается из командной строки.
    Настройка мастер-мастер происходит совсем по другому нежели раньше, и это первый минус новой схемы, я рассмотрю их в конце статьи.

    Инициализируем peer:

    root@files1.domain.com:~# gluster peer probe files2.domain.com
    Probe successful
    


    Проверяем:

    root@files1.domain.com:~# gluster peer status
    Number of Peers: 1
    
    
    Hostname: files2.domain.com
    Uuid: c8f2fg43-ch7e-47f3-9ec5-b4b66f81101d
    State: Peer in Cluster (Connected)
    


    Далее создаем диск(volume):

    root@files1.domain.com:~# gluster volume create volume_data replica 2 transport tcp files1.domain.com:/data files2.domain.com:/data
    Creation of volume volume_data has been successful. Please start the volume to access data.
    


    Стартуем диск:

    root@files1.domain.com:~# gluster volume start volume_data
    Starting volume volume_data has been unsuccessful
    


    Выполняем на обоих мастерах:

    /etc/init.d/glusterfs-server restart
    


    Если все прошло без ошибок, то вывод следующей команды должен выглядеть так:

    root@files1.domain.com:~# gluster volume info
    
    Volume Name: volume_data
    Type: Replicate
    Status: Started
    Number of Bricks: 2
    Transport-type: tcp
    Bricks:
    Brick1: files1.domain.com:/data
    Brick2: files2.domain.com:/data
    


    Ограничиваем доступ к нашим шарам таким образом:

    root@files1.domain.com:~# gluster volume set volume_data auth.allow 10.*
    


    Смотрим снова info:

    Volume Name: volume_data
    Type: Replicate
    Status: Started
    Number of Bricks: 2
    Transport-type: tcp
    Bricks:
    Brick1: files1.domain.com:/data
    Brick2: files2.domain.com:/data
    Options Reconfigured:
    auth.allow: 10.*
    


    Настройка на серверах закончена, идем на клиент. Я предполагаю, что вы в состоянии установить нужную версию пакета для клиента и она уже есть в системе.

    root@client.domain.com:~# mkdir /data
    
    root@client.domain.com:~# mount -t glusterfs files1.domain.com:/volume_data /data
    


    Смотрим на результат:

    root@client.domain.com:~#  df -h
    
    Filesystem            Size  Used Avail Use% Mounted on
    /dev/sda1             7.9G  6.6G  987M  88% /
    none                  3.4G  112K  3.4G   1% /dev
    none                  3.6G     0  3.6G   0% /dev/shm
    none                  3.6G   64K  3.6G   1% /var/run
    none                  3.6G     0  3.6G   0% /var/lock
    none                  3.6G     0  3.6G   0% /lib/init/rw
    /dev/sdb              414G  6.1G  387G   2% /mnt
    tmpfs                  10M  8.0K   10M   1% /tmp/tmpfs
    files1.domain.com:/ volume_data 
    		200G  109G   92G  55% /data
    


    Прописываем в /etc/fstab на client.domain.com :

    files1.domain.com:/volume_data /data glusterfs defaults,_netdev 0 0
    


    И что бы сохранить себе нервы при перезагрузке пробуем обычный трюк в таких случаях:

    root@client.domain.com:~#  umount /data
    root@client.domain.com:~#  mount -a
    


    Проверяем, что все ок:

    root@client.domain.com:~#  df -h
    
    Filesystem            Size  Used Avail Use% Mounted on
    /dev/sda1             7.9G  6.6G  987M  88% /
    none                  3.4G  112K  3.4G   1% /dev
    none                  3.6G     0  3.6G   0% /dev/shm
    none                  3.6G   64K  3.6G   1% /var/run
    none                  3.6G     0  3.6G   0% /var/lock
    none                  3.6G     0  3.6G   0% /lib/init/rw
    /dev/sdb              414G  6.1G  387G   2% /mnt
    tmpfs                  10M  8.0K   10M   1% /tmp/tmpfs
    files1.domain.com:/ volume_data 
    		200G  109G   92G  55% /data
    


    Вот и все.

    Отдельно хотел остановиться на минусах в новой GlusterFS:

    1)Если у вас нет онлайн обоих мастеров при настройке, то вы остановитесь на первой же команде.
    2)В предыдущей версии я ставил пароли на свои шары, в новой можно только сделать как мы делали выше auth.allow: 10.*, что как вы понимаете не всегда хорошая практика.
    3)
    /etc/fstab:
    
    files1.domain.com:/volume_data /data glusterfs defaults,_netdev 0 0
    
    

    Гластеровцы говорят, что такая привязка к одному серверу лишь для того, что бы вытянуть конфиг пиров и прочего, НО!
    Действительно, если пропадает один мастер, то клиент знает где второй, все отрабатывает хорошо в том случае когда уже все примонтировано, но увы и ах, если вам пришлось ребутать, поднимать из образа машину в то время как прописанный в fstab хост лежит. Ваша шара не заведется, так как не сможет вытянуть конфиг. И это изменение в новой версии очень неправильное для распределенной файловой системы, имхо.
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 20
    • 0
      Я конечно, не специалист в GlusterFS, но что мешает поднять VIP на нодах по которому будет вытягиваться конфиг?
      А отсутвие конфиг файлов меня огорчает тем, что теперь не получится разлить конфиги puppet'ом и спать спокойно…
      • 0
        Ну, в случае EC2 получится разве, что переключать днс, но это явно не совсем то, о чем вы говорите.
        • 0
          > Действительно, если пропадает один мастер, то клиент знает где второй, все отрабатывает хорошо в том случае когда уже все примонтировано, но увы и ах, если вам пришлось ребутать, поднимать из образа машину в то время как прописанный в fstab хост лежит.

          Включаете клиента в гластер-кластер, стартуете локального демона и монтируете через него. Проверено, схема работает. Ребут остальных узлов пофигу.

          У меня же другой вопрос. Не пробовали собирать Gluster с дисковой полкой (NAS)? У меня есть несколько массивов на полке, которые видны сразу нескольким «мастерам». Как бы сделать multipathing, чтобы при отвале одного мастера, его кусок автоматом с другого цеплялся. В более взрослых FS такая фигня есть. А тут — не пойму.
          • 0
            Включаете клиента в гластер-кластер, стартуете локального демона и монтируете через него. Проверено, схема работает. Ребут остальных узлов пофигу.


            Не совсе понял. не могли подробнее?

            У меня же другой вопрос. Не пробовали собирать Gluster с дисковой полкой (NAS)? У меня есть несколько массивов на полке, которые видны сразу нескольким «мастерам». Как бы сделать multipathing, чтобы при отвале одного мастера, его кусок автоматом с другого цеплялся. В более взрослых FS такая фигня есть. А тут — не пойму.


            Насколько я знаю, то нет. Но у меня самый универсальный путь применения гластера, может, что-то пропустил.
            • 0
              > Не совсе понял. не могли подробнее?
              Пускай наш нод называется node-1, тогда
              # gluster peer probe node-1
              А затем в fstab
              localhost:data /data glusterfs defaults,_netdev 0 0
              • 0
                Так, я же говорю, о проблемах на клиенте…
                • 0
                  Я так понял, что ситуация такая — на клиенте прописан один хост, мы клиента вырубили, вырубили этот хост. Стартуем клиента и тишина, на клиенте ничего не замонтируется.
                  А вот с localhost такой проблемы быть не должно.
                  • 0
                    Все правильно. Но на localhost нет конфига peer'a, поэтому пока клиент не возьмет его с какого нибудь мастера ничего не произойдет — не примаунтится клиент.
                    • +1
                      Если сделать peer probe, то конфиг появится. Я про то и говорю, что включить хост в кластер, но не экспортировать брики с него.
                      • 0
                        ах, вот как. спасибо за хак:)
          • 0
            А у кого уже есть опыт использования гластера в «продакшене» на относительно больших файловых коллекциях?
            Как раз тоже пытаемся его начать использовать, пока на 2 — 4 млн файлах, посмотрим. Первая проблема — получить приелемые скорости для отдачи файлов виндовым клиентикам — приходится раздавать подмонтированный раздел гластера по самбе…
            • 0
              У нас около 1,5 файликов на нем в продакшне. Скорость первого листинга оставляет желать лучшего. Ну и да, чем больше файлов в одной папке, тем хуже. Опять же смотря какая вам нужна скорость.
              • 0
                А как у вас собран гластер, в какой комбинации — replicated, distributed? Какая ФС «внизу»?
                У нас тоже была серьезная проблема и с листингом и со скоростью чтения. Нам необходимо максимально быстро отдавать относительно небольшие файлы (в среднем до 2 мб), параллельно в 20-30 потоков. Причем, часто файл нужен не целиком, а только начало и может пара seek-ов вглубь (антивирусный сканер). Первая попытка дала просто катастрофически низкую скорость, но тогда глустер был собран distributed replicated (4 ноды), причем, внизу была ZFS.
                Сейчас внесли изменения: четыре ноды собраны в distributed, на каждой ноде хардварный raid для отказоустойчивости, шара для раздачи монтируется через NFS, внизу ext4 с noatime/nodiratime.
                Мы сейчас еще тестируем, но даже на глаз каталоги стали открываться почти как на локальной машине.
                Дерево каталогов двухуровневое: 256 каталогов, в кадаждом — 256 подкаталогов.
            • 0
              Тема кстати очень интересная. Кстати не сравнивали ее с ceph?
              Я вот разрываюсь между ceph и gluster.
              • 0
                Не сравнивали, ничего не могу ответить вам, к сожалению.
                • 0
                  а режим NFS сервера не использовали? И вообще как на текущий момент с производительностью?
                  • 0
                    Не использовали. На счет производительности попробую образно: 16K-32K файликов на запись, 80К-120K в сутки на чтение. Две ноды мастера и 6-7 клиентов.
                    • 0
                      Ясно, спс. Надо будет тогда на виртуалках поигратся.
              • 0
                По своему опыту использования Gluster могу сказать что он нормально работает только на количестве машин >=3.
                Иначе при вылете одной из нод может потом собраться с ошибками в файлах (если они при вылете пострадали)
                • 0
                  3 машны — это нормальное условие для кластера, иначе получаем split-brain.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.