🆒 ⏪ 🧙 Cluster dua simpul - iblis secara detail 🔥 ⛓️ 💑

Halo, Habr! Saya mempersembahkan kepada Anda terjemahan artikel "Two Nodes - The Devil is in the Details" oleh Andrew Beekhof.

Banyak orang lebih suka cluster dua simpul karena mereka tampak lebih sederhana secara konseptual, dan juga 33% lebih murah daripada rekan-rekan tiga simpul mereka. Meskipun sangat mungkin untuk merakit cluster yang baik dari dua node, dalam banyak kasus, karena skenario yang tidak diperhitungkan, konfigurasi seperti itu akan menciptakan banyak masalah yang tidak terlihat.

Langkah pertama untuk menciptakan sistem dengan ketersediaan tinggi adalah mencari dan berupaya menghilangkan titik kegagalan individual, sering disingkat SPoF (titik kegagalan tunggal).

Harus diingat bahwa dalam sistem apa pun tidak mungkin untuk menghilangkan semua risiko downtime. Ini mengikuti setidaknya dari fakta bahwa perlindungan risiko yang khas adalah pengenalan beberapa redundansi, yang mengarah pada peningkatan kompleksitas sistem dan munculnya titik kegagalan baru. Oleh karena itu, kami awalnya berkompromi dan fokus pada peristiwa yang terkait dengan titik kegagalan individu, dan bukan pada rantai yang terkait dan, oleh karena itu, semua peristiwa lebih kecil kemungkinannya.

Mengingat trade-off, kami tidak hanya mencari SPoF, tetapi juga menyeimbangkan risiko dan konsekuensi, sebagai hasilnya, kesimpulannya adalah apa yang penting dan apa yang tidak bisa berbeda untuk setiap penyebaran.

Tidak semua orang membutuhkan penyedia listrik alternatif dengan saluran listrik independen. Meskipun paranoia terbayar untuk setidaknya satu klien ketika pemantauan mereka mendeteksi trafo yang salah. Pelanggan menelepon melalui telepon, mencoba memperingatkan perusahaan energi, sampai trafo yang rusak meledak.

Titik awal alami adalah keberadaan lebih dari satu simpul dalam sistem. Namun, sebelum sistem dapat memindahkan layanan ke node yang selamat setelah kegagalan, secara umum, Anda perlu memastikan bahwa layanan yang dipindahkan tidak aktif di tempat lain.

Cluster dua simpul tidak memiliki kelemahan jika, sebagai akibat dari kegagalan, kedua node melayani situs web statis yang sama. Namun, semuanya berubah jika, sebagai akibatnya, kedua belah pihak mengelola sendiri antrian pekerjaan bersama atau menyediakan akses tulis yang tidak terkoordinasi ke database yang direplikasi atau sistem file bersama.

Oleh karena itu, untuk mencegah korupsi data karena kegagalan satu simpul - kami mengandalkan apa yang disebut "disosiasi" (pagar).

Prinsip pemisahan

Prinsip pemisahan didasarkan pada pertanyaan: dapatkah node yang bersaing menyebabkan kerusakan data? Jika korupsi data merupakan skenario yang mungkin terjadi, mengisolasi simpul dari permintaan masuk dan penyimpanan persisten adalah solusi yang baik. Pendekatan yang paling umum untuk melepaskan diri adalah menonaktifkan node yang salah.

Ada dua kategori metode pemisahan yang saya sebut langsung dan tidak langsung , tetapi sama-sama mereka dapat disebut aktif dan pasif. Metode langsung termasuk tindakan dengan cara bertahan dari rekan-rekan, seperti berinteraksi dengan perangkat IPMI (Intelligent Platform Management Interface - antarmuka untuk pemantauan jarak jauh dan mengelola keadaan fisik server) atau iLO (mekanisme manajemen server tanpa adanya akses fisik ke mereka), sementara metode tidak langsung bergantung pada simpul yang gagal untuk entah bagaimana mengenali bahwa ia berada dalam keadaan tidak sehat (atau setidaknya mencegah anggota lainnya pulih) dan memberi sinyal kepada pengawas perangkat keras tentang perlunya memutus sambungan simpul yang gagal.

