Pemulihan dari bencana dengan snapshot lingkungan

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Pratinjau — Cloud Composer 3

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dalam Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Halaman ini menjelaskan cara menggunakan snapshot lingkungan untuk pemulihan dari bencana.

Definisi

Panduan ini menggunakan definisi berikut:

• Bencana adalah peristiwa saat Cloud Composer atau komponen lain yang penting untuk operasi lingkungan Anda tidak tersedia. Peristiwa ini memerlukan failover ke region dan lingkungan Cloud Composer yang berbeda. Penyebab bencana dapat berupa bencana alam atau buatan manusia, termasuk periode nonaktif wilayah Google Cloud dan pemadaman layanan di infrastruktur Anda sendiri.
• Pemulihan dari Bencana (DR), dalam konteks Cloud Composer, adalah proses pemulihan operasi lingkungan setelah terjadi bencana. Proses ini melibatkan pembuatan ulang lingkungan, mungkin di region lain. Untuk informasi selengkapnya tentang Pemulihan dari Bencana, lihat Panduan perencanaan pemulihan dari bencana.
• Lingkungan utama adalah lingkungan Cloud Composer yang ingin Anda aktifkan kemampuan DR-nya.
• Lingkungan failover adalah lingkungan Cloud Composer yang ditetapkan untuk mengambil alih aktivitas dari lingkungan utama.
• Skenario DR hangat adalah varian Disaster Recovery, tempat Anda menggunakan lingkungan failover standby, yang Anda buat sebelum bencana terjadi.
• Skenario DR dingin adalah varian Disaster Recovery, tempat Anda membuat lingkungan failover setelah terjadi bencana.
• DR lintas region adalah varian Disaster Recovery hangat atau dingin dengan lingkungan utama dan failover berada di region yang berbeda.

Tentang prosedur pemulihan dari bencana (disaster recovery)

Prosedur disaster recovery akan menyelesaikan masalah saat lingkungan utama Anda tidak dapat beroperasi (rusak atau tidak dapat diakses) karena bencana.

Prosedur ini mengasumsikan bahwa lingkungan utama Anda tidak akan diperbaiki di tempat untuk mengatasi bencana. Sebagai gantinya, Anda membuat lingkungan kedua (failover) secara berdampingan. Lingkungan ini beroperasi, bukan lingkungan utama. Pada tahap selanjutnya, Anda dapat memutuskan untuk kembali ke lingkungan utama atau terus menggunakan lingkungan failover.

Karena prosedur menggunakan lingkungan failover, perubahan akan diperkenalkan saat Anda beralih dari lingkungan utama. Perubahan antara lingkungan utama dan lingkungan failover mencakup (daftar ini tidak komprehensif):

• URL server web akan berbeda. Tindakan ini akan mengubah alamat UI Airflow dan endpoint Airflow REST API.

• URL bucket lingkungan akan berbeda.

• Konfigurasi izin akses dan jaringan mungkin perlu disesuaikan.

Jika menggunakan skenario DR hangat, Anda mengetahui nilai untuk server web, alamat bucket lingkungan, dan konfigurasi jaringan terlebih dahulu.

Sebelum memulai

• Database Airflow harus memiliki data kurang dari 20 GB untuk membuat snapshot.

• Jumlah total objek dalam folder /dags, /plugins,dan /data di bucket lingkungan harus kurang dari 100.000 untuk membuat snapshot.

• Jika Anda menggunakan mekanisme XCom untuk mentransfer file, pastikan Anda menggunakannya sesuai dengan panduan Airflow. Mentransfer file besar atau sejumlah besar file menggunakan XCom akan memengaruhi performa database Airflow dan dapat menyebabkan kegagalan saat memuat snapshot atau mengupgrade lingkungan Anda. Pertimbangkan untuk menggunakan alternatif seperti Cloud Storage untuk mentransfer data dalam volume besar.

Ringkasan persiapan

Kedua skenario DR mencakup langkah-langkah persiapan berikut:

