Date: Agustus 23, 2026
Mengapa Uptime 99,99% Tidak Berarti Uptime 100%?
Pernahkah Anda melihat lebih dekat wadah pembersih tangan? “Membunuh 99,99% kuman” biasanya tertera dengan jelas di kemasannya. Jika Anda seperti saya, hal itu mungkin membuat Anda bertanya-tanya: “Bagaimana dengan 0,01% sisanya?” Apa yang membuat bagian kecil terakhir itu begitu sulit? Kita menghadapi pertanyaan yang sama dengan perangkat lunak HA. Anda mungkin pernah menemukan angka 99,99% saat membahas waktu aktif HA. Pertanyaannya tetap sama: mengapa kita tidak dapat mencapai waktu aktif 100%?
Pertama, mari kita bahas apa arti sebenarnya dari uptime 99,99%. Uptime mengacu pada jumlah waktu aplikasi Anda berjalan dan tersedia untuk pengguna akhir. Biasanya, ini diukur selama setahun. Untuk mencapai uptime 99,99%, Anda tidak boleh mengalami downtime lebih dari 52,60 menit. Secara rata-rata, itu terbagi menjadi:
52 menit, 36 detik setahun
4 menit 23 detik sebulan
1 menit 0 detik seminggu
0 menit 8 detik sehari
Itu waktu yang sangat singkat, tetapi bukan apa-apa, jadi dari mana sebenarnya asalnya?
Sumber Waktu Henti yang Disengaja
Mari kita mulai dengan beberapa sumber utama terjadinya downtime. Faktanya, seberapa pun bagusnya perangkat lunak HA Anda, akan selalu dibutuhkan waktu untuk melakukan operasi umum seperti switchover. Setiap kali Anda sengaja memulai switchover, akan terjadi downtime yang sangat minimal. Tergantung pada ukuran hierarki Anda, ini dapat memakan waktu mulai dari beberapa detik hingga beberapa menit. Untuk memahami mengapa demikian, kita perlu memahami apa yang terjadi ketika switchover terjadi. Pada tingkat sumber daya, kita harus terlebih dahulu menonaktifkan sumber daya sepenuhnya pada node aktif saat ini, kemudian mengaktifkan kembali sumber daya sepenuhnya pada node aktif yang baru. Tergantung pada aplikasinya, ini bisa berarti menjalankan beberapa perintah cepat, atau bisa juga berarti menjalankan operasi pematian bertahap yang panjang dan kompleks, diikuti dengan startup dingin yang lambat pada server lain. Pada tingkat hierarki, kita harus melakukan operasi ini satu per satu dalam banyak kasus. Jika suatu sumber daya memiliki anak, maka anak-anak tersebut harus dinonaktifkan sepenuhnya sebelum kita dapat mulai menonaktifkan sumber daya awal; Kemudian di server lain, kita harus mengaktifkan sepenuhnya server anak sebelum kita dapat mulai mengaktifkan server utama. Untuk hierarki multi-level, dengan proses peralihan yang kompleks, ini dapat sangat memakan waktu. Ini adalah jenis waktu henti yang inheren dan tak terhindarkan, tetapi untungnya dalam kebanyakan kasus pengguna akhir Anda seharusnya tidak menyadarinya selain sebagai waktu pemuatan yang sedikit lebih lama, atau koneksi ulang singkat. Namun, hal ini memang menambah perhitungan waktu henti.
Bentuk lain dari waktu henti yang melekat adalah pemeliharaan. Untungnya, sebagian besar pemeliharaan dapat dilakukan dengan cara yang sangat tersedia. Ini berarti melakukan pemeliharaan pada node cadangan terlebih dahulu, melakukan peralihan, kemudian melakukan pemeliharaan pada sistem yang sebelumnya aktif. Hal ini akan menimbulkan sejumlah waktu henti seperti yang dijelaskan di atas, tetapi seharusnya minimal. Namun, ada beberapa bentuk pemeliharaan yang tidak dapat dilakukan dengan cara yang sangat tersedia. Dalam kasus ini, sejumlah besar waktu henti dapat terjadi, dan meningkatkan total waktu henti untuk tahun tersebut.
Sumber-Sumber Waktu Henti yang Tidak Disengaja
Angka-angka tersebut benar-benar mulai bertambah begitu kita mulai melihat tujuan utama perangkat lunak ketersediaan tinggi: pemulihan bencana. Bahkan ketika semuanya berjalan sempurna sesuai rencana, setiap kegagalan akan menghasilkan sejumlah waktu henti. Mari kita lihat terlebih dahulu bagaimana waktu henti terjadi selama failover yang berhasil. Untuk memulihkan diri dengan benar dari suatu kegagalan, kita harus terlebih dahulu mendeteksi dan memverifikasi kegagalan tersebut. Ini adalah tindakan penyeimbangan yang sulit. Jika Anda terlalu agresif dalam mendeteksi kegagalan, Anda mungkin mendeteksi kegagalan yang sebenarnya belum terjadi (kegagalan palsu). Jika Anda tidak cukup agresif, Anda mungkin lebih lambat dari yang seharusnya dalam mendeteksi kegagalan. Sebagian besar kegagalan pertama kali akan dideteksi oleh proses yang berjalan secara berkala. Dalam kasus kegagalan sumber daya individual, ini biasanya berupa skrip pemeriksaan yang gagal. Dalam kasus seluruh server, ini biasanya akan dideteksi oleh detak jantung yang terlewat. Dalam kedua kasus tersebut, kita tidak hanya mengambil satu kegagalan dan langsung memulai pemulihan. Sebaliknya, kita mencoba lagi dan menunggu beberapa kegagalan untuk memverifikasi kegagalan yang sebenarnya. Sebagai contoh, skrip pemeriksaan mendalam, yang melakukan pengujian status sumber daya yang lebih rumit, secara default dijalankan setiap lima menit. Ini berarti bahwa mungkin dibutuhkan waktu hingga lima menit untuk mendeteksi kegagalan tertentu, dan tergantung pada jenis kegagalannya, mungkin dibutuhkan waktu lebih lama untuk memverifikasinya. Setelah kami mendeteksi dan memverifikasi kegagalan, tergantung pada jenis kegagalannya, kami kemudian dapat melakukan beberapa upaya pemulihan lokal. Jika berhasil, hal itu dapat menghemat waktu henti, tetapi jika tidak, hal itu akan menambah sedikit waktu pada perhitungan waktu henti failover. Setelah mendeteksi kegagalan, memverifikasinya, dan mencoba pemulihan lokal, kami kemudian akan melakukan failover. Tergantung pada jenis kegagalannya, hal itu dapat memakan waktu yang hampir sama dengan waktu henti switchover yang dijelaskan sebelumnya. Menambahkan semua potensi sumber penundaan ini, berpotensi untuk benar-benar meningkatkan waktu henti. Untungnya, sebagian besar kegagalan dapat dideteksi dengan cepat, dan sama seperti switchover yang dijelaskan di atas, hampir tidak akan disadari oleh pengguna akhir.
Sumber kedua dari waktu henti yang tidak disengaja adalah kegagalan failover. Ketika ini terjadi, hal ini dapat benar-benar meningkatkan waktu henti, karena bergantung pada teknisi yang berkualifikasi untuk campur tangan dan menstabilkan sistem dengan benar. Hal ini agak jarang terjadi, tetapi memang bisa terjadi. Untungnya, hal ini hampir selalu dapat dicegah. Cara terbaik untuk memastikan bahwa failover akan berjalan sesuai rencana adalah dengan mengujinya terlebih dahulu. Sangat mudah untuk salah mengkonfigurasi sesuatu, tetapi hanya dengan menjalankan uji failover akan mengungkapkan masalah tersebut. Cara lain untuk memastikan bahwa failover akan berhasil adalah dengan memastikan bahwa cluster Anda siap untuk melakukan failover sesering mungkin. Ini berarti memastikan bahwa sistem cadangan aktif dan berjalan, dan bahwa sumber daya berada dalam keadaan ISP (In Service Protected). Misalnya, mirror DataKeeper, yang tidak dalam keadaan mirroring, tidak akan berada dalam keadaan ISP, dan ketika terjadi kegagalan, tidak akan dapat melakukan failover. Untuk memastikan bahwa sumber daya dapat dialihkan, Anda harus mengambil langkah-langkah untuk memastikan bahwa DataKeeper melakukan mirroring sesering mungkin, dan sumber daya lainnya juga selalu diperbarui dan siap untuk failover.
Sumber terakhir dari waktu henti yang tidak disengaja adalah masalah di luar kendali LifeKeeper. Masalah jaringan dapat menyebabkan failover yang berhasil maupun tidak berhasil, tetapi juga dapat membuat cluster yang tampaknya sehat menjadi tidak dapat diakses tergantung pada bagaimana sistem diatur. Demikian pula, masalah dengan perangkat lunak cloud atau virtualisasi yang mendasarinya dapat menyebabkan masalah di luar cakupan LifeKeeper. Untuk mencegah hal ini, menjaga sistem sebisa mungkin terpisah memungkinkan LifeKeeper untuk mengatasi masalah ini. Cluster yang berisi sistem yang semuanya berada di AZ yang sama atau di jaringan yang sama jauh lebih rentan terhadap masalah daripada cluster yang berisi sistem yang beragam. Area masalah lain di luar kendali LifeKeeper adalah masalah aplikasi internal dan kesalahan manusia. Misalnya, penghapusan data penting secara tidak sengaja dapat menyebabkan masalah bagi pengguna akhir yang kemungkinan besar tidak akan terdeteksi dan tidak dapat diperbaiki oleh LifeKeeper. Menggunakan perangkat lunak pencadangan dapat membantu memulihkan dari jenis masalah ini, tetapi tidak dapat mengembalikan waktu aktif yang hilang. Terakhir, ketersediaan tinggi tidak selalu melindungi dari pelaku jahat dan ancaman keamanan siber. Serangan tertentu dapat mengakibatkan hilangnya waktu aktif. Untuk mencegah hal tersebut, disarankan untuk menggunakan perangkat lunak antivirus/antimalware yang terpercaya.
Sumber-Sumber Downtime yang Dapat Dihindari
Seperti yang telah disinggung di beberapa bagian di atas, ada banyak sumber waktu henti yang sepenuhnya dapat dicegah. Saya tidak akan membahas setiap jenis waktu henti yang dapat dicegah di sini, tetapi saya akan menyoroti beberapa yang paling umum.
Saat merancang topologi dan desain klaster Anda, ada beberapa hal yang perlu dipertimbangkan. Split brain, yang terjadi ketika kedua node percaya bahwa mereka adalah node utama, dapat dicegah dengan menggunakan beberapa bentuk kuorum. Jika Anda membuat aplikasi gen, pastikan untuk menulis dan menggunakan skrip pemeriksaan cepat dan pemeriksaan mendalam, sehingga kegagalan benar-benar terdeteksi. Terakhir, pastikan untuk menyiapkan lebih dari satu jalur komunikasi yang berjalan di lebih dari satu NIC dan jaringan.
Sistem yang tidak diatur dengan benar juga dapat menyebabkan waktu henti (downtime). Beberapa di antaranya telah dijelaskan. Pertama, pastikan bahwa aplikasi yang dilindungi, sistem operasi yang mendasarinya, dan perangkat lunak ketersediaan tinggi semuanya sepenuhnya diperbarui menggunakan versi terbaru. Banyak waktu henti terjadi karena bug yang sudah diperbaiki, yang sebenarnya dapat dihindari sepenuhnya. Kedua, pastikan untuk melakukan pengujian peralihan (switchover) dan failover pada klaster setelah pengaturan dan secara berkala. Banyak masalah yang dapat mencegah failover yang berhasil dapat dideteksi dan dicegah sebelumnya dengan melakukan pengujian ini. Ketiga, pastikan Anda selalu beroperasi dengan node cadangan yang aktif dan siap untuk mengambil alih.
Sistem yang dikonfigurasi secara tidak benar dapat menyebabkan waktu henti (downtime). Untuk mencegah hal ini, LifeKeeper dan DataKeeper menawarkan parameter yang dapat disesuaikan untuk mengoptimalkan kinerja, interval heartbeat, pemeriksaan sumber daya, dan pengaturan percobaan ulang. Meskipun pengaturan default biasanya sudah cukup, setiap perubahan harus dilakukan dengan pemahaman yang jelas tentang dampak dan kebutuhannya. Selalu prioritaskan panduan dari Dukungan SIOS, karena rekomendasi mereka didasarkan pada keahlian yang luas dan harus diikuti untuk memastikan keandalan sistem.
Penulis: Carter Chandler, Associate Software Engineer di SIOS
Direproduksi dengan izin dariSIOS