Availability Concept

1. 1
Manajemen Infrastruktur TI:
MIT-02 Konsep Ketersediaan
(Availability Concepts)
Rumadi Hartawan, S.T., M.Kom.

2. Buku Acuan 1
IT Infrastructure Architecture
Infrastructure Building Blocks and Concepts
Third Edition
Sjaak Laan
Lulu Press Inc, 2017
https://s.id/itia3ed
http://www.sjaaklaan.com/
2

3. 3 PENGANTAR ATRIBUT NON-
FUNGSIONAL
3.1 Pendahuluan
3.2 Persyaratan Non-fungsional
3

4. 3.1 Pendahuluan
Infrastruktur TI menyediakan layanan untuk aplikasi. Beberapa layanan infrastruktur ini
dapat didefinisikan dengan baik sebagai fungsi, seperti menyediakan ruang disk, atau
merutekan pesan jaringan.
Atribut non-fungsional, di sisi lain, menggambarkan perilaku kualitatif dari suatu sistem,
daripada fungsi tertentu.
Beberapa contoh atribut non-fungsional adalah:
 Ketersediaan (Availability)
 Skalabilitas (Scalability)
 Keandalan (Reliability)
 Stabilitas (Stability)
 Kemudahan untuk diuji (Testability)
 Kemudahan dipulihkan (Recoverability)
4

5. 3.1 Pendahuluan
 Dalam pengalaman penulis, atribut non-fungsional yang
paling penting untuk sebagian besar infrastruktur TI adalah
keamanan, kinerja, dan ketersediaan.
 Atribut non-fungsional sangat penting untuk keberhasilan
implementasi dan penggunaan infrastruktur TI, tetapi dalam
proyek, atribut tersebut jarang mendapatkan perhatian yang
sama dengan layanan fungsional.
5

6. 3.2 Persyaratan Non-fungsional
 Adalah tugas arsitek TI atau insinyur persyaratan untuk menemukan persyaratan implisit
pada atribut non-fungsional (persyaratan non-fungsional -NFR).
 Ini bisa sangat sulit, karena apa yang jelas atau diterima begitu saja oleh pelanggan atau
pengguna akhir suatu sistem tidak selalu jelas bagi perancang dan pembuat sistem.
 Dan tidak ketinggalan persyaratan non-fungsional yang dimiliki pemangku kepentingan
lainnya, seperti keberadaan jendela layanan atau kemampuan pemantauan, yang
merupakan persyaratan penting bagi manajer sistem.
 Penting untuk diingat bahwa penerimaan suatu sistem sebagian besar tergantung pada
persyaratan non-fungsional yang diterapkan. Sebuah situs web bisa sangat indah dan
fungsional, tetapi jika memuat situs (kinerja, persyaratan non-fungsional) membutuhkan
waktu 30 detik, sebagian besar pelanggan hilang!
6

7. 4 KONSEP KETERSEDIAAN
4.1 Pendahuluan
4.2 Menghitung ketersediaan
4.3 Sumber ketidaktersediaan
4.4 Pola ketersediaan
7

8. Introduction
 Semua orang
mengharapkan
infrastruktur mereka
tersedia setiap saat
 Ketersediaan infrastruktur
yang dijamin 100% adalah
tidak mungkin

9. Menghitung ketersediaan (availability)
 Ketersediaan tidak dapat dihitung, atau dijamin dimuka
 Ketersediaan hanya dapat dilaporkan setelahnya, ketika sistem telah
berjalan selama beberapa tahun
 Selama bertahun-tahun, banyak pengetahuan dan pengalaman
diperoleh tentang bagaimana merancang sistem yang tersedia
tinggi (high available systems)
 Menghindari kegagalan (failover)
 Redundansi
 Pemrograman terstruktur
 Menghindari Titik Kegagalan Tunggal (Single Points of Failures, SPOFs)
 Menerapkan manajemen sistem 9

10. Menghitung ketersediaan (availability)
 Ketersediaan sistem biasanya dinyatakan sebagai