1. Membuat lingkungan failover.

   • Dalam skenario DR warm, Anda akan terus menyediakan lingkungan ini.
   • Dalam skenario DR dingin, Anda membuat lingkungan ini hanya untuk menguji prosedur disaster recovery. Setelah menyelesaikan persiapan, Anda akan menghapus lingkungan ini, dan membuatnya lagi setelah bencana terjadi.

2. Membuat bucket untuk snapshot.

   • Bucket harus tersedia di region DR. Untuk DR lintas region, bucket snapshot harus bersifat multi-regional atau berada di region yang berbeda dengan lingkungan utama.

   • Pastikan DAG dapat mengakses resource regional.

3. Siapkan pemeliharaan DB.

4. Menyiapkan snapshot terjadwal.

5. Uji prosedur pemulihan dari bencana Anda.

Ringkasan pemulihan dari bencana

Setelah bencana terjadi:

1. (Khusus DR dingin) Buat lingkungan failover.
2. Jika memungkinkan, hentikan lingkungan utama agar tidak mengeksekusi DAG.
3. Muat snapshot dari bucket snapshot ke lingkungan penggantian.
4. Jika diperlukan, sesuaikan konfigurasi lingkungan failover.
5. Tentukan tindakan yang akan dilakukan pada lingkungan utama.

Langkah-langkah persiapan

Lakukan langkah-langkah yang diuraikan di bawah untuk menyiapkan disaster recovery bagi lingkungan Anda.

Membuat lingkungan failover

Buat lingkungan yang berfungsi sebagai lingkungan failover.

Gunakan panduan berikut:

• Lingkungan utama dan failover Anda harus menggunakan versi dan build Airflow yang sama.

  Perhatian: Meskipun dapat dilakukan, jangan lakukan failover ke build atau versi Airflow yang berbeda, karena hal ini mungkin memerlukan perubahan tambahan terkait kompatibilitas. Misalnya, dua build dari versi Airflow yang sama mungkin memiliki paket PyPI yang diinstal sebelumnya yang berbeda.

• Dalam skenario DR hangat, pastikan Anda mengupdate dan mengupgrade kedua lingkungan secara sinkron. Misalnya, jika Anda mengupgrade lingkungan utama ke build Airflow yang lebih baru, atau menginstal paket PyPI, lingkungan failover Anda juga harus memiliki perubahan ini.

• Sebaiknya buat lingkungan failover di region yang berbeda dengan lingkungan utama. Akibatnya, berbagai kemungkinan skenario bencana dapat diliput secara lebih luas, seperti bencana yang memengaruhi ketersediaan seluruh region.

• Sebaiknya gunakan Terraform untuk membuat lingkungan primer dan penggantian, sehingga keduanya memiliki konfigurasi yang konsisten. Pastikan definisi Terraform untuk lingkungan utama dan failover disinkronkan.

• Konfigurasi lingkungan failover (seperti ukuran lingkungan, jumlah penjadwal, dan izin IAM) direkomendasikan agar sesuai dengan konfigurasi lingkungan utama. Izin IAM untuk kedua lingkungan harus memberikan akses yang sesuai kepada pengguna dan snapshot.

Memeriksa ketersediaan resource

DAG dapat beroperasi pada resource eksternal, dan akses ke resource tersebut mungkin bergantung pada konfigurasi lingkungan (seperti izin yang diberikan ke akun layanan, konfigurasi jaringan, atau project lingkungan). Pastikan resource tersebut tersedia untuk lingkungan failover.

Lingkungan mungkin berinteraksi dengan beberapa resource eksternal melalui koneksi yang disimpan di Airflow. Periksa apakah resource ini harus disesuaikan di lingkungan failover dibandingkan dengan lingkungan utama.

Membuat bucket penyimpanan untuk snapshot

Buat bucket penyimpanan baru untuk snapshot lingkungan. Jangan gunakan bucket lingkungan untuk pemulihan dari bencana, karena konfigurasi untuk kebijakan retensi dan siklus proses diterapkan di tingkat bucket.

Pastikan bucket penyimpanan ini memiliki izin IAM, kebijakan retensi, dan konfigurasi siklus proses yang ditetapkan dengan cara yang mencegah penghapusan tidak disengaja atau akses tidak sah. Untuk informasi selengkapnya tentang cara mengonfigurasi bucket untuk snapshot, lihat Mengonfigurasi snapshot terjadwal.

