Dokumen ini adalah bagian kedua dari rangkaian yang membahas pemulihan bencana (DR) di Google Cloud. Bagian ini membahas layanan dan produk yang dapat Anda gunakan sebagai elemen penyusun untuk rencana DR produk Google Cloud dan produk yang berfungsi di seluruh platform.
Rangkaian ini terdiri dari bagian-bagian berikut:
- Panduan perencanaan pemulihan dari bencana (disaster recovery)
- Elemen penyusun pemulihan dari bencana (artikel ini)
- Skenario pemulihan dari bencana untuk data
- Skenario pemulihan dari bencana untuk aplikasi
- Merancang pemulihan dari bencana untuk workload yang dibatasi lokalitas
- Kasus penggunaan pemulihan dari bencana: aplikasi analisis data yang dibatasi lokalitas
- Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud
Pengantar
Google Cloud memiliki berbagai produk yang dapat Anda gunakan sebagai bagian dari arsitektur pemulihan dari bencana (DR). Bagian ini membahas fitur terkait DR dari produk yang paling umum digunakan sebagai elemen penyusun DR Google Cloud.
Banyak dari layanan ini memiliki fitur ketersediaan tinggi (HA). HA tidak sepenuhnya tumpang-tindih dengan DR, tetapi banyak tujuan HA juga berlaku untuk merancang rencana DR. Misalnya, dengan memanfaatkan fitur dengan ketersediaan tinggi (HA), Anda dapat merancang arsitektur yang mengoptimalkan waktu beroperasi dan yang dapat mengurangi efek kegagalan berskala kecil, seperti kegagalan VM tunggal. Untuk informasi selengkapnya tentang hubungan DR dan HA, lihat Panduan perencanaan pemulihan dari bencana (disaster recovery).
Bagian berikut menjelaskan elemen penyusun Google Cloud DR ini dan bagaimana keduanya membantu Anda menerapkan sasaran DR.
Komputasi dan penyimpanan
Compute Engine |
|
Penyimpanan Cloud |
|
GKE |
|
Compute Engine
Compute Engine menyediakan instance virtual machine (VM); mereka adalah pekerja keras Google Cloud. Selain mengonfigurasi, meluncurkan, dan memantau instance Compute Engine, umumnya Anda menggunakan berbagai fitur terkait untuk menerapkan paket DR.
Untuk skenario DR, Anda dapat mencegah penghapusan VM secara tidak sengaja dengan menyetel tanda perlindungan hapus. Hal ini sangat berguna saat Anda menghosting layanan stateful seperti database. Untuk membantu memenuhi nilai RTO dan RPO yang rendah, ikuti praktik terbaik untuk mendesain sistem yang tangguh.
Anda dapat mengonfigurasi instance dengan aplikasi yang sudah diinstal sebelumnya, lalu menyimpan konfigurasi tersebut sebagai image kustom. Image kustom Anda dapat mencerminkan RTO yang ingin Anda capai.
Template instance
Anda dapat menggunakan template instance Compute Engine untuk menyimpan detail konfigurasi VM, lalu membuat instance dari template instance yang ada. Anda dapat menggunakan template untuk meluncurkan instance sebanyak yang dibutuhkan, yang dikonfigurasi persis seperti yang diinginkan saat Anda perlu membuat lingkungan target DR. Template instance direplikasi secara global, sehingga Anda dapat membuat ulang instance di mana saja di Google Cloud dengan konfigurasi yang sama.
Anda dapat membuat template instance menggunakan image kustom atau berdasarkan instance VM yang ada.
Kami akan menjelaskan lebih lanjut penggunaan image Compute Engine di bagian menyeimbangkan konfigurasi image dan kecepatan deployment nanti dalam dokumen ini.
Grup instance terkelola
Grup instance terkelola bekerja dengan Cloud Load Balancing (akan dibahas nanti dalam dokumen ini) untuk mendistribusikan traffic ke grup instance yang dikonfigurasi secara identik yang disalin di seluruh zona. Grup instance terkelola memungkinkan fitur seperti penskalaan otomatis dan autohealing, di mana grup instance terkelola dapat menghapus dan membuat ulang instance secara otomatis.
Pemesanan
Compute Engine memungkinkan reservasi instance VM di zona tertentu, menggunakan jenis mesin kustom atau yang telah ditetapkan, dengan atau tanpa GPU tambahan atau SSD lokal. Guna memastikan kapasitas untuk beban kerja yang sangat penting bagi DR, Anda harus membuat reservasi di zona target DR. Tanpa reservasi, Anda mungkin tidak akan mendapatkan kapasitas on demand yang diperlukan untuk memenuhi batas waktu pemulihan Anda. Reservasi dapat berguna dalam skenario DR cold, warm, atau hot. Dengan API ini, Anda dapat menyimpan resource pemulihan yang tersedia untuk failover guna memenuhi kebutuhan RTO yang lebih rendah, tanpa harus mengonfigurasi dan men-deploy sepenuhnya terlebih dahulu.
Persistent disk dan snapshot
Persistent disk adalah perangkat penyimpanan jaringan tahan lama yang dapat diakses instance Anda. Keduanya tidak bergantung pada instance, sehingga Anda dapat melepas dan memindahkan persistent disk agar data tetap tersimpan walaupun Anda telah menghapus instance.
Anda dapat mengambil cadangan atau snapshot VM Compute Engine tambahan yang dapat disalin dari berbagai region dan digunakan untuk membuat ulang persistent disk jika terjadi bencana. Selain itu, Anda dapat membuat snapshot persistent disk untuk melindungi data dari kehilangan data karena error pengguna. Snapshot bersifat inkremental, dan hanya memerlukan waktu beberapa menit untuk dibuat meskipun disk snapshot Anda terpasang ke instance yang berjalan.
Persistent disk memiliki redundansi bawaan untuk melindungi data Anda dari kegagalan peralatan dan untuk memastikan ketersediaan data melalui peristiwa pemeliharaan pusat data. Persistent disk dapat berbentuk zonal atau regional. Persistent disk regional mereplikasi penulisan di dua zona dalam satu region. Jika terjadi pemadaman layanan di zona tertentu, instance VM cadangan dapat memasang persistent disk regional secara paksa di zona sekunder. Untuk mempelajari lebih lanjut, baca Opsi ketersediaan tinggi yang menggunakan persistent disk regional.
Migrasi Langsung
Migrasi Langsung membuat instance VM Anda tetap berjalan bahkan saat peristiwa sistem host terjadi, seperti update software atau hardware. Compute Engine live memigrasikan instance Anda yang sedang berjalan ke host lain di zona yang sama, dan bukannya mengharuskan VM Anda di-reboot. Dengan begitu, Google Cloud dapat melakukan pemeliharaan, yang merupakan bagian penting dalam menjaga keamanan dan keandalan infrastruktur, tanpa mengganggu VM Anda.
Alat impor disk virtual
Alat impor disk virtual memungkinkan Anda mengimpor format file termasuk VMDK, VHD, dan RAW untuk membuat mesin virtual Compute Engine baru. Dengan alat ini, Anda dapat membuat virtual machine Compute Engine yang memiliki konfigurasi yang sama dengan virtual machine lokal. Ini adalah pendekatan yang tepat ketika Anda tidak dapat mengonfigurasi image Compute Engine dari biner sumber software yang sudah diinstal di image Anda.
Cloud Storage
Cloud Storage adalah penyimpanan objek yang ideal untuk menyimpan file cadangan. Penyimpanan ini menyediakan kelas penyimpanan berbeda yang cocok untuk kasus penggunaan tertentu, seperti yang diuraikan dalam diagram berikut.
Dalam skenario DR, Nearline, Coldline, dan Archive storage memiliki kepentingan khusus. Kelas penyimpanan ini mengurangi biaya penyimpanan Anda dibandingkan dengan Penyimpanan standar. Namun, ada biaya tambahan yang terkait dengan pengambilan data atau metadata yang disimpan di kelas ini serta durasi penyimpanan minimum yang ditagihkan kepada Anda. Nearline dirancang untuk skenario pencadangan dengan akses maksimal sebulan sekali, sehingga Anda dapat melakukan pengujian stres DR secara rutin sambil menjaga biaya tetap rendah.
Nearline, Coldline, dan Archive dioptimalkan untuk akses yang jarang, dan model penetapan harga dirancang dengan mempertimbangkan hal ini. Oleh karena itu, Anda dikenai biaya untuk durasi penyimpanan minimum, dan ada biaya tambahan untuk pengambilan data atau metadata di kelas ini yang lebih besar dari durasi penyimpanan minimum untuk.
Storage Transfer Service memungkinkan Anda mengimpor data dari Amazon S3 atau sumber berbasis HTTP ke Cloud Storage. Dalam skenario DR, Anda dapat menggunakan Storage Transfer Service untuk:
- Mencadangkan data dari penyedia penyimpanan lain ke bucket Cloud Storage.
- Pindahkan data dari bucket di dual-region atau multi-region ke bucket di suatu region guna menghemat biaya penyimpanan cadangan Anda.
Filestore
Instance Filestore adalah server file NFS yang terkelola sepenuhnya untuk digunakan dengan aplikasi yang berjalan di instance Compute Engine atau cluster GKE.
Instance Filestore bersifat zona dan tidak mendukung replikasi di seluruh zona. Instance Filestore tidak tersedia jika zona tempatnya berada tidak aktif. Sebaiknya cadangkan data secara berkala dengan menyinkronkan volume Filestore ke instance Filestore di region lain menggunakan perintah gsutil rsync. Tindakan ini mengharuskan tugas dijadwalkan agar berjalan di instance Compute Engine atau cluster GKE.
Dalam skenario DR, aplikasi dapat melanjutkan akses ke volume Filestore secara cepat dengan beralih ke Filestore di region failover tanpa perlu menunggu proses pemulihan selesai. Nilai RTO dari solusi DR ini sangat bergantung pada frekuensi tugas terjadwal.
GKE
GKE Merupakan lingkungan terkelola dan siap produksi untuk men-deploy aplikasi dalam container. GKE memungkinkan Anda mengorkestrasi sistem HA, dan mencakup fitur-fitur berikut:
- Perbaikan otomatis node. Jika sebuah node gagal melakukan health check berturut-turut selama jangka waktu yang lebih lama (sekitar 10 menit), GKE akan memulai proses perbaikan untuk node tersebut.
- Pemeriksaan keaktifan. Anda dapat menentukan pemeriksaan keaktifan, yang secara berkala memberi tahu GKE bahwa pod sedang berjalan. Jika gagal dalam pemeriksaan, pod dapat dimulai ulang.
- Volume persisten. Database harus dapat bertahan selama masa aktif container. Dengan menggunakan abstraksi volume persisten yang dipetakan ke persistent disk Compute Engine, Anda dapat mempertahankan ketersediaan penyimpanan secara terpisah dari masing-masing penampung.
- Cluster multi-zona dan regional. Anda dapat mendistribusikan resource Kubernetes di beberapa zona dalam satu region.
- Gateway Multi-cluster memungkinkan Anda mengonfigurasi resource load balancing bersama di beberapa cluster GKE di berbagai region.
- Pencadangan untuk GKE memungkinkan Anda mencadangkan dan memulihkan workload di cluster GKE.
Jaringan dan transfer data
 Cloud Load Balancing |
