การแจ้งเตือน AWS เรื่องอุโมงค์เดียว: เมื่อใดจึงสำคัญจริง

การแจ้งเตือน AWS Health ที่บอกว่าอุโมงค์หนึ่งล่มมักมาถึงเมื่อไม่มีอะไรดูเหมือนเสีย หาใช่เหตุผลอื่นไม่ที่มันถูกมองข้าม การแจ้งเตือนไม่ได้อธิบายการหยุดให้บริการ แต่กำลังอธิบายสภาวะความซ้ำซ้อนที่ดำเนินต่อเนื่องเกินหน้าต่างการสังเกตของ AWS การที่คุณจะลงมือหรือไม่ขึ้นอยู่กับสิ่งที่การออกแบบของคุณทนได้ ไม่ใช่ว่าแดชบอร์ดดูเป็นอย่างไร

การแจ้งเตือนวัดอะไรจริง

การเชื่อมต่อ Site-to-Site แต่ละรายการมีอุโมงค์สองเส้นที่สิ้นสุดที่ปลายทาง AWS ต่างกัน เอกสารการตรวจสอบของ AWS แนะนำให้กำหนดค่าทั้งสองเส้นเพื่อความซ้ำซ้อน และจะยกการแจ้งเตือนเมื่อเส้นหนึ่งล่มต่อเนื่องตามระยะเวลาที่ระบุไว้ ระยะเวลานั้นสำคัญ เพราะการกระตุกสั้นกับการสูญเสียถาวรดูเหมือนกันในกราฟเดียว

อ่านข้อมูลวัดระยะไกลของแต่ละอุโมงค์แทนสถานะโดยรวมของการเชื่อมต่อ aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' คืนสถานะและข้อความสำหรับแต่ละอุโมงค์ และนั่นคือหลักฐานที่การแจ้งเตือนอ้างอิง

สามเงื่อนไขที่กำหนดการตอบสนองของคุณ

พิจารณาทั้งสามข้อก่อนตัดสินว่านี่คือตั๋วงานหรือการยักไหล่

ข้อแรก อุโมงค์ที่เหลืออยู่รับภาระได้หรือไม่ รวมถึงเพดานแบนด์วิดท์และคำนำหน้าที่มันประกาศ ข้อสอง การสลับเกิดขึ้นจริงหรือไม่ เมื่ออุโมงค์ที่สองล่มตั้งแต่สร้างและไม่เคยพิสูจน์ว่ากลับขึ้นมา ข้อสาม การเปลี่ยนแปลงที่วางแผนไว้ครั้งต่อไปของคุณจะทำให้ทั้งสองอุโมงค์ล่มพร้อมกันหรือไม่ ซึ่งเปลี่ยนคำเตือนเชิงภาพให้เป็นปัญหาหน้าต่างบำรุงรักษา ถ้าคำตอบข้อใดเป็นไม่หรือไม่ทราบ การแจ้งเตือนนั้นคือข้อค้นพบจริง

ถ้าทั้งสามข้อพิสูจน์ได้ว่าดี จดบันทึกว่าทำไมจึงยอมรับได้แล้วเดินหน้าต่อ บันทึกนั้นมีค่ามากกว่าการถกเถียงในไตรมาสหน้า

สิ่งที่เพียร์สำรองไม่ได้พิสูจน์

เกตเวย์ฝั่งลูกค้าที่มีเพียร์สำรองกำหนดค่าไว้ไม่ใช่หลักฐานว่า AWS เห็นอุโมงค์ที่สมบูรณ์สองเส้น ฝั่งลูกค้าอาจเก็บเพียร์เย็นที่ต้องเจรจาใหม่ และนั่นอาจเป็นการออกแบบที่ชอบด้วยกฎหมาย กระนั้นก็ยังไม่ใช่การสังเกตเดียวกับอุโมงค์ที่มีชีวิตสองเส้น

เราเตอร์กายภาพสองเครื่องก็ไม่ได้แก้กรณีตรงกันข้าม เมื่ออุโมงค์ทั้งสองสิ้นสุดที่อุปกรณ์เดียวหรือออกผ่านลิงก์ขึ้นเพียงเส้นเดียว ความซ้ำซ้อนมีอยู่เพียงบนกระดาษ

จับคู่การเปลี่ยนแปลงกับรัศมีผลกระทบ

เอกสาร เอกสารการเปลี่ยนปลายทาง ของ AWS แยกกรณีออกจากกัน และความแตกต่างนั้นง่ายที่จะมองข้าม การอัปเดตที่ AWS จัดการจะถูกนำไปใช้กับอุโมงค์ทีละเส้น การเปลี่ยนแปลงที่ลูกค้าเริ่มต้นบนเกตเวย์เป้าหมาย เกตเวย์ฝั่งลูกค้า หรือตัวเลือกการเชื่อมต่อ ทำให้ทั้งสองอุโมงค์ใช้งานไม่ได้ระหว่างที่มีการจัดเตรียมปลายทางทดแทน

การเปลี่ยนตัวเลือกบนอุโมงค์เดียวเป็นกรณีที่สามซึ่งมีผลกระทบที่ระบุไว้เอง: อุโมงค์นั้นใช้งานไม่ได้ระหว่างการอัปเดตของตัวเอง และอีกเส้นยังทำงานต่อไป

พิสูจน์ทางเลือกก่อนที่คุณจะต้องใช้

กำหนดตารางการทดสอบแทนการรอเหตุการณ์ นำอุโมงค์ที่สมบูรณ์ลงภายในหน้าต่างบำรุงรักษา ยืนยันว่าทางเลือกเจรจาได้ แล้วยืนยันว่าทราฟฟิกจริงผ่านมันไปทั้งสองทิศทาง ตรวจสอบเส้นทางขากลับควบคู่กับสถานะอุโมงค์ เพราะความไม่ตรงกันในเฟสที่สองทำให้อุโมงค์ยังขึ้นอยู่แต่ภาระงานตาย วัดเวลาการเปลี่ยนผ่านขณะที่คุณอยู่ที่นั่น

เก็บการแจ้งเตือน ผลลัพธ์ข้อมูลวัดระยะไกล และแผนการเปลี่ยนแปลงไว้ในบันทึกเดียว บันทึกนั้นเปลี่ยนการแจ้งเตือนของไตรมาสหน้าให้เป็นการทบทวนสองนาที แทนการถกเถียงว่าใครเคยทดสอบระบบสำรองหรือไม่