Apa itu redundansi, replikasi, dan cadangan?

Kita sering berpikir tentang cloud sebagai sistem yang didistribusikan secara global dan di mana-mana. Namun, pada kenyataannya cloud terdiri dari perangkat keras yang berjalan di pusat data. Ketahanan mengharuskan Anda memperhitungkan beberapa risiko yang terkait dengan lokasi fisik tempat komponen yang dihosting cloud Anda berjalan.

Artikel ini memberikan pengenalan umum tentang redundansi, replikasi, dan pencadangan, yang merupakan metode yang digunakan untuk membuat beban kerja yang tahan terhadap risiko fisik menyebabkan gangguan layanan, pemadaman, atau kehilangan data.

Redundansi adalah kemampuan untuk mempertahankan beberapa salinan identik dari komponen layanan, dan untuk menggunakan salinan tersebut dengan cara yang mencegah satu komponen menjadi satu titik kegagalan.

Replikasi atau redundansi data adalah kemampuan untuk mempertahankan beberapa salinan data, yang disebut replika.

Pencadangan adalah kemampuan untuk mempertahankan salinan data bertanda waktu yang dapat digunakan untuk memulihkan data yang telah hilang.

Dari perspektif keandalan, cara penting untuk mengurangi banyak risiko adalah dengan menyertakan beberapa bentuk redundansi, replikasi, atau pencadangan dalam perencanaan kelangsungan bisnis Anda.

Nota

Artikel ini tidak menyediakan panduan desain atau informasi terperinci tentang layanan Azure individual. Untuk informasi tentang cara kerja layanan Azure tertentu dari perspektif keandalan, lihat panduan keandalan setiap layanan.

Pemborosan

Redundansi melibatkan penyebaran beberapa instans dari komponen. Meskipun redundansi mudah dipahami, dalam beberapa situasi, itu bisa menjadi kompleks untuk diterapkan.

Ketika mulai memahami redundansi, paling mudah untuk mempertimbangkan redundansi dalam kaitannya dengan komponen stateless, yang merupakan komponen yang tidak menyimpan data apa pun. Meskipun sebagian besar solusi dunia nyata memang memerlukan pengelolaan status, di bagian ini, kami membahas redundansi dalam hal contoh antarmuka pemrograman aplikasi stateless (API). API contoh menerima input, mengerjakan input tersebut, lalu mengembalikan output, tanpa menyimpan data apa pun. Di bagian berikutnya, Replikasi: Redundansi untuk data, kami akan menambahkan pertimbangan untuk redundansi berstatus.

Skenario: Redundansi tanpa status

Dalam contoh ini, komponen API stateless disebarkan ke komputer virtual. Untuk menghindari waktu henti untuk komponen API jika ada kegagalan perangkat keras pada host fisik, contohnya menerapkan solusi redundan yang:

• Menyebarkan beberapa salinan dari instans API.
• Menerapkan load balancer untuk mendistribusikan permintaan di antara instans API.

Load balancer memantau kesehatan setiap instans untuk mengirim permintaan hanya ke instans yang sehat.

Pertimbangan redundansi

Saat menerapkan solusi redundan, seperti dalam skenario di atas, penting untuk mempertimbangkan hal berikut:

• Biaya sumber daya. Menurut definisi, redundansi melibatkan memiliki beberapa salinan sesuatu, yang meningkatkan total biaya untuk menghosting solusi.

• Performa. Semakin luas area geografis yang Anda distribusikan salinan hal-hal, semakin banyak risiko yang Anda bantu untuk menguranginya. Namun, permintaan dari klien akan memakan waktu lebih lama untuk melakukan perjalanan jarak yang lebih lama karena mereka harus melintasi lebih banyak infrastruktur jaringan, dan ini meningkatkan latensi jaringan.

  Dalam sebagian besar situasi dunia nyata, latensi jaringan tidak konsekuensial untuk jarak pendek, seperti dalam pusat data atau bahkan melintasi pusat data di seluruh kota. Tetapi jika Anda mendistribusikan salinan di jarak jauh, latensi jaringan bisa menjadi lebih signifikan.

• Konsistensi instance. Penting untuk menjaga agar instans tetap konsisten satu sama lain, dan untuk menghindari konfigurasi instans satu per satu karena Anda mungkin secara tidak sengaja memperkenalkan perbedaan antara instans. Jika ada perbedaan antara instans, permintaan mungkin diproses secara berbeda tergantung instans mana yang melayaninya. Ini dapat menyebabkan bug dan perilaku yang sulit didiagnosis.

