Pulihkan dari gangguan layanan di seluruh wilayah

Artikel
03/21/2023

Azure dibagi secara fisik dan logis ke dalam unit yang disebut wilayah. Sebuah wilayah terdiri dari satu atau lebih pusat data dalam jarak dekat. Banyak wilayah dan layanan juga mendukung ketersediaan zona, yang dapat digunakan untuk memberikan lebih banyak ketahanan terhadap pemadaman dalam satu pusat data. Pertimbangkan untuk menggunakan wilayah dengan zona ketersediaan untuk meningkatkan ketersediaan solusi Anda.

Dalam keadaan yang jarang terjadi, ada kemungkinan bahwa fasilitas di seluruh zona ketersediaan atau wilayah dapat menjadi tidak dapat diakses, misalnya, karena kegagalan jaringan. Atau fasilitas bisa hilang seluruhnya, misalnya karena bencana alam. Azure memiliki kemampuan untuk membuat aplikasi yang didistribusikan di seluruh zona dan wilayah. Distribusi tersebut membantu meminimalkan kemungkinan kegagalan di satu zona atau wilayah dapat mempengaruhi zona atau wilayah lain.

Layanan cloud

Manajemen sumber daya

Anda dapat mendistribusikan instans komputasi di seluruh wilayah dengan membuat layanan cloud terpisah di setiap wilayah target, lalu menerbitkan paket penyebaran ke setiap layanan cloud. Namun, mendistribusikan lalu lintas di seluruh layanan cloud di berbagai wilayah harus dilaksanakan oleh pengembang aplikasi atau dengan layanan manajemen lalu lintas.

Menentukan jumlah instans peran cadangan yang akan digunakan terlebih dahulu untuk pemulihan bencana merupakan aspek penting dari perencanaan kapasitas. Memiliki penyebaran sekunder skala penuh memastikan bahwa kapasitas sudah tersedia bila diperlukan; namun, ini secara efektif melipat gandakan biaya. Pola umum adalah memiliki penyebaran sekunder yang kecil, cukup besar untuk menjalankan layanan kritis. Penyebaran sekunder kecil ini adalah ide yang bagus, baik untuk mencadangkan kapasitas, dan untuk menguji konfigurasi lingkungan sekunder.

Catatan

Kuota berlangganan bukanlah jaminan kapasitas. Kuota hanyalah batas kredit. Untuk menjamin kapasitas, jumlah peran yang diperlukan harus didefinisikan dalam model layanan, dan peran harus disebarkan.

Penyeimbangan Beban

Untuk memuat lalu lintas keseimbangan di seluruh wilayah memerlukan solusi manajemen lalu lintas. Azure menyediakan Azure Traffic Manager. Anda juga dapat memanfaatkan layanan pihak ketiga yang menyediakan kemampuan manajemen lalu lintas serupa.

Strategi

Banyak strategi alternatif yang tersedia untuk menerapkan komputasi terdistribusi di seluruh wilayah. Strategi ini harus disesuaikan dengan kebutuhan bisnis tertentu dan keadaan aplikasi. Pada tingkat tinggi, pendekatan dapat dibagi ke dalam kategori berikut:

Menyebarkan ulang saat bencana: Dalam pendekatan ini, aplikasi disebarkan ulang dari awal pada saat bencana. Pendekatan ini sesuai untuk aplikasi non-kritis yang tidak memerlukan waktu pemulihan yang terjamin.
Warm Spare (Aktif/Pasif): Layanan host sekunder dibuat di wilayah alternatif, dan peran digunakan untuk menjamin kapasitas minimal; namun, peran tersebut tidak menerima lalu lintas produksi. Pendekatan ini berguna untuk aplikasi yang belum dirancang untuk mendistribusikan lalu lintas antar wilayah.
Hot Spare (Aktif/Aktif): Aplikasi dirancang untuk menerima beban produksi di beberapa wilayah. Layanan cloud di setiap wilayah mungkin dikonfigurasi untuk kapasitas yang lebih tinggi daripada yang diperlukan untuk tujuan pemulihan bencana. Sebagai gantinya, layanan cloud mungkin diskalakan seperlunya pada saat terjadi bencana dan kegagalan. Pendekatan ini membutuhkan investasi besar dalam desain aplikasi, tetapi memiliki manfaat yang signifikan. Ini termasuk waktu pemulihan yang rendah dan terjamin, pengujian berkelanjutan dari semua lokasi pemulihan, dan penggunaan kapasitas yang efisien.

