Gunakan pemulihan geografis untuk memulihkan aplikasi SaaS multi-penyewa dari cadangan database

Berlaku untuk: Azure SQL Database

Tutorial ini mengeksplorasi skenario pemulihan bencana penuh untuk aplikasi SaaS multi-penyewa yang diterapkan menggunakan model database per penyewa. Anda menggunakan pemulihan geografis untuk memulihkan katalog dan database penyewa dari cadangan geo-redundan yang dikelola secara otomatis ke wilayah pemulihan alternatif. Setelah pemadaman teratasi, Anda menggunakan replikasi geografis untuk merepatriasi database yang diubah ke wilayah aslinya.

Pemulihan geografis adalah solusi pemulihan bencana berbiaya terendah untuk Azure SQL Database. Namun, memulihkan dari cadangan geo-redundan dapat mengakibatkan hilangnya data hingga satu jam. Prosesnya dapat memakan waktu lama, bergantung pada ukuran setiap database.

Catatan

Pulihkan aplikasi dengan RPO dan RTO serendah mungkin menggunakan replikasi geografis sebagai ganti pemulihan geografis.

Tutorial ini mengeksplorasi alur kerja pemulihan dan repatriasi. Anda akan mempelajari cara untuk:

• Menyinkronkan database dan info konfigurasi kumpulan elastis ke dalam katalog penyewa.
• Menyiapkan lingkungan gambar cermin di wilayah pemulihan yang mencakup aplikasi, server, dan kumpulan.
• Memulihkan database katalog dan penyewa menggunakan pemulihan geografis.
• Menggunakan replikasi geografis untuk merepatriasi katalog penyewa dan mengubah database penyewa setelah pemadaman teratasi.
• Memperbarui katalog saat setiap database dipulihkan (atau direpatriasi) untuk melacak lokasi salinan aktif database setiap penyewa saat ini.
• Memastikan aplikasi dan database penyewa selalu berada di wilayah Azure yang sama untuk mengurangi latensi.

Sebelum Anda memulai tutorial ini, selesaikan prasyarat berikut:

• Terapkan database Wingtip Tickets SaaS per aplikasi penyewa. Untuk menerapkan dalam waktu kurang dari lima menit, lihat Menerapkan dan menjelajahi aplikasi Database Multi-penyewa Wingtip Tickets SaaS.
• Pasang Azure PowerShell. Untuk detailnya, lihat Mulai menggunakan Azure PowerShell.

Pengenalan pola pemulihan dengan pemulihan geografis

Pemulihan bencana (DR) menjadi pertimbangan penting bagi banyak aplikasi, baik karena alasan kepatuhan maupun kelangsungan bisnis. Jika terjadi pemadaman layanan yang berkepanjangan, rencana DR yang disiapkan dengan baik dapat meminimalkan gangguan bisnis. Rencana DR berdasarkan pemulihan geografis harus mencapai beberapa tujuan:

• Mencadangkan semua kapasitas yang diperlukan di wilayah pemulihan yang dipilih secepat mungkin untuk memastikan bahwa kapasitas tersebut tersedia untuk memulihkan database penyewa.
• Membuat lingkungan pemulihan gambar cermin yang mencerminkan kumpulan asli dan konfigurasi database.
• Mengizinkan pembatalan proses pemulihan di pertengahan proses jika wilayah asli kembali online.
• Memungkinkan penyediaan penyewa dengan cepat sehingga orientasi penyewa baru dapat dimulai ulang secepatnya.
• Dioptimalkan untuk memulihkan penyewa dalam urutan prioritas.
• Dioptimalkan untuk memungkinkan penyewa online secepat mungkin dengan melakukan langkah-langkah secara paralel jika memungkinkan.
• Tahan terhadap kegagalan, dapat dimulai ulang, dan idempoten.
• Repatriasi database ke wilayah aslinya dengan dampak minimal bagi penyewa ketika pemadaman teratasi.

Catatan

Aplikasi dipulihkan ke wilayah yang dipasangkan dari wilayah tempat aplikasi diterapkan. Untuk informasi selengkapnya, lihat Wilayah berpasangan Azure.

Tutorial ini menggunakan fitur Azure SQL Database dan platform Azure untuk mengatasi tantangan ini:

• Template Azure Resource Manager, untuk mencadangkan semua kapasitas yang diperlukan secepat mungkin. Templat Azure Resource Manager digunakan untuk menyediakan gambar cermin server asli dan kumpulan elastis di wilayah pemulihan. Server dan kumpulan terpisah juga dibuat untuk menyediakan penyewa baru.
• Elastic Database Client Library (EDCL), untuk membuat dan memelihara katalog database penyewa. Katalog yang diperluas mencakup kumpulan yang direfresh secara berkala dan informasi konfigurasi database.
• Fitur pemulihan manajemen Shard EDCL, untuk mempertahankan entri lokasi database dalam katalog selama pemulihan dan repatriasi.
• Pemulihan geografis, untuk memulihkan katalog dan database penyewa dari pencadangan geo-redundan yang dikelola secara otomatis.
• Operasi pemulihan asinkron, dikirim dalam urutan prioritas penyewa, diantrekan untuk setiap kumpulan oleh sistem dan diproses dalam batch sehingga kumpulan tidak kelebihan beban. Operasi ini dapat dibatalkan sebelum atau selama eksekusi jika perlu.
• Replikasi geografis, untuk merepatriasi database ke wilayah asli setelah pemadaman. Tidak ada kehilangan data dan dampak minimal pada penyewa saat Anda menggunakan replikasi geografis.
• Alias DNS server SQL, untuk memungkinkan proses sinkronisasi katalog terhubung ke katalog aktif terlepas dari lokasinya.

Dapatkan skrip pemulihan bencana

Skrip DR yang digunakan dalam tutorial ini tersedia dalam database Wingtip Tickets SaaS per repositori GitHub penyewa. Lihat panduan umum untuk langkah-langkah mengunduh dan membuka blokir skrip manajemen Tiket Wingtip.

Penting

Seperti semua skrip manajemen Tiket Wingtip, skrip DR berkualitas sampel dan tidak digunakan dalam produksi.

Tinjau keadaan aplikasi yang sehat

Sebelum Anda memulai proses pemulihan, tinjau keadaan aplikasi yang sehat normal.