Kuorum membantu dalam hal menggunakan metode langsung dan tidak langsung.

Disosiasi langsung

Dalam kasus disosiasi langsung, kita dapat menggunakan kuorum untuk mencegah ras pengecualian jika terjadi kegagalan jaringan.

Memiliki konsep kuorum, sistem memiliki informasi yang cukup (bahkan tanpa menghubungkan ke mitranya) sehingga node secara otomatis tahu apakah mereka harus memulai pemisahan dan / atau pemulihan.

Tanpa kuorum, kedua belah pihak berbagi jaringan dengan tepat menganggap bahwa pihak lain sudah mati, dan akan berusaha untuk memisahkan yang lain. Dalam kasus terburuk, kedua belah pihak berhasil memutuskan seluruh cluster. Skenario alternatif adalah deathmatch, simpul tak berujung muncul, tidak melihat rekan-rekan mereka, memuat ulang mereka dan memulai pemulihan hanya untuk reboot ketika rekan mereka mengikuti logika yang sama.

Masalah dengan pengecualian adalah bahwa perangkat yang paling sering digunakan menjadi tidak dapat diakses karena peristiwa kegagalan yang sama yang ingin kita fokuskan untuk pemulihan. Sebagian besar kartu IPMI dan iLO dipasang pada host yang mereka kontrol dan, secara default, menggunakan jaringan yang sama, karena itu node target berasumsi bahwa node lain sedang offline.

Sayangnya, fitur pengoperasian perangkat IPMI dan iLo jarang dipertimbangkan pada saat pembelian peralatan.

Pemisahan Tidak Langsung

Kuorum juga penting untuk mengelola pengecualian tidak langsung, jika semuanya dilakukan dengan benar, kuorum dapat memungkinkan orang yang selamat untuk berasumsi bahwa simpul yang hilang akan memasuki keadaan aman setelah periode waktu tertentu.

Dengan pengaturan ini, timer pengawas perangkat keras me-reset setiap N detik jika kuorum tidak hilang. Jika penghitung waktu (biasanya kelipatan N) berakhir, perangkat melakukan pematian daya yang tidak dapat dilacak (bukan pematian).

Pendekatan ini sangat efektif, tetapi tanpa kuorum, tidak ada cukup informasi di dalam cluster untuk mengelolanya. Tidak mudah untuk menentukan perbedaan antara pemadaman jaringan dan kegagalan host mitra. Alasan mengapa ini penting adalah bahwa tanpa kemampuan untuk membedakan antara dua kasus, Anda dipaksa untuk memilih perilaku yang sama dalam kedua kasus.

Masalah dengan memilih satu mode adalah bahwa tidak ada cara tindakan yang akan memaksimalkan aksesibilitas dan mencegah kehilangan data.

Jika Anda memutuskan untuk berasumsi bahwa simpul mitra aktif, tetapi sebenarnya ada kegagalan, gugus tidak perlu menghentikan layanan yang harus bekerja untuk mengkompensasi hilangnya layanan dari simpul mitra jatuh.
Jika Anda memutuskan untuk berasumsi bahwa node tidak berfungsi, tetapi itu hanya kegagalan jaringan dan node jauh benar-benar berfungsi, maka, paling banter, Anda berlangganan beberapa rekonsiliasi manual mendatang dari set data yang dihasilkan.

Tidak peduli apa heuristik yang Anda gunakan, itu sepele untuk membuat kegagalan yang memaksa kedua belah pihak untuk bekerja, atau memaksa gugus untuk memutuskan sambungan node yang masih hidup. Tidak menggunakan kuorum benar-benar merampas gugus salah satu alat paling ampuh dalam arsenalnya.

Jika tidak ada alternatif lain, pendekatan terbaik adalah mengorbankan aksesibilitas (di sini penulis merujuk pada CAP-teorema). Ketersediaan tinggi data yang rusak tidak membantu siapa pun, dan merekonsiliasi berbagai set data secara manual juga tidak menyenangkan.

