Skenario pemulihan dari bencana (disaster recovery) untuk aplikasi

Last reviewed 2023-05-25 UTC

Artikel ini adalah bagian dari rangkaian yang membahas pemulihan bencana (DR) di Google Cloud. Bagian ini menjelaskan skenario pemulihan dari bencana umum untuk aplikasi.

Rangkaian ini terdiri dari bagian-bagian berikut:

Pengantar

Artikel ini menjelaskan skenario DR untuk aplikasi dalam hal pola DR yang menunjukkan seberapa mudah aplikasi dapat pulih dari peristiwa bencana. Fitur ini menggunakan konsep yang dibahas dalam artikel elemen penyusun DR untuk menjelaskan cara menerapkan rencana DR menyeluruh yang sesuai bagi sasaran pemulihan.

Untuk memulai, pertimbangkan beberapa workload umum untuk mengilustrasikan bagaimana pemikiran tentang sasaran dan arsitektur pemulihan Anda memiliki pengaruh langsung terhadap rencana DR Anda.

Workload batch processing

Workload batch processing cenderung tidak begitu penting, jadi biasanya Anda tidak perlu mengeluarkan biaya untuk merancang arsitektur ketersediaan tinggi (HA) untuk memaksimalkan waktu beroperasi; secara umum, workload batch processing dapat menangani gangguan. Jenis beban kerja ini dapat memanfaatkan produk hemat biaya seperti instance preemptible VM, yang merupakan instance yang dapat dibuat dan dijalankan dengan harga yang jauh lebih rendah daripada instance biasanya. (Namun, Compute Engine akan menghentikan—preempt—instance ini jika memerlukan akses ke resource tersebut untuk tugas lain, dan instance tersebut akan dihentikan hingga 24 jam setelah diluncurkan.)

Dengan menerapkan checkpoint reguler sebagai bagian dari tugas pemrosesan, tugas pemrosesan dapat dilanjutkan dari titik kegagalan saat VM baru diluncurkan. Jika Anda menggunakan Dataproc, proses peluncuran node pekerja yang dapat dihentikan dikelola oleh grup instance terkelola. Hal ini dapat dianggap sebagai pola hangat, di mana ada jeda singkat yang menunggu VM pengganti untuk melanjutkan pemrosesan.

Situs e-commerce

Di situs e-commerce, beberapa bagian aplikasi dapat memiliki nilai RTO yang lebih besar. Misalnya, pipeline pembelian yang sebenarnya harus memiliki ketersediaan tinggi, tetapi proses email yang mengirimkan notifikasi pesanan kepada pelanggan dapat menoleransi penundaan beberapa jam. Pelanggan mengetahui tentang pembelian mereka, jadi meskipun mereka mengharapkan email konfirmasi, notifikasi tersebut bukan bagian penting dari proses tersebut. Ini adalah campuran dari pola panas (pembelian) dan hangat/dingin (notifikasi).

Bagian transaksional aplikasi memerlukan waktu beroperasi yang tinggi dengan nilai RTO yang minimal. Oleh karena itu, Anda menggunakan HA, yang memaksimalkan ketersediaan bagian aplikasi ini. Pendekatan ini dapat dianggap sebagai pola panas.

Skenario e-commerce menggambarkan bagaimana Anda dapat memiliki berbagai nilai RTO dalam aplikasi yang sama.

Streaming video

Solusi streaming video memiliki banyak komponen yang harus memiliki ketersediaan tinggi, mulai dari pengalaman penelusuran hingga proses streaming konten sebenarnya kepada pengguna. Selain itu, sistem memerlukan latensi rendah untuk menciptakan pengalaman pengguna yang memuaskan. Jika ada aspek dari solusi yang gagal memberikan pengalaman yang baik, hal ini buruk bagi pemasok serta pelanggan. Terlebih lagi, pelanggan dewasa ini dapat beralih ke produk yang kompetitif.

Dalam skenario ini, arsitektur HA harus dimiliki, dan nilai RTO kecil diperlukan. Skenario ini memerlukan pola panas di seluruh arsitektur aplikasi untuk membantu memastikan dampak yang minimal jika terjadi bencana.

Arsitektur DR dan HA untuk produksi lokal

