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

Роли узлов и демоны

Поверх опе­ра­ци­он­ной систе­мы рабо­та­ют демо­ны Ceph, выпол­ня­ю­щие раз­лич­ные роли кла­сте­ра. Таким обра­зом один сер­вер может высту­пать, напри­мер, и в роли мони­то­ра (MON), и в роли хра­ни­ли­ща дан­ных (OSD). А дру­гой сер­вер тем вре­ме­нем может высту­пать в роли хра­ни­ли­ща дан­ных и в роли сер­ве­ра мета­дан­ных (MDS). В боль­ших кла­сте­рах демо­ны запус­ка­ют­ся на отдель­ных маши­нах, но в малых кла­сте­рах, где коли­че­ство сер­ве­ров силь­но огра­ни­че­но, неко­то­рые сер­ве­ра могут выпол­нять сра­зу две или три роли. Зави­сит от мощ­но­сти сер­ве­ра и самих ролей. Разу­ме­ет­ся, все будет рабо­тать шуст­рее на отдель­ных сер­ве­рах, но не все­гда это воз­мож­но реа­ли­зо­вать. Кла­стер мож­но собрать даже из одной маши­ны и все­го одно­го дис­ка, и он будет рабо­тать. Дру­гой раз­го­вор, что это не будет иметь смыс­ла. Сле­ду­ет отме­тить и то, что бла­го­да­ря про­грамм­ной опре­де­ля­е­мо­сти, хра­ни­ли­ще мож­но под­нять даже поверх RAID или iSCSI-устрой­ства, одна­ко в боль­шин­стве слу­ча­ев это тоже не будет иметь смысла.

В доку­мен­та­ции пере­чис­ле­но 3 вида демонов:

• Mon — демон монитора
• OSD — демон хранилища
• MDS — сер­вер мета­дан­ных (необ­хо­дим толь­ко в слу­чае исполь­зо­ва­ния CephFS)

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

Структура хранения

Кла­стер может иметь один или мно­го пулов дан­ных раз­но­го назна­че­ния и с раз­ны­ми настрой­ка­ми. Пулы делят­ся на плей­смент-груп­пы. В плей­смент-груп­пах хра­нят­ся объ­ек­ты, к кото­рым обра­ща­ют­ся кли­ен­ты. На этом логи­че­ский уро­вень закан­чи­ва­ет­ся, и начи­на­ет­ся физи­че­ский, пото­му как за каж­дой плей­смент-груп­пой закреп­лен один глав­ный диск и несколь­ко дис­ков-реплик (сколь­ко имен­но зави­сит от фак­то­ра репли­ка­ции пула). Дру­ги­ми сло­ва­ми, на логи­че­ском уровне объ­ект хра­нит­ся в кон­крет­ной плей­смент-груп­пе, а на физи­че­ском — на дис­ках, кото­рые за ней закреп­ле­ны. При этом дис­ки физи­че­ски могут нахо­дить­ся на раз­ных узлах или даже в раз­ных датацентрах.

Фактор репликации (RF)

Фак­тор репли­ка­ции — это уро­вень избы­точ­но­сти дан­ных. Коли­че­ство копий дан­ных, кото­рое будет хра­нить­ся на раз­ных дис­ках. За этот пара­метр отве­ча­ет пере­мен­ная size. Фак­тор репли­ка­ции может быть раз­ным для каж­до­го пула, и его мож­но менять на лету. Вооб­ще, в Ceph прак­ти­че­ски все пара­мет­ры мож­но менять на лету, мгно­вен­но полу­чая реак­цию кла­сте­ра. Сна­ча­ла у нас может быть size=2, и в этом слу­чае, пул будет хра­нить по две копии одно­го кус­ка дан­ных на раз­ных дис­ках. Этот пара­метр пула мож­но поме­нять на size=3, и в этот же момент кла­стер нач­нет пере­рас­пре­де­лять дан­ные, рас­кла­ды­вая еще одну копию уже име­ю­щих­ся дан­ных по дис­кам, не оста­нав­ли­вая рабо­ту клиентов.

Пул

