🥇Bizim əllərimiz boş qalmır: Rook klasterinin K8s-də bərpası

Biz artıq danışmışıq, necə/nəyə görə Rook-u bəyənirik: o, K8s klasterlərində anbarlarla işimizi əhəmiyyətli dərəcədə asanlaşdırır. Ancaq bu sadəliklə müəyyən çətinliklər də gəlir. Ümid edirik ki, yeni material bu çətinlikləri ortaya çıxmamışdan əvvəl daha yaxşı başa düşməyə kömək edəcək.

Və oxumağı daha maraqlı etmək üçün başlayırıq nəticələr hipotetik bir problemdən klasterdə.

"Hamısı itdi!"

Təsəvvür edin ki, bir gün Rook-u K8s klasterinizdə konfiqurasiya edib işə saldınız, o, işindən məmnun qalırdı, lakin bir anda baş verənləri belə təsvir etmək olar:

Yeni pod-lar RBD şəkillərini Ceph-dən qoşula bilmir.
Belə komandalar, məsələn lsblk və df Kubernetes nodlarında işləmir. Bu, avtomatik olaraq RBD görüntüləri ilə nodlara qoşulmuş "nəsə səhvdir" deməkdir. Onları oxumaq mümkün olmur, bu da monitorların əlçatmaz olduğunu göstərir...
Bəli, klasterdə işləyən monitorlar yoxdur. Dahası — heç OSD pod-ları və ya MGR pod-u da yoxdur.

Hansı vaxtda pod işə salındı rook-ceph-operator? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Başlamaq üçün daha uzun və maraqlı bir yol seçərək, Rook-un "daxili hissələri" ilə bağlı düşüncəli bir araşdırma aparacağıq və onun komponentlərini addım-addım bərpa edəcəyik. Təbii ki, daha qısa düzgün bir yol da var: ehtiyat nüsxələrdən istifadə etmək. Məlumdur ki, adminlər iki yerə bölünür: ehtiyat nüsxələr etməyənlər və artıq edənlər... Amma bunlar — araşdırmadan sonra.

Bir az təcrübə, ya da Uzun yol

Göz ataq və monitorları bərpa edək

Beləliklə, ConfigMap-ların siyahısına baxaq: orada ehtiyat saxlama üçün lazım olanlar var rook-ceph-config və rook-config-override. Onlar klasterin uğurlu yerləşməsi zamanı yaranır.

Qeyd: Yeni versiyalarda, qəbul edilməsindən sonra bu PR, ConfigMap-lar klasterin uğurlu yerləşməsi göstəricisi olaraq rolunu dayandırdı.

İrəliləmək üçün bizə RBD görüntülərinin qoşulduğu bütün serverlərin sərt yeniden başlatılması lazımdır (ls /dev/rbd*). Bu, qoşulmuş RBD-ləri ayırmaq tələb etdiyi üçün sysrq (ya da "piyada" mərkəzə) vasitəsilə yerinə yetirilməlidir. Bu tələbin səbəbi bağlı RBD-ləri ayırmaqdır, buna görə standart yenidən başlatma uyğun olmayacaq (onları normal şəkildə ayırmağa cəhd edəcəkdir).

Teatr asılqandan başlayır, Ceph klasteri isə monitorlardan. Gəlin onlara göz atalım.

Rook, monitor pod-da belə varlıqları qoşur:

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (ConfigMap tərəfindən doldurulan bir həcmi)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (bir Secret tərəfindən doldurulan bir həcmi)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (sade ev sahibi katalog həcmi)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (sade ev sahibi katalog həcmi)
   Path:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph from rook-ceph-config (ro)
  /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw)
  /var/log/ceph from rook-ceph-log (rw)

Gəlin, "rook-ceph-mons-keyring" sirrində nə olduğunu nəzərdən keçirək rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Dekod edək və admin və monitorlar üçün hüquqlara sahib adi bir keyring alaq:

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "allow *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Yadda qeyd edək. İndi isə gizli keyring-ə baxaq rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

Orada nə var?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Eynidir. Bir daha baxaq… Məsələn, gizli rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "allow *"
       caps mds = "allow *"
       caps osd = "allow *"

Nəticədə, ConfigMap-də daha bir neçə gizli məlumat tapırıq rook-ceph-mon:

kind: Secret
data:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

Və bu, yuxarıda qeyd olunan bütün gizli məlumatların gəldiyi keyring-lərin ilkin siyahısıdır.

Məlumdur (bax. dataDirHostPath daxilindədir. sənəd), Rook bu məlumatları iki yerdə saxlayır. Beləliklə, gəlin düyünlərə baxaq və monitorlar və OSD ilə montaj olunan kataloglarda olan keyring-ləri görək. Bunun üçün düyünlərdə tapacağıq /var/lib/rook/mon-a/data/keyring və görəcəyik:

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

Birdən burada gizli məlumat fərqli çıxdı — ConfigMap-lərlə eyni deyil.

Bəs admin keyring haqqında nə? O da bizdə var:

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Burada problem baş verir. Bir xəta baş verdi: kluster yenidən quruldu... amma əslində yoxdur.

Aydın olur ki, gizli məlumatlarda yenidən yaradılan keyring-lər saxlanılır, və onlar deyil köhnə klusterdən gəlir. Buna görə:

monitorun keyring-ni fayldan götürürük /var/lib/rook/mon-a/data/keyring (ya da yedəkləmədən);
gizli məlumatdakı keyring-i dəyişirik rook-ceph-mons-keyring;
admin və monitor keyring-ni ConfigMap-də qeyd edirik rook-ceph-mon;
monitorlarla olan pod-ların nəzarətçilərini silirik.

Mucizə uzun çəkməyəcək: monitorlar meydana çıxacaq və işə salınacaq. Uğurlar, başlanğıc qoyduq!

OSD-ni bərpa edəcəyik

pod-a daxil oluruq rook-operator: çağrış ceph mon dump bütün monitorların yerində olduğunu göstərir, amma ceph -s onların kvorumda olduğunu göstərir. Lakin OSD ağacına baxsaq (ceph osd tree), orada qəribə bir şey görəcəyik: OSD-lər meydana çıxdı, amma onlar boşdur. Deməli, onları da bərpa etmək lazımdır. Amma necə?

Bu arada, ConfigMap-lərdə çox lazım olan rook-ceph-config və rook-config-override, eyni zamanda "rook-ceph-osd-$nodename-config" formasında bir çox digər ConfigMap-lər ortaya çıxdı. Baxaq onlara:kind: ConfigMap data: osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

Hər şey bu cür deyil, hər şey qarışıb!

Pod operatorunu sıfırlayaq, OSD ilə pod-ların yaradılmış Deployment-larını silək və bu ConfigMap-ləri düzəltiq. Amma düzgün olanını haradan tapaq

OSD xəritəsi düyünlər üzrə? Yenidən düyünlərin içliyinə baxaq və ümid edirəm ki, orada bir şey tapa bilərik.

iki alt qovluq var: /mnt/osd[1-2] osd0
Kataloqdan /mnt/osd1 osd16 . Sonuncusu — bu ConfigMap-da göstərilən ID-dir (16)? və Ölçülərə görə yoxlayaq və görəcəyik kiən böyükdür
Nəticəyə gəlirik ki . Sonuncusu — bu ConfigMap-da göstərilən ID-dir (16)? — bu ConfigMap-da qeyd olunan lazım olan OSD-dir (çünki biz Ölçülərə görə yoxlayaq və görəcəyik ki.

directory based osd . Sonuncusu — bu ConfigMap-da göstərilən ID-dir (16)? — это и есть нужный OSD, что был указан как /mnt/osd1 в ConfigMap (ведь мы используем directory based osd.)

Addım-addım bütün düyünləri yoxlayırıq və ConfigMap’ları düzəldirik. Bütün təlimatlardan sonra Rook operatorunun pod’unu işə sala bilərik və onun loglarına baxa bilərik. Onlarda hər şey mükəmməldir:

Mən klaster operatoruyam;
Düyünlərdə diskleri tapdım;
Monitorları tapdım;
Monitorlar dostlaşdı, yəni kvorum formalaşdı;
OSD dağıtımlarını başlayıram...

Yenidən Rook operator pod’una girərək klasterin canlılığını yoxlayaq... bəli, bəzi düyünlərdə OSD adları ilə bağlı bir az yanlış çıxmışıq! Narahat olmayın: ConfigMap’ları yenidən düzəltdik, yeni OSD-lərin lazımsız kataloqlarını sildik və gözlənilən vəziyyətə gəldik HEALTH_OK!

Hovuzdakı görüntüləri yoxlayaq:

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

Hər şey yerindədir — klaster xilas oldu!

Tembel bir insan kimi ehtiyat nüsxələr edirəm, ya da Tez yol

Əgər Rook üçün ehtiyat nüsxələr alınmışsa, bərpa prosesi xeyli asanlaşır və aşağıdakıya endirilir:

Rook operatorunun dağıtımını sıfıra çəkirik;
Rook operatoru xaricində bütün dağıtımları silirik;
Bütün gizli məlumatları və ConfigMap’ları ehtiyat nüsxədən bərpa edirik;
Kataloqların məzmununu bərpa edirik /var/lib/rook/mon-* düyünlərdə;
İtmiş olarsa CRD-ni bərpa edirik CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Rook operatorunun dağıtımını 1-ə geri qaytardıq.

Faydali məsləhətlər

Ehtiyat nüsxələri yaradın!

Bunları bərpa etmə ehtimalını azaltmaq üçün:

Klasterlə bağlı kütləvi işlər görməzdən əvvəl, serverləri yenidən başladarkən, Rook operatorunu sıfıra ölçün ki, o, lazımsız əməliyyatlar etməsin.
Monitorlara əvvəlcədən nodeAffinity əlavə edin.
Taymaout konfiqurasiyasına diqqət yetirin ROOK_MON_HEALTHCHECK_INTERVAL ROOK_MON_OUT_TIMEOUT və Rook, Kubernetes-də saxlama arxitekturasının əlavə 'layer'ı olaraq, bir çox şeyi asanlaşdırmaqla yanaşı, infrastrukturda yeni çətinliklər və potensial problemlər də yaradır. Məsələ burada 'kiçik' bir şeydir: bu risklər arasında ağıllı, əsaslı bir seçim etməklə sizin konkret halda getdiyi fayda..