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 хост лежит. Ваша шара не заведется, так как не сможет вытянуть конфиг. И это изменение в новой версии очень неправильное для распределенной файловой системы, имхо.