Използвайки Ceph като мрежово хранилище в проекти с различни натоварвания, можем да срещнем различни задачи, които на пръв поглед не изглеждат прости или тривиални. Например:
- миграция на данни от стар Ceph към нов с частично използване на предишни сървъри в новия клъстер;
- решение на проблема с разпределението на дисковото пространство в Ceph.
Справяйки се с подобни проблеми, ние сме изправени пред необходимостта да премахнем правилно екранното меню без загуба на данни, което е особено важно при работа с големи количества данни. Това ще бъде обсъдено в статията.
Методите, описани по-долу, са подходящи за всяка версия на Ceph. Освен това ще бъде взет предвид фактът, че Ceph може да съхранява голямо количество данни: за да се предотврати загуба на данни и други проблеми, някои действия ще бъдат „разделени“ на няколко други.
Предговор за OSD
Тъй като две от трите обсъждани рецепти са посветени на OSD (), преди да се потопите в практическата част - накратко за това какво е в Ceph и защо е толкова важно.
На първо място, трябва да се каже, че целият клъстер Ceph се състои от много OSD. Колкото повече са, толкова по-голям е свободният обем данни в Ceph. Лесно е да се разбере от тук основна OSD функция: Съхранява обектни данни на Ceph във файловите системи на всички клъстерни възли и осигурява мрежов достъп до тях (за четене, писане и други заявки).
На същото ниво параметрите на репликация се задават чрез копиране на обекти между различни екранни менюта. И тук можете да срещнете различни проблеми, решенията на които ще бъдат разгледани по-долу.
Случай №1. Безопасно премахване на OSD от Ceph клъстер без загуба на данни
Необходимостта от премахване на OSD може да бъде причинена от премахването на сървъра от клъстера - например, за да го замените с друг сървър - което се случи с нас, давайки повод за написването на тази статия. По този начин крайната цел на манипулацията е да се извлекат всички OSD и mons на даден сървър, така че да може да бъде спрян.
За удобство и за да избегнем ситуация, при която при изпълнение на команди сгрешим в посочването на нужното OSD, ще зададем отделна променлива, чиято стойност ще бъде номерът на OSD, което трябва да се изтрие. Да й се обадим ${ID} — тук и по-долу такава променлива замества номера на екранното меню, с което работим.
Нека да разгледаме състоянието преди започване на работа:
root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.46857 root default
-3 0.15619 host hv-1
-5 0.15619 host hv-2
1 ssd 0.15619 osd.1 up 1.00000 1.00000
-7 0.15619 host hv-3
2 ssd 0.15619 osd.2 up 1.00000 1.00000
За да започнете премахване на екранното меню, ще трябва да изпълните плавно reweight върху него до нула. По този начин намаляваме количеството данни в екранното меню, като го балансираме с други екранни менюта. За да направите това, изпълнете следните команди:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78... и така до нула.
Изисква се плавно балансиранеза да не загубите данни. Това е особено вярно, ако екранното меню съдържа голямо количество данни. За да се уверите, че след изпълнение на командите reweight всичко мина добре, можете да го завършите ceph -s или стартирайте в отделен терминален прозорец ceph -w за да наблюдавате промените в реално време.
Когато екранното меню е „изпразнено“, можете да продължите със стандартната операция за премахването му. За да направите това, прехвърлете желаното OSD в състоянието down:
ceph osd down osd.${ID}Нека "издърпаме" OSD от клъстера:
ceph osd out osd.${ID}Нека спрем OSD услугата и демонтираме нейния дял във FS:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}Премахване на OSD от :
ceph osd crush remove osd.${ID}Нека изтрием OSD потребителя:
ceph auth del osd.${ID}И накрая, нека премахнем самото OSD:
ceph osd rm osd.${ID}Внимание: Ако използвате Ceph Luminous версия или по-нова, тогава горните стъпки за премахване на OSD могат да бъдат намалени до две команди:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
Ако след изпълнение на описаните по-горе стъпки изпълните командата ceph osd tree, тогава трябва да е ясно, че на сървъра, където е извършена работата, вече няма OSD, за които са извършени горните операции:
root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.46857 root default
-3 0.15619 host hv-1
-5 0.15619 host hv-2
-7 0.15619 host hv-3
2 ssd 0.15619 osd.2 up 1.00000 1.00000
По пътя имайте предвид, че състоянието на клъстера Ceph ще премине HEALTH_WARN, а също така ще видим намаляване на броя на екранните менюта и количеството налично дисково пространство.
По-долу ще бъдат описани стъпките, които ще бъдат необходими, ако искате да спрете напълно сървъра и съответно да го премахнете от Ceph. В този случай е важно да запомните това Преди да изключите сървъра, трябва да премахнете всички екранни менюта на този сървър.
Ако на този сървър не са останали повече OSD, тогава след премахването им трябва да изключите сървъра от OSD картата hv-2като изпълните следната команда:
ceph osd crush rm hv-2
Изтрий mon от сървъра hv-2като изпълните командата по-долу на друг сървър (т.е. в този случай на hv-1):
ceph-deploy mon destroy hv-2След това можете да спрете сървъра и да започнете последващи действия (повторно разполагане и т.н.).
Случай № 2. Разпределение на дисковото пространство във вече създаден Ceph клъстер
Ще започна втората история с предговор за PG (). Основната роля на PG в Ceph е предимно да агрегира Ceph обекти и допълнително да ги репликира в OSD. Формулата, с която можете да изчислите необходимото количество PG, е в Ceph документация. Този въпрос също е дискутиран там с конкретни примери.
И така: един от често срещаните проблеми при използване на Ceph е небалансираният брой OSD и PG между пуловете в Ceph.
Първо, поради това може да възникне ситуация, когато твърде много PG са посочени в малък пул, което по същество е нерационално използване на дисковото пространство в клъстера. Второ, на практика има по-сериозен проблем: препълване на данни в едно от екранните менюта. Това води до преминаване на клъстера към състоянието HEALTH_WARN, и тогава HEALTH_ERR. Причината за това е, че Ceph, когато изчислява наличното количество данни (можете да го намерите от MAX AVAIL в командния изход ceph df за всеки пул поотделно) се базира на количеството налични данни в OSD. Ако няма достатъчно място в поне едно OSD, не могат да се записват повече данни, докато данните не бъдат правилно разпределени между всички OSD.
Струва си да се изясни, че тези проблеми до голяма степен се решават на етапа на конфигурация на клъстер Ceph. Един от инструментите, които можете да използвате е . С негова помощ ясно се изчислява необходимото количество PG. Можете обаче да прибягвате до него и в ситуация, в която клъстерът Ceph вече конфигуриран неправилно. Тук си струва да изясним, че като част от работата по корекцията най-вероятно ще трябва да намалите броя на PG и тази функция не е налична в по-старите версии на Ceph (тя се появи само във версия ).
И така, нека си представим следната картина: клъстерът има статус HEALTH_WARN поради липса на място в едно от екранните менюта. Това ще бъде указано с грешка HEALTH_WARN: 1 near full osd. По-долу е даден алгоритъм за излизане от тази ситуация.
На първо място, трябва да разпределите наличните данни между останалите екранни менюта. Вече извършихме подобна операция в първия случай, когато „източихме“ възела - с единствената разлика, че сега ще трябва леко да намалим reweight. Например до 0.95:
ceph osd reweight osd.${ID} 0.95Това освобождава дисково пространство в екранното меню и коригира грешката в изправността на ceph. Въпреки това, както вече беше споменато, този проблем възниква главно поради неправилна конфигурация на Ceph в началните етапи: много е важно да направите преконфигурация, така че да не се появява в бъдеще.
В нашия конкретен случай всичко се сведе до:
- твърде висока стойност
replication_countв един от басейните, - твърде много PG в един басейн и твърде малко в друг.
Нека използваме вече споменатия калкулатор. Ясно показва какво трябва да се въведе и по принцип няма нищо сложно. След като зададем необходимите параметри, получаваме следните препоръки:
Внимание: Ако настройвате Ceph клъстер от нулата, друга полезна функция на калкулатора е генерирането на команди, които ще създадат пулове от нулата с параметрите, посочени в таблицата.
Последната колона ви помага да навигирате - Предложен брой PG. В нашия случай вторият също е полезен, където е посочен параметърът за репликация, тъй като решихме да променим множителя на репликация.
Така че, първо трябва да промените параметрите на репликация - това си струва да направите първо, тъй като чрез намаляване на множителя ще освободим дисково пространство. Докато командата се изпълнява, ще забележите, че наличното дисково пространство ще се увеличи:
ceph osd pool $pool_name set $replication_size
И след приключването му, ние променяме стойностите на параметрите pg_num и pgp_num както следва:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_numberВажно е: трябва да променим броя на PG последователно във всеки пул и да не променяме стойностите в други пулове, докато предупрежденията не изчезнат „Влошен излишък на данни“ и "n-брой деградирани страници".
Можете също да проверите дали всичко е минало добре, като използвате изходите на командата ceph health detail и ceph -s.
Случай №3. Мигриране на виртуална машина от LVM към Ceph RBD
В ситуация, в която даден проект използва виртуални машини, инсталирани на наети голи сървъри, често възниква проблемът с устойчивото на грешки хранилище. Също така е много желателно в това хранилище да има достатъчно място... Друга често срещана ситуация: има виртуална машина с локално хранилище на сървъра и трябва да разширите диска, но няма къде да отидете, защото няма остава свободно дисково пространство на сървъра.
Проблемът може да бъде решен по различни начини - например чрез мигриране към друг сървър (ако има такъв) или добавяне на нови дискове към сървъра. Но не винаги е възможно да се направи това, така че мигрирането от LVM към Ceph може да бъде отлично решение на този проблем. Избирайки тази опция, ние също опростяваме по-нататъшния процес на миграция между сървъри, тъй като няма да е необходимо да премествате локално хранилище от един хипервизор към друг. Единствената уловка е, че ще трябва да спрете VM, докато работата се извършва.
Следната рецепта е взета от , чиито инструкции са тествани в действие. Между другото, методът за безпроблемна миграция също е описан там, но в нашия случай просто не беше необходимо, така че не го проверихме. Ако това е критично за вашия проект, ще се радваме да научим за резултатите в коментарите.
Да преминем към практическата част. В примера използваме virsh и съответно libvirt. Първо се уверете, че пулът Ceph, към който ще бъдат мигрирани данните, е свързан с libvirt:
virsh pool-dumpxml $ceph_poolОписанието на пула трябва да съдържа данни за връзка с Ceph с данни за оторизация.
Следващата стъпка е LVM изображението да се преобразува в Ceph RBD. Времето за изпълнение зависи преди всичко от размера на изображението:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_nameСлед преобразуването ще остане LVM изображение, което ще бъде полезно, ако мигрирането на VM към RBD е неуспешно и трябва да върнете промените назад. Освен това, за да можете бързо да върнете промените назад, нека направим резервно копие на конфигурационния файл на виртуалната машина:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
... и редактирайте оригинала (vm_name.xml). Нека намерим блок с описание на диска (започва с реда <disk type='file' device='disk'> и завършва с </disk>) и го редуцирайте до следния вид:
<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
<secret type='ceph' uuid='sec-ret-uu-id'/>
</auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
<host name='10.0.0.1' port='6789'/>
<host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>Нека да разгледаме някои подробности:
- Към протокола
sourceе посочен адресът към хранилището в Ceph RBD (това е адресът, указващ името на пула Ceph и изображението на RBD, което беше определено на първия етап). - В блока
secretе посочен типceph, както и UUID на секрета за свързване с него. Неговият uuid може да бъде намерен с помощта на командатаvirsh secret-list. - В блока
hostпосочени са адреси към Ceph мониторите.
След като редактирате конфигурационния файл и завършите конвертирането на LVM в RBD, можете да приложите модифицирания конфигурационен файл и да стартирате виртуалната машина:
virsh define $vm_name.xml
virsh start $vm_name
Време е да проверите дали виртуалната машина е стартирана правилно: можете да разберете, например, като се свържете с нея чрез SSH или чрез virsh.
Ако виртуалната машина работи правилно и не сте открили други проблеми, тогава можете да изтриете LVM изображението, което вече не се използва:
lvremove main/$vm_image_nameЗаключение
Срещнахме всички описани случаи на практика - надяваме се, че инструкциите ще помогнат на други администратори да решат подобни проблеми. Ако имате коментари или други подобни истории от вашия опит с Ceph, ще се радваме да ги видим в коментарите!
PS
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «".
Източник: www.habr.com