Grup ketersediaan Microsoft SQL Server Always On di Google Cloud

Last reviewed 2026-08-12 UTC

Dokumen ini menyediakan arsitektur referensi untuk men-deploy database Microsoft SQL Server dengan ketersediaan tinggi (HA) di Google Cloud menggunakan grup ketersediaan Always On. Dokumen ini juga mencakup pertimbangan desain untuk HA dan disaster recovery (DR), opsi deployment, rekomendasi otomatisasi, serta panduan untuk operasi Backup and DR. Dokumen ini ditujukan bagi praktisi teknis yang mengevaluasi Google Cloud sebagai platform untuk menjalankan database SQL Server. Tutorial 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 non-pengembangan SQL Server di Google Cloud, gunakan salah satu opsi pemberian lisensi berikut:

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

  • Gunakan 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 dengan ketersediaan tinggi (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 yang sangat penting. Grup ketersediaan Always On menyediakan HA lokal (failover dalam satu 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 mengalihkan workload 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 utama dan sekunder berada di zona terpisah dalam satu region. Node DR berada di region yang jauh 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 utama dan sekunder dalam suatu region, Anda dapat menggunakan salah satu pendekatan berikut:

Produk yang digunakan

Arsitektur ini menggunakan produk dan komponen Google Cloud serta 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 fungsionalitas jaringan global yang 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 pada node SQL Server:

  • Windows Server (versi 2019 atau yang lebih baru).
  • WSFC: Sekelompok 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.
  • Pemroses grup ketersediaan: Nama jaringan virtual (VNN) yang dapat digunakan klien untuk mengakses database di replika utama atau sekunder dari grup ketersediaan Always On. Klien tidak perlu mengetahui nama instance fisik replika. Karena pemroses 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 kebutuhan 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 kuat dengan kemampuan HA dan DR SQL Server. Kombinasi ini melindungi database Anda dari kegagalan, mulai dari pemadaman layanan zona hingga bencana regional.

Saat Anda 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 harus dapat beroperasi kembali?
    • Untuk mencapai RTO yang rendah, gunakan grup ketersediaan Always On.
    • Jika beberapa 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 redundan.
    • Biaya sedang: Terapkan replikasi disk asinkron ke region lain atau gunakan Backup and DR.
    • 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 zona, Anda dapat menggunakan grup ketersediaan.
    • Untuk memulihkan dari pemadaman layanan 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 yang sangat penting memerlukan strategi yang memberikan tingkat ketersediaan tertinggi, kehilangan data minimum, dan pemulihan cepat.
    • Untuk sistem yang kurang penting, pertimbangkan strategi yang mengasumsikan periode nonaktif 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 ini bervariasi, mulai dari grup ketersediaan Always On yang memberikan kehilangan data mendekati nol hingga pencadangan di luar lokasi yang hemat biaya.

  1. Apakah pencadangan di luar lokasi memenuhi RPO dan RTO Anda?
    • Ya: Gunakan pencadangan 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. Apa 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. Apa RPO Anda?
    • Kurang dari dua jam: Gunakan grup ketersediaan Always On SQL Server dengan Backup and DR.
    • Delapan jam atau lebih: Gunakan pencadangan di luar lokasi atau pengiriman log.

Memilih 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 hemat biaya untuk database dan log tanpa memerlukan penyimpanan lokal perantara.
  • Snapshot instan Compute Engine: Mengambil snapshot simultan di beberapa disk (misalnya, di seluruh disk Google Cloud Hyperdisk Balanced) dalam waktu kurang dari satu detik menggunakan operasi freeze-thaw Transact-SQL (T-SQL) yang digabungkan dengan grup konsistensi Compute Engine. Opsi ini memungkinkan pencadangan tingkat VM berperforma tinggi untuk database multi-disk, dan memiliki persyaratan pembekuan tulis yang hampir nol.
  • Backup and DR: Mengorkestrasi snapshot yang konsisten dengan 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 melakukan roll forward database.
  • 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 dan memerlukan mitigasi ransomware yang cepat serta 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.

  • Lacak metrik secara terus-menerus untuk resource inti seperti pemakaian CPU dan beban memori. Siapkan pemberitahuan dasar pengukuran untuk mendeteksi tekanan pada resource sebelum kueri mulai menurun.
  • Untuk mencegah penghentian penulisan database, amati penggunaan kapasitas disk secara terus-menerus. Pantau status layanan secara keseluruhan dan siapkan pemberitahuan untuk mendapatkan notifikasi saat database berhenti secara tidak terduga.
  • Untuk deployment 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 metrik khusus database yang ekstensif, seperti batas koneksi pengguna aktif, jeda replikasi, dan tarif transaksi. Lacak metrik ini untuk memantau ketersediaan dan performa database SQL Server Anda.
  • Untuk menangkap error tingkat aplikasi seperti deadlock, 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 merancang deployment SQL Server di Google Cloud yang memenuhi persyaratan keamanan workload Anda.

Keamanan jaringan dan isolasi

  • Untuk mencegah eksposur eksternal database, 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 yang ketat, yang hanya mengizinkan traffic dari subnet aplikasi yang diizinkan atau blok CIDR tertentu.
  • Untuk melindungi data dalam pengiriman dari penyadapan dan intersepsi, 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 otomatis mengenkripsi semua data dalam penyimpanan 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 kriptografis penuh. Anda mengelola siklus proses kunci, menetapkan jadwal rotasi otomatis, dan langsung mencabut akses ke database dan cadangannya jika diperlukan.

Autentikasi dan otorisasi

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

Pengoptimalan biaya

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

Pertimbangkan rekomendasi berikut:

  • Menonaktifkan simultaneous multi-threading (SMT): Dengan menonaktifkan SMT, Anda dapat mengurangi jumlah core yang dilaporkan untuk tujuan pemberian lisensi sebesar 50%. Dengan menyediakan CPU secara berlebihan sebesar 20% lalu menonaktifkan SMT, Anda dapat mencapai penghematan yang signifikan dalam biaya lisensi tanpa mengorbankan performa. Untuk informasi selengkapnya, lihat Menetapkan jumlah thread per core.
  • Gunakan SQL Server Standard Edition: Bergantung pada persyaratan HA dan DR, Anda dapat mengurangi biaya pemberian lisensi dengan menggunakan SQL Server Standard edition, bukan Enterprise edition. Untuk mengetahui informasi selengkapnya, lihat Edisi dan Fitur yang Didukung SQL Server.
  • Mengoptimalkan penyimpanan: Google Cloud 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 pengeluaran infrastruktur Anda sesuai dengan kebutuhan workload. 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 perlu membuat keputusan yang tepat tentang kelompok mesin VM dan jenis disk untuk node database.

Memilih 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 bottleneck 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 yang 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 terhadap 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, dan 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 banyak 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 meng-cache 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 analisis online (OLAP), kueri biasanya memindai tabel dan set data yang besar. Untuk kasus penggunaan tersebut, memori yang lebih tinggi membantu meningkatkan performa.

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

Memilih jenis persistent disk yang sesuai

Performa disk merupakan faktor penting untuk responsivitas database, yang sangat penting untuk performa aplikasi. Untuk jenis disk yang ditawarkan Google Cloud, kemampuan performa ditunjukkan 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 acak berukuran kecil, 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 jenis disk Google Cloud 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 Workload 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 independen dari ukuran disk dan berdasarkan kebutuhan workload.
Google Cloud Hyperdisk Extreme Performa sangat tinggi dengan IOPS yang dapat dikonfigurasi Workload OLTP kelas atas yang sangat penting dan memerlukan IOPS maksimum serta latensi terendah, seperti sistem keuangan atau e-commerce berskala besar.
SSD Lokal IOPS dan throughput tertinggi dibandingkan dengan jenis disk lainnya Data sementara yang tidak memerlukan ketahanan persistent disk. Untuk data seperti database sistem tempdb 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 Konfigurasi disk dan jenis mesin yang direkomendasikan
Database e-commerce transaksi tinggi untuk OLTP IOPS tinggi untuk menangani ribuan operasi baca dan tulis kecil yang serentak

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 Hyperdisk Balanced. Menyediakan IOPS tingkat tinggi untuk memenuhi permintaan transaksional. Gunakan disk terpisah untuk data dan log.

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

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

Disk data: Gunakan disk Hyperdisk Balanced. Menyediakan throughput tingkat tinggi untuk mempercepat pemindaian data besar.
Server pengembangan atau staging Efektivitas biaya, bukan performa puncak

Jenis mesin VM: Pilih jenis mesin untuk 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 lainnya: Kumar Dhanagopal | Developer Solusi Lintas Produk