วิธีปรับขนาดศูนย์ข้อมูล รายงานยานเดกซ์

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

จากรายงานของ Dmitry Afanasyev คุณจะได้เรียนรู้เกี่ยวกับหลักการพื้นฐานของการออกแบบใหม่ การปรับขนาดโทโพโลยี ปัญหาที่เกิดขึ้น ตัวเลือกในการแก้ปัญหา คุณสมบัติของการกำหนดเส้นทางและปรับขนาดฟังก์ชันการส่งต่อระนาบของอุปกรณ์เครือข่ายสมัยใหม่ใน "การเชื่อมต่อที่หนาแน่น" โทโพโลยีที่มีเส้นทาง ECMP จำนวนมาก นอกจากนี้ Dima ยังพูดสั้น ๆ เกี่ยวกับการจัดการเชื่อมต่อภายนอก เลเยอร์ทางกายภาพ ระบบสายเคเบิล และวิธีในการเพิ่มขีดความสามารถเพิ่มเติม

- สวัสดีตอนบ่ายทุกคน! ชื่อของฉันคือ Dmitry Afanasyev ฉันเป็นสถาปนิกเครือข่ายที่ Yandex และออกแบบเครือข่ายศูนย์ข้อมูลเป็นหลัก



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

Yandex คืออะไรในแง่ของปริมาณและบริการ? ยานเดกซ์เป็นไฮเปอร์สเกลทั่วไป หากเราดูที่ผู้ใช้ เราจะดำเนินการตามคำขอของผู้ใช้เป็นหลัก อีกทั้งบริการสตรีมมิ่งและการถ่ายโอนข้อมูลต่างๆ เพราะเรามีบริการจัดเก็บข้อมูลด้วย หากอยู่ใกล้กับแบ็กเอนด์ โหลดโครงสร้างพื้นฐานและบริการจะปรากฏขึ้นที่นั่น เช่น พื้นที่จัดเก็บอ็อบเจ็กต์แบบกระจาย การจำลองข้อมูล และแน่นอนว่าคิวถาวร ปริมาณงานประเภทหลักประเภทหนึ่งคือ MapReduce และระบบที่คล้ายกัน การประมวลผลสตรีม การเรียนรู้ของเครื่อง ฯลฯ

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

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

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

การออกแบบเครือข่ายศูนย์ข้อมูลซ้ำสองสามครั้งล่าสุดได้ใช้โทโพโลยี Clos หลายเลเยอร์และเป็น L3 เท่านั้น เราออกจาก L2 ไปได้สักพักแล้วถอนหายใจด้วยความโล่งอก สุดท้ายนี้ โครงสร้างพื้นฐานของเรามีอินสแตนซ์การประมวลผล (เซิร์ฟเวอร์) หลายแสนรายการ ขนาดคลัสเตอร์สูงสุดเมื่อก่อนคือประมาณ 10 เซิร์ฟเวอร์ สาเหตุหลักมาจากวิธีที่ระบบปฏิบัติการระดับคลัสเตอร์ ตัวกำหนดเวลา การจัดสรรทรัพยากร ฯลฯ สามารถทำงานได้ เนื่องจากความคืบหน้าเกิดขึ้นที่ด้านข้างของซอฟต์แวร์โครงสร้างพื้นฐาน ตอนนี้ขนาดเป้าหมายจึงอยู่ที่ประมาณ 100 เซิร์ฟเวอร์ในคลัสเตอร์คอมพิวเตอร์หนึ่งคลัสเตอร์ และ เรามีงาน - เพื่อสร้างโรงงานเครือข่ายที่ช่วยให้สามารถรวบรวมทรัพยากรอย่างมีประสิทธิภาพในคลัสเตอร์ดังกล่าว

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

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

