Pemulihan dari bencana dengan snapshot lingkungan

Managed Airflow (Gen 3) | Managed Airflow (Gen 2) | Managed Airflow (Legacy Gen 1)

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

Definisi

Panduan ini menggunakan definisi berikut:

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

Tentang prosedur pemulihan dari bencana

Prosedur pemulihan dari bencana memecahkan masalah saat lingkungan utama Anda menjadi tidak 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) berdampingan. Lingkungan ini beroperasi sebagai pengganti lingkungan utama. Pada tahap selanjutnya, Anda dapat memutuskan untuk kembali ke lingkungan utama atau terus menggunakan lingkungan failover.

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

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

• URL bucket lingkungan akan berbeda.

• Konfigurasi izin jaringan dan akses mungkin perlu disesuaikan.

Jika menggunakan skenario DR hangat, Anda akan 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 jumlah besar.

Ringkasan persiapan

Kedua skenario DR mencakup langkah-langkah persiapan berikut:

1. Buat lingkungan failover.

   • Dalam skenario DR hangat, Anda akan menjaga lingkungan ini tetap tersedia.
   • Dalam skenario DR dingin, Anda hanya membuat lingkungan ini untuk menguji prosedur pemulihan dari bencana. Setelah menyelesaikan persiapan, Anda akan menghapus lingkungan ini, dan membuatnya lagi setelah terjadi bencana.

2. Buat 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. Siapkan snapshot terjadwal.

5. Uji prosedur pemulihan dari bencana Anda.

Ringkasan pemulihan dari bencana

Setelah terjadi bencana:

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

Langkah-langkah persiapan

Lakukan langkah-langkah yang diuraikan di bawah untuk menyiapkan pemulihan dari bencana untuk lingkungan Anda.

Membuat lingkungan failover

Buat lingkungan yang bertindak sebagai lingkungan failover.

Gunakan panduan berikut:

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

• 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. Dengan demikian, berbagai kemungkinan skenario bencana dapat dicakup, seperti bencana yang memengaruhi ketersediaan seluruh region.

• Sebaiknya gunakan Terraform untuk membuat lingkungan utama dan failover, 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) sebaiknya 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 lingkungan, konfigurasi jaringan, atau project). 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 pada tingkat bucket.

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

Anda dapat:

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

Menyiapkan pemeliharaan DB

Jaga database Airflow tetap kecil dan dalam batas ukuran dengan menyiapkan pembersihan database. Dengan demikian, proses penyimpanan dan pemuatan snapshot akan lebih cepat. 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 terjadi bencana.

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 frekuensi yang lebih rendah, Anda menggunakan Google Cloud CLI untuk memverifikasi hasil operasi snapshot. Lihat Memverifikasi operasi penyimpanan snapshot.

1. Di Google Cloud Konsol, buka halaman Monitoring.

   Buka Monitoring

2. Di panel navigasi Monitoring, pilih notificationsPemberitahuan.
3. Jika 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 Pemberitahuan, pilih Buat kebijakan.
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 Lingkungan Cloud Composer.
   3. Untuk Kategori metrik, pilih Lingkungan.
   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.
   Label monitor > hasil	=	SUCCEEDED

7. Di bagian Transform data, tetapkan atribut berikut:
   • Untuk Rolling window, pilih jendela pemantauan untuk notifikasi ini. Nilai ini memengaruhi konfigurasi nilai minimum pada 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. Lengkapi halaman ini dengan setelan di tabel berikut.
   

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

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 Nama pemberitahuan dan masukkan nama untuk kebijakan pemberitahuan itu.
15. Klik Create Policy.

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 dapat memengaruhi proses pemulihan dari bencana yang sebenarnya.

Dalam skenario DR dingin, Anda dapat menghapus lingkungan failover setelah selesai menguji prosedur pemulihan dari bencana.

Memverifikasi operasi penyimpanan snapshot

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

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

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

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 terjadi bencana

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

(DR dingin saja) Membuat lingkungan failover

Ikuti petunjuk di bagian Membuat lingkungan failover.

Menghentikan lingkungan utama agar tidak menjalankan DAG

Jika memungkinkan, hentikan lingkungan utama agar tidak menjalankan 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 snapshot 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 dijalankan setelah membuat snapshot dan sebelum terjadi bencana. Akibatnya, beberapa tugas mungkin dijalankan dua kali (di lingkungan utama dan failover). Sebaiknya semua tugas bersifat idempoten dan snapshot terjadwal dibuat setiap dua jam.

(Jika diperlukan) Menyesuaikan konfigurasi lingkungan failover

Dalam beberapa kasus, Anda mungkin ingin mengubah konfigurasi lingkungan failover 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 gcloud composer environment update perintah.

Memutuskan tindakan yang akan dilakukan pada 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 dijalankan.

Jika lingkungan asli masih berjalan, lingkungan tersebut mungkin akan menimbulkan biaya yang terkait langsung dengan Managed Airflow 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 sehat kembali

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

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

Untuk terus menggunakan lingkungan failover:

1. Jika lingkungan utama masih menjalankan DAG, jeda DAG sesegera mungkin.
2. Pastikan semua data yang relevan 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 DAG selesai berjalan di lingkungan failover, atau hentikan.
3. Simpan snapshot lingkungan failover.
4. Muat snapshot ini ke lingkungan utama.
5. Batalkan jeda DAG di lingkungan utama.
6. Jika diperlukan, hapus lingkungan failover.

Langkah berikutnya

• Mengonfigurasi snapshot terjadwal
• Membuat lingkungan