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 database elastis, dan 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

  1. 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.

    Button to deploy the Resource Manager template to Azure.

  2. Tambahkan skrip ASR-SQL-FailoverAG sebagai pra tindakan dari grup pertama rencana pemulihan.

  3. 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.

  1. Siapkan Azure Backup di VM yang menjadi penyelenggara replika grup ketersediaan di Azure.

  2. Sebelum memicu pengujian {i>failover

    Screenshot showing window for restoring a configuration from Azure Backup

  3. Percepat kinerja kuorum di VM yang dipulihkan dari cadangan.

  4. Perbarui alamat IP pendengar untuk menjadi alamat yang tersedia dalam jaringan pengujian {i>failover

    Screenshot of rules window and IP address properties dialog

  5. Jadikan listener online.

    Screenshot of window labeled Content_AG showing server names and statuses

  6. Pastikan bahwa penyeimbang muatan di jaringan {i>failoverfront-endback-end

    Screenshot of window titled

    Screenshot of window titled

  7. Di grup pemulihan nanti, tambahkan {i>failover

  8. 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.

  1. Konfigurasikan instans SQL Server mandiri lainnya di wilayah Azure utama atau di situs lokal.

  2. Konfigurasikan instans yang berfungsi sebagai cermin untuk database yang ingin Anda lindungi. Konfigurasikan pencerminan dalam mode keamanan tinggi.

  3. Konfigurasikan Pemulihan Situs di situs utama untuk Azure,Hyper-V,atau VMware VMs dan server fisik.

  4. 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.

    Image of a standard cluster that shows the relationship and flow among a primary site, Site Recovery, and Azure

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 ASR Bekerja dengan Replikasi Transaksional SQL?

Karena ASR menggunakan salinan tingkat file, SQL tidak dapat menjamin bahwa server dalam topologi replikasi SQL terkait sinkron pada saat failover ASR. Hal ini dapat menyebabkan agen logreader dan/atau 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