Diskusi lengkap tentang desain terdistribusi berada di luar lingkup dokumen ini. Untuk informasi selengkapnya, lihat Pemulihan Bencana dan Ketersediaan Tinggi untuk Aplikasi Azure.

Komputer virtual

Pemulihan infrastruktur sebagai layanan (IaaS) mesin virtual (VM) mirip dengan platform sebagai layanan (PaaS) compute recovery dalam banyak hal. Namun, ada perbedaan penting karena fakta bahwa IaaS VM terdiri dari VM dan disk VM.

Gunakan Azure Backup untuk membuat pencadangan lintas wilayah yang konsisten dengan aplikasi. Azure Backup memungkinkan pelanggan untuk membuat cadangan aplikasi yang konsisten di beberapa disk VM, dan mendukung replikasi pencadangan di seluruh wilayah. Anda dapat melakukan ini dengan memilih untuk mereplikasi secara geografis kubah cadangan pada saat pembuatan. Replikasi vault cadangan harus dikonfigurasi pada saat pembuatan. Itu tidak bisa diatur nanti. Jika wilayah hilang, Microsoft akan membuat cadangan tersedia untuk pelanggan. Pelanggan akan dapat memulihkan ke salah satu titik pemulihan yang dikonfigurasi.
Pisahkan disk data dari disk sistem operasi. Pertimbangan penting untuk VM IaaS adalah Anda tidak dapat mengubah disk sistem operasi tanpa membuat ulang VM. Ini bukanlah masalah jika strategi pemulihan Anda adalah memindahkan setelah bencana. Namun, mungkin menjadi masalah jika Anda menggunakan pendekatan Warm Spare untuk kapasitas cadangan. Untuk menerapkan ini dengan benar, Anda harus memiliki disk sistem operasi yang benar yang digunakan ke lokasi primer dan sekunder, dan data aplikasi harus disimpan pada drive terpisah. Jika memungkinkan, gunakan konfigurasi sistem operasi standar yang dapat disediakan di kedua lokasi. Setelah failover, Anda kemudian harus melampirkan drive data ke VM IaaS yang ada di DC sekunder. Gunakan AzCopy untuk menyalin snapshot dari disk data ke situs jarak jauh.
Waspadai potensi masalah konsistensi setelah kegagalan geografis beberapa Disk VM. VM Disk diterapkan sebagai blob Azure Storage, dan memiliki karakteristik replikasi geografis yang sama. Kecuali Azure Backup digunakan, tidak ada jaminan konsistensi di seluruh disk, karena replikasi geografis asinkron dan mereplikasi secara independen. Disk VM individual dijamin berada dalam keadaan konsisten crash setelah geo-failover, tetapi tidak konsisten di seluruh disk. Hal ini dapat menyebabkan masalah dalam beberapa kasus (misalnya, dalam kasus disk striping).
Gunakan Azure Site Recovery untuk mereplikasi aplikasi di seluruh wilayah. Dengan Azure Site Recovery, pelanggan tidak perlu khawatir tentang memisahkan disk data dari disk sistem operasi atau tentang potensi masalah konsistensi. Azure Site Recovery mereplikasi beban kerja yang berjalan pada mesin fisik dan virtual dari situs utama (baik lokal atau di Azure) ke lokasi sekunder (di Azure). Ketika pemadaman terjadi di situs utama pelanggan, failover dapat dipicu untuk dengan cepat mengembalikan pelanggan ke keadaan operasional. Setelah lokasi utama dipulihkan, pelanggan kemudian dapat gagal kembali. Mereka dapat mereplikasi menggunakan titik pemulihan dengan snapshot yang konsisten untuk aplikasi. Snapshot ini menangkap data disk, semua data dalam memori, dan semua transaksi dalam proses. Azure Site Recovery memungkinkan pelanggan untuk menjaga tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) dalam batas organisasi. Pelanggan juga dapat dengan mudah menjalankan latihan pemulihan bencana tanpa mempengaruhi aplikasi dalam produksi. Dengan menggunakan paket pemulihan, pelanggan dapat mengurutkan failover dan pemulihan aplikasi multitier yang berjalan pada beberapa VM. Mereka dapat mengelompokkan mesin bersama-sama dalam rencana pemulihan, dan secara opsional menambahkan skrip dan tindakan manual. Rencana pemulihan dapat diintegrasikan dengan runbook Azure Automation.

Penyimpanan

Pemulihan dengan menggunakan penyimpanan geo-redundan blob, tabel, antrean, dan penyimpanan disk VM

