ceph-5.0 - ansible role (official)

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

1.Установка
2.Разносим дан­ные по hdd и ssd в CEPH
3.Кеш на SSD в CEPH

Эво­лю­ция дан­ной про­грамм­но-опре­де­ля­е­мой систе­мы хра­не­ния дан­ных пока­зы­ва­ет непло­хие тем­пы и резуль­та­ты. Послед­няя вер­сия дан­но­го ПО на теку­щий момент под назва­ни­ем Octopus хоро­шо под­тя­ну­ла веб интер­фейс. Теперь через гра­фи­че­скую панель мож­но выпол­нять боль­шое коли­че­ство задач, ого­во­рюсь сра­зу, что дале­ко не все. Рань­ше веб интер­фейс CEPH предо­став­лял гораз­до мень­ше воз­мож­но­стей и прак­ти­че­ски все опе­ра­ции про­во­ди­лись через команд­ную стро­ку. Так­же в послед­ней вер­сии доба­ви­лась воз­мож­ность инстал­ля­ции кла­сте­ра с помо­щью ути­ли­ты cephadm, уста­нав­ли­ва­е­мой на первую ноду созда­ва­е­мой систе­мы хра­не­ния. При этом сам основ­ной функ­ци­о­нал хра­ни­ли­ща дан­ных в про­грамм­ном про­дук­те CEPH уже дав­но хоро­шо себя зарекомендовал.

Процесс установки

Самый про­стой спо­соб уста­нов­ки кла­сте­ра CEPH — исполь­зо­ва­ние ansible плей­бу­ка и ansible ролей от самих раз­ра­бот­чи­ков соф­та — ceph-ansible. Для исполь­зо­ва­ния это­го репо­зи­та­рия ска­чи­ва­ем его c github к себе на управ­ля­ю­щий хост с помо­щью команды:

# git clone https://github.com/ceph/ceph-ansible

После это­го пере­хо­дим в дирек­то­рию с локаль­ным репо­зи­та­ри­ем ceph-ansible. Нам нуж­но выбрать ветвь репо­зи­та­рия, в соот­вет­ствии с кото­рой будет про­ис­хо­дить уста­нов­ка кла­сте­ра. Так stable-5.0 исполь­зу­ет­ся для уста­нов­ки послед­не­го ста­биль­но­го на теку­щий момент рели­за CEPH v15.x.x — Octopus. Что­бы выбрать эту вер­сию выпол­ня­ем сле­ду­ю­щую команду:

# git checkout stable-5.0

Далее необ­хо­ди­мо про­ве­рить в фай­ли­ке requirements.txt моду­ли Python, кото­рые долж­ны быть уста­нов­ле­ны в систе­ме на управ­ля­ю­щем хосте, и уста­но­вить их соот­вет­ству­ю­щим обра­зом. К при­ме­ру, это мож­но сде­лать с помо­щью коман­ды pip.

# pip install -r requirements.txt

Теперь необ­хо­ди­мо настро­ить инвен­тарь Ansible в соот­вет­ствии с запла­ни­ро­ван­ным функ­ци­о­на­лом каж­до­го хоста в кла­сте­ре CEPH. Допу­стим, в нашем при­ме­ре мы будем исполь­зо­вать 3 сер­ве­ра (192.168.1.101, 192.168.1.102, 192.168.1.103), на каж­дом из кото­рых долж­ны быть уста­нов­ле­ны сер­ви­сы MONOSDMGRgrafana-server. То есть, каж­дый сер­вер будет выпол­нять роль мони­то­рин­га кла­сте­ра, иметь воз­мож­ность под­клю­чать дис­ки, а так­же обес­пе­чи­вать интер­фейс управ­ле­ния. Для это­го в рабо­чей дирек­то­рии ceph-ansible созда­ем фай­лик inventory_hosts, в кото­ром ука­зы­ва­ем сле­ду­ю­щее содержание.

