GlusterFS. часть1. теория

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

GlusterFS — это рас­пре­де­лен­ная, парал­лель­ная, линей­но мас­шта­би­ру­е­мая фай­ло­вая систе­ма с воз­мож­но­стью защи­ты от сбо­ев. С помо­щью нее мож­но объ­еди­нить мно­же­ство хра­ни­лищ дан­ных, раз­ме­щен­ных на раз­ных сер­ве­рах (гори­зон­таль­ное мас­шта­би­ро­ва­ние) в одну сете­вую фай­ло­вую систе­му. Так же воз­мож­но объ­еди­не­ние несколь­ких хра­ни­лищ одно­го сер­ве­ра (вер­ти­каль­ное мас­шта­би­ро­ва­ние). А защи­та от сбо­ев дости­га­ет­ся с помо­щью раз­лич­ных поли­тик дуб­ли­ро­ва­ния данных.
GlusterFS исполь­зу­ет меха­низ­мы FUSE (фай­ло­вая систе­ма в поль­зо­ва­тель­ском про­стран­стве) и рабо­та­ет по верх любых POSIX ФС, напри­мер Ext3, Ext4, XFS, Btrfs.
В каче­стве транс­пор­та может исполь­зо­вать­ся Infiniband RDMA и TCP/IP.
В отли­чие от дру­гих рас­пре­де­лён­ных фай­ло­вых систем, таких как Lustre и Ceph, для рабо­ты GlusterFS не тре­бу­ет­ся отдель­ный сер­вер для хра­не­ния мета­дан­ных. В дан­ном слу­чае они хра­нят­ся вме­сте с дан­ны­ми в рас­ши­рен­ных атри­бу­тах фай­лов. Бла­го­да­ря отсут­ствию при­вяз­ки к цен­тра­ли­зо­ван­но­му сер­ве­ру мета-дан­ных ФС предо­став­ля­ет прак­ти­че­ски неогра­ни­чен­ную мас­шта­би­ру­е­мость. Объ­ём хра­ни­ли­ща может изме­рять­ся петабайтами.

Корот­ко о осталь­ных воз­мож­но­стях ФС:

Мож­но исполь­зо­вать любое обо­ру­до­ва­ние (подой­дёт даже ARM);
Рабо­та­ет через стан­дарт­ные про­то­ко­лы NFS, SMB/CIFS или натив­ный клиент;
Авто­ма­ти­че­ское обна­ру­же­ние отка­за отдель­но­го хра­ни­ли­ща (Brick Failure Detection);
Воз­мож­но сжа­тие дан­ных при пере­да­че по сети;
Под­дер­жи­ва­ет­ся шиф­ро­ва­ние дан­ных дис­ко­вых раз­де­лов на сто­роне сер­ве­ра с исполь­зо­ва­ни­ем клю­чей, доступ­ных толь­ко кли­ен­ту. При этом шиф­ру­ет­ся толь­ко содер­жи­мое фай­лов, име­на и мета­дан­ные оста­ют­ся неза­шиф­ро­ван­ны­ми. Шиф­ро­ва­ние непри­ме­ни­мо при исполь­зо­ва­нии NFS;
Опти­ми­зи­ро­ва­на для исполь­зо­ва­ния в каче­стве рас­пре­де­лён­но­го хра­ни­ли­ща обра­зов вир­ту­аль­ных машин;
Инте­гра­ция с QEMU и Samba поз­во­ля­ю­щая орга­ни­зо­вать пря­мой доступ к дан­ным, хра­ни­мым в GlusterFS, без мон­ти­ро­ва­ния раздела;
Может исполь­зо­вать­ся в каче­стве пер­вич­но­го хра­ни­ли­ща в OpenStack;
Меха­низм zerofill поз­во­ля­ет запол­нять нуля­ми новые обра­зы вир­ту­аль­ных машин;
Под­дер­жи­ва­ет­ся асин­хрон­ная гео-репли­ка­ция по моде­ли master–slave. На эту тему я пла­ни­рую под­го­то­вить отдель­ный материал.

