Menentukan bagaimana Beban Kerja (node) harus didistribusikan adalah topik diskusi umum saat bermigrasi ke cloud publik dengan mempertimbangkan Ketersediaan Tinggi. Jika beban kerja berada dalam lingkungan di lokasi, lebih sering daripada tidak lokasi beban kerja ini ditentukan oleh lokasi pusat data yang sudah ada. Dalam banyak kasus, memilih lokasi lain untuk menampung beban kerja bukanlah pilihan yang tersedia. Dengan penawaran cloud publik, ada berbagai wilayah geografis serta zona ketersediaan untuk dipilih.

Availability Zone umumnya dianalogikan dengan satu atau lebih pusat data (lokasi fisik) yang terletak di wilayah fisik yang sama (misalnya, di California). Pusat data ini mungkin terletak di area yang berbeda tetapi terhubung menggunakan jaringan berkecepatan tinggi untuk meminimalkan latensi koneksi di antara mereka. (Perhatikan bahwa layanan hosting di beberapa pusat data dalam wilayah ketersediaan harus transparan bagi pengguna).

Sebagai aturan umum, semakin besar jarak fisik antara beban kerja, lingkungan menjadi lebih tangguh. Asumsi yang masuk akal adalah bahwa bencana alam seperti gempa bumi tidak akan mempengaruhi wilayah yang berbeda pada saat yang sama (misalnya, pantai barat AS dan pantai timur pada waktu yang sama). Namun, masih ada kemungkinan mengalami pemadaman layanan di berbagai wilayah secara bersamaan karena kegagalan di seluruh sistem (beberapa penyedia cloud sebelumnya telah melaporkan pemadaman lintas wilayah secara simultan seperti di AS & Australia). Mungkin tepat untuk mempertimbangkan membuat rencana DR (pemulihan bencana) yang ditentukan di berbagai penyedia cloud.

Perspektif lain yang layak dipertimbangkan adalah biaya untuk melindungi sumber daya. Umumnya semakin besar jarak antara beban kerja, semakin banyak biaya yang dikeluarkan untuk transfer data. Dalam banyak kasus, transfer data antar node dalam pusat data yang sama (Availability Zone) tidak dipungut biaya, meskipun mungkin memerlukan biaya $0,01/GB atau lebih untuk mentransfer data di seluruh Availability Zone. Biaya tambahan ini mungkin berlipat ganda (atau lebih) bila data ditransfer lintas wilayah (yaitu $0,02 / GB). Selain itu, karena peningkatan jarak fisik antara beban kerja, latensi data yang lebih besar antar node harus diantisipasi antar lokasi. Melalui pertimbangan faktor-faktor ini, secara umum, disarankan untuk mendistribusikan beban kerja di Availability Zone dalam Wilayah yang sama.

Ketersediaan Tinggi, RTO, dan RPO

Ketersediaan tinggi (HA) adalah istilah teknologi informasi yang mengacu pada perangkat lunak atau komponen komputer yang beroperasi dan tersedia lebih dari 99,99% sepanjang waktu. Pengguna akhir aplikasi, atau sistem, mengalami gangguan layanan kurang dari 52,5 menit per tahun. Tingkat ketersediaan ini biasanya dicapai melalui penggunaan pengelompokan ketersediaan tinggi, konfigurasi yang mengurangi waktu henti aplikasi dengan menghilangkan titik kegagalan tunggal melalui penggunaan server, jaringan, penyimpanan, dan perangkat lunak yang berlebihan.

Apa tujuan waktu pemulihan ( RTO ) dan tujuan titik pemulihan ( RPO )?

Selain 99,99% waktu ketersediaan, lingkungan ketersediaan tinggi juga memenuhi tujuan waktu pemulihan dan titik pemulihan yang ketat. Tujuan waktu pemulihan ( RTO ) adalah ukuran waktu yang berlalu dari kegagalan aplikasi hingga pemulihan operasi dan ketersediaan aplikasi. Ini adalah ukuran seberapa lama perusahaan mampu untuk menghentikan aplikasi itu. Tujuan titik pemulihan ( RPO ) adalah ukuran seberapa mutakhir data saat ketersediaan aplikasi telah dipulihkan setelah masalah waktu henti. Hal ini sering digambarkan sebagai jumlah maksimum kehilangan data yang dapat ditoleransi ketika terjadi kegagalan.SIOS cluster ketersediaan tinggi memberikan RPO dari nol dan an RTO menit.

Apa itu cluster ketersediaan tinggi?

Dalam cluster ketersediaan tinggi, aplikasi penting dijalankan pada node server utama, yang terhubung ke satu atau lebih node sekunder untuk redundansi. Perangkat lunak pengelompokan, seperti SIOS LifeKeeper, memantau aplikasi berkerumun dan sumber daya yang bergantung untuk memastikan mereka beroperasi pada node aktif. Pemantauan tingkat sistem dilakukan melalui detak jantung interval antara node cluster. Jika server utama gagal, server sekunder memulai pemulihan setelah interval waktu habis detak jantung terlampaui. Untuk kegagalan tingkat aplikasi, perangkat lunak pengelompokan mendeteksi bahwa aplikasi tidak tersedia di node aktif. Kemudian memindahkan aplikasi dan sumber daya dependen ke node sekunder dalam proses yang disebut failover, di mana operasi berlanjut dan memenuhi persyaratan ketat. RTO s.

Dalam kluster failover tradisional, semua node dalam kluster terhubung ke penyimpanan bersama yang sama, biasanya jaringan area penyimpanan ( SAN ). Setelah failover, node sekunder diberikan akses ke penyimpanan bersama, memungkinkannya memenuhi persyaratan ketat RPO s.