Praktik terbaik untuk kontrol perutean di ARC - Pengontrol Pemulihan Aplikasi Amazon (ARC)

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik terbaik untuk kontrol perutean di ARC

Kami merekomendasikan praktik terbaik berikut untuk pemulihan dan kesiapan failover untuk kontrol perutean di. ARC

Topik

Jaga agar AWS kredensil yang dibangun khusus dan berumur panjang tetap aman dan selalu dapat diakses

Dalam skenario pemulihan bencana (DR), pertahankan ketergantungan sistem seminimal mungkin dengan menggunakan pendekatan sederhana untuk mengakses AWS dan melakukan tugas pemulihan. Buat IAMkredensil berumur panjang khusus untuk tugas DR, dan simpan kredensialnya dengan aman di brankas fisik lokal atau brankas virtual, untuk diakses bila diperlukan. DenganIAM, Anda dapat mengelola kredenal keamanan secara terpusat, seperti kunci akses, dan izin untuk akses ke sumber daya. AWS Untuk tugas non-DR, kami menyarankan Anda untuk terus menggunakan akses federasi, menggunakan AWS layanan seperti AWS Single Sign-On.

Untuk melakukan tugas failover ARC dengan bidang data klaster pemulihanAPI, Anda dapat melampirkan ARC IAM kebijakan ke pengguna. Untuk mempelajari selengkapnya, lihat Contoh kebijakan berbasis identitas di Amazon Application Recovery Controller () ARC.

Pilih TTL nilai yang lebih rendah untuk DNS catatan yang terlibat dalam failover

Untuk DNS catatan yang mungkin perlu Anda ubah sebagai bagian dari mekanisme failover Anda, terutama catatan yang diperiksa kesehatan, menggunakan TTL nilai yang lebih rendah adalah tepat. Pengaturan 60 atau 120 detik adalah pilihan umum untuk skenario ini. TTL

Pengaturan DNS TTL (waktu untuk hidup) memberi tahu DNS resolver berapa lama untuk menyimpan catatan sebelum meminta yang baru. Ketika Anda memilihTTL, Anda membuat trade-off antara latensi dan keandalan, dan responsif terhadap perubahan. Dengan catatan yang lebih pendek, DNS resolver melihat pembaruan TTL pada catatan lebih cepat karena TTL menentukan bahwa mereka harus melakukan kueri lebih sering.

Untuk informasi selengkapnya, lihat Memilih TTL nilai untuk DNS catatan dalam Praktik terbaik untuk Amazon Route 53 DNS.

Batasi waktu klien tetap terhubung ke titik akhir Anda

Saat Anda menggunakan kontrol perutean untuk berpindah dari satu Wilayah AWS ke yang lain, mekanisme yang digunakan Amazon Application Recovery Controller (ARC) untuk memindahkan lalu lintas aplikasi Anda adalah DNS pembaruan. Pembaruan ini menyebabkan semua koneksi baru diarahkan menjauh dari lokasi yang rusak.

Namun, klien dengan koneksi terbuka yang sudah ada sebelumnya mungkin terus membuat permintaan terhadap lokasi yang rusak sampai klien terhubung kembali. Untuk memastikan pemulihan yang cepat, kami sarankan Anda membatasi jumlah waktu klien tetap terhubung ke titik akhir Anda.

Jika Anda menggunakan Application Load Balancer, Anda dapat menggunakan keepalive opsi untuk mengonfigurasi berapa lama koneksi berlanjut. Untuk informasi selengkapnya, lihat durasi keepalive HTTP klien di Panduan Pengguna Application Load Balancer.

Secara default, Application Load Balancers menetapkan nilai durasi keepalive HTTP klien menjadi 3600 detik, atau 1 jam. Kami menyarankan agar Anda menurunkan nilai agar sesuai dengan sasaran waktu pemulihan untuk aplikasi Anda, misalnya, 300 detik. Saat Anda memilih waktu durasi keepalive HTTP klien, pertimbangkan bahwa nilai ini adalah pertukaran antara menghubungkan kembali lebih sering secara umum, yang dapat memengaruhi latensi, dan lebih cepat memindahkan semua klien dari AZ atau Wilayah yang terganggu.

Tandai atau kode keras lima titik akhir cluster Regional dan kontrol perutean Anda ARNs

Kami menyarankan Anda menyimpan salinan lokal titik akhir kluster ARC Regional Anda, di bookmark atau disimpan dalam kode otomatisasi yang Anda gunakan untuk mencoba lagi titik akhir Anda. Selama peristiwa kegagalan, Anda mungkin tidak dapat mengakses beberapa API operasi, termasuk ARC API operasi yang tidak di-host di cluster pesawat data yang sangat andal. Anda dapat membuat daftar titik akhir untuk ARC cluster Anda dengan menggunakan operasi. DescribeClusterAPI

Pilih salah satu titik akhir Anda secara acak untuk memperbarui status kontrol perutean Anda

Kontrol perutean menyediakan lima titik akhir Regional untuk memastikan ketersediaan tinggi, bahkan ketika menghadapi kegagalan. Untuk mencapai ketahanan penuh mereka, penting untuk memiliki logika coba lagi yang dapat menggunakan kelima titik akhir yang diperlukan. Untuk informasi tentang menggunakan contoh kode dengan AWS SDK, termasuk contoh untuk mencoba titik akhir klaster, lihatContoh kode untuk Application Recovery Controller menggunakan AWS SDKs.

Gunakan bidang data yang sangat andal API untuk membuat daftar dan memperbarui status kontrol perutean, bukan konsol

Menggunakan bidang ARC dataAPI, lihat kontrol dan status perutean Anda dengan ListRoutingControlsoperasi dan perbarui status kontrol perutean untuk mengarahkan lalu lintas untuk failover dengan operasi. UpdateRoutingControlState Anda dapat menggunakan AWS CLI (seperti dalam contoh ini) atau kode yang Anda tulis menggunakan salah satu AWS SDKs. ARCmenawarkan keandalan ekstrim dengan API di bidang data gagal selama lalu lintas. Kami merekomendasikan menggunakan API alih-alih mengubah status kontrol perutean di. AWS Management Console

Connect ke salah satu endpoint kluster Regional Anda ARC untuk menggunakan bidang API data. Jika titik akhir tidak tersedia, coba sambungkan ke titik akhir cluster lain.

Jika aturan keselamatan memblokir pembaruan status kontrol perutean, Anda dapat memotongnya untuk membuat pembaruan dan gagal atas lalu lintas. Untuk informasi selengkapnya, lihat Mengesampingkan aturan keselamatan untuk mengubah rute lalu lintas.

Uji failover dengan ARC

Uji failover secara teratur dengan kontrol ARC perutean, untuk gagal dari tumpukan aplikasi utama Anda ke tumpukan aplikasi sekunder. Penting untuk memastikan bahwa ARC struktur yang Anda tambahkan selaras dengan sumber daya yang benar di tumpukan Anda, dan semuanya berfungsi seperti yang Anda harapkan. Anda harus menguji ini setelah Anda mengatur ARC untuk lingkungan Anda, dan terus menguji secara berkala, sehingga lingkungan failover Anda siap, sebelum Anda mengalami situasi kegagalan di mana Anda memerlukan sistem sekunder Anda untuk aktif dan berjalan cepat untuk menghindari downtime bagi pengguna Anda.