persentase waktu aktif dalam periode waktu tertentu
 Biasanya satu tahun atau satu bulan
 Contoh untuk waktu henti (downtime) yang dinyatakan
dalam persentase per tahun:
Availability %
Downtime
per year
Downtime
per month
Downtime
per week
99.8% 17.5 hours 86.2 minutes 20.2 minutes
99.9% ("three nines") 8.8 hours 43.2 minutes 10.1 minutes
99.99% ("four nines") 52.6 minutes 4.3 minutes 1.0 minutes
99.999% ("five nines") 5.3 minutes 25.9 seconds 6.1 seconds

11. Menghitung ketersediaan (availability)
 Persyaratan umum yang digunakan dalam perjanjian tingkat
layanan (service level agreements, SLA) saat ini adalah
ketersediaan 99,8% atau 99,9% per bulan untuk sistem TI
lengkap
 Ketersediaan infrastruktur harus jauh lebih tinggi
 Biasanya di kisaran 99,99% atau lebih tinggi
 Waktu aktif 99,999% juga dikenal sebagai ketersediaan tingkat
operator
 Untuk satu komponen
 Tingkat ketersediaan yang lebih tinggi untuk sistem yang lengkap sangat
jarang, karena hampir tidak mungkin dicapai

12. Menghitung ketersediaan (availability)
Adalah praktik yang baik untuk menyepakati frekuensi
maksimum ketidaktersediaan
Unavailability
(minutes)
Number of events
(per year)
0 – 5 <= 35
5 – 10 <= 10
10 – 20 <= 5
20 – 30 <=2
> 30 <= 1

13. MTBF dan MTTR
 Waktu Rata-Rata Antara Kegagalan
(Mean Time Between Failures, MTBF)
 Waktu rata-rata yang berlalu di antara kegagalan
 Waktu Rata-Rata Untuk Perbaikan
(Mean Time To Repair, MTTR)
 Waktu yang dibutuhkan untuk pulih dari kegagalan

14. MTBF dan MTTR
 Beberapa komponen memiliki MTBF lebih tinggi
daripada yang lain
 Beberapa MTBF yang khas:
Component MTBF (hours)
Hard disk 750,000
Power supply 100,000
Fan 100,000
Ethernet Network Switch 350,000
RAM 1,000,000

15. MTTR
MTTR dapat dijaga tetap rendah dengan:
 Memiliki kontrak layanan dengan pemasok
 Memiliki suku cadang di tempat
 Redundansi dan failover otomatis

16. MTTR
Langkah-langkah untuk menyelesaikan perbaikan:
 Pemberitahuan kegagalan (waktu sebelum melihat pesan
alarm)
 Memproses alarm
 Menemukan akar penyebab kesalahan
 Mencari informasi perbaikan
 Mendapatkan komponen cadangan dari penyimpanan
 Menginstruksikan teknisi datang ke pusat data dengan
komponen cadangan
 Memperbaiki kesalahan secara fisik
 Memulai ulang (restarting) dan menguji komponen

17. Quiz Interaktif
 Tuliskan formula perhitungan ketersediaan (availability) jika
diketahui nilai MTBF dan MTTR.
17

18. Contoh perhitungan
Availability =
MTBF
MTBF + MTTR
× 100%
Component MTBF (h) MTTR (h) Availability in %
Power supply 100,000 8 0.9999200 99.99200
Fan 100,000 8 0.9999200 99.99200
System board 300,000 8 0.9999733 99.99733
Memory 1,000,000 8 0,9999920 99.99920
CPU 500,000 8 0.9999840 99.99840
Network
Interface
Controller (NIC)
250,000 8 0.9999680 99.99680

19. Contoh perhitungan
 Komponen serial: Satu cacat menyebabkan waktu
henti
 Contoh: ketersediaan sistem di atas adalah:
0.9999200 × 0.9999200 × 0.9999733 × 0.9999920
× 0.9999840 × 0.9999680 = 0.99977 = 𝟗𝟗. 𝟗𝟕𝟕%
(ketersediaan setiap komponen setidaknya 99,99%)