1. Di browser web Anda, buka hub acara Wingtip Tickets (http://events.wingtip-dpt.<user>.trafficmanager.net, ganti <user> dengan nilai pengguna penyebaran).

   Gulir ke bagian bawah halaman dan perhatikan nama dan lokasi server katalog di footer. Lokasi adalah wilayah tempat Anda menerapkan aplikasi.

   Tip

   Arahkan mouse ke lokasi untuk memperbesar tampilan.

   

2. Pilih penyewa Contoso Concert Hall dan buka halaman acaranya.

   Di catatan kaki, perhatikan nama server penyewa. Lokasinya akan sama dengan lokasi server katalog.

   

3. Di portal Microsoft Azure, tinjau dan buka grup sumber daya tempat Anda menyebarkan aplikasi.

   Perhatikan sumber daya dan wilayah tempat komponen layanan aplikasi dan SQL Database disebarkan.

Menyinkronkan konfigurasi penyewa ke dalam katalog

Dalam tugas ini, Anda memulai proses untuk menyinkronkan konfigurasi server, kumpulan elastis, dan database ke dalam katalog penyewa. Informasi ini digunakan nanti untuk mengonfigurasi lingkungan gambar cermin di wilayah pemulihan.

Penting

Demi kemudahan, sinkronisasi dan proses pemulihan serta repatriasi jangka panjang lainnya diimplementasikan di dalam tutorial ini sebagai pekerjaan atau sesi PowerShell lokal yang berjalan di bawah login pengguna klien Anda. Token autentikasi yang dikeluarkan ketika Anda masuk akan kedaluwarsa setelah beberapa jam dan pekerjaan kemudian akan gagal. Dalam skenario produksi, proses jangka panjang harus diimplementasikan sebagai layanan Azure yang andal dari beberapa jenis, berjalan di bawah perwakilan layanan. Lihat Menggunakan Azure PowerShell untuk membuat perwakilan layanan dengan sertifikat.

1. Di PowerShell ISE, buka file ...\Learning Modules\UserConfig.psm1. Ganti <resourcegroup> dan <user> pada baris 10 dan 11 dengan nilai yang digunakan saat Anda menyebarkan aplikasi. Simpan file.

2. Di PowerShell ISE, buka skrip ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1.

   Dalam tutorial ini, Anda menjalankan setiap skenario dalam skrip PowerShell ini, jadi tetap buka file ini.

3. Atur berikut ini:

   $DemoScenario = 1: Mulai pekerjaan latar belakang yang menyinkronkan info konfigurasi kumpulan dan server penyewa ke dalam katalog.

4. Untuk menjalankan skrip sinkronisasi, pilih F5.

   Informasi ini digunakan nanti untuk memastikan bahwa pemulihan membuat gambar cermin server, kumpulan, dan database di wilayah pemulihan.

   

Biarkan jendela PowerShell berjalan di latar belakang dan lanjutkan sisa tutorial ini.

Catatan

Proses sinkronisasi tersambung ke katalog melalui alias DNS. Alias ini dimodifikasi selama pemulihan dan repatriasi untuk menunjuk ke katalog aktif. Proses sinkronisasi memastikan katalog selalu diperbarui dengan perubahan konfigurasi database atau kumpulan apa pun yang dibuat di wilayah pemulihan. Selama repatriasi, perubahan ini diterapkan pada sumber daya yang setara di wilayah asli.

Gambaran umum proses pemulihan geografis

Proses pemulihan geografis menyebarkan aplikasi dan memulihkan database dari cadangan ke wilayah pemulihan.

Proses pemulihan melakukan hal berikut:

1. Menonaktifkan titik akhir Azure Traffic Manager untuk aplikasi web di wilayah asli. Menonaktifkan titik akhir mencegah pengguna terhubung ke aplikasi dalam keadaan tidak valid jika wilayah asli online selama pemulihan.

2. Menyediakan server katalog pemulihan di wilayah pemulihan, melakukan pemulihan geografis untuk database katalog, dan memperbarui alias activecatalog untuk menunjuk ke server katalog yang dipulihkan. Mengubah alias katalog memastikan bahwa proses sinkronisasi katalog selalu disinkronkan ke katalog aktif.

3. Menandai semua penyewa yang ada dalam katalog pemulihan sebagai offline untuk mencegah akses ke database penyewa sebelum dipulihkan.

4. Menyediakan instans aplikasi di wilayah pemulihan dan mengonfigurasikannya untuk menggunakan katalog yang dipulihkan di wilayah tersebut. Untuk menjaga latensi minimal, aplikasi sampel dirancang untuk selalu terhubung ke database penyewa di wilayah yang sama.

5. Menyediakan server dan kumpulan elastis tempat penyewa baru tersedia. Pembuatan sumber daya ini akan memastikan bahwa penyediaan penyewa baru tidak mengganggu pemulihan penyewa yang sudah ada.

6. Memperbarui alias penyewa baru untuk mengarahkan ke server untuk database penyewa baru di wilayah pemulihan. Pengubahan alias ini akan memastikan bahwa database untuk penyewa baru tersedia di wilayah pemulihan.

7. Menyediakan server dan kumpulan elastis di wilayah pemulihan untuk memulihkan database penyewa. Server dan kumpulan ini adalah gambar cermin dari konfigurasi di wilayah aslinya. Penyediaan kumpulan di depan akan mempertahankan kapasitas yang diperlukan untuk memulihkan semua database.

   Pemadaman di sebuah wilayah mungkin memberikan tekanan signifikan pada sumber daya yang tersedia di wilayah yang dipasangkan. Jika Anda mengandalkan pemulihan geografis untuk DR, sebaiknya pesan sumber daya dengan cepat. Pertimbangkan replikasi geografis jika penting untuk sebuah aplikasi dipulihkan di wilayah tertentu.

8. Mengaktifkan endpoint Traffic Manager untuk aplikasi web di wilayah asli. Mengaktifkan endpoint ini memungkinkan aplikasi untuk menyediakan penyewa baru. Pada tahap ini, penyewa yang ada masih offline.

9. Mengirimkan batch permintaan untuk memulihkan database dalam urutan prioritas.

   • Batch teratur sehingga database dipulihkan secara paralel di semua kumpulan.

   • Permintaan pemulihan diajukan secara asinkron sehingga permintaan tersebut diajukan dengan cepat dan diantrekan untuk dijalankan di setiap kumpulan.

   • Karena permintaan pemulihan diproses secara paralel di semua kumpulan, akan lebih baik untuk mendistribusikan penyewa penting di banyak kumpulan.

10. Pantau layanan untuk menentukan waktu pemulihan database. Setelah database penyewa dipulihkan, database ditandai online di katalog, dan jumlah rowversion untuk database penyewa akan direkam.

    • Database penyewa dapat diakses oleh aplikasi segera setelah ditandai secara online di katalog.

    • Sejumlah nilai rowversion dalam database penyewa disimpan di katalog. Jumlah ini bertindak sebagai sidik jari yang memungkinkan proses repatriasi untuk menentukan apakah database telah diperbarui di wilayah pemulihan.

Jalankan skrip pemulihan

Penting

Tutorial ini memulihkan database dari cadangan geo-redundan. Meskipun cadangan ini biasanya tersedia dalam waktu 10 menit, itu bisa memakan waktu hingga satu jam. Skrip akan jeda hingga tersedia.

Bayangkan terdapat pemadaman di wilayah tempat aplikasi disebarkan, dan jalankan skrip pemulihan:

1. Di PowerShell ISE, di dalam skrip ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, tetapkan nilai berikut:

   $DemoScenario = 2: Pulihkan aplikasi ke wilayah pemulihan dengan memulihkan dari cadangan geo-redundan.

2. Untuk menjalankan skrip, pilih F5.

   • Skrip terbuka di jendela PowerShell yang baru dan kemudian memulai serangkaian pekerjaan PowerShell yang berjalan secara paralel. Pekerjaan-pekerjaan ini akan memulihkan server, kumpulan, dan database ke wilayah pemulihan.

   • Wilayah pemulihan adalah wilayah yang dipasangkan yang terkait dengan wilayah Azure tempat Anda menyebarkan aplikasi. Untuk informasi selengkapnya, lihat Wilayah berpasangan Azure.

3. Pantau status proses pemulihan di jendela PowerShell.

   

Catatan

Untuk menjelajahi kode untuk pekerjaan pemulihan, tinjau skrip PowerShell di folder ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\RecoveryJobs.

Tinjau status aplikasi selama pemulihan

Sementara endpoint aplikasi dinonaktifkan di Traffic Manager, aplikasi tidak tersedia. Katalog dipulihkan, dan semua penyewa ditandai offline. Titik akhir aplikasi di wilayah pemulihan kemudian diaktifkan, dan aplikasi kembali online. Meskipun aplikasi tersedia, penyewa akan tetap muncul offline di hub acara sampai database mereka dipulihkan. Penting untuk merancang aplikasi Anda untuk menangani database penyewa offline.

• Setelah database katalog dipulihkan tetapi sebelum penyewa kembali online, refresh hub acara Wingtip Tickets di browser web Anda.

  • Di catatan kaki, perhatikan bahwa nama server katalog sekarang memiliki akhiran -recovery dan terletak di wilayah pemulihan.

  • Perhatikan bahwa penyewa yang belum dipulihkan, ditandai sebagai offline, dan tidak dapat dipilih.

    

  • Jika Anda membuka halaman acara penyewa secara langsung saat penyewa offline, halaman akan menampilkan pemberitahuan penyewa offline. Misalnya, jika Contoso Concert Hall offline, coba buka http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall.

    

Menyediakan penyewa baru di wilayah pemulihan

Bahkan sebelum database penyewa dipulihkan, Anda dapat menyediakan penyewa baru di wilayah pemulihan. Database penyewa baru yang tersedia di wilayah pemulihan akan direpatriasi dengan database yang dipulihkan nanti.

1. Di PowerShell ISE, di dalam skrip ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, tetapkan properti berikut:

   $DemoScenario = 3: Provisikan penyewa baru di wilayah pemulihan.

2. Untuk menjalankan skrip, pilih F5.

3. Halaman acara Hawthorn Hall terbuka di browser ketika provisi selesai.

   Perhatikan bahwa database Hawthorn Hall terletak di wilayah pemulihan.

   

4. Di browser, refresh halaman hub acara Wingtip Tickets untuk melihat Hawthorn Hall yang disertakan.

   Jika Anda menyediakan Hawthorn Hall tanpa menunggu penyewa lain melakukan pemulihan, penyewa lain mungkin masih offline.

Tinjau status aplikasi yang dipulihkan

Ketika proses pemulihan selesai, aplikasi dan semua penyewa berfungsi penuh di wilayah pemulihan.

1. Setelah tampilan di jendela konsol PowerShell menunjukkan semua penyewa dipulihkan, refresh hub acara.

   Semua penyewa akan muncul online, termasuk penyewa baru, Hawthorn Hall.

   

2. Klik Contoso Concert Hall dan buka halaman acaranya.

   Di catatan kaki, perhatikan bahwa database terletak di server pemulihan yang terletak di wilayah pemulihan.

   

3. Di portal Azure, buka daftar grup sumber daya.

   Perhatikan grup sumber daya yang Anda sebarkan, ditambah grup sumber daya pemulihan, dengan akhiran -recovery. Grup sumber daya pemulihan berisi semua sumber daya yang dibuat selama proses pemulihan, ditambah sumber daya baru yang dibuat selama pemadaman.

4. Buka grup sumber daya pemulihan dan perhatikan item berikut:

   • Versi pemulihan katalog dan server tenants1, dengan akhiran -recovery. Katalog yang dipulihkan dan database penyewa di server ini semuanya memiliki nama yang digunakan di wilayah asli.

   • Server SQL tenants2-dpt-<user>-recovery. Server ini digunakan untuk menyediakan penyewa baru selama pemadaman.

   • Layanan aplikasi bernama events-wingtip-dpt-<recoveryregion>-<user>, yang merupakan instans pemulihan dari aplikasi acara.

     

5. Buka server SQL tenants2-dpt-<user>-recovery. Perhatikan bahwa di dalamnya berisi database hawthornhall dan kumpulan elastis Pool1. Database hawthornhall dikonfigurasi sebagai database elastis di kumpulan elastis Pool1.

Mengubah data penyewa

Dalam tugas ini, Anda memperbarui salah satu database penyewa yang dipulihkan. Proses repatriasi menyalin database yang dipulihkan yang telah diubah ke wilayah asli.

1. Di browser Anda, temukan daftar acara untuk Contoso Concert Hall, gulir acara, dan perhatikan acara terakhirnya, Seriously Strauss.

2. Di PowerShell ISE, di dalam skrip ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, tetapkan nilai berikut:

   $DemoScenario = 4: Hapus acara dari penyewa di wilayah pemulihan.

3. Untuk menjalankan skrip, pilih F5.

4. Refresh halaman acara Contoso Concert Hall (http://events.wingtip-dpt.<user>.trafficmanager.net/contosoconcerthall), dan perhatikan bahwa acara Seriously Strauss tidak ada.

Pada titik ini dalam tutorial, Anda telah memulihkan aplikasi, yang sekarang berjalan di wilayah pemulihan. Anda telah menyediakan penyewa baru di wilayah pemulihan dan memodifikasi data salah satu penyewa yang dipulihkan.

Catatan

Tutorial lain dalam sampel tidak dirancang untuk berjalan dengan aplikasi dalam status pemulihan. Jika Anda ingin menjelajahi tutorial lain, pastikan untuk merepatriasi aplikasi terlebih dahulu.

Gambaran umum proses repatriasi

Proses repatriasi mengembalikan aplikasi dan databasenya ke wilayah asli setelah pemadaman terselesaikan.

Prosesnya:

1. Menghentikan aktivitas pemulihan yang sedang berlangsung dan membatalkan permintaan pemulihan database yang beredar atau dalam penerbangan.

2. Mengaktifkan kembali di database penyewa wilayah asli yang belum diubah sejak pemadaman. Database ini mencakup yang belum dipulihkan dan yang sudah dipulihkan tetapi tidak berubah sesudahnya. Database yang diaktifkan kembali persis seperti yang terakhir diakses oleh penyewa mereka.

3. Menyediakan gambar cermin kumpulan elastis dan server penyewa baru di wilayah aslinya. Setelah tindakan ini selesai, alias penyewa baru diperbarui untuk menunjuk ke server ini. Memperbarui alias menyebabkan onboarding penyewa baru terjadi di wilayah asli, bukan wilayah pemulihan.

4. Menggunakan replikasi geografis untuk memindahkan katalog ke wilayah asli dari wilayah pemulihan.

5. Memperbarui konfigurasi kumpulan di wilayah asli sehingga konsisten dengan perubahan yang dilakukan di wilayah pemulihan selama pemadaman.

6. Membuat server dan kumpulan yang diperlukan untuk meng-hosting database baru yang dibuat selama pemadaman.

7. Menggunakan replikasi geografis untuk merepatriasi database penyewa yang dipulihkan yang telah diperbarui pasca-pemulihan dan semua database penyewa baru yang tersedia selama pemadaman.

8. Membersihkan sumber daya yang dibuat di wilayah pemulihan selama proses pemulihan.

Untuk membatasi jumlah database penyewa yang perlu direpatriasi, langkah 1 sampai 3 dilakukan segera.

Langkah 4 hanya dilakukan jika katalog di wilayah pemulihan telah dimodifikasi selama pemadaman. Katalog diperbarui jika penyewa baru dibuat atau jika terdapat perubahan konfigurasi database atau kumpulan di wilayah pemulihan.

Penting bahwa langkah 7 menyebabkan gangguan yang minim pada penyewa dan tidak ada data yang hilang. Untuk mencapai tujuan ini, prosesnya menggunakan replikasi geografis.

Sebelum setiap database direplikasi secara geografis, database terkait di wilayah asli akan dihapus. Database di wilayah pemulihan kemudian direplikasi secara geografis, menghasilkan replika sekunder di wilayah aslinya. Setelah replikasi selesai, penyewa ditandai offline dalam katalog, yang memutus koneksi apa pun ke database di wilayah pemulihan. Database kemudian di-failover, menyebabkan transaksi yang tertunda diproses pada sekunder sehingga tidak ada data yang hilang.

Pada failover, peran database dibalik. Sekunder di wilayah asli menjadi database baca-tulis utama, dan database di wilayah pemulihan menjadi sekunder baca-saja. Entri penyewa dalam katalog diperbarui untuk mereferensikan database di wilayah asli, dan penyewa ditandai online. Pada titik ini, repatriasi database selesai.

Aplikasi harus ditulis dengan logika coba lagi untuk memastikan bahwa mereka tersambung kembali secara otomatis bila koneksi putus. Ketika mereka menggunakan katalog untuk broker koneksi ulang, mereka tersambung ke database yang direpatriasi di wilayah asli. Meskipun pemutusan singkat ini sering tidak diperhatikan, Anda dapat memilih untuk merepatriasi database keluar dari jam kerja.

Setelah database direpatriasi, database sekunder di wilayah pemulihan dapat dihapus. Database di wilayah asli kemudian bergantung lagi pada pemulihan geografis untuk perlindungan DR.

Pada langkah 8, sumber daya di wilayah pemulihan, termasuk kumpulan dan server pemulihan, akan dihapus.

Menjalankan skrip repatriasi

Mari kita bayangkan pemadaman telah terselesaikan dan jalankan skrip repatriasi.

Jika Anda telah mengikuti tutorial, skrip akan segera mengaktifkan kembali Fabrikam Jazz Club dan Dogwood Dojo di wilayah asli karena mereka tidak berubah. Kemudian merepatriasi penyewa baru, Hawthorn Hall, dan Contoso Concert Hall karena telah dimodifikasi. Skrip ini juga merepatriasi katalog, yang telah diperbarui ketika Hawthorn Hall tersedia.

1. Di PowerShell ISE, dalam skrip ...\Learning Modules\Business Continuity dan Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, verifikasikan bahwa proses Sinkronisasi Katalog masih berjalan di dalam instans PowerShell-nya. Jika perlu, mulai ulang dengan mengatur:

   $DemoScenario = 1: Mulai sinkronisasi info konfigurasi database, kumpulan, dan server penyewa ke dalam katalog.

   Untuk menjalankan skrip, pilih F5.

2. Kemudian untuk memulai proses repatriasi, setel:

   $DemoScenario = 5: Repatriasi aplikasi ke wilayah aslinya.

   Untuk menjalankan skrip pemulihan di jendela PowerShell yang baru, pilih F5. Repatriasi akan memakan waktu beberapa menit dan dapat dipantau di jendela PowerShell.

3. Saat skrip berjalan, refresh halaman hub acara (http://events.wingtip-dpt.<user>.trafficmanager.net).

   Perhatikan bahwa semua penyewa online dan dapat diakses selama proses ini.

4. Pilih Fabrikam Jazz Club untuk membukanya. Jika Anda tidak mengubah penyewa ini, perhatikan dari catatan kaki bahwa server sudah dikembalikan ke server asli.

5. Buka atau refresh halaman acara Contoso Concert Hall. Pemberitahuan dari catatan kaki bahwa, awalnya, database masih di -recovery server.

6. Refresh halaman acara Contoso Concert Hall ketika proses repatriasi selesai, dan perhatikan bahwa database sekarang berada di wilayah asli Anda.

7. Refresh hub acara lagi dan buka Hawthorn Hall. Perhatikan bahwa databasenya juga terletak di wilayah asli.

Membersihkan sumber daya wilayah pemulihan setelah repatriasi

Setelah repatriasi selesai, aman untuk menghapus sumber daya di wilayah pemulihan.

Penting

Segera hapus sumber daya ini untuk menghentikan semua tagihan atas sumber daya tersebut.

Proses pemulihan menghasilkan semua sumber daya pemulihan dalam grup sumber daya pemulihan. Proses pembersihan menghapus grup sumber daya ini dan menghapus semua referensi ke sumber daya dari katalog.

1. Di PowerShell ISE, dalam skrip ...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1, atur:

   $DemoScenario = 6: Hapus sumber daya usang dari wilayah pemulihan.

2. Untuk menjalankan skrip, pilih F5.

Setelah membersihkan skrip, aplikasi akan kembali ke tempat mulainya. Pada titik ini, Anda dapat menjalankan skrip lagi atau mencoba tutorial lain.

Merancang aplikasi untuk memastikan bahwa aplikasi dan database paralel

Aplikasi ini dirancang untuk selalu tersambung dari instans di wilayah yang sama dengan database penyewa. Desain ini mengurangi latensi antara aplikasi dan database. Pengoptimalan ini mengasumsikan interaksi aplikasi ke database lebih komunikatif daripada interaksi pengguna ke aplikasi.

Database penyewa dapat tersebar di seluruh wilayah pemulihan dan asli untuk beberapa waktu selama repatriasi. Untuk setiap database, aplikasi mencari wilayah di mana database berada dengan melakukan pencarian DNS pada nama server penyewa. Nama server adalah alias. Nama server alias berisi nama kawasan. Jika aplikasi tidak berada di wilayah yang sama dengan database, aplikasi akan dialihkan ke contoh di wilayah yang sama dengan server. Mengalihkan ke instans di wilayah yang sama dengan database akan meminimalkan latensi antara aplikasi dan database.

Langkah berikutnya

Dalam tutorial ini, Anda mempelajari cara:

• Menggunakan katalog penyewa untuk menyimpan informasi konfigurasi yang direfresh secara berkala, yang memungkinkan lingkungan pemulihan gambar cermin dibuat di wilayah lain.
• Memulihkan database ke wilayah pemulihan dengan menggunakan pemulihan geografis.
• Memperbarui katalog penyewa untuk mencerminkan lokasi database penyewa yang dipulihkan.
• Menggunakan alias DNS untuk memungkinkan aplikasi tersambung ke katalog penyewa tanpa konfigurasi ulang.
• Menggunakan replikasi geografis untuk merepatriasi database yang dipulihkan ke wilayah aslinya setelah pemadaman terselesaikan.

Cobalah Pemulihan bencana untuk aplikasi SaaS multi-penyewa menggunakan tutorial replikasi geografis database untuk mempelajari cara menggunakan replikasi geografis agar secara signifikan mengurangi waktu yang diperlukan untuk memulihkan aplikasi multi-penyewa skala besar.

Sumber Daya Tambahan:

Tutorial tambahan yang dibangun di aplikasi Wingtip SaaS