Bagaimana Memilih Awan Saat Anda Membutuhkan Ketersediaan Tinggi

Bagaimana Memilih Awan Saat Anda Membutuhkan Ketersediaan Tinggi

Pahami pasar cloud

Sejumlah firma analis memperkirakan jumlah penerapan aplikasi, database, dan solusi yang terus meningkat di cloud. Menurut Gartner, perusahaan "beralih ke cloud dengan kecepatan yang men^[1]ingkat". Faktanya, Gartner dan analis lainnya memperkirakan laju migrasi dan penerapan cloud akan terus meningkat, sebagian besar didorong oleh laju inovasi di cloud. Dalam artikel TechTarget oleh Kurt Marko, dari MarkoInsights, Marko mencatat bahwa laju inovasi yang "dilakukan di cloud kemungkinan tidak dapat direplikasi di tempat karena sifat cloud publik terkelola yang elastis, dapat diskalakan, dan sesuai permintaan. jasa."

Kami melihat semakin banyak perusahaan yang selama ini menggunakan cloud hanya untuk aplikasi DevOps dan database yang tidak penting untuk bisnis mereka, kini memindahkan aplikasi, ERP, dan database misi penting yang memerlukan perlindungan ketersediaan tinggi ke cloud.

Jika Anda sedang mempertimbangkan untuk pindah ke cloud – dan sepertinya memang demikian – ada beberapa kunci yang perlu dipahami saat Anda membutuhkan ketersediaan tinggi.

Biasakan diri Anda dengan opsi ketersediaan tinggi cloud

Untuk merencanakan solusi ketersediaan yang tepat untuk cloud atau penerapan cloud hybrid, pertimbangkan apa saja poin masalah terkait dengan ketersediaan (99,9% waktu aktif) dan ketersediaan tinggi (99,99% waktu aktif). Anda juga perlu memahami opsi yang tersedia untuk ketersediaan tinggi dengan memperhatikan rencana Anda untuk bermigrasi ke cloud. Analis dan pakar terkemuka menyarankan untuk mencari solusi yang tidak hanya akan mengurangi dan mengurangi rasa sakit saat memigrasi beban kerja Anda, tetapi juga akan memberikan pendekatan yang seimbang dan komprehensif untuk ketersediaan di seluruh masa pakai arsitektur cloud Anda. Perhatikan, sebaiknya pertimbangkan juga solusi yang dapat memberikan perlindungan dan ketersediaan tinggi untuk sebagian dari beban kerja Anda yang suatu hari dapat dikembalikan dari cloud ke lingkungan lokal Anda.

Berikut sepuluh hal yang perlu dipertimbangkan saat membandingkan opsi ketersediaan Anda di cloud:

1. Metode penerapan. Apakah mungkin untuk menerapkan solusi ketersediaan yang Anda pertimbangkan menggunakan gambar, CLI, UI, atau solusi berulang lainnya seperti template pembentukan awan atau skrip paket.

2. Persyaratan sistem.Terutama, pertimbangkan persyaratan sistem operasi (OS), disk, CPU, dan memori.

3. Lingkungan penerapan.Apakah opsi ketersediaan Anda hanya mendukung lokal, satu atau beberapa cloud publik, atau dapatkah mereka mendukung campuran, dan / atau penyebaran cloud hybrid. Apakah ada penawaran SaaS juga tersedia?

4. Luas dan kedalaman perlindungan aplikasi. “Breadth” artinya jenis aplikasi, database, front-end, jaringan, dan komponen infrastruktur apa yang dapat dilindungi?Apakah ada kerangka kerja yang fleksibel untuk menambahkan aplikasi dan varian baru? Arti “Kedalaman” – apakah solusinya sadar aplikasi – dan mampu mempertahankan praktik terbaik khusus aplikasi selama proses failover / failback aplikasi?

5. Persyaratan kinerja. Kami sering memikirkan RTO dan RPO, tetapi bagaimana dengan kinerja lain yang membutuhkan solusi Anda. Akankah solusi ketersediaan Anda menyebabkan masalah kinerja saat failover?

6. Persyaratan ketahanan.Seberapa besar cluster yang dapat didukung oleh solusi ketersediaan ?, Berapa banyak kesalahan dan kegagalan yang dapat dideteksi dan dipulihkan. Bagaimana replikasi akan ditangani sambil menjaga metadata tetap sinkron?