Пул — это логи­че­ский абстракт­ный кон­тей­нер для орга­ни­за­ции хра­не­ния дан­ных поль­зо­ва­те­ля. Любые дан­ные хра­нят­ся в пуле в виде объ­ек­тов. Несколь­ко пулов могут быть раз­ма­за­ны по одним и тем же дис­кам (а может и по раз­ным, как настро­ить) с помо­щью раз­ных набо­ров плей­смент-групп. Каж­дый пул име­ет ряд настра­и­ва­е­мых пара­мет­ров: фак­тор репли­ка­ции, коли­че­ство плей­смент-групп, мини­маль­ное коли­че­ство живых реплик объ­ек­та, необ­хо­ди­мое для рабо­ты и т. д. Каж­до­му пулу мож­но настро­ить свою поли­ти­ку репли­ка­ции (по горо­дам, дата­цен­трам, стой­кам или даже дис­кам). Напри­мер, пул под хостинг может иметь фак­тор репли­ка­ции size=3, а зоной отка­за будут дата­цен­тры. И тогда Ceph будет гаран­ти­ро­вать, что каж­дый кусо­чек дан­ных име­ет по одной копии в трех дата­цен­трах. Тем вре­ме­нем, пул для вир­ту­аль­ных машин может иметь фак­тор репли­ка­ции size=2, а уров­нем отка­за уже будет сер­вер­ная стой­ка. И в этом слу­чае, кла­стер будет хра­нить толь­ко две копии. При этом, если у нас две стой­ки с хра­ни­ли­щем вир­ту­аль­ных обра­зов в одном дата­цен­тре, и две стой­ки в дру­гом, систе­ма не будет обра­щать вни­ма­ние на дата­цен­тры, и обе копии дан­ных могут уле­теть в один дата­центр, одна­ко гаран­ти­ро­ван­но в раз­ные стой­ки, как мы и хотели.

Мониторы

Мони­тор — это демон, выпол­ня­ю­щий роль коор­ди­на­то­ра, с кото­ро­го начи­на­ет­ся кла­стер. Как толь­ко у нас появ­ля­ет­ся хотя бы один рабо­чий мони­тор, у нас появ­ля­ет­ся Ceph-кла­стер. Мони­тор хра­нит инфор­ма­цию о здо­ро­вье и состо­я­нии кла­сте­ра, обме­ни­ва­ясь раз­лич­ны­ми кар­та­ми с дру­ги­ми мони­то­ра­ми. Кли­ен­ты обра­ща­ют­ся к мони­то­рам, что­бы узнать, на какие OSD писать/читать дан­ные. При раз­во­ра­чи­ва­нии ново­го хра­ни­ли­ща, пер­вым делом созда­ет­ся мони­тор (или несколь­ко). Кла­стер может про­жить на одном мони­то­ре, но реко­мен­ду­ет­ся делать 3 или 5 мони­то­ров, во избе­жа­ние паде­ния всей систе­мы по при­чине паде­ния един­ствен­но­го мони­то­ра. Глав­ное, что­бы их коли­че­ство было нечет­ным, дабы избе­жать ситу­а­ций раз­дво­е­ния созна­ния (split-brain). Мони­то­ры рабо­та­ют в кво­ру­ме, поэто­му если упа­дет боль­ше поло­ви­ны мони­то­ров, кла­стер забло­ки­ру­ет­ся для

 

OSD (Object Storage Device)

OSD — это юнит хра­ни­ли­ща, кото­рый хра­нит сами дан­ные и обра­ба­ты­ва­ет запро­сы кли­ен­тов, обме­ни­ва­ясь дан­ны­ми с дру­ги­ми OSD. Обыч­но это диск. И обыч­но за каж­дый OSD отве­ча­ет отдель­ный OSD-демон, кото­рый может запус­кать­ся на любой машине, на кото­рой уста­нов­лен этот диск. Это вто­рое, что нуж­но добав­лять в кла­стер, при раз­во­ра­чи­ва­нии. Один мони­тор и один OSD — мини­маль­ный набор для того, что­бы под­нять кла­стер и начать им поль­зо­вать­ся. Если на сер­ве­ре кру­тит­ся 12 дис­ков под хра­ни­ли­ще, то на нем будет запу­ще­но столь­ко же OSD-демо­нов. Кли­ен­ты рабо­та­ют непо­сред­ствен­но с сами­ми OSD, минуя узкие места, и дости­гая, тем самым, рас­пре­де­ле­ния нагруз­ки. Кли­ент все­гда запи­сы­ва­ет объ­ект на пер­вич­ный OSD для какой-то плей­смент груп­пы, а уже даль­ше дан­ный OSD син­хро­ни­зи­ру­ет дан­ные с осталь­ны­ми (вто­рич­ны­ми) OSD из этой же плей­смент-груп­пы. Под­твер­жде­ние успеш­ной запи­си может отправ­лять­ся кли­ен­ту сра­зу же после запи­си на пер­вич­ный OSD, а может после дости­же­ния мини­маль­но­го коли­че­ства запи­сей (пара­метр пула min_size). Напри­мер если фак­тор репли­ка­ции size=3, а min_size=2, то под­твер­жде­ние об успеш­ной запи­си отпра­вит­ся кли­ен­ту, когда объ­ект запи­шет­ся хотя бы на два OSD из трех (вклю­чая первичный).

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

