Kita
sudah bicara tentang bagaimana / mengapa kita suka Rook: sampai batas tertentu, ini menyederhanakan bekerja dengan penyimpanan di cluster Kubernetes. Namun, dengan kesederhanaan ini beberapa kesulitan datang. Kami berharap bahwa materi baru akan membantu untuk lebih memahami kesulitan seperti itu bahkan sebelum mereka menampakkan diri.
Dan untuk membacanya lebih menarik, kita mulai dengan
konsekuensi dari masalah hipotetis di kluster.
"Semuanya hilang!"
Bayangkan bahwa Anda pernah mengkonfigurasi dan meluncurkan Rook di cluster K8s Anda, ia senang dengan pekerjaannya, tetapi pada saat "luar biasa" hal berikut terjadi:
- Pod baru tidak dapat me-mount Ceph RBDs.
- Perintah seperti
lsblk dan df tidak berfungsi pada host Kubernetes. Ini secara otomatis berarti "ada sesuatu yang salah" dengan gambar RBD yang dipasang di simpul. Saya tidak bisa membacanya, yang menunjukkan tidak dapat diaksesnya monitor ... - Ya, tidak ada monitor operasional di cluster. Selain itu - bahkan tidak ada pod dengan OSD, atau pod dari MGR.
Kapan
rook-ceph-operator pod
rook-ceph-operator diluncurkan? Belum lama ini saat dia dikerahkan. Mengapa Operator-pemula memutuskan untuk membuat cluster baru ... Bagaimana kita sekarang dapat mengembalikan cluster dan data di dalamnya?
Untuk memulai, mari kita pergi ke cara yang
lebih menarik, setelah melakukan penyelidikan mendalam terhadap "internal" Rook dan restorasi komponennya secara bertahap. Tentu saja, ada cara yang benar
lebih pendek : menggunakan cadangan. Seperti yang Anda ketahui, admin dibagi menjadi dua jenis: mereka yang tidak melakukan backup, dan mereka yang sudah melakukannya ... Tetapi lebih lanjut tentang ini setelah penyelidikan.
Sedikit latihan, atau jauh
Lihatlah dan pulihkan monitor
Jadi, mari kita lihat daftar ConfigMaps: ada
rook-ceph-config dan
rook-config-override diperlukan untuk cadangan. Mereka muncul setelah penyebaran cluster berhasil.
NB : Dalam versi baru, setelah adopsi PR ini , ConfigMaps tidak lagi menjadi indikator keberhasilan penyebaran cluster.Untuk melakukan tindakan lebih lanjut, kita perlu mem-boot ulang semua server yang telah memasang gambar RBD (
ls /dev/rbd* ). Itu harus dilakukan melalui sysrq (atau "berjalan kaki" ke pusat data). Persyaratan ini disebabkan oleh tugas melepaskan RBD yang terpasang, yang untuk itu reboot biasa tidak akan berfungsi (itu tidak akan berhasil mencoba melepasnya secara normal).
Teater dimulai dengan gantungan, dan cluster Ceph dimulai dengan monitor. Mari lihat mereka.
Rook memasang entitas berikut di pod monitor:
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)
Mari kita lihat apa rahasia dari
rook-ceph-mons-keyring :
kind: Secret data: keyring: LongBase64EncodedString=
Kami men-decode dan mendapatkan keyring biasa dengan hak admin dan monitor:
[mon.] key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA== caps mon = "allow *" [client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
Ingat. Sekarang lihat keyring di
rook-ceph-admin-keyring rahasia:
kind: Secret data: keyring: anotherBase64EncodedString=
Apa isinya?
[client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
Yang sama. Mari kita lihat lebih lanjut ... Di sini, misalnya, adalah rahasia
rook-ceph-mgr-a-keyring :
[mgr.a] key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew== caps mon = "allow *" caps mds = "allow *" caps osd = "allow *"
Pada akhirnya, kami menemukan beberapa rahasia lagi di ConfigMap
rook-ceph-mon :
kind: Secret data: admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== cluster-name: a3ViZS1yb29r fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg== mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
Dan ini adalah daftar awal dengan keyring, dari mana semua rahasia yang dijelaskan di atas berasal.
Seperti yang Anda ketahui (lihat
dataDirHostPath dalam
dokumentasi ), Rook menyimpan data ini di dua tempat. Oleh karena itu, mari kita pergi ke node untuk melihat keyring'y berbaring di direktori yang dipasang di pod dengan monitor dan OSD. Untuk melakukan ini, cari node
/var/lib/rook/mon-a/data/keyring dan lihat:
# cat /var/lib/rook/mon-a/data/keyring [mon.] key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg== caps mon = "allow *"
Tiba-tiba, rahasianya ternyata berbeda - tidak seperti di ConfigMap.
Bagaimana dengan keyring admin? Kami juga memilikinya:
# 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 *"
Inilah masalahnya. Terjadi kegagalan: kluster diciptakan kembali ... tetapi kenyataannya tidak.
Menjadi jelas bahwa keyring yang baru dibuat disimpan dalam rahasia, dan itu
bukan dari cluster lama kami. Oleh karena itu:
- kami mengambil keyring dari monitor dari file
/var/lib/rook/mon-a/data/keyring (atau dari cadangan); - mengubah keyring di secret
rook-ceph-mons-keyring ; - mendaftar keyring dari admin dan monitor di ConfigMap'e
rook-ceph-mon ; - menghapus pengontrol pod dengan monitor.
Mukjizat tidak akan lama: monitor akan muncul dan mulai. Hore, sebuah awal!
Kembalikan OSD
Kami masuk ke
rook-operator pod pod: memanggil
ceph mon dump menunjukkan bahwa semua monitor ada di tempatnya, dan
ceph -s bahwa mereka berada dalam kuorum. Namun, jika Anda melihat pohon OSD (
ceph osd tree ), Anda akan melihat sesuatu yang aneh di dalamnya: OSD mulai muncul, tetapi semuanya kosong. Ternyata mereka juga perlu dipulihkan. Tapi bagaimana caranya?
Sementara itu,
rook-ceph-config dan
rook-config-override , serta banyak ConfigMaps lainnya dengan nama form
rook-ceph-osd-$nodename-config , muncul di ConfigMap yang sangat dibutuhkan. Mari kita lihat mereka:
kind: ConfigMap data: osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'
Semuanya salah, semuanya tercampur aduk!
Skala pod operator ke nol, hapus pod Deployment yang dihasilkan dari OSD, dan perbaiki ConfigMaps ini. Tapi di mana mendapatkan peta OSD yang
benar dengan node?
- Mari mencoba menggali
/mnt/osd[1-2] pada node lagi - dengan harapan kita dapat menangkap sesuatu di sana. - Ada 2 subdirektori dalam direktori
/mnt/osd1 : osd0 dan osd16 . Yang terakhir hanyalah ID yang ditentukan dalam ConfigMap (16)? - Mari kita
osd0 ukurannya dan lihat bahwa osd0 jauh lebih besar dari osd16 .
Kami menyimpulkan bahwa
osd0 adalah OSD yang diperlukan, yang ditetapkan sebagai
/mnt/osd1 di ConfigMap (karena kami menggunakan
osd berbasis direktori .)
Langkah demi langkah, kami memeriksa semua node dan mengedit ConfigMap. Setelah semua instruksi, Anda dapat menjalankan pod dari operator Rook dan membaca log-nya. Dan semuanya indah di dalamnya:
- Saya adalah operator klaster;
- Saya menemukan drive di node;
- Saya menemukan monitor;
- monitor menjadi teman, mis. membentuk kuorum;
- menjalankan penyebaran OSD ...
Mari kita kembali ke pod dari operator Rook dan memeriksa cluster liveness ... ya, kami membuat sedikit kesalahan dengan kesimpulan tentang nama OSD pada beberapa node! Tidak masalah: mereka sekali lagi memperbaiki ConfigMaps, menghapus direktori tambahan dari OSD baru dan sampai pada keadaan
HEALTH_OK telah lama ditunggu-tunggu!
Periksa gambar di kolam:
Semuanya ada di tempatnya - kluster disimpan!
Saya malas melakukan backup, atau Fast Way
Jika cadangan dilakukan untuk Rook, maka prosedur pemulihan menjadi lebih sederhana dan bermuara sebagai berikut:
- Skala ke nol penyebaran operator Benteng;
- Kami menghapus semua penyebaran kecuali operator Benteng;
- Kami mengembalikan semua rahasia dan ConfigMaps dari cadangan;
- Kembalikan isi
/var/lib/rook/mon-* pada node; - Pulihkan (jika tiba-tiba hilang) CRD
CephCluster , CephFilesystem , CephBlockPool , CephNFS , CephObjectStore ; - Skala penyebaran operator Rook kembali ke 1.
Tips Berguna
Buat cadangan!
Dan untuk menghindari situasi ketika Anda harus pulih dari mereka:
- Sebelum skala besar bekerja dengan cluster, yang terdiri dari reboot server, skala operator Rook ke nol sehingga tidak terlalu banyak.
- Pada monitor, tambahkan nodeAffinity terlebih dahulu.
- Perhatikan pengaturan waktu
ROOK_MON_HEALTHCHECK_INTERVAL dan ROOK_MON_OUT_TIMEOUT .
Alih-alih sebuah kesimpulan
Tidak ada gunanya berargumentasi bahwa Rook, sebagai “lapisan” tambahan (dalam skema umum mengatur penyimpanan di Kubernetes), yang lebih disederhanakan, juga menambah kesulitan baru dan potensi masalah dalam infrastruktur. Masalahnya tetap "kecil": untuk membuat pilihan yang seimbang dan terinformasi antara risiko ini di satu sisi dan manfaat yang dibawa solusi dalam kasus khusus Anda, di sisi lain.
Omong-omong, bagian "Mengadopsi kluster Rook Ceph yang ada ke dalam kluster Kubernet baru" baru-baru
ini ditambahkan ke dokumentasi Rook. Ini menjelaskan secara lebih terperinci apa yang perlu dilakukan untuk memindahkan data yang ada ke kluster Kubernet baru atau mengembalikan kluster yang telah runtuh karena satu dan lain alasan.
PS
Baca juga di blog kami: