Linux บอนด์แบบแอคทีฟ-สแตนด์บายบน EVPN all-active: อะไรพัง

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

แอคทีฟ-สแตนด์บายทำอะไรกับเฟรมขาเข้า

โหมดบอนดิ้ง 1 เก็บสเลฟไว้หนึ่งตัวพอดีในเส้นทางส่ง และสลับก็ต่อเมื่อตัวปัจจุบันล้มเหลว ส่วนนั้นเป็นที่รู้จักกันดี สิ่งที่สำคัญตรงนี้คือฝั่งรับ เคอร์เนลส่งเฟรมให้สแตกก็ต่อเมื่อเฟรมมาถึงสเลฟที่แอคทีฟ และทิ้งเฟรมที่ปรากฏบนสเลฟอื่น การตั้งค่า all_slaves_active นี้มีอยู่เพื่อผ่อนกฎนั้น และโดยค่าเริ่มต้นปิดอยู่ ip -d link show bond0 พิมพ์ค่าปัจจุบันข้างโหมด

/proc/net/bonding/bond0 ระบุชื่อสเลฟที่แอคทีฟและรายงานสถานะลิงก์ของแต่ละสเลฟ ไฟล์นั้นเป็นแหล่งข้อมูลซื่อตรงเพียงแหล่งเดียวว่าพอร์ตใดกำลังแบกทราฟฟิกอยู่

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

มัลติโฮมมิ่ง all-active ทำอะไรกับฮอปถัดไปที่อยู่ไกล

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

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

จุดที่การเลือกทั้งสองไม่ตรงกัน

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

มีทางออกที่รองรับสองทาง และใช้แทนกันไม่ได้ ให้บอนด์ที่แฟบริกมองเป็นการเชื่อมต่อเชิงตรรกะเดียวแก่โฮสต์ ซึ่งในทางปฏิบัติหมายถึงบอนด์ LACP ที่เจรจากับใบไม้ และลิงก์ทั้งสองทำงานพร้อมกันจริง หรือยอมรับการส่งแบบ single-active จากแฟบริกด้วย เพื่อให้เซกเมนต์เดินตามโมเดลทีละพอร์ตเหมือนบอนด์ สิ่งที่ไม่ทำงานคือเซกเมนต์ all-active วางอยู่หน้าบอนด์ที่ฟังพอร์ตเดียว เว้นแต่คุณจะเปิดรับบนสเลฟที่ไม่แอคทีฟโดยเจตนาและยอมรับการส่งซ้ำที่ตามมา

ทำไมสายสำรองจึงดูแข็งแรงอยู่เสมอ

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

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

ทดสอบการส่งในทั้งสองทิศทาง ไม่ใช่สถานะลิงก์

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

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

ยอมรับการออกแบบก็ต่อเมื่อเมทริกซ์แสดงการส่งสองทิศทางผ่านเส้นทางที่คุณตั้งใจ สายสองเส้นที่ลิงก์ขึ้นไม่ใช่ผลลัพธ์นั้น