Kelola peningkatan bergulir aplikasi cloud dengan menggunakan replikasi geo aktif SQL Database

Berlaku untuk: Azure SQL Database

Pelajari cara menggunakan replikasi geo aktif di Azure SQL Database untuk mengaktifkan peningkatan berkelanjutan aplikasi cloud Anda. Karena peningkatan adalah operasi yang mengganggu, mereka harus menjadi bagian dari perencanaan dan desain kelangsungan bisnis Anda. Dalam artikel ini, kita melihat dua metode berbeda untuk mengatur proses peningkatan dan mendiskusikan keuntungan dan penjualan dari setiap opsi. Untuk tujuan artikel ini, kami merujuk ke aplikasi yang terdiri dari situs web yang terhubung ke satu database sebagai tingkat datanya. Tujuan kami adalah untuk meningkatkan versi 1 (V1) aplikasi ke versi 2 (V2) tanpa dampak signifikan pada pengalaman pengguna.

Saat mengevaluasi opsi peningkatan, pertimbangkan faktor-faktor berikut:

• Dampak pada ketersediaan aplikasi selama peningkatan, seperti berapa lama fungsi aplikasi yang mungkin menjadi terbatas atau terdegradasi.
• Kemampuan untuk mengembalikan jika peningkatan gagal.
• Kerentanan aplikasi jika tidak terkait, kegagalan fatal terjadi selama peningkatan.
• Total biaya dolar. Faktor ini termasuk redundansi database tambahan dan tahapan biaya komponen sementara yang digunakan oleh proses peningkatan.

Meningkatkan aplikasi yang mengandalkan cadangan database untuk pemulihan bencana

Jika aplikasi Anda bergantung pada pencadangan database otomatis dan menggunakan pemulihan geo untuk pemulihan bencana, aplikasi tersebut disebarkan ke satu wilayah Azure. Untuk meminimalkan gangguan pengguna, buat lingkungan penyiapan di wilayah tersebut dengan semua komponen aplikasi yang terlibat dalam peningkatan. Diagram pertama menggambarkan lingkungan operasional sebelum proses peningkatan. Titik akhir contoso.azurewebsites.net mewakili lingkungan produksi aplikasi web. Agar dapat menggulung balik peningkatan, Anda harus membuat lingkungan penyiapan dengan salinan database yang sepenuhnya disinkronkan. Ikuti langkah-langkah berikut untuk membuat lingkungan penyiapan untuk peningkatan:

1. Buat database sekunder di wilayah Azure yang sama. Pantau sekundernya untuk melihat apakah proses penyemaian selesai (1).
2. Buat lingkungan baru untuk aplikasi web Anda dan sebut saja 'Penyiapan'. Ini akan terdaftar di Azure DNS dengan URL contoso-staging.azurewebsites.net (2).

Catatan

Langkah-langkah persiapan ini tidak akan berdampak pada lingkungan produksi, yang dapat berfungsi dalam mode akses penuh.

Ketika langkah-langkah persiapan selesai, aplikasi siap untuk peningkatan aktual. Diagram berikutnya mengilustrasikan langkah-langkah yang terlibat dalam proses peningkatan:

1. Atur database utama ke mode baca-saja (3). Mode ini menjamin bahwa lingkungan produksi aplikasi web (V1) tetap baca-saja selama peningkatan, sehingga mencegah perbedaan data antara instans database V1 dan V2.
2. Putuskan sambungan database sekunder dengan menggunakan mode penghentian yang direncanakan (4). Tindakan ini membuat salinan database utama yang sepenuhnya disinkronkan dan independen. Database ini akan ditingkatkan.
3. Ubah database sekunder ke mode baca-tulis dan jalankan skrip peningkatan (5).

Jika peningkatan berhasil diselesaikan, Anda sekarang siap untuk mengalihkan pengguna ke salinan aplikasi yang ditingkatkan, yang menjadi lingkungan produksi. Beralih meliputi beberapa langkah lagi, seperti yang digambarkan dalam diagram berikutnya:

1. Aktifkan operasi pertukaran antara lingkungan produksi dan penyiapan aplikasi web (6). Operasi ini mengalihkan URL dari dua lingkungan. Sekarang contoso.azurewebsites.net menunjuk ke versi V2 dari situs web dan database (lingkungan produksi).
2. Jika Anda tidak lagi memerlukan versi V1, yang menjadi salinan penyiapan setelah swap, Anda dapat menonaktifkan lingkungan penyiapan (7).