• Distribusi pekerjaan. Ketika Anda memiliki beberapa instans komponen, Anda perlu membagi tugas di antara mereka. Anda mungkin menyebarkan pekerjaan di semua instans secara merata, atau Anda mungkin mengirim permintaan ke satu instans utama dan hanya menggunakan instans sekunder jika instans utama tidak tersedia.

  Untuk komponen yang menerima permintaan masuk, load balancer sering digunakan untuk mengirim permintaan tersebut ke instans. Namun, terkadang komponen bekerja secara independen dan tidak menerima permintaan dari klien, jadi dalam situasi ini, instans mungkin perlu mengoordinasikan pekerjaan mereka satu sama lain.

• Pemantauan kesehatan. Kesehatan setiap instans menentukan apakah instans tersebut dapat melakukan pekerjaannya, dan pemantauan kesehatan penting untuk mengaktifkan pemulihan cepat jika ada masalah.

  Penyeimbang beban biasanya melakukan pemantauan kesehatan. Untuk komponen yang tidak menyertakan load balancer, Anda mungkin memiliki komponen eksternal yang mengawasi kesehatan semua instans, atau setiap instans mungkin memantau kesehatan instans lain.

Lokasi fisik di cloud

Kebutuhan akan redundansi jelas ketika Anda memahaminya, bahkan di lingkungan cloud, instans atau sepotong data disimpan di lokasi fisik tertentu.

Contohnya:

• Komputer virtual berjalan di satu tempat fisik kapan saja.
• Data disimpan di lokasi fisik tertentu, seperti pada solid-state drive (SSD) atau hard disk yang terhubung ke server.

Bahkan jika ada beberapa salinan dari sepotong data atau instans komponen, setiap salinan terikat dengan perangkat keras fisik tempatnya disimpan.

Lokasi fisik lingkungan cloud secara keseluruhan dapat dibagi dalam lingkup fisik. Pada setiap cakupan fisik, ada potensi risiko yang dapat membahayakan komponen atau data dalam cakupan tersebut. Berikut adalah daftar risiko non-lengkap yang dapat didefinisikan dalam hal cakupan fisik:

Cakupan fisik	Kemungkinan risiko
Perangkat keras tertentu, seperti disk atau server	Kegagalan perangkat keras
Rak di pusat data	Pemadaman switch jaringan top-of-rack
Pusat data	Masalah dengan sistem pendingin bangunan
Sekelompok pusat data, yang di Azure disebut zona ketersediaan	Badai listrik di seluruh kota
Area geografis yang lebih luas tempat pusat data berada, seperti kota, yang merupakan wilayah Azure	Bencana alam yang meluas

Dari perspektif keandalan, cara penting untuk mengurangi risiko yang terkait dengan cakupan fisik adalah dengan menyebarkan instans komponen di berbagai cakupan fisik. Layanan Azure dengan redundansi bawaan dapat menawarkan kepada Anda satu atau beberapa dari tiga cara berikut untuk menyebarkan instans redundan:

• Redundansi lokal menempatkan instans di beberapa bagian dari satu pusat data Azure dan melindungi dari kegagalan perangkat keras yang mungkin memengaruhi satu instans. Redundansi lokal biasanya memberikan biaya dan latensi terendah. Namun, kegagalan pusat data dapat berarti bahwa semua instans tidak tersedia.

• Redundansi zona mendistribusikan instans layanan di beberapa zona ketersediaan dalam satu wilayah Azure. Redundansi zona melindungi dari kegagalan pusat data, selain kegagalan perangkat keras.

• Redundansi geografis menempatkan instans di beberapa wilayah Azure dan memberikan perlindungan terhadap pemadaman regional skala besar. Geo-redundansi memiliki biaya yang lebih tinggi dan memerlukan pertimbangan desain solusi yang lebih luas dan bagaimana Anda akan beralih antar instans komponen Anda di setiap wilayah. Anda juga perlu mempertimbangkan latensi, yang dijelaskan dalam Replikasi sinkron dan asinkron.

Cara kerja redundansi di Azure: Layanan komputasi

Redundansi digunakan di hampir setiap bagian Azure. Sebagai contoh bagaimana Azure menerapkan redundansi, pertimbangkan layanan yang menjalankan beban kerja komputasi.

