Thank you for reading this post, don't forget to subscribe!

Уста­нав­ли­ва­ем wget и attr

yum install wget attr -y

Так­же необ­хо­ди­мо отклю­чить фай­р­волл и уда­лить его из авто­за­груз­ки, так как кли­ент­ская маши­на обра­ща­ет­ся к сер­ве­рам каж­дый раз по раз­ным портам

systemctl stop firewalld

systemctl disable firewalld

Добав­ля­ем необ­хо­ди­мые репозитории:

Уста­нав­ли­ва­ем сер­вер­ную часть GlusterFS

yum install -y glusterfs gluster-cli glusterfs-libs glusterfs-server

Далее запус­ка­ем служ­бу glusterd и добав­ля­ем в автозагрузку;

systemctl start glusterd

systemctl enable glusterd

 

отклю­ча­ем сете­вой экран и SELinux.

vi /etc/sysconfig/selinux

SELINUX=disabled

При­ме­ча­ние: Во избе­жа­ние раз­лич­ных про­блем, реко­мен­ду­ет­ся исполь­зо­вать служ­бу NTP для син­хро­ни­за­ции вре­ме­ни сер­ве­ров хра­не­ния и кли­ен­тов, а так­же исполь­зо­вать DNS вме­сто локаль­ных фай­лов hosts.

 

Уста­нав­ли­ва­ем кли­ент­скую часть GlusterFS

yum install glusterfs-client

 

====================================

Создание томов

Преж­де чем создать рас­пре­де­лен­ный по несколь­ким узлам том, необ­хо­ди­мо объ­еди­нить сер­ве­ры в дове­рен­ный пул.

Если у вас два сер­ве­ра, напри­мер gl01 и gl02, то на пер­вом выпол­ня­ем сле­ду­ю­щую команду;

 Если сер­ве­ров боль­ше, то тоже самое выпол­ня­ем с остальными.

Создание Replicated-тома

Пожа­луй самая про­стая конфигурация.

 Здесь rep01 — это имя созда­ва­е­мо­го тома, а replica 2 — его кон­фи­гу­ра­ция кото­рая гово­рит о том, что дан­ные будут хра­нить­ся в двух экзем­пля­рах, на gl01:/gluster/gv01 и gl02:/gluster/gv01 соответственно.

Далее запус­ка­ем том;

Полу­чить инфор­ма­цию о кон­фи­гу­ра­ции тома мож­но с помо­щью коман­ды info:

 Расширение тома

В дан­ном слу­чае, добав­ле­ние еще одной или несколь­ких фай­ло­вых систем никак не ска­жет­ся на доступ­ном объ­е­ме хра­ни­ли­ща а лишь уве­ли­чит чис­ло копий(реплик).

В дан­ном при­ме­ре добав­ля­е­мая фай­ло­вая систе­ма раз­ме­ща­ет­ся на одном из сер­ве­ров пула. Если же необ­хо­ди­мо создать репли­ку на новом сер­ве­ре, его пред­ва­ри­тель­но нуж­но вклю­чить в пул (peer probe), как это было пока­за­но в нача­ле раз­де­ла. Далее, мож­но доба­вить новую фай­ло­вую систе­му с помо­щью коман­ды add-brick, уве­ли­чив коли­честв реплик на 1 (replica 4).

Репли­ка­ция име­ю­щих­ся дан­ных на новые фай­ло­вые систе­мы будет про­из­ве­де­на неко­то­рое через вре­мя автоматически.

Создание Distributed-тома

Для созда­ния тако­го тома необ­хо­ди­ма мини­мум одна фай­ло­вая систе­ма. В даль­ней­шем том мож­но рас­ши­рять новы­ми ФС сколь­ко угодно.

В этом при­ме­ре созда­ет­ся том (distr01) кото­рый будет состо­ять из двух фай­ло­вых систем (/distr01, /distr01) рас­по­ло­жен­ных на сер­ве­рах gl01 и gl02.
Если локаль­ная фай­ло­вая систе­ма явля­ет­ся частью кор­не­вой ФС сер­ве­ра то необ­хо­ди­мо доба­вить в конец ключ force для при­ну­ди­тель­но­го созда­ния тома.

Смон­ти­ро­вав такой том на кли­ен­те, вы уви­ди­те, что его объ­ем равен сум­ме объ­е­мов фай­ло­вых систем сер­ве­ров. А запи­сав на него неко­то­рое коли­че­ство фай­лов, лег­ко заме­тить, что часть их ока­жет­ся на одном сер­ве­ре, а часть — на дру­гом. При­чем соот­но­ше­ние фай­лов и их объ­е­ма будет нерав­но­мер­ным. Выбор сер­ве­ра про­из­во­дит­ся на осно­ве име­ни фай­ла с исполь­зо­ва­ни­ем алго­рит­ма хеши­ро­ва­ния (прак­ти­че­ски слу­чай­ным образом).

