Date: Desember 18, 2020
Menghitung Ketersediaan Aplikasi di Cloud
Saat menerapkan aplikasi bisnis penting di cloud, Anda ingin memastikan ketersediaannya sangat tinggi. Kabar baiknya adalah jika Anda merencanakan dengan benar, Anda dapat mencapai 99,99% (4-sembilan) ketersediaan atau lebih. Namun, menghitung ketersediaan Anda yang sebenarnya mungkin tidak sesederhana kelihatannya.
Saat mempertimbangkan ketersediaan, Anda harus mempertimbangkan komponen utama yang memungkinkan akses ke aplikasi Anda, yang akan saya sebut rantai ketersediaan. Komponen rantai ketersediaan adalah:
- Menghitung
- Jaringan
- Penyimpanan
- Aplikasi
- Layanan yang bergantung
Aplikasi Anda hanya tersedia sebagai tautan terlemah Anda, dan waktu henti Anda meningkat secara eksponensial dengan setiap tautan tambahan yang Anda tambahkan ke rantai.Mari kita periksa setiap tautan.
Hitung Ketersediaan
Masing-masing dari tiga penyedia layanan cloud utama memiliki beberapa kesamaan. Satu kesamaan di ketiga platform adalah perjanjian tingkat layanan (SLA) yang akan mereka janjikan untuk komputasi.
SLA untuk ketiga penyedia cloud publik untuk VM saat Anda memiliki dua atau lebih VM yang dikonfigurasi di berbagai zona ketersediaan adalah 99,99%.Perlu diingat, SLA ini hanya menjamin aksesibilitas jarak jauh dari salah satu VM pada waktu tertentu, SLA tidak menjanjikan ketersediaan layanan atau aplikasi yang berjalan di dalam VM.Jika Anda menerapkan satu VM dalam satu pusat data, SLA ini bervariasi dari "90% setiap jam" (AWS) hingga 99,5% (Azure dan GCP) atau 99,9% (VM tunggal Azure saat menggunakan SSD Premium).
Ketersediaan tinggi sebenarnya dimulai dari 99,99%, jadi langkah pertama adalah memastikan aplikasi Anda tersedia adalah memastikan aplikasi didistribusikan ke dua atau lebih VM yang menjangkau zona ketersediaan. Dengan dua VM yang tersebar di dua zona ketersediaan, yang memberi Anda 99,99% ketersediaan dari setidaknya satu VM tersebut, Anda dapat berteori bahwa jika Anda memiliki tiga VM yang tersebar di tiga zona ketersediaan, ketersediaan Anda akan lebih besar dari 99,99%. Meskipun SLA penyedia cloud tidak akan pernah menjamin melebihi ketersediaan 99,99% terlepas dari jumlah zona ketersediaan yang digunakan, jika Anda menggunakan statistik murni, Anda mungkin sampai pada kesimpulan bahwa ketersediaan Anda dapat melonjak hingga 99,9999999% atau 8-sembilan dari ketersediaan, waktu henti 26,30 milidetik per bulan.
1 – (. 0001 * .0001) = .99999999
99,999999% ketersediaan dengan tiga zona ketersediaan?
Jangan seenaknya mengutip angka itu. Namun perlu diingat bahwa masuk akal jika dua zona ketersediaan dapat memberi Anda ketersediaan 99,99%. Masuk akal bahwa tiga zona ketersediaan akan memberi Anda sesuatu yang secara signifikan lebih dari 99,99% ketersediaan.
Hitung hanyalah salah satu tautan dalam rantai ketersediaan. Kami masih harus menangani jaringan, penyimpanan, dan layanan lain yang bergantung, yang semuanya mewakili kemungkinan titik kegagalan.
Ketersediaan Jaringan
Agar aplikasi Anda tersedia, setiap hop jaringan antara klien dan aplikasi dan semua sumber daya yang bergantung pada aplikasi, harus tersedia dan bekerja dalam rentang latensi yang dapat ditoleransi. Anda perlu memahami tautan jaringan antara server basis data, server aplikasi, server web, dan klien untuk mengetahui dengan tepat di mana jaringan mungkin gagal. Ingat, semakin banyak tautan dalam rantai ketersediaan Anda, semakin rendah ketersediaan Anda secara keseluruhan.
Meskipun ketersediaan jaringan antara VM dalam vNet yang sama tercakup dalam SLA komputasi standar, ada layanan jaringan lain yang mungkin Anda gunakan. Berikut adalah beberapa contoh layanan jaringan yang dapat Anda manfaatkan yang akan memengaruhi ketersediaan aplikasi secara keseluruhan.
Rute Ekspres – 99,95%
Gerbang VPN – 99,9% hingga 99,95%
Load Balancer – 99,99%
Manajer Lalu Lintas – 99,99%
Penyeimbang Beban Elastis – 99,99%
Sambungan Langsung – 99,9% – 99,99%
Berdasarkan apa yang telah kita pelajari sejauh ini, mari kita lihat ketersediaan aplikasi yang diterapkan di dua zona ketersediaan.
Ketersediaan komputasi 99,99%
Ketersediaan penyeimbang beban 99,99%
.9999 * .9999 = .9998
Ketersediaan 99,98% = ~ 9 menit waktu henti per bulan
Sekarang setelah kita membahas ketersediaan komputasi dan jaringan, mari beralih ke penyimpanan.
Ketersediaan Penyimpanan
Sekarang di sinilah ceritanya menjadi sedikit berbulu. Lihat SLA penyimpanan berikut
https://azure.microsoft.com/en-us/support/legal/sla/storage/v1_5/
https://cloud.google.com/storage/sla
https://aws.amazon.com/compute/sla/
Tampaknya cukup jelas bahwa Azure dan Google memberi Anda SLA 99,9% pada solusi penyimpanan blok. AWS tidak menyebutkan EBS secara khusus di sini. Mereka hanya berbicara tentang VM dan mengukur ketersediaan VM instance tunggal mereka menurut jam, bukan menurut bulan seperti yang dilakukan penyedia cloud lainnya. Demi diskusi, mari gunakan jaminan ketersediaan 99,9% yang telah dipublikasikan oleh Azure dan GCP.
Membangun dari contoh kita sebelumnya, mari tambahkan beberapa penyimpanan ke persamaan.
Ketersediaan komputasi 99,99%
Ketersediaan penyeimbang beban 99,99%
99,9% disk yang dikelola
.9999 * .9999 * .999 = .9988
Ketersediaan 99,88% = ~ 53 menit waktu henti per bulan.
Waktu henti 53 menit jauh lebih banyak daripada waktu henti 9 menit yang kami hitung di contoh sebelumnya. Apa yang dapat kita lakukan untuk meminimalkan dampak dari ketersediaan penyimpanan 99,9%? Kami harus membangun lebih banyak redundansi dalam penyimpanan!
Untungnya, kami biasanya menyertakan redundansi penyimpanan saat merencanakan ketersediaan aplikasi. Misalnya, saat kami menyiapkan server web, setiap server web biasanya akan menyimpan data pada disk yang terpasang secara lokal. Saat menyebarkan pengontrol domain, Microsoft Active Directory menangani penggandaan informasi AD di semua pengontrol domain. Dalam kasus seperti SQL Server, kami memanfaatkan Grup Ketersediaan Selalu Aktif atau SIOS DataKeeper untuk menjaga data tetap sinkron di seluruh disk yang terpasang secara lokal.
Semakin banyak salinan data yang telah kami distribusikan ke berbagai zona ketersediaan, semakin besar kemungkinan kami dapat bertahan dari kegagalan.
Misalnya, aplikasi yang menyimpan datanya di dua disk yang berbeda di zona ketersediaan yang berbeda akan mendapatkan keuntungan dari redundansi dan daripada ketersediaan 99,9%, aplikasi tersebut lebih cenderung mencapai ketersediaan penyimpanan sebesar 99,9999%.
1 – (.001 * .001) = .999999
Jika kita memasukkannya ke persamaan sebelumnya, gambar mulai terlihat sedikit lebih cerah.
.9999 * .9999 * .999999 = .9998
Ketersediaan 99,98% = ~ 9 menit waktu henti
Dengan menduplikasi data di beberapa AZ, dan oleh karena itu, beberapa disk, kami telah secara efektif mengurangi waktu henti yang terkait dengan penyimpanan cloud.
Ketersediaan Aplikasi Dan Layanan Bergantung
Anda telah melakukan semua yang dapat Anda lakukan untuk memastikan ketersediaan komputasi, jaringan, dan penyimpanan. Tapi bagaimana dengan aplikasinya sendiri? Beberapa aplikasi dapat menskalakan dan menyediakan redundansi dengan load balancing antara beberapa contoh aplikasi yang sama. Pikirkan pertanian server web tipikal Anda di mana Anda biasanya dapat memuat permintaan web keseimbangan antara lima server. Jika Anda kehilangan satu server, penyeimbang beban hanya menghapusnya dari rotasinya hingga kembali responsif.
Aplikasi lain membutuhkan lebih banyak perawatan dan pemantauan. Ambil contoh SQL Server. Biasanya Grup Ketersediaan Selalu Aktif atau Mesin Virtual Failover Cluster digunakan untuk memantau ketersediaan database dan melakukan tindakan pemulihan jika database menjadi tidak responsif karena kegagalan tingkat aplikasi atau sistem. Meskipun tidak ada SLA yang diterbitkan untuk solusi ketersediaan SQL Server, secara umum diterima bahwa ketika dikonfigurasi dengan benar untuk ketersediaan tinggi, SQL Server dapat menyediakan ketersediaan 99,99%.
Anda dapat mengandalkan layanan berbasis cloud lainnya, seperti Active Directory yang dihosting, DNS yang dihosting, layanan mikro, atau bahkan ketersediaan portal cloud itu sendiri, semuanya harus diperhitungkan dalam persamaan ketersediaan Anda secara keseluruhan.
Ringkasan
Ketersediaan aplikasi adalah jumlah dari semua bagian yang bergerak. Menghemat hanya di satu area dapat secara eksponensial memengaruhi ketersediaan aplikasi Anda secara keseluruhan. Luangkan waktu Anda dan selidiki semua tautan dalam rantai ketersediaan Anda untuk menemukan kelemahan termasuk komputasi, jaringan, penyimpanan, aplikasi, dan layanan yang bergantung.
Secara umum, angka yang disajikan di sini mudah-mudahan merupakan skenario kasus terburuk dan ketersediaan Anda yang sebenarnya harus melebihi SLA yang dipublikasikan. Kerjakan pekerjaan rumah Anda dan waspadalah terhadap layanan apa pun yang tidak dapat menjamin ketersediaan 99,99%, ambang umum dari apa yang dianggap sangat tersedia.
Kesalahan manusia dan keamanan tidak dibahas dalam artikel ini. Anda dapat membuat aplikasi Anda tersedia semaksimal mungkin. Namun, jika Anda belum mengambil langkah untuk mengamankan aplikasi Anda dari ancaman eksternal dan kesalahan manusia yang bodoh, maka semua taruhan dibatalkan dalam hal ketersediaan.