Bagian ini membahas cara menerapkan tiga pola—cold, warm, dan hot—saat aplikasi Anda berjalan di infrastruktur lokal dan solusi DR Anda berada di Google Cloud.

Pola cold: Pemulihan ke Google Cloud

Dalam pola dingin, Anda memiliki resource minimal di project DR Google Cloud—hanya cukup untuk memungkinkan skenario pemulihan. Ketika ada masalah yang mencegah lingkungan produksi menjalankan workload produksi, strategi failover memerlukan pencerminan lingkungan production untuk dimulai di Google Cloud. Klien kemudian mulai menggunakan layanan dari lingkungan DR.

Di bagian ini, kita memeriksa contoh dari pola ini. Dalam contoh ini, Cloud Interconnect dikonfigurasi dengan solusi VPN yang dikelola sendiri (non-Google Cloud) untuk menyediakan konektivitas ke Google Cloud. Data disalin ke Cloud Storage sebagai bagian dari lingkungan produksi.

Elemen penyusun DR::

  • Cloud DNS
  • Cloud Interconnect
  • Solusi VPN yang dikelola sendiri
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

Diagram berikut mengilustrasikan arsitektur ini.

Arsitektur untuk pola dingin saat produksi dilakukan di infrastruktur lokal

Langkah-langkah berikut menjelaskan cara mengonfigurasi lingkungan::

  1. Buat Jaringan VPC
  2. Konfigurasi konektivitas antara jaringan lokal dan jaringan Google Cloud.
  3. Buat bucket Cloud Storage sebagai target untuk pencadangan data Anda.
  4. Buat kunci akun layanan untuk akun layanan khusus. File ini digunakan untuk meneruskan kredensial ke skrip otomatis.

  5. Salin kunci akun layanan ke komputer lokal tempat Anda akan menjalankan skrip yang mengupload cadangan database. (Hal ini dapat berupa server database Anda, tetapi kebijakan keamanan mungkin tidak mengizinkan Anda menginstal software tambahan pada server database.)

  6. Buat kebijakan IAM untuk membatasi siapa yang dapat mengakses bucket dan objeknya. Anda menyertakan akun layanan yang dibuat khusus untuk tujuan ini. Tambahkan juga akun pengguna atau grup ke kebijakan untuk operator atau administrator sistem, dengan memberikan izin yang relevan ke semua identitas ini. Untuk mengetahui detail tentang izin akses ke Cloud Storage, lihat izin IAM untuk Cloud Storage.

  7. Uji apakah Anda dapat mengupload dan mendownload file di bucket target.

  8. Buat skrip transfer data.

  9. Buat tugas terjadwal untuk menjalankan skrip.

  10. Buat gambar kustom yang dikonfigurasi untuk setiap server di lingkungan produksi. Setiap gambar harus memiliki konfigurasi yang sama dengan gambar lokal yang setara.

    Sebagai bagian dari konfigurasi gambar kustom server database, buat skrip startup yang akan otomatis menyalin cadangan terbaru dari bucket Cloud Storage ke instance, lalu menjalankan proses pemulihan.

  11. Konfigurasikan Cloud DNS agar mengarah ke layanan web yang terhubung ke internet.

  12. Buat template Deployment Manager yang akan membuat server aplikasi di jaringan Google Cloud menggunakan gambar kustom yang dikonfigurasi sebelumnya. Template ini juga harus menyiapkan firewall sesuai aturan yang diperlukan.

Anda perlu menerapkan proses untuk memastikan bahwa gambar kustom memiliki versi aplikasi yang sama seperti di infrastruktur lokal. Pastikan Anda menggabungkan upgrade ke gambar kustom sebagai bagian dari siklus upgrade standar, dan pastikan template Deployment Manager Anda menggunakan gambar kustom terbaru.

Proses failover dan tugas pasca-mulai ulang

Jika terjadi bencana, Anda dapat melakukan pemulihan ke sistem yang berjalan di Google Cloud. Untuk melakukannya, Anda perlu meluncurkan proses pemulihan agar dapat membuat lingkungan pemulihan menggunakan template Deployment Manager yang dibuat. Saat instance di lingkungan pemulihan siap menerima traffic produksi, Anda menyesuaikan DNS agar mengarah ke server web di Google Cloud.