แน่นอนว่าเราต้องการระบบอัตโนมัติ เนื่องจากเป็นไปไม่ได้ที่จะจัดการโครงสร้างพื้นฐานดังกล่าวด้วยตนเอง และก็เป็นไปไม่ได้มาระยะหนึ่งแล้ว เราต้องการการสนับสนุนการปฏิบัติงานให้มากที่สุดเท่าที่จะเป็นไปได้และการสนับสนุน CI/CD เท่าที่สามารถให้ได้

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

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

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

แล้วอะไรคือสิ่งที่เราไม่ต้องการ อะไรที่เรายอมแพ้ได้ ไม่ใช่ด้วยความยินดีเสมอไปในเวลาที่มันเกิดขึ้น แต่ด้วยความโล่งใจอย่างมากเมื่อกระบวนการเสร็จสิ้น?

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

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

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

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

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

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

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

ในกรณี เช่น เมื่อใช้ Clos สองระดับ เมื่อสามารถระบุส่วนประกอบที่อยู่ในแนวตั้งได้อย่างชัดเจนในไดอะแกรมของฉัน โดยปกติจะเรียกว่าระนาบ หากเราต้องสร้าง Clos ด้วยสวิตช์กระดูกสันหลังสามระดับ (ทั้งหมดไม่ใช่ขอบเขตหรือสวิตช์ ToR และใช้สำหรับการขนส่งเท่านั้น) เครื่องบินจะดูซับซ้อนมากขึ้น เครื่องบินสองระดับจะมีลักษณะเช่นนี้ทุกประการ เราเรียกบล็อกของสวิตช์ ToR หรือลีฟ และสวิตช์สไปน์ระดับแรกที่เกี่ยวข้องกับพวกมันว่าพ็อด สวิตช์กระดูกสันหลังของระดับกระดูกสันหลัง-1 ที่ด้านบนของ Pod คือด้านบนของ Pod ด้านบนของ Pod สวิตช์ที่อยู่ด้านบนสุดของโรงงานทั้งหมดจะเป็นชั้นบนสุดของโรงงาน ชั้นบนสุดของผ้า

แน่นอนว่าคำถามเกิดขึ้น: เครือข่าย Clos ถูกสร้างขึ้นมาระยะหนึ่งแล้ว แนวคิดนี้มาจากสมัยของระบบโทรศัพท์แบบคลาสสิก เครือข่าย TDM อาจมีบางสิ่งที่ดีกว่าปรากฏขึ้นบางทีอาจมีบางสิ่งที่สามารถทำได้ดีกว่านี้? ใช่และไม่. ตามทฤษฎีแล้ว ใช่ ในทางปฏิบัติในอนาคตอันใกล้นี้จะไม่เป็นเช่นนั้นอย่างแน่นอน เนื่องจากมีโทโพโลยีที่น่าสนใจจำนวนหนึ่ง โทโพโลยีบางส่วนจึงถูกนำมาใช้ในการผลิตด้วยซ้ำ เช่น Dragonfly ถูกใช้ในแอปพลิเคชัน HPC; นอกจากนี้ยังมี Topologie ที่น่าสนใจ เช่น Xpander, FatClique, Jellyfish หากคุณดูรายงานในการประชุมเช่น SIGCOMM หรือ NSDI เมื่อเร็ว ๆ นี้ คุณจะพบงานจำนวนมากเกี่ยวกับโทโพโลยีทางเลือกที่มีคุณสมบัติที่ดีกว่า (อย่างใดอย่างหนึ่ง) มากกว่า Clos

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

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

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

ดังนั้นทิศทางนี้จึงน่าสนใจ แต่น่าเสียดายที่เราไม่สามารถนำไปใช้ได้ในขณะนี้

โอเค เราตัดสินใจเลือกโทโพโลยีแบบลอจิคัลของ Clos แล้ว เราจะขยายขนาดได้อย่างไร? มาดูกันว่ามันทำงานอย่างไรและทำอะไรได้บ้าง

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

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

ในเรื่องความจุ โดยเฉพาะบนสวิตช์ ToR นั้น มีสองตัวเลือกในการขยายขนาด ไม่ว่าเราจะใช้ลิงก์ที่เร็วขึ้นในขณะที่ยังคงรักษาโครงสร้างโทโพโลยีทั่วไปไว้ หรืออาจเพิ่มระนาบเพิ่มเติมได้

