Windows Server 2025 / Merencanakan kluster failover

Windows Server Failover Clustering (WSFC), fitur kluster failover Windows Server, mengoordinasikan peran yang didukung pada beberapa server dan dapat memulai ulang atau memindahkannya setelah kegagalan. Dua server saja belum merupakan solusi lengkap: aplikasi, penyimpanan, jaringan, kuorum, validasi, dan sasaran pemulihan harus dirancang bersama.

Menentukan kegagalan yang harus ditangani

Node adalah server peserta. Peran dalam kluster merupakan kumpulan sumber daya layanan atau mesin virtual yang dikelola kluster. Deteksi kegagalan dan perpindahan dapat memutus koneksi. Karena itu, periksa kapan klien dapat tersambung kembali dan aplikasi benar-benar dapat dipakai, bukan hanya kapan konsol menampilkan sumber daya online.

Ketersediaan tinggi tidak menggantikan pencadangan atau pemulihan bencana. Dua mesin virtual pada host fisik yang sama dapat gagal bersamaan; host berbeda pun dapat bergantung pada penyimpanan, pasokan listrik, atau switch yang sama. Mengaktifkan fitur kluster pada server IIS biasa tidak otomatis membuat situsnya berketersediaan tinggi. Pastikan dahulu arsitektur yang didukung aplikasi.

Tentukan peran yang dilindungi, Recovery Time Objective (RTO), yaitu batas waktu pemulihan yang dapat diterima, dan Recovery Point Objective (RPO), yaitu kehilangan data yang dapat diterima terhadap titik pemulihan. Catat awal dan akhir pengukuran serta bukti yang diperlukan. Jangan menganggap kluster otomatis memberikan waktu henti atau kehilangan data nol.

Meninjau node, jaringan, dan kapasitas tersisa

Bandingkan persyaratan perangkat keras dan penyimpanan kluster dengan versi Windows Server, perangkat yang didukung, driver, dan firmware. Untuk desain baru, gunakan node Windows Server 2025 yang sebanding serta pastikan dukungan dan validasi keseluruhan konfigurasi. Pada metode domain biasa berlaku kondisi versi dan domain yang sama; kluster workgroup memiliki ketentuan berbeda. Jangan mencampur kedua prosedurnya.

• Petakan lalu lintas administrasi, kluster, penyimpanan, dan migrasi mesin virtual jika digunakan. Perkirakan bandwidth serta persaingan lalu lintas selama kegagalan dan pemulihan.
• Identifikasi titik kegagalan tunggal pada adaptor jaringan, switch, listrik, dan jalur penyimpanan. Catat dependensi bersama meskipun nama node berbeda.
• Hitung CPU, memori, dan kapasitas penyimpanan yang tersisa setelah satu node gagal, termasuk beban yang diambil alih serta sinkronisasi ulang. Kapasitas total yang cukup saat normal belum membuktikan kapasitas saat gagal.
• Pada penerapan domain, verifikasi DNS internal, sinkronisasi waktu, identitas kluster, dan izin pendaftaran nama. Pisahkan node kluster dari pengontrol domain sesuai metode penerapan.

Simpan alamat, nama, jaringan lokal virtual (VLAN), dan kebutuhan firewall dalam rencana jaringan bersama. Beberapa adaptor yang terhubung ke switch atau jalur kabel yang sama belum menjadi jalur independen. Sebagai contoh, ketika satu host hilang, catat node penerima beban serta sumber daya kosongnya. Jika penyimpanan bersama hilang, jelaskan apakah node yang tersisa masih dapat mengakses data. Bedakan skenario tersebut sebelum menentukan tambahan kapasitas.

Memilih penyimpanan yang didukung peran

Disk bersama, penyimpanan Server Message Block (SMB), dan Storage Spaces Direct memiliki ketentuan peran, perangkat keras, edisi, serta dukungan tersendiri. Tidak semua pilihan sesuai untuk semua beban. Folder lokal bernama sama pada dua node tidak menyediakan data bersama; DFS Namespaces juga tidak otomatis menyediakan replikasi atau penyimpanan kluster. Pilihan yang digunakan harus memungkinkan node pengambil alih mengakses data terkini melalui konfigurasi yang didukung.

