Opsi pemulihan bencana di cloud
Strategi pemulihan bencana yang tersedia bagi Anda dalam AWS dapat dikategorikan secara luas menjadi empat pendekatan, mulai dari biaya rendah dan kompleksitas rendah dalam membuat cadangan hingga strategi yang lebih kompleks menggunakan sejumlah Wilayah aktif. Penting untuk secara rutin menguji strategi pemulihan bencana Anda sehingga Anda memiliki keyakinan dalam menjalankannya, saat strategi ini diperlukan.
Gambar 6 - Strategi pemulihan bencana
Untuk peristiwa bencana berdasarkan gangguan atau kehilangan satu pusat data fisik untuk beban kerja yang dirancang dengan baik
Pencadangan dan pemulihan
Pencadangan dan pemulihan adalah pendekatan yang cocok untuk mengurangi kehilangan atau kerusakan data. Pendekatan ini juga dapat digunakan untuk mengurangi bencana regional dengan mereplikasi data ke Wilayah AWS lainnya, atau untuk memitigasi kurangnya redundansi untuk beban kerja yang di-deploy ke Zona Ketersediaan tunggal. Selain data, Anda harus men-deploy ulang infrastruktur, konfigurasi, dan kode aplikasi di Wilayah pemulihan. Untuk memungkinkan infrastruktur di-deploy kembali dengan cepat tanpa kesalahan, Anda harus selalu men-deploy infrastruktur sebagai kode (IAC) menggunakan layanan seperti AWS CloudFormation
Gambar 7 - Arsitektur pencadangan dan pemulihan
Layanan AWS
Data beban kerja Anda akan memerlukan strategi pencadangan yang berjalan secara berkala atau terus-menerus. Seberapa sering Anda menjalankan cadangan Anda akan menentukan titik pemulihan yang dapat dicapai (yang harus selaras untuk memenuhi RPO Anda). Cadangannya juga harus menawarkan cara untuk dipulihkan ke titik waktu saat cadangan tersebut dibuat. Cadangan dengan pemulihan titik waktu (PITR) tersedia melalui layanan dan sumber daya berikut:
Untuk Amazon Simple Storage Service (Amazon S3), Anda dapat menggunakan Amazon S3 Cross-Region Replication (CRR)
AWS Backup
-
Instans Amazon EC2
-
Basis data Amazon Relational Database Service (Amazon RDS)
(termasuk basis data Amazon Aurora ) -
Tabel Amazon DynamoDB
-
Sistem file Amazon Elastic File System (Amazon EFS)
-
Volume AWS Storage Gateway
-
Amazon FSx for Windows File Server
dan Amazon FSx for Lustre
AWS Backup mendukung penyalinan cadangan di seluruh Wilayah, misalnya ke Wilayah pemulihan bencana.
Sebagai strategi pemulihan bencana tambahan untuk data Amazon S3 Anda, aktifkan versioning objek S3. Versioning objek melindungi data Anda di S3 dari konsekuensi tindakan penghapusan atau modifikasi dengan mempertahankan versi asli sebelum tindakan tersebut. Versioning objek dapat menjadi mitigasi yang berguna untuk bencana jenis kesalahan manusia. Jika Anda menggunakan replikasi S3 untuk mencadangkan data ke wilayah DR Anda, maka, secara default, ketika objek dihapus dalam bucket sumber, Amazon S3 menambahkan delete marker di bucket sumber saja. Pendekatan ini melindungi data di Wilayah DR dari penghapusan berniat jahat di wilayah sumber.
Selain data, Anda juga harus mencadangkan konfigurasi dan infrastruktur yang diperlukan untuk men-deploy kembali beban kerja Anda dan memenuhi Sasaran Waktu Pemulihan (RTO). AWS CloudFormation
Setiap data yang tersimpan di Wilayah pemulihan bencana sebagai cadangan harus dipulihkan pada saat failover. AWS Backup menawarkan kemampuan pemulihan, tetapi saat ini tidak memungkinkan pemulihan terjadwal atau otomatis. Anda dapat menerapkan pemulihan otomatis ke wilayah DR menggunakan SDK AWS untuk memanggil API AWS Backup. Anda dapat menyiapkannya sebagai tugas yang berulang secara rutin atau memicu pemulihan setiap kali pencadangan selesai. Gambar berikut menunjukkan contoh pemulihan otomatis menggunakan Amazon Simple Notification Service (Amazon SNS)
Gambar 8 - Memulihkan dan menguji cadangan
catatan
Strategi pencadangan Anda harus menyertakan pengujian cadangan Anda. Lihat bagian Menguji Pemulihan Bencana untuk informasi lebih lanjut. Lihat AWS Well-Architected Lab: Menguji Pencadangan dan Pemulihan Data
Pilot light
Dengan pendekatan pilot light, Anda mereplikasi data Anda dari satu Wilayah ke Wilayah lainnya dan menyediakan salinan infrastruktur beban kerja inti Anda. Sumber daya yang diperlukan untuk mendukung replikasi data dan cadangan, seperti basis data dan penyimpanan objek, selalu aktif. Elemen lain, seperti server aplikasi, dimuat dengan kode aplikasi dan konfigurasi, tetapi dimatikan dan hanya digunakan selama pengujian atau ketika failover pemulihan bencana dipanggil. Berbeda dengan pendekatan pencadangan dan pemulihan, infrastruktur inti Anda selalu tersedia dan Anda selalu memiliki opsi untuk menyediakan lingkungan produksi skala penuh dengan mengaktifkan dan menskalakan keluar server aplikasi Anda.
Gambar 9 - Arsitektur pilot light
Pendekatan pilot light meminimalkan biaya pemulihan bencana yang berkelanjutan dengan meminimalkan sumber daya aktif, dan menyederhanakan pemulihan pada saat bencana karena semua persyaratan infrastruktur inti sudah terpenuhi. Opsi pemulihan ini mengharuskan Anda untuk mengubah pendekatan deployment Anda. Anda perlu membuat perubahan infrastruktur inti ke setiap Wilayah dan men-deploy perubahan beban kerja (konfigurasi, kode) secara bersamaan ke setiap Wilayah. Langkah ini dapat disederhanakan dengan mengotomatisasi deployment Anda dan menggunakan infrastruktur sebagai kode (IAC) untuk men-deploy infrastruktur di sejumlah akun dan Wilayah (deployment infrastruktur penuh ke Wilayah utama dan deployment infrastruktur yang berskala rendah/dimatikan ke wilayah DR). Sebaiknya Anda menggunakan akun yang berbeda per Wilayah untuk memberikan tingkat isolasi sumber daya dan keamanan tertinggi (jika kredensial yang mengalami kebocoran keamanan juga merupakan bagian dari rencana pemulihan bencana Anda).
Dengan pendekatan ini, Anda juga harus mengurangi dampak bencana data. Replikasi data berkelanjutan melindungi Anda dari sebagian jenis bencana, tetapi mungkin tidak melindungi Anda dari kerusakan atau pemusnahan data kecuali jika strategi Anda juga mencakup versioning data yang disimpan atau opsi untuk pemulihan titik waktu (PITR). Anda dapat mencadangkan data yang direplikasi di Wilayah bencana untuk membuat cadangan point-in-time di Wilayah yang sama.
Layanan AWS
Selain menggunakan layanan AWS yang tercakup dalam bagian Pencadangan dan Pemulihan untuk membuat cadangan point-in-time, pertimbangkan juga layanan berikut untuk strategi pilot light Anda.
Untuk pilot light, replikasi data terus-menerus ke basis data dan penyimpanan data aktif di wilayah DR adalah pendekatan terbaik untuk RPO rendah (jika digunakan di samping pencadangan point-in-time yang dibahas sebelumnya). AWS menyediakan replikasi data asinkron lintas wilayah yang berkelanjutan untuk data menggunakan layanan dan sumber daya berikut:
Dengan replikasi berkelanjutan, versi data Anda segera tersedia di Wilayah DR Anda. Waktu replikasi aktual dapat dipantau menggunakan fitur layanan seperti S3 Replication Time Control (S3 RTC) untuk objek S3 dan fitur manajemen basis data global Amazon Aurora.
Ketika melakukan failover untuk menjalankan beban kerja baca/tulis Anda dari Wilayah pemulihan bencana, Anda harus mempromosikan replika baca RDS untuk menjadi instans utama. Untuk instans DB selain Aurora, prosesnya membutuhkan waktu beberapa menit untuk selesai, termasuk rebooting. Untuk Cross-Region Replication (CRR) dan failover dengan RDS, penggunaan basis data global Amazon Aurora memberikan beberapa keuntungan. Basis data global menggunakan infrastruktur khusus yang membuat basis data Anda sepenuhnya tersedia untuk melayani aplikasi Anda, dan dapat mereplikasi ke Wilayah sekunder dengan latensi standar di bawah satu detik (dan dalam Wilayah AWS, jauh lebih rendah dari 100 milidetik). Dengan basis data global Amazon Aurora, jika Wilayah utama Anda mengalami penurunan atau gangguan performa, Anda dapat mempromosikan salah satu wilayah sekunder untuk mengambil tanggung jawab baca/tulis dalam waktu kurang dari 1 menit bahkan jika terjadi gangguan regional yang menyeluruh. Promosi ini bisa otomatis dan tidak ada reboot.
Versi yang berskala rendah dari infrastruktur beban kerja inti Anda dengan sumber daya yang lebih sedikit atau lebih kecil harus di-deploy di Wilayah DR Anda. Dengan menggunakan AWS CloudFormation, Anda dapat menentukan infrastruktur Anda dan men-deploy-nya secara konsisten di seluruh akun AWS dan di seluruh Wilayah AWS. AWS CloudFormation menggunakan parameter semu yang telah ditetapkan untuk mengidentifikasi akun AWS dan Wilayah AWS tempat layanan ini digunakan. Oleh karena itu, Anda dapat menerapkan logika kondisi di templat CloudFormation Anda untuk men-deploy hanya versi berskala rendah dari infrastruktur Anda di Wilayah DR. Untuk deployment instans EC2, Amazon Machine Image (AMI) menyediakan informasi seperti konfigurasi perangkat keras dan perangkat lunak yang diinstal. Anda dapat menerapkan alur Image Builder yang membuat AMI yang Anda butuhkan dan menyalinnya ke Wilayah utama dan cadangan Anda. Ini membantu memastikan bahwa golden AMI ini memiliki semua yang Anda butuhkan untuk men-deploy ulang atau menskalakan keluar beban kerja Anda di wilayah baru, jika terjadi peristiwa bencana. Instans Amazon EC2 digunakan dalam konfigurasi berskala rendah (lebih sedikit instans daripada di Wilayah utama Anda). Anda dapat menggunakan hibernasi untuk mengalihkan instans EC2 ke dalam status berhenti yang tidak mengharuskan Anda membayar biaya EC2, Anda hanya membayar penyimpanan yang digunakan. Untuk memulai instans EC2, Anda dapat membuat skrip menggunakan AWS Command Line Interface (CLI)
Untuk konfigurasi aktif/siaga seperti pilot light, semua lalu lintas awalnya pergi ke Wilayah utama dan beralih ke Wilayah pemulihan bencana jika Wilayah utama tidak lagi tersedia. Ada dua opsi manajemen lalu lintas yang perlu dipertimbangkan dengan menggunakan layanan AWS. Opsi pertama adalah menggunakan Amazon Route 53
Pilihan kedua adalah dengan menggunakan AWS Global Accelerator
CloudEndure Disaster Recovery
CloudEndure Disaster Recovery
Gambar 10 - CloudEndure Disaster Recovery
Warm standby
Pendekatan warm standby berfokus untuk memastikan bahwa ada salinan lingkungan produksi Anda yang berskala rendah, namun berfungsi penuh, di Wilayah lain. Pendekatan ini memperluas konsep pilot light dan mengurangi waktu pemulihan karena beban kerja Anda selalu aktif di Wilayah lain. Pendekatan ini juga memungkinkan Anda untuk lebih mudah melakukan pengujian atau menerapkan pengujian berkelanjutan untuk meningkatkan kepercayaan pada kemampuan Anda untuk pulih dari bencana.
Gambar 11 - Arsitektur warm standby
Catatan: Perbedaan antara pilot light dan warm standby terkadang sulit dimengerti. Keduanya mencakup sebuah lingkungan di Wilayah DR Anda dengan salinan aset Wilayah utama Anda. Perbedaannya adalah bahwa pilot light tidak dapat memproses permintaan tanpa tindakan tambahan yang diambil terlebih dahulu, sedangkan warm standby dapat menangani lalu lintas (pada tingkat kapasitas yang berkurang) dengan segera. Pendekatan pilot light mengharuskan Anda untuk “menghidupkan” server, mungkin men-deploy infrastruktur tambahan (non-inti), dan menaikkan skala, sedangkan Warm Standby hanya mengharuskan Anda untuk menaikkan skala (semuanya sudah di-deploy dan berjalan). Gunakan kebutuhan RTO dan RPO Anda untuk membantu Anda memilih di antara pendekatan ini.
Layanan AWS
Semua layanan AWS yang tercakup dalam pencadangan dan pemulihan dan pilot light juga digunakan dalam warm standby untuk pencadangan data, replikasi data, perutean lalu lintas aktif/siaga, dan deployment infrastruktur termasuk instans EC2.
AWS Auto Scaling
Multi-lokasi aktif/aktif
Anda dapat menjalankan beban kerja Anda secara bersamaan di sejumlah Wilayah sebagai bagian dari strategi multi-lokasi aktif/aktif atau hot standby aktif/pasif. Multi-lokasi aktif/aktif melayani lalu lintas dari semua wilayah tempat strategi ini di-deploy, sedangkan hot standby melayani lalu lintas hanya dari satu wilayah, dan Wilayah lainnya hanya digunakan untuk pemulihan bencana. Dengan pendekatan multi-lokasi aktif/aktif, pengguna dapat mengakses beban kerja Anda di Wilayah mana pun tempat strategi ini di-deploy. Pendekatan ini adalah pendekatan yang paling kompleks dan mahal untuk pemulihan bencana, tetapi dapat mengurangi waktu pemulihan Anda mendekati nol untuk sebagian besar bencana dengan pilihan dan implementasi teknologi yang benar (namun kerusakan data mungkin akan memerlukan cadangan, yang biasanya menghasilkan titik pemulihan non-nol). Hot standby menggunakan konfigurasi aktif/pasif yang hanya mengarahkan pengguna ke satu wilayah, dan wilayah DR tidak mengambil lalu lintas. Sebagian besar pelanggan menemukan bahwa jika mereka akan menyiapkan lingkungan penuh di Wilayah kedua, masuk akal untuk menggunakannya dengan konfigurasi aktif/aktif. Atau, jika Anda tidak ingin menggunakan kedua Wilayah untuk menangani lalu lintas pengguna, maka Warm Standby menawarkan pendekatan yang lebih ekonomis dan secara operasional tidak kompleks.
Gambar 12 - Arsitektur multi-lokasi aktif/aktif (ubah satu jalur Aktif menjadi Tidak Aktif untuk hot standby)
Dengan multi-lokasi aktif/aktif, karena beban kerja berjalan di lebih dari satu Wilayah, tidak akan ada failover yang diperlukan dalam skenario ini. Pengujian pemulihan bencana dalam hal ini akan berfokus pada bagaimana beban kerja bereaksi terhadap kehilangan suatu Wilayah: Apakah lalu lintas dialihkan jauh dari Wilayah yang gagal? Dapatkah Wilayah lain menangani semua lalu lintas? Pengujian untuk bencana data juga diperlukan. Pencadangan dan pemulihan masih diperlukan dan harus diuji secara teratur. Perlu juga dicatat bahwa waktu pemulihan untuk bencana data yang mencakup kerusakan, penghapusan, atau obfuskasi data akan selalu lebih besar dari nol dan titik pemulihan akan selalu berada di titik tertentu sebelum bencana ditemukan. Jika kompleksitas dan biaya tambahan dari pendekatan multi-lokasi aktif/aktif (atau hot standby) diperlukan untuk mempertahankan waktu pemulihan hampir nol, maka upaya tambahan harus dilakukan untuk menjaga keamanan dan mencegah kesalahan manusia agar dapat mengurangi bencana manusia.
Layanan AWS
Semua layanan AWS yang tercakup dalam pencadangan dan pemulihan, pilot light, dan warm standby juga digunakan di sini untuk pencadangan data point-in-time, replikasi data, perutean lalu lintas aktif/aktif, dan deployment dan penskalaan infrastruktur termasuk instans EC2.
Untuk skenario aktif/pasif yang dibahas sebelumnya (Pilot Light dan Warm Standby), Amazon Route 53 dan AWS Global Accelerator dapat digunakan untuk merutekan lalu lintas jaringan ke wilayah aktif. Untuk strategi aktif/aktif di sini, kedua layanan ini juga memungkinkan definisi kebijakan yang menentukan pengguna mana yang dialihkan ke titik akhir regional aktif tertentu. Dengan AWS Global Accelerator, Anda menetapkan dial lalu lintas untuk mengontrol persentase lalu lintas yang diarahkan ke setiap titik akhir aplikasi. Amazon Route 53 mendukung pendekatan persentase ini, dan juga sejumlah kebijakan lain yang tersedia termasuk yang berbasis geoproksimitas dan latensi. Global Accelerator secara otomatis memanfaatkan jaringan server edge AWS yang luas, untuk melakukan onboarding lalu lintas ke tulang punggung jaringan AWS sesegera mungkin, sehingga menghasilkan latensi permintaan yang lebih rendah.
Replikasi data dengan strategi ini memungkinkan RPO mendekati nol. Layanan AWS, seperti basis data global Aurora , menggunakan infrastruktur khusus yang membuat basis data Anda tersedia sepenuhnya untuk melayani aplikasi, dan dapat mereplikasi ke satu wilayah sekunder dengan latensi standar di bawah satu detik. Dengan strategi aktif/pasif, penulisan hanya terjadi pada Wilayah utama. Perbedaan dengan aktif/aktif adalah merancang bagaimana menangani penulisan untuk setiap Wilayah aktif. Biasanya pembacaan pengguna dirancang agar disajikan dari Wilayah yang terdekat, yang dikenal sebagai read local. Dengan penulisan, Anda memiliki beberapa opsi:
-
Strategi write global akan merutekan semua penulisan ke satu Wilayah. Jika Wilayah itu gagal, Wilayah lain akan dipromosikan untuk menerima penulisan. Basis data global Aurora sangat cocok untuk write global, karena mendukung sinkronisasi dengan replika baca di seluruh Wilayah, dan Anda dapat mempromosikan salah satu Wilayah sekunder untuk mengambil tanggung jawab baca/tulis dalam waktu kurang dari 1 menit.
-
Strategi write local merutekan penulisan ke Wilayah terdekat (seperti pembacaan). Tabel global Amazon DynamoDB memungkinkan strategi seperti itu, sehingga memungkinkan pembacaan dan penulisan dari setiap wilayah, tempat tabel global Anda di-deploy. Tabel global Amazon DynamoDB menggunakan rekonsiliasi penulis terakhir diprioritaskan jika ada pembaruan yang bersamaan.
-
Strategi write partitioned menetapkan penulisan ke Wilayah tertentu berdasarkan kunci partisi (seperti ID pengguna) untuk menghindari konflik penulisan. Replikasi Amazon S3 yang dikonfigurasi secara dua arah
dapat digunakan untuk kasus ini, dan saat ini mendukung replikasi antara dua Wilayah. Saat menerapkan pendekatan ini, pastikan untuk mengaktifkan sinkronisasi modifikasi replika pada kedua bucket A dan B untuk mereplikasi perubahan metadata seperti daftar kontrol akses (ACL) objek, tag objek, atau kunci objek pada objek yang direplikasi. Anda juga dapat mengonfigurasi apakah akan mereplikasi delete marker di antara bucket di Wilayah aktif Anda. Selain replikasi, strategi Anda juga harus menyertakan pencadangan point-in-time untuk melindungi terhadap peristiwa kerusakan atau pemusnahan data.
AWS CloudFormation adalah alat yang ampuh untuk menegakkan infrastruktur yang di-deploy secara konsisten di antara akun AWS di sejumlah Wilayah AWS. AWS CloudFormation StackSets memperluas fungsionalitas ini dengan memungkinkan Anda membuat, memperbarui, atau menghapus tumpukan CloudFormation di sejumlah akun dan Wilayah dengan satu operasi. Meskipun AWS CloudFormation menggunakan YAML atau JSON untuk mendefinisikan Infrastruktur sebagai Kode (IaC), AWS Cloud Development Kit (AWS CDK)