Grup ketersediaan Always On Microsoft SQL Server di Google Cloud

Last reviewed 2026-08-12 UTC

Dokumen ini memberikan arsitektur referensi untuk men-deploy database Microsoft SQL Server dengan ketersediaan tinggi (HA) di Google Cloud dengan menggunakan grup ketersediaan Always On. Dokumen ini juga mencakup pertimbangan desain untuk HA dan pemulihan dari bencana (DR), opsi deployment, rekomendasi otomatisasi, serta panduan untuk operasi pencadangan dan DR. Dokumen ini ditujukan bagi praktisi teknis yang mengevaluasi Google Cloud sebagai platform untuk menjalankan database SQL Server. Artikel ini mengasumsikan bahwa Anda memiliki pengetahuan dasar tentang Compute Engine dan SQL Server.

Google Cloud menyediakan solusi yang hemat biaya, andal, aman, dan berperforma tinggi untuk menjalankan database SQL Server. Untuk ringkasan solusi SQL Server yang didukung di Google Cloud, lihat SQL Server di Google Cloud.

Untuk mengoperasikan deployment SQL Server non-pengembangan di Google Cloud, gunakan salah satu opsi pemberian lisensi berikut:

  • Bring your own licenses (BYOL): Bawa lisensi Microsoft SQL Server yang ada ke Google Cloud. Anda harus menggunakan sole-tenant node atau Software Assurance dengan Mobilitas Lisensi.

  • Menggunakan lisensi on-demand: Gunakan image SQL Server bawaan di Google Cloud dan bayar biaya yang mencakup biaya komputasi dan biaya lisensi Microsoft. Google menangani perjanjian lisensi dan penagihan Microsoft.

Bagian Deployment dalam dokumen ini menyediakan resource untuk membantu Anda men-deploy arsitektur referensi ini.

Arsitektur

Diagram berikut menunjukkan arsitektur referensi untuk deployment SQL Server yang dikonfigurasi HA di Google Cloud:

Arsitektur yang menunjukkan deployment SQL Server dengan grup ketersediaan Always On yang mencakup VM Compute Engine di berbagai zona dan region.

Arsitektur sebelumnya menunjukkan grup ketersediaan Always On dengan tiga node dalam Windows Server Failover Cluster (WSFC). Setiap node adalah VM Compute Engine yang menjalankan SQL Server.

Grup ketersediaan Always On adalah pola deployment standar industri untuk mencapai tujuan keandalan database SQL Server penting. Grup ketersediaan Always On menyediakan HA lokal (failover dalam region) dan failover lintas region untuk DR. Pola deployment ini adalah alternatif tingkat perusahaan untuk pencerminan database. Grup ketersediaan Always On memberikan manfaat berikut:

  • Tidak memerlukan komponen infrastruktur khusus: SQL Server mengelola replikasi di semua replika database yang dikonfigurasi.
  • Konfigurasi SLA tertinggi untuk SQL Server: Batas waktu pemulihan (RTO) kurang dari satu menit dan toleransi jumlah data yang hilang (RPO) mendekati nol.
  • Kemampuan untuk mengurangi beban kerja hanya baca ke replika sekunder: Menskalakan deployment Anda secara efisien untuk analisis dan kasus penggunaan umum lainnya.
  • Node di region tambahan untuk DR: Deploy replika utama dan hingga delapan replika sekunder.
  • Dapat di-deploy di Windows dan Linux: Anda dapat menggunakan alat pihak ketiga seperti Pacemaker sebagai pengelola cluster untuk deployment Linux.

Dalam arsitektur sebelumnya, node SQL Server primer dan sekunder berada di zona terpisah dalam suatu region. Node DR berada di region yang terpencil secara geografis. Data dari node utama direplikasi secara sinkron ke node sekunder dan secara asinkron ke node DR.

Untuk mendistribusikan traffic dari lapisan aplikasi ke node database primer dan sekunder dalam suatu region, Anda dapat menggunakan salah satu pendekatan berikut:

Produk yang digunakan

Arsitektur ini menggunakan Google Cloud produk dan komponen Microsoft berikut.