Di Azure, komputer virtual individual (VM) berjalan pada satu host fisik di pusat data Azure. Anda dapat memberikan instruksi kepada Azure untuk memastikan bahwa VM berjalan di tempat yang Anda harapkan, seperti wilayah dan zona ketersediaan, dan dalam beberapa situasi, Anda bahkan mungkin ingin menempatkannya di host yang didedikasikan untuk Anda.

Merupakan hal umum untuk menjalankan beberapa instans mesin virtual. Dalam skenario tersebut, Anda dapat memilih untuk mengelolanya satu per satu, atau dengan menggunakan Set Skala Komputer Virtual. Saat Anda menggunakan skalabilitas set, Anda masih dapat melihat masing-masing mesin virtual (VM) yang mendasarinya, tetapi skalabilitas set menyediakan berbagai kemampuan untuk membantu mengelola VM yang berlebihan. Kemampuan ini termasuk penempatan otomatis VM berdasarkan aturan yang Anda tentukan, seperti dengan menyebarkannya di seluruh domain kesalahan dalam wilayah atau zona ketersediaan.

Ada banyak layanan komputasi Azure lainnya yang mengandalkan komputer virtual untuk melakukan tugas komputasi. Layanan komputasi umumnya menawarkan berbagai pengaturan redundansi yang menentukan bagaimana komputer virtual didistribusikan. Misalnya, layanan mungkin menyediakan pengaturan redundansi zona, yang dapat Anda aktifkan untuk mendistribusikan komputer virtual secara otomatis di seluruh zona ketersediaan dan mengonfigurasi penyeimbangan beban.

Replikasi: Redundansi untuk data

Redundansi, ketika diterapkan ke status (data), disebut replikasi. Dengan replikasi, Anda dapat mempertahankan beberapa salinan data aktif secara real-time atau hampir seketika, yang disebut replika. Untuk meningkatkan ketahanan terhadap risiko, Anda dapat mendistribusikan replika di berbagai lokasi. Jika satu replika menjadi tidak tersedia, sistem mungkin gagal sehingga replika lain mengambil alih fungsinya.

Ada berbagai jenis replikasi, dan setiap jenis memprioritaskan konsistensi data, kinerja, dan biaya dengan cara yang berbeda. Setiap jenis replikasi memengaruhi dua metrik utama yang digunakan dalam diskusi kelangsungan bisnis: tujuan waktu pemulihan (RTO), yang merupakan jumlah maksimum waktu henti yang dapat Anda toleransi dalam skenario bencana, dan tujuan titik pemulihan (RPO), yang merupakan jumlah maksimum kehilangan data yang dapat Anda toleransi dalam skenario bencana. Untuk mempelajari selengkapnya tentang metrik ini dan bagaimana kaitannya dengan kelangsungan bisnis, lihat Apa itu kelangsungan bisnis, ketersediaan tinggi, dan pemulihan bencana?.

Karena pentingnya replikasi dalam memenuhi persyaratan fungsional dan performa, sebagian besar sistem database dan produk dan layanan penyimpanan data lainnya mencakup beberapa jenis replikasi sebagai fitur yang terintegrasi erat. Jenis replikasi yang mereka tawarkan biasanya didasarkan pada arsitektur mereka dan cara yang dimaksudkan untuk digunakan. Untuk mempelajari tentang jenis replikasi yang didukung oleh layanan Azure, lihat Panduan keandalan layanan Azure.

Penting

Replikasi tidak sama dengan cadangan. Replikasi menyinkronkan semua perubahan di antara beberapa replika dan tidak mempertahankan salinan data lama.

Misalkan Anda secara tidak sengaja menghapus beberapa data. Operasi penghapusan direplikasi ke setiap replika, dan data Anda dihapus di mana-mana. Dalam situasi ini, Anda mungkin perlu memulihkan data yang dihapus dari cadangan. Pencadangan dijelaskan nanti dalam artikel ini.

Replikasi sinkron dan asinkron

Saat Anda mereplikasi data, setiap perubahan pada data tersebut harus tetap sinkron di antara replika. Ada beberapa tantangan utama saat mencoba mempertahankan konsistensi ketika data berubah:

• Latensi Memperbarui replika membutuhkan waktu, dan semakin jauh replika, semakin lama waktu yang diperlukan untuk mengirimkan data di seluruh jarak antara replika dan menerima pengakuan.

