Rancangan aplikasi Azure untuk ketahanan dan ketersediaan
Setelah menetapkan persyaratan untuk aplikasi, langkah selanjutnya adalah membangun ketahanan dan ketersediaandi dalamnya. Kualitas ini tidak dapat dilakukan di akhir — Anda harus mendesainnya ke dalam arsitektur.
Rencana redundansi
Kegagalan memiliki dampak bervariasi. Beberapa kegagalan perangkat keras, seperti disk yang gagal, memengaruhi satu mesin host. Sakelar jaringan yang gagal dapat memengaruhi seluruh server. Sedikit kegagalan yang tidak umum, seperti kehilangan daya, mengganggu seluruh pusat data. Jarang, seluruh wilayah tidak tersedia.
Redundansi merupakan salah satu cara untuk membuat aplikasi menjadi tangguh. Tingkat redundansi bergantung pada kebutuhan bisnis Anda — tidak semua aplikasi memerlukan redundansi untuk mencegah pemadaman. Secara umum, ada tukar tambah antara redundansi dan keandalan yang lebih besar versus biaya dan kompleksitas yang lebih tinggi.
Tinjauan fitur redundansi Azure
Azure memiliki sejumlah fitur redundansi di setiap kegagalan, dari mesin virtual individu (VM) hingga seluruhnya.
Single VMs memiliki masa aktif perjanjian tingkat layanan (SLA) yang disediakan oleh Azure. (VM harus menggunakan penyimpanan premium untuk semua disk sistem operasi dan data.) Meskipun bisa mendapatkan SLA yang lebih tinggi dengan menjalankan dua atau lebih VM, namun satu VM cukup andal untuk melakukan beberapa beban kerja. Namun, untuk beban kerja produksi, sebaiknya gunakan dua atau lebih VM untuk redundansi.
Ketersediaan melindungi dari kegagalan perangkat keras lokal, seperti kegagalan disk atau sakelar jaringan. VM dalam ketersediaan didistribusikan hingga tiga domain kesalahan. Domain kesalahan adalah grup VM yang berbagi sumber daya dan sakelar jaringan yang sama. Jika kegagalan perangkat keras memengaruhi kesalahan satu domain, lalu lintas jaringan akan dialihkan ke VM di domain kesalahan lainnya. Untuk mempelajari tentang set ketersediaan, lihat Kelola ketersediaan mesin virtual Windows di Azure.
Zona ketersediaan adalah zona terpisah secara fisik dalam wilayah Azure. Setiap Zona Ketersediaan memiliki sumber daya, jaringan, dan pendinginan yang berbeda. Menyebarkan VM di seluruh Zone Ketersediaan membantu melindungi aplikasi dari kegagalan di seluruh pusat data. Tidak semua wilayah mendukung Zona Ketersediaan. Untuk wilayah dan layanan yang didukung, lihat Apa itu Zona Ketersediaan di Azure??.
Jika Anda berencana untuk menggunakan Zona Ketersediaan dalam penerapan Anda, validasikan terlebih dahulu bahwa arsitektur aplikasi dan basis kode Anda mendukung konfigurasi ini. Jika Anda menerapkan perangkat lunak komersial, konsultasikan dengan vendor perangkat lunak dan uji secara memadai sebelum dinerapkan ke produksi. Aplikasi harus mempertahankan status dan mencegah hilangnya data selama pemadaman dalam zona konfigurasi. Aplikasi harus mendukung jalannya dalam infrastruktur yang elastis dan terdistribusi tanpa komponen infrastruktur perangkat keras.
Azure Site Recoverymereplikasi Azure Virtual Machines ke wilayah Azure lain untuk kebutuhan kelangsungan bisnis (BC) dan pemulihan bencana (DR). Anda dapat melakukan latihan DR secara berkala untuk memastikan bahwa kebutuhan Anda terpenuhi. VM akan direplikasi dengan pengaturan yang ditentukan ke wilayah yang dipilih sehingga dapat memulihkan aplikasi Anda jika terjadi pemadaman di wilayah sumber. Untuk informasi selengkapnya, lihat Mulai Cepat: Menyiapkan pemulihan bencana ke wilayah Azure sekunder untuk Azure Virtual Machines.
Selama pengujian, pastikan bahwa: tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) sesuai kebutuhan Anda. RTO adalah waktu maksimum aplikasi yang tidak tersedia setelah insiden, dan RPO adalah durasi maksimum kehilangan data selama bencana.
Wilayah berpasangan dibuat menggunakan Azure Traffic Manager untuk mendistribusikan lalu lintas Internet ke berbagai wilayah, melindungi aplikasi dari pemadaman regional. Setiap wilayah Azure dipasangkan dengan wilayah lain. Secara bersamaan, daerah-daerah ini membentuk pasangan regional. Untuk memenuhi persyaratan residensi data untuk tujuan yurisdiksi pajak dan penegakan hukum, pasangan regional berada dalam geografi yang sama (dengan pengecualian Brasil Selatan).
Untuk meningkatkan ketahanan aplikasi, Azure membuat serial pembaruan platform (pemeliharaan terencana) di setiap pasangan wilayah, jadi hanya satu wilayah yang dipasangkan yang diperbarui pada satu waktu.
Saat mendesain aplikasi multiregion, pertimbangkan bahwa latensi jaringan lintas region lebih tinggi daripada di dalam region. Misalnya, jika Anda mereplikasi database untuk mengaktifkan failover, gunakan replikasi data langsung dalam suatu wilayah tetapi replikasi data tidak langsung di seluruh wilayah.
Tabel berikut membandingkan faktor redundansi strategi ketahanan:
| Rangkaian ketersediaan | Zona Ketersediaan | Azure Site Recovery/Wilayah berpasangan | |
|---|---|---|---|
| Lingkup kegagalan | Rak | Pusat data | Wilayah |
| Permintaan rute | Azure Load Balancer | Lintas Zona Azure Load Balancer | Azure Traffic Manager |
| Latensi jaringan | Sangat rendah | Rendah | Pertengahan ke tinggi |
| Jaringan virtual | Azure Virtual Network | Azure Virtual Network | Pemantauan Microsoft Azure Virtual Network lintas wilayah |
Penyelesaian perintah redundansi Azure
Gunakan perintah berikut untuk memenuhi persyaratan redundansi:
Menyebarkan beberapa instans sumber daya. Jika aplikasi Anda bergantung pada satu instans layanan, itu akan membuat satu titik kegagalan. Penyediaan beberapa instans akan meningkatkan ketahanan dan skalabilitas. Untuk Azure App Service, pilih paket App Service yang menawarkan beberapa instans. Untuk Azure Virtual Machines, pastikan arsitektur Anda menyertakan lebih dari satu VM dan setiap VM disertakan dalam set ketersediaan.
Replikasi VM menggunakan Azure Site Recovery. Saat Anda mereplikasi VM Azure menggunakan Site Recovery, semua disk VM terus direplikasi ke wilayah target secara asinkronis. Titik pemulihan dibuat setiap beberapa menit, hal ini memberikan RPO dalam urutan menit.
Pertimbangkan untuk menyebarkan aplikasi Anda di beberapa region. Jika aplikasi disebarkan ke satu region, dan region menjadi tidak tersedia, aplikasi Anda juga tidak akan tersedia. Hal ini tidak dapat diterima menurut persyaratan SLA aplikasi. Jika demikian, pertimbangkan untuk mendeploy aplikasi Anda dan layanannya di beberapa region. Penyebaran multiregion dapat menggunakanaktif-aktif atau aktif-pasif konfigurasi. Konfigurasi aktif-aktif mendistribusikan permintaan di beberapa wilayah yang aktif. Konfigurasi aktif-pasif membuat instans tetap hangat di region sekunder, tetapi tidak mengirimkan lalu lintas ke sana kecuali jika region utama gagal. Untuk penerapan multiregion, sebaiknya terapkan ke region berpasangan, seperti yang dijelaskan di atas. Untuk informasi selengkapnya, lihat Kelangsungan bisnis dan pemulihan bencana (Business Continuity and Disaster Recovery/BCDR): Wilayah Berpasangan Azure.
Gunakan Azure Traffic Manager untuk merutekan lalu lintas aplikasi ke berbagai wilayah.Azure Traffic Manager melakukan penyeimbangan di tingkat DNS dan merutekan lalu lintas ke berbagai wilayah berdasarkan metode perutean lalu lintas dan kesehatan titik akhir aplikasi Anda. Tanpa Traffic Manager, penyebaran terbatas pada satu wilayah, yang membatasi skala, meningkatkan latensi untuk beberapa pengguna, dan menyebabkan padamnya aplikasi, jika terjadi gangguan layanan di seluruh wilayah.
Konfigurasikan Azure Application Gateway untuk menggunakan beberapa instans. Tergantung pada persyaratan aplikasi Anda, dan Azure Application Gatewaymungkin lebih cocok untuk mendistribusikan permintaan ke layanan aplikasi. Namun, instans tunggal layanan Application Gateway tidak dijamin oleh SLA, jadi aplikasi Anda mungkin gagal jika instans Application Gateway gagal. Sediakan lebih dari satu instans menengah atau lebih besar untuk menjamin ketersediaan layanan di bawah persyaratan Application Gateway SLA.
Pastikan ketersediaan sesuai SLA
Ketersediaan adalah proporsi waktu di mana suatu sistem berfungsi dan bekerja, dan merupakan salah satu pilar kualitas perangkat lunak. Gunakan perintah di bagian ini untuk meninjau arsitektur aplikasi dari sudut pandang ketersediaan dalam memastikan ketersediaan terpenuhinya SLA.
Hindari satu titik kegagalan. Semua komponen, layanan, sumber daya, dan instans komputasi harus diterapkan sebagai beberapa instans untuk mencegah satu titik kegagalan yang akan memengaruhi ketersediaan. Mekanisme autentikasi juga bisa menjadi satu titik kegagalan. Rancang aplikasi agar dapat dikonfigurasi untuk menggunakan beberapa instans dan untuk secara otomatis mendeteksi kegagalan dan mengalihkan permintaan ke instans yang tidak gagal, jika platform tidak melakukan ini secara otomatis.
Menguraikan beban kerja berdasarkan tujuan tingkat layanan. Jika layanan terdiri dari beban kritis dan kurang kritis, kelola secara berbeda dan tentukan fitur layanan dan jumlah instans untuk memenuhi persyaratan ketersediaannya.
Minimalkan dan pahami dependensi layanan. Minimalkan jumlah layanan yang digunakan, jika memungkinkan. Pastikan Anda memahami semua fitur dan dependensi layanan yang ada di sistem. Secara khusus, pahami dampak keseluruhan kegagalan atau penurunan kinerja di setiap dependensi.
Rancang tugas dan pesan agar idempoten, jika memungkinkan. Suatu operasi dikatakan idempoten jika dapat diulang beberapa kali dan menghasilkan hasil yang sama. Ini untuk memastikan permintaan duplikat tidak menyebabkan masalah. Pesan konsumen dan operasi yang dilakukan harus idempoten sehingga pengulangan operasi yang dijalankan sebelumnya tidak membuat hasil menjadi tidak valid. Ini akan mendeteksi pesan duplikat atau memastikan konsistensi dengan menggunakan pendekatan optimis untuk menangani konflik.
Konfigurasikan batas waktu permintaan. Layanan dan sumber daya menjadi tidak tersedia, akan menyebabkan gagalnya permintaan. Pastikan batas waktu yang Anda terapkan sesuai untuk setiap layanan atau sumber daya dan untuk klien yang mengaksesnya. Dalam beberapa kasus, Anda mungkin mengizinkan batas waktu yang lebih lama untuk klien tertentu, bergantung pada konteks dan tindakan yang dilakukan klien. Waktu tunggu yang singkat dapat menyebabkan percobaan ulang berlebihan untuk layanan dan sumber daya yang memiliki latensi yang cukup besar. Waktu tunggu yang lama dapat menyebabkan pemblokiran, jika banyak permintaan yang antre, menunggu layanan atau sumber daya untuk merespons.
Gunakan broker pesan yang menerapkan ketersediaan tinggi untuk transaksi penting. Banyak aplikasi cloud menggunakan pesan untuk melakukan tugas secara tidak langsung. Untuk menjamin pengiriman pesan, sistem pesan harus menyediakan ketersediaan tinggi. Azure Service Bus messaging mengimplementasikan setidaknya sekali semantik, yang berarti bahwa pesan dijamin terkirim setidaknya satu kali. Pesan duplikasi dapat dikirimkan dalam keadaan tertentu. Jika pemrosesan pesan idempoten (lihat item sebelumnya), pengiriman berulang kali tidak menjadi masalah.
Batasi pengguna bervolume tinggi. Terkadang, sebagian kecil pengguna membuat beban yang berlebihan. Ini dapat berdampak pada pengguna lain dan dapat mengurangi ketersediaan aplikasi secara keseluruhan. Ketika satu klien membuat permintaan yang berlebihan, aplikasi dapat membatasi klien untuk jangka waktu tertentu. Selama periode pembatasan, aplikasi akan menolak sebagian atau semua permintaan dari klien tersebut. Ambang batas untuk pembatasan bergantung pada tingkat layanan pelanggan. Untuk mengetahui informasi selengkapnya, lihat Pola pembatasan.
Pembatasan tidak menyiratkan bahwa klien melakukan kejahatan — hanya saja melakukan kegiatan melebihi kuota layanannya. Dalam beberapa kasus, konsumen mungkin secara konsisten melakukan kegiatan melebihi kuota atau berperilaku buruk. Dalam hal ini, diperbolehkan untuk melangkah lebih jauh dan memblokir pengguna. Biasanya, ini dilakukan dengan memblokir kunci API atau rentang alamat IP.
Rancang aplikasi untuk diturunkan. Beban aplikasi dapat melebihi kapasitas satu atau lebih bagian, yang menyebabkan ketersediaan berkurang dan koneksi gagal. Penskalaan dapat mengurangi masalah, tetapi mungkin mencapai batas yang ditentukan oleh faktor lain, seperti ketersediaan sumber daya atau biaya. Saat aplikasi mencapai batas sumber daya, aplikasi harus mengambil tindakan yang tepat untuk meminimalkan dampak bagi pengguna. Misalnya, dalam sistem e-commerce, jika subsistem pemrosesan pesanan berada di bawah tekanan atau gagal, subsistem tersebut dapat dinonaktifkan sementara sehingga memungkinkan fungsi lain, seperti penelusuran katalog produk. Mungkin tepat untuk menunda permintaan ke subsistem yang gagal — misalnya, masih memungkinkan pelanggan untuk mengirimkan pesanan tetapi menyimpannya untuk diproses nanti, ketika subsistem pesanan tersedia lagi.
Penanganan ledakan dengan cepat. Sebagian besar aplikasi perlu menangani beban kerja yang bervariasi dari waktu ke waktu. Penskalaan otomatis dapat membantu penanganan beban, tetapi perlu beberapa waktu agar instans tambahan dapat daring dan menangani permintaan. Untuk mencegah ledakan aktivitas membanjiri aplikasi, rancang aplikasi antrian untuk permintaan ke layanan yang digunakannya dan untuk menurunkan saat antrean mendekati kapasitas. Pastikan kinerja dan kapasitas cukup tersedia di bawah kondisi tidak meledak untuk mengatasi antrian dan menangani permintaan yang luar biasa. Untuk informasi selengkapnya, lihat Pola Perataan Beban Berbasis Antrean.
Menulis atau gagal kembali ke beberapa komponen. Rancang aplikasi untuk dapat menggunakan banyak instans tanpa memengaruhi operasi dan koneksi yang ada, jika memungkinkan. Untuk memaksimalkan ketersediaan, gunakan beberapa instans dan distribusikan permintaan di antara mereka, serta deteksi dan hindari mengirim permintaan ke instans yang gagal.
Gagal kembali ke layanan atau alur kerja yang berbeda. Sebagai contoh, jika menulis ke SQL Database gagal, simpan data sementara di penyimpanan Blob atau Azure Cache for Redis. Sediakan cara untuk menulis ulang ke SQL Database saat layanan tersedia. Dalam beberapa kasus, operasi yang gagal memiliki tindakan alternatif yang memungkinkan aplikasi terus bekerja, bahkan ketika komponen atau layanan gagal. Jika memungkinkan, deteksi kegagalan dan alihkan permintaan ke layanan lain saat layanan utama mati.
Gunakan pemerataan beban untuk memuluskan lonjakan lalu lintas. Aplikasi dapat mengalami lonjakan lalu lintas tiba-tiba, yang dapat membebani back-end. Jika back-end tidak dapat menanggapi permintaan dengan cepat, permintaan yang tertunda dapat menumpuk atau layanan dapat membatasi aplikasi. Untuk menghindari ini, Anda dapat menggunakan antrian sebagai penyangga. Saat memulai item kerja baru, alih-alih segera memanggil layanan back-end, aplikasi mengantre item kerja untuk dijalankan secara tidak langsung. Antrian bertindak sebagai penyangga yang menghaluskan puncak beban. Untuk informasi lebih lanjut, lihat Pola Pemerataan Beban Berbasis Antrean.
Kelola data Anda
Bagaimana Anda mengelola data secara langsung ke ketersediaan aplikasi. Perintah ini dapat membantu Anda membuat rencana pengelolaan dalam memastikan ketersediaan.
Replikasi data dan pahami metode replikasi untuk penyimpanan data aplikasi Anda. Mereplikasi data adalah strategi untuk menangani kegagalan tidak sementara dalam penyimpanan data. Pertimbangkan alur baca dan tulis. Bergantung pada teknologi penyimpanan, Anda memiliki beberapa replika yang dapat ditulis atau mungkin memiliki satu replika yang dapat ditulis dan beberapa replika lainnya hanya-baca. Untuk memaksimalkan ketersediaan, replika dapat ditempatkan di beberapa wilayah. Namun, pendekatan ini akan meningkatkan latensi saat mereplikasi data. Biasanya, replikasi di seluruh wilayah dilakukan secara tidak langsung, yang menyiratkan model konsistensi di akhirnya dan potensi kehilangan data jika replika gagal.
Anda dapat menggunakan Azure Site Recovery untuk mereplikasi Azure Virtual Machines dari satu wilayah ke wilayah lainnya. Pemulihan Situs mereplikasi data secara berkesinambungan ke wilayah target. Ketika terjadi pemedaman di situs utama, Anda gagal ke lokasi sekunder.
Pastikan bahwa tidak ada satu pun akun pengguna yang memiliki akses ke data produksi dan cadangan. Cadangan data akan disusupi jika satu akun pengguna memiliki izin untuk menulis ke sumber produksi dan cadangan. Pengguna jahat dapat dengan sengaja menghapus semua data Anda, dan pengguna biasa juga dapat tanpa sengaja menghapusnya. Rancang aplikasi untuk memberi izin terbatas setiap akun pengguna. Berikan akses tulis hanya untuk pengguna yang memerlukan, dan berikan akses ke produksi atau pencadangan, tetapi tidak keduanya.
Dokumentasikan dan uji proses kegagalan dan kegagalan berulang pada penyimpanan data Anda. Jika penyimpanan data gagal secara serempak, operator harus mengikuti serangkaian instruksi terdokumentasi untuk proses gagal ke penyimpanan data baru. Jika langkah-langkah yang didokumentasikan terdapat kesalahan, operator tidak akan berhasil mengikutinya dan menyatakan gagal mengakses sumber daya. Uji langkah-langkah instruksi secara teratur untuk memverifikasi bahwa operator yang mengikuti dokumentasi dapat mengalami kegagalan dan kegagalan juga bisa terulang kembali.
Cadangkan data dan validasi cadangan data Anda. Jalankan skrip secara teratur untuk memvalidasi integritas data, skema, dan kueri untuk memastikan bahwa cadangan data sesuai dengan yang diharapkan. Catat dan laporkan semua inkonsistensi sehingga layanan pencadangan dapat diperbaiki.
Gunakan pencadangan berkala dan pemulihan tepat waktu. Lakukan secara teratur dan otomatis mencadangkan data yang tidak disimpan di tempat lain. Lakukan verifikasi bahwa Anda dapat memulihkan data dan aplikasi dengan andal jika terjadi kegagalan. Pastikan bahwa cadangan memenuhi RPO Anda. Replikasi data bukanlah fitur cadangan, karena kesalahan manusia atau operasi yang berbahaya dapat merusak data di semua replika. Proses pencadangan harus aman untuk melindungi data dalam perjalanan dan penyimpanan. Basis data biasanya dapat dipulihkan ke titik awal sebelumnya dengan menggunakan log transaksi. Untuk informasi selengkapnya, lihat Data Management for Reliability.
Pertimbangkan untuk menggunakan akun penyimpanan geo-redundan Data yang disimpan dalam akun Azure Storage selalu direplikasi secara lokal. Namun, ada beberapa strategi replikasi yang dapat dipilih saat akun penyimpanan disediakan. Untuk melindungi data aplikasi Anda dari kasus yang jarang terjadi saat seluruh wilayah tidak tersedia, pilih Azure Read-Access Geo-Redundant Storage (RA-GRS).
Catatan
Untuk VM, jangan mengandalkan replikasi RA-GRS untuk memulihkan disk VM (file VHD). Sebagai gantinya, gunakan Azure Backup.
Pertimbangkan untuk menerapkan data referensi ke beberapa wilayah. Data referensi adalah data yang hanya bisa -dibaca yang mendukung fungsionalitas aplikasi. Biasanya tidak sering berubah. Meskipun pemulihan cadangan adalah salah satu cara untuk menangani gangguan layanan di seluruh wilayah, namun RTO relatif lama. Saat Anda menyebarkan aplikasi ke bagian sekunder, beberapa strategi dapat meningkatkan RTO untuk data referensi.
Karena data referensi jarang berubah, Anda dapat meningkatkan RTO dengan mempertahankan salinan permanen di wilayah sekunder. Ini menghilangkan waktu yang diperlukan untuk memulihkan cadangan setelah terjadi bencana. Untuk memenuhi persyaratan pemulihan bencana di beberapa wilayah, Anda harus menyebarkan aplikasi dan data referensi secara bersama-sama di beberapa wilayah.
Gunakan konkurensi optimis dan konsistensi. Transaksi yang memblokir akses ke sumber daya melalui penguncian (konkurensi yang pesimis) dapat menyebabkan kinerja buruk dan mengurangi ketersediaan. Masalah-masalah ini menjadi sangat akut dalam sistem terdistribusi. Dalam banyak kasus, desain dan teknik yang cermat, seperti pembuatan partisi, dapat meminimalkan kemungkinan terjadinya pembaruan yang tidak sejalan. Jika data direplikasi atau dibaca dari penyimpanan yang diperbarui secara terpisah, data akan konsisten pada akhirnya. Tetapi keuntungan biasanya lebih besar daripada dampak pada ketersediaan transaksi untuk memastikan konsistensi yang cepat.
Gunakan geo-replikasi aktif untuk SQL Database untuk mereplikasi perubahan ke database sekunder. Replikasi geografis aktif untuk Microsoft Azure SQL Database secara otomatis mereplikasi perubahan database ke database sekunder di wilayah yang sama atau wilayah yang berbeda. Untuk informasi selengkapnya, lihat Membuat dan menggunakan geo-replikasi aktif.
Atau, Anda dapat melakukan pendekatan yang lebih manual dengan menggunakan perintah DATABASE COPY untuk membuat salinan cadangan database dengan transaksi yang konsisten. Anda dapat juga menggunakan layanan impor/ekspor Database Azure SQL, yang mendukung ekspor database ke file BACPAC (file terkompresi yang berisi skema database dan data terkait) yang disimpan di penyimpanan Azure Blob. Microsoft Azure Storage membuat dua replika file cadangan di wilayah yang sama. Namun, frekuensi proses pencadangan menentukan RPO Anda, yang merupakan jumlah data yang mungkin hilang dalam skenario bencana. Misalnya, jika mencadangkan data setiap jam, dan bencana terjadi dua menit sebelum pencadangan, Anda akan kehilangan 58 menit data. Juga, untuk melindungi dari gangguan layanan di seluruh wilayah, Anda harus menyalin file BACPAC ke wilayah alternatif. Untuk informasi selengkapnya, lihat Ikhtisar kelangsungan bisnis dengan Azure SQL Database.
Gunakan cadangan-geografis untuk Azure Synapse Analytics. Untuk Azure Synapse, gunakan cadangan- geografis untuk memulihkan data ke wilayah yang dipasangkan untuk pemulihan setelah bencana. Cadangan ini diambil setiap 24 jam dan dapat dipulihkan ke wilayah yang dipasangkan. Fitur ini aktif dan merupakan bawaan untuk semua instans Azure Synapse. Untuk informasi selengkapnya tentang cara memulihkan gudang penyimpanan data Anda, lihat memulihkan dari wilayah geografis Azure menggunakan PowerShell.
Replikasi VM menggunakan Azure Site Recovery. Saat Anda mereplikasi VM Azure menggunakan Site Recovery, semua disk VM terus direplikasi ke wilayah target secara asinkronis. Poin pemulihan dibuat setiap beberapa menit. Ini memberi Anda RPO dalam urutan menit.
Cadangkan SQL Server yang ada di VM atau konfigurasikan sesi pengiriman log. Untuk SQL Server yang berjalan di VM, ada dua opsi: pencadangan tradisional dan pengiriman log. Pencadangan tradisional memungkinkan Anda memulihkan ke titik waktu tertentu, tetapi proses pemulihannya lambat. Memulihkan cadangan tradisional memerlukan dimulainya dengan pencadangan penuh awal, dan kemudian menerapkan cadangan apa pun yang diambil setelah itu. Opsi kedua adalah mengonfigurasi sesi pengiriman log untuk menunda pemulihan cadangan log (misalnya, dua jam). Ini menyediakan jendela untuk memulihkan dari kesalahan yang dibuat pada primer.
Gunakan proses kustom atau pihak ketiga untuk pencadangan Azure Storage. Untuk Microsoft Azure Storage, Anda dapat mengembangkan proses pencadangan kustom atau menggunakan alat pencadangan pihak ketiga. Sebagian besar desain aplikasi memiliki kompleksitas tambahan, di mana sumber daya penyimpanan saling merujuk. Misalnya, pertimbangkan database SQL dengan kolom yang terhubung ke gumpalan di Microsoft Azzure Storage. Jika proses pencadangan tidak terjadi secara bersamaan, database mungkin memiliki penunjuk ke gumpalan yang tidak dicadangkan sebelum terjadi kegagalan. Aplikasi atau rencana pemulihan bencana harus menerapkan proses penanganan inkonsistensi setelah pemulihan.
Gunakan kemampuan replikasi atau foto asli untuk platform data lain yang dihosting di VM. Platform data lain, seperti Elasticsearch atau MongoDB, memiliki kemampuan dan pertimbangan sendiri saat membuat proses pencadangan dan pemulihan terintegrasi. Untuk platform data ini, rekomendasi umumnya menggunakan kemampuan replikasi atau foto berbasis integrasi asli atau yang tersedia. Jika kemampuan tersebut tidak ada atau tidak sesuai, pertimbangkan untuk menggunakan Azure Backup atau foto disk untuk membuat salinan data aplikasi tepat waktu. Dalam semua kasus, penting untuk menentukan bagaimana cara mencapai pencadangan yang konsisten, terutama ketika data aplikasi mencakup beberapa sistem file atau beberapa drive digabungkan menjadi satu sistem file.
Pahami metode replikasi untuk sumber data aplikasi Anda. Data aplikasi Anda akan disimpan di sumber data yang berbeda dan memiliki persyaratan ketersediaan yang bervariasi. Evaluasi metode replikasi untuk setiap jenis penyimpanan data di Azure, termasuk redundansi Azure Storage dan geo-replikasi aktif Database SQL untuk memastikan bahwa persyaratan data aplikasi terpenuhi. Saat Anda mereplikasi VM Azure menggunakan Site Recovery, semua disk VM terus direplikasi ke wilayah target secara asinkronis. Poin pemulihan dibuat setiap beberapa menit.
Penetapan strategi data untuk pemulihan bencana. Penanganan data yang tepat merupakan aspek menantang dari setiap rencana pemulihan bencana. Selama proses pemulihan, pemulihan data biasanya memakan waktu paling lama. Pilihan yang berbeda untuk mengurangi fungsionalitas menghasilkan tantangan yang sulit untuk pemulihan dan konsistensi data.