Как Вы пони­ма­е­те, что­бы плей­бук успеш­но отра­бо­тал на ука­зан­ных хостах, на них дол­жен при­сут­ство­вать ssh rsa пуб­лич­ный ключ с управ­ля­ю­ще­го хоста. Для это­го необ­хо­ди­мо ско­пи­ро­вать этот клю­чик на эти сер­ве­ра, если это еще не было сде­ла­но до этого.

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

# cp ./group_vars/all.yml.sample ./group_vars/all.yml
# cp ./group_vars/mons.yml.sample ./group_vars/mons.yml
# cp ./group_vars/osds.yml.sample ./group_vars/osds.yml

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

Давай­те посмот­рим по наше­му при­ме­ру зна­чи­мое содер­жи­мое фай­лов с пере­мен­ны­ми. Так файл ./group_vars/all.yml выгля­ди сле­ду­ю­щим обра­зом. В нашем слу­чае мы исполь­зу­ем одну под­сеть 192.168.1.0/24 для уда­лен­но­го досту­па к хостам кла­сте­ра, балан­си­ров­ки кла­сте­ра и досту­па к CEPH со сто­ро­ны кли­ен­тов. Поэто­му зна­че­ния пере­мен­ных monitor_address_block, public_network, cluster_network будут идентичными.

Содер­жи­мое фай­ла ./group_vars/mons.yml пред­став­ле­но ниже.

И содер­жа­ние фай­ла ./group_vars/osds.yml далее. В дан­ном слу­чае мы задей­ству­ем для хра­не­ния дан­ных в кла­сте­ре CEPH дис­ки /dev/sdb и /dev/sdc на каж­дом из хостов.

Теперь оста­лось под­ра­бо­тать сам ansible плей­бук, кото­рый про­во­дит саму уста­нов­ку CEPH. Для это­го вна­ча­ле копи­ру­ем его из шаб­ло­на с помо­щью сле­ду­ю­щей команды:

# cp ./site.yml.sample ./site.yml

После это­го редак­ти­ру­ем файл ./site.yml таким обра­зом, что­бы он содер­жал толь­ко коман­ды, реле­вант­ные сер­ви­сам CEPH, кото­рые мы будем уста­нав­ли­вать. В дан­ном слу­чае это MONOSDMGRgrafana-server. Всю осталь­ную инфор­ма­цию из фай­ли­ка удаляем.

Когда все под­го­то­ви­тель­ные рабо­ты завер­ше­ны, запус­ка­ем плей­бук с помо­щью сле­ду­ю­щей коман­ды и полу­ча­ем в резуль­та­те ее завер­ше­ния рабо­та­ю­щий кла­стер CEPH. Вре­мя выпол­не­ния плей­бу­ка может быть поряд­ка 10 — 20 минут.

# ansible-playbook ./site.yml -i ./inventory_hosts

После успеш­но­го завер­ше­ния отра­бот­ки плей­бу­ка, мож­но начи­нать исполь­зо­вать CEPH либо через веб интер­фейс, либо через CLI в SSH.

 

2. Разносим данные по hdd и ssd в CEPH

Кла­стер CEPH по умол­ча­нию пред­став­ля­ет собой один общий мас­сив хра­не­ния дан­ных, в кото­ром объ­ек­ты рас­пре­де­ля­ют­ся по всем име­ю­щим­ся дис­кам в соот­вет­ствии с их весом. Но зача­стую это­го быва­ет недо­ста­точ­но. SSD дис­ки уже дав­но не явля­ют­ся экзо­ти­кой, и исполь­зу­ют­ся на боль­шин­стве сер­ве­ров, да и обыч­ных деск­то­пах и ноут­бу­ках. Как рас­пре­де­лить дан­ные на кла­сте­ре CEPH таким обра­зом, что­бы SSD дис­ки исполь­зо­ва­лись стро­го для опре­де­лен­ных кате­го­рий дан­ных, а HDD для дру­гих категорий?

Настройка