При­ме­ча­ние: FUSE — это модуль ядра в ОС UNIX и Linux, кото­рый явля­ет­ся сво­е­го рода посред­ни­ком меж­ду поль­зо­ва­тель­ским про­стран­ством и про­стран­ством ядра. FUSE предо­став­ля­ет интер­фейс ядра (API) с помо­щью кото­ро­го непри­ви­ле­ги­ро­ван­ные про­цес­сы полу­ча­ют доступ к низ­ко­уров­не­вым меха­низ­мам фай­ло­вых систем (посред­ством VFS). Бла­го­да­ря это­му, мож­но напи­сать свою соб­ствен­ную фай­ло­вую систе­му кото­рая будет обла­дать прак­ти­че­ски все­ми воз­мож­но­стя­ми низ­ко­уров­не­вой ФС но рабо­тать с пра­ва­ми обыч­но­го поль­зо­ва­те­ля. Конеч­но же, нали­чие дан­ной про­слой­ки ска­зы­ва­ет­ся на про­из­во­ди­тель­но­сти ФС, но сего­дня даже сред­нее по про­из­во­ди­тель­но­сти обо­ру­до­ва­ние может ком­пен­си­ро­вать дан­ный недо­ста­ток. Наи­бо­лее извест­ные ФС исполь­зу­ю­щие меха­низм FUSE; SSHFS (SSH Filesystem), EncFS(Encrypted Filesystem), NTFS-3G.

GlusterFS сейчас

Рабо­та над GlusterFS была нача­та в 2005 году. В 2011 про­ект был при­об­ре­тен ком­па­ни­ей Red Hat и лег в осно­ву Red Hat Storage Server.

На теку­щий момент код ФС пол­но­стью открыт а про­ект Gluster транс­фор­ми­ро­ван в новое сооб­ще­ство для раз­ра­бот­ки сво­бод­ных про­ек­тов, свя­зан­ных с систе­ма­ми хра­не­ния данных.

Glus­terFS. Архитектура

GlusterFS име­ет кли­ент-сер­вер­ную архи­тек­ту­ру рас­ши­ря­е­мую за счет раз­лич­ных модулей(трансляторов).
Сер­ве­ры здесь — это узлы хра­не­ния (Storage Node). На каж­дом таком узле рабо­та­ет служ­ба glusterd кото­рая предо­став­ля­ет доступ кли­ен­там к локаль­ным фай­ло­вым систе­мам. Одна экс­пор­ти­ру­е­мая фай­ло­вая систе­ма узла хра­не­ния назы­ва­ет­ся «brick» (кир­пич). В рам­ках ста­тьи я так же буду исполь­зо­вать тер­мин «под том». Таких кир­пи­чей на одном сер­ве­ре может быть мно­же­ство. Напри­мер на одном дис­ке или мас­си­ве может быть несколь­ко раз­де­лов с раз­лич­ны­ми фай­ло­вы­ми систе­ма­ми каж­дая из кото­рых будет отдель­ным кирпичом.
Несколь­ко сер­ве­ров объ­еди­ня­ют­ся в кла­стер или пул хра­не­ния дан­ных (Trusted Storage Pool), в тер­ми­но­ло­гии GlusterFS. В рам­ках пула хра­не­ния, под тома на раз­лич­ных узлах объ­еди­ня­ют­ся в логи­че­ские тома(volumes) раз­лич­ной кон­фи­гу­ра­ции. Кли­ент­ская часть, вза­и­мо­дей­ствуя с узла­ми кла­сте­ра, совер­шен­но про­зрач­но для при­ло­же­ний мон­ти­ру­ет логи­че­ский том посред­ством меха­низ­ма FUSE.

На одном ком­пью­те­ре допус­ка­ет­ся рабо­та как сер­вер­ной так и кли­ент­ской части.

Транс­ля­то­ры

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

Стан­дарт­ные трансляторы:

storage – низ­ко­уров­не­вый транс­ля­тор, про­из­во­дит запись и чте­ние дан­ных с локаль­ной фай­ло­вой системы;
cluster – зани­ма­ет­ся репли­ка­ци­ей дан­ных и их рас­пре­де­ле­ни­ем по кирпичам;
debug – предо­став­ля­ет интер­фейс и ста­ти­сти­ку оши­бок для отладки;
encryption – зани­ма­ет­ся шиф­ро­ва­ни­ем и рас­шиф­ров­кой дан­ных на лету;
protocol – про­из­во­дит аутен­ти­фи­ка­цию меж­ду кли­ен­том и сервером;
pеrformance – транс­ля­тор для опти­ми­за­ции производительности(опережающее чте­ние (read-ahead) и запаз­ды­ва­ю­щая запись (write-behind));
system – управ­ле­ние ACL;
scheduler – гло­баль­ный пла­ни­ров­щик опе­ра­ций I/O;
features –кво­ты, филь­тры, и прочее;
bindings – раз­лич­ные API.

Кро­ме это­го есть воз­мож­ность напи­сать свой соб­ствен­ный транс­ля­тор для какой-то осо­бой зада­чи. Напри­мер, есть сто­рон­ние реа­ли­за­ции хра­ни­ли­ща GlusterFS по ана­ло­гии с мас­си­вом RAID5.

Типы томов

Distributed — рас­пре­де­лен­ный том. Тип тома, при кото­ром дан­ные рас­пре­де­ля­ют­ся рав­но­мер­но (в про­из­воль­ном поряд­ке) по всем под томам. Напри­мер пер­вый файл будет запи­сан на пер­вый сер­вер а вто­рой файл — на тре­тий. Тома тако­го типа очень хоро­шо и лег­ко мас­шта­би­ру­ют­ся, но никак не защи­ще­ны сред­ства­ми GlusterFS. Надеж­ность Distributed тома необ­хо­ди­мо обес­пе­чить отдель­но на аппа­рат­ном или про­грамм­ном уровне. В слу­чае выхо­да из строя сер­ве­ра или его дис­ков, дан­ные нахо­дя­щи­е­ся на нем будут не доступ­ны. Самое инте­рес­ное в этой схе­ме, что совер­шен­но непред­ска­зу­е­мо, какие имен­но дан­ные будут потеряны.

Replicated — тома с репли­ка­ци­ей. Ана­ло­гич­но RAID 1. В такой кон­фи­гу­ра­ции одни и те же дан­ные запи­сы­ва­ют­ся мини­мум на два под­то­ма. Более деталь­ное разъ­яс­не­ние будет дано с примерами.
Striped — том с чере­до­ва­ни­ем. Ана­ло­гич­но RAID 0, наи­бо­лее про­из­во­ди­тель­ный и одно­вре­мен­но самый нена­деж­ный тип. Все посту­па­ю­щие дан­ные раз­би­ва­ют­ся на части и парал­лель­но пишут­ся на раз­ные под­то­ма на раз­ных сер­ве­рах. При счи­ты­ва­нии дан­ные в обрат­ном поряд­ке соби­ра­ют­ся и отда­ют­ся кли­ен­ту. В резуль­та­те выхо­да из строя одно­го сер­ве­ра или его дис­ка, том при­хо­дит в негод­ность до вос­ста­нов­ле­ния сбой­но­го узла.
Distributed Striped — рас­пре­де­ле­ние с чере­до­ва­ни­ем. Здесь как и в слу­чае с Distributed-томом дан­ные рас­пре­де­ля­ют­ся меж­ду раз­ны­ми сер­ве­ра­ми при этом они еще раз­би­ва­ют­ся на части меж­ду несколь­ки­ми Striped-томами(См. рис. 1).
Distributed Replicated — то же, что и Distributed Striped, толь­ко вме­сто чере­до­ва­ния будет исполь­зо­вать­ся репли­ка­ция (мм. рис. 2). Этот вари­ант предо­став­ля­ет такую же мас­шта­би­ру­е­мость как и про­стой Distributed том но при этом обла­да­ет повы­шен­ной надеж­но­стью за кото­рую при­дет­ся пла­тить вдвое боль­шим коли­че­ством серверов/дисков. Такая кон­фи­гу­ра­ция реко­мен­ду­ет­ся раз­ра­бот­чи­ка­ми для высо­ко­про­из­во­ди­тель­ных сред, с повы­шен­ны­ми тре­бо­ва­ни­ям к надежности.

Прин­цип рабо­ты Distributed Striped тома

Прин­цип рабо­ты Distributed Replicated тома