ลิงก์ไร้สายเป็นระบบสำรอง: สลับเส้นทางแบบเราเตอร์หรือหนึ่งเซกเมนต์?

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

กำหนดว่าอะไรต้องรอดจากเหตุขัดข้อง

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

เขียนรายการนั้นและแนบไปกับการออกแบบ เพราะคำตอบมักเปลี่ยนทันทีที่เจ้าของแอปพลิเคชันคนแรกได้ยินเรื่องลิงก์ใหม่

การสลับแบบเราเตอร์: สองพรีฟิกซ์ หนึ่งเส้นทางที่ต้องการ

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

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

อ่านคำสั่งที่สามเช่นเดียวกับคำสั่งที่สอง: กฎนโยบาย ตารางที่สอง หรือการตัดสินใจตามต้นทางอาจส่งทราฟฟิกจากซับเน็ตหนึ่งต่างจากอีกซับเน็ต และการค้นหาเริ่มต้นเพียงครั้งเดียวก็ซ่อนเรื่องนี้

การสลับแบบบริดจ์: หนึ่งเซกเมนต์ หนึ่งเส้นทางที่บล็อก

หากจำเป็นต้องมีความใกล้เคียงจริง ๆ ระบบสำรองต้องบรรทุกเฟรมอีเทอร์เน็ต ซึ่งทันเนล IP แบบเราเตอร์ทำไม่ได้ บางแพลตฟอร์มรองรับ การบริดจ์อินเทอร์เฟซ VPN เข้าเซกเมนต์ท้องถิ่น และอินเทอร์เฟซเหล่านั้นจะกลายเป็นสมาชิกบริดจ์พร้อมผลที่ตามมา เส้นทาง Layer 2 สองเส้นที่ส่งต่อพร้อมกันจะสร้างลูป ดังนั้นการออกแบบต้องมีสแปนนิงทรีที่ครอบทั้งสองไซต์และข้อความชัดเจนว่าเส้นทางใดควรบล็อก

นี่เป็นการตัดสินใจออกแบบที่สำคัญ ไม่ใช่ช่องทำเครื่องหมาย และเอกสารบริดจ์ของแพลตฟอร์มคุณ เช่น ภาพรวมบริดจ์ สำหรับ pfSense คือที่ที่คุณยืนยันว่าสมาชิก VPN มีส่วนร่วมกับอะไรจริง ๆ การเปิดตัวเลือกสแปนนิงทรีบนอุปกรณ์เดียวที่ไม่เกี่ยวข้องไม่ได้พิสูจน์อะไรเกี่ยวกับการจัดวางตั้งแต่ต้นจนจบ

ตรวจสอบขอบเขตที่มีความสำคัญ

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

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

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

ฝึกซ้อมทั้งสองทิศทางภายใต้ภาระ

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

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

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