Рас­ши­рить том очень просто;

После добав­ле­ния новых ФС, они будут оста­вать­ся пусты­ми пока на них не будут запи­са­ны новые фай­лы. Что бы рав­но­мер­но рас­пре­де­лить меж­ду все­ми кир­пи­ча­ми уже име­ю­щи­е­ся дан­ные необ­хо­ди­мо выпол­нить про­це­ду­ру перераспределения(rebalance).

В резуль­та­те все дан­ные на этом томе будут, насколь­ко это воз­мож­но, рав­но­мер­но рас­пре­де­ле­ны меж­ду узла­ми хра­не­ния. На кли­ент­ской сто­роне види­мых изме­не­ний про­изой­ти не должно.

Уда­ле­ние под тома;

Все дан­ные нахо­дя­щи­е­ся на этой ФС будут недо­ступ­ны поль­зо­ва­те­лю через том distr01

Создание Distributed Replicated тома

В таком томе чис­ло фай­ло­вых систем долж­но быть крат­но чис­лу реплик. Кро­ме того, очень важ­на после­до­ва­тель­ность сер­ве­ров ука­зан­ных при созда­нии тома.

В этом при­ме­ре, чис­ло реплик рав­но двум — replica 2. Это озна­ча­ет, что все запи­сы­ва­е­мые на том дан­ные будут хра­нить­ся в двух экзем­пля­рах. Далее сер­ве­ра ука­зы­ва­ют­ся пара­ми gl01:/dr gl02:/dr и сле­дом gl01:/dr2 gl02:/dr2. Каж­дая пара будет реп­ли­ци­ро­вать дан­ные меж­ду собой.
Так как это Distributed том, поло­ви­на запи­сан­ных дан­ных будет нахо­дит­ся на пер­вой паре, по копии на каж­дом сер­ве­ре, а вто­рая поло­ви­на на вто­рой паре соот­вет­ствен­но. Важ­но, что­бы фай­ло­вые систе­мы в одной паре нахо­ди­лись на раз­ных узлах!

Рас­ши­рить том так же про­сто. Един­ствен­ное усло­вие, фай­ло­вые систе­мы долж­ны добав­лять­ся парами:

После добав­ле­ния необ­хо­ди­мо выпол­нить пере­рас­пре­де­ле­ние дан­ных (rebalance)

Если нужен еще более надеж­ный том, то мож­но уве­ли­чить чис­ло реплик и соот­вет­ствен­но коли­че­ство фай­ло­вых систем.

Здесь пара­метр replica равен 3 а соот­вет­ствен­но при созда­нии или при рас­ши­ре­нии тома сер­ве­ры долж­ны ука­зы­вать­ся тройками.

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

Чередующийся том

Тома тако­го типа совер­шен­но небез­опас­ны, но воз­мож­но кому-то это и не нужно.

Здесь созда­ёт­ся том с име­нем st_vol, типом stripe (чере­ду­ю­щий­ся) и состо­ять он будет из двух фай­ло­вых систем на раз­ных серверах.

Так как дан­ные, запи­сы­ва­е­мые на такой том, будут раз­де­ле­ны попо­лам меж­ду дву­мя сер­ве­ра­ми, раз­мер ката­ло­га на каж­дом сер­ве­ре будет в два раза мень­ше чем сум­мар­ный объ­ем на кли­ен­те. При этом визу­аль­но содер­жи­мое будет идентичное.

Рас­ши­ре­ние тако­го тома не под­дер­жи­ва­ет­ся, так как нель­зя зано­во рас­ще­пить име­ю­щи­е­ся дан­ные на новое чис­ло частей. При выпол­не­нии коман­ды (add-brick) будет выда­но пре­ду­пре­жде­ние о том что все суще­ству­ю­щие дан­ные на рас­ши­ря­е­мом томе могут быть поте­ря­ны. В моем слу­чае так и про­изо­шло. Хотя дан­ные на сер­ве­рах оста­лись, кли­ент же видел лишь пустой ката­лог. В таких слу­ча­ях что бы не рис­ко­вать реко­мен­ду­ет­ся выпол­нить резерв­ную копию дан­ных, создать том с нуж­ны­ми пара­мет­ра­ми зано­во и вер­нуть дан­ные обратно.

Прочие команды

Уда­ле­ние тома

Пред­ва­ри­тель­но его необ­хо­ди­мо остановить:

 а затем мож­но удалить