Urutan pemulihan umumnya adalah:

  1. Gunakan template Deployment Manager untuk membuat deployment di Google Cloud.
  2. Terapkan pencadangan database terbaru di Cloud Storage ke server database yang berjalan di Google Cloud dengan mengikuti petunjuk sistem database Anda untuk memulihkan file cadangan.
  3. Terapkan log transaksi terbaru di Cloud Storage.
  4. Uji apakah aplikasi berfungsi seperti yang diharapkan dengan menyimulasikan skenario pengguna di lingkungan yang dipulihkan..
  5. Setelah pengujian berhasil, konfigurasi Cloud DNS agar mengarah ke server web di Google Cloud. (Misalnya, Anda dapat menggunakan alamat IP anycast di balik load balancer Google Cloud, dengan beberapa server web di balik load balancer.)

Diagram berikut menunjukkan lingkungan yang dipulihkan:

cold pattern<i} untuk pemulihan saat produksi berada di infrastruktur lokal" class="l10n-absolute-url-src" l10n-attrs-original-order="src,alt,class" src="https://cloud.google.com/static/architecture/images/dr-scenarios-for-apps-onprem-cold-pattern-state-2.svg" />

Saat lingkungan produksi berjalan lagi secara lokal dan lingkungan dapat mendukung workload produksi, Anda akan membalik langkah-langkah yang diikuti untuk melakukan failover ke lingkungan pemulihan Google Cloud. Urutan umum untuk kembali ke lingkungan produksi adalah sebagai berikut:

  1. Lakukan pencadangan database yang berjalan di Google Cloud.
  2. Salin file cadangan ke lingkungan produksi Anda.
  3. Terapkan file cadangan ke sistem database produksi Anda.
  4. Mencegah koneksi ke aplikasi di Google Cloud. Misalnya, mencegah koneksi ke load balancer global. Mulai saat ini, aplikasi Anda tidak akan tersedia sampai Anda selesai memulihkan lingkungan produksi.
  5. Salin semua file log transaksi ke lingkungan production dan terapkan ke server database.
  6. Konfigurasikan Cloud DNS agar mengarah ke layanan web lokal Anda.
  7. Pastikan proses yang Anda miliki untuk menyalin data ke Cloud Storage beroperasi seperti yang diharapkan.
  8. Hapus deployment Anda.

Mode warm standby: Pemulihan ke Google Cloud

Pola hangat biasanya diterapkan untuk menjaga nilai RTO dan RPO sekecil mungkin tanpa upaya dan biaya konfigurasi HA sepenuhnya. Makin kecil nilai RTO dan RPO, makin tinggi biaya karena Anda makin mendekati lingkungan yang sepenuhnya redundan yang dapat menyalurkan traffic dari dua lingkungan. Oleh karena itu, menerapkan pola hangat untuk skenario DR Anda merupakan kompromi yang baik antara anggaran dan ketersediaan.

Contoh pendekatan ini adalah menggunakan Cloud Interconnect yang dikonfigurasi dengan solusi VPN yang dikelola sendiri untuk menyediakan konektivitas ke Google Cloud. Aplikasi multitingkat berjalan di infrastruktur lokal sembari menggunakan rangkaian pemulihan minimal di Google Cloud. Rangkaian pemulihan terdiri dari instance server database operasional di Google Cloud. Instance ini harus berjalan setiap saat agar dapat menerima transaksi yang direplikasi melalui teknik replikasi asinkron atau semisinkron. Untuk mengurangi biaya, Anda dapat menjalankan database pada jenis mesin terkecil yang mampu menjalankan layanan database. Karena Anda dapat menggunakan instance yang berjalan lama, diskon untuk penggunaan berkelanjutan akan berlaku.

Elemen penyusun DR:

  • Cloud DNS
  • Cloud Interconnect
  • Solusi VPN yang dikelola sendiri
  • Compute Engine
  • Deployment Manager