Google Cloud produk

  • Compute Engine: Layanan komputasi yang aman dan dapat disesuaikan yang memungkinkan Anda membuat dan menjalankan VM di infrastruktur Google.
  • Google Cloud Hyperdisk: Layanan penyimpanan jaringan yang dapat Anda gunakan untuk menyediakan dan menskalakan volume block storage secara dinamis dengan performa yang dapat dikonfigurasi dan diprediksi.
  • Virtual Private Cloud (VPC): Sistem virtual yang menyediakan fungsi jaringan global dan skalabel untuk workload Google Cloud Anda. VPC mencakup Peering Jaringan VPC, Private Service Connect, akses layanan pribadi, dan VPC Bersama.
  • Cloud Load Balancing: Portofolio load balancer global dan regional yang berperforma tinggi dan skalabel.

Produk dan komponen Microsoft

Komponen berikut disertakan atau diaktifkan di node SQL Server:

  • Windows Server (versi 2019 atau yang lebih baru).
  • WSFC: Grup instance SQL Server yang diinstal di beberapa node cluster Windows Server atau di beberapa subnet.
  • Grup ketersediaan Always On: Alternatif HA dan DR tingkat perusahaan untuk pencerminan database.
  • Listener grup ketersediaan: Nama jaringan virtual (VNN) yang dapat digunakan klien untuk mengakses database di replika primer atau sekunder dari grup ketersediaan Always On. Klien tidak perlu mengetahui nama instance fisik replika. Karena listener merutekan traffic, string koneksi klien tidak perlu diubah setelah failover.

Komponen tambahan berikut diperlukan untuk men-deploy arsitektur ini:

Pertimbangan desain

Bagian ini menjelaskan faktor desain, praktik terbaik, dan rekomendasi desain yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mengembangkan topologi yang memenuhi persyaratan Anda akan keandalan, efisiensi operasional, keamanan, biaya, dan performa.

Keandalan

Bagian ini menjelaskan pertimbangan dan rekomendasi desain untuk membangun dan mengoperasikan infrastruktur yang andal untuk deployment SQL Server Anda di Google Cloud.

Memilih strategi HA dan DR

Untuk men-deploy database SQL Server yang andal di Google Cloud, Anda memerlukan strategi yang menggabungkan infrastruktur Google Cloud yang andal dengan kemampuan HA dan DR SQL Server. Kombinasi ini melindungi database Anda dari kegagalan mulai dari pemadaman layanan zona hingga bencana regional.

Saat mendesain strategi HA dan DR untuk deployment SQL Server, pertimbangkan faktor-faktor berikut:

  • RPO: Berapa banyak kehilangan data yang dapat diterima jika terjadi kegagalan?
  • RTO: Setelah terjadi kegagalan, seberapa cepat database perlu beroperasi kembali?
    • Untuk mencapai RTO rendah, gunakan grup ketersediaan Always On.
    • Jika periode nonaktif dapat diterima, pulihkan database dari cadangan atau gunakan pengiriman log dengan failover manual.
  • Anggaran: Pertimbangkan kompromi antara biaya dan keandalan.
    • Biaya tinggi, tetapi andal: Gunakan grup ketersediaan Always On dengan replikasi asinkron ke node tambahan di region DR. Rencanakan infrastruktur dan lisensi yang redundan.
    • Biaya sedang: Terapkan replikasi disk asinkron ke region lain atau gunakan Backup and DR Service.
    • Biaya rendah, tetapi waktu pemulihan tinggi: Cadangkan database ke bucket Cloud Storage multi-region.
  • Jenis kegagalan: Jenis kegagalan apa yang perlu Anda tangani?
    • Untuk menangani kegagalan tingkat hardware, tingkat instance, dan tingkat zona, Anda dapat menggunakan grup ketersediaan.
    • Untuk memulihkan dari gangguan atau bencana di seluruh situs, Anda memerlukan solusi DR yang tersebar secara geografis seperti pengiriman log atau grup ketersediaan Always On dengan replikasi database asinkron.
  • Kekritisan bisnis: Seberapa penting aplikasi bagi bisnis Anda?
    • Aplikasi penting memerlukan strategi yang memberikan tingkat ketersediaan tertinggi, kehilangan data minimum, dan pemulihan cepat.
    • Untuk sistem yang kurang penting, pertimbangkan strategi yang mengasumsikan waktu henti yang dapat diterima atau beberapa kehilangan data.

Gunakan kuesioner alur keputusan berikut untuk memilih strategi keandalan yang optimal untuk database SQL Server Anda. Opsi strategi berkisar dari grup ketersediaan Always On yang memberikan kehilangan data mendekati nol hingga pencadangan offsite yang hemat biaya.

  1. Apakah pencadangan di luar lokasi memenuhi RPO dan RTO Anda?
    • Ya: Gunakan cadangan di luar lokasi atau pengiriman log.
    • Tidak: Lanjutkan ke pertanyaan berikutnya.
  2. Apakah RTO atau RPO Anda kurang dari satu menit?
    • Ya (RPO mendekati nol): Gunakan grup ketersediaan Always On SQL Server dengan replika database DR.
    • Tidak: Lanjutkan ke pertanyaan berikutnya.
  3. Berapa RTO Anda?
    • Kurang dari lima menit: Gunakan grup ketersediaan AlwaysOn SQL Server dengan replika disk asinkron.
    • Satu jam atau lebih: Lanjutkan ke pertanyaan berikutnya.
  4. Berapa RPO Anda?
    • Kurang dari dua jam: Gunakan grup ketersediaan AlwaysOn SQL Server dengan Backup and DR Service.
    • Delapan jam atau lebih: Gunakan cadangan di luar lokasi atau pengiriman log.

Pilih opsi pencadangan yang sesuai

Jika strategi keandalan Anda mencakup pencadangan database, pilih metode pencadangan yang memenuhi persyaratan Anda. Google Cloud menawarkan opsi yang fleksibel dan siap digunakan perusahaan berikut untuk mencadangkan database SQL Server:

  • Pencadangan langsung ke bucket Cloud Storage: Tulis cadangan database langsung ke Cloud Storage menggunakan perintah BACKUP TO URL dan konektor S3 di SQL Server (versi 2022 atau yang lebih baru). Untuk lingkungan produksi, Anda dapat menggunakan kunci akses hash-based message authentication code (HMAC). Opsi pencadangan ini memberikan perlindungan yang hemat biaya untuk database dan log tanpa memerlukan penyimpanan lokal perantara.
  • Snapshot instan Compute Engine: Ambil snapshot secara bersamaan di beberapa disk (misalnya, di disk Hyperdisk Balanced) dalam waktu kurang dari satu detik menggunakan operasi freeze-thaw Transact-SQL (T-SQL) yang dikombinasikan dengan grup konsistensi Compute Engine. Opsi ini memungkinkan pencadangan tingkat VM berperforma tinggi untuk database multi-disk, dan memiliki persyaratan pembekuan penulisan yang mendekati nol.
  • Backup and DR: Mengatur snapshot yang konsisten pada aplikasi menggunakan penyedia Microsoft VSS dan grup konsistensi. Opsi pencadangan ini cocok jika Anda memerlukan pemulihan point-in-time (PITR) multi-database yang terperinci dan kemampuan untuk menggunakan log guna mengembalikan database ke versi sebelumnya.
  • Google Cloud NetApp Volumes: Buat snapshot instan dan cadangan asinkron ke vault jarak jauh menggunakan mesin penyimpanan ONTAP. Sebaiknya gunakan NetApp Volumes untuk aplikasi perusahaan yang sensitif terhadap latensi yang memerlukan mitigasi ransomware yang cepat dan clone yang hemat ruang.

Untuk deployment multi-cloud dan hybrid yang memerlukan kebijakan perlindungan data terpadu, Anda dapat memilih produk pencadangan pihak ketiga seperti Veeam, Veritas NetBackup, atau Cohesity.

Operasi

