Pemberitahuan AWS satu tunnel: kapan benar-benar penting

Pemberitahuan AWS Health yang menyatakan satu tunnel mati biasanya datang ketika tidak ada yang tampak rusak. Justru karena itulah pemberitahuan itu diabaikan. Pemberitahuan ini tidak menggambarkan gangguan; ia menggambarkan keadaan redundansi yang bertahan melewati jendela pengamatan AWS. Apakah Anda bertindak bergantung pada apa yang dapat ditanggung desain Anda, bukan pada bagaimana dasbor terasa.

Apa yang sebenarnya diukur pemberitahuan itu

Setiap koneksi Site-to-Site memiliki dua tunnel, yang berakhir di endpoint AWS berbeda. Dokumentasi pemantauan AWS menyarankan mengonfigurasi keduanya untuk redundansi dan mengangkat notifikasi ketika salah satunya tetap mati selama periode yang didokumentasikan. Periode itu penting, karena fluktuasi singkat dan kehilangan permanen terlihat identik dalam satu grafik.

Baca telemetri per tunnel, bukan status keseluruhan koneksi. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' mengembalikan status dan pesan untuk setiap tunnel, dan itulah bukti yang menjadi dasar pemberitahuan.

Tiga kondisi yang menentukan respons Anda

Telusuri ketiganya sebelum memutuskan apakah ini tiket atau angkat bahu.

Pertama, dapatkah tunnel yang bertahan membawa beban, termasuk batas bandwidth apa pun dan prefiks yang diiklankannya? Kedua, apakah failover benar-benar terjadi, mengingat tunnel kedua yang mati sejak dibuat tidak pernah terbukti naik? Ketiga, apakah perubahan terencana Anda berikutnya akan menurunkan kedua tunnel sekaligus, yang mengubah peringatan kosmetik menjadi masalah jendela pemeliharaan. Jika ada jawaban tidak atau tidak diketahui, pemberitahuan itu adalah temuan nyata.

Jika ketiganya terbukti baik, tuliskan mengapa hal itu dapat ditoleransi dan lanjutkan. Catatan itu lebih berharga daripada perdebatan kuartal depan.

Apa yang tidak dibuktikan peer cadangan

Gateway pelanggan dengan peer cadangan yang dikonfigurasi bukan bukti bahwa AWS melihat dua tunnel yang sehat. Sisi pelanggan dapat menyimpan peer dingin yang memerlukan negosiasi baru, dan itu bisa menjadi desain yang sah. Namun itu tetap bukan pengamatan yang sama dengan dua tunnel yang hidup.

Dua router fisik juga tidak memperbaiki kasus sebaliknya. Ketika kedua tunnel berakhir di satu perangkat atau keluar melalui satu uplink, redundansi hanya ada di atas kertas.

Sesuaikan perubahan dengan radius dampaknya

Dokumentasi dokumentasi penggantian endpoint AWS memisahkan kasus-kasusnya, dan perbedaannya mudah terlewat. Pembaruan yang dikelola AWS diterapkan ke satu tunnel pada satu waktu. Perubahan yang dimulai pelanggan pada gateway target, gateway pelanggan, atau opsi koneksi membuat kedua tunnel tidak tersedia selama endpoint pengganti disediakan.

Mengubah opsi pada satu tunnel adalah kasus ketiga dengan dampak tersendiri yang dinyatakan: tunnel itu tidak tersedia selama pembaruannya sendiri dan yang lain tetap berjalan.

Buktikan alternatifnya sebelum Anda membutuhkannya

Jadwalkan pengujian alih-alih menunggu peristiwa. Turunkan tunnel yang sehat di dalam jendela pemeliharaan, pastikan alternatifnya bernegosiasi, lalu pastikan lalu lintas nyata melintasinya di kedua arah. Periksa perutean balik serta status tunnel, karena ketidakcocokan fase kedua membuat tunnel tetap naik dan beban kerja mati. Ukur waktu transisi saat Anda berada di sana.

Simpan pemberitahuan, keluaran telemetri, dan rencana perubahan dalam satu catatan. Catatan itu mengubah pemberitahuan kuartal depan menjadi tinjauan dua menit alih-alih perdebatan tentang apakah seseorang pernah menguji cadangan.