Di Azure, blob, tabel, antrean, dan disk VM semuanya direplikasi secara geografis secara default. Ini disebut sebagai penyimpanan geo-redundan (GRS). GRS mereplikasi data penyimpanan ke pusat data berpasangan yang terletak ratusan mil terpisah dalam wilayah geografis tertentu. GRS dirancang untuk memberikan daya tahan tambahan jika ada bencana pusat data utama. Microsoft mengontrol ketika failover terjadi, dan failover terbatas pada bencana besar di mana lokasi utama asli dianggap tidak dapat diperbaiki dalam jumlah waktu yang wajar. Dalam beberapa skenario, hal ini bisa beberapa hari. Data biasanya direplikasi dalam beberapa menit, meskipun interval penyelarasan belum dicakup oleh perjanjian tingkat layanan.

Jika geo-failover terjadi, tidak akan ada perubahan pada cara akun diakses (URL dan kunci akun tidak akan berubah). Akun penyimpanan akan, bagaimanapun, berada di wilayah yang berbeda setelah failover. Hal ini dapat berdampak pada aplikasi yang memerlukan afinitas regional dengan akun penyimpanan mereka. Bahkan untuk layanan dan aplikasi yang tidak memerlukan akun penyimpanan di pusat data yang sama, latensi pusat data silang dan biaya bandwidth mungkin menjadi alasan kuat untuk memindahkan lalu lintas ke wilayah failover sementara. Ini bisa menjadi faktor dalam strategi pemulihan bencana secara keseluruhan.

Selain failover otomatis yang disediakan oleh GRS, Azure telah memperkenalkan layanan yang memberi Anda akses baca ke salinan data Anda di lokasi penyimpanan sekunder. Ini disebut penyimpanan read-access geo-redundant (RA-GRS).

Untuk informasi selengkapnya tentang penyimpanan GRS dan RA-GRS, lihat replikasi Azure Storage.

Pemetaan wilayah replikasi geografis

Penting untuk mengetahui di mana data Anda direplikasi secara geografis, untuk mengetahui di mana menyebarkan contoh lain dari data Anda yang memerlukan afinitas regional dengan penyimpanan Anda. Untuk informasi selengkapnya, lihat Wilayah berpasangan Azure.

Biaya replikasi geografis

Replikasi geografis termasuk dalam harga saat ini untuk Azure Storage. Ini disebut penyimpanan geo-redundan (GRS). Jika Anda tidak ingin data Anda direplikasi secara geografis, Anda dapat menonaktifkan replikasi geografis untuk akun Anda. Ini disebut penyimpanan redundan lokal (LRS), dan dikenakan harga diskon dibandingkan dengan GRS.

Menentukan apakah geo-failover telah terjadi

Jika terjadi geo-failover, ini akan diposting ke Dasbor Azure Service Health. Aplikasi dapat menerapkan cara otomatis untuk mendeteksi ini, bagaimanapun, dengan memantau geo-wilayah untuk akun penyimpanan mereka. Ini dapat digunakan untuk memicu operasi pemulihan lainnya, seperti aktivasi sumber daya komputasi di wilayah geografis tempat penyimpanan mereka dipindahkan. Anda dapat melakukan kueri untuk ini dari API manajemen layanan, dengan menggunakan Get Storage Account Properties. Properti yang relevan adalah:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime>
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion>
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

Database

SQL Database

Azure SQL Database menyediakan dua jenis pemulihan: pemulihan geo dan replikasi geo aktif.

Pengembalian geografis

Pemulihan geo juga tersedia dengan database Dasar, Standar, dan Premium. Fitur ini menyediakan opsi pemulihan default ketika database tidak tersedia karena insiden di wilayah tempat database Anda dihosting. Mirip dengan pemulihan titik waktu, pemulihan geo bergantung pada cadangan database di penyimpanan Azure geo-redundan. Fitur ini memulihkan dari salinan cadangan yang direplikasi secara geografis, sehingga tahan terhadap pemadaman penyimpanan di wilayah utama. Untuk informasi selengkapnya, lihat Memulihkan Azure SQL Database atau failover ke wilayah sekunder.

Replikasi Geo Aktif

