Administrasi Server High Availability

Pendahuluan Sistem Komputer digunakan di seluruh aspek kehidupan (sistem penerbangan, lalu lintas, operasi dunia bisnis. High Available (sistem dapat diandalkan terus menerus). Harus meminimalisir downtime. Memastikan aplikasi dan datanya bisa diakses oleh pengguna.

Pendahuluan (lanj.) Menghilangkan Single Point of Failure (SPOF). Cara menghilangkan SPOF (desain yang baik, perencanaan pemilihan hardware, konfigurasi software, kontrol disiplin manajemen. Waktu yang dihitung saat sistem tidak dapat bekerja (downtime). Contoh downtime (maintenance terjadwal dan tidak terjadwal).

Persentase Availability Downtime terjadwal bukan termasuk pertimbangan desain sistem high available. Misal 99% uptime, 1% downtime (1 tahun = 365 hari), berarti sistem boleh downtime selama 3,65 hari. Sistem yang high available lebih dari 99% uptime (99,9%; 99,99%, 99,999%, dst). Semakin tinggi persentase uptime, semakin tinggi pula biaya dan kompleksitas yang dibutuhkan.

Persentase Availability (lanj.) Tabel 2.1. Persentase uptime dan waktu downtime yang diijinkan Persentase uptime Waktu downtime yang diijinkan per tahun Waktu downtime yang diijinkan per minggu Waktu downtime yang diijinkan per hari 90% 36,5 hari 16,8 jam 2,4 jam 95% 18,25 hari 8,4 jam 1,2 jam 98% 7,3 hari 3,36 jam 28,8 menit 99% 3,65 hx`ari 1,68 jam 14,4 menit 99,5% 43,92 jam 50,4 menit 7,2 menit 99,8% 17,52 jam 20,16 menit 2,9 menit 99,9% 8,76 jam 10,1 menit 1,4 menit 99,95% 4,38 jam 5,04 menit 42,3 detik 99,99% 52,26 menit 1,01 menit 8,7 detik 99,999% 5,26 menit 6,05 detik 0,86 detik 99,9999% 31,5 detik 0,605 detik 0,086 detik

Identifikasi Resiko Identifikasi komponen yang menyebabkan kegagalan. Menentukan efek kegagalan tersebut terhadap operasi sistem menyeluruh. Peluang kegagalan muncul. Jika mungkin, mencari cara untuk meminimalisir peluang sistem gagal.

Identifikasi Resiko (lanj.) Tabel 2. Penyebab kegagalan sistem Faktor Eksternal Faktor Internal Kegagalan sistem tenaga listrik (solusi UPS, generator, provider pihak ketiga) Kegagalan jaringan penghubung antara jaringan internal dan eksternal sistem Perubahan konfigurasi (firewall, proxy, dsb.) oleh klien/pengguna Kegagalan sistem backup Isu terkait keamanan sistem akibat gangguan dari pihak luar Kegagalan hardware server Konfigurasi server yang salah Kegagalan aplikasi berbasis web/konfigurasi aplikasi yang salah Kegagalan basis data Kegagalan jaringan internal (LAN) Isu terkait keamanan sistem akibat pihak internal

Syarat-syarat High Availability HA adalah proses memastikan sebuah aplikasi selalu tersedia untuk pengguna dangan cara penggunaan hardware cadangan atau penggunaan sumberdaya secara bersama yang dikontrol oleh sebuah software. Syarat HA: 1. Reliability 5. Redundancy 2. Fault tolerance 6. Minimal disruption 3. High uptime 4. Operational continuity

Strategi Penerapan HA Menggunakan failover (pemindahan otomatis ke host lain) Menggunakan software heartbeat. Server backup pasif langsung menggantikan, hanya ketika server utama mengalami kegagalan .

Strategi Penerapan HA (lanj.) Pertukaran data antara dua server memakai 2 metode: 1. Replikasi data kedua server secara berkala 2. Penggunaan penyimpanan bersama kedua server

Gambar 2.1 Replikasi data antara kedua server Metode Replikasi Data Gambar 2.1 Replikasi data antara kedua server

Metode Replikasi Data (lanj.) Kelemahan: terdapat pengurangan performa dibandingkan dengan metode yang tidak menggunakan replikasi data. Keunggulannya: tidak membutuhkan hardware tambahan yang berfungsi sebagai tempat penyimpanan bersama (contohnya storage area network (SAN)) yang harganya cukup mahal.

Metode Shared Storage Gambar 2.2 Penggunaan shared storage sebagai tempat penyimpanan data bersama

Metode Shared Storage (lanj.) Keunggulan: tidak ada replikasi dan redundansi data yang muncul antara server utama dan server backup. Hal ini menyebabkan tidak ada penurunan performa yang diakibatkan proses replikasi saat operasi normal. Kelemahannya adalah metode ini membutuhkan tempat penyimpanan bersama, dan ketika server backup aktif, server backup harus membaca dan memproses journal dari shared storage terlebih dahulu. Sehingga terdapat waktu yang dibutuhkan sebelum server backup benar-benar aktif.

Terima Kasih