Opsi untuk Saat Tingkat Layanan Cloud Publik Gagal

Semua penyedia layanan cloud publik menawarkan beberapa bentuk jaminan terkait ketersediaan. Ini mungkin atau mungkin tidak cukup, tergantung pada persyaratan setiap aplikasi untuk waktu aktif. Jaminan ini biasanya berkisar dari 95,00% hingga 99,99% dari waktu aktif selama sebulan. Sebagian besar memaksakan beberapa jenis "penalti" pada penyedia layanan karena gagal memenuhi ambang tersebut. Biasanya, sebagian besar penyedia layanan cloud menawarkan batas waktu aktif 99,00%. Ini sama dengan sekitar tujuh jam downtime per bulan. Dan untuk banyak aplikasi, kedua-9 itu mungkin sudah cukup. Tetapi untuk aplikasi yang sangat penting, diperlukan lebih banyak 9. Terutama mengingat kenyataan bahwa banyak penyebab umum waktu henti tidak termasuk dalam jaminan. Ada, tentu saja, cara yang hemat biaya untuk mencapai ketersediaan tinggi dan perlindungan pemulihan bencana yang tangguh di konfigurasi dengan menggunakan layanan cloud publik, baik secara eksklusif atau sebagai bagian dari pengaturan hybrid. Artikel ini menyoroti keterbatasan yang melibatkan ketentuan HA dan DR di cloud publik. Ini mengeksplorasi tiga opsi untuk mengatasi keterbatasan ini, dan menjelaskan dua konfigurasi umum untuk kluster failover.

Caveat Emptor in the Cloud

Sementara semua penyedia layanan cloud (CSP) mendefinisikan "waktu henti" atau "tidak tersedia" agak berbeda, definisi ini hanya mencakup sekumpulan terbatas semua kemungkinan penyebab kegagalan pada tingkat aplikasi. Secara umum termasuk kegagalan yang mempengaruhi zona atau wilayah, atau konektivitas eksternal. Semua CSP juga menawarkan kredit mulai dari 10% karena gagal memenuhi empat-9 uptime hingga sekitar 25% karena gagal memenuhi dua-9 uptime. Sumber daya redundan dapat dikonfigurasikan untuk menjangkau zona dan / atau wilayah dalam infrastruktur CSP. Ini akan membantu meningkatkan ketersediaan tingkat aplikasi. Tetapi bahkan dengan redundansi seperti itu, masih ada beberapa keterbatasan yang sering tidak dapat diterima untuk aplikasi mission-critical. Terutama mereka yang membutuhkan kinerja throughput transaksional tinggi. Batasan ini mencakup setiap master yang hanya dapat membuat replika failover tunggal. Dan itu membutuhkan penggunaan dataset master untuk cadangan, dan menggunakan log peristiwa untuk mereplikasi data. Batasan ini dan lainnya dapat meningkatkan waktu pemulihan selama kegagalan dan membuatnya perlu untuk menjadwalkan setidaknya beberapa waktu henti yang direncanakan.

Keterbatasan yang Signifikan

Keterbatasan yang lebih signifikan melibatkan banyak pengecualian untuk apa yang merupakan downtime. Berikut adalah beberapa contoh dari perjanjian Level Layanan Cloud Publik aktual tentang apa yang dikecualikan dari "waktu henti" atau "tidak tersedianya" yang menyebabkan kegagalan tingkat aplikasi yang diakibatkan dari:

• faktor-faktor di luar kendali wajar CSP (dengan kata lain, beberapa hal yang terjadi secara teratur, seperti pemadaman jaringan operator dan bencana alam)
• perangkat lunak pelanggan, atau perangkat lunak atau teknologi pihak ketiga, termasuk perangkat lunak aplikasi
• input atau instruksi yang salah, atau kurangnya tindakan saat diperlukan (dengan kata lain, kesalahan tak terhindarkan yang disebabkan oleh kesalahan manusia)
• masalah dengan instance atau volume individual yang tidak disebabkan oleh keadaan khusus “tidak tersedianya”
• setiap pemeliharaan perangkat keras atau perangkat lunak sebagaimana disediakan sesuai dengan perjanjian