20. Contoh perhitungan
 Komponen paralel: Satu yang gagal: tidak ada waktu henti!
 Tapi hati-hati adanya SPOF!
 Hitung ketersediaan:
𝐴 = 1 − (1 − 𝐴1)𝑛
 Total ketersediaan = 1 − (1 − 0.99)2 = 99.99%

21. Sumber ketidaktersediaan –
kesalahan manusia
80% pemadaman (outages) yang berdampak pada layanan mission-
critical disebabkan oleh orang dan masalah proses
Contoh:
 Melakukan tes di lingkungan produksi
 Mematikan komponen yang salah untuk keperluan perbaikan
 Menukar disk yang berfungsi baik dalam kumpulan RAID alih-alih
yang rusak
 Memulihkan tape cadangan yang salah ke produksi
 Tidak sengaja menghapus file
 Folder email, file konfigurasi
 Tidak sengaja menghapus entri basis data
 Hapus tabel x alih-alih hapus tabel y

22. Sumber ketidaktersediaan –
bug perangkat lunak
 Karena kerumitan sebagian besar perangkat lunak, hampir
tidak mungkin (dan sangat mahal) untuk membuat
perangkat lunak bebas bug
 Bug perangkat lunak aplikasi dapat menghentikan seluruh
sistem
 Sistem operasi juga perangkat lunak
 Sistem operasi yang mengandung bug dapat menyebabkan
sistem file rusak, kegagalan jaringan, atau sumber
ketidaktersediaan lainnya

23. Sumber ketidaktersediaan –
pemeliharaan terencana
 Terkadang diperlukan untuk melakukan tugas manajemen
sistem:
 Meningkatkan (upgrade) perangkat keras atau perangkat lunak
 Menerapkan perubahan perangkat lunak
 Migrasi data
 Pembuatan cadangan
 Hanya boleh dilakukan pada bagian infrastruktur di mana
bagian lain tetap melayani klien
 Selama pemeliharaan terencana, sistem lebih rentan terhadap
waktu henti daripada dalam keadaan normal
 SPOF sementara dapat terjadi
 Manajer sistem bisa membuat kesalahan

24. Sumber ketidaktersediaan –
cacat fisik
 Semuanya hancur pada akhirnya
 Bagian mekanis kemungkinan besar akan rusak terlebih
dahulu
 Contoh:
 Kipas untuk peralatan pendingin biasanya rusak karena debu di
bantalan
 Disk drive berisi bagian yang bergerak
 Pita (tape) sangat rentan terhadap cacat karena pita diputar dan
dimatikan sepanjang waktu
 Tape drive berisi bagian mekanik yang sangat sensitif yang
dapat dengan mudah rusak

25. Sumber ketidaktersediaan –
kurva bak mandi
 Kegagalan komponen kemungkinan besar terjadi ketika komponen
masih baru
 Ketika sebuah komponen masih berfungsi setelah bulan pertama,
kemungkinan besar komponen tersebut akan terus bekerja tanpa
kegagalan hingga akhir masa pakainya

26. Sumber ketidaktersediaan –
masalah lingkungan
Masalah lingkungan dapat menyebabkan waktu henti:
 Fasilitas yang gagal
 Daya listrik
 Pendinginan
 Bencana
 Api / kebakaran
 Gempa bumi
 Banjir

27. Sumber ketidaktersediaan –
kompleksitas infrastruktur
 Menambahkan lebih banyak komponen ke desain sistem secara
keseluruhan dapat merusak ketersediaan tinggi
 Bahkan jika komponen tambahan diterapkan untuk mencapai
ketersediaan tinggi
 Sistem yang kompleks
 Memiliki lebih banyak titik kegagalan potensial
 Lebih sulit untuk diterapkan dengan benar
 Lebih sulit untuk dikelola
 Terkadang lebih baik memiliki sistem cadangan ekstra di lemari
daripada menggunakan sistem redundan yang rumit

28. Redundansi
(Redundancy)
 Redundansi adalah duplikasi komponen kritis dalam satu