Untuk membantu memastikan ketersediaan tinggi dan performa optimal database SQL Server yang di-deploy di VM Compute Engine, siapkan sistem pemantauan dan pemberitahuan yang komprehensif menggunakan Cloud Monitoring dan Cloud Logging.

  • Terus lacak metrik untuk resource inti seperti pemakaian CPU dan pemuatan memori. Siapkan pemberitahuan dasar pengukuran untuk mendeteksi tekanan pada resource sebelum kueri mulai mengalami penurunan kualitas.
  • Untuk mencegah penghentian penulisan database, amati penggunaan ruang disk secara terus-menerus. Pantau status layanan secara keseluruhan dan siapkan pemberitahuan untuk mendapatkan notifikasi saat database berhenti secara tiba-tiba.
  • Untuk deployment dengan ketersediaan tinggi, lacak failover yang tidak direncanakan dan pastikan visibilitas lengkap selama peristiwa pemulihan dari bencana (disaster recovery) otomatis.
  • Selain telemetri tingkat sistem, Google Cloud menyediakan rangkaian lengkap metrik khusus database seperti batas koneksi pengguna aktif, jeda replikasi, dan rasio transaksi. Lacak metrik ini untuk memantau ketersediaan dan performa database SQL Server Anda.
  • Untuk merekam error tingkat aplikasi seperti kebuntuan, kerusakan database, dan kegagalan tugas agen langsung dari log error SQL Server, siapkan pemberitahuan berbasis log kustom di Logging.

Keamanan

Bagian ini menjelaskan pertimbangan dan rekomendasi desain untuk mendesain deployment SQL Server di Google Cloud yang memenuhi persyaratan keamanan workload Anda.

Keamanan dan isolasi jaringan

  • Untuk mencegah database terekspos secara eksternal, deploy instance SQL Server dengan alamat IP pribadi dalam VPC. Gunakan akses layanan pribadi untuk merutekan traffic secara internal. Pendekatan ini membantu memastikan bahwa traffic database Anda tidak pernah melintasi internet publik.
  • Batasi akses ke database lebih lanjut dengan mengonfigurasi aturan firewall VPC ketat yang mengizinkan traffic hanya dari subnet aplikasi yang sah atau blok CIDR tertentu.
  • Untuk melindungi data dalam pengiriman dari penyadapan dan pencegatan, terapkan konektivitas terenkripsi dengan menerapkan TLS/SSL untuk semua koneksi database.

Enkripsi dan kontrol kunci

  • Secara default, Google Cloud menggunakan kunci AES-256 yang dikelola Google untuk mengenkripsi semua data saat istirahat secara otomatis di disk database, file sementara, dan cadangan. Untuk membantu memenuhi lingkungan kepatuhan, Anda dapat menerapkan enkripsi tingkat database menggunakan kemampuan transparent data encryption (TDE) SQL Server.
  • Untuk membantu memastikan kedaulatan data, Anda dapat menggunakan kunci enkripsi yang dikelola pelanggan (CMEK) di Cloud Key Management Service. CMEK memberi Anda kontrol kriptografi penuh. Anda dapat mengelola siklus proses kunci, menetapkan jadwal rotasi otomatis, dan mencabut akses ke database dan cadangannya secara instan jika diperlukan.

Autentikasi dan otorisasi

  • Integrasikan database Anda dengan Microsoft Active Directory, atau pusatkan pengelolaan identitas di seluruh database SQL Server dan Google Cloud resource lainnya dengan menggunakan Identity and Access Management (IAM).
  • Setelah identitas ditetapkan, terapkan prinsip hak istimewa terendah agar akun layanan aplikasi dan pengguna hanya memiliki izin yang diperlukan untuk menjalankan fungsinya. Memetakan identitas ke peran database SQL Server yang terperinci.

Pengoptimalan biaya

Bagian ini memberikan panduan untuk mengoptimalkan biaya penyiapan dan pengoperasian deployment SQL Server yang Anda buat menggunakan arsitektur referensi ini. Pengoptimalan biaya membantu memastikan bahwa deployment memenuhi persyaratan keandalan dan performa workload Anda sesuai dengan batasan anggaran.