|
Direktur Traffic |
|
Cloud DNS |
|
Cloud Interconnect
|
|
Cloud Load Balancing
Cloud Load Balancing menyediakan HA untuk Compute Engine dengan mendistribusikan permintaan pengguna di antara serangkaian instance. Anda dapat mengonfigurasi Cloud Load Balancing dengan health check yang menentukan apakah instance tersedia untuk berfungsi sehingga traffic tidak dirutekan ke instance yang gagal.
Cloud Load Balancing menyediakan satu alamat IP yang dapat diakses secara global untuk menampilkan instance Compute Engine Anda. Aplikasi Anda dapat menjalankan instance di berbagai region (misalnya, di Eropa dan AS), dan pengguna akhir akan diarahkan ke kumpulan instance terdekat. Selain menyediakan load balancing untuk layanan yang terekspos ke internet, Anda dapat mengonfigurasi load balancing internal untuk layanan Anda di balik IP load balancing pribadi alamat IP Alamat IP ini hanya dapat diakses oleh instance VM yang bersifat internal untuk Virtual Private Cloud (VPC) Anda.
Traffic Director
Dengan Traffic Director, deploy bidang kontrol traffic yang terkelola sepenuhnya untuk mesh layanan Anda. Traffic Director mengelola konfigurasi proxy layanan yang berjalan di Compute Engine dan GKE. Deploy layanan di beberapa region untuk menjadikannya memiliki ketersediaan tinggi. Traffic Director akan mengalihkan health check layanan dan memulai konfigurasi failover proxy layanan, sehingga mengalihkan traffic ke instance yang responsif.
Traffic Director juga mendukung konsep kontrol traffic lanjutan, pemutusan sirkuit, dan injeksi kesalahan. Dengan pemutusan sirkuit, Anda dapat menerapkan batas pada permintaan ke layanan tertentu, setelah itu permintaan akan dicegah mencapai layanan, sehingga mencegah layanan mengalami penurunan versi lebih lanjut. Dengan injeksi fault, Traffic Director dapat membuat penundaan atau membatalkan sebagian kecil permintaan ke layanan, sehingga Anda dapat menguji kemampuan layanan untuk bertahan dari penundaan permintaan atau permintaan yang dibatalkan.
Cloud DNS
Cloud DNS menyediakan cara terprogram untuk mengelola entri DNS sebagai bagian dari proses pemulihan otomatis. Cloud DNS menggunakan jaringan global server namaAnycast kami untuk melayani zona DNS Anda dari lokasi redundan di seluruh dunia, yang memberikan ketersediaan tinggi dan latensi yang lebih rendah untuk pengguna Anda.
Jika memilih untuk mengelola entri DNS secara lokal, Anda dapat mengaktifkan VM di Google Cloud untuk me-resolve alamat ini melalui penerusan Cloud DNS.
Cloud Interconnect
Cloud Interconnect memberikan cara untuk memindahkan informasi dari sumber lain ke Google Cloud. Kita akan membahas produk ini nanti di bagian Mentransfer data ke dan dari Google Cloud.
Pengelolaan dan pemantauan
| Dasbor status Cloud |
|
Kemampuan observasi Google Cloud |
|
Dasbor status Cloud
Dasbor Status Cloud menampilkan ketersediaan layanan Google Cloud saat ini. Anda dapat melihat status di halaman dan berlangganan feed RSS yang diperbarui setiap kali ada berita tentang suatu layanan.
Cloud Monitoring
Cloud Monitoring mengumpulkan metrik, peristiwa, dan metadata dari Google Cloud, AWS, pemeriksaan waktu beroperasi yang dihosting, instrumentasi aplikasi, serta berbagai komponen aplikasi lainnya. Anda dapat mengonfigurasi pemberitahuan untuk mengirim notifikasi ke alat pihak ketiga seperti Slack atau Pagerduty guna memberikan info terbaru yang tepat waktu tentang administrator. Cara lain untuk menggunakan Cloud Monitoring untuk DR adalah mengonfigurasi sink Pub/Sub dan menggunakan Cloud Functions untuk memicu proses otomatis sebagai respons terhadap pemberitahuan Cloud Monitoring.
Elemen penyusun DR lintas platform
Saat Anda menjalankan beban kerja di lebih dari satu platform, cara untuk mengurangi overhead operasional adalah dengan memilih alat yang berfungsi dengan semua platform yang Anda gunakan. Bagian ini membahas beberapa alat dan layanan yang tidak bergantung pada platform, sehingga mendukung skenario DR lintas platform.
Alat template deklaratif
Alat pembuatan template deklaratif memungkinkan Anda mengotomatiskan deployment infrastruktur di seluruh platform. Terraform adalah alat template deklaratif yang populer.
Alat pengelolaan konfigurasi
Untuk infrastruktur DR yang besar atau kompleks, kami merekomendasikan alat pengelolaan software yang tidak bergantung pada platform seperti Chef dan Ansible. Alat ini memastikan bahwa konfigurasi yang dapat direproduksi dapat diterapkan di mana pun beban kerja komputasi Anda berada.
Penyimpanan objek
Pola DR yang umum adalah memiliki salinan objek di penyimpanan objek di penyedia cloud yang berbeda. Salah satu alat lintas platform untuk hal ini adalah boto, yang merupakan library Python open source yang memungkinkan Anda berinteraksi dengan Amazon S3 dan Cloud Storage.
Alat Orchestrator
Container juga dapat dianggap sebagai elemen penyusun DR. Container adalah cara untuk mengemas layanan dan memperkenalkan konsistensi di seluruh platform.
Jika bekerja dengan container, Anda biasanya menggunakan orchestrator. Kubernetes tidak hanya berfungsi untuk mengelola container dalam Google Cloud (menggunakan GKE), tetapi juga menyediakan cara untuk mengorkestrasi workload berbasis container di beberapa platform. Google Cloud, AWS, dan Microsoft Azure menyediakan versi Kubernetes terkelola.
Untuk mendistribusikan traffic ke cluster Kubernetes yang berjalan di berbagai platform cloud, Anda dapat menggunakan layanan DNS yang mendukung data berbobot dan menggabungkan health check.
Anda juga perlu memastikan bahwa Anda dapat menarik image ke lingkungan target. Artinya, Anda harus dapat mengakses registry image Anda jika terjadi bencana. Opsi bagus yang juga tidak bergantung pada platform adalah Artifact Registry.
Transfer data
Transfer data adalah komponen penting dari skenario DR lintas platform. Pastikan Anda mendesain, menerapkan, dan menguji skenario DR lintas platform menggunakan maket realistis yang sesuai dengan skenario transfer data DR. Kami membahas skenario transfer data di bagian berikutnya.
Pola untuk DR
Bagian ini membahas beberapa pola paling umum untuk arsitektur DR berdasarkan elemen penyusun yang telah dibahas sebelumnya.
Mentransfer data ke dan dari Google Cloud
Aspek penting dari rencana DR Anda adalah seberapa cepat data dapat ditransfer ke dan dari Google Cloud. Hal ini penting jika rencana DR Anda didasarkan pada pemindahan data dari infrastruktur lokal ke Google Cloud atau dari penyedia cloud lain ke Google Cloud. Bagian ini membahas layanan jaringan dan Google Cloud yang dapat memastikan throughput yang baik.
Saat Anda menggunakan Google Cloud sebagai situs pemulihan untuk beban kerja yang berada di infrastruktur lokal atau di lingkungan cloud lain, pertimbangkan item utama berikut:
- Bagaimana cara terhubung ke Google Cloud?
- Berapa banyak bandwidth yang tersedia antara Anda dan penyedia interkoneksi?
- Berapa bandwidth yang disediakan langsung oleh penyedia ke Google Cloud?
- Data lain apa yang akan ditransfer menggunakan link tersebut?
Jika Anda menggunakan koneksi internet publik untuk mentransfer data, throughput jaringan tidak dapat diprediksi karena dibatasi oleh kapasitas dan perutean ISP. ISP mungkin menawarkan SLA terbatas, atau tidak ada sama sekali. Di sisi lain, koneksi ini memiliki biaya yang relatif rendah.
Cloud Interconnect menyediakan beberapa opsi untuk terhubung ke Google dan Google Cloud:
- Cloud VPN memungkinkan pembuatan tunnel VPN IPsec antara jaringan VPC Google Cloud dan jaringan target. Traffic yang beralih di antara dua jaringan tersebut dienkripsi oleh satu gateway VPN, lalu didekripsi oleh gateway VPN lainnya. VPN dengan ketersediaan tinggi (HA) memungkinkan Anda membuat koneksi VPN dengan ketersediaan tinggi dengan SLA 99,99%, ditambah penyiapan yang lebih sederhana dibandingkan dengan pembuatan VPN redundan.
- Peering langsung menyediakan hop jaringan minimal ke alamat IP publik Google. Anda dapat menggunakan peering langsung untuk bertukar traffic internet antara jaringan Anda dan edge point (PoP) Google.
- Dedicated Interconnect menyediakan koneksi fisik langsung antara jaringan lokal Anda dan jaringan Google. Layanan ini menyediakan SLA beserta throughput yang lebih konsisten untuk transfer data berukuran besar. Sirkuit berukuran 10 Gbps atau 100 Gbps dan dihentikan di salah satu fasilitas kolokasi Google.
Dengan bandwidth yang lebih besar, Anda dapat mengurangi waktu yang diperlukan untuk mentransfer data dari infrastruktur lokal ke Google Cloud. Tabel berikut mengilustrasikan peningkatan kecepatan saat mengupgrade dari 10 Gbps menjadi 100 Gbps.
- Partner Interconnect memberikan kemampuan yang mirip dengan Dedicated Interconnect, tetapi pada kecepatan sirkuit kurang dari 10 Gbps. Lihat Penyedia layanan yang didukung.
Diagram berikut memberikan panduan tentang metode transfer yang akan digunakan, bergantung pada jumlah data yang perlu Anda transfer ke Google Cloud.
Anda dapat menggunakan kalkulator waktu transfer untuk memahami berapa lama waktu yang mungkin diperlukan untuk suatu transfer, mengingat ukuran set data yang Anda pindahkan dan bandwidth yang tersedia untuk transfer tersebut. Untuk informasi selengkapnya tentang transfer data sebagai bagian dari perencanaan DR, lihat Mentransfer set data besar.
Menyeimbangkan konfigurasi image dan kecepatan deployment
Saat Anda mengonfigurasi image mesin untuk men-deploy instance baru, pertimbangkan efek konfigurasi Anda terhadap kecepatan deployment. Ada kompromi antara jumlah prakonfigurasi image, biaya pemeliharaan image, dan kecepatan deployment. Misalnya, jika image mesin dikonfigurasi secara minimal, instance yang menggunakannya akan memerlukan lebih banyak waktu untuk diluncurkan, karena harus mendownload dan menginstal dependensi. Di sisi lain, jika image mesin Anda sangat dikonfigurasi, instance yang menggunakannya akan diluncurkan lebih cepat, tetapi Anda harus mengupdate image lebih sering. Waktu yang diperlukan untuk meluncurkan instance yang beroperasi penuh akan memiliki korelasi langsung dengan RTO Anda.
Mempertahankan konsistensi image mesin di seluruh lingkungan hybrid
Jika menerapkan solusi hybrid (lokal ke cloud atau cloud ke cloud), Anda perlu menemukan cara untuk mempertahankan konsistensi VM di seluruh lingkungan produksi.
Jika image yang dikonfigurasi sepenuhnya diperlukan, pertimbangkan hal seperti Packer, yang dapat membuat image mesin identik untuk beberapa platform. Anda dapat menggunakan skrip yang sama dengan file konfigurasi khusus platform. Dalam kasus Packer, Anda dapat menempatkan file konfigurasi di kontrol versi untuk melacak versi yang di-deploy dalam produksi.
Sebagai opsi lainnya, Anda dapat menggunakan alat pengelolaan konfigurasi, seperti Chef, Puppet, Ansible, atau Saltstack untuk mengonfigurasi instance dengan perincian yang lebih baik, membuat image dasar, image yang dikonfigurasi secara minimal, atau image yang dikonfigurasi sepenuhnya sebagai diperlukan. Untuk pembahasan cara menggunakan alat ini secara efektif, lihat Zero-to-Deploy dengan Chef di Google Cloud.
Anda juga dapat mengonversi dan mengimpor gambar yang ada secara manual, seperti Amazon AMI, image Virtualbox, dan disk image RAW ke Compute Engine.
Menerapkan penyimpanan bertingkat
Pola penyimpanan bertingkat biasanya digunakan untuk pencadangan, dengan cadangan terbaru yang berada di penyimpanan yang lebih cepat, dan Anda secara perlahan memigrasikan cadangan lama ke penyimpanan yang berbiaya lebih rendah (tetapi lambat). Ada dua cara untuk menerapkan pola menggunakan Cloud Storage, bergantung pada asal data Anda—di Google Cloud atau secara lokal. Dalam kedua kasus tersebut, Anda akan memigrasikan objek di antara bucket dengan kelas penyimpanan yang berbeda, biasanya dari kelas penyimpanan Standard hingga Nearline yang lebih rendah.
Jika data sumber Anda dibuat secara lokal, implementasinya akan terlihat mirip dengan diagram berikut:
Atau, Anda dapat mengubah kelas penyimpanan objek di bucket menggunakan aturan siklus proses objek untuk mengotomatiskan perubahan pada class objek.
Mempertahankan alamat IP yang sama untuk instance pribadi
Pola yang umum adalah mempertahankan satu instance VM yang aktif. Jika VM harus diganti, penggantinya harus terlihat seolah-olah itu adalah VM asli. Oleh karena itu, alamat IP yang digunakan klien untuk terhubung dengan instance baru harus tetap sama.
Konfigurasi yang paling sederhana adalah mengatur grup instance terkelola yang mempertahankan tepat satu instance. Grup instance terkelola ini terintegrasi dengan load balancer internal (pribadi) yang memastikan bahwa alamat IP yang sama digunakan di depan instance, terlepas dari apakah itu image asli atau pengganti.
Partner teknologi
Google memiliki ekosistem partner tangguh yang mendukung kasus penggunaan pencadangan dan DR dengan Google Cloud. Secara khusus, kami melihat pelanggan yang menggunakan solusi partner untuk melakukan hal berikut:
- Cadangkan data dari infrastruktur lokal ke Google Cloud. Dalam hal ini, Cloud Storage terintegrasi sebagai target penyimpanan untuk sebagian besar platform pencadangan lokal. Anda dapat menggunakan pendekatan ini untuk mengganti plester dan peralatan penyimpanan lainnya.
- Mengimplementasikan rencana DR yang beralih dari infrastruktur lokal ke Google Cloud. Partner kami dapat membantu menghilangkan pusat data sekunder dan menggunakan Google Cloud sebagai situs DR.
- Mengimplementasikan DR dan pencadangan untuk beban kerja berbasis cloud.
Untuk mengetahui informasi selengkapnya tentang solusi partner, lihat halaman Partners di situs Google Cloud.
Langkah selanjutnya
- Baca tentang Geografi dan region Google Cloud.
Baca artikel lain dalam rangkaian DR ini:
- Panduan perencanaan pemulihan dari bencana (disaster recovery)
- Skenario pemulihan dari bencana untuk data
- Skenario pemulihan dari bencana untuk aplikasi
- Merancang pemulihan dari bencana untuk workload yang dibatasi lokalitas
- Kasus penggunaan pemulihan dari bencana: aplikasi analisis data yang dibatasi lokalitas
- Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud
Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.