• Mengubah manajemen. Data dapat berubah saat replika sedang disinkronkan sehingga mengelola konsistensi data dapat menjadi kompleks.

Untuk mengatasi tantangan ini, ada dua cara utama agar Anda dapat mereplikasi perubahan data dan mengelola konsistensi data:

• Replikasi sinkron memerlukan pembaruan untuk dilakukan pada beberapa replika sebelum pembaruan dianggap selesai. Diagram berikut ini menggambarkan cara kerja replikasi sinkron:

  

  Dalam contoh ini, urutan langkah-langkah berikut terjadi:

  1. Klien mengubah data, dan permintaan dikirim ke replika 1, yang memproses permintaan dan menyimpan data yang diubah.
  2. Replika 1 mengirimkan perubahan ke replika 2, yang memproses permintaan dan menyimpan data yang diubah.
  3. Replika 2 mengakui perubahan kembali ke replika 1.
  4. Replika 1 mengonfirmasi perubahan tersebut kembali ke klien.

  Replikasi sinkron dapat menjamin konsistensi, yang berarti dapat mendukung RPO nol. Namun, ini mengorbankan kinerja. Semakin jauh terpisah replika Anda secara geografis dan semakin banyak hop jaringan yang perlu dilalui, semakin banyak latensi yang akan diperkenalkan oleh proses replikasi.

• Replikasi asinkron terjadi di latar belakang. Diagram berikut mengilustrasikan cara kerja replikasi asinkron:

  

  Dalam contoh ini, urutan langkah-langkah berikut terjadi:

  1. Klien mengubah data, dan permintaan dikirim ke replika 1.
  2. Replika 1 memproses permintaan, menyimpan data yang diubah, dan segera mengakui perubahan kembali ke klien.
  3. Pada suatu titik nanti, replika 1 menyinkronkan perubahan ke replika 2.

  Karena replikasi asinkron terjadi di luar alur transaksi, replikasi akan dihapus sebagai batasan pada performa aplikasi. Namun, jika Anda perlu melakukan failover ke replika lain, mungkin tidak memiliki data terbaru, sehingga RPO Anda harus lebih besar dari nol. RPO yang tepat yang dapat didukung replikasi asinkron tergantung pada frekuensi replikasi.

Peran replika

Dalam banyak sistem replikasi, replika dapat mengambil peran yang berbeda, yang membantu mengoordinasikan perubahan pada data dan mengurangi kemungkinan konflik. Ada dua jenis peran utama, aktif dan pasif. Ada dua cara umum untuk mendistribusikan replika dengan peran ini:

• Replikasi pasif aktif berarti Anda memiliki satu replika aktif, yang bertanggung jawab untuk bertindak sebagai sumber kebenaran. Setiap perubahan yang dilakukan pada data harus diterapkan ke replika tersebut. Replika lain bertindak dalam peran pasif , yang berarti mereka menerima pembaruan data dari replika aktif, tetapi mereka tidak memproses perubahan langsung dari klien. Replika pasif tidak digunakan untuk lalu lintas aktif kecuali failover terjadi dan peran replika berubah. Diagram berikut menunjukkan sistem pasif aktif dengan satu replika pasif:

  

  Dalam sistem aktif-pasif, lamanya waktu yang diperlukan untuk failover menentukan RTO. Umumnya, RTO untuk sistem pasif aktif diukur dalam hitungan menit.

  Beberapa solusi replikasi juga mendukung replika baca-saja, yang memungkinkan Anda membaca (tetapi tidak menulis) data dari replika pasif. Pendekatan ini dapat berguna untuk mendapatkan lebih banyak pemanfaatan dari replika Anda, seperti ketika Anda perlu melakukan analitik atau pelaporan data tanpa memengaruhi replika utama yang Anda gunakan untuk pekerjaan transaksional aplikasi Anda. Beberapa layanan Azure mendukung replika baca-saja, termasuk Azure Storage dengan jenis replikasi akses baca GRS (RA-GRS), dan replikasi geografis aktif Azure SQL Database.

• Replikasi aktif-aktif memungkinkan penggunaan beberapa replika aktif untuk lalu lintas langsung secara bersamaan, dan salah satu replika dapat memproses permintaan:

  

  Replikasi aktif-aktif memungkinkan tingkat performa yang tinggi karena sistem dapat menggunakan sumber daya pada semua replika. Replikasi aktif-aktif dapat mendukung RTO nol dalam beberapa situasi. Namun, manfaat ini datang dengan biaya konsistensi data yang rumit, karena perubahan bersaing secara bersamaan pada beberapa replika mungkin perlu direkonsiliasi secara asinkron.

