Kelangsungan bisnis dan HADR untuk SQL Server di Microsoft Azure Virtual Machines

Berlaku untuk:SQL Server di Azure VM

Kelangsungan bisnis berarti melanjutkan bisnis Anda jika terjadi bencana, merencanakan pemulihan, dan memastikan bahwa data Anda sangat tersedia. SQL Server di Microsoft Azure Virtual Machines dapat membantu menurunkan biaya solusi database ketersediaan tinggi dan pemulihan bencana (HADR).

Sebagian besar solusi SQL Server HADR didukung pada mesin virtual (VM), sebagai solusi khusus Azure dan hibrid. Dalam solusi khusus Azure, seluruh sistem HADR berjalan di Azure. Dalam konfigurasi hibrid, bagian dari solusi berjalan di Azure dan bagian lain berjalan di organisasi Anda. Fleksibilitas lingkungan Azure memungkinkan Anda untuk memindah sebagian atau semuanya ke Azure untuk memenuhi anggaran dan persyaratan HADR dari sistem database SQL Server Anda.

Artikel ini membandingkan dan membedakan solusi kelangsungan bisnis yang tersedia untuk SQL Server di Azure VM.

Gambaran Umum

Terserah Anda untuk memastikan bahwa sistem database Anda memiliki kemampuan HADR yang disyaratkan perjanjian tingkat layanan (SLA). Fakta bahwa Azure menyediakan mekanisme ketersediaan tinggi, seperti penyembuhan layanan untuk layanan cloud dan deteksi kegagalan pemulihan untuk mesin virtual, tidak secara langsung menjamin bahwa Anda dapat memenuhi SLA. Meskipun mekanisme ini membantu melindungi ketersediaan komputer virtual yang tinggi, mereka tidak melindungi ketersediaan SQL Server yang berjalan di dalam komputer virtual.

Memungkinkan bagi instans SQL Server untuk gagal saat komputer virtual online dan sehat. Bahkan mekanisme ketersediaan tinggi yang disediakan oleh Azure memungkinkan waktu henti komputer virtual karena peristiwa seperti pemulihan dari kegagalan perangkat lunak atau perangkat keras dan pemutakhiran sistem operasi.

Penyimpanan geo-redundan (GRS) di Azure diimplementasikan dengan fitur yang disebut geo-replikasi. GRS mungkin bukan solusi pemulihan bencana yang memadai untuk database Anda. Karena geo-replikasi mengirim data secara tidak sinkron, pembaruan terbaru dapat hilang dalam bencana. Informasi lebih lanjut tentang batasan replikasi geografis tercakup dalam bagian dukungan replikasi geografis.

Catatan

Sekarang dimungkinkan untuk mengangkat dan mengalihkan solusi instans kluster failover dan grup ketersediaan Anda ke SQL Server di Azure VM menggunakan Azure Migrate.

Arsitektur penyebaran

Azure mendukung teknologi SQL Server ini untuk kelangsungan bisnis:

• Grup Ketersediaan Always On
• Instans kluster failover (FCI) Grup Ketersediaan AlwaysOn
• Log pengiriman
• Pencadangan dan pemulihan SQL Server dengan penyimpanan Azure Blob
• Pencerminan database - Tidak digunakan lagi di SQL Server 2016
• Azure Site Recovery

Anda dapat menggabungkan teknologi-teknologi untuk mengimplementasikan solusi SQL Server yang memiliki baik kemampuan ketersediaan tinggi maupun pemulihan bencana. Bergantung pada teknologi yang Anda gunakan, penyebaran hibrid mungkin memerlukan jalur VPN dengan jaringan virtual Azure. Bagian berikut ini memperlihatkan kepada Anda beberapa contoh arsitektur penyebaran.

Khusus Azure: Solusi ketersediaan tinggi

Anda dapat memiliki solusi ketersediaan tinggi untuk SQL Server pada tingkat database dengan Grup Ketersediaan Always On. Anda juga dapat membuat solusi ketersediaan tinggi pada tingkat instans dengan instans kluster failover Grup Ketersediaan AlwaysOn. Untuk perlindungan tambahan, Anda dapat membuat redundansi di kedua tingkat dengan membuat grup ketersediaan pada instans kluster failover.

Teknologi	Contoh arsitektur
Grup ketersediaan	Replika ketersediaan yang berjalan di komputer virtual Azure di wilayah yang sama menyediakan ketersediaan tinggi. Anda perlu mengonfigurasi komputer virtual pengendali domain, karena pengelompokan failover Windows memerlukan domain Direktori Aktif. Untuk redundansi dan ketersediaan yang lebih tinggi, komputer virtual Azure dapat digunakan di zona ketersediaan yang berbeda seperti yang didokumentasikan dalam gambaran umum grup ketersediaan. Untuk memulai, tinjau tutorial grup ketersediaan.
Instans kluster failover	Instans kluster failover didukung pada komputer virtual SQL Server. Karena fitur FCI memerlukan penyimpanan bersama, lima solusi akan berfungsi dengan SQL Server di komputer virtual Azure: - Menggunakan disk bersama Azure untuk Windows Server 2019. Disk terkelola bersama adalah produk Azure yang memungkinkan pemasangan disk terkelola ke beberapa mesin virtual secara bersamaan. Komputer virtual dalam kluster dapat membaca atau menulis ke disk terlampir Anda berdasarkan reservasi yang dipilih oleh aplikasi terkluster melalui SCSI Persistent Reservations (SCSI PR). SCSI PR adalah solusi penyimpanan standar industri yang digunakan oleh aplikasi yang berjalan di jaringan area penyimpanan (SAN) lokal. Mengaktifkan SCSI PR pada disk terkelola memungkinkan Anda untuk memigrasikan aplikasi ini ke Azure sama seperti aslinya. - Menggunakan Storage Spaces Direct (S2D) untuk menyediakan SAN virtual berbasis perangkat lunak untuk Windows Server 2016 dan yang lebih baru. - Menggunakan pembagian file premium untuk Windows Server 2012 dan yang lebih baru. Pembagian file premium memiliki dukungan SSD, memiliki latensi rendah yang konsisten, dan didukung penuh untuk digunakan dengan FCI. - Menggunakan penyimpanan yang didukung oleh solusi mitra untuk pengelompokan. Untuk contoh tertentu yang menggunakan SIOS DataKeeper, lihat entri blog Pengklusteran failover dan SIOS DataKeeper. - Menggunakan penyimpanan blok bersama untuk target iSCSI jarak jauh melalui Azure ExpressRoute. Misalnya, NetApp Private Storage (NPS) memaparkan target iSCSI melalui ExpressRoute dengan Equinix ke Azure VMs. Untuk solusi penyimpanan bersama dan replikasi data dari mitra Microsoft, hubungi vendor untuk masalah apa pun yang terkait dengan akses data pada kegagalan. Untuk memulai, siapkan Mesin Virtual Anda untuk FCI

Khusus Azure: Solusi pemulihan bencana

Anda dapat memiliki solusi pemulihan bencana untuk database SQL Server Anda di Azure dengan menggunakan grup ketersediaan, pencerminan database, atau pencadangan dan pemulihan dengan penyimpanan blob.

Teknologi	Contoh arsitektur
Grup ketersediaan	Replika ketersediaan berjalan di beberapa pusat data di komputer virtual Azure untuk pemulihan bencana. Solusi lintas wilayah ini membantu melindungi dari penonaktifan situs sepenuhnya. Dalam suatu wilayah, semua replika harus berada dalam layanan cloud yang sama dan jaringan virtual yang sama. Karena setiap wilayah akan memiliki jaringan virtual yang terpisah, solusi ini memerlukan konektivitas antar jaringan. Untuk informasi selengkapnya, lihat Mengonfigurasi koneksi antar jaringan menggunakan portal Microsoft Azure. Untuk instruksi mendetail, lihat Mengonfigurasi SQL Server grup ketersediaan AlwaysOn di berbagai wilayah Azure.
Pencerminan database	Database utama, database cermin, dan server berjalan di pusat data yang berbeda untuk pemulihan bencana. Anda harus menyebarkannya dengan menggunakan sertifikat server.
Pencadangan dan pemulihan dengan penyimpanan Azure Blob	Database produksi dicadangkan langsung ke penyimpanan Blob di pusat data yang berbeda untuk pemulihan bencana. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan untuk SQL Server di komputer virtual Azure.
Mereplikasi kegagalan SQL Server ke Azure dengan Azure Site Recovery	Instans SQL Server Produksi dalam satu pusat data Azure direplikasi langsung ke Azure Storage di pusat data Azure yang berbeda untuk pemulihan bencana. Untuk informasi selengkapnya, lihat Melindungi SQL Server menggunakan pemulihan bencana SQL Server dan Azure Site Recovery.

