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

Установка Ceph на нодах.

Обла­дая учёт­ной запи­сью ceph на каж­дой ноде и 4ым пунк­том При­го­тов­ле­ния, кото­рый ука­зал, что если исполь­зу­ет­ся про­сто имя ноды, то при исполь­зо­ва­нии ssh под­ра­зу­ме­вать поль­зо­ва­те­ля ceph. Крат­ко коман­да тира­жи­ро­ва­ния ceph на ноде выгля­дит так ceph-deploy install {ceph-node}[{ceph-node} ...]. Подроб­но­сти коман­ды ceph-deploy install -h

Для наших 3 нод мы хотим уста­но­вить релиз mimic и поэто­му если ука­за­ли не его в репо­зи­то­рии то его мож­но поста­вить сле­ду­ю­щей командой;
ceph-deploy install --release mimic ceph2 ceph3 ceph4

Инициализация мониторов.

С новой вер­сии ceph-deploy 1.1.3 и новее, мож­но ини­ци­а­ли­зи­ро­вать мони­то­ры и разо­брать­ся с клю­ча­ми в один шаг -

ceph-deploy mon create-initial, кото­рая зная адре­са мони­то­ров из ceph.conf сде­ла­ет нужное.

Но не лиш­ним будет знать, что до вер­сии 1.1.3 ини­ци­а­ли­зи­ро­вать мони­то­ры и забрать клю­чи мож­но было через 2 раз­дель­ных шага:

• ceph-deploy mon create {ceph-node1} {ceph-node2}
• ceph-deploy gatherkeys {ceph-node}

Так или ина­че долж­ны появит­ся ещё клю­чи в ката­ло­ге /my-cluster
ceph.client.admin.keyring
ceph.bootstrap-osd.keyring
ceph.bootstrap-mds.keyring

Добав­лять в буду­щем ещё мони­то­ры в суще­ству­ю­щий кла­стер мож­но с помощью

ceph-deploy mon add {ceph-node}

Коман­да­ми ceph mon stat и ceph mon dump мож­но посмот­реть теку­щее состо­я­ние мониторов.

 

Для хра­не­ния дан­ных в Ceph нам для при­ме­ра нуж­но доба­вить по одно­му дис­ку для каж­дой ноды. В даль­ней­шем, для обу­че­ния мы доба­вим ещё дис­ки, а сле­до­ва­тель­но и ещё OSD, и поучим­ся уда­лять дис­ки, ими­ти­руя их полом­ки и посмот­рим готов­ность кла­сте­ра к сбоям.

Раз­ра­бот­чи­ки Ceph реко­мен­ду­ют XFS в каче­стве фай­ло­вой систе­мы ваших дис­ков. Про­верь­те, что пакет xfsprogs уста­нов­лен на всех нодах. Через fdisk создай­те раз­дел на новом дис­ке и отфор­ма­ти­руй­те его в XFS коман­дой sudo mkfs.xfs -i size=512 /dev/sdX

Под­клю­чи­те ваш новый диск в /etc/fstab, ука­зав /mnt/disk1 как точ­ку мон­ти­ро­ва­ния. У наших трёх сер­ве­ров - ceph2, ceph3, ceph4 - теперь есть по одно­му дис­ку и он при­мон­ти­ро­ван в /mnt/disk1. Теперь мож­но под­го­то­вить и акти­ви­ро­вать по одно­му OSD на каж­дый диск, кото­рый пока один.

ceph-deploy --overwrite-conf osd prepare ceph2:/mnt/disk1/
ceph-deploy --overwrite-conf osd activate ceph2:/mnt/disk1/

ceph-deploy --overwrite-conf osd prepare ceph3:/mnt/disk1/
ceph-deploy --overwrite-conf osd activate ceph3:/mnt/disk1/

ceph-deploy --overwrite-conf osd prepare ceph4:/mnt/disk1/
ceph-deploy --overwrite-conf osd activate ceph4:/mnt/disk1/


Коман­да­ми ceph osd stat и ceph osd dump мож­но посмот­реть теку­щее состо­я­ние OSD.

 

Описание текущей конфигурации кластера.

На дан­ном эта­пе чуток задер­жим­ся. Мы созда­ли кла­стер, ини­ци­а­ли­зи­ро­ва­ли мони­то­ры и доба­ви­ли на нодах по одно­му OSD. Теперь нуж­но научить­ся опи­сы­вать нами создан­ное в виде кон­фи­гу­ра­ци­он­но­го фай­ла, ибо ceph за нас это­го делать не будет. Дру­ги­ми сло­ва­ми, все наши коман­ды, кото­рые мы вво­ди­ли или будем вво­дить нуж­но фик­си­ро­вать в виде ceph.conf.

Ceph.conf пишет­ся в ini сти­ле. Есть секции:

• [global] - настрой­ки при­ме­нять­ся ко всем демо­нам Ceph.
• [osd] - настрой­ки при­ме­нять­ся ко всем ceph-osd демо­нам и пере­кры­ва­ют global.
• [mon] - настрой­ки при­ме­нять­ся ко всем ceph-mon демо­нам и пере­кры­ва­ют global.
• [mds] - настрой­ки при­ме­нять­ся ко всем ceph-mds демо­нам и пере­кры­ва­ют global.
• [client]- вли­я­ют на кли­ен­тов Ceph, кото­рые исполь­зу­ют Ceph Filesystems или мон­ти­ру­ют Ceph Block Devices.