หากคุณดูเครือข่าย Clos เวอร์ชันขยาย (ที่มุมขวาล่าง) แล้วกลับมาที่ภาพนี้พร้อมกับเครือข่าย Clos ด้านล่าง...

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

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

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

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

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

ยิ่งไปกว่านั้น แม้แต่วงดนตรีเพิ่มเติมนี้ก็ไม่เหมือนกันทุกประการ แม้ว่าช่วงระยะเวลาจะสั้น แต่เราสามารถใช้บางอย่าง เช่น DAC (ทองแดงที่ต่อโดยตรง ซึ่งก็คือสาย Twinax) หรือออปติกแบบมัลติโหมด ซึ่งต้องใช้เงินที่สมเหตุสมผลไม่มากก็น้อย ทันทีที่เราย้ายไปยังช่วงที่ยาวขึ้น - ตามกฎแล้วสิ่งเหล่านี้คือออปติกโหมดเดียวและค่าใช้จ่ายของแบนด์วิดท์เพิ่มเติมนี้จะเพิ่มขึ้นอย่างเห็นได้ชัด

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

จากภาพนี้ ชัดเจนว่าเราต้องการสร้างบางอย่างเช่นสวิตช์ที่มีรัศมี 128 จริงๆ

โดยหลักการแล้วทุกอย่างเหมือนกับที่ฉันพูดไปนี่คือสไลด์เพื่อประกอบการพิจารณาในภายหลัง

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

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

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

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

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

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

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

โดยสรุป เรากำลังสร้างโทโพโลยีที่มีกระดูกสันหลังสองระดับ โดยมีแปดชั้นในโรงงาน

จะเกิดอะไรขึ้นกับฟิสิกส์? การคำนวณที่ง่ายมาก หากเรามีสไปน์สองระดับ เราก็จะมีสวิตช์เพียงสามระดับ และเราคาดหวังว่าจะมีส่วนของสายเคเบิลสามส่วนในเครือข่าย: จากเซิร์ฟเวอร์ไปยังลีฟสวิตช์ กระดูกสันหลัง 1 ถึงกระดูกสันหลัง 2 ตัวเลือกที่เราสามารถทำได้ การใช้งานคือ - เหล่านี้คือ twinax, multimode, single mode และที่นี่ เราต้องพิจารณาว่าแถบใดบ้างที่มีจำหน่าย ราคาเท่าไร ขนาดทางกายภาพคืออะไร ช่วงที่เราสามารถครอบคลุมได้ และเราจะอัปเกรดอย่างไร

ในส่วนของต้นทุนทุกอย่างสามารถเรียงกันได้ Twinaxes มีราคาถูกกว่า Active Optic อย่างมาก ราคาถูกกว่าตัวรับส่งสัญญาณมัลติโหมด หากคุณใช้ต่อเที่ยวบินจากจุดสิ้นสุด ค่อนข้างถูกกว่าพอร์ตสวิตช์ 100 กิกะบิต และโปรดทราบว่ามีค่าใช้จ่ายน้อยกว่าเลนส์โหมดเดี่ยว เนื่องจากในเที่ยวบินที่ต้องใช้โหมดเดี่ยว ในศูนย์ข้อมูลด้วยเหตุผลหลายประการ จึงสมเหตุสมผลที่จะใช้ CWDM ในขณะที่โหมดเดี่ยวคู่ขนาน (PSM) ไม่สะดวกในการทำงานมากนัก โดยจะได้รับไฟเบอร์เป็นแพ็คขนาดใหญ่มากและหากเรามุ่งเน้นไปที่เทคโนโลยีเหล่านี้ เราจะได้ลำดับชั้นราคาโดยประมาณดังต่อไปนี้