Итак, у нас есть рабо­та­ю­щий кла­стер CEPH, на кото­ром задей­ство­ва­ны дис­ки HDD и SSD под нуж­ды хра­не­ния объ­ек­тов OSD. Дан­ные реко­мен­да­ции акту­аль­ны для послед­ней теку­щей на дан­ный момент вер­сии CEPH — Octopus. Веб интер­фейс CEPH замет­но под­рос в воз­мож­но­стях за послед­нее вре­мя, но для кон­фи­гу­ра­ции поли­тик, кото­рые поз­во­лят раз­но­сить дан­ные, все рав­но при­дет­ся исполь­зо­вать ком­манд­ную стро­ку ceph.

По умол­ча­нию в систе­ме настро­е­на одна crush поли­ти­ка — replicated_rule. Мы созда­дим еще две crush поли­ти­ки с помо­щью сле­ду­ю­щих команд.

# ceph osd crush rule create-replicated ssdrule default host ssd
# ceph osd crush rule create-replicated hddrule default host hdd

Пер­вая поли­ти­ка по име­ни ssdrule зада­ет пра­ви­ла хра­не­ния дан­ных на SSD дис­ках, а вто­рая поли­ти­ка hddrule уже опи­сы­ва­ет исполь­зо­ва­ние шпин­дель­ных дис­ков. В обо­их слу­ча­ях исполь­зу­ет­ся репли­ка­ция для хра­не­ния дан­ных и в каче­стве failure-domain хост кластера.

Что­бы посмот­реть crush поли­ти­ки в кла­сте­ре выпол­ня­ем сле­ду­ю­щую коман­ду. Так мы можем убе­дить­ся, что настро­ен­ные поли­ти­ки успеш­но вид­ны в кластере.

# ceph osd crush rule ls
replicated_rule
ssdrule
hddrule

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

# ceph osd pool create  ssdpool 32 32 ssdrule
# ceph osd pool create  hddpool 32 32 hddrule

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

 

3.Кеш на SSD в CEPH

Систе­ма хра­не­ния CEPH уже дав­но под­дер­жи­ва­ет функ­ци­о­нал кеши­ро­ва­ния HDD пулов с помо­щью дис­ков SSD или NVMe. То есть, сами дан­ные хра­нят­ся на мас­си­вах мед­лен­ных HDD дис­ках, но при этом при опе­ра­тив­ной записи/чтении могут исполь­зо­вать­ся намно­го более быст­рые дис­ки SSD/NVMe. Такой функ­ци­о­нал счи­та­ет­ся одним из базо­вых в доро­гих ком­мер­че­ских сто­ра­джах middle-range уров­ня. В свое вре­мя дол­гое вре­мя зани­мал­ся тако­го типа обо­ру­до­ва­ни­ем. По сво­е­му опы­ту могу ска­зать, что такое кеши­ро­ва­ние явля­ет­ся одним из важ­ных момен­тов при выбо­ре СХД в орга­ни­за­ции. Для Open Source про­дук­та Ceph это важ­ная фича, кото­рая поз­во­ля­ет обес­пе­чить нуж­ную про­из­во­ди­тель­ность общей систе­мы при исполь­зо­ва­нии шпин­дель­ных дис­ков при необходимости.

Как настроить

Будем счи­тать, что у нас уже есть гото­вый кла­стер CEPH вер­сии 15 — Octopus, на кото­ром настро­е­ны, как мини­мум, роли OSD, MONMGR

В систе­ме долж­ны при­сут­ство­вать 2 типа дис­ков — HDD и SSD. Пер­вый тип дис­ков будет исполь­зо­вать­ся для хра­не­ния дан­ных, а вто­рой для кеши­ро­ва­ния. Как извест­но, по умол­ча­нию CEPH пишет дан­ные любо­го пула на все име­ю­щи­е­ся в нали­чии дис­ки. Что­бы раз­не­сти дан­ные по раз­ным типам дис­ков, нуж­но настро­ить соот­вет­ству­ю­щие CRUSH правила

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