Replikasi geo aktif tersedia untuk semua tingkat database. Ini dirancang untuk aplikasi yang memiliki persyaratan pemulihan yang lebih agresif daripada yang dapat ditawarkan oleh geo-restore. Dengan menggunakan geo-replikasi aktif, Anda dapat membuat hingga empat sekunder yang dapat dibaca di server dalam wilayah yang berbeda. Anda dapat memulai failover ke salah satu sekunder. Selain itu, geo-replikasi aktif dapat digunakan untuk mendukung peningkatan aplikasi atau skenario relokasi, serta penyeimbangan beban untuk beban kerja baca-saja. Untuk detail selengkapnya, lihat Mengonfigurasi replikasi geo aktif untuk Azure SQL Database dan memulai failover. Lihat Merancang layanan yang tersedia secara global menggunakan Azure SQL Database dan Mengelola peningkatan berkelanjutan dari aplikasi cloud dengan menggunakan replikasi geo aktif SQL Database untuk detail tentang cara merancang dan menerapkan aplikasi dan peningkatan aplikasi tanpa waktu henti.

SQL Server on Azure Virtual Machines

Berbagai opsi tersedia untuk pemulihan dan ketersediaan tinggi untuk SQL Server 2012 (dan yang lebih baru) yang berjalan di Azure Virtual Machines. Untuk informasi selengkapnya, lihat Ketersediaan tinggi dan pemulihan bencana untuk SQL Server di Mesin Virtual Azure.

Layanan platform Azure lainnya

Saat mencoba menjalankan layanan cloud di beberapa wilayah Azure, Anda harus mempertimbangkan implikasi untuk setiap dependensi Anda. Di bagian berikut, panduan khusus layanan mengasumsikan bahwa Anda harus menggunakan layanan Azure yang sama di pusat data Azure alternatif. Ini melibatkan tugas konfigurasi dan replikasi data.

Catatan

Dalam beberapa kasus, langkah-langkah ini dapat membantu mengurangi pemadaman khusus layanan daripada seluruh peristiwa pusat data. Dari perspektif aplikasi, pemadaman khusus layanan mungkin sama membatasi dan akan mengharuskan migrasi sementara layanan ke wilayah Azure alternatif.

Service Bus

Azure Service Bus menggunakan namespace layanan unik yang tidak mencakup wilayah Azure. Jadi persyaratan pertama adalah menyiapkan namespace bus layanan yang diperlukan di wilayah alternatif. Namun, ada juga pertimbangan untuk daya tahan pesan yang mengantre. Ada beberapa strategi untuk mereplikasi pesan di seluruh wilayah Azure. Untuk detail tentang strategi replikasi ini dan strategi pemulihan bencana lainnya, lihat Praktik terbaik untuk mengisolasi aplikasi terhadap pemadaman dan bencana Bus Layanan.

App Service

Untuk memigrasikan aplikasi Azure App Service, seperti Aplikasi Web atau Aplikasi Seluler, ke wilayah Azure sekunder, Anda harus memiliki cadangan situs web yang tersedia untuk dipublikasikan. Jika pemadaman tidak melibatkan seluruh pusat data Azure, dimungkinkan untuk menggunakan FTP untuk mengunduh cadangan konten situs terbaru. Kemudian buat aplikasi baru di wilayah alternatif, kecuali Anda sebelumnya telah melakukan ini untuk memesan kapasitas. Terbitkan situs ke wilayah baru, dan buat perubahan konfigurasi yang diperlukan. Perubahan ini dapat mencakup string koneksi database atau pengaturan khusus wilayah lainnya. Jika perlu, tambahkan sertifikat SSL situs dan ubah catatan DNS CNAME sehingga nama domain kustom mengarah ke URL Azure Web App yang dipindahkan.

HDInsight

Data yang terkait dengan HDInsight disimpan secara default di Azure Blob Storage. HDInsight mensyaratkan bahwa pekerjaan pemrosesan kluster Hadoop MapReduce harus dikosongkan di wilayah yang sama dengan akun penyimpanan yang berisi data yang sedang dianalisis. Asalkan Anda menggunakan fitur replikasi geografis yang tersedia untuk Azure Storage, Anda dapat mengakses data Anda di wilayah sekunder tempat data direplikasi jika karena alasan tertentu wilayah utama tidak lagi tersedia. Anda dapat membuat kluster Hadoop baru di wilayah tempat data telah direplikasi dan terus memprosesnya.

Pelaporan SQL

Saat ini, pemulihan dari hilangnya wilayah Azure memerlukan beberapa instans Pelaporan SQL di berbagai wilayah Azure. Contoh pelaporan SQL ini harus mengakses data yang sama, dan data tersebut harus memiliki rencana pemulihan sendiri jika terjadi bencana. Anda juga dapat menyimpan salinan cadangan eksternal dari file RDL untuk setiap laporan.

Media Services

