ExpressRoute กับ VPN: คุณครอบคลุมโดเมนความล้มเหลวใดบ้าง
อุโมงค์ IPsec ที่สองครอบคลุมจุดปลายทาง ไม่ใช่วงจรที่อยู่ข้างใต้ จัดทำแผนที่แต่ละโดเมนความล้มเหลว แล้วตัดสินว่าจะอนุญาตเส้นทางสำรองที่ไม่เข้ารหัสหรือไม่
อุโมงค์ IPsec ที่ทำงานบนเพียริ่งส่วนตัวของ ExpressRoute เพิ่มการเข้ารหัสให้กับการรับส่งที่มีอยู่แล้ว อุโมงค์ที่สองช่วยเพิ่มความพร้อมใช้งานของจุดปลายทาง และไม่ได้ทำอะไรเลยกับเส้นทางของผู้ให้บริการที่อยู่ใต้ทั้งสอง ความแตกต่างนี้หายไปได้ง่ายเมื่อแดชบอร์ดแสดงอุโมงค์สีเขียวสองอุโมงค์และการทบทวนการออกแบบถามคำถามอีกข้อ: ความล้มเหลวใดที่การเชื่อมต่อนี้ต้องอยู่รอด ตอบคำถามนั้นก่อน แล้วจึงนับอุโมงค์ เพราะจำนวนตัวชี้วัดสีเขียวเป็นคุณสมบัติของชั้นการเข้ารหัส และจำนวนโดเมนความล้มเหลวเป็นคุณสมบัติของเส้นทางทั้งหมด
เริ่มจากความล้มเหลว ไม่ใช่จากอุโมงค์สีเขียว
เขียนสี่แถวก่อนวาดอะไรทั้งสิ้น: จุดปลายทาง VPN หนึ่งจุดหรืออินสแตนซ์ peer หนึ่งตัวล้มเหลว เราเตอร์ท้องถิ่นหนึ่งตัวหรือการเชื่อมต่อไมล์แรกหนึ่งเส้นล้มเหลว เส้นทาง ExpressRoute ที่ใช้ร่วมกันล้มเหลว และ IPsec ไม่พร้อมใช้งานในขณะที่เพียริ่งส่วนตัวยังรับส่งข้อมูลอยู่ แต่ละแถวระบุสิ่งที่การออกแบบต้องรักษาไว้ และแต่ละข้อมีกลไกต่างกันตอบ
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft จัดทำเอกสาร VPN แบบไซต์ทูไซต์ด้วย IP ส่วนตัวบนเพียริ่งส่วนตัวของ ExpressRoute และการอยู่ร่วมกันที่รองรับกับการเชื่อมต่อไซต์ทูไซต์ผ่านอินเทอร์เน็ต การอยู่ร่วมกันนั้นเป็นการออกแบบชั้นล่างที่แตกต่าง และไม่ได้เกิดขึ้นเพียงเพราะคุณเพิ่มจุดปลายทางอุโมงค์ส่วนตัวอีกจุด
โดเมนความล้มเหลว 1: จุดปลายทาง VPN
อุโมงค์สองอุโมงค์บนเกตเวย์เดียวมักเป็นคู่ active-active ที่สิ้นสุดบนทรัพยากรฝั่ง Azure เดียวกัน อุโมงค์เหล่านี้ป้องกันปัญหาของอุโมงค์เดียวหรืออินสแตนซ์เดียว และไม่ได้ป้องกันทรัพยากรนั้นไม่พร้อมใช้งาน ถูกกำหนดค่าใหม่ หรือหมดความจุ ความซ้ำซ้อนของจุดปลายทางหมายถึงจุดปลายทางที่รองรับจุดที่สอง ซึ่งมีเส้นทางของตัวเองและการกำหนดค่าของตัวเอง พร้อมเส้นทางที่เข้าถึงได้
ตรวจสอบสิ่งที่คุณปรับใช้จริง ไม่ใช่สิ่งที่แผนภาพบอก เพราะพอร์ทัลจัดกลุ่มทรัพยากรเหล่านี้ในวิธีที่ซ่อนความสัมพันธ์:
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'หากอุโมงค์ทั้งสองชี้ไปที่เกตเวย์เดียวที่มี IP สาธารณะหนึ่งหมายเลข คุณมีความซ้ำซ้อนของจุดปลายทางแบบเฉพาะและจำกัด นั่นอาจเป็นสิ่งที่ข้อกำหนดต้องการ และควรพูดเช่นนั้นแทนที่จะอธิบายว่าเป็นการเชื่อมต่อซ้ำซ้อน
โดเมนความล้มเหลว 2: เส้นทางท้องถิ่นและผู้ให้บริการ
ใต้การเข้ารหัสมีความเป็นจริงทางกายภาพและเชิงพาณิชย์: อุปกรณ์ขอบลูกค้า การเชื่อมต่อไขว้ เครือข่ายผู้ให้บริการ และตำแหน่งเพียริ่ง แนวทางความพร้อมใช้งานของ ExpressRoute ระบุชัดเจนว่าความซ้ำซ้อนจากต้นทางถึงปลายทางรวมถึงส่วนของลูกค้าและผู้ให้บริการ ไม่ใช่เพียงฝั่ง Microsoft เส้นทางตรรกะสองเส้นที่ใช้เราเตอร์ แหล่งจ่ายไฟ หรือการเชื่อมต่อไมล์แรกเดียวกันยังคงใช้การพึ่งพานั้นร่วมกัน
นี่คือจุดที่การออกแบบมักตกในการทบทวนอย่างตรงไปตรงมา วงจรสองวงจากผู้ให้บริการรายเดียวกัน สิ้นสุดในอาคารเดียวกัน บนอุปกรณ์จากคำสั่งซื้อเดียวกัน ไม่ใช่สองโดเมนความล้มเหลว มันเป็นโดเมนความล้มเหลวเดียวที่มีสองใบแจ้งหนี้
ถามผู้ให้บริการเป็นลายลักษณ์อักษร: เส้นทางใดแตกต่างกัน ที่ใด และพฤติกรรมที่บันทึกไว้เมื่อส่วนที่ใช้ร่วมกันล้มเหลวคืออะไร คำรับรองด้วยวาจาในการประชุมออกแบบไม่สามารถอยู่รอดจากเหตุขัดข้องที่คุณกำลังออกแบบรองรับ
โดเมนความล้มเหลว 3: เส้นทางที่อยู่รอดได้โดยไม่มี IPsec
เพียริ่งส่วนตัวและ IPsec สามารถเสนอเส้นทางที่แข่งขันกันไปยังคำนำหน้าแอปพลิเคชันเดียวกัน. หากเส้นทางที่ป้องกันไว้หายไป เส้นทางตรง ExpressRoute ที่เหลืออยู่อาจยังใช้งานได้ โดยไม่มีชั้นการเข้ารหัสที่อุโมงค์ให้ไว้ การยอมรับได้หรือไม่เป็นการตัดสินใจเชิงนโยบาย และเป็นการตัดสินใจที่มักถูกปล่อยให้เป็นนัยบ่อยที่สุด
ข้อกำหนดด้านการเข้ารหัสและข้อกำหนดด้านความพร้อมใช้งานอาจขัดแย้งกันจริงได้ที่นี่ «เส้นทางใดที่เหลืออยู่ก็นับว่าสำเร็จ» เป็นข้อความเกี่ยวกับความพร้อมใช้งานที่ตอบคำถามเรื่องการเข้ารหัสอย่างเงียบ ๆ ว่า «ไม่» เขียนว่าอะไรชนะ สำหรับคำนำหน้าใด และใครอนุมัติ
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o tableเปรียบเทียบเส้นทางที่เรียนรู้กับคำนำหน้าที่คุณคาดไว้ เส้นทางสำรองที่รับภาระงานบริหารเล็กน้อยอาจเพียงพออย่างสมบูรณ์สำหรับภาระนั้น และยังห่างไกลจากความจุที่ความต้องการในการผลิตต้องการ ดังนั้นบันทึกสมมติฐานด้านความจุไว้ข้างเส้นทาง
บันทึกสามแถวแยกกัน ไม่ใช่คำตัดสินเดียว
เก็บความซ้ำซ้อนของจุดปลายทาง ความซ้ำซ้อนของการรับส่ง และการกู้คืนจากภัยพิบัติเป็นรายการแยกกันในบันทึกการออกแบบ แต่ละรายการมีกลไก การตรวจสอบ และเจ้าของของตัวเอง เมื่อการทบทวนเหตุการณ์ถามว่าทำไมการเชื่อมต่ออยู่รอดจากการรีสตาร์ตเกตเวย์แต่ไม่รอดจากการตัดไฟเบอร์ สามแถวตอบได้ในประโยคเดียว ช่องทำเครื่องหมาย «ซ้ำซ้อน» ช่องเดียวทำไม่ได้
จากนั้นทดสอบแถวที่ทดสอบได้ในราคาถูก ทำให้อุโมงค์หนึ่งล้มเหลวและยืนยันว่าทราฟฟิกย้ายและถูกเข้ารหัสใหม่ ดึงเส้นทางหนึ่งกลับและยืนยันว่าเส้นทางที่เหลืออยู่คือเส้นทางที่คุณตั้งใจ แล้วยืนยันว่ายังเข้ารหัสอยู่หรือไม่ จัดทำเอกสารความล้มเหลวที่คุณจำลองไม่ได้ เพราะแถวที่ไม่ได้ทดสอบคือสมมติฐานและควรมีป้ายกำกับเช่นนั้น
ผลลัพธ์ที่มีประโยชน์คือตารางสั้น ๆ พร้อมหนึ่งประโยคต่อแถว หากแถวใดไม่มีกลไก นั่นคือข้อค้นพบ และถูกกว่ามากที่จะค้นพบในการทบทวนการออกแบบมากกว่าในช่วงที่ผู้ให้บริการขัดข้องซึ่งอุโมงค์ทั้งสองไม่เคยจะอยู่รอดได้