Если size=3 и min_size=2: все будет хоро­шо, пока 2 из 3 OSD плей­смент-груп­пы живы. Когда оста­нет­ся все­го лишь 1 живой OSD, кла­стер замо­ро­зит опе­ра­ции дан­ной плей­смент-груп­пы, пока не ожи­вет хотя бы еще один OSD.

Если size=min_size, то плей­смент-груп­па будет бло­ки­ро­вать­ся при паде­нии любо­го OSD, вхо­дя­ще­го в ее состав. А из-за высо­ко­го уров­ня раз­ма­зан­но­сти дан­ных, боль­шин­ство паде­ний хотя бы одно­го OSD будет закан­чи­вать­ся замо­роз­кой все­го или почти все­го кла­сте­ра. Поэто­му пара­метр size все­гда дол­жен быть хотя бы на один пункт боль­ше пара­мет­ра min_size.

Если size=1, кла­стер будет рабо­тать, но смерть любой OSD будет озна­чать без­воз­врат­ную поте­рю дан­ных. Ceph доз­во­ля­ет выста­вить этот пара­метр в еди­ни­цу, но даже если адми­ни­стра­тор дела­ет это с опре­де­лен­ной целью на корот­кое вре­мя, он риск берет на себя.

Диск OSD состо­ит из двух частей: жур­нал и сами дан­ные. Соот­вет­ствен­но, дан­ные сна­ча­ла пишут­ся в жур­нал, затем уже в раз­дел дан­ных. С одной сто­ро­ны это дает допол­ни­тель­ную надеж­ность и неко­то­рую опти­ми­за­цию, а с дру­гой сто­ро­ны — допол­ни­тель­ную опе­ра­цию, кото­рая ска­зы­ва­ет­ся на про­из­во­ди­тель­но­сти. Вопрос про­из­во­ди­тель­но­сти жур­на­лов рас­смот­рим ниже.

Плейсмент-группа (PG)

Плей­смент-груп­пы — это такое свя­зу­ю­щее зве­но меж­ду физи­че­ским уров­нем хра­не­ния (дис­ки) и логи­че­ской орга­ни­за­ци­ей дан­ных (пулы).

Каж­дый объ­ект на логи­че­ском уровне хра­нит­ся в кон­крет­ной плей­смент-груп­пе. На физи­че­ском же уровне, он лежит в нуж­ном коли­че­стве копий на раз­ных физи­че­ских дис­ках, кото­рые в эту плей­смент-груп­пу вклю­че­ны (на самом деле не дис­ки, а OSD, но обыч­но один OSD это и есть один диск, и для про­сто­ты я буду назы­вать это дис­ком, хотя напом­ню, за ним может быть и RAID-мас­сив или iSCSI-устрой­ство). При фак­то­ре репли­ка­ции size=3, каж­дая плей­смент груп­па вклю­ча­ет в себя три дис­ка. Но при этом каж­дый диск нахо­дит­ся во мно­же­стве плей­смент-групп, и для каких то групп он будет пер­вич­ным, для дру­гих — репли­кой. Если OSD вхо­дит, напри­мер, в состав трех плей­смент-групп, то при паде­нии тако­го OSD, плей­смент-груп­пы исклю­чат его из рабо­ты, и на его место каж­дая плей­смент-груп­па выбе­рет рабо­чий OSD и раз­ма­жет по нему дан­ные. С помо­щью дан­но­го меха­низ­ма и дости­га­ет­ся доста­точ­но рав­но­мер­ное рас­пре­де­ле­ние дан­ных и нагруз­ки. Это весь­ма про­стое и одно­вре­мен­но гиб­кое решение.

 

Алгоритм CRUSH

