Seperti yang telah kita bahas, dalam Ketersediaan Tinggi lingkungan cluster ada satu node aktif dan satu atau lebih node siaga yang akan mengambil alih layanan ketika node aktif gagal atau berhenti merespons.

Ini terdengar seperti asumsi yang masuk akal sampai lapisan jaringan antara node dipertimbangkan. Bagaimana jika jalur jaringan antara node turun?

Tidak ada node yang sekarang dapat berkomunikasi dengan yang lain dan dalam situasi ini server siaga dapat mempromosikan dirinya sendiri untuk menjadi server aktif atas dasar bahwa ia percaya bahwa node aktif telah gagal. Hal ini menyebabkan kedua node menjadi 'aktif' karena masing-masing akan melihat yang lain mati. Akibatnya, integritas dan konsistensi data terganggu karena data pada kedua node akan berubah. Ini disebut sebagai "Otak Terbelah" .

Untuk menghindari skenario otak terbelah, simpul Kuorum (juga disebut sebagai 'Saksi') harus dipasang di dalam cluster. Menambahkan node kuorum (ke sebuah cluster yang terdiri dari jumlah node yang genap) menciptakan jumlah node yang ganjil (3, 5, 7, dll.), dengan voting node untuk memutuskan mana yang harus bertindak sebagai node aktif dalam cluster.

Pada contoh di bawah, rak server yang berisi Node B telah hilang LAN konektivitas. Dalam skenario ini, melalui penambahan node ke-3 ke lingkungan cluster, sistem masih dapat menentukan node mana yang harus menjadi node aktif.

Fungsi kuorum/Saksi disertakan dalam SIOS Suite Perlindungan. Saat instalasi, Kuorum / Saksi dipilih di semua node (tidak hanya node kuorum) dan jalur komunikasi ditentukan antara semua node (termasuk node kuorum).

Node kuorum tidak menghosting layanan aktif apa pun. Satu-satunya perannya adalah untuk berpartisipasi dalam komunikasi node untuk menentukan mana yang aktif dan untuk memberikan 'tie-break voting' jika terjadi gangguan komunikasi.

SIOS juga mendukung Pagar dan Penyimpanan IO sebagai perangkat kuorum, dan dalam konfigurasi ini node kuorum tambahan tidak diperlukan.

Seperti yang dibahas sebelumnya, sekali Cluster Ketersediaan Tinggi telah dikonfigurasi, dua atau lebih node berjalan secara bersamaan dan pengguna terhubung ke simpul "aktif" . Ketika masalah terjadi pada node aktif, kondisi "failover" terjadi dan node "standby" menjadi node "aktif" baru. Ketika terjadi failover harus ada mekanisme yang memungkinkan klien untuk mendeteksi kondisi failover dan menyambung kembali, atau transfer mulus sesi klien aktif pengguna ke node aktif.

Alamat IP Virtual

Biasanya alamat IP "virtual" dibuat ketika sebuah cluster dikonfigurasi dan klien berkomunikasi dengan simpul aktif menggunakan alamat IP virtual. Ketika terjadi failover, alamat IP virtual dipindahkan ke node aktif baru dan klien menyambung kembali ke alamat IP virtual yang sama.

Sebagai contoh, mari kita asumsikan bahwa ada dua node, A dan B, dengan alamat IP 10.20.1.10 dan 10.20.2.10 . Dalam contoh ini, kami akan mendefinisikan alamat IP virtual 10.20.0.10 yang harus dianggap ditetapkan ke node aktif saat ini.

Ini mirip dengan menetapkan alamat IP kedua ke satu kartu antarmuka jaringan pada satu node. Jika perintah ip a dimasukkan pada node aktif, kedua alamat IP akan muncul (seperti pada baris 10 dan 12 dalam contoh Linux ini):

Itu ARP Protokol

Ketika klien mencoba untuk menemukan server menggunakan alamat IP, klien biasanya menggunakan: ARP (Protokol Resolusi Alamat) untuk menemukan MAC (Kontrol Akses Media) alamat mesin target.

Setelah klien menyiarkan pesan untuk menemukan alamat IP target, node aktif menjawab dengan MAC alamat dan klien menyelesaikan permintaan dan menghubungkannya.

ARP Alternatif untuk Lingkungan Cloud

Di lingkungan cloud, bagaimanapun, tidak mungkin untuk mengidentifikasi node aktif menggunakan ARP karena banyak lapisan diabstraksikan dalam lingkungan virtual. Metode alternatif berdasarkan infrastruktur jaringan yang digunakan di lingkungan cloud tertentu mungkin diperlukan. Biasanya ada beberapa pilihan, dan pilihan harus dibuat dari daftar berikut.

• AWS Skenario Tabel Rute

• AWS Skenario IP Elastis

• AWS Skenario Route53

• Skenario Penyeimbang Beban Internal Azure

• Skenario Penyeimbang Beban Internal Google Cloud

Menentukan bagaimana Beban Kerja (node) harus didistribusikan adalah topik diskusi umum saat bermigrasi ke cloud publik dengan mempertimbangkan Ketersediaan Tinggi. Jika beban kerja berada dalam lingkungan di lokasi, lebih sering daripada tidak lokasi beban kerja ini ditentukan oleh lokasi pusat data yang sudah ada. Dalam banyak kasus, memilih lokasi lain untuk menampung beban kerja bukanlah pilihan yang tersedia. Dengan penawaran cloud publik, ada berbagai wilayah geografis serta zona ketersediaan untuk dipilih.

Availability Zone umumnya dianalogikan dengan satu atau lebih pusat data (lokasi fisik) yang terletak di wilayah fisik yang sama (misalnya, di California). Pusat data ini mungkin terletak di area yang berbeda tetapi terhubung menggunakan jaringan berkecepatan tinggi untuk meminimalkan latensi koneksi di antara mereka. (Perhatikan bahwa layanan hosting di beberapa pusat data dalam wilayah ketersediaan harus transparan bagi pengguna).

Sebagai aturan umum, semakin besar jarak fisik antara beban kerja, lingkungan menjadi lebih tangguh. Asumsi yang masuk akal adalah bahwa bencana alam seperti gempa bumi tidak akan mempengaruhi wilayah yang berbeda pada saat yang sama (misalnya, pantai barat AS dan pantai timur pada waktu yang sama). Namun, masih ada kemungkinan mengalami pemadaman layanan di berbagai wilayah secara bersamaan karena kegagalan di seluruh sistem (beberapa penyedia cloud sebelumnya telah melaporkan pemadaman lintas wilayah secara simultan seperti di AS & Australia). Mungkin tepat untuk mempertimbangkan membuat rencana DR (pemulihan bencana) yang ditentukan di berbagai penyedia cloud.

Perspektif lain yang layak dipertimbangkan adalah biaya untuk melindungi sumber daya. Umumnya semakin besar jarak antara beban kerja, semakin banyak biaya yang dikeluarkan untuk transfer data. Dalam banyak kasus, transfer data antar node dalam pusat data yang sama (Availability Zone) tidak dipungut biaya, meskipun mungkin memerlukan biaya $0,01/GB atau lebih untuk mentransfer data di seluruh Availability Zone. Biaya tambahan ini mungkin berlipat ganda (atau lebih) bila data ditransfer lintas wilayah (yaitu $0,02 / GB). Selain itu, karena peningkatan jarak fisik antara beban kerja, latensi data yang lebih besar antar node harus diantisipasi antar lokasi. Melalui pertimbangan faktor-faktor ini, secara umum, disarankan untuk mendistribusikan beban kerja di Availability Zone dalam Wilayah yang sama.