Layanan data kompleks dapat menggabungkan replikasi aktif-aktif dan pasif. Misalnya, mereka mungkin menyebarkan satu set replika di satu wilayah Azure dan satu lagi di wilayah yang berbeda. Dalam setiap wilayah, satu replika aktif melakukan pemrosesan permintaan sementara satu atau beberapa replika pasif siaga untuk pengalihan cadangan. Sementara itu, kedua wilayah beroperasi dalam model aktif-aktif, memungkinkan distribusi lalu lintas di antara keduanya.

Cara kerja replikasi di layanan data Azure

Setiap layanan Azure yang menyimpan data menawarkan beberapa bentuk replikasi. Namun, setiap layanan dapat menggunakan pendekatan berbeda yang khusus untuk arsitektur layanan dan penggunaan yang dimaksudkan.

Sebagai contoh, Azure Storage dapat menyediakan replikasi sinkron dan asinkron melalui serangkaian kemampuan:

• Beberapa salinan data Anda direplikasi secara sinkron dalam wilayah utama Anda. Anda dapat memilih apakah akan menempatkan replika pada perangkat keras fisik yang berbeda dalam satu pusat data di penyimpanan redundan lokal (LRS) atau menyebarkannya di beberapa zona ketersediaan untuk penyimpanan zona redundan (ZRS).
• Jika wilayah utama Anda dipasangkan dan Anda mengaktifkan penyimpanan geo-redundan (GRS), data juga direplikasi ke wilayah yang dipasangkan. Karena wilayah yang dipasangkan secara geografis jauh, replikasi ini terjadi secara asinkron untuk mengurangi dampak pada throughput aplikasi Anda.
• Anda dapat memilih untuk menggunakan penyimpanan yang tahan zona dan penyimpanan yang tahan geo secara bersamaan dengan menggunakan tingkatan penyimpanan yang tahan geo-zona (GZRS). Data dalam wilayah direplikasi secara sinkron, dan data di seluruh wilayah direplikasi secara asinkron.

Untuk informasi lebih lanjut, lihat Redundansi Azure Storage.

Contoh lain adalah Azure Cosmos DB, yang juga menyediakan replikasi. Semua database Azure Cosmos DB memiliki beberapa replika. Saat Anda mendistribusikan replika secara global, hal itu mendukung penulisan multi-wilayah, di mana klien dapat menulis ke replika di salah satu wilayah yang Anda gunakan. Operasi tulis tersebut direplikasi secara sinkron dalam wilayah tersebut, lalu direplikasi secara asinkron di seluruh wilayah lain. Azure Cosmos DB menyediakan mekanisme penyelesaian konflik jika terjadi konflik penulisan di berbagai replika. Untuk mempelajari selengkapnya, lihat Distribusi data global dengan Azure Cosmos DB - di balik layar.

Jika Anda menggunakan komputer virtual, Anda dapat menggunakan Azure Site Recovery untuk mereplikasi komputer virtual dan disknya antara zona ketersediaan atau ke wilayah Azure lain.

Saat Anda merancang solusi Azure, lihat panduan keandalan untuk setiap layanan untuk memahami bagaimana layanan tersebut menyediakan redundansi dan replikasi, termasuk di berbagai lokasi.

Backup

Pencadangan mengambil salinan data Anda pada titik waktu di tertentu. Jika ada masalah, Anda dapat memulihkan cadangan nanti. Namun, setiap perubahan pada data Anda yang terjadi setelah cadangan diambil tidak akan berada di cadangan, dan mungkin hilang.

Dengan menggunakan cadangan, Anda dapat memberikan solusi untuk mencadangkan dan memulihkan data Anda di dalam atau ke cloud Microsoft Azure. Pencadangan dapat melindungi Anda dari berbagai risiko, termasuk:

• Kerugian besar perangkat keras atau infrastruktur lainnya.
• Kerusakan dan penghapusan data.
• Serangan cyber, seperti ransomware.

Penting