Snapshot Compute Engine menyediakan cara untuk mengambil cadangan yang dapat Anda roll back ke status sebelumnya. Snapshot digunakan dalam contoh ini karena biner aplikasi dan halaman web yang diupdate sering ditulis ke web produksi dan ke server aplikasi. Update ini direplikasi secara teratur ke server web referensi dan instance server aplikasi di Google Cloud. (Server referensi tidak menerima traffic produksi. Server referensi tersebut digunakan untuk membuat snapshot.)

Diagram berikut mengilustrasikan arsitektur yang mengimplementasikan pendekatan ini. Target replikasi tidak ditampilkan dalam diagram.

Arsitektur untuk pola warm saat produksi dilakukan di infrastruktur lokal

Langkah-langkah berikut menjelaskan cara mengonfigurasi lingkungan:

  1. Buat Jaringan VPC
  2. Konfigurasi konektivitas antara jaringan lokal Anda dan jaringan Google Cloud.
  3. Replikasikan server lokal Anda ke instance VM Google Cloud. Salah satu pilihannya adalah menggunakan solusi mitra; metode yang Anda gunakan tergantung pada keadaan Anda.
  4. Buat gambar kustom server database Anda di Google Cloud yang memiliki konfigurasi yang sama dengan server database lokal Anda.
  5. Buat snapshot server web dan instance server aplikasi.
  6. Mulai instance database di Google Cloud menggunakan image kustom yang Anda buat sebelumnya. Gunakan jenis mesin terkecil yang mampu menerima data replika dari database produksi lokal.
  7. Instal persistent disk ke instance database Google Cloud untuk database dan log transaksi.
  8. Konfigurasikan replikasi antara server database lokal dan server database di Google Cloud dengan mengikuti petunjuk untuk software database Anda.
  9. Tetapkan flag hapus otomatis di persistent disk yang terpasang pada instance database ke no-auto-delete.
  10. Konfigurasi tugas terjadwal untuk membuat snapshot reguler dari persistent disk instance database di Google Cloud.
  11. Buat reservasi untuk memastikan kapasitas server web dan server aplikasi sesuai kebutuhan.
  12. Uji proses pembuatan instance dari snapshot dan pengambilan snapshot persistent disk.
  13. Buat instance server web dan server aplikasi menggunakan snapshot yang dibuat sebelumnya.
  14. Buat skrip yang menyalin update ke aplikasi web dan server aplikasi setiap kali server lokal yang terkait diupdate. Tulis skrip untuk membuat snapshot server yang diupdate.
  15. Konfigurasikan Cloud DNS agar mengarah ke layanan web yang terhubung ke internet secara lokal.

Proses failover dan tugas pasca-mulai ulang

Untuk mengelola failover, biasanya Anda menggunakan sistem pemantauan dan pemberitahuan untuk menjalankan proses failover otomatis. Jika aplikasi lokal perlu melakukan failover, Anda akan mengonfigurasi sistem database di Google Cloud agar dapat menerima traffic produksi. Anda juga memulai instance dari server web dan server aplikasi.

Diagram berikut menunjukkan konfigurasi setelah failover ke Google Cloud yang memungkinkan workload produksi disalurkan dari Google Cloud:

Konfigurasi pola warm untuk pemulihan saat produksi berada di infrastruktur lokal

Urutan pemulihan umumnya adalah:

  1. Ubah ukuran instance server database agar dapat menangani beban produksi.
  2. Gunakan snapshot server web dan aplikasi di Google Cloud untuk membuat server web dan instance aplikasi baru.
  3. Uji apakah aplikasi berfungsi seperti yang diharapkan dengan menyimulasikan skenario pengguna di lingkungan yang dipulihkan.
  4. Setelah pengujian berhasil, konfigurasi Cloud DNS agar mengarah ke layanan web Anda di Google Cloud.

