Dokumen ini menjelaskan cara men-deploy topologi failover dingin untuk server web menggunakan grup instance terkelola dan snapshot persistent disk. Dokumen ini ditujukan untuk arsitek dan orang yang bekerja dalam tim operasi dan administratif.
Anda membuat grup instance terkelola yang menjalankan satu VM dengan persistent disk yang menyimpan data. Snapshot terjadwal persistent disk akan meminimalkan kehilangan data dalam skenario failover. Load Balancer Aplikasi eksternal mengarahkan pengguna ke VM yang berjalan di grup instance terkelola, seperti yang ditunjukkan dalam diagram berikut:
Jika terjadi kegagalan instance, grup instance terkelola akan mencoba membuat ulang VM di zona yang sama. Jika kegagalan berada di tingkat zona, Cloud Monitoring atau yang serupa dapat memberi tahu Anda bahwa ada masalah dan Anda juga dapat membuat grup instance terkelola lainnya secara manual di zona atau region lain. Dalam salah satu skenario failover, platform akan menggunakan snapshot persistent disk terbaru untuk membuat disk pengganti dan memasangnya ke VM baru dalam grup instance.
Dalam dokumen ini, Anda menggunakan alamat IP eksternal VM atau load balancer untuk melihat halaman dasar di server web. Dengan pendekatan ini, Anda dapat menguji pola cold failover jika Anda tidak memiliki nama domain terdaftar dan tanpa perubahan DNS apa pun. Dalam lingkungan produksi, buat dan konfigurasi zona dan kumpulan data Cloud DNS yang ditetapkan ke alamat IP eksternal yang ditetapkan untuk load balancer.
Pola ini menyeimbangkan selisih biaya saat menjalankan beberapa VM atau persistent disk regional dengan mempertahankan tingkat perlindungan data tertentu. Biaya Anda akan lebih rendah saat Anda menjalankan satu VM dan persistent disk, tetapi ada risiko kehilangan data karena snapshot persistent disk hanya diambil pada interval yang ditetapkan. Untuk mengurangi potensi kehilangan data, sebaiknya deploy server web yang dapat dipulihkan dengan dingin yang menggunakan persistent disk regional.
Tabel berikut menguraikan beberapa perbedaan tingkat tinggi dalam opsi perlindungan data untuk pendekatan cold yang dapat dipulihkan yang menggunakan persistent disks regional atau snapshot persistent disk. Untuk informasi selengkapnya, lihat Opsi ketersediaan tinggi yang menggunakan persistent disk.
Persistent disk menurut region | Snapshot persistent disk | |
---|---|---|
Kebocoran data - batas titik pemulihan (RPO) | Nol untuk kegagalan tunggal, seperti pemadaman berkelanjutan pada zona atau pemutusan jaringan. | Seluruh data sejak snapshot terakhir diambil, yang biasanya dalam satu jam sebelumnya atau
lebih. Potensi kebocoran data bergantung pada jadwal snapshot Anda yang mengontrol seberapa sering snapshot diambil. |
Batas waktu pemulihan (RTO) | Waktu deployment untuk VM baru, ditambah beberapa detik hingga persistent disk regional dipasang kembali. | Waktu deployment untuk VM baru, ditambah waktu untuk membuat persistent disk baru dari
snapshot terbaru. Waktu pembuatan disk bergantung pada ukuran snapshot, dan dapat memakan waktu puluhan menit atau jam. |
Biaya | Biaya penyimpanan berlipat ganda karena persistent disk regional direplikasi secara terus-menerus ke zona lain. | Anda hanya membayar sesuai jumlah ruang snapshot yang terpakai. |
Untuk informasi selengkapnya, lihat Harga disk dan gambar. |
Tujuan
- Membuat grup instance terkelola untuk menjalankan VM dengan persistent disk.
- Mengonfigurasi jadwal snapshot untuk mengambil snapshot reguler dari persistent disk.
- Membuat template instance dan skrip startup.
- Membuat dan mengonfigurasi Load Balancer Aplikasi eksternal.
- Menguji failover server web cold dengan grup instance terkelola pengganti.
Biaya
Dalam dokumen ini, Anda menggunakan komponen Google Cloud yang dapat ditagih berikut:
Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda,
gunakan kalkulator harga.
Sebelum memulai
- Login ke akun Google Cloud Anda. Jika Anda baru menggunakan Google Cloud, buat akun untuk mengevaluasi performa produk kami dalam skenario dunia nyata. Pelanggan baru juga mendapatkan kredit gratis senilai $300 untuk menjalankan, menguji, dan men-deploy workload.
-
Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.
-
Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.
-
Enable the Compute Engine API.
- Menginstal Google Cloud CLI.
-
Untuk initialize gcloud CLI, jalankan perintah berikut:
gcloud init
-
Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.
-
Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.
-
Enable the Compute Engine API.
- Menginstal Google Cloud CLI.
-
Untuk initialize gcloud CLI, jalankan perintah berikut:
gcloud init
Anda dapat menjalankan Google Cloud CLI di Konsol Google Cloudtanpa harus menginstal Google Cloud CLI. Untuk menjalankan gcloud CLI di Google Cloud Console, gunakan Cloud Shell.
Menyiapkan lingkungan
Pada bagian ini, Anda akan menentukan beberapa variabel untuk nama dan lokasi resource. Variabel ini digunakan oleh perintah Google Cloud CLI saat Anda men-deploy resource.
Dalam dokumen ini, kecuali jika dinyatakan lain, Anda memasukkan semua perintah di Cloud Shell atau lingkungan pengembangan lokal Anda.
Ganti
PROJECT_ID
dengan project ID Anda. Jika diperlukan, berikan akhiran nama Anda sendiri untuk resource, sepertiapp
.Tentukan region, seperti
us-central1
, dan dua zona di dalam region tersebut, sepertius-central1-a
danus-central1-f
. Zona ini menentukan tempat persistent disk awal dan tempat grup instance terkelola di-deploy, serta tempat Anda bisa failover secara manual jika diperlukan.PROJECT_ID=PROJECT_ID NAME_SUFFIX=app REGION=us-central1 ZONE1=us-central1-a ZONE2=us-central1-f
Membuat VPC dan subnet
Untuk memberikan akses jaringan ke VM, buat Virtual Private Cloud (VPC) dan subnet. Karena grup instance terkelola berfungsi di berbagai zona dalam satu region, hanya satu subnet yang akan dibuat. Untuk informasi selengkapnya tentang keuntungan mode subnet khusus untuk mengelola rentang alamat IP yang digunakan di lingkungan Anda, lihat Menggunakan jaringan VPC mode khusus.
Membuat VPC dengan mode subnet khusus:
gcloud compute networks create network-$NAME_SUFFIX \ --subnet-mode=custom
Jika Anda melihat perintah Cloud Shell, izinkan permintaan pertama ini untuk melakukan panggilan API.
Membuat subnet di VPC baru. Tentukan rentang alamat Anda sendiri, seperti
10.1.0.0/20
, yang sesuai dengan rentang jaringan Anda:gcloud compute networks subnets create subnet-$NAME_SUFFIX-$REGION \ --network=network-$NAME_SUFFIX \ --range=10.1.0.0/20 \ --region=$REGION
Membuat aturan firewall
Membuat aturan firewall untuk mengizinkan traffic web dan health check untuk load balancer grup instance terkelola:
gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:80 \ --source-ranges=0.0.0.0/0 \ --target-tags=http-server gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
Aturan HTTP mengizinkan traffic ke VM mana pun tempat tag
http-server
diterapkan, dan dari sumber mana pun yang menggunakan rentang0.0.0.0/0
. Untuk aturan health check, rentang default pada Google Cloud ditetapkan untuk memungkinkan platform memeriksa status resource dengan benar.Guna mengizinkan traffic SSH untuk konfigurasi awal image VM dasar, buat cakupan aturan firewall ke lingkungan Anda menggunakan parameter
--source-range
. Anda mungkin perlu bekerja dengan tim jaringan untuk menentukan rentang sumber yang digunakan organisasi Anda.Ganti
IP_ADDRESS_SCOPE
dengan cakupan alamat IP Anda sendiri:gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=IP_ADDRESS_SCOPE
Setelah membuat aturan firewall, pastikan bahwa ketiga aturan tersebut telah ditambahkan:
gcloud compute firewall-rules list \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"
Contoh output berikut menunjukkan bahwa tiga aturan telah dibuat dengan benar:
NAME NETWORK DIRECTION PRIORITY ALLOW allow-health-check-app network-app INGRESS 1000 tcp:80 allow-http-app network-app INGRESS 1000 tcp:80 allow-ssh-app network-app INGRESS 1000 tcp:22
Membuat dan mengonfigurasi image VM dasar
Untuk membuat VM identik yang di-deploy tanpa konfigurasi tambahan, gunakan image VM kustom. Gambar ini merekam konfigurasi OS dan Apache, serta digunakan untuk membuat setiap VM dalam grup instance terkelola pada langkah berikutnya.
Anda dapat menggunakan persistent disk untuk menyimpan data aplikasi. Dalam dokumen ini, Anda menggunakan situs Apache dasar untuk menayangkan aplikasi. Kemudian dalam dokumen ini, Anda akan membuat jadwal snapshot yang terpasang pada persistent disk ini untuk membuat snapshot disk otomatis.
Di VM, Anda membuat file index.html
dasar di persistent disk dan
memasangnya ke /var/www/example.com
. File konfigurasi Apache di
/etc/apache2/sites-available/example.com.conf
menyalurkan konten web dari
lokasi persistent disk yang terpasang.
Diagram berikut menunjukkan halaman HTML dasar yang disalurkan oleh Apache yang disimpan di persistent disk:
Anda membangun lingkungan ini dengan langkah-langkah berikut.
Buat SSD sebesar 10 GiB. Memahami kebutuhan penyimpanan Anda dan biaya terkait pembayaran ruang yang disediakan, bukan ruang yang dipakai. Untuk informasi selengkapnya, lihat harga persistent disk.
gcloud compute disks create disk-$NAME_SUFFIX \ --zone $ZONE1 \ --size=10 \ --type=pd-ssd
Buat VM dasar dengan persistent disk yang terpasang:
gcloud compute instances create vm-base-$NAME_SUFFIX \ --zone=$ZONE1 \ --machine-type=n1-standard-1 \ --subnet=subnet-$NAME_SUFFIX-$REGION \ --tags=http-server \ --image=debian-10-buster-v20210721 \ --image-project=debian-cloud \ --boot-disk-size=10GB \ --boot-disk-type=pd-balanced \ --boot-disk-device-name=vm-base-$NAME_SUFFIX \ --disk=mode=rw,name=disk-$NAME_SUFFIX,device-name=disk-$NAME_SUFFIX
Anda menggunakan parameter yang ditentukan di awal dokumen ini untuk memberi nama VM dan terhubung ke subnet yang benar. Nama juga telah ditetapkan dari parameter untuk boot disk dan disk data.
Untuk menginstal dan mengonfigurasi situs sederhana, pertama-tama hubungkan ke VM dasar menggunakan SSH:
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE1
Dalam sesi SSH ke VM, buat skrip untuk mengonfigurasi VM di editor pilihan Anda. Contoh berikut menggunakan Nano sebagai editor:
nano configure-vm.sh
Tempel skrip konfigurasi berikut ke dalam file. Perbarui variabel
NAME_SUFFIX
agar cocok dengan nilai yang telah ditetapkan di awal dokumen ini, seperti app:#!/bin/bash NAME_SUFFIX=app # Create directory for the basic website files sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Find the disk name, then format and mount it DISK_NAME="google-disk-$NAME_SUFFIX" DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')" sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH sudo mount -o discard,defaults $DISK_PATH /var/www/example.com # Install Apache, additional utilities, and cloud-init sudo apt-get update && sudo apt-get -y install apache2 moreutils cloud-init # Write out a basic HTML file to the mounted persistent disk sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF' <!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>HA / DR example</title> </head> <body> <p>Welcome to a test web server with persistent disk snapshots!</p> </body> </html> EOF # Write out an Apache configuration file sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF' <VirtualHost *:80> ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www/example.com ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> EOF # Enable the Apache configuration file and reload service sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Tulis file dan keluar dari editor Anda. Misalnya, di Nano Anda menggunakan
Ctrl-O
untuk menulis file, lalu keluar denganCtrl-X
.Jadikan skrip konfigurasi sebagai file yang dapat dieksekusi, lalu jalankan:
chmod +x configure-vm.sh ./configure-vm.sh
Jika terjadi kegagalan instance dan grup instance terkelola perlu membuat pengganti dari VM dasar ini, data aplikasi harus tersedia. Langkah-langkah berikut akan otomatis berjalan di setiap VM baru:
- Dapatkan beberapa info dari server metadata.
- Dapatkan snapshot terbaru untuk persistent disk.
- Buat disk dari snapshot terbaru ini.
- Pasang disk baru ke VM.
- Pasang disk ke dalam VM.
Buat skrip startup bernama
app-startup.sh
yang melakukan langkah-langkah berikut yang diperlukan untuk VM. Skrip startup ini diterapkan ke template instance pada langkah berikutnya.sudo mkdir /opt/cloud-init-scripts sudo tee -a /opt/cloud-init-scripts/app-startup.sh >/dev/null <<'EOF' #!/bin/bash # Install jq and get an access token for API requests apt-get install -y jq OAUTH_TOKEN=$(curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \ -H "Metadata-Flavor: Google" --silent | jq -r '.access_token') # Make a request against the metadata server to determine the project name, # instance name, and what zone it's running in ZONE_INFO=$(curl http://metadata.google.internal/computeMetadata/v1/instance/zone \ -H "Metadata-Flavor: Google" --silent) PROJECT_NAME=$(curl http://metadata.google.internal/computeMetadata/v1/instance/zone \ -H "Metadata-Flavor: Google" --silent | awk -v FS="/" '{print $2}') ZONE_NAME=$(curl http://metadata.google.internal/computeMetadata/v1/instance/zone \ -H "Metadata-Flavor: Google" --silent | sed 's:.*/::') INSTANCE_NAME=$(curl http://metadata.google.internal/computeMetadata/v1/instance/name \ -H "Metadata-Flavor: Google" --silent) # Get the latest snapshot of the app disk LATEST_SNAPSHOT=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" \ https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/global/snapshots \ --silent | jq -s '.[].items[] | select(.name | contains("disk-$NAME")) | .name' \ | sort -r | head -n 1 | tr -d '"') # Create a persistent disk using the latest persistent disk snapshot curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json; charset=utf-8" \ https://compute.googleapis.com/compute/v1/$ZONE_INFO/disks \ --data '{"name":"'$LATEST_SNAPSHOT'-restored","sizeGb":"10","type":"zones/'$ZONE_NAME'/diskTypes/pd-ssd","sourceSnapshot":"https://www.googleapis.com/compute/v1/projects/'$PROJECT_NAME'/global/snapshots/'$LATEST_SNAPSHOT'"}' # Wait for the persistent disk to be created from the disk snapshot DISK_STATUS=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" \ https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/zones/$ZONE_NAME/disks/$LATEST_SNAPSHOT-restored \ --silent | jq -r .status) while [ $DISK_STATUS != "READY" ] do sleep 2 DISK_STATUS=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" \ https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/zones/$ZONE_NAME/disks/$LATEST_SNAPSHOT-restored \ --silent | jq -r .status) done # Attach the new persistent disk created from the snapshot to the VM curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json; charset=utf-8" \ https://compute.googleapis.com/compute/v1/$ZONE_INFO/instances/$INSTANCE_NAME/attachDisk \ --data '{ "source": "/compute/v1/'$ZONE_INFO'/disks/'$LATEST_SNAPSHOT'-restored"}' # Wait for the persistent disk to be attached before mounting ATTACH_STATUS=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" \ https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/zones/$ZONE_NAME/instances/$INSTANCE_NAME \ --silent | jq '.disks[] | select(.source | contains("disk-"))') while [ -z "$ATTACH_STATUS" ] do sleep 2 ATTACH_STATUS=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" GET \ https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/zones/$ZONE_NAME/instances/$INSTANCE_NAME \ --silent | jq '.disks[] | select(.source | contains("disk-"))') done # With the disk attached, mount the disk and restart Apache echo UUID=`blkid -s UUID -o value /dev/sdb` /var/www/example.com ext4 discard,defaults,nofail 0 2 \ | tee -a /etc/fstab mount -a systemctl reload apache2 # Remove jq so it's not left on the VM apt-get remove -y jq EOF
Untuk menerapkan variabel
NAME_SUFFIX
yang Anda tentukan di awal dokumen ke dalam skrip startup, sepertiapp
, gunakan perintahenvsubst
:export NAME=app envsubst '$NAME' < "/opt/cloud-init-scripts/app-startup.sh" \ | sudo sponge "/opt/cloud-init-scripts/app-startup.sh"
Keluar dari sesi SSH ke VM:
exit
Dapatkan alamat IP VM dan gunakan
curl
untuk melihat halaman web dasar:curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \ --zone $ZONE1 \ --format="value(networkInterfaces.accessConfigs.[0].natIP)")
Situs dasar ditampilkan, seperti yang ditunjukkan dalam contoh output berikut:
<!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>HA / DR example</title> </head> <body> <p>Welcome to a test web server with persistent disk snapshots!</p> </body> </html>
Langkah ini mengonfirmasi bahwa Apache dikonfigurasi dengan benar, dan halaman dimuat dari persistent disk yang terpasang. Di bagian berikut, Anda akan membuat gambar menggunakan VM dasar ini dan mengonfigurasi template instance dengan skrip startup.
Membuat jadwal snapshot persistent disk
Untuk memastikan bahwa VM yang dibuat dalam grup instance terkelola selalu memiliki data terbaru dari persistent disk, Anda perlu membuat jadwal snapshot. Jadwal ini mengambil snapshot otomatis persistent disk pada waktu yang ditentukan, dan mengontrol berapa lama penyimpanan snapshot tersebut. Gambar berikut menampilkan cara kerja proses snapshot ini:
Pikirkan kebutuhan aplikasi dan sasaran bisnis Anda terkait seberapa sering Anda harus mengambil snapshot - misalnya, situs statis memerlukan snapshot yang lebih jarang daripada aplikasi aktif yang menulis data ke disk.
Untuk informasi selengkapnya tentang cara menentukan pendekatan terbaik untuk aplikasi Anda dan metode pemulihan yang akan digunakan, lihat panduan perencanaan pemulihan dari bencana (disaster recovery).
Dalam skenario ini, Anda menggunakan jadwal snapshot untuk membuat snapshot persistent disk reguler. Anda menentukan jadwal snapshot ini dalam kebijakan resource. Kebijakan resource memungkinkan Anda menentukan tindakan yang akan dijalankan dan memasangnya ke resource di lingkungan Anda.
Pada kebijakan resource ini, Anda menentukan jadwal untuk membuat snapshot dengan setelan berikut:
- Ambil snapshot setiap 4 jam, mulai pukul 22.00 UTC
- Pertahankan snapshot selama 1 hari
Konfigurasi jadwal ini sesuai kebutuhan untuk lingkungan Anda, seperti waktu mulai dan seberapa sering Anda ingin mengambil snapshot:
gcloud compute resource-policies create snapshot-schedule snapshot-schedule-$NAME_SUFFIX \ --description "Snapshot persistent disk every 4 hours" \ --max-retention-days 1 \ --start-time 22:00 \ --hourly-schedule 4 \ --region $REGION
Untuk informasi lebih lanjut, baca cara menggunakan snapshot terjadwal untuk persistent disk.
Untuk menggunakan jadwal snapshot, lampirkan kebijakan resource ke persistent disk. Tentukan nama persistent disk Anda dan kebijakan resource yang dibuat di langkah sebelumnya:
gcloud compute disks add-resource-policies disk-$NAME_SUFFIX \ --resource-policies snapshot-schedule-$NAME_SUFFIX \ --zone $ZONE1
Anda tidak dapat menyelesaikan sisa dokumen ini dan melihat cara kerja grup instance terkelola sampai snapshot disk pertama telah dibuat. Buat snapshot disk secara manual sekarang, dan biarkan jadwal snapshot kebijakan resource membuat snapshot tambahan seperti yang ditentukan:
gcloud compute disks snapshot disk-$NAME_SUFFIX \ --zone=$ZONE1 \ --snapshot-names=disk-$NAME_SUFFIX-$(date "+%Y%m%d%H%M%S")
Membuat akun layanan
Setiap VM dalam grup instance terkelola yang dibuat pada langkah berikutnya harus menjalankan skrip startup. Skrip startup ini membuat persistent disk dari snapshot, lalu memasangkannya ke VM. Sebagai praktik keamanan terbaik, buat akun layanan baru hanya dengan izin yang diperlukan untuk melakukan operasi disk ini. Kemudian, tetapkan akun layanan ini ke VM.
Buat akun layanan untuk digunakan dengan VM di grup instance terkelola:
gcloud iam service-accounts create instance-sa-$NAME_SUFFIX \ --description="Service account for HA/DR example" \ --display-name="HA/DR for VM instances"
Buat peran khusus dan tetapkan hanya izin yang diperlukan untuk melakukan tugas pengelolaan disk. Izin berikut diperlukan:
compute.snapshots.list
compute.snapshots.useReadOnly
compute.disks.get
compute.disks.create
compute.instances.get
compute.instances.attachDisk
compute.disks.use
gcloud iam roles create instance_snapshot_management_$NAME_SUFFIX \ --project=$PROJECT_ID \ --title="Snapshot management for VM instances" \ --description="Custom role to allow an instance to create a persistent disk from a snapshot and attach to VM." \ --permissions=compute.snapshots.list,compute.snapshots.useReadOnly,compute.disks.get,compute.disks.create,compute.instances.get,compute.instances.attachDisk,compute.disks.use \ --stage=GA
Tambahkan binding peran yang diperlukan untuk akun layanan baru:
gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:instance-sa-$NAME_SUFFIX@$PROJECT_ID.iam.gserviceaccount.com" \ --role="projects/$PROJECT_ID/roles/instance_snapshot_management_$NAME_SUFFIX" gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:instance-sa-$NAME_SUFFIX@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/iam.serviceAccountUser"
Membuat VM image dan template instance
Untuk membuat VM identik yang dapat di-deploy secara otomatis tanpa memerlukan konfigurasi tambahan, Anda harus menggunakan image VM khusus. Image ini merekam konfigurasi OS dan Apache. Setiap VM yang dibuat dalam grup instance terkelola akan menggunakan image ini pada langkah berikutnya.
Sebelum dapat membuat image, Anda harus menghentikan VM:
gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE1
Buat gambar VM dasar yang dikonfigurasi di bagian sebelumnya:
gcloud compute images create image-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE1 \ --storage-location=$REGION
Anda menggunakan cloud-init untuk menjalankan skrip startup sebelumnya saat pertama kali VM dalam grup instance terkelola melakukan booting. Skrip startup reguler yang diterapkan ke VM berjalan setiap kali VM melakukan booting, seperti jika Anda memulai ulang VM setelah update.
Buat file konfigurasi cloud-init untuk digunakan dengan template instance:
tee -a cloud-init.yaml >/dev/null <<'EOF' #cloud-config runcmd: - [ bash, /opt/cloud-init-scripts/app-startup.sh ] EOF
Buat template instance yang menerapkan konfigurasi cloud-init untuk menjalankan skrip startup yang membuat disk dari snapshot, lalu memasang disk ke VM:
gcloud compute instance-templates create template-$NAME_SUFFIX \ --machine-type=n1-standard-1 \ --subnet=projects/$PROJECT_ID/regions/$REGION/subnetworks/subnet-$NAME_SUFFIX-$REGION \ --tags=http-server \ --image=image-$NAME_SUFFIX \ --scopes cloud-platform \ --service-account="instance-sa-$NAME_SUFFIX@$PROJECT_ID.iam.gserviceaccount.com" \ --metadata-from-file user-data=cloud-init.yaml
Membuat grup instance terkelola
Grup instance terkelola menjalankan VM. Grup instance terkelola berjalan di zona yang ditentukan dan memantau kondisi VM. Jika terjadi kegagalan dan VM berhenti berjalan, grup instance terkelola akan mencoba membuat ulang VM lain di zona yang sama dan membuat persistent disk dari snapshot terbaru. Jika kegagalan berada di tingkat zona, Anda harus melakukan cold failover secara manual dan membuat grup instance terkelola lainnya di zona yang berbeda. Template gambar dan instance khusus yang sama akan otomatis mengonfigurasi VM dengan cara yang identik.
Membuat health check untuk memantau VM di grup instance terkelola. Health check ini memastikan VM merespons port 80. Untuk aplikasi Anda sendiri, pantau port yang sesuai untuk memeriksa kondisi VM.
gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX --port 80
Membuat grup instance terkelola hanya dengan satu VM. VM tunggal ini melakukan booting dan membuat persistent disk dari snapshot terbaru, lalu memasangnya dan mulai menyalurkan traffic web.
gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE1 \ --base-instance-name=instance-vm-$NAME_SUFFIX \ --template=template-$NAME_SUFFIX \ --size=1 \ --zone=$ZONE1 \ --health-check=http-basic-check-$NAME_SUFFIX
Membuat dan mengonfigurasi load balancer
Agar pengguna dapat mengakses situs Anda, Anda harus mengizinkan traffic melalui VMs yang berjalan dalam grup instance terkelola. Anda juga perlu mengalihkan traffic secara otomatis ke VM baru jika terjadi kegagalan zona dalam grup instance terkelola.
Pada bagian berikut, Anda akan membuat load balancer eksternal dengan layanan backend untuk traffic HTTP pada port 80, menggunakan health check yang telah dibuat pada langkah sebelumnya, dan memetakan alamat IP eksternal ke layanan backend.
Untuk informasi selengkapnya, lihat Cara menyiapkan load balancer HTTP eksternal sederhana.
Membuat dan mengonfigurasi load balancer untuk aplikasi Anda:
# Configure port rules for HTTP port 80 gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$ZONE1 \ --named-ports http:80 \ --zone $ZONE1 # Create a backend service and add the managed instance group to it gcloud compute backend-services create \ web-backend-service-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global gcloud compute backend-services add-backend \ web-backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$ZONE1 \ --instance-group-zone=$ZONE1 \ --global # Create a URL map for the backend service gcloud compute url-maps create web-map-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Configure forwarding for the HTTP traffic gcloud compute target-http-proxies create \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http-$NAME_SUFFIX gcloud compute forwarding-rules create \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
Dapatkan alamat IP aturan penerusan untuk traffic web:
IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress)")
Gunakan
curl
, atau buka browser web Anda, untuk melihat situs menggunakan alamat IP load balancer dari langkah sebelumnya:curl $IP_ADDRESS
Load balancer memerlukan waktu beberapa menit untuk menyelesaikan deployment dan mengarahkan traffic ke backend Anda dengan benar. Error HTTP 404 atau 502 akan ditampilkan jika load balancer masih di-deploy. Jika perlu, tunggu beberapa menit dan coba akses kembali situs web Anda.
Situs dasar ditampilkan, seperti yang ditunjukkan dalam contoh output berikut:
<!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>HA / DR example</title> </head> <body> <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p> </body> </html>
Menyimulasikan kegagalan dan pemulihan zona
Tinjau deployment resource sebelum menyimulasikan kegagalan di tingkat zona. Semua resource telah dibuat untuk mendukung lingkungan berikut:
- Satu VM berjalan di grup instance terkelola dengan persistent disk terpasang yang menyimpan situs dasar.
- Snapshot diambil secara berkala dari persistent disk menggunakan jadwal snapshot kebijakan resource.
- Skrip startup diterapkan ke template instance sehingga setiap VM yang dibuat dalam grup instance terkelola membuat persistent disk dari snapshot disk terakhir dan melampirkannya.
- Health check memantau status VM di dalam grup instance terkelola.
- Load Balancer Aplikasi eksternal mengarahkan pengguna ke VM yang berjalan di grup instance terkelola.
- Jika VM gagal, grup instance terkelola akan mencoba membuat ulang VM di zona yang sama. JIka kegagalan berada pada tingkat zona, Anda harus membuat grup instance terkelola pengganti secara manual di zona kerja yang lain
Dalam lingkungan produksi, Anda mungkin mendapatkan pemberitahuan menggunakan Cloud Monitoring atau solusi pemantauan lainnya ketika terjadi masalah. Pemberitahuan ini akan meminta manusia memahami cakupan kegagalan sebelum Anda membuat grup instance terkelola pengganti secara manual di zona kerja yang lain. Pendekatan alternatifnya adalah menggunakan solusi pemantauan untuk merespons pemadaman layanan secara otomatis dengan grup instance terkelola.
Saat Anda atau solusi pemantauan menentukan tindakan yang paling sesuai adalah melakukan failover, buat grup instance terkelola pengganti. Dalam dokumen ini, Anda membuat resource pengganti secara manual.
Untuk menyimulasikan kegagalan pada tingkat zona, hapus backend load balancer dan grup instance terkelola:
gcloud compute backend-services remove-backend \ web-backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$ZONE1 \ --instance-group-zone=$ZONE1 \ --global gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE1 \ --zone=$ZONE1
Saat diminta, konfirmasi permintaan untuk menghapus grup instance terkelola.
Dalam lingkungan produksi, sistem pemantauan Anda menghasilkan pemberitahuan yang sekarang meminta tindakan cold failover.
Gunakan
curl
atau browser web Anda kembali untuk mengakses alamat IP load balancer:curl $IP_ADDRESS --max-time 5
Permintaan
curl
gagal karena tidak ada target yang responsif untuk load balancer.Untuk menyimulasikan cold failover, buat grup instance terkelola di zona berbeda:
gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE2 \ --template=template-$NAME_SUFFIX \ --size=1 \ --zone=$ZONE2 \ --health-check=http-basic-check-$NAME_SUFFIX
VM image, template instance, dan persistent disk mengelola semua konfigurasi untuk instance aplikasi.
Perbarui load balancer untuk menambahkan grup instance terkelola dan VM yang baru:
gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$ZONE2 \ --named-ports http:80 \ --zone $ZONE2 gcloud compute backend-services add-backend \ web-backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$ZONE2 \ --instance-group-zone=$ZONE2 \ --global
Gunakan
curl
atau browser web Anda sekali lagi untuk mengakses alamat IP load balancer yang mengarahkan traffic ke VM yang berjalan di grup instance terkelola:curl $IP_ADDRESS
VM memerlukan waktu beberapa menit untuk menyelesaikan deployment dan memulihkan data dari snapshot persistent disk terbaru. Error HTTP 404 atau 502 ditampilkan jika VM masih di-deploy, dan Apache default akan ditampilkan jika masih memulihkan data. Jika perlu, tunggu beberapa menit dan coba akses situs lagi.
Contoh respons berikut menunjukkan halaman web yang berjalan dengan benar di VM:
<!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>HA / DR example</title> </head> <body> <p>Welcome to a test web server with persistent disk snapshots!</p> </body> </html>
Periksa status kesehatan grup instance terkelola:
gcloud compute instance-groups managed list-instances instance-group-$NAME_SUFFIX-$ZONE2 \ --zone $ZONE2
Contoh output berikut menampilkan status VM sebagai
RUNNING
danHEALTHY
:NAME ZONE STATUS HEALTH_STATE ACTION instance-vm-app us-central1-f RUNNING HEALTHY NONE
Untuk memverifikasi bahwa disk persisten yang terpasang telah dibuat dari snapshot, lihat sumbernya. Tentukan instance
NAME
yang ditampilkan dari perintahlist-instances
sebelumnya.gcloud compute instances describe NAME \ --zone=$ZONE2 \ --format="value(disks.[1].source)"
Contoh output berikut menunjukkan persistent disk yang diberi nama disk-app-us-central1-a-20210630165529-umopkt17-restored. Akhiran yang dipulihkan ditambahkan oleh skrip startup ke nama snapshot disk terbaru:
https://www.googleapis.com/compute/v1/projects/project/zones/us-central1-f/disks/disk-app-us-central1-a-20210630165529-umopkt17-restored
Pembersihan
Agar tidak perlu membayar biaya pada akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini, hapus project yang berisi resource tersebut, atau simpan project dan hapus setiap resource.
Untuk menghapus setiap resource yang dibuat dalam dokumen ini, lakukan langkah-langkah berikut.
Hapus konfigurasi load balancer:
gcloud compute forwarding-rules delete \ http-content-rule-$NAME_SUFFIX --global --quiet gcloud compute target-http-proxies delete \ http-lb-proxy-$NAME_SUFFIX --quiet gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet gcloud compute backend-services delete \ web-backend-service-$NAME_SUFFIX --global --quiet
Hapus grup instance terkelola dan health check:
gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE2 \ --zone=$ZONE2 --quiet gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
Hapus template instance, konfigurasi cloud-init, gambar, VM dasar, persistent disk, dan jadwal snapshot.
gcloud compute instance-templates delete template-$NAME_SUFFIX --quiet rm cloud-init.yaml gcloud compute images delete image-$NAME_SUFFIX --quiet gcloud compute instances delete vm-base-$NAME_SUFFIX --zone=$ZONE1 --quiet gcloud compute disks delete disk-$NAME_SUFFIX --zone=$ZONE1 --quiet gcloud compute resource-policies delete \ snapshot-schedule-$NAME_SUFFIX --region $REGION --quiet
Masukkan daftar, lalu hapus snapshot dan disk yang dibuat oleh instance:
gcloud compute disks list --filter="name:disk-$NAME_SUFFIX" \ --uri | xargs gcloud compute disks delete gcloud compute snapshots list --filter="name:disk-$NAME_SUFFIX" \ --uri | xargs gcloud compute snapshots delete
Hapus akun layanan dan peran khusus:
gcloud iam roles delete instance_snapshot_management_$NAME_SUFFIX \ --project=$PROJECT_ID --quiet gcloud iam service-accounts delete \ instance-sa-$NAME_SUFFIX@$PROJECT_ID.iam.gserviceaccount.com --quiet
Menghapus aturan firewall:
gcloud compute firewall-rules delete allow-health-check-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete allow-ssh-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete allow-http-$NAME_SUFFIX --quiet
Hapus subnet dan VPC:
gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION --region=$REGION --quiet gcloud compute networks delete network-$NAME_SUFFIX --quiet
Langkah selanjutnya
- Untuk pendekatan alternatif guna mengurangi potensi kehilangan data, lihat Men-deploy aplikasi cold yang dapat dipulihkan yang menggunakan persistent disk regional.
- Untuk mempelajari cara menentukan pendekatan terbaik untuk aplikasi Anda dan metode pemulihan yang akan digunakan, lihat Panduan perencanaan pemulihan dari bencana (disaster recovery).
- Untuk melihat pola lain pada aplikasi, seperti failover cold dan hot, lihat Skenario pemulihan dari bencana (disaster recovery) untuk aplikasi.
- Untuk mengetahui cara lainnya dalam menangani skala dan ketersediaan, lihat Pola untuk aplikasi yang skalabel dan tangguh.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.