7. Dukungan dan pemeliharaan.Apakah vendor ketersediaan memiliki pengalaman dengan berbagai macam kebutuhan dan konfigurasi ketersediaan? Apakah mereka memiliki umur panjang, dan sistem pendukung yang dirancang untuk mengatasi masalah yang mungkin melampaui solusi mereka? Dapatkah mereka membantu Anda meminimalkan gangguan dan waktu henti yang direncanakan selama pengelolaan dan pemeliharaan sistem Anda (tambalan, peningkatan versi, dan pemeliharaan umum).

8. Total biaya kepemilikan.Ada seluruh industri dan layanan yang didedikasikan untuk membantu Anda menghitung total biaya kepemilikan, jadi kami tidak akan membahasnya di sini. Singkatnya, perhitungan Anda akan unik untuk organisasi, penyedia cloud, aplikasi, dan tim TI Anda. Anda harus mempertimbangkan apakah vendor solusi ketersediaan Anda dapat membantu Anda mengidentifikasi strategi untuk menghemat penggunaan, lisensi, dan biaya lainnya? Apakah solusi mengotomatiskan tugas manual, mengurangi waktu kerja TI?

9. Perizinan dan model harga.Bagaimana Anda menggunakan biaya perangkat lunak? Apakah ada biaya langganan, model langganan, penawaran bayar sesuai pemakaian, bawa lisensi Anda sendiri (BYOL), atau kombinasi opsi fleksibel. Bagaimana Anda akan mengaktifkan lisensi produk?Apakah ada server lisensi, layanan lisensi, atau kunci terenkripsi berdasarkan detail penerapan mesin virtual, seperti alamat, nama host, alamat MAC.

10. Dampaknya pada staf TI.Berapa banyak pelatihan dengan solusinya yang dibutuhkan? Berapa banyak intervensi manual yang akan dibutuhkan jika terjadi peristiwa kegagalan aplikasi atau bencana? Apakah ini memerlukan skrip khusus yang perlu dipertahankan? Siapa yang akan bertanggung jawab atas pemeliharaan berkelanjutan?

Pertimbangkan manfaat dan kompromi

Seperti setiap keputusan penting, Anda perlu memahami pengorbanan Anda dan memilih keseimbangan terbaik untuk memenuhi kebutuhan Anda. Misalnya, baru-baru ini saya meminta seorang teman untuk merekomendasikan sepatu jalan yang bagus. Saya membeli sepasang yang dia ocehkan – memperhatikan betapa ringannya mereka, seberapa kuat dan tahan lama kainnya, dan betapa gayanya mereka.Saya pergi untuk lari jarak jauh pertama saya di dalamnya, dan saya segera menyumbangkan sepasang sepatu “satu lari” pertama saya setelah itu. Ketika saya pergi ke 'Fleet Feet' untuk mendapatkan pendapat ahli, saya mendapatkan sepatu yang lebih berat, dengan kain yang lebih bernapas (juga kurang tahan lama), dan tingkat keburukan yang tak tertandingi. Saya melakukan tradeoff antara penampilan dan fungsi yang sesuai dengan kebutuhan dan anggaran saya.

Seperti sepatu lari, tidak ada solusi peluru perak yang sesuai untuk setiap perusahaan, setiap aplikasi, setiap database, dan setiap server dan arsitektur yang memungkinkan. Anda secara resmi bebas untuk berhenti mencarinya. Alih-alih, selesaikan aktivitas menimbang trade-off untuk menentukan apa yang tepat untuk kebutuhan perusahaan Anda. Pikirkan pengorbanan Anda. Misalnya, jika Anda yakin akan menjadi toko Microsoft sepenuhnya, pentingnya dukungan GCP dan AWS seharusnya sedikit lebih rendah dalam proses evaluasi Anda.

Pertimbangkan dinamika infrastruktur TI Anda

Pikirkan secara holistik tentang ketersediaan di seluruh infrastruktur TI Anda – baik di lokasi maupun di cloud. Alasan untuk melakukannya paling baik dijelaskan dengan analogi lain. Pada tahun 2018, saya menjadi koordinator untuk program penjangkauan memberi makan para tunawisma dan kelaparan di Columbia, Carolina Selatan. Kelompok kami bertemu sekali seminggu untuk menyajikan makanan dan pesan harapan kepada lebih dari 100 pria, wanita dan anak-anak. Saat kami mempertimbangkan untuk memperluas – menambahkan lebih banyak hari dalam seminggu, lebih banyak jam, atau layanan tambahan, kami harus memikirkan jauh di luar persyaratan penjadwalan sederhana. Mengetahui bahwa kami memberikan layanan penting kepada klien yang bergantung pada kami, kami harus mempertimbangkan semua faktor yang memengaruhi kemampuan kami untuk memberikan layanan tersebut secara konsisten untuk jangka panjang, seperti: biaya, usia anggota tim kami, kewajiban luar , metode alternatif untuk mencapai tujuan kami, faktor risiko, dan dinamika lain dalam organisasi induk kami.