Anda dapat:

• Buat bucket di region lain.
• Buat bucket multi-regional.

Perhatian: Jika Anda membuat bucket di region yang sama dengan lingkungan utama, beberapa skenario bencana tidak dapat ditanggung, seperti bencana yang memengaruhi ketersediaan seluruh region.

Menyiapkan pemeliharaan DB

Pastikan database Airflow tetap kecil dan dalam batas ukuran dengan menyiapkan pembersihan database. Tindakan ini akan mempercepat proses penyimpanan dan pemuatan snapshot. Database Airflow harus memiliki data kurang dari 20 GB untuk membuat snapshot.

Menyiapkan snapshot terjadwal

Siapkan snapshot terjadwal untuk lingkungan utama.

Snapshot hanya dapat dibuat di lingkungan yang sehat, sehingga snapshot harus disimpan sebelum bencana terjadi.

Untuk mengetahui informasi selengkapnya tentang cara kerja snapshot, lihat Menyimpan dan memuat snapshot lingkungan. Lihat bagian Menyimpan snapshot lingkungan dalam dokumentasi untuk mengetahui informasi tentang tempat menemukan snapshot yang disimpan.

(Opsional) Menyiapkan pemantauan untuk operasi snapshot terjadwal

Untuk snapshot terjadwal dengan frekuensi minimal sekali setiap 12 jam, Anda dapat menggunakan Cloud Monitoring untuk memberi tahu Anda saat snapshot tidak dibuat secara otomatis.

Untuk jadwal dengan frekuensi yang lebih rendah, Anda dapat menggunakan Google Cloud CLI untuk memverifikasi hasil operasi snapshot. Lihat Memverifikasi operasi simpan snapshot.

1. Di konsol Google Cloud, buka halaman Monitoring.

   Buka Monitoring

2. Di panel navigasi Monitoring, pilih Alerting.
3. ika Anda belum membuat saluran notifikasi dan ingin menerima notifikasi, klik Edit Notification Channels dan tambahkan saluran notifikasi Anda. Kembali ke halaman Alerting setelah menambahkan saluran.
4. Dari halaman Alerting, pilih Create policy.
5. Untuk memilih metrik, luaskan menu Pilih metrik, lalu lakukan tindakan berikut:
   1. Untuk membatasi menu pada entri yang relevan, masukkan Composer Snapshot ke kolom filter. Jika tidak ada hasil setelah memfilter menu, nonaktifkan tombol Hanya tampilkan resource & metrik aktif.
   2. Untuk Jenis resource, pilih Cloud Composer Environment.
   3. Untuk Kategori metrik, pilih Environment.
   4. Untuk Metrik, pilih Jumlah pembuatan snapshot.
   5. Pilih Apply.
6. Klik Tambahkan filter, lalu gunakan menu dropdown untuk menambahkan filter berikut:

   Filter	Pembanding	Nilai
   Label resource > environment_name	=	Nama lingkungan tempat Anda ingin memantau snapshot terjadwal.
   Monitor label > result	=	SUCCEEDED

7. Di bagian Transform data, tetapkan atribut berikut:
   • Untuk Periode bergulir, pilih periode pemantauan untuk pemberitahuan ini. Nilai ini memengaruhi konfigurasi nilai minimum di langkah berikutnya.

     Nilai yang direkomendasikan untuk pemantauan snapshot terjadwal: 1 hari.

   • Untuk Rolling window function, pilih delta.