Pertimbangkan rekomendasi berikut:

  • Menonaktifkan multi-threading simultan (SMT): Dengan menonaktifkan SMT, Anda dapat mengurangi jumlah core yang dilaporkan untuk tujuan pemberian lisensi sebesar 50%. Dengan menyediakan CPU secara berlebih sebesar 20% lalu menonaktifkan SMT, Anda dapat menghemat biaya lisensi secara signifikan tanpa mengorbankan performa. Untuk informasi selengkapnya, lihat Menetapkan jumlah thread per core.
  • Gunakan SQL Server Standard Edition: Bergantung pada persyaratan HA dan DR Anda, Anda dapat mengurangi biaya lisensi dengan menggunakan SQL Server Standard Edition, bukan Enterprise Edition. Untuk mengetahui informasi selengkapnya, lihat Edisi dan Fitur yang Didukung SQL Server.
  • Mengoptimalkan penyimpanan: Hyperdisk menyediakan berbagai opsi disk yang dapat Anda pilih berdasarkan kebutuhan deployment SQL Server Anda. Hyperdisk Balanced memberikan keseimbangan antara biaya dan performa. Anda dapat menskalakan throughput dan operasi input/output per detik (IOPS) secara independen, sehingga pembelanjaan infrastruktur Anda cocok dengan kebutuhan beban kerja secara tepat. Untuk mengetahui informasi selengkapnya, lihat bagian Memilih jenis disk penyimpanan yang sesuai.

Pengoptimalan performa

Bagian ini menjelaskan pertimbangan dan rekomendasi desain untuk deployment SQL Server yang memenuhi persyaratan performa Anda.

Dengan men-deploy SQL Server di VM Compute Engine, Anda mendapatkan kontrol penuh atas database dan infrastruktur yang mendasarinya. Performa workload Anda bergantung pada infrastruktur yang Anda pilih. Untuk menyeimbangkan performa dengan biaya dan keandalan, Anda harus membuat keputusan yang tepat tentang kelompok mesin VM dan jenis disk untuk node database.

Pilih kelompok mesin VM yang sesuai

Kelompok mesin yang Anda pilih untuk VM Compute Engine menentukan daya pemrosesan (vCPU) dan memori (RAM) yang tersedia untuk node SQL Server Anda. Resource ini memengaruhi performa database Anda.

Pilih kelompok mesin VM yang mengatasi hambatan performa utama Anda. Misalnya, jika database SQL Server Anda terus-menerus menggunakan CPU yang tinggi, pilih jenis mesin dari kelompok mesin yang dioptimalkan untuk komputasi. Jika database SQL Server Anda menunjukkan pembacaan lambat dari disk, pilih jenis mesin yang dioptimalkan untuk memori.

Tabel berikut membandingkan kelompok mesin VM yang disediakan Compute Engine, kasus penggunaan utama untuk setiap kelompok mesin, dan dampak performa pada database SQL Server:

Kelompok dan seri mesin Kasus penggunaan utama Dampak pada performa SQL Server
Tujuan umum (seri mesin N4) Harga dan performa yang seimbang Gunakan kelompok mesin ini sebagai titik awal untuk sebagian besar workload. Seri mesin N4 memberikan keseimbangan CPU dan memori yang optimal untuk database penggunaan campuran, aplikasi web, serta lingkungan pengembangan atau pengujian.
Dioptimalkan untuk komputasi (seri mesin C3 atau C4) Performa tertinggi per core Gunakan kelompok mesin ini untuk workload yang terikat CPU. Untuk database yang menjalankan kueri kompleks, memproses data dalam volume besar, atau melayani sejumlah besar operasi pemrosesan transaksi online (OLTP), gunakan seri mesin C3 dan C4. Jenis mesin dari seri ini membantu mengurangi waktu eksekusi kueri secara signifikan.
Dioptimalkan untuk memori (seri mesin M3 atau M4) Rasio memori terhadap vCPU yang besar Kelompok mesin ini ideal untuk aplikasi yang memerlukan banyak memori. SQL Server menyimpan data dan rencana eksekusi dalam memori, yang memberikan performa lebih tinggi daripada membaca dari disk. Dengan database atau data warehouse yang sangat besar untuk pemrosesan analitis online (OLAP), kueri biasanya memindai tabel dan set data yang besar. Untuk kasus penggunaan tersebut, memori yang lebih tinggi akan membantu meningkatkan performa.

Untuk mengetahui informasi selengkapnya, lihat Panduan perbandingan dan resource kelompok mesin.

Pilih jenis disk penyimpanan yang sesuai