หมายเหตุอีกประการหนึ่ง: น่าเสียดายที่คุณไม่สามารถใช้พอร์ตมัลติโหมด 100 ถึง 4x25 แบบถอดประกอบได้ เนื่องจากคุณสมบัติการออกแบบของตัวรับส่งสัญญาณ SFP28 จึงไม่ถูกกว่า 28 Gbit QSFP100 มากนัก และการถอดแยกชิ้นส่วนสำหรับมัลติโหมดนี้ทำงานได้ไม่ดีนัก

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

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

นี่คือสิ่งที่ดูเหมือนเมื่อเร็วๆ นี้ สิ่งที่เรากำลังจะมุ่งหน้าไปและสิ่งที่เป็นไปได้ อย่างน้อยก็ชัดเจนว่าจะก้าวไปสู่ ​​50-Gigabit SerDes สำหรับทั้งมัลติโหมดและโหมดเดี่ยวได้อย่างไร ยิ่งไปกว่านั้น หากคุณดูว่ามีอะไรอยู่ในตัวรับส่งสัญญาณโหมดเดี่ยวในปัจจุบันและในอนาคตสำหรับ 400G บ่อยครั้งแม้ว่า SerDes 50G จะมาถึงจากฝั่งไฟฟ้าก็ตาม 100 Gbps ต่อเลนก็สามารถไปที่ระบบออปติกได้แล้ว ดังนั้นจึงค่อนข้างเป็นไปได้ที่แทนที่จะย้ายไปที่ 50 จะมีการเปลี่ยนแปลงเป็น 100 Gigabit SerDes และ 100 Gbps ต่อเลน เนื่องจากตามคำสัญญาของผู้ขายหลายราย คาดว่าจะมีความพร้อมใช้งานในเร็วๆ นี้ ดูเหมือนว่าช่วงเวลาที่ 50G SerDes เร็วที่สุดจะไม่นานนัก เพราะชุดแรกของ 100G SerDes จะเปิดตัวในเกือบปีหน้า และหลังจากนั้นไม่นานหลังจากนั้นพวกเขาก็อาจจะคุ้มค่ากับเงินที่สมเหตุสมผล

ความแตกต่างอีกอย่างหนึ่งเกี่ยวกับการเลือกฟิสิกส์ โดยหลักการแล้ว เราสามารถใช้พอร์ต 400 หรือ 200 Gigabit โดยใช้ 50G SerDes ได้แล้ว แต่ปรากฎว่าสิ่งนี้ไม่สมเหตุสมผลนัก เพราะอย่างที่ฉันพูดไปก่อนหน้านี้ เราต้องการรัศมีที่ใหญ่พอสมควรบนสวิตช์ ด้วยเหตุผลแน่นอน เราต้องการ 128 และถ้าเรามีความจุของชิปที่จำกัด และเราเพิ่มความเร็วการเชื่อมต่อ ดังนั้น Radix จะลดลงตามธรรมชาติ ก็ไม่มีปาฏิหาริย์ใดๆ

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

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

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

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

สี่เหลี่ยมเล็กๆ หมายถึงทางแยก ที่ด้านซ้ายบนคือรายละเอียดของแต่ละทางแยก ซึ่งจริงๆ แล้วนี่คือโมดูลเชื่อมต่อข้ามพอร์ตขนาด 512 x 512 ที่บรรจุสายเคเบิลใหม่เพื่อให้มาอยู่ในแร็คเดียวโดยสมบูรณ์ โดยมีระนาบ Spin-2 เพียงระนาบเดียว และทางด้านขวา การสแกนรูปภาพนี้จะมีรายละเอียดมากขึ้นเล็กน้อยเกี่ยวกับ Pod หลายตัวที่ระดับกระดูกสันหลัง-1 และวิธีการบรรจุในการเชื่อมต่อข้าม วิธีมาถึงระดับกระดูกสันหลัง-2

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