Sangat penting bahwa Anda menguji dan memverifikasi proses pencadangan dan pemulihan Anda secara teratur, bersama dengan langkah-langkah pemulihan Anda yang lain. Pengujian memastikan bahwa cadangan Anda komprehensif dan bebas kesalahan, dan bahwa proses Anda memulihkannya dengan benar. Pengujian juga penting untuk memastikan tim Anda memahami proses yang harus diikuti. Untuk mempelajari selengkapnya, lihat Pengujian dan latihan.

Bagaimana pencadangan memengaruhi kebutuhan Anda

Saat digunakan sebagai bagian dari strategi pemulihan bencana, cadangan biasanya mendukung RTO dan RPO yang dinyatakan dalam hitungan jam.

• RTO dipengaruhi oleh waktu yang diperlukan bagi Anda untuk memulai dan menyelesaikan proses pemulihan Anda, termasuk memulihkan cadangan dan memvalidasi bahwa pemulihan berhasil diselesaikan. Tergantung pada ukuran cadangan dan berapa banyak file cadangan yang perlu dibaca, biasanya diperlukan waktu beberapa jam atau bahkan lebih lama untuk memulihkan cadangan sepenuhnya.

• RPO dipengaruhi oleh frekuensi proses pencadangan Anda. Jika Anda mengambil cadangan lebih sering, itu berarti Anda kehilangan lebih sedikit data jika Anda harus memulihkan dari cadangan. Namun, cadangan memerlukan penyimpanan, dan dalam beberapa situasi, cadangan mungkin memengaruhi performa layanan saat cadangan sedang diambil. Oleh karena itu, Anda perlu mempertimbangkan frekuensi pencadangan dan mencari keseimbangan yang tepat untuk persyaratan organisasi Anda. Frekuensi pencadangan harus menjadi pertimbangan dalam perencanaan kelangsungan bisnis.

Beberapa sistem cadangan mendukung persyaratan pencadangan yang lebih kompleks, termasuk beberapa tingkat cadangan dengan periode retensi yang berbeda, dan cadangan diferensial atau inkremental yang lebih cepat untuk menyimpan dan mengonsumsi lebih sedikit penyimpanan.

Pencadangan di layanan Azure

Banyak layanan Azure menyediakan kemampuan pencadangan untuk data Anda.

Azure Backup adalah solusi pencadangan khusus untuk beberapa layanan Azure utama, termasuk komputer virtual, Azure Storage, dan Azure Kubernetes Service (AKS).

Selain itu, banyak database terkelola menyediakan kemampuan pencadangan mereka sendiri sebagai bagian dari layanan, seperti:

• Azure SQL Database menyediakan pencadangan otomatis.
• Azure Cosmos DB menyediakan kemampuan pencadangan yang berkesinambungan dan berkala.
• Azure Key Vault memungkinkan Anda mengunduh cadangan data di vault Anda.
• Azure App Service menyediakan pencadangan otomatis dan kustom untuk aplikasi web, serta dapat mencadangkan database aplikasi tersebut.

Pencadangan vs. replikasi

Pencadangan dan replikasi masing-masing melindungi Anda dari risiko yang berbeda, dan kedua pendekatan tersebut saling melengkapi.

Replikasi mendukung ketahanan sehari-hari dan umumnya digunakan dalam strategi ketersediaan tinggi. Beberapa pendekatan replikasi memerlukan sedikit atau tanpa waktu henti atau kehilangan data dan mendukung RTO dan RPO yang rendah. Namun, replikasi tidak melindungi Anda dari risiko yang mengakibatkan kehilangan atau kerusakan data.

Sebaliknya, pencadangan sering kali merupakan garis pertahanan terakhir terhadap risiko bencana. Pencadangan sering memerlukan RTO dan RPO yang relatif tinggi, meskipun cara Anda mengonfigurasi cadangan memengaruhi dengan tepat seberapa tingginya cadangan tersebut. Pemulihan total dari cadangan sering kali merupakan bagian dari rencana pemulihan bencana.

Menyiapkan komponen untuk redundansi

Saat Anda merancang sistem yang menggunakan redundansi sebagai bagian dari arsitekturnya, penting untuk juga mempertimbangkan cara:

• Penggandaan konfigurasi sumber daya demi konsistensi.
• Kelola kapasitas pada saat kegagalan instans dengan metode overprovisioning.

Konfigurasi sumber daya duplikat

