Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Multi-Region: pemulihan
Tes Multi-Region: pemulihan memperkenalkan kegagalan ke dalam dependensi di satu Wilayah untuk memvalidasi bahwa layanan Anda dapat memulihkan dan melayani klien dari Wilayah pemulihan dalam tujuan pemulihan Anda. Tes ini berlaku untuk kedua active/active dan active/passive arsitektur. Misalnya, Anda dapat memulai prosedur pemulihan dan mengonfirmasi pemulihan layanan Anda dalam Tujuan Waktu Pemulihan (RTO) yang Anda tentukan di Wilayah pemulihan.
Apa yang membuat tes ini unik
-
Memvalidasi pemulihan ke Wilayah lain terhadap tujuan pemulihan Anda, bukan hanya ketahanan dalam wilayah.
-
Anda memilih dependensi mana yang akan dirusak di Wilayah utama, sehingga Anda dapat berlatih deteksi dan pemulihan.
-
Tes terintegrasi dengan sakelar Wilayah ARC sehingga Anda dapat melacak detail pelaksanaan rencana dalam laporan pengujian.
Cara lulus tes ini
-
Ini adalah tes pemulihan. Hitung mundur RTO dimulai saat tindakan pengujian dimulai. Tes lulus jika semua alarm sukses kembali ke
OKstatus dalam Multi-Region RTO Anda dan tetap di sana sampai tindakan pengujian berakhir. Layanan Anda harus memiliki kebijakan ketahanan dengan Multi-Region RTO yang ditentukan.
Hal-hal yang perlu dipikirkan
-
Pilih dependensi di Wilayah terganggu yang cukup signifikan untuk memicu prosedur pemulihan Anda. Pilih dependensi keras atau titik akhir DNS yang, jika diblokir, akan merusak Wilayah itu secara berarti.
-
Tes menyuntikkan kesalahan di Wilayah yang terganggu — Anda melakukan tindakan pemulihan sendiri (misalnya, memicu rencana peral failover/ARC ihan Wilayah). Tes mengamati apakah Wilayah pemulihan Anda sehat dalam RTO Anda dengan mengevaluasi keadaan alarm.
-
Pilih alarm keberhasilan di Wilayah pemulihan yang memvalidasi lalu lintas yang melayani — atau gunakan global/application alarm tingkat yang mencerminkan pengalaman pelanggan secara keseluruhan.
-
Pertimbangkan untuk mengatur durasi lebih lama dari RTO Anda untuk memvalidasi pemulihan berkelanjutan.
-
Pastikan dependensi Anda digunakan secara aktif selama pengujian (lalu lintas mengalir ke mereka) - ini memvalidasi blok memiliki efek. Pertimbangkan untuk menambahkan alarm atau metrik yang melacak penggunaan dependensi (misalnya, jumlah permintaan atau kesalahan koneksi) untuk memverifikasi bahwa ketergantungan sedang dilakukan selama pengujian.
-
Dependensi harus menjadi titik akhir DNS yang dapat diselesaikan.
-
Memblokir dependensi yang memicu kegagalan pemeriksaan kesehatan dapat menyebabkan komputasi (misalnya, tugas Amazon ECS) diganti. Tindakan kehilangan paket tidak berlaku kembali untuk tugas penggantian dan mungkin dilaporkan gagal.
Parameter uji utama
-
Wilayah Gang guan — Wilayah di mana kesalahan disuntikkan.
-
Daerah Pemulihan — Wilayah tempat Anda mengharapkan layanan Anda pulih.
-
Durasi — Lamanya waktu tindakan pengujian dijalankan. Dibutuhkan beberapa menit lagi sesudahnya untuk mengumpulkan hasil akhir sebelum tes berakhir. Standar Multi-Region RTO Anda dari kebijakan layanan Anda ditambah 30 menit saat pertama kali Anda membuat pengujian.
-
Dependensi untuk diblokir — Pilih dependensi yang, jika diblokir, akan secara signifikan mengganggu layanan Anda dan membantu memvalidasi failover ke Wilayah lain. Secara default, ketergantungan keras yang ditemukan dengan volume kueri tertinggi dipilih sebelumnya. Jika tidak ada dependensi yang diklasifikasikan sebagai keras, tidak ada yang dipilih. Anda dapat menyesuaikan atau menambahkan dependensi secara manual berdasarkan nama domain DNS. Dependensi tambahan yang ditambahkan di sini hanya digunakan untuk pengujian ini dan tidak akan disimpan ke penemuan ketergantungan layanan. Default ini berlaku di konsol; saat menggunakan API, Anda memberikan dependensi secara eksplisit.
-
Paket Area Switch (opsional) — Melampirkan paket ARC Region Switch memungkinkan generasi Resilience Hub berikutnya menyertakan garis waktu failover aktual dalam hasil pengujian dan laporan Anda. Jika Anda menggunakan failover manual atau otomatisasi khusus, biarkan ini kosong.
Tindakan
Pengujian ini menjalankan AWS FIS tindakan berikut untuk menurunkan lalu lintas ke dependensi yang Anda pilih. Tindakan menyuntikkan kehilangan paket 100% pada instans Amazon EC2, tugas Amazon ECS (Amazon EC2 dan Fargate), dan pod Amazon EKS (Amazon EC2). Jika layanan Anda tidak memiliki sumber daya yang cocok dengan jenis target tindakan, tindakan tersebut dilewati.
catatan
Tindakan yang digunakan untuk memblokir dependensi memerlukan pengaturan tambahan: Agen SSM diinstal pada instans Amazon EC2, wadah Agen SSM dalam definisi tugas Amazon ECS Anda, atau akun layanan Kubernetes untuk pod Amazon EKS.
| Tindakan | Deskripsi |
|---|---|
aws:ssm:send-command |
Menurunkan lalu lintas dari instans Amazon EC2 ke dependensi yang dipilih. |
aws:ecs:task-network-packet-loss |
Menurunkan lalu lintas dari tugas Amazon ECS ke dependensi yang dipilih. |
aws:eks:pod-network-packet-loss |
Menurunkan lalu lintas dari pod Amazon EKS ke dependensi yang dipilih. |
Untuk melihat parameter pengujian ini dan nilai defaultnya, gunakanget-test-template.