Siapkan pemulihan bencana untuk SQL Server

Artikel ini menjelaskan cara melindungi aplikasi back-end dari SQL Server. Gunakan kombinasi teknologi keberlangsungan bisnis dan pemulihan bencana (BCDR) dari SQL Server, dan Azure Site Recovery.

Sebelum memulai, pastikan Anda paham kemampuan pemulihan bencana dari SQL Server. Kemampuannya meliputi:

  • Pengklusteran failover
  • Grup Ketersediaan AlwaysOn
  • Pencerminan database
  • Pengiriman log
  • Replikasi geografis 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 (Recovery Time Objective) dan Tujuan Titik Pemulihan (Recovery Point Ojective) Anda seperti yang dijelaskan dalam tabel berikut. Gabungkan Pemulihan Situs dengan operasi failover dari teknologi yang dipilih untuk mengatur pemulihan seluruh aplikasi Anda.

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 node. Karena Always On FCI menggunakan penyimpanan bersama, tampilan instans penyimpanan yang sama tersedia saat 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 geografis aktif 30 detik setelah failover dipicu.

Ketika failover diaktifkan ke salah satu database sekunder, semua database sekunder lainnya secara otomatis ditautkan ke primer baru.
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 failover otomatis menyediakan semantik grup di atas replikasi geografis yang aktif. Tetapi mekanisme replikasi asinkron yang sama bisa digunakan.
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 crash. Untuk mencari RPO yang lebih rendah, gunakan teknologi BCDR lainnya.

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 byte ditulis per detik. Untuk mesin yang menjalankan Windows, lihat laju perubahan ini dengan memilih tab 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 failover dan failover di seluruh aplikasi Anda dengan bantuan rencana pemulihan.

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: memiliki beberapa aplikasi dan pengontrol domain tunggal 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 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 failover otomatis

Always On dari Teknologi BCDR, replikasi geografis aktif, dan grup failover otomatis memiliki replika sekunder dari SQL Server yang berjalan di wilayah target Azure. Langkah pertama untuk failover aplikasi yaitu menentukan replika ini sebagai primer. Langkah ini mengasumsikan bahwa Anda sudah memiliki pengontrol domain di sekunder. Langkah ini mungkin tidak diperlukan jika Anda memilih untuk melakukan failover otomatis. Mengalihkan tingkatan web dan aplikasi Anda setelah failover database selesai.

Catatan

Jika SQL mesin telah dilindungi oleh Pemulihan Situs, Anda hanya perlu membuat grup pemulihan mesin-mesin ini dan menambahkan failover ke rencana pemulihan.

Buat rencana pemulihan dengan aplikasi dan mesin virtual tingkat web. Langkah-langkah berikut ini menjelaskan cara menambahkan failover dari tingkat database:

  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.

    Deploy to Azure logo

  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 failover

Beberapa teknologi BCDR seperti SQL Always On secara asli tidak mendukung pengujian failover. Kami merekomendasikan pendekatan berikut jika menggunakan teknologi tersebut.

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

  2. Sebelum memicu pengujian failover dari rencana pemulihan, pulihkan VM dari cadangan yang diambil pada langkah sebelumnya.

    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 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 failover memiliki satu alamat IP, dari kumpulan alamat IP front-end yang sesuai dengan setiap pendengar grup ketersediaan, dan dengan SQL Server VM di kumpulan Alamat IP.back-end.

    Screenshot of window titled

    Screenshot of window titled

  7. Di grup pemulihan nanti, tambahkan failover dari tingkat aplikasi Anda diikuti oleh tingkat web Anda untuk rencana pemulihan ini.

  8. Lakukan pengujian failover dari rencana pemulihan untuk menguji failover ujung ke ujung dari aplikasi Anda.

Langkah-langkah untuk melakukan failover

Setelah Anda menambahkan skrip di Langkah 3 dan memvalidasinya di Langkah 4, Anda dapat melakukan failover dari rencana pemulihan yang dibuat di Langkah 3.

Langkah-langkah failover untuk tingkat aplikasi dan web harus sama dalam rencana pemulihan failover dan pengujian failover.

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 tambahan di wilayah utama Azure 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 keamanan tinggi, akan disinkronkan dengan klaster utama tetapi direplikasi menggunakan replikasi Pemulihan Situs.

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

Pertimbangan failback

Untuk kluster SQL Server Standard, failback setelah failover yang tidak direncanakan memerlukan pencadangan dan pemulihan SQL Server. Operasi ini dilakukan dari instans cermin ke klaster asli dengan pembentukan kembali cermin.

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.

Langkah berikutnya