Saat lingkungan produksi berjalan lagi secara lokal dan dapat mendukung workload produksi, Anda membalik langkah-langkah yang diikuti untuk beralih ke lingkungan pemulihan Google Cloud. Urutan umum untuk kembali ke lingkungan produksi adalah sebagai berikut:

  1. Lakukan pencadangan database yang berjalan di Google Cloud.
  2. Salin file cadangan ke lingkungan produksi Anda.
  3. Terapkan file cadangan ke sistem database produksi Anda.
  4. Mencegah koneksi ke aplikasi di Google Cloud. Salah satu cara melakukannya adalah mencegah koneksi ke server web dengan mengubah aturan firewall. Mulai sekarang, aplikasi Anda tidak akan tersedia sampai Anda selesai memulihkan lingkungan produksi.
  5. Salin semua file log transaksi ke lingkungan production dan terapkan ke server database.
  6. Uji apakah aplikasi berfungsi seperti yang diharapkan dengan menyimulasikan skenario pengguna di lingkungan produksi.
  7. Konfigurasikan Cloud DNS agar mengarah ke layanan web lokal Anda.
  8. Hapus instance server web dan server aplikasi yang berjalan di Google Cloud. Biarkan server referensi tetap berjalan.
  9. Ubah ukuran server database di Google Cloud kembali ke ukuran instance minimum yang dapat menerima data replika dari database produksi lokal.
  10. Konfigurasikan replikasi antara server database lokal dan server database di Google Cloud dengan mengikuti petunjuk untuk software database Anda.

Hot HA di seluruh infrastruktur lokal dan Google Cloud

Jika memiliki nilai RTO dan RPO yang kecil, Anda hanya dapat mencapainya dengan menjalankan HA di seluruh lingkungan produksi dan Google Cloud secara serentak. Pendekatan ini memberi Anda pola hot, karena infrastruktur lokal dan Google Cloud menyalurkan traffic produksi.

Perbedaan utama dari pola warm ini adalah resource di kedua lingkungan berjalan dalam mode produksi dan melayani traffic produksi.

Elemen penyusun DR:

  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • Grup instance terkelola
  • Cloud Monitoring
  • Cloud Load Balancing

Diagram berikut mengilustrasikan arsitektur ini. Dengan menerapkan arsitektur ini, Anda memiliki rencana DR yang memerlukan sedikit intervensi jika terjadi bencana.

Arsitektur untuk pola hot saat produksi berada di infrastruktur lokal

Langkah-langkah berikut menjelaskan cara mengonfigurasi lingkungan:

  1. Buat Jaringan VPC
  2. Konfigurasi konektivitas antara jaringan lokal dan jaringan Google Cloud Anda.
  3. Buat gambar kustom di Google Cloud yang dikonfigurasi untuk setiap server di lingkungan produksi lokal. Setiap gambar Google Cloud harus memiliki konfigurasi yang sama dengan konfigurasi lokal yang setara.

  4. Konfigurasikan replikasi antara server database lokal dan server database di Google Cloud dengan mengikuti petunjuk untuk software database Anda.

    Banyak sistem database hanya mengizinkan satu instance database yang dapat ditulis saat Anda mengonfigurasi replikasi. Oleh karena itu, Anda mungkin perlu memastikan bahwa salah satu replika database berfungsi sebagai server hanya baca.

  5. Membuat masing-masing template instance yang menggunakan gambar untuk server aplikasi dan server web.

  6. Konfigurasikan grup instance terkelola regional untuk aplikasi dan server web.

  7. Konfigurasi health check menggunakan Cloud Monitoring.

  8. Konfigurasikan load balancing menggunakan grup instance terkelola regional yang telah dikonfigurasi sebelumnya.

  9. Konfigurasikan tugas terjadwal untuk membuat snapshot reguler dari persistent disk.

  10. Konfigurasi layanan DNS untuk mendistribusikan traffic antara lingkungan lokal Anda dan lingkungan Google Cloud.

Dengan pendekatan hibrid ini, Anda perlu menggunakan layanan DNS yang mendukung perutean berbobot ke dua lingkungan produksi sehingga Anda dapat melayani aplikasi yang sama dari keduanya.

Anda perlu mendesain sistem untuk kegagalan yang mungkin terjadi hanya di sebagian lingkungan (kegagalan sebagian). Dalam hal ini, traffic harus dialihkan ke layanan yang setara di lingkungan cadangan lainnya. Misalnya, jika server web lokal menjadi tidak tersedia, Anda dapat menonaktifkan pemilihan rute DNS ke lingkungan tersebut. Jika layanan DNS Anda mendukung health check, hal ini akan otomatis terjadi saat health check menentukan bahwa server web di salah satu lingkungan tidak dapat dijangkau.

