Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
REL11-BP04 Mengandalkan bidang data dan bukan bidang kontrol selama pemulihan
Bidang kontrol menyediakan administrasi yang APIs digunakan untuk membuat, membaca, dan mendeskripsikan, memperbarui, menghapus, dan mencantumkan (CRUDL) sumber daya, sementara pesawat data menangani lalu lintas day-to-day layanan. Saat mengimplementasikan respons pemulihan atau mitigasi terhadap peristiwa yang berpotensi berdampak pada ketahanan, fokuslah pada penggunaan operasi bidang kontrol dalam jumlah minim untuk memulihkan, mengubah skala, mengembalikan, memperbaiki, atau melakukan failover layanan. Tindakan bidang data harus menggantikan aktivitas apa pun selama terjadi peristiwa degradasi ini.
Misalnya, berikut ini adalah semua tindakan bidang kontrol: meluncurkan instans komputasi baru, membuat penyimpanan blok, dan mendeskripsikan layanan antrean. Saat Anda meluncurkan instans komputasi, bidang kontrol harus melakukan beberapa tugas seperti menemukan temuan host fisik dengan kapasitas, mengalokasikan antarmuka jaringan, menyiapkan volume penyimpanan blok lokal, menghasilkan kredensial, dan menambahkan aturan keamanan. Orkestrasi bidang kontrol cenderung rumit.
Hasil yang diinginkan: Ketika sumber daya memasuki keadaan terganggu, sistem mampu pulih secara otomatis atau manual dengan mengalihkan lalu lintas dari sumber daya yang terganggu ke sumber daya yang sehat.
Anti-pola umum:
-
Ketergantungan pada perubahan DNS catatan untuk merutekan kembali lalu lintas.
-
Ketergantungan pada operasi penskalaan bidang kontrol untuk menggantikan komponen yang terganggu karena sumber daya yang disediakan tidak memadai.
-
Mengandalkan tindakan pesawat API multi-kontrol yang luas, multi layanan, untuk memulihkan kategori gangguan apa pun.
Manfaat menerapkan praktik terbaik ini: Peningkatan tingkat keberhasilan untuk remediasi otomatis dapat mengurangi waktu rata-rata pemulihan Anda dan meningkatkan ketersediaan beban kerja.
Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Sedang: Untuk jenis degradasi layanan tertentu, bidang kontrol terpengaruh. Ketergantungan pada penggunaan ekstensif bidang kontrol untuk remediasi dapat meningkatkan waktu pemulihan (RTO) dan waktu rata-rata untuk pemulihan (). MTTR
Panduan implementasi
Untuk membatasi tindakan bidang data, lakukan penilaian atas setiap layanan untuk menemukan tindakan-tindakan yang diperlukan untuk memulihkan layanan.
Manfaatkan Amazon Application Recovery Controller untuk menggeser DNS lalu lintas. Fitur-fitur ini terus memantau kemampuan aplikasi Anda untuk pulih dari kegagalan dan memungkinkan Anda untuk mengontrol pemulihan aplikasi Anda di beberapa Wilayah AWS, Availability Zone, dan di lokasi.
Kebijakan perutean Route 53 menggunakan bidang kontrol, jadi jangan mengandalkannya untuk pemulihan. Pesawat data Route 53 menjawab DNS pertanyaan dan melakukan serta mengevaluasi pemeriksaan kesehatan. Mereka didistribusikan secara global dan dirancang untuk perjanjian tingkat layanan ketersediaan 100% (SLA)
Manajemen APIs dan konsol Route 53 tempat Anda membuat, memperbarui, dan menghapus sumber daya Route 53 berjalan pada bidang kontrol yang dirancang untuk memprioritaskan konsistensi dan daya tahan yang kuat yang Anda butuhkan saat mengelola. DNS Untuk mencapai hal ini, bidang kontrol ditempatkan di satu Wilayah: AS Timur (Virginia Utara). Sementara kedua sistem dibangun agar sangat andal, pesawat kontrol tidak termasuk dalamSLA. Mungkin ada peristiwa langka di mana desain tangguh bidang data memungkinkannya untuk mempertahankan ketersediaan sedangkan bidang kontrol tidak. Untuk mekanisme failover dan pemulihan bencana, Anda harus menggunakan fungsi bidang data untuk memberikan keandalan yang sebaik mungkin.
Rancang infrastruktur komputasi Anda agar stabil secara statis agar tidak menggunakan bidang kontrol selama insiden. Misalnya, jika Anda menggunakan EC2 instans Amazon, hindari penyediaan instans baru secara manual atau instruksikan Grup Auto Scaling untuk menambahkan instance sebagai respons. Untuk tingkat ketahanan tertinggi, berikan kapasitas yang cukup di klaster yang digunakan untuk failover. Jika ambang kapasitas ini harus dibatasi, tetapkan throttle pada keseluruhan end-to-end sistem untuk membatasi lalu lintas total yang mencapai set sumber daya terbatas.
Untuk layanan seperti Amazon DynamoDB, API Amazon Gateway, load balancer, dan tanpa server AWS Lambda , menggunakan layanan tersebut memanfaatkan bidang data. Namun, membuat fungsi baru, penyeimbang beban, API gateway, atau tabel DynamoDB adalah tindakan bidang kontrol dan harus diselesaikan sebelum degradasi sebagai persiapan untuk acara dan latihan tindakan failover. Untuk AmazonRDS, tindakan bidang data memungkinkan akses ke data.
Untuk informasi selengkapnya tentang bidang data, pesawat kontrol, dan cara AWS membangun layanan untuk memenuhi target ketersediaan tinggi, lihat Stabilitas statis menggunakan Availability Zones
Pahami operasi mana yang ada di bidang data dan mana yang ada di bidang kontrol.
Langkah-langkah implementasi
Untuk setiap beban kerja yang perlu dipulihkan setelah terjadinya peristiwa degradasi, lakukan evaluasi terhadap runbook failover, desain ketersediaan tinggi, desain perbaikan otomatis, atau rencana pemulihan sumber daya HA. Identifikasi setiap tindakan yang mungkin dianggap sebagai tindakan bidang kontrol.
Pertimbangkan mengubah tindakan kontrol ke tindakan bidang data:
-
Auto Scaling (bidang kontrol) ke sumber daya EC2 Amazon yang telah diskalakan sebelumnya (bidang data)
-
Penskalaan EC2 instans Amazon (bidang kontrol) ke AWS Lambda penskalaan (bidang data)
-
Nilai desain apa pun menggunakan Kubernetes dan sifat tindakan bidang kontrol. Menambahkan pod adalah tindakan bidang data di Kubernetes. Tindakan harus dibatasi ke penambahan pod dan bukan ke penambahan simpul. Menggunakan simpul yang disediakan secara berlebihan
adalah metode yang lebih disukai untuk membatasi tindakan bidang kontrol
Pertimbangkan pendekatan alternatif yang memungkinkan tindakan-tindakan bidang data untuk memengaruhi remediasi yang sama.
-
Rute 53 Rekam perubahan (bidang kontrol) atau Pengontrol Pemulihan Aplikasi Amazon (bidang data)
-
Route 53 Pemeriksaan kondisi untuk pembaruan yang lebih otomatis
Pertimbangkan beberapa layanan di Wilayah sekunder, jika layanan sangat penting, untuk memungkinkan lebih banyak tindakan bidang kontrol dan bidang data di Wilayah yang tidak terdampak.
-
Amazon EC2 Auto Scaling atau Amazon EKS di Wilayah utama dibandingkan dengan Amazon Auto EC2 Scaling atau EKS Amazon di Wilayah sekunder dan merutekan lalu lintas ke Wilayah sekunder (aksi bidang kontrol)
-
Membuat replika baca di primer sekunder atau mencoba tindakan yang sama di Wilayah primer (tindakan bidang kontrol)
Sumber daya
Praktik-praktik terbaik terkait:
Dokumen terkait:
Video terkait:
Contoh terkait:
Alat terkait: