Бид , бид Rook-д хэрхэн/яагаад таалагддаг вэ: энэ нь Кубернетес кластерт хадгалалттай ажиллах ажлыг ихээхэн хялбаршуулдаг. Гэсэн хэдий ч ийм энгийн байдал нь тодорхой бэрхшээлийг дагуулдаг. Шинэ материал нь ийм нарийн төвөгтэй байдлыг өөрсдийгөө илэрхийлэхээс өмнө илүү сайн ойлгоход тусална гэж найдаж байна.
Уншихад илүү сонирхолтой болгохын тулд эхлээд эхэлье үр дагавар кластер дахь таамаглалын асуудал.
"Бүх зүйл алдагдсан!"
Та K8-ийн кластертаа Rook-г тохируулж, ажиллуулж байсан ч энэ нь таны ажилд сэтгэл хангалуун байсан гэж төсөөлөөд үз дээ, гэвч зарим нэг "гайхалтай" мөчид дараах зүйл тохиолдоно:
- Шинэ pods Ceph-ийн RBD зургийг холбож чадахгүй.
- Багууд дуртай
lsblkиdfKubernetes зангилаанууд дээр бүү ажиллуул. Энэ нь автоматаар: зангилаанууд дээр суурилуулсан RBD зургуудтай "ямар нэг зүйл буруу байна" гэсэн үг юм. Би тэдгээрийг уншиж чадахгүй байгаа нь мониторууд байхгүй байгааг харуулж байна... - Тиймээ, кластерт ажиллаж байгаа монитор байхгүй байна. Түүгээр ч барахгүй OSD эсвэл MGR хонхорцог бүхий хонхорцог ч байдаггүй.
Под хэзээ гарсан бэ? rook-ceph-operator? Түүнийг томилогдоод удаагүй байна. Яагаад? Rook-operator шинэ кластер хийхээр шийдлээ... Одоо бид кластер болон доторх өгөгдлийг хэрхэн сэргээх вэ?
Эхлээд Рүүкийн "дотор талыг" сайтар судалж, түүний бүрэлдэхүүн хэсгүүдийг алхам алхмаар сэргээж, илүү урт, сонирхолтой замыг сонгоцгооё. Мэдээжийн хэрэг, илүү богино зөв арга бий: нөөцлөлтийг ашиглах. Та бүхний мэдэж байгаагаар админууд нь нөөцлөлт хийдэггүй, аль хэдийн хийдэг хүмүүс гэсэн хоёр төрөлд хуваагддаг ... Гэхдээ мөрдөн байцаалтын дараа энэ талаар дэлгэрэнгүй.
Жаахан дадлага хийх юм уу урт зам
Эргэн тойрноо харж, мониторуудыг сэргээцгээе
Тиймээс, ConfigMap-ийн жагсаалтыг харцгаая: захиалга хийхэд шаардлагатай зүйлүүд байдаг rook-ceph-config и rook-config-override. Тэд кластерыг амжилттай байрлуулсны дараа гарч ирнэ.
NB: Шинэ хувилбаруудад, хүлээн авсны дараа , ConfigMaps нь кластер байршуулах амжилтын үзүүлэлт байхаа больсон.
Цаашдын үйлдлийг гүйцэтгэхийн тулд бидэнд RBD дүрсийг суулгасан бүх серверүүдийг дахин ачаалах хэрэгтэй.ls /dev/rbd*). Үүнийг sysrq (эсвэл мэдээллийн төв рүү "явган") дамжуулан хийх ёстой. Энэ шаардлага нь суурилуулсан RBD-уудыг салгах даалгавраас үүдэлтэй бөгөөд стандарт дахин ачаалах нь ажиллахгүй (энэ нь тэдгээрийг хэвийн байдлаар салгах оролдлого амжилтгүй болно).
Театр нь өлгүүрээс эхэлдэг бол Ceph кластер нь мониторуудаас эхэлдэг. Тэднийг харцгаая.
Rook нь мониторын самбарт дараах объектуудыг холбодог:
Volumes:
rook-ceph-config:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: rook-ceph-config
rook-ceph-mons-keyring:
Type: Secret (a volume populated by a Secret)
SecretName: rook-ceph-mons-keyring
rook-ceph-log:
Type: HostPath (bare host directory volume)
Path: /var/lib/rook/kube-rook/log
ceph-daemon-data:
Type: HostPath (bare host directory volume)
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) Ямар нууц байгааг харцгаая rook-ceph-mons-keyring:
kind: Secret
data:
keyring: LongBase64EncodedString=Бид кодыг тайлж, админ болон мониторын эрх бүхий ердийн түлхүүрийн зүүлтийг авдаг.
[mon.]
key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
caps mon = "allow *"
[client.admin]
key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
caps mds = "allow *"
caps mon = "allow *"
caps osd = "allow *"
caps mgr = "allow *" Санаж үзье. Одоо түлхүүрийн бөгжийг нууцаар харцгаая rook-ceph-admin-keyring:
kind: Secret
data:
keyring: anotherBase64EncodedString=Үүнд юу байгаа вэ?
[client.admin]
key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
caps mds = "allow *"
caps mon = "allow *"
caps osd = "allow *"
caps mgr = "allow *" Үүнтэй адил. Илүү ихийг харцгаая ... Энд жишээ нь нууц байна rook-ceph-mgr-a-keyring:
[mgr.a]
key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
caps mon = "allow *"
caps mds = "allow *"
caps osd = "allow *" Бид ConfigMap-аас хэд хэдэн нууцыг олж авлаа rook-ceph-mon:
kind: Secret
data:
admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
cluster-name: a3ViZS1yb29r
fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==Энэ бол дээр дурдсан бүх нууцаас гаралтай түлхүүрийн бөгж бүхий анхны жагсаалт юм.
Мэдэгдэж байгаагаар (үзнэ үү dataDirHostPath в ), Rook ийм өгөгдлийг хоёр газар хадгалдаг. Тиймээс, монитор болон OSD бүхий хонгилд суурилуулсан лавлахуудад байрлах түлхүүрийн оосоруудыг үзэхийн тулд зангилаа руу явцгаая. Үүнийг хийхийн тулд бид зангилаанууд дээр олдог /var/lib/rook/mon-a/data/keyring мөн бид харах болно:
# cat /var/lib/rook/mon-a/data/keyring
[mon.]
key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
caps mon = "allow *"Гэнэт л Энд нууц нь өөр болсон - ConfigMap шиг биш.
Админ түлхүүрийн талаар юу хэлэх вэ? Бидэнд бас байгаа:
# 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 *"Энд л асуудал оршиж байна. Ямар нэг алдаа гарсан: кластер дахин үүсгэгдсэн ... гэхдээ бодит байдал дээр тийм биш байсан.
Шинээр бий болсон түлхүүрийн бөгж нь нууцад хадгалагддаг нь тодорхой болж байна үгүй манай хуучин кластераас. Тийм учраас:
- монитороос түлхүүрийн оосорыг файлаас ав
/var/lib/rook/mon-a/data/keyring(эсвэл нөөцөөс); - түлхүүрийн оосорыг нууцаар солих
rook-ceph-mons-keyring; - админаас түлхүүрийн оосорыг бүртгүүлж, ConfigMap-д хяналт тавина
rook-ceph-mon; - монитортой под контроллеруудыг устгана уу.
Гайхамшиг удахгүй ирэхгүй: мониторууд гарч ирэх бөгөөд эхлэх болно. Уучлаарай, эхлэл тавигдлаа!
OSD-г сэргээцгээе
Под руу явцгаая rook-operator: сорилт ceph mon dump бүх мониторууд байрандаа байгааг харуулж байна, мөн ceph -s - тэд чуулгад байгаа. Гэсэн хэдий ч, хэрэв та OSD модыг харвал (ceph osd tree), бид үүнээс хачирхалтай зүйлийг харах болно: OSD-ууд гарч эхэлсэн боловч хоосон байна. Тэднийг бас ямар нэгэн байдлаар сэргээх шаардлагатай болж байна. Гэхдээ яаж?
Энэ хооронд ConfigMaps нь бидэнд маш их хэрэгтэй байгаа зүйлсийг агуулж байна rook-ceph-config и rook-config-override, түүнчлэн бусад олон ConfigMaps гэх мэт нэртэй rook-ceph-osd-$nodename-config. Тэднийг харцгаая:
kind: ConfigMap
data:
osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'Бүх зүйл буруу, бүх зүйл холилдсон!
Операторын подкуудыг тэг болгож, үүсгэсэн Байрлуулалтын подкуудыг OSD-ээс устгаж, эдгээр ConfigMaps-ийг засъя. Гэхдээ хаанаас авах вэ? зөв Зангилаагаар OSD газрын зураг?
- Лавлахуудыг дахин ухаж үзэхийг оролдъё
/mnt/osd[1-2]зангилаанууд дээр - бид тэнд ямар нэгэн зүйлийг барьж чадна гэж найдаж байна. - Каталог дээр
/mnt/osd12 дэд лавлах байдаг:osd0иosd16. Сүүлийнх нь яг ConfigMap (16) дээр заасан ID мөн үү? - Хэмжээг нь шалгаад харцгаая
osd0илүү ихosd16.
Бид ийм дүгнэлтэд хүрч байна osd0 - энэ бол шаардлагатай OSD, гэж заасан /mnt/osd1 ConfigMap дээр (эцэст нь бид ашигладаг .)
Бид алхам алхмаар бүх зангилааг шалгаж, ConfigMaps-ийг засдаг. Бүх зааврын дараа та pod Rook операторыг ажиллуулж, бүртгэлийг нь уншиж болно. Тэдний тухай бүх зүйл гайхалтай:
- Би кластерын оператор;
- Би зангилаанууд дээр диск олсон;
- Би мониторуудыг олсон;
- мониторууд найзууд болсон, өөрөөр хэлбэл. чуулга байгуулсан;
- Би OSD байршуулалтыг эхлүүлж байна...
Rook операторын pod руу дахин орж кластерын эрч хүчийг шалгацгаая... тийм ээ, бид зарим зангилаа дээрх OSD нэрсийн талаархи дүгнэлтэд бага зэрэг буруу байсан! Ямар ч асуудалгүй: бид ConfigMaps-ийг дахин засч, шинэ OSD-ээс шаардлагагүй лавлахуудыг устгаж, удаан хүлээсэн төлөвт хүрлээ. HEALTH_OK!
Усан сан дахь зургуудыг шалгацгаая:
# 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
…Бүх зүйл байрандаа байна - кластер хадгалагдсан!
Би залхуураад нөөцлөлт хийдэг, эсвэл хурдан арга
Хэрэв Rook-д зориулж нөөцлөлт хийсэн бол сэргээх процедур нь илүү хялбар болж, дараахь зүйлийг багтаана.
- Бид байршуулах Rook операторыг тэг хүртэл томруулдаг;
- Бид Rook оператороос бусад бүх байршуулалтыг устгана;
- Бид нөөцөөс бүх нууц болон ConfigMaps-ийг сэргээдэг;
- Лавлахуудын агуулгыг сэргээх
/var/lib/rook/mon-*зангилаанууд дээр; - Бид CRD-г (хэрэв та гэнэт алдсан бол) сэргээдэг
CephCluster,CephFilesystem,CephBlockPool,CephNFS,CephObjectStore; - Байршуулах Rook операторыг 1 болгож багасгая.
Ашигтай зөвлөмжүүд
Нөөцлөлт хийх!
Мөн тэднээс сэргээх шаардлагатай нөхцөл байдлаас зайлсхийхийн тулд:
- Серверүүдийг дахин ачаалахтай холбоотой кластертай томоохон хэмжээний ажил хийхээс өмнө шаардлагагүй зүйл хийхгүйн тулд Rook операторыг тэг болгож томруулна уу.
- Мониторуудад урьдчилан .
- Урьдчилсан байдлаар анхаарлаа хандуулаарай
ROOK_MON_HEALTHCHECK_INTERVALиROOK_MON_OUT_TIMEOUT.
Оронд дүгнэлтийг
Rook нь нэмэлт "давхарга" (Кубернетес дэх хадгалалтыг зохион байгуулах ерөнхий схемд) болохын тулд маш их зүйлийг хялбарчилж, дэд бүтцэд шинэ төвөгтэй байдал, болзошгүй асуудлуудыг нэмж өгдөг гэж маргах нь утгагүй юм. Нэг талаас эдгээр эрсдэл, нөгөө талаас тухайн шийдвэр таны тодорхой тохиолдолд авчрах ашиг хоёрын хооронд тэнцвэртэй, мэдээлэлтэй сонголт хийх л үлдлээ.
Дашрамд хэлэхэд, саяхан Rook баримт бичигт "Одоо байгаа Rook Ceph кластерийг шинэ Kubernetes кластер болгон ашиглах" хэсэг. Энэ нь одоо байгаа өгөгдлийг шинэ Kubernetes кластер руу шилжүүлэх эсвэл нэг шалтгааны улмаас сүйрсэн кластерын ажиллагааг сэргээхийн тулд юу хийх хэрэгтэйг илүү дэлгэрэнгүй тайлбарласан болно.
PS
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «".
- «".
Эх сурвалж: www.habr.com