Performa disk adalah faktor penting untuk responsivitas database, yang sangat penting untuk performa aplikasi. Untuk jenis disk yang ditawarkan Google Cloud, kemampuan performa ditunjukkan dengan menggunakan metrik berikut:

  • IOPS: Jumlah permintaan baca dan tulis yang dapat ditangani disk per detik. IOPS sangat penting untuk workload OLTP yang melibatkan banyak operasi baca dan tulis kecil acak, seperti memperbarui data pelanggan atau memproses pesanan.
  • Throughput: Jumlah total data yang dapat dipindahkan ke atau dari disk per detik. Throughput sangat penting untuk workload OLAP yang melibatkan pemindaian data dalam jumlah besar, seperti menjalankan laporan, data warehousing, atau melakukan pencadangan.

Tabel berikut memberikan perbandingan Google Cloud jenis disk yang dapat Anda pilih:

Jenis disk Karakteristik performa Kesesuaian workload
Persistent Disk SSD (pd-ssd) Performa sedang hingga tinggi, bergantung pada jenis mesin VM dan ukuran disk Beban kerja yang memerlukan performa untuk diskalakan dengan ukuran disk dan vCPU VM. Untuk mengetahui informasi selengkapnya, lihat Ringkasan performa Persistent Disk.
Hyperdisk Balanced Performa tinggi dengan IOPS dan throughput yang dapat dikonfigurasi File log dan data SQL Server produksi. Hyperdisk Balanced memungkinkan Anda mengonfigurasi IOPS dan throughput secara terpisah dari ukuran disk dan berdasarkan kebutuhan workload.
Hyperdisk Extreme Performa sangat tinggi dengan IOPS yang dapat dikonfigurasi Beban kerja OLTP penting kelas atas yang memerlukan IOPS maksimum dan latensi terendah, seperti sistem keuangan atau e-commerce skala besar.
SSD Lokal IOPS dan throughput tertinggi dibandingkan dengan jenis disk lainnya Data sementara yang tidak memerlukan daya tahan persistent disk. Untuk data seperti tempdb database sistem dan file halaman Windows, SSD lokal memberikan latensi terendah karena terpasang secara fisik ke VM.

Menyesuaikan infrastruktur dengan persyaratan performa

Pilih jenis mesin VM dan jenis disk berdasarkan persyaratan performa workload Anda. Tabel berikut merekomendasikan konfigurasi infrastruktur untuk berbagai skenario workload:

Skenario Persyaratan performa Jenis mesin dan konfigurasi disk yang direkomendasikan
Database e-commerce dengan transaksi tinggi untuk OLTP IOPS tinggi untuk menangani ribuan operasi baca dan tulis serentak berukuran kecil

Jenis mesin VM: Pilih jenis mesin yang dioptimalkan untuk komputasi (misalnya, dari seri mesin C4) untuk pemrosesan transaksi yang efisien.

Disk data dan log: Gunakan disk Balanced Hyperdisk. Sediakan IOPS tingkat tinggi untuk memenuhi permintaan transaksional. Gunakan disk terpisah untuk data dan log.

tempdb: Gunakan disk SSD lokal untuk mengurangi beban operasi sementara dan memaksimalkan performa.
Data warehouse perusahaan untuk OLAP Throughput tinggi untuk memindai dan menggabungkan data terabyte untuk pelaporan

Jenis mesin VM: Pilih jenis mesin yang dioptimalkan untuk memori (misalnya, dari seri mesin M4), sehingga Anda dapat menyimpan dalam cache sebanyak mungkin set data besar.

Disk data: Gunakan disk Hyperdisk Balanced. Sediakan throughput tingkat tinggi untuk mempercepat pemindaian data besar.
Server pengembangan atau penyiapan Efisiensi biaya daripada performa puncak

Jenis mesin VM: Pilih jenis mesin tujuan umum dengan ukuran mesin kecil dari seri mesin E2 atau N4.

Disk: Gunakan Persistent Disk Seimbang (pd-balanced) untuk semua file database guna mencapai performa yang dapat diterima dengan biaya rendah.

Deployment

Untuk men-deploy arsitektur referensi ini, gunakan salah satu referensi berikut:

Langkah berikutnya

Kontributor

Penulis:

Kontributor lain: Kumar Dhanagopal | Cross-Product Solution Developer