8. Klik Berikutnya.
9. Setelan di halaman Konfigurasi pemicu notifikasi menentukan kapan notifikasi dipicu. Isi halaman ini dengan setelan dalam tabel berikut.
   

   Kolom	Nilai
   Condition type	Threshold
   Alert trigger	Any time series violates
   Threshold position	Below threshold
   Threshold value	Jumlah snapshot terjadwal yang Anda harapkan akan disimpan dalam jangka waktu yang dikonfigurasi sebagai Jendela bergulir untuk pemberitahuan. Hitung nilai ini menggunakan formula berikut: (rolling window in hours / schedule frequency in hours) - 1 Catatan: Mengurangi 1 jam dalam formula adalah untuk memperhitungkan waktu penyelesaian snapshot yang bervariasi. Hal ini membantu mencegah munculnya positif palsu jika snapshot terbaru masih berjalan selama pemeriksaan pemantauan. Contoh: Jika Anda menggunakan periode rolling yang direkomendasikan sebesar 1 hari, dan frekuensi jadwal Anda adalah sekali setiap 2 jam, tetapkan nilai ini ke 11 (sesuai penghitungan: 24 / 2 - 1 = 11). Jika jadwal berjalan dengan benar, dalam periode 24 jam, Anda harus memiliki minimal 11 snapshot. Jika tidak, berarti operasi snapshot tidak berhasil diselesaikan dan Cloud Monitoring memicu pemberitahuan ini.
   Condition name	Nama kustom Anda untuk kondisi.

10. Klik Berikutnya.
11. Opsional: Untuk menambahkan notifikasi ke kebijakan pemberitahuan, klik Notification channels. Dalam dialog ini, pilih satu atau beberapa saluran notifikasi dari menu, lalu klik OK.
12. Opsional: Perbarui Incident autoclose duration. Kolom ini menentukan kapan Monitoring akan menutup insiden jika data metrik tidak ada.
13. Opsional: Klik Documentation, lalu tambahkan informasi apa pun yang ingin Anda sertakan dalam pesan notifikasi.
14. Klik Alert name dan masukkan nama untuk kebijakan pemberitahuan itu.
15. Klik Create Policy.

Untuk informasi selengkapnya, lihat Kebijakan pemberitahuan.

Menguji prosedur pemulihan dari bencana

Pastikan untuk menguji prosedur pemulihan dari bencana setelah Anda menyiapkannya, lalu secara berkala setelahnya. Hal ini memungkinkan Anda mengatasi potensi masalah yang mungkin memengaruhi proses pemulihan dari bencana yang sebenarnya.

Dalam skenario DR dingin, Anda dapat menghapus lingkungan failover setelah selesai menguji prosedur disaster recovery.

Memverifikasi operasi simpan snapshot

Anda dapat menggunakan Google Cloud CLI untuk mengambil daftar operasi save snapshot dan memverifikasi apakah snapshot Anda siap untuk skenario pemulihan dari bencana.

Metode ini berguna jika Anda menyimpan snapshot lebih jarang dari setidaknya sekali setiap 12 jam. Untuk memverifikasi snapshot yang disimpan lebih sering, sebaiknya konfigurasikan pemberitahuan Cloud Monitoring. Lihat Menyiapkan pemantauan untuk operasi snapshot terjadwal.

gcloud

Mencantumkan semua operasi snapshot untuk lingkungan tertentu. Untuk referensi perintah lengkap, lihat gcloud composer operations list.

gcloud composer operations list \
    --locations LOCATION \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_ID"
    --format yaml

Ganti:

• LOCATIONS dengan daftar ID region tempat lingkungan berada
• PROJECT_ID dengan ID project tempat lingkungan berada
• ENVIRONMENT_ID dengan ID lingkungan tempat Anda ingin memeriksa operasi snapshot

Contoh:

gcloud composer operations list \
    --locations us-central1 \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/my-project/locations/us-central1/environments/my-environment"
    --format yaml

Setelah bencana terjadi

Lakukan langkah-langkah yang diuraikan di bawah setelah terjadi bencana untuk memulihkan lingkungan primer Anda.

(Khusus DR dingin) Membuat lingkungan failover

Ikuti petunjuk di bagian Membuat lingkungan failover.

Menghentikan lingkungan utama agar tidak mengeksekusi DAG

Jika memungkinkan, hentikan lingkungan utama agar tidak mengeksekusi DAG:

• Jika lingkungan utama masih dapat diakses, jeda semua DAG.
• Jika bucket lingkungan utama dapat diakses, pindahkan semua DAG dari bucket lingkungan, atau ke folder di luar /dags di bucket lingkungan utama.

Memuat snapshot ke lingkungan failover

Muat snapshot dari lingkungan utama ke lingkungan failover.

