Pemulihan dari bencana dengan snapshot lingkungan

Cloud Composer 1 | Cloud Composer 2

Halaman ini menjelaskan cara menggunakan snapshot lingkungan untuk pemulihan bencana.

Definisi

Panduan ini menggunakan definisi berikut:

  • Disaster adalah peristiwa ketika 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 bersifat alami atau buatan manusia, termasuk periode nonaktif region Google Cloud dan pemadaman layanan di infrastruktur Anda sendiri.
  • Pemulihan dari Bencana (DR), dalam konteks Cloud Composer, adalah proses pemulihan operasi lingkungan setelah terjadinya bencana. Proses ini melibatkan pembuatan ulang lingkungan, mungkin di region lain. Untuk informasi selengkapnya tentang Pemulihan dari Bencana (Disaster Recovery), lihat Panduan perencanaan pemulihan dari bencana.
  • Lingkungan utama adalah lingkungan Cloud Composer yang Anda inginkan untuk mengaktifkan kemampuan DR.
  • Lingkungan failover adalah lingkungan Cloud Composer yang ditetapkan untuk mengambil alih aktivitas dari lingkungan utama.
  • Skenario DR hangat adalah varian Pemulihan dari Bencana (Disaster Recovery), di mana Anda menggunakan lingkungan failover standby, yang Anda buat sebelum terjadi bencana.
  • Skenario Cold DR adalah varian dari Disaster Recovery, di mana Anda membuat lingkungan failover setelah terjadi bencana.
  • DR lintas region adalah varian Pemulihan dari Bencana yang bersifat warm atau cold, yaitu lingkungan utama dan failover berada di region yang berbeda.

Tentang prosedur pemulihan dari bencana (disaster recovery)

Prosedur pemulihan dari bencana memecahkan 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 untuk mengatasi bencana. Sebagai gantinya, Anda membuat lingkungan kedua (failover) secara berdampingan. Lingkungan ini beroperasi, bukan lingkungan utama. Pada tahap berikutnya, Anda mungkin memutuskan untuk kembali ke lingkungan utama atau tetap menggunakan lingkungan failover.