Jika Anda menggunakan sistem database yang hanya mengizinkan satu instance yang dapat ditulis, dalam banyak kasus, sistem database akan secara otomatis mempromosikan replika hanya-baca menjadi replika yang dapat ditulisi saat heartbeat antara yang aslinya dari database yang dapat ditulis dan replika baca akan kehilangan kontak. Pastikan Anda memahami aspek replikasi database ini jika Anda perlu melakukan intervensi setelah bencana.

Anda harus menerapkan proses untuk memastikan bahwa image VM kustom di Google Cloud memiliki versi aplikasi yang sama dengan versi lokal. Gabungkan upgrade ke image kustom sebagai bagian dari siklus upgrade standar Anda, dan pastikan template Deployment Manager Anda menggunakan image kustom terbaru.

Proses failover dan tugas pasca-mulai ulang

Dalam konfigurasi yang dijelaskan di sini untuk skenario panas, bencana berarti salah satu dari dua lingkungan tidak tersedia. Tidak ada proses failover dengan cara yang sama seperti pada skenario warm atau cold, yang mengharuskan Anda memindahkan data atau pemrosesan ke lingkungan kedua. Namun, Anda mungkin perlu menangani perubahan konfigurasi berikut:

  • Jika layanan DNS tidak secara otomatis mengalihkan traffic berdasarkan kegagalan health check, Anda harus mengonfigurasi ulang pemilihan rute DNS secara manual untuk mengirim traffic ke sistem yang masih aktif.
  • Jika sistem database Anda tidak secara otomatis mempromosikan replika hanya baca menjadi replika utama yang dapat ditulisi jika terjadi kegagalan, Anda perlu melakukan intervensi untuk memastikan bahwa replika tersebut dipromosikan.

Saat lingkungan kedua sudah berjalan lagi dan dapat menangani traffic produksi, Anda perlu menyinkronkan ulang database. Karena kedua lingkungan mendukung workload produksi, Anda tidak perlu melakukan tindakan lebih lanjut untuk mengubah database mana yang utama. Setelah database disinkronkan, Anda dapat mengizinkan traffic produksi didistribusikan kembali di kedua lingkungan dengan menyesuaikan setelan DNS.

Arsitektur DR dan HA untuk produksi di Google Cloud

Saat Anda mendesain arsitektur aplikasi untuk workload produksi di Google Cloud, fitur HA di platform memiliki pengaruh langsung terhadap arsitektur DR Anda.

Cold: server aplikasi yang dapat dipulihkan

Dalam skenario cold failover, yaitu ketika Anda memerlukan satu instance server aktif, hanya satu instance yang harus menulis ke disk. Di lingkungan lokal, Anda sering menggunakan cluster aktif / pasif. Saat Anda menjalankan lingkungan production di Google Cloud, Anda dapat membuat VM dalam grup instance terkelola yang hanya menjalankan satu instance.

Elemen penyusun DR:

  • Compute Engine
  • Grup instance terkelola

Skenario cold failover ini ditampilkan dalam contoh gambar arsitektur berikut:

cold pattern<i} untuk pemulihan saat produksi dilakukan di Google Cloud" class="l10n-absolute-url-src" l10n-attrs-original-order="src,alt,class" src="https://cloud.google.com/static/architecture/images/dr-scenarios-for-apps-gcp-cold-failover.svg" />

Untuk ringkasan lengkap tentang cara men-deploy contoh skenario ini dan menguji pemulihan dari kegagalan, lihat Men-deploy server web cold yang dapat dipulihkan dengan snapshot persistent disk.

Langkah-langkah berikut menguraikan cara mengonfigurasi skenario cold failover ini:

  1. Buat Jaringan VPC
  2. Buat image VM kustom yang dikonfigurasi dengan layanan web aplikasi Anda.
    1. Konfigurasikan VM sehingga data yang diproses oleh layanan aplikasi ditulis ke persistent disk yang terpasang.
  3. Buat snapshot dari persistent disk yang terpasang.
  4. Buat template instance yang merujuk ke image VM kustom untuk server web.
    1. Mengonfigurasi skrip startup untuk membuat persistent disk dari snapshot terbaru dan untuk memasang disk. Skrip ini harus dapat memperoleh snapshot terbaru dari disk.
  5. Buat grup instance terkelola dan health check dengan ukuran target yang mereferensikan template instance.
  6. Buat tugas terjadwal untuk membuat snapshot reguler persistent disk.
  7. Konfigurasikan Load Balancer Aplikasi eksternal.
  8. Konfigurasi pemberitahuan menggunakan Cloud Monitoring untuk mengirim pemberitahuan ketika layanan gagal.