Jika proses peningkatan tidak berhasil (misalnya, karena kesalahan dalam skrip peningkatan), pertimbangkan untuk mengkompromikan lingkungan penyiapan. Untuk mengembalikan aplikasi ke status pra-peningkatan, kembalikan aplikasi di lingkungan produksi ke akses penuh. Diagram berikutnya memperlihatkan langkah-langkah pengalihan kembali:

1. Atur salinan database ke mode baca-tulis (8). Tindakan ini memulihkan fungsionalitas V1 penuh dari salinan produksi.
2. Lakukan analisis akar penyebab dan nonaktifkan lingkungan penyiapan (9).

Pada titik ini, aplikasi berfungsi penuh, dan Anda dapat mengulangi langkah-langkah peningkatan.

Catatan

Pemutaran kembali tidak memerlukan perubahan DNS karena Anda belum melakukan operasi swap.

Keuntungan utama dari opsi ini adalah Anda dapat meningkatkan aplikasi dalam satu wilayah dengan mengikuti serangkaian langkah sederhana. Biaya dolar dari peningkatan relatif rendah.

Penjualan utamanya adalah bahwa, jika kegagalan fatal terjadi selama peningkatan, pemulihan ke keadaan pra-peningkatan meliputi pemindahan aplikasi di wilayah yang berbeda dan memulihkan database dari cadangan dengan menggunakan pemulihan geo. Proses ini menghasilkan waktu henti yang signifikan.

Meningkatkan aplikasi yang mengandalkan replikasi geo database untuk pemulihan bencana

Jika aplikasi Anda menggunakan replikasi geografis aktif atau grup failover untuk kelangsungan bisnis, aplikasi tersebut disebarkan ke setidaknya dua wilayah yang berbeda. Ada database utama aktif di wilayah utama dan database sekunder baca-saja di wilayah cadangan. Seiring dengan faktor-faktor yang disebutkan di awal artikel ini, proses peningkatan juga harus menjamin bahwa:

• Aplikasi ini tetap terlindungi dari kegagalan fatal setiap saat selama proses peningkatan.
• Komponen geo-redundan dari aplikasi ditingkatkan secara paralel dengan komponen aktif.

Untuk mencapai tujuan ini, selain menggunakan lingkungan Web Apps, Anda akan memanfaatkan Azure Traffic Manager dengan menggunakan profil kegagalan dengan satu titik akhir aktif dan satu titik akhir cadangan. Diagram selanjutnya menggambarkan lingkungan operasional sebelum proses peningkatan. Situs web contoso-1.azurewebsites.net dan contoso-dr.azurewebsites.net mewakili lingkungan produksi aplikasi dengan redundansi geografis penuh. Lingkungan produksi mencakup komponen-komponen berikut:

• Lingkungan produksi aplikasi web di contoso-1.azurewebsites.net wilayah utama (1)
• Database utama di wilayah utama (2)
• Instans siaga aplikasi web di wilayah cadangan (3)
• Database sekunder yang direplikasi geo di wilayah cadangan (4)
• Profil kinerja Traffic Manager dengan titik akhir online disebut contoso-1.azurewebsites.net dan titik akhir offline yang disebut contoso-dr.azurewebsites.net

Untuk dapat membatalkan peningkatan, Anda harus membuat lingkungan penyiapan dengan salinan aplikasi yang disinkronkan sepenuhnya. Karena Anda perlu memastikan bahwa aplikasi dapat pulih dengan cepat jika kegagalan bencana terjadi selama proses peningkatan, lingkungan penyiapan juga harus geo-redundan. Langkah-langkah berikut diperlukan untuk membuat lingkungan penyiapan untuk peningkatan:

1. Sebar lingkungan penyiapan aplikasi web di wilayah utama (6).
2. Buat database sekunder di wilayah Azure yang sama (7). Konfigurasikan lingkungan penyiapan aplikasi web untuk terhubung ke aplikasi web tersebut.
3. Buat database sekunder geo-redundan lainnya di wilayah cadangan dengan mereplikasi database sekunder di wilayah utama. (Metode ini disebut replikasi geo berantai.) (8).
4. Sebarkan lingkungan penyiapan instans aplikasi web di wilayah cadangan (9) dan konfigurasikan untuk menghubungkan database sekunder geo-redundan yang dibuat pada (8).

Catatan

Langkah-langkah persiapan ini tidak akan berdampak pada aplikasi di lingkungan produksi. Ia akan tetap berfungsi penuh dalam mode baca-tulis.