В осно­ве меха­низ­ма децен­тра­ли­за­ции и рас­пре­де­ле­ния лежит так назы­ва­е­мый CRUSH-алго­ритм (Controlled Replicated Under Scalable Hashing), игра­ю­щий важ­ную роль в архи­тек­ту­ре систе­мы. Этот алго­ритм поз­во­ля­ет одно­знач­но опре­де­лить место­по­ло­же­ние объ­ек­та на осно­ве хеша име­ни объ­ек­та и опре­де­лен­ной кар­ты, кото­рая фор­ми­ру­ет­ся исхо­дя из физи­че­ской и логи­че­ской струк­тур кла­сте­ра (дата­цен­тры, залы, ряды, стой­ки, узлы, дис­ки). Кар­та не вклю­ча­ет в себя инфор­ма­цию о место­на­хож­де­нии дан­ных. Путь к дан­ным каж­дый кли­ент опре­де­ля­ет сам, с помо­щью CRUSH-алго­рит­ма и акту­аль­ной кар­ты, кото­рую он пред­ва­ри­тель­но спра­ши­ва­ет у мони­то­ра. При добав­ле­нии дис­ка или паде­нии сер­ве­ра, кар­та обновляется.

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

 

Кеширование

Ceph преду­смат­ри­ва­ет несколь­ко спо­со­бов уве­ли­че­ния про­из­во­ди­тель­но­сти кла­сте­ра мето­да­ми кеширования.

Primary-Affinity
У каж­до­го OSD есть несколь­ко весов, и один из них отве­ча­ет за то, какой OSD в плей­смент-груп­пе будет пер­вич­ным. А, как мы выяс­ни­ли ранее, кли­ент пишет дан­ные имен­но на пер­вич­ный OSD. Так вот, мож­но доба­вить в кла­стер пач­ку SSD дис­ков, сде­лав их все­гда пер­вич­ны­ми, сни­зив вес primary-affinity HDD дис­ков до нуля. И тогда запись будет осу­ществ­лять­ся все­гда сна­ча­ла на быст­рый диск, а затем уже не спе­ша реп­ли­ци­ро­вать­ся на мед­лен­ные. Этот метод самый непра­виль­ный, одна­ко самый про­стой в реа­ли­за­ции. Глав­ный недо­ста­ток в том, что одна копия дан­ных все­гда будет лежать на SSD и потре­бу­ет­ся очень мно­го таких дис­ков, что­бы пол­но­стью покрыть репли­ка­цию. Хотя этот спо­соб кто-то и при­ме­нял на прак­ти­ке, но его я ско­рее упо­мя­нул для того, что­бы рас­ска­зать о воз­мож­но­сти управ­ле­ния при­о­ри­те­том записи.

Вынос жур­на­лов на SSD
Вооб­ще, льви­ная доля про­из­во­ди­тель­но­сти зави­сит от жур­на­лов OSD. Осу­ществ­ляя запись, демон сна­ча­ла пишет дан­ные в жур­нал, а затем в само хра­ни­ли­ще. Это вер­но все­гда, кро­ме слу­ча­ев исполь­зо­ва­ния BTRFS в каче­стве фай­ло­вой систе­мы на OSD, кото­рая может делать это парал­лель­но бла­го­да­ря тех­ни­ке copy-on-write, но я так и не понял, насколь­ко она гото­ва к про­мыш­лен­но­му при­ме­не­нию. На каж­дый OSD идет соб­ствен­ный жур­нал, и по умол­ча­нию он нахо­дит­ся на том же дис­ке, что и сами дан­ные. Одна­ко, жур­на­лы с четы­рёх или пяти дис­ков мож­но выне­сти на один SSD, непло­хо уско­рив опе­ра­ции запи­си. Метод не очень гиб­кий и удоб­ный, но доста­точ­но про­стой. Недо­ста­ток мето­да в том, что при выле­те SSD с жур­на­лом, мы поте­ря­ем сра­зу несколь­ко OSD, что не очень при­ят­но и вно­сит допол­ни­тель­ные труд­но­сти во всю даль­ней­шую под­держ­ку, кото­рая ска­ли­ру­ет­ся с ростом кластера.

Кеш-тиринг
Орто­док­саль­ность дан­но­го мето­да в его гиб­ко­сти и мас­шта­би­ру­е­мо­сти. Схе­ма тако­ва, что у нас есть пул с холод­ны­ми дан­ны­ми и пул с горя­чи­ми. При частом обра­ще­нии к объ­ек­ту, тот как бы нагре­ва­ет­ся и попа­да­ет в горя­чий пул, кото­рый состо­ит из быст­рых SSD. Затем, если объ­ект осты­ва­ет, он попа­да­ет в холод­ный пул с мед­лен­ны­ми HDD. Дан­ная схе­ма поз­во­ля­ет лег­ко менять SSD в горя­чем пуле, кото­рый в свою оче­редь может быть любо­го раз­ме­ра, ибо пара­мет­ры нагре­ва и охла­жде­ния регулируются.