Yang pasti, masuk akal bagi CSP untuk mengecualikan penyebab kegagalan tertentu. Tetapi administrator sistem tidak bertanggung jawab untuk menggunakan ini sebagai alasan. Penting untuk memastikan ketersediaan tingkat aplikasi dengan beberapa cara lain.

Apa Tingkat Layanan Cloud Publik Yang Tersedia?

Menyediakan sumber daya untuk ketersediaan tinggi dengan cara yang tidak mengorbankan keamanan atau kinerja tidak pernah menjadi upaya sepele. Tantangannya terutama sulit di lingkungan cloud hybrid di mana infrastruktur cloud pribadi dan publik dapat berbeda secara signifikan. Itu membuat konfigurasi sulit untuk diuji dan dipelihara. Lebih jauh lagi, hal itu dapat mengakibatkan ketentuan failover gagal ketika benar-benar dibutuhkan. Untuk aplikasi di mana tingkat layanan yang ditawarkan oleh CSP gagal, ada tiga opsi tambahan yang tersedia berdasarkan aplikasi itu sendiri, fitur dalam sistem operasi, atau melalui penggunaan perangkat lunak pengelompokan failover yang dibangun khusus.

Tiga Pilihan untuk Meningkatkan Ketersediaan Tingkat Aplikasi

HA / DR

Opsi HA / DR yang tampaknya paling mudah diterapkan adalah yang dirancang khusus untuk setiap aplikasi. Contoh yang baik adalah basis data SQL Server Microsoft dengan fitur Selalu Di Ketersediaan Grup kelasnya. Namun, ada dua kelemahan dari pendekatan ini. Biaya lisensi yang lebih tinggi, dalam hal ini untuk Edisi Enterprise, dapat membuatnya sangat mahal untuk banyak kebutuhan. Dan kerugian yang lebih meresahkan adalah perlunya ketentuan HA / DR yang berbeda untuk aplikasi yang berbeda, yang membuat manajemen yang berkelanjutan menjadi perjuangan yang konstan (dan mahal).

Fitur Terkait Waktu Kerja Yang Terintegrasi ke Dalam Sistem Operasi

Opsi kedua untuk meningkatkan Tingkat Layanan Cloud Publik mencakup penggunaan fitur-fitur terkait uptime yang diintegrasikan ke dalam sistem operasi. Windows Server Failover Clustering, misalnya, adalah fitur yang kuat dan terbukti yang dibangun ke dalam OS. Tetapi dengan sendirinya, WSFC mungkin tidak menyediakan solusi HA / DR yang lengkap karena tidak memiliki fitur replikasi data. Dalam cloud pribadi, replikasi data dapat disediakan menggunakan beberapa bentuk penyimpanan bersama, seperti jaringan area penyimpanan. Tetapi karena penyimpanan bersama tidak tersedia di cloud publik, menerapkan replikasi data yang kuat membutuhkan penggunaan perangkat lunak komersial atau kustom yang dikembangkan terpisah. Untuk Linux, yang tidak memiliki fitur seperti WSFC, kebutuhan untuk ketentuan HA / DR tambahan dan / atau pengembangan kustom jauh lebih besar. Menggunakan perangkat lunak sumber terbuka seperti Pacemaker dan Corosync membutuhkan pembuatan (dan pengujian) skrip khusus untuk setiap aplikasi. Skrip-skrip ini seringkali perlu diperbarui dan diuji ulang bahkan setelah perubahan kecil dilakukan pada perangkat lunak atau perangkat keras apa pun yang digunakan. Tetapi karena mendapatkan tumpukan HA penuh untuk bekerja dengan baik untuk setiap aplikasi bisa menjadi sangat sulit, hanya organisasi yang sangat besar yang membutuhkan bahkan untuk mempertimbangkan mengambil upaya.

Cluster Failover yang Dibangun Khusus