Jumlah anggota minimum

Kuorum terdengar hebat, bukan?

Satu-satunya kelemahan adalah bahwa untuk memilikinya dalam sebuah cluster dengan anggota N, Anda harus menjaga koneksi antara N / 2 + 1 dari node Anda. Apa yang tidak mungkin dalam sebuah cluster dengan dua node setelah kegagalan satu node.

Yang akhirnya membawa kita ke masalah mendasar dengan dua simpul: sebuah
kuorum tidak masuk akal dalam dua kelompok simpul, dan tanpa ini tidak mungkin untuk menentukan langkah tindakan yang dapat diandalkan untuk memaksimalkan aksesibilitas dan mencegah kehilangan data
Bahkan dalam sistem dua node yang dihubungkan oleh kabel silang, tidak mungkin untuk akhirnya membedakan antara memutus jaringan dan kegagalan node lain. Memutuskan salah satu ujung (probabilitas yang tentu saja sebanding dengan jarak antar node) akan cukup untuk membantah anggapan bahwa saluran tersebut bekerja sama dengan kesehatan simpul mitra.

Membuat cluster dua node berfungsi

Terkadang klien tidak dapat atau tidak ingin membeli simpul ketiga, dan kami terpaksa mencari alternatif.

Opsi 1 - Metode pemisahan duplikat

Perangkat simpul ILO atau IPMI adalah titik kegagalan karena, jika terjadi kegagalan, penyintas tidak dapat menggunakannya untuk menempatkan simpul dalam keadaan aman. Dalam sekelompok 3 simpul atau lebih, kita dapat mengurangi ini dengan menghitung kuorum dan menggunakan pengawas perangkat keras (mekanisme pelepasan tidak langsung, seperti dibahas sebelumnya). Dalam kasus dua node, kita harus menggunakan switch daya jaringan (unit distribusi daya atau PDU).

Setelah kegagalan, korban pertama kali mencoba menghubungi perangkat pemisahan utama (built-in iLO atau IPMI). Jika ini berhasil, pemulihan berlanjut seperti biasa. Hanya jika terjadi kegagalan perangkat iLO / IPMI, panggilan ke PDU terjadi, jika panggilan berhasil, pemulihan dapat dilanjutkan.

Pastikan untuk menempatkan PDU di jaringan selain dari lalu lintas cluster, jika tidak, satu kegagalan jaringan akan memblokir akses ke kedua perangkat isolasi dan memblokir pemulihan layanan.

Di sini Anda mungkin bertanya - bukankah PDU titik kegagalan tunggal? Yang jawabannya tentu saja.

Jika risiko ini penting bagi Anda, Anda tidak sendirian: hubungkan kedua node ke dua PDU dan perintahkan perangkat lunak cluster untuk menggunakan keduanya ketika menghidupkan dan mematikan node. Sekarang cluster tetap aktif jika satu PDU mati dan kegagalan kedua baik PDU atau perangkat IPMI lain diperlukan untuk memblokir pemulihan.

Opsi 2 - Menambahkan Arbiter

Dalam beberapa skenario, meskipun metode pemisahan duplikat secara teknis dimungkinkan, namun secara politis kompleks. Banyak perusahaan ingin memiliki pemisahan tertentu antara administrator dan pemilik aplikasi, dan administrator jaringan yang sadar akan keamanan tidak selalu antusias menyampaikan parameter akses PDU kepada siapa pun.

Dalam hal ini, alternatif yang disarankan adalah membuat pihak ketiga yang netral yang dapat melengkapi perhitungan kuorum.

Dalam hal terjadi kegagalan, node harus dapat melihat siaran mitra atau arbiter untuk mengembalikan layanan. Arbiter juga mencakup fungsi memutus koneksi, jika kedua node dapat melihat arbiter, tetapi tidak saling melihat.