С точки зрения клиента

Ceph предо­став­ля­ет для кли­ен­та раз­лич­ные вари­ан­ты досту­па к дан­ным: блоч­ное устрой­ство, фай­ло­вая систе­ма или объ­ект­ное хранилище.

Блоч­ное устрой­ство (RBD, Rados Block Device)
Ceph поз­во­ля­ет в пуле дан­ных создать блоч­ное устрой­ство RBD, и в даль­ней­шем смон­ти­ро­вать его на опе­ра­ци­он­ных систе­мах, кото­рые это под­дер­жи­ва­ют (на момент напи­са­ния ста­тьи были толь­ко раз­лич­ные дис­три­бу­ти­вы linux, одна­ко FreeBSD и VMWare тоже рабо­та­ют в эту сто­ро­ну). Если кли­ент не под­дер­жи­ва­ет RBD (напри­мер Windows), то мож­но исполь­зо­вать про­ме­жу­точ­ный iSCSI-target с под­держ­кой RBD (напри­мер, tgt-rbd). Кро­ме того, такое блоч­ное устрой­ство под­дер­жи­ва­ет снапшоты.

Фай­ло­вая систе­ма CephFS
Кли­ент может смон­ти­ро­вать фай­ло­вую систе­му CephFS, если у него linux с вер­си­ей ядра 2.6.34 или новее. Если вер­сия ядра стар­ше, то мож­но смон­ти­ро­вать ее через FUSE (Filesystem in User Space). Для того, что­бы кли­ен­ты мог­ли под­клю­чать Ceph как фай­ло­вую систе­му, необ­хо­ди­мо в кла­сте­ре под­нять хотя бы один сер­вер мета­дан­ных (MDS)

Шлюз объ­ек­тов
С помо­щью шлю­за RGW (RADOS Gateway) мож­но кли­ен­там дать воз­мож­ность поль­зо­вать­ся хра­ни­ли­щем через RESTful Amazon S3 или OpenStack Swift сов­ме­сти­мое API.

 

 

Более подробно:

Мони­то­ры Ceph (Ceph Monitors) под­дер­жи­ва­ют глав­ную копию (master copy) кла­стер­ной кар­ты (cluster map), по кото­рой кли­ен­ты Ceph могут опре­де­лить рас­по­ло­же­ние всех мони­то­ров, OSD демо­нов и сер­ве­ров Metadata (MDS). До того как кли­ен­ты нач­нут что-либо писать или читать у OSD или MDS, они долж­ны в первую оче­редь свя­зать­ся с мони­то­ром Ceph.

С теку­щей кла­стер­ной кар­той и алго­рит­мом CRUSH, кли­ен­ты могут вычис­лить рас­по­ло­же­ние любо­го объ­ек­та. Эта спо­соб­ность поз­во­ля­ет кли­ен­там напря­мую общать­ся с OSD, что явля­ет­ся важ­ным аспек­том в архи­тек­ту­ре Ceph и его спо­соб­но­сти к высо­кой доступ­но­сти и производительности.

Глав­ная зада­ча мони­то­ров - под­дер­жи­вать глав­ную копию кла­стер­ной кар­ты. Поми­мо это­го мони­то­ры зани­ма­ют­ся аутен­ти­фи­ка­ци­ей и жур­на­ли­ро­ва­ни­ем. Кла­стер­ная кар­та - это ком­плекс­ная кар­та. Она состо­ит из кар­ты мони­то­ров (monitor map), кар­ты OSD (OSD map), кар­ты плей­смент-груп­пы (placement group map) и кар­ты MDS (metadata server map).

В кла­сте­ре может быть один мони­тор, но он сра­зу ста­нет еди­ной точ­кой отка­за (single-point-of-failure). Для обес­пе­че­ния высо­кой доступ­но­сти нуж­но запус­кать мно­же­ство мони­то­ров на раз­лич­ных нодах. Необя­за­тель­но, но жела­тель­но, что­бы коли­че­ство мони­то­ров в вашем кла­сте­ре было нечёт­ным чис­лом для улуч­ше­ния рабо­ты алго­рит­ма Paxos при сохра­не­нии кво­ру­ма. В иде­а­ле, раз­ра­бот­чи­ки Ceph сове­ту­ют ноды-мони­то­ры не сов­ме­щать с нода­ми OSD, так как мони­то­ры актив­но исполь­зу­ют fsync() и это пагуб­но вли­я­ет на про­из­во­ди­тель­ность OSD.