Ketika langkah-langkah persiapan selesai, lingkungan penyiapan siap untuk ditingkatkan. Diagram berikutnya mengilustrasikan langkah-langkah peningkatan ini:

1. Atur database utama di lingkungan produksi ke mode baca-saja (10). Mode ini menjamin bahwa database produksi (V1) tidak akan berubah selama peningkatan, sehingga mencegah perbedaan data antara instans database V1 dan V2.

-- Set the production database to read-only mode
ALTER DATABASE [<Prod_DB>]
SET READ_ONLY

2. Hentikan replikasi geografis dengan memutus sambungan sekunder (11). Tindakan ini membuat salinan database produksi yang independen namun sepenuhnya disinkronkan. Database ini akan ditingkatkan. Contoh berikut menggunakan T-SQL tetapi PowerShell juga tersedia.

-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE [<Prod_DB>]
REMOVE SECONDARY ON SERVER [<Partner-Server>]

3. Jalankan skrip peningkatan terhadap contoso-1-staging.azurewebsites.net, contoso-dr-staging.azurewebsites.net, dan penyiapan database utama (12). Perubahan database akan direplikasi secara otomatis ke sekunder penyiapan.

Jika peningkatan berhasil diselesaikan, Anda sekarang siap untuk mengalihkan pengguna ke versi V2 aplikasi. Diagram berikutnya mengilustrasikan langkah-langkah yang terlibat:

1. Mengaktifkan operasi pertukaran antara lingkungan produksi dan penyiapan aplikasi web di wilayah utama (13) dan di wilayah cadangan (14). V2 dari aplikasi sekarang menjadi lingkungan produksi, dengan salinan redundan di wilayah cadangan.
2. Jika Anda tidak lagi memerlukan aplikasi V1 (15 dan 16), Anda dapat menonaktifkan lingkungan penyiapan.

Jika proses peningkatan tidak berhasil (misalnya, karena kesalahan dalam skrip peningkatan), anggap lingkungan penyiapan berada dalam keadaan tidak konsisten. Untuk mengembalikan aplikasi ke status pra-peningkatan, kembali menggunakan V1 aplikasi di lingkungan produksi. Langkah-langkah yang diperlukan diperlihatkan pada diagram berikutnya:

1. Set database utama di lingkungan produksi ke mode baca-saja (17). Tindakan ini memulihkan fungsionalitas penuh V1 di lingkungan produksi.
2. Lakukan analisis akar penyebab dan perbaiki atau hapus lingkungan penyiapan (18 dan 19).

Pada titik ini, aplikasi berfungsi penuh, dan Anda dapat mengulangi langkah-langkah peningkatan.

Catatan

Pemutaran kembali tidak memerlukan perubahan DNS karena Anda tidak melakukan operasi swap.

Keuntungan utama dari opsi ini adalah Anda dapat meningkatkan aplikasi dan salinan geo-redundan secara paralel tanpa mengorbankan kelangsungan bisnis Anda selama peningkatan.

Penjualan utama adalah bahwa ia membutuhkan redundansi ganda dari setiap komponen aplikasi dan oleh karena itu dikenakan biaya dolar yang lebih tinggi. Ini juga melibatkan alur kerja yang lebih rumit.

Ringkasan

Dua metode peningkatan yang dijelaskan dalam artikel berbeda dalam kompleksitas dan biaya dolar, tetapi mereka berdua fokus pada meminimalkan berapa lama pengguna terbatas pada operasi baca-saja. Waktunya secara langsung didefinisikan oleh durasi skrip peningkatan. Ini tidak tergantung pada ukuran database, tingkat layanan yang Anda pilih, konfigurasi situs web, atau faktor lain yang tidak dapat Anda kontrol dengan mudah. Semua langkah persiapan dipisahkan dari langkah-langkah peningkatan dan tidak berdampak pada aplikasi produksi. Efisiensi skrip peningkatan adalah faktor kunci yang menentukan pengalaman pengguna selama peningkatan. Jadi, cara terbaik untuk meningkatkan pengalaman itu adalah memfokuskan upaya Anda untuk membuat skrip peningkatan seefisien mungkin.

Konten terkait

• Gambaran umum kelangsungan bisnis.
• Buat database sekunder yang dapat dibaca menggunakan replikasi geografis aktif.
• Gunakan grup failover untuk mengaktifkan failover transparan dan terkoordinasi dari beberapa database.
• Menyiapkan staging environment di App Service Azure.
• Mengelola profil Azure Traffic Manager.