Во-пер­вых, необ­хо­ди­мо все име­ю­щи­е­ся систем­ные пулы на кла­сте­ре CEPH пере­ве­сти на исполь­зо­ва­ние HDD дис­ков. Для это­го пере­на­стра­и­ва­ем CRUSH rule для каж­до­го из пулов и ждем, когда про­изой­дет ресин­хро­ни­за­ция. Поте­ри дан­ных при этом не про­ис­хо­дит. При­мер такой коман­ды для пула .rgw.root пред­став­лен ниже.

# ceph osd pool set .rgw.root crush_rule hddrule

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

Во-вто­рых, необ­хо­ди­мо создать CRUSH пра­ви­ло для рас­пре­де­ле­ния дан­ных по ssd дис­кам для кеш слоя. Будем исполь­зо­вать тип пра­ви­ла — replicated rule. С помо­щью него все дан­ные будут реп­ли­ци­ро­вать­ся на 3 хоста наше­го кла­сте­ра. При­мер коман­ды для созда­ния CRUSH rule под назва­ни­ем ssdrule для клас­са дис­ков ssd при­ве­ден ниже.

# ceph osd crush rule create-replicated ssdrule default host ssd

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

# ceph osd pool create ssdcache 32 32 ssdrule

В-чет­вер­тых, настра­и­ва­ет­ся связ­ка меж­ду основ­ным пулом, на кото­ром будут хра­нить­ся дан­ные и горя­чим пулом для кеши­ро­ва­ния. Допу­стим для наше­го при­ме­ра, что пул для хра­не­ния дан­ных назы­ва­ет­ся mypoolhdd. Его мы свя­зы­ва­ем с ssd пулом — ssdcache. В каче­стве режи­ма рабо­ты кеши­ру­ю­ще­го слоя выби­ра­ет­ся — writeback. Это поз­во­ля­ет запи­сы­вать дан­ные на ssd дис­ки и потом уже пере­но­сить инфор­ма­цию с них непо­сред­ствен­но на основ­ной пул.

# ceph osd tier add mypoolhdd ssdcache
# ceph osd tier cache-mode ssdcache writeback
# ceph osd tier set-overlay mypoolhdd ssdcache

В-пятых, для кеши­ру­ю­ще­го слоя необ­хо­ди­мо скон­фи­гу­ри­ро­вать пара­мет­ры попа­да­ния в него. Преж­де все­го мы выби­ра­ем фильтр bloom, кото­рый будет исполь­зо­вать­ся для опред­ле­ния попа­да­ния в кеши­ру­ю­щий слой. Так­же ука­зы­ва­ем коли­че­ствен­ные пара­мет­ры сра­ба­ты­ва­ния кеша — hit_set_count и hit_set_period. Пер­вый из них ука­зы­ва­ет сколь­ко раз нуж­но обра­тить­ся к объ­ек­ту, что­бы он попал в кеш, а вто­рой пока­зы­ва­ет вре­мя жиз­ни объ­ек­та в кеше.

# ceph osd pool set ssdcache hit_set_type bloom
# ceph osd pool set ssdcache hit_set_count 6
# ceph osd pool set ssdcache hit_set_period 3600

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

# ceph osd pool set ssdcache target_max_bytes 1000000000000
# ceph osd pool set ssdcache target_max_objects 102400
# ceph osd pool set ssdcache cache_target_dirty_ratio 0.4
# ceph osd pool set ssdcache cache_target_dirty_high_ratio 0.6
# ceph osd pool set ssdcache cache_target_full_ratio 0.8

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

На дан­ном эта­пе созда­ние тирин­га для орга­ни­за­ция кеши­ру­ю­ще­го слоя на базе ssd дис­ков завер­ше­но. Мож­но под­клю­чать основ­ной hdd пул к выбран­но­му CEPH кли­ен­ту и исполь­зо­вать его по назна­че­нию с уве­ли­чен­ной производительностью.