Сле­ду­ет знать об архи­тек­тур­ной осо­бен­но­сти мони­то­ров. Ceph накла­ды­ва­ет жёст­кие тре­бо­ва­ния согла­со­ва­ния для мони­то­ра, когда тот разыс­ки­ва­ет дру­гие мони­то­ры в кла­сте­ре. Дру­гие демо­ны Ceph и кли­ен­ты исполь­зу­ют кон­фи­гу­ра­ци­он­ный файл для обна­ру­же­ния мони­то­ров, сами мони­то­ры исполь­зу­ют для это­го кар­ту мони­то­ров (monmap), а не кон­фи­гу­ра­ци­он­ный файл. Исполь­зо­ва­ние monmap вме­сто кон­фи­гу­ра­ци­он­но­го фай­ла Ceph поз­во­ля­ет избе­жать оши­бок, кото­рые могут при­ве­сти к раз­ру­ше­нию кла­сте­ра (напри­мер, в резуль­та­те опе­чат­ки в ceph.conf при ука­за­нии адре­са мони­то­ра или пор­та). Тем более, что кон­фи­гу­ра­ци­он­ный файл Ceph обнов­ля­ет­ся и рас­про­стра­ня­ет­ся чело­ве­ком, а не авто­ма­ти­че­ски, и мони­то­ры мог­ли бы не пред­на­ме­рен­но исполь­зо­вать ста­рую вер­сию конфигурации.

 

OSD (object storage daemon) — в каж­дой ноде кла­сте­ра может быть несколь­ко дис­ков и на каж­дый диск нужен отдель­ный демон OSD.

В тра­ди­ци­он­ной архи­тек­ту­ре кли­ент обща­ет­ся с неким цен­траль­ным ком­по­нен­том (шлюз, бро­кер, API и так далее), кото­рый сра­зу ста­но­вит­ся еди­ной точ­кой отка­за этой слож­ной систе­мы. Так же обыч­но цен­траль­ный эле­мент явля­ет­ся буты­лоч­ным гор­лыш­ком в плане про­из­во­ди­тель­но­сти. Ceph избав­ля­ет­ся от цен­траль­но­го эле­мен­та в сво­ей струк­ту­ре, поз­во­ляя кли­ен­там общать­ся с OSD демо­на­ми напря­мую с помо­щью алго­рит­ма CRUSH.

Демо­ны Ceph OSD сохра­ня­ют дан­ные в виде объ­ек­тов в плос­ком про­стран­стве имён, то есть без иерар­хии в виде ката­ло­гов. Объ­ек­ты обла­да­ют иден­ти­фи­ка­то­ра­ми, бинар­ны­ми дан­ны­ми и мета­дан­ны­ми в виде ключ-зна­че­ние, кото­рые исполь­зу­ет MDS сохра­няя вла­дель­ца фай­ла, вре­мя созда­ния, вре­мя моди­фи­ка­ции и так далее. Иден­ти­фи­ка­тор объ­ек­та уни­ка­лен в пре­де­лах кластера.

Демон OSD в соста­ве кла­сте­ра посто­ян­но сооб­ща­ет о сво­ём ста­ту­се - up или down. Если по ряду при­чин OSD демон не сооб­ща­ет о сво­ём состо­я­нии, демон мони­то­ра пери­о­ди­че­ски сам про­ве­ря­ет ста­тус OSD демо­нов и упол­но­мо­чен обнов­лять кла­стер­ную кар­ту и уве­дом­лять дру­гих демо­нов мони­то­ров о состо­я­нии OSD демонов.

Metadata server (MDS) — вспо­мо­га­тель­ный демон для обес­пе­че­ния син­хрон­но­го состо­я­ния фай­лов в точ­ках мон­ти­ро­ва­ния CephFS. В один момент вре­ме­ни рабо­та­ет толь­ко один MDS в пре­де­лах кла­сте­ра, а дру­гие нахо­дят­ся в режи­ме ожи­да­ния и кто-то ста­нет актив­ным, если теку­щий MDS упадёт.