Azure Media Services memiliki pendekatan pemulihan yang berbeda untuk pengodean dan streaming. Biasanya, streaming lebih penting selama pemadaman regional. Untuk mempersiapkan ini, Anda harus memiliki akun Media Services di dua wilayah Azure yang berbeda. Konten yang dikodekan harus ditempatkan di kedua wilayah. Selama kegagalan, Anda dapat mengalihkan lalu lintas streaming ke wilayah alternatif. Pengodean dapat dilakukan di wilayah Azure mana pun. Jika pengodean sensitif terhadap waktu, misalnya selama pemrosesan peristiwa langsung, Anda harus siap untuk mengirimkan pekerjaan ke pusat data alternatif selama kegagalan.

Jaringan virtual

File konfigurasi menyediakan cara tercepat untuk menyiapkan jaringan virtual di wilayah Azure alternatif. Setelah mengonfigurasi jaringan virtual di wilayah Azure utama, ekspor pengaturan jaringan virtual untuk jaringan saat ini ke file konfigurasi jaringan. Jika pemadaman terjadi di wilayah utama, pulihkan jaringan virtual dari file konfigurasi tersimpan. Kemudian konfigurasikan layanan cloud lainnya, mesin virtual, atau pengaturan lintas tempat untuk bekerja dengan jaringan virtual baru.
Ada sumber daya terkait VNET yang perlu kita pertimbangkan (Mis. NSG, DNS, Tabel Rute). Metode yang dijelaskan dalam Infrastruktur sebagai kode adalah cara untuk menghasilkan lingkungan yang sama setiap saat, dan Anda dapat menyebarkan di wilayah baru.

Daftar periksa untuk pemulihan bencana

Daftar periksa Cloud Services

Tinjau bagian Cloud Services dari dokumen ini.
Buat strategi pemulihan bencana lintas wilayah.
Memahami trade-off dalam memesan kapasitas di daerah alternatif.
Gunakan alat perutean lalu lintas, seperti Azure Traffic Manager.

Daftar periksa Microsoft Azure Virtual Machines

Tinjau bagian Microsoft Azure Virtual Machines dari dokumen ini.
Gunakan Azure Backup untuk membuat pencadangan yang konsisten di seluruh wilayah.

daftar periksa Storage

Tinjau bagian Storage dari dokumen ini.
Jangan menonaktifkan replikasi geografis sumber daya penyimpanan.
Memahami wilayah alternatif untuk replikasi geografis jika failover terjadi.
Buat strategi pencadangan kustom untuk strategi failover yang dikendalikan pengguna.

daftar periksa SQL Database

Tinjau bagian SQL Database dari dokumen ini.
Gunakan geo-pemulihan atau geo-replikasi yang sesuai.

SQL Server pada daftar periksa Microsoft Azure Virtual Machines

Tinjau bagian SQL Server pada Microsoft Azure Virtual Machines dari dokumen ini.
Gunakan Grup Ketersediaan AlwaysOn lintas wilayah atau pencerminan database.
Secara bergantian gunakan pencadangan dan pulihkan ke penyimpanan blob.

Daftar periksa Bus Layanan

Tinjau bagian Bus Layanan dari dokumen ini.
Konfigurasikan namespace layanan Bus Layanan di wilayah alternatif.
Pertimbangkan strategi replikasi kustom untuk pesan di seluruh wilayah.

Daftar periksa App Service

Tinjau bagian App Service dari dokumen ini.
Pertahankan pencadangan situs di luar wilayah utama.
Jika pemadaman parsial, cobalah untuk mengambil situs saat ini dengan FTP.
Rencanakan untuk menyebarkan situs ke situs baru atau yang sudah ada di wilayah alternatif.
Rencanakan perubahan konfigurasi untuk catatan aplikasi dan DNS CNAME.

Daftar periksa HDInsight

Tinjau bagian HDInsight dari dokumen ini.
Buat kluster Hadoop baru di wilayah tersebut dengan data yang direplikasi.

Daftar periksa Pelaporan SQL

Tinjau bagian Pelaporan SQL dari dokumen ini.
Pertahankan instans Pelaporan SQL alternatif di wilayah lain.
Pertahankan rencana terpisah untuk mereplikasi target ke wilayah itu.

Daftar periksa Media Services

Tinjau bagian Media Services dari dokumen ini.
Buat akun Media Services di wilayah alternatif.
Encode konten yang sama di kedua wilayah untuk mendukung failover streaming.
Kirimkan pekerjaan pengodean ke wilayah alternatif jika terjadi gangguan layanan.

Daftar periksa Virtual Network

Tinjau bagian Virtual Network dari dokumen ini.
Gunakan pengaturan virtual network yang diekspor untuk membuatnya kembali di wilayah lain.