Idealnya akan ada pendekatan "universal" untuk HA / DR yang mampu bekerja dengan biaya efektif untuk semua aplikasi yang berjalan di Windows atau Linux di cloud publik, pribadi dan hybrid. Di antara solusi yang paling fleksibel dan terjangkau adalah pilihan ketiga: cluster failover yang dibangun khusus. Solusi HA / DR ini diimplementasikan sepenuhnya dalam perangkat lunak yang dirancang khusus untuk membuat, sesuai dengan peruntukannya, sekelompok server virtual atau fisik dan penyimpanan data dengan failover dari instance aktif atau primer ke siaga untuk memastikan ketersediaan tinggi pada aplikasi. tingkat.

Manfaat Solusi Ini

Solusi-solusi ini menyediakan, sekurang-kurangnya, kombinasi replikasi data waktu-nyata, pemantauan aplikasi terus-menerus dan kebijakan pemulihan gagal / gagal yang dapat dikonfigurasi. Beberapa yang lebih kuat menawarkan kemampuan canggih tambahan, seperti pilihan replikasi sinkron atau asinkron tingkat blok, dukungan untuk Failover Cluster Instances (FCIs) dalam SQL Server Edisi Standar yang lebih murah, optimalisasi WAN untuk peningkatan kinerja dan bandwidth minimal. pemanfaatan, dan peralihan manual penugasan server primer dan sekunder untuk memfasilitasi pemeliharaan yang direncanakan. Meskipun solusi tujuan umum ini umumnya agnostik-penyimpanan, memungkinkan mereka untuk bekerja dengan jaringan area penyimpanan, kluster failover SANless-shared tanpa apa-apa biasanya dipilih berdasarkan kemampuan mereka untuk menghilangkan titik kegagalan tunggal yang potensial.

Dua Konfigurasi Clustering Kegagalan Umum

Setiap kluster failover terdiri dari dua node atau lebih. Menemukan setidaknya satu node di pusat data yang berbeda diperlukan untuk melindungi dari bencana lokal. Berikut ini adalah dua konfigurasi populer: satu untuk keperluan pemulihan bencana; yang lain untuk menyediakan ketersediaan tinggi yang kritis-misi dan pemulihan bencana. Kinerja transaksional yang tinggi sering kali merupakan persyaratan untuk konfigurasi yang sangat tersedia. Contoh aplikasi adalah database. Cluster failover SANless dasar untuk pemulihan bencana memiliki dua node dengan satu server primer atau server sekunder atau siaga. Konfigurasi minimal ini juga membutuhkan simpul ketiga atau instance untuk berfungsi sebagai saksi, yang diperlukan untuk mencapai kuorum untuk menentukan penugasan primer. Untuk aplikasi basis data, replikasi ke instance siaga di WAN tidak sinkron untuk mempertahankan kinerja tinggi pada instance primer. Cluster failover SANless menghasilkan pemulihan cepat jika terjadi kegagalan pada primer. Menghasilkan konfigurasi DR dasar yang cocok untuk banyak aplikasi. Ia mampu mendeteksi hampir semua kemungkinan kegagalan, termasuk yang tidak dihitung sebagai downtime dalam layanan cloud publik. Dengan demikian itu akan bekerja di lingkungan cloud pribadi, publik atau hybrid. Sebagai contoh, primer bisa di pusat data perusahaan dengan yang sekunder ditempatkan di cloud publik. Karena instance cloud publik hanya akan diperlukan selama pemeliharaan terencana dari primer atau jika terjadi kegagalan — kondisi yang dapat dengan cepat diatasi — pembatasan layanan dan pengecualian yang disebutkan di atas mungkin dapat diterima untuk semua tetapi yang paling kritis terhadap misi aplikasi.