Di lingkungan cloud, konfigurasi setiap sumber daya Anda sangat penting. Misalnya, saat membuat penyeimbang beban jaringan, Anda mengonfigurasi berbagai pengaturan yang memengaruhi cara kerjanya; dan saat Anda menyebarkan fungsi dengan menggunakan Azure Functions, Anda mengonfigurasi pengaturan yang terkait dengan pengaturan keamanan, performa, dan konfigurasi aplikasi. Setiap sumber daya di Azure memiliki semacam konfigurasi yang mendorong perilakunya.

Saat Anda mengelola salinan sumber daya yang berlebihan di tempat yang berbeda, penting untuk mengontrol konfigurasinya. Banyak pengaturan harus disiapkan dengan cara yang sama di setiap salinan, sehingga sumber daya berperilaku dengan cara yang sama. Tetapi beberapa pengaturan mungkin berbeda antara setiap salinan, seperti referensi ke jaringan virtual wilayah tertentu.

Pendekatan umum untuk menjaga konsistensi dalam sumber daya Anda adalah menggunakan infrastruktur sebagai kode (IaC), seperti Bicep atau Terraform. Alat-alat ini memungkinkan Anda membuat file yang menentukan sumber daya, dan Anda dapat menggunakan kembali definisi tersebut untuk setiap instans sumber daya. Dengan menggunakan IaC, Anda dapat mengurangi beban membuat dan mengelola beberapa instans sumber daya untuk tujuan ketahanan, dan ada banyak manfaat lain juga. Untuk mempelajari selengkapnya, lihat Apa itu infrastruktur sebagai kode (IaC)? dan Rekomendasi untuk menggunakan infrastruktur sebagai kode.

Mengelola kapasitas dengan pengadaan berlebih

Ketika instans gagal, kapasitas sistem Anda secara keseluruhan mungkin berbeda dari kapasitas yang diperlukan selama operasi yang sehat. Misalnya, Anda biasanya memiliki enam instans server web untuk memproses lalu lintas web masuk Anda, dan instans tersebut tersebar sama di antara tiga zona ketersediaan Azure di suatu wilayah:

Jika zona ketersediaan mengalami pemadaman, Anda mungkin kehilangan dua instans untuk sementara waktu dan hanya dibiarkan dengan empat instans server web. Jika aplikasi Anda biasanya sibuk dan membutuhkan keenam instans untuk mengikuti lalu lintas normal Anda, maka operasi pada kapasitas yang berkurang dapat memengaruhi kinerja solusi Anda.

Untuk mempersiapkan kegagalan, Anda dapat menyediakan kapasitas layanan Anda secara berlebihan . Provisi berlebihan memungkinkan solusi untuk mentolerir beberapa tingkat kehilangan kapasitas dan masih terus berfungsi tanpa penurunan performa.

Untuk menyediakan instans server web Anda secara lebih besar guna mempertimbangkan kegagalan satu zona ketersediaan, ikuti langkah-langkah berikut:

1. Tentukan jumlah instans yang diperlukan oleh beban kerja puncak Anda.
2. Ambil jumlah instans kelebihan penyediaan dengan mengalikan jumlah instans beban kerja puncak dengan faktor [(zona/(zona-1)].
3. Bulatkan hasil ke bilangan bulat terdekat.

Nota

Tabel berikut mengasumsikan bahwa Anda menggunakan tiga zona ketersediaan dan Anda ingin memperhitungkan kehilangan kapasitas salah satu zona tersebut. Jika persyaratan Anda berbeda, sesuaikan rumus yang sesuai.

Instans beban kerja saat puncak	Faktor [(zona/(zona-1)]	Formula	Instans yang akan disediakan (Dibulatkan)
3	3/2 atau 1,5	(3 x 1,5 = 4,5)	5 instans
4	3/2 atau 1,5	(4 x 1,5 = 6)	6 instans
5	3/2 atau 1,5	(5 x 1,5 = 7,5)	8 contoh
6	3/2 atau 1,5	(6 x 1,5 = 9)	9 instans
7	3/2 atau 1,5	(7 x 1,5 = 10,5)	11 instans
8	3/2 atau 1,5	(8 x 1,5 = 12)	12 instans
9	3/2 atau 1,5	(9 x 1,5 = 13,5)	14 kejadian
10	3/2 atau 1,5	(10 x 1,5 = 15)	15 kasus

Dalam contoh sebelumnya, beban kerja puncak memerlukan enam instans server web, sehingga provisi berlebihan memerlukan total sembilan instans:

Langkah selanjutnya

Pelajari tentang failover dan failback.