คำถามสำคัญ: เราเลือกโทโพโลยีแบบลอจิคัลและสร้างฟิสิกส์ขึ้นมา จะเกิดอะไรขึ้นกับเครื่องบินควบคุม? จากประสบการณ์การดำเนินงานเป็นที่ทราบกันดีอยู่แล้ว มีรายงานหลายฉบับที่โปรโตคอลสถานะลิงก์นั้นดี เรายินดีเป็นอย่างยิ่งที่ได้ร่วมงานกับพวกเขา แต่น่าเสียดายที่พวกเขาไม่ได้ปรับขนาดได้ดีบนโทโพโลยีที่เชื่อมต่ออย่างหนาแน่น และมีปัจจัยหลักประการหนึ่งที่ป้องกันสิ่งนี้ - นี่คือวิธีการทำงานของน้ำท่วมในโปรโตคอลสถานะลิงก์ หากคุณใช้อัลกอริธึม Flooding และดูว่าเครือข่ายของเรามีโครงสร้างอย่างไร คุณจะเห็นว่าจะมีการกระจายออกไปจำนวนมากในแต่ละขั้นตอน และจะทำให้ Control Plane ท่วมท้นด้วยการอัปเดต โดยเฉพาะอย่างยิ่ง โทโพโลยีดังกล่าวผสมผสานได้ไม่ดีนักกับอัลกอริธึมการฟลัดแบบเดิมในโปรโตคอลสถานะลิงก์

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

ในการดำเนินการนี้ เราใช้การออกแบบที่เรียบง่ายพอที่จะใช้กลไก BGP พื้นฐานได้ นั่นคือเราใช้ eBGP ทำงานบนลิงก์โลคัล และระบบอัตโนมัติถูกกำหนดดังนี้: ระบบอัตโนมัติบน ToR ระบบอัตโนมัติบนบล็อกทั้งหมดของสวิตช์ Spin-1 ของ Pod หนึ่งตัว และระบบอัตโนมัติทั่วไปบนทั้งด้านบน ของผ้า ไม่ยากเลยที่จะเห็นว่าแม้แต่พฤติกรรมปกติของ BGP ก็ทำให้เราเผยแพร่การอัปเดตที่เราต้องการได้

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

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

งานที่น่าสนใจมากในเรื่องนี้ได้ดำเนินการภายใต้กรอบของโปรโตคอล RIFT ซึ่งจะกล่าวถึงในรายงานฉบับถัดไป

สิ่งสำคัญอีกประการหนึ่งคือวิธีที่ Data Plane ปรับขนาดในโทโพโลยีที่หนาแน่น ซึ่งเรามีเส้นทางอื่นจำนวนมาก ในกรณีนี้ มีการใช้โครงสร้างข้อมูลเพิ่มเติมหลายโครงสร้าง: กลุ่ม ECMP ซึ่งจะอธิบายกลุ่ม Next Hop

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

ความสามารถในการปรับขนาด Data Plane บนอุปกรณ์สมัยใหม่มีลักษณะอย่างไร หากเราทำ LPM (การจับคู่คำนำหน้าที่ยาวที่สุด) ทุกอย่างจะค่อนข้างดี มีคำนำหน้ามากกว่า 100 คำ หากเรากำลังพูดถึงกลุ่ม Next Hop ทุกอย่างก็แย่ลง 2-4 พัน หากเรากำลังพูดถึงตารางที่มีคำอธิบายของ Next Hops (หรือที่อยู่ติดกัน) ค่านี้จะอยู่ระหว่าง 16k ถึง 64k และนี่อาจกลายเป็นปัญหาได้ และที่นี่เรามาถึงการพูดนอกเรื่องที่น่าสนใจ: เกิดอะไรขึ้นกับ MPLS ในศูนย์ข้อมูล โดยหลักการแล้วเราต้องการที่จะทำมัน