IT Hybrid: Solusi pemulihan bencana

Anda dapat memiliki solusi pemulihan bencana untuk database SQL Server Anda di lingkungan IT hibrid dengan menggunakan grup ketersediaan, pencerminan database, pengiriman log, dan pencadangan dan pemulihan dengan penyimpanan Azure Blob.

Teknologi	Contoh arsitektur
Grup ketersediaan	Beberapa replika ketersediaan yang berjalan di komputer virtual Azure dan replika lain yang berjalan di tempat untuk pemulihan bencana lintas lokasi. Situs produksi dapat saja lokal atau berada di pusat data Azure. Karena semua replika ketersediaan harus berada di kluster failover yang sama, kluster harus mencakup kedua jaringan (kluster failover multi-subnet). Konfigurasi ini memerlukan koneksi VPN antara Azure dan jaringan lokal. Untuk pemulihan bencana yang sukses dari database Anda, Anda juga harus memasang pengendali domain replika di lokasi pemulihan bencana. Untuk memulai, tinjau tutorial grup ketersediaan.
Pencerminan database	Satu mitra yang berjalan di komputer virtual Azure dan mitra lain yang berjalan lokal untuk pemulihan bencana lintas situs dengan menggunakan sertifikat server. Mitra tidak perlu berada di domain Direktori Aktif yang sama, dan tidak memerlukan koneksi VPN. Skenario pencerminan database lain melibatkan satu mitra yang berjalan di komputer virtual Azure dan yang lain berjalan lokal di domain Direktori Aktif yang sama untuk pemulihan bencana lintas situs. Diperlukan Koneksi VPN antara jaringan virtual Azure dan jaringan lokal. Untuk pemulihan bencana yang sukses dari database Anda, Anda juga harus memasang pengendali domain replika di lokasi pemulihan bencana.
Log pengiriman	Satu server yang berjalan di komputer virtual Azure dan server lain yang berjalan lokal untuk pemulihan bencana lintas situs. Pengiriman log tergantung pada file bersama Windows, sehingga diperlukan koneksi VPN antara jaringan virtual Azure dan jaringan lokal. Untuk pemulihan bencana yang sukses dari database Anda, Anda juga harus memasang pengendali domain replika di lokasi pemulihan bencana.
Pencadangan dan pemulihan dengan penyimpanan Azure Blob	Database produksi lokal dicadangkan langsung ke penyimpanan Azure Blob untuk pemulihan bencana. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan untuk SQL Server di komputer virtual Azure.
Mereplikasi kegagalan SQL Server ke Azure dengan Azure Site Recovery	Instans SQL Server produksi lokal direplikasi langsung ke Azure Storage untuk pemulihan bencana. Untuk informasi selengkapnya, lihat Melindungi SQL Server menggunakan pemulihan bencana SQL Server dan Azure Site Recovery.

Replika DR gratis di Azure

Jika Anda memiliki Jaminan Perangkat Lunak, Anda dapat menerapkan rencana pemulihan bencana (DR) hibrid dengan SQL Server tanpa dikenai biaya lisensi tambahan untuk instans pemulihan bencana pasif. Anda juga memenuhi syarat untuk replika DR bebas lisensi dengan lisensi prabayar jika semua replika dihosting di Azure.

Misalnya, Anda dapat memiliki dua cadangan pasif gratis saat ketiga replika di-hosting di Azure:

Atau Anda dapat mengonfigurasi lingkungan kegagalan hibrid, dengan lisensi utama lokal, satu pasif gratis untuk HA, satu pasif gratis untuk DR lokal, dan satu pasif gratis untuk DR di Azure:

Untuk informasi selengkapnya, lihat ketentuan lisensi produk.

Untuk mengaktifkan keuntungan ini, buka sumber daya komputer virtual SQL Server Anda. Pilih Konfigurasikan di bawah Pengaturan, lalu pilih opsi HA/DR di bawah Lisensi SQL Server. Pilih kotak centang untuk mengonfirmasi bahwa komputer virtual SQL Server ini akan digunakan sebagai replika pasif, lalu pilih Terapkan untuk menyimpan pengaturan Anda. Ketika ketiga replika dihosting di Azure, pelanggan prabayar juga berhak menggunakan jenis lisensi HA/DR .

Pertimbangan penting untuk HADR SQL Server di Azure