Gunakan lingkungan pengujian terpisah sebelum menyajikan disk operasional untuk konfigurasi atau validasi penyimpanan. Dokumentasikan pemilik disk, reservasi, jalur, dan ketentuan lisensi arsitektur. Disk yang terlihat belum tentu bebas untuk diambil alih. Jangan mengikutsertakan data produksi dalam pengujian penyimpanan tanpa rencana yang melindungi layanan dan datanya.

Merencanakan kuorum dan lokasi witness

Kuorum menentukan apakah kluster boleh tetap beroperasi, termasuk ketika partisi jaringan memisahkan komponennya, serta membantu mencegah kepemilikan sumber daya yang saling bersaing. Witness, atau saksi kuorum, ikut dalam keputusan tersebut; bukan salinan data layanan maupun node tambahan untuk menjalankan beban. Witness yang terjangkau tidak membuktikan bahwa penyimpanan atau aplikasi dapat diakses.

Bandingkan witness disk, berbagi berkas, dan cloud melalui panduan penerapan witness kuorum. Pertimbangkan lokasi, izin, partisi jaringan, serta konektivitas eksternal selain jumlah node. Setiap jenis memiliki prasyarat sendiri; misalnya witness cloud bergantung pada sumber daya Azure yang disetujui dan koneksi HTTPS dari node. Kuorum dinamis tidak menjamin ketahanan terhadap semua kombinasi atau urutan kegagalan.

Witness dalam domain kegagalan yang sama dapat hilang bersama kedua node. Lokasi jauh pun tidak cukup jika jalur bersama terputus atau otorisasi tidak tersedia. Buat matriks kehilangan node, sambungan antarnode, jalur penyimpanan, dan seluruh lokasi. Untuk setiap kasus, catat peserta yang tersisa, lokasi witness, akses data, dan perilaku yang diharapkan. Cocokkan matriks dengan panduan jenis witness pilihan sebelum menganggap kesinambungan telah terbukti.

Mensyaratkan validasi sebelum penerapan

1. Dokumentasikan node, jaringan, penyimpanan, akun, nama, dan peran yang dilindungi. Tetapkan penanggung jawab dan hubungkan setiap dependensi dengan kegagalan yang dapat ditimbulkannya.
2. Selaraskan fitur, pembaruan, driver, dan persyaratan dukungan. Konfirmasi kompatibilitas konfigurasi lengkap, bukan hanya setiap komponen secara terpisah.
3. Rencanakan validasi konfigurasi sebelum membuat kluster. Atasi atau jelaskan setiap peringatan dan kegagalan beserta dampak serta tindakannya; menyimpan temuan saja bukan berarti meninjaunya.
4. Uji perpindahan terencana secara terpisah dari kegagalan mendadak dalam lingkungan yang diizinkan. Perpindahan berhasil tidak membuktikan deteksi dan pemulihan otomatis akan sama.
5. Ukur koneksi ulang klien, konsistensi data, waktu pemulihan, dan pengiriman peringatan. Bandingkan hasil pengamatan dengan RTO dan RPO, lalu catat selisihnya tanpa membuat angka pengukuran.
6. Validasi pemulihan cadangan dan kehilangan seluruh domain kegagalan secara terpisah. Sertakan urutan pemulihan, dependensi, pemilik, dan kriteria untuk mengembalikan layanan ke operasi normal.

Ikuti panduan pembuatan dan validasi kluster sesuai arsitektur. Pengujian penyimpanan dapat mengganggu layanan; jangan menjalankan seluruh pengujian tanpa menilai dampaknya pada produksi. Simpan laporan beserta penyebab, dampak, dan tindakan setiap temuan. Pada penerapan domain, rencanakan izin untuk mengelola node serta membuat atau menyiapkan objek komputer terlebih dahulu; jangan memberi administrasi seluruh domain hanya untuk melewati galat izin.

Latihan perencanaan ini tidak mengubah DC1, FS1, atau server kursus lain menjadi kluster. Hasilnya adalah desain peran yang didukung, kebutuhan sumber daya, peta domain kegagalan, sasaran gangguan, serta rencana validasi dengan penanggung jawab. Jika belum jelas apa yang terjadi ketika penyimpanan hilang atau bagaimana berkas terhapus dipulihkan, catat sebagai keputusan tertunda. Menambahkan node saja tidak menyelesaikan kondisi tersebut.