สองสิ่งเกิดขึ้น เราทำการแบ่งส่วนย่อยบนโฮสต์ เราไม่จำเป็นต้องทำบนเครือข่ายอีกต่อไป การสนับสนุนจากผู้ขายหลายรายไม่ค่อยดีนัก และยิ่งไปกว่านั้นด้วยการใช้งานแบบเปิดบน white box ด้วย MPLS และ MPLS อย่างน้อยการใช้งานแบบดั้งเดิมก็น่าเสียดายที่ผสมผสานกับ ECMP ได้แย่มาก และนั่นคือเหตุผล

นี่คือลักษณะโครงสร้างการส่งต่อ ECMP สำหรับ IP คำนำหน้าจำนวนมากสามารถใช้กลุ่มเดียวกันและบล็อก Next Hops เดียวกัน (หรือที่อยู่ติดกัน ซึ่งอาจเรียกต่างกันในเอกสารที่แตกต่างกันสำหรับอุปกรณ์ที่แตกต่างกัน) ประเด็นก็คือว่านี่คือพอร์ตขาออกและสิ่งที่ต้องเขียนที่อยู่ MAC ใหม่เพื่อไปที่ Next Hop ที่ถูกต้อง สำหรับ IP ทุกอย่างดูเรียบง่าย คุณสามารถใช้คำนำหน้าจำนวนมากสำหรับกลุ่มเดียวกัน ซึ่งเป็นบล็อก Next Hops เดียวกัน

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

เห็นได้ง่ายว่าในการออกแบบของเราเราต้องการสวิตช์ ToR ประมาณ 4000 ตัว ความกว้างสูงสุดคือ 64 เส้นทาง ECMP ถ้าเราย้ายออกจากสไปน์-1 ไปยังสไปน์-2 เราแทบจะไม่ได้เข้าไปในตารางของกลุ่ม ECMP เลย ถ้ามีเพียงหนึ่งคำนำหน้าที่มี ToR หายไป และเราไม่ได้เข้าไปในตาราง Next Hops เลย

มันไม่ได้สิ้นหวังไปเสียหมด เพราะสถาปัตยกรรมอย่าง Segment Routing เกี่ยวข้องกับป้ายกำกับระดับโลก อย่างเป็นทางการ มันเป็นไปได้ที่จะยุบบล็อก Next Hops ทั้งหมดเหล่านี้อีกครั้ง ในการดำเนินการนี้ คุณต้องดำเนินการประเภทไวด์การ์ด: นำป้ายกำกับแล้วเขียนใหม่ให้เป็นรายการเดียวกันโดยไม่มีค่าเฉพาะ แต่น่าเสียดายที่สิ่งนี้ไม่มีอยู่ในการใช้งานที่มีอยู่มากนัก

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

อีกทางเลือกหนึ่งคือเริ่มการรับส่งข้อมูลดังกล่าวจากด้านล่าง ง่ายต่อการตรวจสอบว่าโทโพโลยี Clos ถูกสร้างขึ้นในลักษณะที่การรับส่งข้อมูลที่มาจากด้านล่าง ซึ่งก็คือจากฝั่ง ToR มีการกระจายเท่าๆ กันระหว่างระดับต่างๆ ทั่วทั้ง Top of Fabric ในการวนซ้ำสองครั้ง โดยโหลดเครือข่ายทั้งหมด ดังนั้นเราจึงแนะนำ Pod ชนิดพิเศษ Edge Pod ที่ให้การเชื่อมต่อภายนอก

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

เราเห็นโอกาสในการพัฒนาอะไรบ้าง? ประการแรก ปรับปรุงการรองรับไปป์ไลน์ CI/CD เราต้องการบินในแบบที่เราทดสอบ และทดสอบในแบบที่เราบิน สิ่งนี้ไม่ได้ผลดีนัก เนื่องจากโครงสร้างพื้นฐานมีขนาดใหญ่และเป็นไปไม่ได้ที่จะทำซ้ำสำหรับการทดสอบ คุณต้องเข้าใจวิธีแนะนำองค์ประกอบการทดสอบในโครงสร้างพื้นฐานการผลิตโดยไม่ทำให้เสีย

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

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

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

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

ที่มา: will.com