Skenario cold failover ini memanfaatkan beberapa fitur dengan ketersediaan tinggi (HA) yang tersedia di Google Cloud. Jika VM gagal, grup instance terkelola akan mencoba membuat ulang VM secara otomatis. Anda tidak perlu memulai langkah failover ini. Load Balancer Aplikasi eksternal memastikan bahwa meskipun VM pengganti diperlukan, alamat IP yang sama digunakan di depan server aplikasi. Template instance dan image kustom memastikan bahwa VM pengganti dikonfigurasi secara identik ke instance yang digantikannya.

RPO Anda ditentukan oleh snapshot terakhir yang diambil. Semakin sering Anda mengambil snapshot, semakin kecil nilai RPOnya.

Grup instance terkelola menyediakan HA secara mendalam. Grup instance terkelola menyediakan cara untuk merespons kegagalan di tingkat aplikasi atau VM. Anda tidak melakukan intervensi secara manual jika salah satu skenario tersebut terjadi. Ukuran target sebesar satu akan memastikan bahwa Anda hanya memiliki satu instance aktif yang berjalan di grup instance terkelola dan menyalurkan traffic.

Persistent disk bersifat zonal, jadi Anda harus mengambil snapshot untuk membuat ulang disk jika terjadi kegagalan zonal. Snapshot juga tersedia di seluruh region, sehingga memungkinkan Anda memulihkan disk ke region berbeda yang mirip dengan memulihkannya ke region yang sama.

Jika terjadi kegagalan zonal yang jarang terjadi, Anda harus melakukan intervensi secara manual untuk memulihkan data, seperti yang diuraikan di bagian berikutnya.

Proses failover

Jika VM gagal, grup instance terkelola akan otomatis mencoba membuat ulang VM di zona yang sama. Skrip startup dalam template instance membuat persistent disk dari snapshot terbaru dan melampirkannya ke VM baru.

Namun, grup instance terkelola dengan ukuran satu tidak dapat dipulihkan jika terjadi kegagalan zona. Jika suatu zona gagal, Anda harus bereaksi terhadap pemberitahuan Cloud Monitoring, atau platform pemantauan lainnya, saat layanan gagal dan membuat grup instance di zona lain secara manual.

Variasi pada konfigurasi ini adalah menggunakan persistent disk regional, bukan persistent disk zonal. Dengan pendekatan ini, Anda tidak perlu menggunakan snapshot untuk memulihkan persistent disk sebagai bagian dari langkah pemulihan. Namun, variasi ini menghabiskan penyimpanan dua kali lebih banyak dan Anda perlu anggaran untuk itu. Untuk men-deploy skenario alternatif ini dan menguji pemulihan dari kegagalan, lihat Men-deploy server web cold yang dapat dipulihkan dengan persistent disk regional.

Pendekatan yang Anda pilih ditentukan oleh anggaran, nilai RTO, dan RPO Anda.

Warm: failover situs statis

Jika instance Compute Engine gagal, Anda dapat mengurangi gangguan layanan dengan menyiapkan situs statis berbasis Cloud Storage dalam mode standby. Menggunakan situs statis adalah sebuah opsi jika aplikasi web Anda sebagian besar bersifat statis. Dalam skenario ini, aplikasi utama berjalan pada instance Compute Engine. Instance ini dikelompokkan ke dalam grup instance terkelola, dan grup instance berfungsi sebagai layanan backend untuk load balancer HTTPS. Load balancer HTTP mengarahkan traffic masuk ke instance sesuai dengan konfigurasi load balancer, konfigurasi setiap grup instance, dan kondisi setiap instance.

Elemen penyusun DR:

  • Compute Engine
  • Cloud Storage
  • Cloud Load Balancing
  • Cloud DNS