Setelah dimuat ke lingkungan failover, snapshot akan menjadwalkan dan menjalankan tugas seolah-olah tidak ada yang dijalankan oleh lingkungan utama setelah membuat snapshot. Namun, beberapa tugas tersebut mungkin telah dijalankan oleh lingkungan utama. Lingkungan failover tidak memiliki cara untuk mengenali tugas mana yang telah dieksekusi setelah membuat snapshot dan sebelum bencana. Akibatnya, beberapa tugas mungkin dijalankan dua kali (baik di lingkungan utama maupun lingkungan failover). Sebaiknya semua tugas adalah idempoten dan snapshot terjadwal dibuat setiap dua jam.

(Jika diperlukan) Sesuaikan konfigurasi lingkungan failover

Dalam beberapa kasus, Anda mungkin ingin mengubah konfigurasi lingkungan penggantian setelah memuat snapshot lingkungan utama ke dalamnya.

Misalnya, dalam skenario DR dingin, Anda mungkin perlu menggunakan kumpulan variabel lingkungan Airflow yang berbeda di lingkungan failover. Sebagai contoh lain, dalam skenario DR hangat, Anda mungkin perlu memberikan izin kepada pengguna di UI Airflow, sehingga mereka dapat mengakses lingkungan failover.

Anda dapat melakukan perubahan ini secara manual, atau menyiapkan skrip shell dengan perintah yang mengubah konfigurasi lingkungan failover dengan menjalankan perintah gcloud composer environment update.

Memutuskan apa yang harus dilakukan dengan lingkungan utama

Beberapa bencana mungkin terjadi karena lingkungan utama tidak dapat dijangkau, tetapi masih beroperasi atau tidak beroperasi dengan benar. Misalnya, Anda tidak dapat mengakses lingkungan utama melalui jaringan karena kegagalan infrastruktur. Sebagai contoh lain, lingkungan beroperasi dengan beberapa error atau dengan kapasitas yang berkurang, tetapi beberapa DAG masih dieksekusi.

Jika lingkungan asli masih berjalan, lingkungan tersebut mungkin menghasilkan biaya yang terkait langsung dengan Cloud Composer atau layanan lain yang diakses melalui DAG, meskipun lingkungan baru dibuat sebagai pengganti. Lingkungan ini masih dapat menjalankan beberapa DAG; akibatnya, beberapa operasi mungkin dijalankan dua kali: di lingkungan utama yang masih berjalan dan di lingkungan failover setelah memuat snapshot.

Jika lingkungan utama ada, tetapi tidak beroperasi dengan benar

Lingkungan utama dapat dihapus, jika semua data yang relevan telah dipulihkan. Misalnya, Anda mungkin ingin memulihkan data yang tidak disertakan dalam snapshot lingkungan, seperti konfigurasi jaringan, atau konten bucket lingkungan di luar folder /dags dan /plugins.

Jika lingkungan utama dapat diakses dan berfungsi kembali

Jika lingkungan utama tidak dapat diakses hanya untuk sementara, dan menjadi dapat diakses dan sehat kembali, Anda dapat memilih pendekatan:

• Terus gunakan lingkungan failover.
• Kembali ke lingkungan utama.

Untuk terus menggunakan lingkungan failover:

1. Jika lingkungan utama masih mengeksekusi DAG, jeda DAG sesegera mungkin.
2. Pastikan semua data yang relevan telah dipulihkan, lalu hapus lingkungan utama.
3. Ulangi langkah-langkah persiapan DR untuk lingkungan failover, seperti menyiapkan snapshot terjadwal.

Untuk kembali ke lingkungan utama:

1. Jeda semua DAG di lingkungan failover.
2. Tunggu hingga semua operasi DAG selesai di lingkungan failover, atau hentikan operasi tersebut.
3. Simpan snapshot lingkungan failover.
4. Muat snapshot ini ke lingkungan utama.
5. Hentikan jeda DAG di lingkungan utama.
6. Jika diperlukan, hapus lingkungan failover.

Langkah selanjutnya

• Mengonfigurasi snapshot terjadwal
• Membuat lingkungan