Pendorong utama dalam mempertimbangkan kelangsungan bisnis untuk sistem yang sangat penting adalah membantu organisasi agar menjadi tangguh dan melanjutkan operasi bisnisnya selama dan setelah peristiwa kegagalan. Dengan mereplikasi sistem dan data di beberapa region geografis dan menghindari titik tunggal kegagalan, Anda dapat meminimalkan risiko bencana alam yang memengaruhi infrastruktur lokal. Skenario kegagalan lainnya mencakup kegagalan sistem yang parah, serangan pengamanan cyber, atau bahkan error konfigurasi sistem.
Mengoptimalkan sistem untuk mengatasi kegagalan sangat penting untuk membangun kelangsungan bisnis yang efektif. Keandalan sistem dapat dipengaruhi oleh beberapa faktor, termasuk, tetapi tidak terbatas pada, performa, ketahanan, ketersediaan waktu beroperasi, keamanan, dan pengalaman pengguna. Untuk mengetahui informasi selengkapnya tentang cara merancang dan mengoperasikan layanan andal di Google Cloud, lihat pilar keandalan Framework Arsitektur Google Cloud dan elemen penyusun keandalan di Google Cloud.
Pola arsitektur ini bergantung pada deployment aplikasi yang redundan di beberapa lingkungan komputasi. Dalam pola ini, Anda men-deploy aplikasi yang sama di beberapa lingkungan komputasi dengan tujuan meningkatkan keandalan. Kelangsungan bisnis dapat didefinisikan sebagai kemampuan organisasi untuk melanjutkan fungsi atau layanan bisnis utamanya pada tingkat yang dapat diterima yang telah ditentukan setelah terjadinya peristiwa disruptif.
Disaster recovery (DR) dianggap sebagai bagian dari kelangsungan bisnis, yang secara eksplisit berfokus untuk memastikan bahwa sistem IT yang mendukung fungsi bisnis penting dapat beroperasi sesegera mungkin setelah terjadinya gangguan. Secara umum, strategi dan rencana DR sering kali membantu membentuk strategi kelangsungan bisnis yang lebih luas. Dari sudut pandang teknologi, saat Anda mulai membuat strategi pemulihan dari bencana, analisis dampak bisnis Anda harus menentukan dua metrik utama: tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO). Untuk mendapatkan panduan lebih lanjut tentang penggunaan Google Cloud untuk mengatasi pemulihan dari bencana, baca Panduan perencanaan pemulihan dari bencana.
Makin kecil nilai target RPO dan RTO, makin cepat layanan dapat pulih dari gangguan dengan kehilangan data minimal. Namun, ini menyiratkan biaya yang lebih tinggi karena artinya membangun sistem redundan. Sistem redundan yang mampu melakukan replikasi data mendekati real-time dan beroperasi pada skala yang sama setelah peristiwa kegagalan, meningkatkan kompleksitas, overhead administratif, dan biaya.
Keputusan untuk memilih strategi atau pola DR harus didorong oleh analisis dampak bisnis. Misalnya, kerugian finansial yang timbul akibat periode nonaktif selama beberapa menit saja untuk organisasi jasa keuangan dapat jauh melebihi biaya penerapan sistem DR. Namun, bisnis di industri lain mungkin mengalami periode nonaktif selama berjam-jam tanpa efek bisnis yang signifikan.
Saat Anda menjalankan sistem yang sangat penting di pusat data lokal, salah satu pendekatan DR adalah mempertahankan sistem standby di pusat data kedua di region yang berbeda. Namun, pendekatan yang lebih hemat biaya adalah menggunakan lingkungan komputasi berbasis cloud publik untuk tujuan failover. Pendekatan ini adalah pendorong utama pola hibrida kelangsungan bisnis. Dari segi biaya, cloud bisa sangat menarik karena memungkinkan Anda menonaktifkan sebagian infrastruktur DR saat tidak digunakan. Untuk mencapai solusi DR biaya yang lebih rendah, solusi cloud memungkinkan bisnis menerima potensi peningkatan nilai RPO dan RTO.
Diagram sebelumnya menggambarkan penggunaan cloud sebagai lingkungan failover atau pemulihan dari bencana pada lingkungan lokal.
Varian yang kurang umum (dan jarang diperlukan) dari pola ini adalah pola cloud kontinuitas bisnis. Dalam pola tersebut, lingkungan produksi menggunakan satu penyedia cloud dan lingkungan DR menggunakan penyedia cloud lain. Dengan men-deploy salinan workload di beberapa penyedia cloud, Anda dapat meningkatkan ketersediaan melebihi apa yang ditawarkan oleh deployment multi-region.
Mengevaluasi DR di beberapa cloud dibandingkan menggunakan satu penyedia cloud dengan region yang berbeda memerlukan analisis menyeluruh atas beberapa pertimbangan, termasuk yang berikut ini:
- Kemudahan dikelola
- Keamanan
- Kelayakan secara keseluruhan.
- Biaya
- Potensi biaya transfer data keluar dari lebih dari satu penyedia cloud dapat menjadi lebih mahal dengan komunikasi antar-cloud yang berkelanjutan.
- Mungkin terdapat volume traffic yang tinggi saat mereplikasi database.
- TCO dan biaya pengelolaan infrastruktur jaringan antar-cloud.
Jika data Anda harus tetap berada di negara Anda untuk memenuhi persyaratan peraturan, penggunaan penyedia cloud kedua yang juga tersedia di negara Anda sebagai DR dapat menjadi pilihan. Penggunaan penyedia cloud kedua tersebut mengasumsikan bahwa tidak ada opsi untuk menggunakan lingkungan lokal untuk membangun konfigurasi hybrid. Untuk menghindari arsitektur ulang solusi cloud, idealnya penyedia cloud kedua Anda harus menawarkan semua kemampuan dan layanan yang diperlukan di region.
Pertimbangan desain
- Ekspektasi DR: Target RPO dan RTO yang ingin dicapai bisnis Anda harus mendorong arsitektur DR Anda dan membangun perencanaan.
- Arsitektur solusi: Dengan pola ini, Anda perlu mereplikasi fungsi dan kemampuan yang ada di lingkungan lokal Anda untuk memenuhi ekspektasi DR Anda. Oleh karena itu, Anda perlu menilai kelayakan dan kelangsungan hosting ulang, pemfaktoran ulang, atau perancangan ulang aplikasi Anda untuk memberikan fungsi dan performa yang sama (atau lebih dioptimalkan) di lingkungan cloud.
- Desain dan build: Membangun zona landing hampir selalu merupakan prasyarat untuk men-deploy workload perusahaan di lingkungan cloud. Untuk mengetahui informasi selengkapnya, lihat Desain zona landing di Google Cloud.
Pemanggilan DR: Desain dan proses DR Anda harus mempertimbangkan pertanyaan-pertanyaan berikut:
- Apa yang memicu skenario DR? Misalnya, DR mungkin dipicu oleh kegagalan fungsi atau sistem tertentu di situs utama.
- Bagaimana failover ke lingkungan DR dipanggil? Apakah proses persetujuan manual, atau dapatkah diotomatiskan untuk mencapai target RTO yang rendah?
- Bagaimana deteksi kegagalan sistem dan mekanisme notifikasi harus dirancang untuk memanggil failover sesuai dengan RTO yang diharapkan?
- Bagaimana traffic dialihkan ke lingkungan DR setelah kegagalan terdeteksi?
Validasi jawaban Anda atas pertanyaan ini melalui pengujian.
Pengujian: Uji dan evaluasi failover secara menyeluruh untuk DR. Pastikan failover tersebut memenuhi ekspektasi RPO dan RTO Anda. Melakukan hal tersebut dapat membuat Anda lebih percaya diri untuk memanggil DR saat diperlukan. Setiap kali ada perubahan atau pembaruan baru pada proses atau solusi teknologi, lakukan pengujian lagi.
Keterampilan tim: Satu atau beberapa tim teknis harus memiliki keterampilan dan keahlian untuk membangun, mengoperasikan, dan memecahkan masalah beban kerja produksi di lingkungan cloud, kecuali jika lingkungan Anda dikelola oleh pihak ketiga.
Kelebihan
Penggunaan Google Cloud untuk kelangsungan bisnis menawarkan beberapa keuntungan:
- Karena Google Cloud memiliki banyak region di seluruh dunia yang dapat dipilih, Anda dapat menggunakannya untuk mencadangkan atau mereplikasi data ke situs yang berbeda di benua yang sama. Anda juga dapat mencadangkan atau mereplikasi data ke situs di benua lain.
- Google Cloud menawarkan kemampuan untuk menyimpan data di Cloud Storage dalam bucket dual-region atau multi-region. Data disimpan secara redundan di setidaknya dua region geografis terpisah. Data yang disimpan dalam bucket dual-region dan multi-region direplikasi di seluruh region geografis menggunakan replikasi default.
- Bucket dual-region menyediakan geo-redundansi untuk mendukung kelangsungan bisnis dan rencana DR. Selain itu, untuk mereplikasi yang lebih cepat, dengan RPO yang lebih rendah, objek yang disimpan di dual-region dapat secara opsional menggunakan replikasi turbo di seluruh region tersebut.
- Replikasi multi-region juga menyediakan redundansi di beberapa region, dengan menyimpan data Anda dalam batas geografis multi-region.
- Memberikan satu atau beberapa opsi berikut untuk mengurangi biaya modal
dan biaya operasional untuk membuat DR:
- Instance VM yang dihentikan hanya dikenai biaya penyimpanan dan jauh lebih murah daripada menjalankan instance VM. Artinya, Anda dapat meminimalkan biaya pemeliharaan sistem cold standby.
- Dengan model bayar per penggunaan Google Cloud, Anda hanya membayar untuk kapasitas penyimpanan dan komputasi yang benar-benar Anda gunakan.
- Kemampuan elastisitas, seperti penskalaan otomatis, memungkinkan Anda menskalakan atau mengecilkan lingkungan DR secara otomatis sesuai kebutuhan.
Misalnya, diagram berikut menunjukkan aplikasi yang berjalan di lingkungan lokal (produksi) yang menggunakan komponen pemulihan di Google Cloud dengan Compute Engine, Cloud SQL, dan Cloud Load Balancing. Dalam skenario ini, database telah disediakan menggunakan database berbasis VM atau menggunakan database yang dikelola Google Cloud, seperti Cloud SQL, untuk pemulihan lebih cepat dengan replikasi data berkelanjutan. Anda dapat meluncurkan VM Compute Engine dari snapshot yang telah dibuat sebelumnya untuk mengurangi biaya selama operasi normal. Dengan penyiapan ini, dan setelah peristiwa kegagalan, DNS harus mengarah ke alamat IP eksternal Cloud Load Balancing.
Agar aplikasi dapat beroperasi di cloud, Anda perlu menyediakan VM web dan aplikasi. Bergantung pada tingkat RTO dan kebijakan perusahaan yang ditargetkan, seluruh proses untuk memanggil DR, menyediakan workload di cloud, dan merutekan ulang traffic dapat diselesaikan secara manual atau otomatis.
Untuk mempercepat dan mengotomatiskan penyediaan infrastruktur, pertimbangkan untuk mengelola infrastruktur sebagai kode. Anda dapat menggunakan Cloud Build, yang merupakan layanan continuous integration, untuk menerapkan manifes Terraform secara otomatis ke lingkungan Anda. Untuk mengetahui informasi selengkapnya, lihat Mengelola infrastruktur sebagai kode dengan Terraform, Cloud Build, dan GitOps.
Praktik terbaik
Saat Anda menggunakan pola kesinambungan bisnis, pertimbangkan praktik terbaik berikut:
- Buat rencana pemulihan dari bencana yang mendokumentasikan infrastruktur Anda beserta prosedur failover dan pemulihan.
- Pertimbangkan tindakan berikut berdasarkan analisis dampak bisnis Anda serta target RPO dan RTO yang diperlukan:
- Tentukan apakah pencadangan data ke Google Cloud sudah memadai, atau apakah Anda perlu mempertimbangkan strategi DR lain (sistem cold, warm, atau hot standby).
- Tentukan layanan dan produk yang dapat Anda gunakan sebagai elemen penyusun untuk rencana DR Anda.
- Susun skenario DR yang berlaku untuk aplikasi dan data Anda sebagai bagian dari strategi DR yang Anda pilih.
- Pertimbangkan untuk menggunakan pola handover jika Anda hanya mencadangkan data. Jika tidak, pola meshed mungkin merupakan opsi yang bagus untuk mereplikasi arsitektur jaringan lingkungan yang ada.
- Minimalkan dependensi antara sistem yang berjalan di lingkungan berbeda, terutama saat komunikasi ditangani secara sinkron. Dependensi ini dapat memperlambat performa dan mengurangi ketersediaan keseluruhan.
Hindari masalah tumpah. Jika Anda mereplikasi data secara dua arah di seluruh lingkungan, Anda mungkin akan terpapar masalah split-brain. Masalah split-brain terjadi saat dua lingkungan yang mereplikasi data secara dua arah kehilangan komunikasi satu sama lain. Pemisahan ini dapat menyebabkan sistem di kedua lingkungan menyimpulkan bahwa lingkungan lain tersebut tidak tersedia dan memiliki akses eksklusif ke data. Hal ini dapat menyebabkan modifikasi data yang bertentangan. Ada dua cara umum untuk menghindari masalah {i>split-brain<i}:
- Menggunakan lingkungan komputasi ketiga. Lingkungan ini memungkinkan sistem memeriksa kuorum sebelum memodifikasi data.
Izinkan modifikasi data yang bertentangan untuk direkonsiliasi setelah konektivitas dipulihkan.
Dengan database SQL, Anda dapat menghindari masalah pemecahan masalah dengan membuat instance utama asli tidak dapat diakses sebelum klien mulai menggunakan instance utama baru. Untuk mengetahui informasi selengkapnya, lihat pemulihan dari bencana database Cloud SQL.
Pastikan sistem CI/CD dan repositori artefak tidak menjadi titik tunggal kegagalan. Saat satu lingkungan tidak tersedia, Anda tetap harus dapat men-deploy rilis baru atau menerapkan perubahan konfigurasi.
Menjadikan semua workload portabel saat menggunakan sistem standby. Semua workload harus portabel (jika didukung oleh aplikasi dan memungkinkan) agar sistem tetap konsisten di seluruh lingkungan. Pendekatan ini dapat dicapai dengan mempertimbangkan container dan Kubernetes. Dengan edisi Google Kubernetes Engine (GKE) Enterprise, Anda dapat menyederhanakan build dan operasinya.
Integrasikan deployment sistem standby ke dalam pipeline CI/CD Anda. Integrasi ini membantu memastikan bahwa versi dan konfigurasi aplikasi konsisten di seluruh lingkungan.
Pastikan perubahan DNS diterapkan secara cepat dengan mengonfigurasi DNS dengan waktu aktif yang cukup singkat sehingga Anda dapat mengalihkan pengguna ke sistem standby ketika terjadi bencana.
Pilih kebijakan DNS dan kebijakan perutean yang sesuai dengan arsitektur dan perilaku solusi Anda. Selain itu, Anda dapat menggabungkan beberapa load balancer regional dengan kebijakan perutean DNS guna membuat arsitektur load balancing global untuk berbagai kasus penggunaan, termasuk penyiapan hybrid.
Menggunakan beberapa penyedia DNS. Saat menggunakan beberapa penyedia DNS, Anda dapat:
- Tingkatkan ketersediaan serta ketahanan aplikasi dan layanan Anda.
Sederhanakan deployment atau migrasi aplikasi hybrid yang memiliki dependensi di lingkungan lokal dan cloud dengan konfigurasi DNS multi-penyedia.
Google Cloud menawarkan solusi open source berbasis octoDNS untuk membantu Anda menyiapkan dan mengoperasikan lingkungan dengan beberapa penyedia DNS. Untuk mengetahui informasi selengkapnya, lihat DNS publik multi-penyedia menggunakan Cloud DNS.
Gunakan load balancer saat menggunakan sistem standby untuk membuat failover otomatis. Perlu diingat bahwa hardware load balancer dapat gagal.
Gunakan Cloud Load Balancing, bukan load balancer hardware, untuk mendukung beberapa skenario yang terjadi saat menggunakan pola arsitektur ini. Permintaan klien internal atau permintaan klien eksternal dapat dialihkan ke lingkungan utama atau lingkungan DR berdasarkan metrik yang berbeda, seperti pemisahan traffic berdasarkan bobot. Untuk mengetahui informasi selengkapnya, baca Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.
Pertimbangkan untuk menggunakan Cloud Interconnect atau Cross-Cloud Interconnect jika volume transfer data keluar dari Google Cloud ke lingkungan lain tinggi. Cloud Interconnect dapat membantu mengoptimalkan performa konektivitas dan dapat mengurangi biaya transfer data keluar untuk traffic yang memenuhi kondisi tertentu. Untuk mengetahui informasi selengkapnya, lihat harga Cloud Interconnect.
Pertimbangkan untuk menggunakan solusi partner pilihan Anda di Google Cloud Marketplace untuk membantu memfasilitasi pencadangan data, replikasi, dan tugas lain yang memenuhi kebutuhan Anda, termasuk target RPO dan RTO.
Uji dan evaluasi skenario pemanggilan DR untuk memahami seberapa mudah aplikasi dapat pulih dari peristiwa bencana jika dibandingkan dengan nilai RTO target.
Mengenkripsi komunikasi saat transit. Untuk melindungi informasi sensitif, sebaiknya enkripsi semua komunikasi saat dalam pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas hybrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN HA melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.