Diagram berikut mengilustrasikan arsitektur ini.

Arsitektur untuk failover warm ke situs statis saat produksi berada di Google Cloud

Untuk ringkasan lengkap cara men-deploy contoh skenario ini dan menguji pemulihan dari kegagalan, lihat Men-deploy server web warm yang dapat dipulihkan menggunakan Cloud DNS dengan Compute Engine dan Cloud Storage.

Langkah-langkah berikut menguraikan cara mengonfigurasi skenario ini:

  1. Buat Jaringan VPC
  2. Buat image kustom yang dikonfigurasi dengan layanan web aplikasi.
  3. Buat template instance yang menggunakan image tersebut untuk server web.
  4. Konfigurasikan grup instance terkelola untuk server web.
  5. Mengonfigurasi health check menggunakan Monitoring.
  6. Konfigurasikan load balancing menggunakan grup instance terkelola yang Anda konfigurasi sebelumnya.
  7. Buat situs statis berbasis Cloud Storage.

Dalam konfigurasi produksi, Cloud DNS dikonfigurasi untuk mengarah ke aplikasi utama ini, dan situs statis standby tidak aktif. Jika aplikasi Compute Engine tidak aktif, Anda akan mengonfigurasi Cloud DNS agar mengarah ke situs statis ini.

Proses failover

Jika server aplikasi atau server tidak berfungsi, urutan pemulihan Anda adalah mengonfigurasi Cloud DNS agar mengarah ke situs statis Anda. Diagram berikut menunjukkan arsitektur dalam mode pemulihannya:

Konfigurasi setelah failover ke situs statis saat produksi dilakukan di Google Cloud.

Saat instance Compute Engine aplikasi berjalan kembali dan dapat mendukung workload produksi, Anda membalikkan langkah pemulihan: Anda mengonfigurasi Cloud DNS agar mengarah ke load balancer yang menghadap ke instance.

Untuk pendekatan alternatif yang menggunakan Load Balancer Aplikasi eksternal, bukan Cloud DNS, untuk mengontrol failover, lihat Men-deploy server web warm yang dapat dipulihkan dengan Compute Engine dan Cloud Storage. Pola ini berguna jika Anda tidak memiliki, atau tidak ingin menggunakan, Cloud DNS.

Hot: Aplikasi web dengan ketersediaan tinggi (HA)

Pola hot saat lingkungan produksi Anda berjalan di Google Cloud adalah membangun deployment HA yang dirancang dengan baik.

Elemen penyusun DR:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

Diagram berikut mengilustrasikan arsitektur ini:

Arsitektur pola hot saat produksi di Google Cloud

Skenario ini memanfaatkan fitur dengan ketersediaan tinggi (HA) di Google Cloud. Anda tidak perlu memulai langkah-langkah failover apa pun, karena langkah tersebut akan terjadi secara otomatis jika terjadi bencana.

Seperti yang ditunjukkan pada diagram, arsitektur ini menggunakan grup instance terkelola regional bersama dengan load balancing global dan Cloud SQL. Contoh di sini menggunakan grup instance terkelola regional, sehingga instance didistribusikan di tiga zona.

Dengan pendekatan ini, Anda akan mendapatkan ketersediaan tinggi (HA). Grup instance terkelola regional menyediakan mekanisme untuk bereaksi terhadap kegagalan di tingkat aplikasi, instance, atau zona, dan Anda tidak perlu melakukan intervensi secara manual jika salah satu skenario tersebut terjadi.

Untuk mengatasi pemulihan tingkat aplikasi, sebagai bagian dari penyiapan grup instance terkelola, Anda perlu mengonfigurasi health check HTTP yang memverifikasi bahwa layanan berjalan dengan benar pada instance dalam grup tersebut. Jika health check menentukan bahwa suatu layanan telah gagal pada suatu instance, grup akan otomatis membuat ulang instance tersebut.

Untuk mengetahui langkah-langkah mendetail tentang satu cara mengonfigurasi aplikasi web dengan ketersediaan tinggi (HA) di Google Cloud, lihat Aplikasi web yang skalabel dan tangguh di Google Cloud.

Langkah selanjutnya