Hei Habr! Untuk perhatian Anda, saya persembahkan terjemahan artikel tersebut oleh Andrew Beekhof.
Banyak orang lebih memilih cluster dua node karena konsepnya lebih sederhana dan juga 33% lebih murah dibandingkan cluster tiga node. Meskipun sangat mungkin untuk menyusun cluster yang baik yang terdiri dari dua node, dalam banyak kasus, karena skenario yang tidak dipertimbangkan, konfigurasi seperti itu akan menimbulkan banyak masalah yang tidak terlihat jelas.
Langkah pertama untuk menciptakan sistem ketersediaan tinggi adalah menemukan dan berupaya menghilangkan setiap titik kegagalan, yang sering disingkat sebagai SPoF (titik kegagalan).
Perlu diingat bahwa tidak mungkin menghilangkan semua kemungkinan risiko downtime pada sistem apa pun. Hal ini berasal dari fakta bahwa pertahanan terhadap risiko adalah dengan memperkenalkan beberapa redundansi, yang mengarah pada peningkatan kompleksitas sistem dan munculnya titik kegagalan baru. Oleh karena itu, pada awalnya kami berkompromi dan fokus pada peristiwa-peristiwa yang terkait dengan titik-titik kegagalan tertentu, dan bukan pada rangkaian peristiwa-peristiwa yang terkait dan, oleh karena itu, semakin kecil kemungkinannya.
Mengingat adanya trade-off, kami tidak hanya mencari SPoF, namun juga menyeimbangkan risiko dan konsekuensi, sehingga kesimpulan mengenai apa yang penting dan apa yang tidak mungkin berbeda untuk setiap penerapan.
Tidak semua orang membutuhkan pemasok listrik alternatif dengan saluran listrik independen. Meskipun paranoia itu membuahkan hasil bagi setidaknya satu pelanggan ketika pemantauan mereka mendeteksi trafo yang rusak. Pelanggan melakukan panggilan telepon untuk mencoba mengingatkan perusahaan listrik sampai trafo yang rusak meledak.
Titik awal yang alami adalah memiliki lebih dari satu node dalam sistem. Namun, sebelum sistem dapat memindahkan layanan ke node yang bertahan setelah kegagalan, sistem biasanya perlu memastikan bahwa layanan yang dipindahkan tidak aktif di tempat lain.
Tidak ada kerugian pada cluster dua node jika kegagalan mengakibatkan kedua node melayani situs web statis yang sama. Namun, hal-hal berubah jika hasilnya adalah kedua belah pihak secara mandiri mengelola antrian pekerjaan bersama atau memberikan akses tulis yang tidak terkoordinasi ke database yang direplikasi atau sistem file bersama.
Oleh karena itu, untuk mencegah kerusakan data akibat kegagalan satu node - kami mengandalkan sesuatu yang disebut "disosiasi" (pagar).
Prinsip disosiasi
Inti dari prinsip disosiasi adalah pertanyaan: dapatkah node yang bersaing menyebabkan kerusakan data? Jika kerusakan data mungkin terjadi, solusi yang baik adalah dengan mengisolasi node dari permintaan masuk dan penyimpanan persisten. Pendekatan yang paling umum untuk disosiasi adalah dengan memutuskan sambungan node yang salah.
Ada dua kategori metode disosiasi, yang akan saya sebutkan lurus и tidak langsung, tapi mereka bisa disebut sama aktif и pasif. Metode langsung mencakup tindakan dari pihak yang masih bertahan, seperti interaksi dengan perangkat IPMI (Intelligent Platform Management Interface) atau iLO (mekanisme untuk mengelola server tanpa adanya akses fisik ke perangkat tersebut), sementara metode tidak langsung mengandalkan kegagalan node untuk mengenali bahwa ia berada dalam keadaan tidak sehat (atau setidaknya mencegah anggota lain untuk pulih) dan memberi sinyal tentang perlunya memutuskan sambungan node yang gagal.
Kuorum membantu ketika menggunakan metode langsung dan tidak langsung.
Disosiasi langsung
Dalam kasus disosiasi langsung, kita dapat menggunakan kuorum untuk mencegah perlombaan disosiasi jika terjadi kegagalan jaringan.
Dengan konsep kuorum, terdapat cukup informasi dalam sistem (bahkan tanpa terhubung ke rekan-rekannya) agar node dapat secara otomatis mengetahui apakah mereka harus memulai disosiasi dan/atau pemulihan.
Tanpa kuorum, kedua belah pihak yang terpecah dalam jaringan akan berasumsi bahwa pihak lain sudah mati dan akan berusaha memisahkan pihak lain. Dalam kasus terburuk, kedua belah pihak berhasil menutup seluruh cluster. Skenario alternatifnya adalah deathmatch, perulangan node tanpa akhir yang muncul, tidak melihat rekannya, melakukan boot ulang, dan memulai pemulihan hanya untuk melakukan boot ulang ketika rekannya mengikuti logika yang sama.
Masalah dengan disasosiasi adalah perangkat yang paling umum digunakan menjadi tidak tersedia karena peristiwa kegagalan yang sama yang ingin kita targetkan untuk pemulihan. Sebagian besar kartu IPMI dan iLO dipasang pada host yang mereka kendalikan dan, secara default, menggunakan jaringan yang sama, yang menyebabkan host target percaya bahwa host lain sedang offline.
Sayangnya, fitur pengoperasian perangkat IPMI dan iLo jarang dipertimbangkan saat membeli peralatan.
Disosiasi tidak langsung
Kuorum juga penting untuk mengelola disasosiasi tidak langsung; jika dilakukan dengan benar, kuorum dapat memungkinkan penyintas berasumsi bahwa node yang hilang akan bertransisi ke keadaan aman setelah jangka waktu tertentu.
Dengan konfigurasi ini, pengatur waktu pengawas perangkat keras direset setiap N detik jika kuorum tidak hilang. Jika pengatur waktu (biasanya beberapa kelipatan N) habis masa berlakunya, maka perangkat akan melakukan pemadaman tanpa batas waktu (bukan mematikan).
Pendekatan ini sangat efektif, namun tanpa kuorum maka tidak akan ada cukup informasi dalam cluster untuk mengelolanya. Tidak mudah untuk membedakan antara pemadaman jaringan dan kegagalan node rekan. Alasan mengapa hal ini penting adalah karena tanpa kemampuan untuk membedakan kedua kasus tersebut, Anda terpaksa memilih perilaku yang sama dalam kedua kasus tersebut.
Masalah dalam memilih satu mode adalah tidak ada tindakan yang memaksimalkan ketersediaan dan mencegah kehilangan data.
- Jika Anda memilih untuk berasumsi bahwa node rekan aktif namun kenyataannya gagal, klaster akan menghentikan layanan yang berjalan secara tidak perlu untuk mengkompensasi hilangnya layanan dari node rekan yang gagal.
- Jika Anda memutuskan untuk berasumsi bahwa sebuah node sedang down, namun itu hanya kegagalan jaringan dan faktanya node jarak jauh tersebut berfungsi, maka yang terbaik adalah Anda mendaftar untuk beberapa rekonsiliasi manual di masa depan dari kumpulan data yang dihasilkan.
Terlepas dari heuristik apa yang Anda gunakan, sangatlah mudah untuk membuat kegagalan yang akan menyebabkan kedua belah pihak gagal atau menyebabkan klaster mematikan node yang masih hidup. Tidak menggunakan kuorum benar-benar menghilangkan salah satu alat paling kuat yang ada dalam gudang senjata cluster.
Jika tidak ada alternatif lain, pendekatan terbaik adalah mengorbankan ketersediaan (di sini penulis mengacu pada teorema CAP). Ketersediaan data yang rusak dalam jumlah besar tidak membantu siapa pun, dan merekonsiliasi kumpulan data yang berbeda secara manual juga tidak menyenangkan.
Jumlah anggota minimum
Kuorum kedengarannya bagus, bukan?
Satu-satunya kekurangannya adalah untuk memilikinya dalam sebuah cluster dengan N anggota, Anda harus memiliki koneksi antara N/2+1 node Anda yang tersisa. Yang tidak mungkin dilakukan dalam cluster dua node setelah satu node gagal.
Yang pada akhirnya membawa kita pada masalah mendasar dengan dua node:
Kuorum tidak masuk akal dalam dua cluster node, dan tanpanya tidak mungkin menentukan tindakan yang memaksimalkan ketersediaan dan mencegah kehilangan data secara andal.
Bahkan dalam sistem dua node yang dihubungkan dengan kabel crossover, tidak mungkin untuk membedakan secara pasti antara pemadaman jaringan dan kegagalan node lainnya. Menonaktifkan salah satu ujung (probabilitasnya, tentu saja, sebanding dengan jarak antar node) akan cukup untuk membatalkan asumsi bahwa kesehatan link sama dengan kesehatan node mitra.
Membuat cluster dua node berfungsi
Terkadang klien tidak dapat atau tidak ingin membeli node ketiga, dan kami terpaksa mencari alternatif lain.
Opsi 1 - Metode disosiasi duplikat
Perangkat iLO atau IPMI sebuah node mewakili titik kegagalan karena, jika gagal, penyintas tidak dapat menggunakannya untuk membawa node ke kondisi aman. Dalam cluster yang terdiri dari 3 node atau lebih, kita dapat memitigasi hal ini dengan menghitung kuorum dan menggunakan pengawas perangkat keras (mekanisme disasosiasi tidak langsung, seperti yang dibahas sebelumnya). Dalam kasus dua node, kita harus menggunakan unit distribusi daya jaringan (PDU).
Setelah kegagalan, penyintas pertama-tama mencoba menghubungi perangkat disasosiasi utama (iLO atau IPMI tertanam). Jika berhasil, pemulihan akan dilanjutkan seperti biasa. Hanya jika perangkat iLO/IPMI gagal maka PDU dapat diakses; jika akses berhasil, pemulihan dapat dilanjutkan.
Pastikan untuk menempatkan PDU pada jaringan yang berbeda dari lalu lintas cluster, jika tidak, kegagalan jaringan tunggal akan memblokir akses ke perangkat disasosiasi dan memblokir pemulihan layanan.
Di sini Anda mungkin bertanya - apakah PDU merupakan satu-satunya titik kegagalan? Tentu saja jawabannya adalah demikian.
Jika risiko ini signifikan bagi Anda, Anda tidak sendirian: sambungkan kedua node ke dua PDU dan beri tahu perangkat lunak pengelompokan untuk menggunakan keduanya saat menghidupkan dan mematikan node. Cluster sekarang tetap aktif jika salah satu PDU mati, dan kegagalan kedua pada PDU lain atau perangkat IPMI akan diperlukan untuk memblokir pemulihan.
Opsi 2 - Menambahkan Arbiter
Dalam beberapa skenario, meskipun metode disasosiasi duplikat secara teknis memungkinkan, namun secara politis sulit dilakukan. Banyak perusahaan ingin memisahkan antara administrator dan pemilik aplikasi, dan administrator jaringan yang sadar akan keamanan tidak selalu antusias untuk berbagi pengaturan akses PDU dengan siapa pun.
Dalam hal ini, alternatif yang disarankan adalah membentuk pihak ketiga yang netral yang dapat melengkapi penghitungan kuorum.
Jika terjadi kegagalan, sebuah node harus dapat melihat gelombang udara dari rekan atau arbiternya untuk memulihkan layanan. Arbiter juga menyertakan fungsi pemutusan jika kedua node dapat melihat arbiter tetapi tidak dapat melihat satu sama lain.
Opsi ini harus digunakan bersama dengan metode disasosiasi tidak langsung, seperti pengatur waktu pengawas perangkat keras, yang dikonfigurasi untuk mematikan mesin jika kehilangan koneksi ke node rekan dan arbiternya. Dengan demikian, penyintas dapat berasumsi bahwa node rekannya akan berada dalam kondisi aman setelah pengatur waktu pengawas perangkat keras berakhir.
Perbedaan praktis antara arbiter dan node ketiga adalah bahwa arbiter memerlukan sumber daya yang jauh lebih sedikit untuk beroperasi dan berpotensi melayani lebih dari satu cluster.
Opsi 3 - Faktor manusia
Pendekatan terakhir adalah bagi para penyintas untuk terus menjalankan layanan apa pun yang telah mereka jalankan, namun tidak memulai layanan baru hingga masalahnya teratasi dengan sendirinya (pemulihan jaringan, reboot node) atau seseorang bertanggung jawab untuk mengonfirmasi secara manual bahwa pihak lain telah mati.
Opsi bonus
Apakah saya menyebutkan Anda dapat menambahkan node ketiga?
Dua rak
Demi argumen, anggap saja saya telah meyakinkan Anda tentang manfaat node ketiga, sekarang kita harus mempertimbangkan susunan fisik node. Jika mereka ditempatkan (dan diberi daya) di rak yang sama, ini juga merupakan SPoF, dan tidak dapat diselesaikan dengan menambahkan rak kedua.
Jika hal ini mengejutkan, pertimbangkan apa yang akan terjadi jika rak dengan dua node gagal, dan bagaimana node yang bertahan akan membedakan antara kegagalan tersebut dan kegagalan jaringan.
Jawaban singkatnya adalah hal itu tidak mungkin, dan sekali lagi kita berurusan dengan semua masalah dalam kasus dua node. Atau yang selamat:
- mengabaikan kuorum dan salah dalam upaya untuk memulai pemulihan selama pemadaman jaringan (kemampuan untuk menyelesaikan disosiasi adalah cerita yang berbeda dan bergantung pada apakah PDU terlibat dan apakah mereka berbagi daya dengan salah satu rak), atau
- menghormati kuorum dan memutus koneksinya sendiri sebelum waktunya ketika node rekannya gagal
Bagaimanapun, dua rak tidak lebih baik dari satu, dan node harus menerima pasokan listrik independen atau didistribusikan ke tiga (atau lebih, tergantung pada berapa banyak node yang Anda miliki) rak.
Dua pusat data
Pada titik ini, pembaca yang tidak lagi menolak risiko mungkin ingin mempertimbangkan pemulihan bencana. Apa yang terjadi jika sebuah asteroid menghantam pusat data yang sama dengan tiga node kita tersebar di tiga rak berbeda? Jelas Hal Buruk, tetapi tergantung kebutuhan Anda, menambahkan pusat data kedua mungkin tidak cukup.
Jika dilakukan dengan benar, pusat data kedua memberi Anda (dan secara wajar demikian) salinan layanan Anda dan datanya yang terkini dan konsisten. Namun, seperti dalam skenario dua simpul, dua rak, tidak ada cukup informasi dalam sistem untuk memastikan ketersediaan maksimum dan mencegah korupsi (atau perbedaan kumpulan data). Bahkan dengan tiga node (atau rak), mendistribusikannya ke dua pusat data saja membuat sistem tidak dapat mengambil keputusan yang tepat jika terjadi peristiwa (yang kini lebih mungkin terjadi) di mana kedua belah pihak tidak dapat berkomunikasi.
Ini tidak berarti bahwa solusi pusat data ganda tidak pernah cocok. Perusahaan sering kali ingin seseorang waspada sebelum mengambil langkah luar biasa dengan pindah ke pusat data cadangan. Ingatlah bahwa jika Anda ingin mengotomatiskan pemadaman, Anda memerlukan pusat data ketiga agar kuorum dapat masuk akal (baik secara langsung atau melalui arbiter), atau Anda akan menemukan cara untuk mematikan seluruh data dengan andal. tengah.
Sumber: www.habr.com