Karena prosedur ini menggunakan lingkungan failover, perubahan akan diperkenalkan saat Anda beralih dari lingkungan utama. Perubahan antara lingkungan primer dan failover meliputi (daftarnya 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 jaringan dan akses mungkin memerlukan penyesuaian.

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

Sebelum memulai

  • Cloud Composer mendukung snapshot terjadwal pada versi 2.0.32 dan yang lebih baru. Snapshot lingkungan didukung dalam 2.0.9 dan versi yang lebih baru.

Ringkasan persiapan

Kedua skenario DR mencakup langkah-langkah persiapan berikut:

  1. Buat lingkungan failover.

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

  2. Membuat bucket untuk snapshot.

    • Bucket harus tersedia di wilayah DR. Untuk DR lintas region, bucket snapshot harus multiregional 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 (disaster recovery) Anda.

Ringkasan pemulihan dari bencana

Setelah bencana terjadi:

  1. (Khusus DR Cold) Buat lingkungan failover.
  2. Jika memungkinkan, hentikan lingkungan primer agar tidak menjalankan DAG.
  3. Memuat snapshot dari bucket snapshot ke lingkungan failover.
  4. Jika perlu, sesuaikan konfigurasi lingkungan failover.
  5. Tentukan apa yang harus dilakukan dengan lingkungan utama.

Langkah-langkah persiapan

Lakukan langkah-langkah yang diuraikan di bawah ini 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 yang sama antara Cloud Composer dan Airflow.

  • Dalam skenario DR warm, pastikan Anda mengupdate dan mengupgrade kedua lingkungan secara sinkron. Misalnya, jika Anda mengupgrade lingkungan primer ke versi Cloud Composer 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. Sebagai hasilnya, berbagai kemungkinan skenario bencana dapat ditangani, seperti bencana yang memengaruhi ketersediaan seluruh wilayah.

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

  • Konfigurasi lingkungan failover (seperti ukuran lingkungan, jumlah penjadwal, dan izin IAM) direkomendasikan agar sesuai dengan konfigurasi lingkungan primer. 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 dapat 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

Membuat bucket penyimpanan baru untuk snapshot lingkungan. Jangan gunakan bucket lingkungan untuk pemulihan dari bencana, karena konfigurasi untuk kebijakan retensi dan siklus proses diterapkan pada level 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 tanpa izin. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi bucket untuk snapshot, baca Mengonfigurasi snapshot terjadwal.

Anda dapat:

  • Buat bucket di region yang berbeda.
  • Buat bucket multiregional.

Menyiapkan pemeliharaan DB

Pastikan database metadata Airflow tetap kecil dengan mengeksekusi DAG pemeliharaan database. Tindakan ini akan mempercepat proses penyimpanan dan pemuatan snapshot. Database metadata Airflow harus memiliki data kurang dari 20 Gb untuk mendukung snapshot.

Menyiapkan snapshot terjadwal

Menyiapkan 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 frekuensi yang lebih rendah, gunakan Google Cloud CLI untuk memverifikasi hasil operasi snapshot. Lihat Memverifikasi operasi penyimpanan 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 Lingkungan Cloud Composer.
    3. Untuk Kategori metrik, pilih Lingkungan.
    4. Untuk Metric, pilih Snapshot creation count.
    5. Pilih Apply.
  6. Klik Tambahkan filter, dan gunakan menu dropdown untuk menambahkan filter berikut:
    Filter Pembanding Nilai
    Label resource > environment_name = Nama lingkungan tempat Anda ingin memantau snapshot terjadwal.
    Pantau label > hasil = SUCCEEDED

  7. Di bagian Mentransformasi 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 day.

    • Untuk Rolling window function, pilih delta.
  8. Klik Next.
  9. Setelan di halaman Konfigurasi pemicu notifikasi menentukan kapan notifikasi dipicu. Lengkapi 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 ingin Anda simpan dalam jangka waktu yang dikonfigurasi sebagai Rolling window untuk pemberitahuan.

    Hitung nilai ini menggunakan rumus berikut:

    (rolling window in hours / schedule frequency in hours) - 1

    Catatan: Mengurangi 1 jam dalam formula akan 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 berjalan yang direkomendasikan, yaitu 1 hari, dan frekuensi jadwal adalah setiap 2 jam sekali, tetapkan nilai ini ke 11 (sesuai penghitungan: 24 / 2 - 1 = 11).

    Jika jadwal Anda berjalan dengan benar, dalam periode 24 jam Anda akan memiliki minimal 11 snapshot. Jika tidak, berarti operasi snapshot tidak berhasil diselesaikan dan Cloud Monitoring memicu pemberitahuan ini.

    Condition name Nama kustom untuk kondisi tersebut.
  10. Klik Next.
  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 mengetahui informasi selengkapnya, lihat Kebijakan pemberitahuan.

Menguji prosedur pemulihan dari bencana (disaster recovery) Anda

Pastikan untuk menguji prosedur pemulihan dari bencana (disaster recovery) setelah menyiapkannya, lalu secara berkala setelahnya. Hal ini memungkinkan Anda mengatasi potensi masalah yang dapat mempengaruhi proses pemulihan dari bencana (disaster recovery) yang sebenarnya.

Dalam skenario cold DR, 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 menyimpan snapshot dan memverifikasi apakah snapshot Anda siap untuk skenario pemulihan dari bencana (disaster recovery).

Metode ini berguna jika Anda lebih jarang menyimpan snapshot, 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 Anda 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 wilayah 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 ini setelah bencana terjadi untuk memulihkan lingkungan utama Anda.

(Khusus DR Cold) Membuat lingkungan failover

Ikuti petunjuk di bagian Membuat lingkungan failover.

Menghentikan lingkungan primer agar tidak menjalankan DAG

Jika memungkinkan, hentikan lingkungan primer agar tidak menjalankan DAG:

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

Memuat snapshot ke lingkungan failover

Memuat snapshot dari lingkungan utama ke lingkungan failover.

Setelah dimuat ke lingkungan failover, snapshot menjadwalkan dan menjalankan tugas seolah-olah tidak ada yang dijalankan oleh lingkungan utama setelah membuat snapshot. Namun, beberapa tugas tersebut mungkin telah dieksekusi 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 dibuat setiap dua jam.

(Jika diperlukan) Sesuaikan konfigurasi lingkungan failover

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

Misalnya, dalam skenario DR cold, Anda mungkin perlu menggunakan kumpulan variabel lingkungan Airflow yang berbeda di lingkungan failover. Sebagai contoh lainnya, dalam skenario DR yang 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 primer tidak dapat dijangkau tetapi masih beroperasi atau tidak beroperasi dengan benar. Misalnya, Anda tidak dapat mengakses lingkungan primer melalui jaringan karena kegagalan infrastruktur. Sebagai contoh lain, lingkungan beroperasi dengan beberapa error atau dengan kapasitas yang lebih rendah, tetapi beberapa DAG masih dijalankan.

Jika lingkungan asli masih berjalan, lingkungan tersebut dapat menimbulkan 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 primer ada, tetapi tidak beroperasi dengan benar

Lingkungan utama dapat dihapus, jika semua data yang relevan 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 primer dapat diakses dan kembali sehat

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

  • Tetap gunakan 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 primer:

  1. Menjeda semua DAG di lingkungan failover.
  2. Tunggu hingga semua proses DAG selesai di lingkungan failover, atau hentikan.
  3. Simpan snapshot lingkungan failover.
  4. Muat snapshot ini ke lingkungan utama.
  5. Lanjutkan DAG di lingkungan primer.
  6. Jika perlu, hapus lingkungan failover.

Langkah selanjutnya