sistem, untuk menghindari satu titik kegagalan (single point of
failure, SPOF)
 Contoh:
 Satu komponen yang memiliki dua catu daya; jika satu gagal, yang
lain mengambil alih
 Antarmuka jaringan ganda
 Kabel redundan

29. Kegagalan (Failover)
 Failover adalah peralihan (semi) otomatis ke sistem atau
komponen siaga
 Contoh:
 Windows Server failover clustering
 VMware High Availability
 Oracle Real Application Cluster (RAC) database

30. Berbalik (Fallback)
 Fallback adalah peralihan manual ke sistem komputer siaga
yang identik di lokasi yang berbeda
 Biasanya digunakan untuk pemulihan bencana
 Tiga bentuk dasar solusi fallback:
 Situs panas (Hot site)
 Situs dingin (Cold site)
 Situs hangat (Warm site)

31. Fallback – hot site
 Sebuah situs panas (hot site) adalah
 Pusat data fallback yang terkonfigurasi sepenuhnya
 Dilengkapi dengan catu daya dan pendingin
 Aplikasi diinstal di server
 Data tetap up-to-date untuk sepenuhnya mencerminkan sistem
produksi
 Memerlukan pemeliharaan terus-menerus atas perangkat
keras, perangkat lunak, data, dan aplikasi untuk memastikan
lokasi secara akurat mencerminkan keadaan lokasi produksi
setiap saat

32. Fallback - cold site
 Disiapkan untuk penempatan peralatan yang dapat dibawa
selama keadaan darurat, tetapi tidak ada perangkat keras
komputer yang tersedia di lokasi
 Aplikasi perlu diinstal dan data saat ini sepenuhnya dipulihkan
dari cadangan
 Jika sebuah organisasi memiliki anggaran yang sangat sedikit
untuk situs fallback, situs yang dingin mungkin lebih baik
daripada tidak sama sekali

33. Fallback - warm site
 Fasilitas komputer yang tersedia dengan daya, pendingin,
dan komputer, tetapi aplikasi mungkin tidak diinstal atau
dikonfigurasi
 Campuran antara situs panas dan situs dingin
 Aplikasi dan data harus dipulihkan dari media cadangan dan
diuji
 Ini biasanya memakan waktu satu hari

34. Kelangsungan Bisnis
(Business Continuity)
 Bencana TI didefinisikan sebagai masalah yang tidak dapat
diperbaiki di pusat data, membuat pusat data tidak dapat
digunakan
 Bencana alam:
 Banjir
 Badai
 Tornado
 Gempa bumi
 Bencana akibat perbuatan manusia:
 Tumpahan bahan berbahaya
 Kegagalan infrastruktur
 Bio-terorisme

35. Kelangsungan Bisnis
(Business Continuity)
 Dalam kasus bencana, infrastruktur bisa menjadi tidak
tersedia, dalam beberapa kasus untuk jangka waktu yang
lebih lama
 Manajemen Kontinuitas Bisnis meliputi:
 TI (teknologi informasi)
 Mengelola proses bisnis
 Ketersediaan orang dan tempat kerja dalam situasi bencana
 Perencanaan pemulihan bencana (Disaster recovery
planning, DRP) berisi serangkaian tindakan yang harus
diambil jika terjadi bencana, ketika (bagian dari) infrastruktur
TI harus diakomodasi di lokasi alternatif

36. RTO and RPO
 RTO dan RPO adalah tujuan/target jika terjadi bencana
 Tujuan Waktu Pemulihan (Recovery Time Objective,
RTO)
 Durasi waktu maksimum di mana proses bisnis harus
dipulihkan setelah bencana, untuk menghindari konsekuensi
yang tidak dapat diterima (seperti kebangkrutan)

37. RTO dan RPO
 Tujuan Titik Pemulihan (Recovery Point Objective, RPO)
 Titik waktu di mana data harus dipulihkan mengingat beberapa
"kehilangan yang dapat diterima" dalam situasi bencana
 RTO dan RPO adalah tujuan yang berbeda
 Keduanya tidak berhubungan