При этом дан­ные на дис­ках всех сер­ве­ров оста­ют­ся нетронутыми.

==================================================

Монтирование томов

Наи­бо­лее попу­ляр­ные сред­ства для досту­па к Gluster-тому это NFS и соб­ствен­ный клиент(Gluster Native Client)

Под­клю­чить том по NFS мож­но без какой либо под­го­тов­ки системы:

В таком слу­чае, сер­вис Gluster на узлах хра­не­ния под­гру­зит соот­вет­ству­ю­щий транс­ля­тор и будет вести себя как NFS-сер­вер тре­тей версии.

А вот что бы поль­зо­вать­ся кли­ен­том, при­дет­ся пред­ва­ри­тель­но его установить:

на Ubuntu:

 на CentOS:

После уста­нов­ки кли­ен­та, мон­ти­ро­ва­ние тома выгля­дит сле­ду­ю­щим образом:

 Мон­ти­ро­ва­ние с помо­щью fstab

Добав­ля­ем строч­ку в /etc/fstab вида:

gl01.mydomain.com:/<имя_тома> /<каталог_монтирования> glusterfs defaults,_netdev 0 0

При­ме­ча­ние: Выпол­нен­ные тесты про­из­во­ди­тель­но­сти про­то­ко­лов досту­па пока­за­ли, что NFS наи­бо­лее эффек­ти­вен при чте­нии любых дан­ных и запи­си мел­ких фай­лов. Соб­ствен­ный кли­ент пока­зал луч­шую про­из­во­ди­тель­ность при интен­сив­ной запи­си боль­ших фай­лов. Осо­бен­но это вид­но при запи­си с несколь­ких клиентов.

=================================================

Тонкая настройка

При созда­нии ново­го тома, в рабо­чей дирек­то­рии по умол­ча­нию (/var/lib/glusterd/vols) созда­ет­ся под­ди­рек­то­рия с име­нем соот­вет­ству­ю­щим назва­нию тома. В этом ката­ло­ге раз­ме­ща­ет­ся вся слу­жеб­ная инфор­ма­ция о кон­крет­ном томе сре­ди кото­рой несколь­ко фай­лов с рас­ши­ре­ни­ем *.vol. Глав­ный из них это trusted-<имя-тома>-fuse.vol, он опи­сы­ва­ет общие пара­мет­ры тома; инфор­ма­цию о сер­ве­рах, топо­ло­гию репли­ка­ции, и неко­то­рые общие пара­мет­ры исполь­зу­е­мых транс­ля­то­ров. В фай­лах <имя-тома>-<имя-сервера>-<имя-каталога>.vol опи­сы­ва­ют­ся пара­мет­ры транс­ля­то­ров серверов.

Отры­вок vol-фай­ла trusted-r1-fuse.vol:

Каж­дая сек­ция опи­сы­ва­ет опре­де­лен­ные пара­мет­ры транс­ля­то­ра. После­до­ва­тель­ность сек­ций соот­вет­ству­ет цепоч­ке транс­ля­то­ров через кото­рую про­хо­дят дан­ные. Хотя vol-фай­лы могут исполь­зо­вать­ся для изме­не­ния пара­мет­ров томов и сер­ве­ров, на мой взгляд они более полез­ны для иллю­стра­ции рабо­ты ФС изнут­ри и пони­ма­ния коман­ды set.

 Дан­ная коман­да поз­во­ля­ет изме­нять зна­че­ния пара­мет­ров неко­то­рых транс­ля­то­ров на лету.

Напри­мер задать спи­сок кли­ен­тов кото­рым раз­ре­шен доступ к тому:

 или задать наи­бо­лее эффек­тив­ные зна­че­ния пара­мет­ров производительности

 Доступ­ный спи­сок опций, опи­са­ния и зна­че­ния по умол­ча­нию мож­но най­ти на офи­ци­аль­ном сайте.

=============================================

Квоты

Еще одна инте­рес­ная воз­мож­ность кото­рая очень полез­на в облач­ной сре­де, где одним томом может поль­зо­вать­ся мно­же­ство пользователей.

Суще­ству­ет два вида квот: на ката­лог и на том.

Вна­ча­ле необ­хо­ди­мо их вклю­чить для кон­крет­но­го тома:

 Уста­но­вить кво­ту на весь том в 1GB:

 кво­та на кон­крет­ный ката­лог тома:

 Выве­сти спи­сок квот:

Сто­ит заме­тить, что сра­ба­ты­ва­ют кво­ты не момен­таль­но. Напри­мер при сво­бод­ных 50 МБ ино­гда может полу­чить­ся запи­сать файл раз­ме­ром в 200 МБ и обры­ва запи­си не произойдет.