Если нуж­но что-то ука­зать для кон­крет­но­го демо­на, то сек­ция пишет­ся по тра­ди­ции в чис­ло­вой нота­ции для OSD - [osd.1]. Для мони­то­ров Mon и MDS по тра­ди­ции сек­ции пишут­ся бук­ва­ми - [mon.a] [mds.b].

Итак, при­сту­пим к допол­не­нию наше­го ceph.conf, кото­рый после ceph-deploy new никем не попол­нял­ся, а мы к это вре­ме­ни вве­ли уже доста­точ­но команд для рабо­ты кластера.

Опи­шем наши мони­то­ры,  меняя IP адре­са на свои. Из мини­маль­но необ­хо­ди­мых дирек­тив это host и mon addr.

Мони­то­ры Ceph очень чув­стви­тель­ны к рас­хож­де­нию вре­ме­ни на нодах и ско­рее все­го будет ругань от ceph. Поэто­му стро­кой mon clock drift allowed = 2 я раз­ре­шаю раз­ни­цу в 2 секун­ды, хотя это не заме­на пра­виль­но настро­ен­ной син­хро­ни­за­ции вре­ме­ни меж­ду нода­ми кластера!

Для опи­са­ния пра­виль­ных сек­ций OSD жела­тель­но вызвать команду 

ceph osd tree,

кото­рая выве­дет нам какие номе­ра OSD каким нодам доста­лись, когда мы дела­ли prepare и activate. Пишем сек­ции для OSD.

Кон­тро­ли­руй­те, что­бы ваши сек­ции osd сов­па­да­ли с выво­дом ceph osd tree!

Дирек­ти­ва osd journal ука­зы­ва­ет на рас­по­ло­же­ние жур­на­ла, кото­рый раз­ра­бот­чи­ки Ceph реко­мен­ду­ют раз­ме­щать на отдель­ном SSD дис­ке для боль­шей про­из­во­ди­тель­но­сти кла­сте­ра, но в нашем слу­чае жур­нал лежит на том же дис­ке, что и дан­ные. Про­из­во­ди­тель­но­сти, как вы пони­ма­е­те, наше­му тесто­во­му стен­ду это не добавляет.

Заметь­те, что
osd data = /mnt/disk1/
osd journal = /mnt/disk1/journal
явля­ет­ся общим у наших трёх нод и по логи­ке мож­но было бы выне­сти эти две стро­ки в сек­цию [osd], но в буду­щем мы попро­бу­ем доба­вить допол­ни­тель­ные дис­ки раз­ным нодам в раз­ном коли­че­стве и поэто­му я зара­нее опи­сал сек­ции osd имен­но так.

Тиражирование текущей конфигурации кластера среди нод.

После того, как вы вно­си­те прав­ки в ваш глав­ный кон­фи­гу­ра­ци­он­ный файл ceph.conf, его сле­ду­ет ско­пи­ро­вать на все ваши ноды в /etc/ceph/ и себе на админ­скую ноду тоже! Для это­го суще­ству­ет команда:

ceph-deploy admin, ско­ман­до­вав

ceph-deploy --overwrite-conf admin ceph2 ceph3 ceph4 ceph1 мы при­ка­жем ско­пи­ро­вать акту­аль­ную вер­сию ceph.conf и нуж­ные клю­чи на ноды ceph2, ceph3, ceph4. Ука­зы­ва­ем сами себя (ceph1) для того, что­бы в наш /etc/ceph/ поло­жи­ли ключ, кото­рый будет исполь­зо­вать­ся для досту­па к кла­сте­ру, так как он по умол­ча­нию исполь­зу­ет авто­ри­за­цию. Може­те не ука­зы­вать в коман­де ceph-deploy admin сами себя, а про­сто сде­лать сим­во­ли­че­скую ссыл­ку /etc/ceph/ceph.client.admin.keyring -> /my-cluster/ceph.client.admin.keyring

Есть отдель­ная коман­да для копи­ро­ва­ния кон­фи­гу­ра­ци­он­но­го фай­ла, не заде­вая клю­чи. Это команда

ceph-deploy --overwrite-conf config push {ceph-node}

После того, как кон­фи­гу­ра­ци­он­ный файл рас­ти­ра­жи­ро­ван сре­ди нод, сле­ду­ет пере­за­пу­стить все ceph демоны.

По умол­ча­нию в ceph исполь­зу­ет­ся авто­ри­за­ция меж­ду все­ми демо­на­ми и параметры
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
как раз этим и занимаются.

 

Если у вас воз­ни­ка­ют какие-либо про­бле­мы, то мож­но отклю­чить авто­ри­за­цию, выста­вив пара­мет­ры в none
auth_cluster_required = none
auth_service_required = none
auth_client_required = none
рас­ти­ра­жи­ро­вать новый конф и рестарт­нуть службы.

Если всё сде­ла­но правильно:

• Вре­мя на нодах син­хро­ни­зи­ро­ва­но или укла­ды­ва­ет­ся в раз­ни­цу mon clock drift allowed.
• Клю­чи и конф рас­ти­ра­жи­ро­ва­ны пра­виль­но или пара­мет­ры auth_*_required выстав­ле­ны в none.
• Служ­бы на нодах перезапущены.

То коман­да

 ceph status долж­на выве­сти что-то вро­де такого:

Кла­стер чув­ству­ет себя пре­вос­ход­но - HEALTH_OK. Три мони­то­ра в строю. Три дис­ка в раз­ных нодах обслу­жи­ва­ют­ся тре­мя OSD и они в соста­ве кла­сте­ра (3 in) и рабо­та­ют (3 up). Active+clean под­твер­жда­ет рабо­то­спо­соб­ность кластера.