Tutorial ini menjelaskan cara mengaktifkan Replikasi Asinkron Persistent Disk (Replikasi Asinkron PD) di dua region Google Cloud sebagai pemulihan dari bencana (DR) dan cara memunculkan instance DR jika terjadi bencana. Untuk tujuan dokumen ini, bencana adalah peristiwa saat cluster ketersediaan tinggi (HA) database utama gagal atau menjadi tidak tersedia. Database utama dapat mengalami kegagalan jika regionnya berada gagal atau menjadi tidak dapat diakses.
Tutorial ini ditujukan untuk arsitek, administrator, dan engineer database.
Tujuan
- Aktifkan replikasi Persistent Disk asinkron untuk semua Node cluster grup ketersediaan Selalu Aktif SQL Server yang berjalan dan aplikasi yang dihosting di Google Cloud.
- Menyimulasikan peristiwa bencana dan melakukan pemulihan dari bencana sepenuhnya untuk memvalidasi konfigurasi pemulihan dari bencana.
Biaya
Dalam dokumen ini, Anda menggunakan komponen Google Cloud yang dapat ditagih berikut:
Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda,
gunakan kalkulator harga.
Setelah menyelesaikan tugas yang dijelaskan dalam dokumen ini, Anda dapat menghindari penagihan berkelanjutan dengan menghapus resource yang Anda buat. Untuk mengetahui informasi selengkapnya, lihat Pembersihan.
Sebelum memulai
Untuk tutorial ini, Anda memerlukan proyek Google Cloud. Anda dapat membuat yang baru, atau pilih project yang sudah Anda buat:
-
Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.
-
Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.
-
Di konsol Google Cloud, aktifkan Cloud Shell.
Pemulihan dari bencana di Google Cloud
Di Google Cloud, DR berkaitan dengan menyediakan kontinuitas pemrosesan data, terutama saat region gagal atau tidak dapat diakses. Ada beberapa opsi deployment untuk situs DR dan akan ditentukan oleh toleransi jumlah data yang hilang (RPO) dan batas waktu pemulihan (RTO). Tutorial ini membahas salah satu opsi di mana disk virtual machine (VM) direplikasi dari model utama ke DR teritorial Anda.
Pemulihan dari bencana untuk replikasi Persistent Disk asinkron
Replikasi Asinkron Persistent Disk (Replikasi Asinkron PD) menyediakan replikasi block storage RPO dan RTO yang rendah untuk lintas region DR pasif aktif.
Replikasi Asinkron PD adalah opsi penyimpanan yang menyediakan replikasi data antara dua region. Jika terjadi peristiwa yang tidak mungkin layanan terkelola, Replikasi Asinkron PD memungkinkan Anda melakukan failover data ke dan memulai ulang workload di region tersebut.
Replikasi Asinkron PD mereplikasi data dari {i>disk<i} yang dipasang ke beban kerja yang berjalan yang disebut {i>disk<i} utama, ke disk terpisah yang berada di wilayah lain. {i>Disk<i} yang menerima data replika disebut sebagai disk sekunder.
Untuk memastikan bahwa replika dari semua disk yang terpasang pada setiap SQL Server berisi data dari waktu yang sama, disk ditambahkan ke grup konsistensi. Dengan grup konsistensi, Anda dapat melakukan pengujian DR dan DR di berbagai {i>disk<i}.
Arsitektur pemulihan dari bencana (disaster recovery)
Untuk Replikasi Asinkron PD, diagram berikut menunjukkan arsitektur minimal yang mendukung HA database di region utama, dan replikasi disk dari region utama ke region DR.
Gambar 1. Arsitektur pemulihan dari bencana dengan Microsoft SQL Server dan Replikasi Asinkron PD
Arsitektur ini berfungsi sebagai berikut:
- Dua instance Microsoft SQL Server, instance utama dan standby adalah bagian dari grup ketersediaan, dan berada di grup ketersediaan region (R1), tetapi zona berbeda (zona A dan B). Dua {i>instance<i} di R1 mengoordinasikan statusnya menggunakan mode commit sinkron. Fungsi sinkron mode yang digunakan karena mendukung ketersediaan tinggi dan mempertahankan keadaan data yang konsisten.
- {i>Disk<i} dari kedua {i>node<i} SQL ditambahkan ke grup konsistensi dan direplikasi ke region DR R2. Data direplikasi secara asinkron berdasarkan struktur infrastruktur IT.
- Hanya disk yang direplikasi ke region R2. Selama DR, VM baru dibuat dan {i>disk<i} replika yang ada dipasang ke VM untuk membawa {i>node <i}secara {i>online<i}.
Proses pemulihan dari bencana
Proses DR dimulai saat region menjadi tidak tersedia. DR menentukan langkah-langkah operasional yang harus diambil, baik secara manual secara otomatis, untuk memitigasi kegagalan region dan membangun jaringan di region yang tersedia.
Proses DR database dasar terdiri dari langkah-langkah berikut:
- Region pertama (R1), yang menjalankan instance database utama, menjadi tidak tersedia.
- Tim operasi mengenali dan secara resmi mengonfirmasi bencana, dan memutuskan apakah failover diperlukan.
- Jika failover diperlukan, replikasi disk dari utama ke DR region dihentikan. VM baru dibuat dari replika {i> disk<i} dan dibawa secara online.
- Database primer baru di region DR (R2) divalidasi dan dibawa yang memungkinkan konektivitas secara online.
- Pengguna melanjutkan pemrosesan di {i>database<i} utama yang baru dan mengakses instance utama di R2.
Meskipun proses dasar ini menetapkan kembali sebuah {i>database<i} utama yang berfungsi, tidak membangun arsitektur HA yang lengkap, di mana primer baru memiliki standby.
Gambar 2. Deployment SQL Server setelah Pemulihan dari bencana dengan Replikasi Asinkron Persistent Disk
Penggantian ke region yang dipulihkan
Ketika region utama (R1) kembali online, Anda dapat merencanakan dan melaksanakan proses {i>fail-back<i}. Proses {i>failback<i} terdiri dari semua langkah yang diuraikan dalam tutorial ini tetapi, dalam hal ini, R2 adalah sumbernya dan R1 adalah hasil pemulihan teritorial Anda.
Memilih edisi SQL Server
Tutorial ini mendukung versi Microsoft SQL Server berikut:
- SQL Server 2016 Enterprise Edition
- SQL Server 2017 Enterprise Edition
- SQL Server 2019 Enterprise Edition
- SQL Server 2022 Enterprise Edition
Tutorial ini menggunakan fitur grup ketersediaan AlwaysOn di SQL Server.
Jika Anda tidak memerlukan Microsoft SQL Server HA dan satu instance database sudah cukup sebagai instance utama, Anda dapat menggunakan versi SQL Server berikut ini:
- SQL Server 2016 Standard Edition
- SQL Server 2017 Standard Edition
- SQL Server 2019 Standard Edition
- SQL Server 2022 Edisi Standar
Versi SQL Server 2016, 2017, 2019, dan 2022 memiliki Microsoft SQL Server Studio Pengelolaan yang diinstal di gambar; Anda tidak perlu menginstalnya secara terpisah. Namun, dalam lingkungan produksi, sebaiknya Anda menginstal satu instance Microsoft SQL Server Management Studio di VM terpisah di masing-masing teritorial Anda. Jika Anda menyiapkan lingkungan HA, Anda harus menginstal Microsoft SQL Server Management Studio sekali untuk setiap zona guna memastikan bahwa zona tersebut tetap tersedia jika zona lain menjadi tidak tersedia.
Menyiapkan pemulihan dari bencana untuk Microsoft SQL Server
Tutorial ini menggunakan gambar sql-ent-2022-win-2022 untuk Microsoft SQL Server
Perusahaan.
Untuk mengetahui daftar lengkap gambar, lihat OS Image.
Menyiapkan cluster ketersediaan tinggi dua instance
Untuk menyiapkan replikasi disk ke region DR untuk SQL Server, pertama-tama
membuat cluster HA dua instance di sebuah region.
Satu instance berfungsi sebagai instance utama, dan instance lainnya berfungsi sebagai instance
standby. Untuk melakukannya, ikuti petunjuk di
Mengonfigurasi grup ketersediaan SQL Server AlwaysOn.
Tutorial ini menggunakan us-central1 untuk region utama (disebut sebagai R1).
Jika Anda mengikuti
langkah-langkah dalam
Mengonfigurasi grup ketersediaan SQL Server AlwaysOn,
Anda akan membuat dua instance SQL Server di region yang sama (us-central1). Anda akan men-deploy instance SQL Server utama (node-1) di
us-central1-a, dan instance standby (node-2) di us-central1-b.
Aktifkan replikasi asinkron disk
Setelah semua VM dibuat dan dikonfigurasi, aktifkan penyalinan disk antar-region dengan membuat grup konsistensi untuk semua disk yang terpasang ke VM. Data disalin dari {i>disk<i} sumber ke {i>disk<i} kosong yang baru dibuat di region yang ditentukan.
Buat grup konsistensi untuk node SQL dan pengontrol domain. Salah satu batasan untuk disk zona adalah grup konsistensi tidak dapat menjangkau seluruh zona.
gcloud compute resource-policies create disk-consistency-group node-1-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group node-2-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group witness-disk-const-grp \ --region=$REGION
Tambahkan disk dari VM utama dan standby ke VM yang sesuai {i>consistency <i}(konsistensi).
gcloud compute disks add-resource-policies node-1 \ --zone=$REGION-a \ --resource-policies=node-1-disk-const-grp gcloud compute disks add-resource-policies node-1-datadisk \ --zone=$REGION-a \ --resource-policies=node-1-disk-const-grp gcloud compute disks add-resource-policies node-2 \ --zone=$REGION-b \ --resource-policies=node-2-disk-const-grp gcloud compute disks add-resource-policies node-2-datadisk \ --zone=$REGION-b \ --resource-policies=node-2-disk-const-grp gcloud compute disks add-resource-policies witness \ --zone=$REGION-c \ --resource-policies=witness-disk-const-grp
Membuat disk sekunder kosong di region yang disambungkan
DR_REGION="us-west1" gcloud compute disks create node-1-replica \ --zone=$DR_REGION-a \ --size=50 \ --primary-disk=node-1 \ --primary-disk-zone=$REGION-a gcloud compute disks create node-1-datadisk-replica \ --zone=$DR_REGION-a \ --size=$PD_SIZE \ --primary-disk=node-1-datadisk \ --primary-disk-zone=$REGION-a gcloud compute disks create node-2-replica \ --zone=$DR_REGION-b \ --size=50 \ --primary-disk=node-2 \ --primary-disk-zone=$REGION-b gcloud compute disks create node-2-datadisk-replica \ --zone=$DR_REGION-b \ --size=$PD_SIZE \ --primary-disk=node-2-datadisk \ --primary-disk-zone=$REGION-b gcloud compute disks create witness-replica \ --zone=$DR_REGION-c \ --size=50 \ --primary-disk=witness \ --primary-disk-zone=$REGION-c
Mulai replikasi disk. Data direplikasi dari {i>disk<i} utama ke {i>disk <i}baru membuat disk kosong di region DR.
gcloud compute disks start-async-replication node-1 \ --zone=$REGION-a \ --secondary-disk=node-1-replica \ --secondary-disk-zone=$DR_REGION-a gcloud compute disks start-async-replication node-1-datadisk \ --zone=$REGION-a \ --secondary-disk=node-1-datadisk-replica \ --secondary-disk-zone=$DR_REGION-a gcloud compute disks start-async-replication node-2 \ --zone=$REGION-b \ --secondary-disk=node-2-replica \ --secondary-disk-zone=$DR_REGION-b gcloud compute disks start-async-replication node-2-datadisk \ --zone=$REGION-b \ --secondary-disk=node-2-datadisk-replica \ --secondary-disk-zone=$DR_REGION-b gcloud compute disks start-async-replication witness \ --zone=$REGION-c \ --secondary-disk=witness-replica \ --secondary-disk-zone=$DR_REGION-c
Data harus direplikasi antar-region pada tahap ini.
Status replikasi untuk setiap disk harus berupa Active.
Melakukan simulasi pemulihan dari bencana
Di bagian ini, Anda akan menguji arsitektur pemulihan dari bencana yang disiapkan dalam tutorial.
Menyimulasikan pemadaman layanan dan menjalankan failover pemulihan dari bencana
Selama failover DR, Anda membuat VM baru di region DR dan memasang direplikasi. Untuk menyederhanakan failover, Anda dapat menggunakan Virtual Private Cloud (VPC) yang berbeda di region DR untuk pemulihan, untuk menggunakan alamat IP yang sama.
Sebelum memulai failover, pastikan node-1 adalah node utama untuk
Grup ketersediaan AlwaysOn yang Anda buat. Munculkan {i>domain controller<i} dan
{i>node<i} SQL Server utama untuk menghindari
masalah sinkronisasi data, seperti
kedua {i>node<i} dilindungi oleh dua kelompok
konsistensi yang terpisah.
Untuk menyimulasikan pemadaman layanan, gunakan langkah-langkah berikut:
Membuat VPC pemulihan.
DRVPC_NAME="default-dr" DRSUBNET_NAME="default-recovery" gcloud compute networks create $DRVPC_NAME \ --subnet-mode=custom CIDR = $(gcloud compute networks subnets describe default \ --region=$REGION --format=value\(ipCidrRange\)) gcloud compute networks subnets create $DRSUBNET_NAME \ --network=$DRVPC_NAME --range=$CIDR --region=$DR_REGION
Menghentikan replikasi data.
PROJECT=$(gcloud config get-value project) gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-1-disk-const-grp \ --zone=$REGION-a gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-2-disk-const-grp \ --zone=$REGION-b gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/witness-disk-const-grp \ --zone=$REGION-c
Hentikan VM sumber di region utama.
gcloud compute instances stop node-1 \ --zone=$REGION-a gcloud compute instances stop node-2 \ --zone=$REGION-b gcloud compute instances stop witness \ --zone=$REGION-c
Buat VM di region DR menggunakan replika disk. VM ini akan memiliki alamat IP dari VM sumber.
NODE1IP=$(gcloud compute instances describe node-1 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) NODE2IP=$(gcloud compute instances describe node-2 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) WITNESSIP=$(gcloud compute instances describe witness --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) gcloud compute instances create node-1 \ --zone=$DR_REGION-a \ --machine-type $MACHINE_TYPE \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $NODE1IP\ --disk=boot=yes,device-name=node-1-replica,mode=rw,name=node-1-replica \ --disk=auto-delete=yes,boot=no,device-name=node-1-datadisk-replica,mode=rw,name=node-1-datadisk-replica gcloud compute instances create witness \ --zone=$DR_REGION-c \ --machine-type=n2-standard-2 \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $WITNESSIP \ --disk=boot=yes,device-name=witness-replica,mode=rw,name=witness-replica
Kami telah menyimulasikan kemarahan dan gagal lolos ke wilayah DR. Sekarang kita dapat menguji apakah instance sekunder berfungsi dengan benar atau tidak.
Memverifikasi konektivitas SQL Server
Setelah VM dibuat, pastikan database telah dipulihkan berhasil dan server berfungsi seperti yang diharapkan. Untuk menguji {i>database<i} Anda akan menjalankan kueri pilihan dari {i>database<i} yang dipulihkan.
- Hubungkan ke VM SQL Server menggunakan Desktop Jarak Jauh.
- Buka SQL Server Management Studio.
- Dalam dialog Hubungkan ke server, pastikan nama server disetel ke
NODE-1, lalu pilih Hubungkan. Di menu file, pilih File > Baru > Buat kueri dengan koneksi saat ini.
USE [bookshelf]; SELECT * FROM Books;
Pembersihan
Agar tidak menimbulkan tagihan ke akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini:
Menghapus project
- Di konsol Google Cloud, buka halaman Manage resource.
- Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
- Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus project.
Langkah berikutnya
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.