Notis AWS satu terowong: bila ia benar-benar penting

Notis AWS Health yang menyatakan satu terowong mati biasanya tiba apabila tiada apa yang kelihatan rosak. Itulah sebabnya ia diabaikan. Notis itu tidak menerangkan gangguan; ia menerangkan keadaan redundansi yang berterusan melepasi tetingkap pemerhatian AWS. Sama ada anda bertindak bergantung pada apa yang dapat ditanggung oleh reka bentuk anda, bukan pada rupa papan pemuka.

Apa yang sebenarnya diukur oleh notis itu

Setiap sambungan Site-to-Site mempunyai dua terowong, yang berakhir di titik akhir AWS yang berbeza. Dokumentasi pemantauan AWS mengesyorkan kedua-duanya dikonfigurasikan untuk redundansi dan menaikkan pemberitahuan apabila satu kekal mati selama tempoh yang didokumenkan. Tempoh itu penting, kerana turun naik singkat dan kehilangan kekal kelihatan sama dalam satu graf.

Baca telemetri setiap terowong dan bukan keadaan keseluruhan sambungan. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' mengembalikan status dan mesej untuk setiap terowong, dan itulah bukti yang menjadi asas notis.

Tiga syarat yang menentukan tindak balas anda

Teliti ketiga-tiganya sebelum memutuskan sama ada ini tiket atau angkat bahu.

Pertama, bolehkah terowong yang tinggal menanggung beban, termasuk sebarang had lebar jalur dan awalan yang diiklankannya? Kedua, adakah failover benar-benar berlaku, memandangkan terowong kedua yang mati sejak penciptaan tidak pernah terbukti naik? Ketiga, adakah perubahan terancang anda seterusnya akan menurunkan kedua-dua terowong serentak, yang mengubah amaran kosmetik menjadi masalah tetingkap penyelenggaraan. Jika mana-mana jawapan tidak atau tidak diketahui, notis itu ialah penemuan sebenar.

Jika ketiga-tiganya terbukti baik, catat mengapa ia boleh diterima dan teruskan. Nota itu lebih bernilai daripada perdebatan suku tahun depan.

Apa yang tidak dibuktikan oleh peer sandaran

Get laluan pelanggan dengan peer sandaran yang dikonfigurasikan bukan bukti bahawa AWS melihat dua terowong yang sihat. Pihak pelanggan boleh menyimpan peer sejuk yang memerlukan rundingan baharu, dan itu boleh menjadi reka bentuk yang sah. Namun ia tetap bukan pemerhatian yang sama seperti dua terowong hidup.

Dua penghala fizikal juga tidak membetulkan kes sebaliknya. Apabila kedua-dua terowong berakhir pada satu peranti atau keluar melalui satu uplink, redundansi hanya wujud di atas kertas.

Padankan perubahan dengan jejari impaknya

Dokumentasi dokumentasi penggantian titik akhir AWS memisahkan kes-kes itu, dan perbezaannya mudah terlepas pandang. Kemas kini yang diurus oleh AWS digunakan pada satu terowong pada satu masa. Perubahan yang dimulakan pelanggan pada get laluan sasaran, get laluan pelanggan atau pilihan sambungan menjadikan kedua-dua terowong tidak tersedia sementara titik akhir pengganti disediakan.

Menukar pilihan pada satu terowong ialah kes ketiga dengan impak tersendiri yang dinyatakan: terowong itu tidak tersedia semasa kemas kininya sendiri dan yang lain terus berjalan.

Buktikan alternatif sebelum anda memerlukannya

Jadualkan ujian dan bukan menunggu peristiwa. Turunkan terowong yang sihat dalam tetingkap penyelenggaraan, sahkan alternatif berunding, kemudian sahkan trafik sebenar melintasinya dalam kedua-dua arah. Semak penghalaan balik serta status terowong, kerana ketidakpadanan fasa kedua membiarkan terowong naik dan beban kerja mati. Ukur masa peralihan semasa anda berada di sana.

Simpan notis, output telemetri dan pelan perubahan dalam satu rekod. Rekod itu menjadikan notis suku tahun depan sebagai semakan dua minit dan bukan perdebatan tentang sama ada seseorang pernah menguji sandaran itu.