ข้ามไปยังเนื้อหา

โมเดลอินเทอร์เฟซและการจัดการแบบ Out-of-band

Customer Edge (CE) ไม่มีเพลนการจัดการในเครื่องที่มีนัยสำคัญ นอกจากการกำหนดค่าบูตสแตรปและการวินิจฉัยแล้ว ทุกสิ่งที่จัดการ CE จะถูกขับเคลื่อนจากเพลนควบคุม F5 Distributed Cloud และโหนดจะเข้าถึงเพลนควบคุมนั้นผ่านอินเทอร์เฟซเฉพาะอินเทอร์เฟซเดียว ข้อเท็จจริงประการเดียวนี้นำไปสู่การตัดสินใจโมเดลอินเทอร์เฟซทั้งหมด และการเข้าใจผิดในเรื่องนี้เป็นวิธีที่พบบ่อยที่สุดที่ทำให้การปรับใช้ CE จบลงด้วยสถาปัตยกรรมที่ผิดพลาดมากกว่าการชำรุดเสียหาย

หน้านี้จะแยกแยะสองสิ่งที่ใช้คำว่า “การจัดการ” ร่วมกันแต่ไม่ใช่โครงสร้างเดียวกัน:

สิ่งที่มันเป็น
Site Local Outside (SLO)อินเทอร์เฟซที่ CE ใช้ลงทะเบียนและสื่อสารกลับไปยังศูนย์กลาง (phone home) มีอยู่ใน CE ทุกเครื่องและในทุกโหมด ไม่สามารถเปลี่ยนแปลงได้หลังการลงทะเบียน ในกรณีทั่วไป อินเทอร์เฟซนี้คือเส้นทางการจัดการ
Management networkตัวเลือก Secure Mesh Site v2 (SMSv2) ที่แตกต่าง ใหม่กว่า และแคบกว่า ซึ่งเพิ่มอินเทอร์เฟซแบบ Out-of-band (OOB) ที่แท้จริงในอินสแตนซ์ Virtual Routing and Forwarding (VRF) ของเคอร์เนลของตนเอง สำหรับไซต์โหนดเดียวเท่านั้น

Site Local Outside ไม่อินเทอร์เฟซข้อมูลที่บังเอิญอยู่อันดับแรก

หัวข้อที่มีชื่อว่า “Site Local Outside ไม่อินเทอร์เฟซข้อมูลที่บังเอิญอยู่อันดับแรก”

SLO เชื่อมต่อโหนด CE เข้ากับ Regional Edges (REs) ของ F5 Distributed Cloud และเป็นเส้นทางที่การลงทะเบียน การอัปเกรด และการเชื่อมต่อเพลนควบคุมทำงาน นอกจากนี้ยังทำหน้าที่เป็นเส้นทางเริ่มต้นสำหรับการส่งออกของเพลนข้อมูล และเป็นจุดสิ้นสุดของอุโมงค์เชื่อมต่อระหว่างไซต์ เนื่องจากแพลตฟอร์มสำรองอินเทอร์เฟซนี้ไว้สำหรับการเข้าถึง F5 โปรดปฏิบัติต่ออินเทอร์เฟซนี้เป็นพิเศษและออกแบบโดยยึดรอบอินเทอร์เฟซนี้ แทนที่จะโหลดทราฟก์แอปพลิเคชันลงไป

ผลลัพธ์สองประการตามมา และทั้งสองประการเป็นข้อตกลงเชิงสัญญามากกว่าข้อแนะนำ:

  • SLO ต้องสามารถเข้าถึง F5 ได้ ข้อกำหนดการเข้าถึงได้รับการระบุไว้ใน CE IP Address and Domain Reference CE ที่อินเทอร์เฟซ SLO ไม่สามารถเข้าถึง F5 ได้จะไม่สามารถลงทะเบียนได้ และโหนดที่ไม่ได้รับการลงทะเบียนจะไม่สามารถวินิจฉัยผ่านเพลนควบคุมได้เช่นกัน — ดู เส้นทางการเข้าถึงทั้งสี่เส้นทาง
  • SLO ไม่สามารถเปลี่ยนแปลงได้เมื่อโหนดได้รับการลงทะเบียนและปรับใช้แล้ว F5 ระบุว่าหลังจากปรับใช้ CE Site แล้ว ที่อยู่ Internet Protocol (IP) สำหรับอินเทอร์เฟซ SLO จะไม่สามารถเปลี่ยนแปลงได้ และที่อยู่ Media Access Control (MAC) ก็ไม่สามารถเปลี่ยนแปลงได้เช่นกัน การเปลี่ยนพารามิเตอร์ SLO หมายถึงการปรับใช้โหนดใหม่อีกครั้ง

เซกเมนต์คือคำตอบทั่วไปสำหรับเครือข่ายภายใน

หัวข้อที่มีชื่อว่า “เซกเมนต์คือคำตอบทั่วไปสำหรับเครือข่ายภายใน”

SLI เป็นตัวเลือกเสริม คำแนะนำของ F5 เองเสนอให้พิจารณา Network Segments แทน ซึ่งสามารถเข้าถึงได้ใน Console ภายใต้ Multi-Cloud Network Connect > Networking > Segments เซกเมนต์คือ VRF ระดับโลกที่สามารถแนบกับอินเทอร์เฟซได้ ดังนั้นมันจึงรักษาเครือข่ายให้แยกต่างหากภายใน CE Site เดียว หรือขยายเครือข่ายนั้นข้าม CE Sites ในรูปแบบไฮบริดและมัลติคลาวด์หลายแห่ง นั่นทำให้เซกเมนต์เป็นเครื่องมือที่ถูกต้องเมื่อมีข้อกำหนดว่า “บริการเหล่านี้จะต้องถูกจำกัดไว้ใน VRF ของตนเอง”

นี่คือโครงสร้างที่เมนู Management Network เปิดใช้งานบนวัตถุไซต์ SMSv2 และเป็นอินเทอร์เฟซ OOB ที่แท้จริง ไม่ใช่อินเทอร์เฟซ SLO ที่เปลี่ยนป้ายชื่อใหม่ เมื่อเปิดใช้งาน F5 จะสร้างอินเทอร์เฟซเครือข่ายแยกต่างหากที่ไม่ใช่ทั้งอินเทอร์เฟซ SLO หรือ SLI โดยทำงานใน VRF ของเคอร์เนลของตนเองเพื่อแยกจากทราฟฟิกเพลนข้อมูลอย่างสมบูรณ์ เนื่องจากมันอยู่นอกย่านความถี่ (Out-of-band) มันจึงไม่มีส่วนในการส่งต่อข้อมูลของโหนด CE วัตถุประสงค์การใช้งานที่ตั้งใจไว้คือการจัดการบริการแบบ OOB (Secure Shell (SSH) และส่วนติดต่อผู้ใช้เว็บในเครื่อง) และการแก้ไขปัญหา (การรันคำสั่ง Site CLI และการส่งไฟล์ syslog ออกไป)

ข้อจำกัดสามประการเป็นตัวตัดสินว่าตัวเลือกนี้พร้อมใช้งานสำหรับคุณหรือไม่:

ข้อจำกัดค่า
จำนวนโหนดเฉพาะ CE Sites โหนดเดียวเท่านั้น ไม่รองรับสำหรับ CE Site หลายโหนด (cluster)
เวอร์ชันซอฟต์แวร์crt-20251001-0189 หรือใหม่กว่า ดู บันทึกการปล่อยซอฟต์แวร์โหนด
ค่าเริ่มต้นไม่เปิดใช้งาน

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

  1. อินเทอร์เฟซเครือข่ายการจัดการ
  2. อินเทอร์เฟซ Site Local Outside (SLO)
  3. อินเทอร์เฟซเพิ่มเติมใดๆ ซึ่งจะกลายเป็นส่วนหนึ่งของอินเทอร์เฟซ Site Local Inside (SLI)

CE แต่ละเครื่องในที่นี้มี Azure NICs สามใบ และใบแรกมีชื่อว่า mgmt ใน terraform/modules/ce-node/main.tf ชื่อนั้นอธิบายถึงซับเน็ต Azure ที่มันตั้งอยู่ มัน ไม่ได้ หมายความว่ามีการกำหนดค่าเครือข่ายการจัดการ XC และไม่มีหน้าใดในที่นี้ที่ควรอ่านว่าเป็นการระบุเช่นนั้น

terraform/modules/xc-site/main.tf ประกาศอินเทอร์เฟซเพียงหนึ่งอินเทอร์เฟซบนวัตถุไซต์:

interface_list {
name = "eth0"
ethernet_interface {
device = "eth0"
mac = var.mgmt_nic_mac
}
# Site Local Outside (SLO) — required on every site; BGP peers from here.
network_option {
site_local_network {}
}
dhcp_client {}
}

site_local_network {} คือ SLO ดังนั้น:

ในการปรับใช้นี้สิ่งที่มันเป็นจริงๆ
mgmt NIC (eth0, NIC ใบแรกของ VM)อินเทอร์เฟซ SLO นำส่งทราฟฟิกการลงทะเบียนและเพลนควบคุมไปยัง F5 และเป็นที่อยู่นครหลวงของ Border Gateway Protocol (BGP) ที่ Azure Route Server ทำการเชื่อมต่อ
external NICอินเทอร์เฟซเพลนข้อมูล
internal NICอินเทอร์เฟซ SLI
เครือข่ายการจัดการไม่ได้กำหนดค่า ไม่มีตัวทำเครื่องหมาย enable_management_network ถูกตั้งค่าไว้บนวัตถุไซต์

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

ฉันจะกำหนดอินเทอร์เฟซการจัดการแบบ Out-of-band ที่แยกต่างหากพร้อมการกำหนดค่า IP และการกำหนด VLAN ของตนเองได้อย่างไร?

หัวข้อที่มีชื่อว่า “ฉันจะกำหนดอินเทอร์เฟซการจัดการแบบ Out-of-band ที่แยกต่างหากพร้อมการกำหนดค่า IP และการกำหนด VLAN ของตนเองได้อย่างไร?”

บน CE Site โหนดเดียว ให้เปิดใช้งานตัวเลือก Management Network บนวัตถุไซต์ SMSv2 บนซอฟต์แวร์ crt-20251001-0189 หรือใหม่กว่า จากนั้น F5 จะสร้างอินเทอร์เฟซแยกต่างหากใน VRF ของเคอร์เนลของตนเอง ซึ่ง อยู่นอกเพลนการส่งต่อข้อมูล

บน CE Site หลายโหนด (สามโหนด) ไม่มีวิธีที่ได้รับการรองรับในการทำเช่นนี้ เครือข่ายการจัดการไม่ได้รับการรองรับอย่างชัดเจนสำหรับคลัสเตอร์ สำหรับคลัสเตอร์ ให้ปฏิบัติต่อ SLO เป็นเส้นทางการจัดการ — ซึ่งเป็นสิ่งที่เข้าถึง F5 Global Controller และถูกสำรองไว้สำหรับสิ่งนั้น — และเพิ่มอินเทอร์เฟซเพลนข้อมูลเพิ่มเติม ใน SLI VRF หรือในเซกเมนต์ของตนเองสำหรับสิ่งอื่นทั้งหมด

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

ฉันเปิดใช้งาน Management Network บนไซต์สามโหนดของฉัน แต่โหนดเปิดขึ้นมาพร้อมกับ SLO เท่านั้น ทำไมจึงเป็นเช่นนั้น?

หัวข้อที่มีชื่อว่า “ฉันเปิดใช้งาน Management Network บนไซต์สามโหนดของฉัน แต่โหนดเปิดขึ้นมาพร้อมกับ SLO เท่านั้น ทำไมจึงเป็นเช่นนั้น?”

เนื่องจากตัวเลือกนี้ไม่ได้รับการรองรับบน CE Site หลายโหนด วัตถุไซต์ยอมรับการตั้งค่า แต่คลัสเตอร์จะไม่ได้รับอินเทอร์เฟซเพิ่มเติม ดังนั้นอินเทอร์เฟซภายนอกที่คุณเห็นคืออินเทอร์เฟซ SLO ที่ทำงานตามปกติ นี่คือข้อจำกัดของการกำหนดค่าที่รองรับ ไม่ใช่ข้อผิดพลาดของการจัดสรร และไม่สามารถแก้ไขได้บนวัตถุไซต์นั้น: High Availability ไม่สามารถเปลี่ยนแปลงได้หลังการสร้าง

ฉันสามารถย้ายการจัดการออกจาก SLO หลังจากปรับใช้ไซต์แล้วได้หรือไม่?

หัวข้อที่มีชื่อว่า “ฉันสามารถย้ายการจัดการออกจาก SLO หลังจากปรับใช้ไซต์แล้วได้หรือไม่?”

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

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

อินเทอร์เฟซ SLO หนึ่งอินเทอร์เฟซเป็นขั้นต่ำที่แพลตฟอร์มต้องการ หากทราฟก์การจัดการต้องไม่แชร์อินเทอร์เฟซกับทราฟฟิกแอปพลิเคชัน ให้วางแผนไว้สามอินเทอร์เฟซ: SLO สำหรับเพลนควบคุม บวกกับอินเทอร์เฟซเพลนข้อมูลอย่างน้อยสองอินเทอร์เฟซ การปรับใช้นี้ใช้รูปแบบนั้น — SLO, external, internal