Komputer virtual, penyimpanan, dan jaringan Azure memiliki karakteristik operasional yang berbeda dari infrastruktur non-virtual IT lokal. Implementasi yang sukses dari solusi HADR SQL Server di Azure mengharuskan Anda untuk memahami perbedaan ini dan merancang solusi Anda untuk mengakomodasinya.

Node ketersediaan tinggi dalam set ketersediaan

Set ketersediaan di Azure memungkinkan Anda menempatkan node ketersediaan tinggi ke domain kesalahan dan domain pembaruan secara terpisah. Platform Azure menetapkan domain pembaruan dan domain kesalahan untuk setiap komputer virtual dalam set ketersediaan Anda. Konfigurasi dalam pusat data ini memastikan bahwa baik selama tindakan pemeliharaan yang direncanakan atau pun tidak direncanakan, setidaknya satu mesin virtual tersedia dan memenuhi Azure SLA sebesar 99,95 persen.

Untuk mengonfigurasi pengaturan ketersediaan tinggi, tempatkan semua komputer virtual SQL Server yang berpartisipasi dalam rangkaian ketersediaan yang sama untuk menghindari hilangnya aplikasi atau data selama tindakan pemeliharaan. Hanya node dalam layanan cloud yang sama yang dapat berpartisipasi dalam set ketersediaan yang sama. Untuk informasi selengkapnya, lihat Mengelola ketersediaan mesin virtual.

Node ketersediaan tinggi dalam zona ketersediaan

Zona Ketersediaan adalah lokasi fisik yang unik dalam wilayah Azure. Setiap Zona Ketersediaan terdiri dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan yang independen. Pemisahan fisik zona ketersediaan dalam suatu wilayah membantu melindungi aplikasi dan data dari kegagalan pusat data dengan memastikan bahwa setidaknya satu mesin virtual tersedia dan memenuhi Azure SLA sebesar 99,99 persen.

Untuk mengonfigurasi ketersediaan tinggi, tempatkan komputer virtual SQL Server yang berpartisipasi secara menyebar di zona ketersediaan di wilayah tersebut. Akan ada biaya tambahan untuk transfer jaringan ke jaringan antara zona ketersediaan. Untuk informasi selengkapnya, lihat Zona ketersediaan.

Latensi jaringan dalam IT hibrid

Terapkan solusi HADR Anda dengan asumsi bahwa mungkin ada periode latensi jaringan yang tinggi antara jaringan lokal dan jaringan Azure anda. Saat Anda menyebarkan replika ke Azure, gunakan penerapan asinkron sebagai ganti penerapan sinkron untuk mode sinkronisasi. Saat Anda menggunakan server pencerminan database baik di lokal maupun di Azure, gunakan mode berperforma tinggi alih-alih mode keamanan tinggi.

Lihat praktik terbaik konfigurasi HADR untuk kluster dan pengaturan HADR yang dapat membantu mengakomodasi lingkungan cloud.

Dukungan replikasi geografis

Replikasi geografis pada disk Azure tidak mendukung file data dan file log pada database yang sama untuk disimpan di disk terpisah. GRS mereplikasi perubahan pada setiap disk secara independen dan asinkron. Mekanisme ini menjamin urutan tulis dalam satu disk pada salinan replikasi geografis, tetapi tidak di seluruh salinan replikasi geografis dari beberapa disk. Jika Anda mengonfigurasi database untuk menyimpan file data dan file log pada disk terpisah, disk yang dipulihkan setelah bencana mungkin berisi salinan file data yang lebih terbaru daripada file log, yang menyalahi log tulis di SQL Server dan properti ACID (atomitas, konsistensi, isolasi, dan daya tahan) dari transaksi.

Jika Anda tidak memiliki opsi untuk menonaktifkan replikasi geografis pada akun penyimpanan, simpan semua file data dan log untuk database pada disk yang sama. Jika Anda perlu menggunakan lebih dari satu disk karena ukuran database, terapkan salah satu solusi pemulihan bencana yang tercantum sebelumnya untuk memastikan redundansi data.

Langkah berikutnya

Putuskan apakah grup ketersediaan atau instans kluster failover adalah solusi kelangsungan bisnis terbaik untuk bisnis Anda. Kemudian tinjau praktik terbaik untuk mengonfigurasi lingkungan Anda untuk ketersediaan tinggi dan pemulihan bencana.