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