Pilihan ini harus digunakan bersama dengan metode disosiasi tidak langsung, seperti timer pengawas perangkat keras, yang dikonfigurasi untuk mematikan mesin jika kehilangan koneksi dengan simpul mitra dan arbiter. Dengan demikian, orang yang selamat dapat dengan yakin berasumsi bahwa simpul mitranya akan berada dalam keadaan aman setelah berakhirnya timer pengawas perangkat keras.

Perbedaan praktis antara arbiter dan simpul ketiga adalah bahwa arbiter membutuhkan jauh lebih sedikit sumber daya untuk pekerjaannya dan, berpotensi, dapat melayani lebih dari satu cluster.

Opsi 3 - Faktor Manusia

Pendekatan terakhir adalah bagi penyintas untuk terus melakukan layanan apa pun yang telah mereka lakukan, tetapi tidak memulai yang baru, sampai masalah diselesaikan sendiri (restorasi jaringan, reboot node), atau orang tersebut tidak bertanggung jawab untuk mengkonfirmasi secara manual bahwa sisi lain sudah mati.

Opsi Bonus

Apakah saya menyebutkan bahwa Anda dapat menambahkan simpul ketiga?

Dua rak

Demi argumen, mari kita bayangkan bahwa saya meyakinkan Anda tentang manfaat dari simpul ketiga, sekarang kita harus mempertimbangkan lokasi fisik dari simpul tersebut. Jika mereka ditempatkan (dan diberdayakan) di rak yang sama, ini juga mewakili SPoF, dan yang tidak bisa diselesaikan dengan menambahkan rak kedua.

Jika ini mengejutkan, pertimbangkan apa yang akan terjadi jika rak dengan dua node turun, dan bagaimana node yang bertahan akan membedakan antara kasus ini dan kegagalan jaringan.

Jawaban singkat: ini tidak mungkin, dan sekali lagi kita berurusan dengan semua masalah dalam kasus dua node. Atau selamat:

mengabaikan kuorum dan salah mencoba memulai pemulihan selama pemadaman jaringan (kemungkinan menyelesaikan pemisahan adalah cerita yang terpisah dan tergantung pada apakah PDU terlibat dan apakah mereka berbagi kekuasaan dari salah satu rak), atau
menghormati kuorum dan memutus sendiri sebelum waktunya ketika simpul mitranya gagal

Bagaimanapun, dua rak tidak lebih baik dari satu, dan node harus menerima sumber daya independen, atau didistribusikan di antara tiga (atau lebih, tergantung pada berapa banyak node yang Anda miliki) rak.

Dua pusat data

Pada titik ini, pembaca yang tidak lagi menolak risiko dapat mempertimbangkan untuk pulih dari kecelakaan. Apa yang terjadi ketika asteroid memasuki pusat data tunggal dengan tiga node kami didistribusikan di tiga rak yang berbeda? Jelas, Hal-Hal Buruk, tetapi tergantung pada kebutuhan Anda, menambahkan pusat data kedua mungkin tidak cukup.

Jika semuanya dilakukan dengan benar, pusat data kedua memberi Anda (dan ini masuk akal) salinan terbaru dari layanan Anda dan data mereka. Namun, seperti dalam skenario dengan dua node dan dua rak, sistem tidak memiliki informasi yang cukup untuk memastikan ketersediaan maksimum dan mencegah kerusakan (atau penyimpangan set data). Bahkan jika ada tiga node (atau rak), distribusinya hanya pada dua pusat data membuat sistem tidak dapat diandalkan untuk membuat keputusan yang tepat jika terjadi (sekarang jauh lebih mungkin) peristiwa yang tidak dapat disambungkan oleh kedua pihak.

Ini tidak berarti bahwa solusi dengan dua pusat data tidak pernah cocok. Perusahaan sering ingin orang-orang sadar sebelum mengambil langkah luar biasa ketika pindah ke pusat data cadangan. Hanya perlu diingat bahwa jika Anda ingin mengotomatiskan kegagalan, Anda akan membutuhkan pusat data ketiga sehingga kuorum masuk akal (baik secara langsung atau melalui arbiter), atau Anda akan menemukan cara untuk secara andal menonaktifkan seluruh pusat data.

Cluster dua simpul - iblis secara detail