Saat Anda memilih solusi, setelah Anda memahami pasar, membiasakan diri dengan opsi, dan menimbang kompromi, langkah terakhir adalah memperhitungkan berbagai dinamika lain di lingkungan Anda secara keseluruhan. Akankah solusi tersebut memenuhi kebutuhan bisnis Anda secara keseluruhan? Akankah data penting Anda dilindungi dari kehilangan? Akankah produktivitas pengguna akhir Anda dilindungi dari waktu henti? Pelatihan apa yang akan diperlukan untuk pindah ke cloud dan bagaimana hal itu akan memengaruhi kemampuan Anda untuk mengelola atau mempertahankan solusi yang Anda pilih? Peran TI apa yang akan ditambahkan, dihapus, atau diubah dalam perjalanan cloud Anda?Akankah tanggung jawab untuk ketersediaan aplikasi berpindah ke pemilik lini bisnis mana pun? Dan bagaimana perubahan dalam tanggung jawab, atau pembentukan tim akan meningkatkan atau menurunkan potensi kesuksesan Anda secara keseluruhan. Pertimbangkan apakah tim Anda perlu mengambil pendekatan langkah demi langkah, memigrasi beban kerja yang lebih kecil terlebih dahulu.

Sebagai Wakil Presiden Pengalaman Pelanggan, saya telah melihat berbagai macam perencanaan migrasi cloud – beberapa langsung yang lainnya sangat mengganggu. Dalam satu contoh, perpindahan pelanggan ke cloud sangat kontroversial karena manajemen melihatnya sebagai peluang untuk menghilangkan seluruh departemen TI. Saya tidak menyarankan Anda untuk bermain politik, tetapi Anda harus menyadari semua faktor yang berperan dalam proyek kompleks ini.

Bermigrasi ke cloud diharapkan dapat menghemat uang, waktu, dan sumber daya sambil meningkatkan ketersediaan dan ketahanan. Apa pun cloud yang Anda pilih, pastikan Anda mempertimbangkan tip berikut dan memilih solusi ketersediaan terkait yang memberi Anda fleksibilitas untuk memberikan perlindungan yang Anda butuhkan dalam konfigurasi yang Anda inginkan.

Pelajari lebih lanjut tentang opsi ketersediaan tinggi cloud dengan SIOS.

– Cassius Rhue, Wakil Presiden Pengalaman Pelanggan, SIOS

Direproduksi dengan izin dari SIOS

Cara Mengkloning Ketersediaan Di Cloud Dengan Hasil Lebih Baik

Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1

Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1

SIOS terus memperbarui produk kami untuk memenuhi kebutuhan pelanggan yang terus berkembang akan ketersediaan tinggi untuk aplikasi penting. Kami sangat senang mengumumkan ketersediaan umum SIOS Protection Suite untuk Linux versi 9.5.1!Fitur rilis ini menambahkan dukungan untuk lebih banyak jenis platform dan penyempurnaan pada fitur antarmuka baris perintah kami.

• • • Dukungan untuk sistem operasi dan platform berikut: VMware Vsphere 7, Red Hat Enterprise Linux (RHEL) 8.2, Oracle Linux 8.2, CentOS 8.2, SUSE Linux Enterprise (SLES) 12 SP5, RHEL 7.8, CentOS 7.8, Oracle Linux 7.8, SLES 15 SP2
    • CLI Auto Install dengan skrip pengaturan yang ditingkatkan – untuk implementasi yang lebih cepat dan mudah
    • Dukungan CLI yang diperluas untuk ARK dan Kloning – memungkinkan penerapan beberapa klaster yang sederhana dan konsisten

Direproduksi dengan izin dari SIOS

Enam Alasan Migrasi Cloud Anda Terhenti

Direproduksi dari SIOS

Menghitung Ketersediaan Aplikasi di Cloud

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.