Siapkan pemulihan bencana untuk SQL Server
Artikel ini menjelaskan cara melindungi aplikasi {i>back-endAzure Site Recovery.
Sebelum memulai, pastikan Anda paham kemampuan pemulihan bencana dari SQL Server. Kemampuan ini mencakup:
- Pengklusteran failover
- Grup Ketersediaan AlwaysOn
- Pencerminan database
- Pengiriman log
- Replikasi Geo Aktif
- Grup Failover Otomatis
Menggabungkan teknologi BCDR dengan Pemulihan Situs
Dalam memilih teknologi BCDR untuk memulihkan instans SQL Server harus didasarkan pada kebutuhan Tujuan Waktu Pemulihan {i>(Recovery Time Objective)(Recovery Point Ojective)failover
Jenis penyebaran | Teknologi BCDR | RTO yang diharapkan untuk SQL Server | RPO yang diharapkan untuk SQL Server |
---|---|---|---|
SQL Server pada infrastruktur sebagai layanan (IaaS) dan mesin virtual (VM) dari Azure atau di tempat. | Grup ketersediaan AlwaysOn | Waktu yang dibutuhkan untuk membuat replika sekunder sebagai primer. | Karena replikasi ke replika sekunder tidak sinkron, ada beberapa data yang hilang. |
SQL Server pada Azure IaaS VM atau di tempat. | Pengklusteran failover (Always On FCI) | Waktu yang dibutuhkan untuk mengalihkan di antara {i>node | Karena Always On FCI menggunakan penyimpanan bersama, tampilan instans penyimpanan yang sama tersedia saat {i>failover. |
SQL Server pada Azure IaaS VM atau di tempat. | Pencerminan database (mode kinerja tinggi) | Waktu yang dibutuhkan untuk mempercepat layanan, yang menggunakan server cermin sebagai server siaga hangat. | Replikasi bersifat asinkron. Database cermin mungkin agak tertinggal di belakang database pokok. Ketertinggalannya cenderung ringan. Tetapi bisa menjadi besar jika sistem server utama atau cermin digunakan untuk beban berat. Pengiriman log dapat menjadi faktor tambahan untuk pencerminan database. Cara alternatif yang menguntungkan untuk pencerminan database asinkron. |
SQL merupakan platform sebagai layanan (PaaS) di Azure. Jenis penyebaran ini mencakup kumpulan database tunggal dan elastis. |
Replikasi Geo Aktif | 30 detik setelah {i>failover Ketika {i>failover | RPO lima detik. Replikasi geografis aktif menggunakan teknologi Always On dari SQL Server. Secara asinkron mereplikasi transaksi yang dilakukan pada database utama ke database sekunder dengan menggunakan isolasi snapshot. Data sekunder dijamin memiliki transaksi parsial. |
SQL sebagai PaaS dikonfigurasi dengan replikasi geografis yang aktif di Azure. Jenis penyebaran ini mencakup instans terkelola, kumpulan elastis, dan database tunggal. |
Grup Failover Otomatis | RTO satu jam. | RPO lima detik. Grup {i>failover |
SQL Server pada Azure IaaS VM atau di tempat. | Replikasi dengan Azure Site Recovery | RTO biasanya, kurang dari 15 menit. Untuk mempelajari lebih lanjut, baca RTO SLA yang disediakan oleh Pemulihan Situs. | Satu jam untuk konsistensi aplikasi dan lima menit untuk konsistensi {i>crash |
Catatan
Ada beberapa pertimbangan penting untuk melindungi beban kerja SQL dengan Pemulihan Situs:
- Pemulihan Situs merupakan aplikasi yang bersifat agnostik. Pemulihan Situs dapat melindungi SQL Server versi apa pun yang disebarkan pada sistem operasi yang didukung. Untuk mempelajari lebih lanjut, lihat matriks dukungan untuk pemulihan mesin yang direplikasi.
- Gunakan Pemulihan Situs untuk penyebaran apa pun di Azure, Hyper-V, VMware, atau infrastruktur fisik. Ikuti panduan di akhir artikel ini tentang perlindungan klaster SQL Server dengan Pemulihan Situs.
- Pastikan bahwa tingkat perubahan data yang diamati pada mesin berada dalam batas Pemulihan Situs. Tingkat perubahan diukur dalam {i>bytetab Kinerja di Manager Tugas. Amati kecepatan menulis untuk setiap disk.
- Pemulihan Situs mendukung replikasi dari Instans Kluster Failover di Ruang Penyimpanan Langsung. Untuk mempelajari lebih lanjut, lihat cara mengaktifkan replikasi Ruang Penyimpanan Langsung.
Saat melakukan imigrasi Beban Kerja SQL Anda ke Azure, disarankan untuk menerapkan Panduan kinerja untuk SQL Server di Azure Virtual Machines.
Pemulihan bencana aplikasi
Pemulihan Situs mengatur pengujian {i>failoverfailover
Ada beberapa prasyarat untuk memastikan rencana pemulihan sepenuhnya yang disesuaikan dengan kebutuhan Anda. Setiap penyebaran SQL Server biasanya memerlukan penyebaran Direktori Aktif. Membutuhkan konektivitas untuk tingkat aplikasi Anda.
Langkah 1: Siapkan Direktori Aktif
Siapkan Direktori Aktif di situs pemulihan sekunder agar SQL Server bisa berjalan dengan benar.
- Perusahaan kecil: Anda memiliki beberapa aplikasi dan satu pengendali domain untuk situs lokal. Jika ingin mengalihkan seluruh situs, gunakan replikasi Pemulihan Situs. Layanan ini mereplikasi pengontrol domain ke pusat data sekunder atau ke Azure.
- Perusahaan menengah hinggabesar: siapkan pengontrol domain tambahan.
- Jika memiliki aplikasi dengan jumlah besar, memiliki siratan Direktori Aktif, dan untuk mengalihkan aplikasi atau beban kerja, siapkan pengontrol domain lain di pusat data sekunder atau di Azure.
- Jika menggunakan grup ketersediaan Always On untuk memulihkan situs jarak jauh, siapkan pengontrol domain lain di situs sekunder atau di Azure. Pengontrol domain ini digunakan untuk instans SQL Server yang dipulihkan.
Instruksi dalam artikel ini mengasumsikan bahwa pengontrol domain tersedia di lokasi sekunder. Untuk mempelajari lebih lanjut, lihat prosedur untuk melindungi Direktori Aktif dengan Pemulihan Situs.
Langkah 2: Memastikan konektivitas dengan tingkatan lain
Setelah tingkat database yang berjalan di wilayah target Azure, pastikan untuk memiliki konektivitas dengan aplikasi dan tingkatan web. Ambil langkah-langkah yang diperlukan terlebih dahulu untuk memvalidasi konektivitas dengan pengujian {i>failover
Untuk memahami cara mendesain aplikasi sebagai pertimbangan konektivitas, lihat contoh-contoh berikut:
Langkah 3: Saling beroperasi dengan Always On, replikasi geografis aktif, dan grup {i>failover
Always On dari Teknologi BCDR, replikasi geografis aktif, dan grup {i>failoverfailoverfailoverfailover
Catatan
Jika SQL mesin telah dilindungi oleh Pemulihan Situs, Anda hanya perlu membuat grup pemulihan mesin-mesin ini dan menambahkan {i>failover
Buat rencana pemulihan dengan aplikasi dan mesin virtual tingkat web. Langkah-langkah berikut ini menjelaskan cara menambahkan {i>failover
Impor skrip untuk mengalihkan melalui Grup Ketersediaan SQL di mesin virtual Manager Sumber Daya dan mesin virtual klasik. Impor skrip ke akun Otomatisasi Azure Anda.
Tambahkan skrip ASR-SQL-FailoverAG sebagai pra tindakan dari grup pertama rencana pemulihan.
Ikuti instruksi yang tersedia dalam skrip untuk membuat variabel otomatisasi. Variabel ini menyediakan nama grup ketersediaan.
Langkah 4: Lakukan pengujian {i>failover
Beberapa teknologi BCDR seperti SQL Always On secara asli tidak mendukung pengujian {i>failover.berikut jika menggunakan teknologi tersebut.
Siapkan Azure Backup di VM yang menjadi penyelenggara replika grup ketersediaan di Azure.
Sebelum memicu pengujian {i>failover
Percepat kinerja kuorum di VM yang dipulihkan dari cadangan.
Perbarui alamat IP pendengar untuk menjadi alamat yang tersedia dalam jaringan pengujian {i>failover
Jadikan listener online.
Pastikan bahwa penyeimbang muatan di jaringan {i>failoverfront-endback-end
Di grup pemulihan nanti, tambahkan {i>failover
Lakukan pengujian {i>failoverfailover
Langkah-langkah untuk melakukan {i>failover
Setelah Anda menambahkan skrip di Langkah 3 dan memvalidasinya di Langkah 4, Anda dapat melakukan {i>failover
Langkah-langkah {i>failover failoverfailover
Cara melindungi klaster SQL Server
Untuk kluster yang menjalankan SQL Server Edisi Standar atau SQL Server 2008 R2, kami sarankan Anda menggunakan replikasi Pemulihan Situs untuk melindungi SQL Server.
Azure ke Azure dan Lokal ke Azure
Pemulihan Situs tidak menyediakan dukungan klaster tamu saat mereplikasi ke wilayah Azure. SQL Server Edisi Standard juga tidak menyediakan solusi pemulihan bencana berbiaya rendah. Pada umumnya,disarankan untuk melindungi klaster SQL Server ke instans SQL Server mandiri di lokasi utama dan memulihkannya di wilayah sekunder.
Konfigurasikan instans SQL Server mandiri lainnya di wilayah Azure utama atau di situs lokal.
Konfigurasikan instans yang berfungsi sebagai cermin untuk database yang ingin Anda lindungi. Konfigurasikan pencerminan dalam mode keamanan tinggi.
Konfigurasikan Pemulihan Situs di situs utama untuk Azure, Hyper-V, atau VMware VMs dan server fisik.
Gunakan replikasi Pemulihan Situs untuk mereplikasi instans SQL Server baru ke situs sekunder. Karena ini adalah salinan cermin dengan keamanan tinggi, itu disinkronkan dengan kluster utama tetapi direplikasi menggunakan replikasi Site Recovery.
Pertimbangan {i>failback
Untuk kluster SQL Server Standard, {i>failbackfailover
Tanya jawab umum
Bagaimana SQL Server mendapatkan lisensi saat digunakan dengan Pemulihan Situs?
Replikasi Pemulihan Situs untuk SQL Server tercakup dalam manfaat pemulihan bencana dari Jaminan Perangkat Lunak. Cakupan ini berlaku untuk semua skenario Pemulihan Situs: di tempat untuk pemulihan bencana Azure dan pemulihan bencana Azure IaaS lintas wilayah. Lihat Harga Azure Site Recovery untuk informasi selengkapnya.
Apakah Pemulihan Situs mendukung versi SQL Server saya?
Pemulihan Situs merupakan aplikasi yang bersifat agnostik. Pemulihan Situs dapat melindungi SQL Server versi apa pun yang disebarkan pada sistem operasi yang didukung. Untuk mempelajari lebih lanjut, lihat matriks dukungan untuk pemulihan mesin yang direplikasi.
Apakah Azure Site Recovery Berfungsi dengan Replikasi Transaksional SQL?
Karena Azure Site Recovery menggunakan salinan tingkat file, SQL tidak dapat menjamin bahwa server dalam topologi replikasi SQL terkait sinkron pada saat failover Azure Site Recovery. Hal ini dapat menyebabkan pembaca log dan/atau agen distribusi gagal karena ketidakcocokan LSN, yang dapat memutus replikasi. Jika Anda melakukan failover penerbit, distributor, atau pelanggan dalam topologi replikasi, Anda perlu membangun kembali replikasi. Disarankan untuk menginisialisasi ulang langganan ke SQL Server.
Langkah berikutnya
- Pelajari selengkapnya tentang arsitektur Pemulihan Situs.
- Untuk SQL Server di Azure, pelajari selengkapnya tentang solusi ketersediaan tinggi untuk pemulihan di wilayah sekunder Azure.
- Untuk Database SQL, pelajari selengkapnya tentang kelangsungan bisnis dan opsi ketersediaan tinggi untuk pemulihan di wilayah sekunder Azure.
- Untuk mesin SQL Server lokal, pelajari selengkapnya tentang opsi ketersediaan tinggi untuk pemulihan di Azure Virtual Machines.