Cluster failover SANless tiga simpul ini memiliki satu instance server aktif dan dua server siaga. Ia mampu menangani dua kegagalan bersamaan dengan downtime minimal dan tanpa kehilangan data. [/ Caption] Angka tersebut menunjukkan cluster failover SANless tiga simpul yang disempurnakan yang memberikan ketersediaan tinggi dan perlindungan bencana yang kuat, baik pada 5-9 dan perlindungan pemulihan bencana yang kuat. Seperti halnya kluster dua-simpul, konfigurasi ini juga akan berfungsi di lingkungan cloud pribadi, publik, atau hibrid. Dalam contoh ini, server # 1 dan # 2 terletak di pusat data perusahaan dengan server # 3 di cloud publik. Dalam pusat data, replikasi di LAN dapat sepenuhnya sinkron untuk meminimalkan waktu yang diperlukan untuk menyelesaikan failover. Karena itu, maksimalkan ketersediaan. Ketika dikonfigurasikan dengan benar, kluster failover SANless tiga-node menghasilkan HA dan DR kelas carrier yang sesungguhnya. Operasi dasarnya adalah agnostik aplikasi dan berfungsi sama untuk Windows atau Linux. Server # 1 pada awalnya adalah instance primer atau aktif yang mereplikasi data terus menerus ke kedua server # 2 dan # 3. Jika mengalami kegagalan, aplikasi akan secara otomatis failover ke server # 2, yang kemudian akan menjadi data replikasi utama ke server # 3.

Pemulihan

Segera setelah kegagalan di server # 1, staf TI akan mulai mendiagnosis dan memperbaiki apa pun yang menyebabkan masalah. Setelah diperbaiki, server # 1 dapat dikembalikan sebagai primer dengan failback manual, atau server # 2 dapat terus berfungsi sebagai data replikasi primer ke server # 1 dan # 3. Jika server # 2 gagal sebelum server # 1 dikembalikan ke operasi, seperti yang ditunjukkan, server # 3 akan menjadi yang utama. Karena server # 3 berada di seberang WAN di cloud publik, replikasi data tidak sinkron dan failover bersifat manual untuk mencegah "penundaan replikasi" menyebabkan hilangnya data apa pun. Perangkat lunak clustering failover SANless mampu mendeteksi semua kemungkinan kegagalan pada tingkat aplikasi. Ini mudah mengatasi keterbatasan dan pengecualian CSP yang disebutkan di atas. Jadi, memungkinkan konfigurasi tiga simpul ini untuk digunakan sepenuhnya dalam cloud publik. Untuk mendapatkan ketersediaan tinggi lima-9 yang sama berdasarkan kegagalan langsung dan otomatis, server # 1 dan # 2 perlu ditempatkan dalam satu zona atau wilayah di mana LAN memfasilitasi replikasi sinkron. Untuk perlindungan DR yang tepat, server # 3 harus ditempatkan di pusat data atau wilayah yang berbeda, di mana penggunaan replikasi asinkron dan failover / failback manual akan diperlukan untuk aplikasi yang memerlukan throughput transaksional tinggi. Cluster tiga simpul juga dapat memfasilitasi pemeliharaan perangkat keras dan perangkat lunak yang direncanakan untuk ketiga server. Pada saat yang sama, terus memberikan perlindungan DR berkelanjutan untuk aplikasi dan datanya. Dengan menawarkan beberapa pusat data yang tersebar secara geografis, cloud publik memberikan banyak peluang untuk meningkatkan ketersediaan dan meningkatkan ketentuan DR. Perangkat lunak SAN failover clustering membuat penggunaan semua sumber daya komputasi, penyimpanan, dan jaringan menjadi efektif dan efisien. Ini juga mudah diimplementasikan dan dioperasikan. Solusi yang dibangun khusus ini meminimalkan semua pengeluaran modal dan operasional. Akhirnya, menghasilkan ketersediaan tinggi menjadi lebih kuat dan lebih terjangkau daripada sebelumnya. # # #

tentang Penulis

Cassius Rhue adalah Direktur Teknik di SIOS Technology.  Dia memimpin pengembangan produk perangkat lunak dan tim teknik di Lexington, SC. Cassius memiliki lebih dari 17 tahun pengalaman rekayasa perangkat lunak, pengembangan dan pengujian. Dia juga memegang gelar BS di bidang Teknik Komputer dari University of South Carolina.