Apa Itu High Availability Server dan Kapan Diperlukan

Single point of failure: cara menemukannya

Merancang ketersediaan tinggi dimulai dari mencari single point of failure — bagian yang bila mati menghentikan segalanya. Caranya dengan bertanya untuk setiap komponen: kalau ini mati sekarang, apa yang terjadi?

Jawabannya sering mengejutkan. Aplikasi sudah berjalan di tiga server, tetapi ketiganya menunjuk ke satu basis data. Basis datanya sudah direplikasi, tetapi keduanya berada di rak yang sama dengan satu sakelar jaringan. Semuanya redundan, tetapi satu nama domain dikelola satu penyedia DNS tanpa cadangan.

Daftar itu perlu ditulis, karena mengingatnya tidak cukup. Dan biasanya ada satu atau dua titik yang perbaikannya murah — memindahkan satu server ke rak lain, menambah penyedia DNS kedua — yang memberi peningkatan besar tanpa arsitektur baru.

Cluster aktif pasif dan aktif aktif

Ada dua pola dasar. Pada cluster aktif pasif, satu node melayani dan satu lagi menunggu siap; ketika yang aktif gagal, yang pasif mengambil alih beserta alamat IP-nya. Lebih sederhana, dan cocok untuk layanan yang tidak bisa berjalan ganda seperti sebagian basis data.

Pada aktif-aktif, semua node melayani sekaligus. Kapasitasnya terpakai penuh dan kegagalan satu node hanya mengurangi kapasitas, bukan menghentikan layanan. Tetapi ia menuntut aplikasi yang memang bisa berjalan paralel tanpa saling mengganggu.

Yang menentukan pilihan biasanya bukan preferensi, melainkan apakah aplikasinya mendukung. Memaksa aplikasi yang menyimpan keadaan di lokal untuk berjalan aktif-aktif menghasilkan kerusakan data yang sulit ditelusuri.

Kuorum cluster: kenapa jumlah node harus ganjil

Konsep kuorum cluster adalah bagian yang paling sering menyebabkan masalah pada penyiapan yang tergesa. Ketika node kehilangan kontak satu sama lain, masing-masing harus memutuskan apakah dirinya yang berhak melayani.

Dengan tiga node, dua yang masih terhubung punya mayoritas dan berhak; yang terisolasi tahu dirinya minoritas dan berhenti. Dengan dua node, keduanya melihat satu lawan satu — dan bila keduanya memutuskan melayani, keduanya menulis ke data yang sama.

Kondisi itu, yang disebut split brain, lebih merugikan daripada layanan mati. Layanan mati bisa dipulihkan; data yang ditulis dua arah secara bersamaan sering tidak bisa direkonsiliasi.

Karena itu jumlah node ganjil, minimal tiga. Kalau hanya ada anggaran untuk dua node data, tambahkan satu perangkat kecil sebagai penentu kuorum — biayanya jauh lebih kecil daripada node penuh.

Target uptime realistis dan artinya dalam menit

Angka ketersediaan lebih mudah dinilai kalau diterjemahkan menjadi waktu. Menentukan target uptime realistis berarti memahami berapa lama layanan boleh mati setahun.

Biaya redundansi server yang perlu diakui di muka

Perlu jujur soal biaya redundansi server: ketersediaan tinggi berarti membayar kapasitas yang sebagian besar waktu tidak terpakai. Node pasif tetap ditagih penuh meski hanya menunggu.

Biaya kedua lebih sering diabaikan: kerumitan. Cluster punya mode kegagalan yang tidak dimiliki server tunggal — masalah kuorum, keterlambatan replikasi, peralihan yang gagal di tengah. Menelusurinya menuntut pemahaman yang lebih dalam, dan itu berarti orang atau pengelola yang lebih mahal.

Karena itu pertanyaan yang benar bukan apakah ketersediaan tinggi bagus, tapi apakah kerugian dari waktu mati memang melebihi biaya ini. Untuk banyak perusahaan menengah, jawabannya tidak — dan pemulihan cepat dari cadangan yang waktunya sudah diukur adalah pilihan yang lebih bijak.

Kami akan mengatakan itu terus terang saat pemetaan kebutuhan, meski artinya pekerjaan yang lebih kecil untuk kami.

Yang lebih dulu perlu dibereskan sebelum bicara HA

Ada urutan yang sering dilanggar: membangun cluster pada lingkungan yang cadangannya belum teruji. Itu menambah kerumitan pada pondasi yang belum kokoh.

Urutan yang kami sarankan: pastikan cadangan berjalan dan pernah dipulihkan, pasang pemantauan yang notifikasinya memang dibaca, tutup celah keamanan yang paling terbuka, dokumentasikan lingkungan. Baru setelah empat hal itu, ketersediaan tinggi menjadi langkah yang masuk akal.

Alasannya praktis. Sebagian besar gangguan yang benar-benar terjadi pada perusahaan menengah bukan kegagalan perangkat, melainkan disk penuh, salah konfigurasi, atau serangan. Cluster tidak melindungi dari ketiganya.

Langkah pertama yang murah menuju ketersediaan lebih baik

Antara satu server tanpa perlindungan dan cluster penuh, ada beberapa langkah yang biayanya kecil tetapi dampaknya besar. Ini yang biasanya kami sarankan lebih dulu.

Pisahkan basis data ke server tersendiri. Ini tidak menambah ketersediaan secara langsung, tetapi membuat pemulihan jauh lebih cepat karena kedua lapisan bisa ditangani terpisah, dan masalah di satu sisi tidak menjatuhkan yang lain.

Siapkan salinan siaga yang tidak menyala. Server pengganti dengan konfigurasi identik yang siap dinyalakan memberi waktu pemulihan jauh lebih pendek daripada membangun dari nol, dengan biaya yang jauh di bawah node aktif.

Otomatiskan penyiapan server. Kalau seluruh konfigurasi bisa dibangun ulang dari kode dalam belasan menit, kebutuhan akan redundansi berkurang dengan sendirinya — dan itu sering lebih murah daripada menambah perangkat.

Perlu dicatat juga bahwa ketersediaan tinggi menambah pekerjaan pemeliharaan, bukan menguranginya. Ada lebih banyak node untuk ditambal, konfigurasi cluster yang harus tetap sinkron, dan mekanisme peralihan yang perlu diuji berkala supaya tidak diam-diam berhenti bekerja.