ศูนย์ข้อมูลสมัยใหม่มีอุปกรณ์ที่ใช้งานอยู่หลายร้อยเครื่องติดตั้งอยู่ ซึ่งครอบคลุมด้วยการตรวจสอบประเภทต่างๆ แต่แม้แต่วิศวกรในอุดมคติที่มีการตรวจสอบที่สมบูรณ์แบบก็ยังสามารถตอบสนองความล้มเหลวของเครือข่ายได้อย่างถูกต้องในเวลาเพียงไม่กี่นาที ในรายงานที่การประชุม Next Hop 2020 ฉันได้นำเสนอวิธีการออกแบบเครือข่าย DC ซึ่งมีคุณลักษณะเฉพาะ นั่นคือศูนย์ข้อมูลจะรักษาตัวเองได้ในเสี้ยววินาที แม่นยำยิ่งขึ้นวิศวกรจะแก้ไขปัญหาอย่างใจเย็นในขณะที่บริการก็ไม่สังเกตเห็น
สำหรับวิศวกรเครือข่ายจำนวนมาก แน่นอนว่าเครือข่ายศูนย์ข้อมูลเริ่มต้นด้วย ToR โดยมีสวิตช์อยู่ในชั้นวาง ToR มักจะมีลิงก์สองประเภท ตัวเล็กไปที่เซิร์ฟเวอร์ส่วนคนอื่น ๆ - มีมากกว่า N เท่า - ไปที่กระดูกสันหลังของระดับแรกนั่นคือไปยังอัปลิงก์ โดยปกติแล้วอัปลิงก์จะถือว่าเท่ากัน และการรับส่งข้อมูลระหว่างอัปลิงก์จะมีความสมดุลโดยอิงตามแฮชจาก 5-tuple ซึ่งรวมถึง proto, src_ip, dst_ip, src_port, dst_port ไม่มีความประหลาดใจที่นี่
ต่อไปสถาปัตยกรรมแผนจะมีลักษณะอย่างไร? กระดูกสันหลังของระดับแรกไม่ได้เชื่อมต่อถึงกัน แต่เชื่อมต่อกันผ่าน superspine ตัวอักษร X จะรับผิดชอบ superspine ซึ่งเกือบจะเหมือนกับการเชื่อมต่อข้าม
และเห็นได้ชัดว่า ในทางกลับกัน โทริเชื่อมต่อกับกระดูกสันหลังทั้งหมดของชั้นแรก ในภาพนี้มีความสำคัญอะไร? หากเรามีปฏิสัมพันธ์ภายในชั้นวาง แน่นอนว่าการโต้ตอบนั้นจะต้องผ่าน ToR หากการโต้ตอบเกิดขึ้นภายในโมดูล การโต้ตอบจะเกิดขึ้นผ่านกระดูกสันหลังระดับแรก หากปฏิสัมพันธ์เป็นแบบโมดูลาร์ เช่น ToR 1 และ ToR 2 ปฏิสัมพันธ์ดังกล่าวจะผ่านสันกระดูกสันหลังของทั้งระดับที่ XNUMX และระดับที่ XNUMX
ตามทฤษฎีแล้ว สถาปัตยกรรมดังกล่าวสามารถปรับขนาดได้ง่าย หากเรามีความจุของพอร์ต พื้นที่ว่างในศูนย์ข้อมูล และไฟเบอร์แบบวางล่วงหน้า ก็สามารถเพิ่มจำนวนเลนได้เสมอ ซึ่งจะเป็นการเพิ่มความจุโดยรวมของระบบ นี่เป็นเรื่องง่ายมากที่จะทำบนกระดาษ มันจะเป็นเช่นนี้ในชีวิต แต่เรื่องราวของวันนี้ไม่เกี่ยวกับเรื่องนั้น
ฉันต้องการข้อสรุปที่ถูกต้อง เรามีเส้นทางมากมายภายในศูนย์ข้อมูล พวกเขาเป็นอิสระอย่างมีเงื่อนไข เส้นทางเดียวภายในศูนย์ข้อมูลสามารถทำได้ภายใน ToR เท่านั้น ภายในโมดูล เราจะมีจำนวนเส้นทางเท่ากับจำนวนเลน จำนวนเส้นทางระหว่างโมดูลจะเท่ากับผลคูณของจำนวนระนาบและจำนวน superspines ในแต่ละระนาบ เพื่อให้ชัดเจนยิ่งขึ้น เพื่อให้เข้าใจถึงขนาด ฉันจะให้ตัวเลขที่ถูกต้องสำหรับศูนย์ข้อมูล Yandex แห่งใดแห่งหนึ่ง
มีเครื่องบินทั้งหมด 32 ลำ แต่ละลำมี 256 ลำ เป็นผลให้ปรากฎว่ามีแปดเส้นทางภายในโมดูลและด้วยการโต้ตอบระหว่างโมดูลมี XNUMX เส้นทางแล้ว
นั่นคือหากเรากำลังพัฒนา Cookbook โดยพยายามเรียนรู้วิธีสร้างศูนย์ข้อมูลที่ทนทานต่อความเสียหายซึ่งจะรักษาตัวเองได้ สถาปัตยกรรมระนาบก็เป็นตัวเลือกที่เหมาะสม ช่วยแก้ปัญหาการปรับขนาดได้ และในทางทฤษฎีแล้วมันง่ายมาก มีเส้นทางอิสระมากมาย คำถามยังคงอยู่: สถาปัตยกรรมดังกล่าวอยู่รอดจากความล้มเหลวได้อย่างไร มีความล้มเหลวต่างๆ และเราจะหารือเรื่องนี้ตอนนี้
ปล่อยให้ superspine ของเราคนหนึ่ง "ป่วย" ที่นี่ฉันกลับมาที่สถาปัตยกรรมสองระนาบ เราจะยึดถือสิ่งเหล่านี้เป็นตัวอย่าง เพราะจะช่วยให้เห็นได้ง่ายขึ้นว่าเกิดอะไรขึ้นโดยมีชิ้นส่วนที่เคลื่อนไหวน้อยลง ให้ X11 หายป่วย สิ่งนี้จะส่งผลต่อบริการที่อยู่ภายในศูนย์ข้อมูลอย่างไร หลายอย่างขึ้นอยู่กับว่าความล้มเหลวนั้นมีลักษณะอย่างไร
หากความล้มเหลวดี ก็จะถูกจับที่ระดับอัตโนมัติของ BFD เดียวกัน ระบบอัตโนมัติจะวางข้อต่อที่เป็นปัญหาอย่างมีความสุขและแยกปัญหาออก จากนั้นทุกอย่างก็เรียบร้อยดี เรามีเส้นทางมากมาย การจราจรจะถูกเปลี่ยนเส้นทางไปยังเส้นทางอื่นทันที และบริการต่างๆ จะไม่สังเกตเห็นอะไรเลย นี่เป็นสคริปต์ที่ดี
สถานการณ์ที่ไม่ดีคือถ้าเราขาดทุนอย่างต่อเนื่อง และระบบอัตโนมัติไม่สังเกตเห็นปัญหา เพื่อทำความเข้าใจว่าสิ่งนี้ส่งผลต่อแอปพลิเคชันอย่างไร เราจะต้องใช้เวลาเล็กน้อยเพื่อหารือเกี่ยวกับการทำงานของ TCP
ฉันหวังว่าฉันจะไม่ทำให้ใครตกใจกับข้อมูลนี้: TCP เป็นโปรโตคอลยืนยันการส่งสัญญาณ นั่นคือในกรณีที่ง่ายที่สุด ผู้ส่งจะส่งแพ็กเก็ตสองแพ็กเก็ตและได้รับแอคสะสมจากแพ็กเก็ตเหล่านั้น: "ฉันได้รับสองแพ็กเก็ต"
หลังจากนั้นเขาจะส่งอีกสองซอง และสถานการณ์จะเกิดขึ้นซ้ำอีก ฉันขอโทษล่วงหน้าเพื่อทำให้ง่ายขึ้น สถานการณ์นี้ถูกต้องหากหน้าต่าง (จำนวนแพ็กเก็ตที่กำลังบิน) เป็นสอง แน่นอนว่าในกรณีทั่วไปไม่จำเป็นต้องเป็นเช่นนั้นเสมอไป แต่ขนาดของหน้าต่างไม่ส่งผลต่อบริบทการส่งต่อแพ็กเก็ต
จะเกิดอะไรขึ้นถ้าเราสูญเสียแพ็กเก็ต 3? ในกรณีนี้ ผู้รับจะได้รับแพ็กเก็ต 1, 2 และ 4 และเขาจะแจ้งให้ผู้ส่งทราบอย่างชัดเจนโดยใช้ตัวเลือก SACK: “คุณรู้ไหม มีสามคนมาถึง แต่ตรงกลางหายไป” เขาพูดว่า "อัก 2 กระสอบ 4"
ในขณะนี้ผู้ส่งจะทำซ้ำแพ็คเก็ตที่สูญหายโดยไม่มีปัญหาใด ๆ
แต่ถ้าแพ็กเก็ตสุดท้ายในหน้าต่างหายไป สถานการณ์จะดูแตกต่างไปจากเดิมอย่างสิ้นเชิง
ผู้รับจะได้รับสามแพ็กเก็ตแรกและอันดับแรกเริ่มรอ ด้วยการปรับปรุงประสิทธิภาพบางอย่างใน TCP stack ของเคอร์เนล Linux ระบบจะรอแพ็กเก็ตที่จับคู่ เว้นแต่ว่าแฟล็กจะระบุอย่างชัดเจนว่าเป็นแพ็กเก็ตสุดท้ายหรือสิ่งที่คล้ายกัน จะรอจนกว่าการหมดเวลา ACK ล่าช้าจะหมดลง จากนั้นจึงส่งการตอบรับไปยังแพ็กเก็ตสามชุดแรก แต่ตอนนี้ผู้ส่งจะรอ เขาไม่รู้ว่าพัสดุชิ้นที่สี่สูญหายหรือกำลังจะมาถึง และเพื่อไม่ให้เครือข่ายทำงานหนักเกินไป เครือข่ายจะพยายามรอตัวบ่งชี้ที่ชัดเจนว่าแพ็กเก็ตสูญหาย หรือรอให้การหมดเวลาของ RTO หมดอายุ
การหมดเวลา RTO คืออะไร นี่คือค่าสูงสุดของ RTT ที่คำนวณโดยสแต็ก TCP และค่าคงที่บางส่วน นี่คือค่าคงที่แบบใดตอนนี้เราจะหารือกัน
แต่สิ่งสำคัญคือถ้าเราโชคไม่ดีอีกครั้งและแพ็กเก็ตที่สี่หายไปอีกครั้ง RTO จะเพิ่มเป็นสองเท่า นั่นคือการพยายามแต่ละครั้งที่ไม่สำเร็จหมายถึงการหมดเวลาเพิ่มขึ้นเป็นสองเท่า
ทีนี้ลองดูว่าฐานนี้เท่ากับอะไร. ตามค่าเริ่มต้น RTO ขั้นต่ำคือ 200 ms นี่คือ RTO ขั้นต่ำสำหรับแพ็คเกจข้อมูล สำหรับแพ็กเก็ต SYN จะต่างกัน 1 วินาที อย่างที่คุณเห็น แม้แต่ความพยายามครั้งแรกในการส่งแพ็คเก็ตอีกครั้งก็ยังใช้เวลานานกว่า RTT ภายในศูนย์ข้อมูลถึง 100 เท่า
ตอนนี้เรากลับมาที่สถานการณ์ของเราอีกครั้ง เกิดอะไรขึ้นกับบริการ? บริการเริ่มสูญเสียแพ็กเก็ต ปล่อยให้บริการโชคดีแบบมีเงื่อนไขในตอนแรกและทำบางสิ่งหายไปกลางหน้าต่าง จากนั้นจะได้รับ SACK และส่งแพ็กเก็ตที่สูญหายอีกครั้ง
แต่หากโชคร้ายเกิดขึ้นซ้ำ เราก็มี RTO มีอะไรสำคัญที่นี่? ใช่ เรามีเส้นทางมากมายในเครือข่ายของเรา แต่การรับส่งข้อมูล TCP ของการเชื่อมต่อ TCP หนึ่งรายการจะยังคงผ่านสแต็กที่เสียหายเหมือนเดิม การสูญเสียแพ็คเก็ตโดยมีเงื่อนไขว่า X11 อันมหัศจรรย์ของเรานี้ไม่ได้ออกไปเองไม่นำไปสู่การรับส่งข้อมูลที่ไหลเข้าสู่พื้นที่ที่ไม่มีปัญหา เรากำลังพยายามส่งแพ็กเก็ตผ่านสแต็กที่เสียหายเดียวกัน สิ่งนี้นำไปสู่ความล้มเหลวแบบเรียงซ้อน: ศูนย์ข้อมูลคือชุดของแอปพลิเคชันที่มีการโต้ตอบ และการเชื่อมต่อ TCP บางส่วนของแอปพลิเคชันเหล่านี้ทั้งหมดเริ่มลดลง เนื่องจาก superspine ส่งผลกระทบต่อแอปพลิเคชันทั้งหมดที่มีอยู่ภายในศูนย์ข้อมูล ดังสุภาษิตที่ว่า: ถ้าคุณไม่สวมรองเท้าม้า ม้าก็ง่อยไป ม้าง่อย - ไม่ได้ส่งรายงาน ไม่ได้ส่งรายงาน - เราแพ้สงคราม เฉพาะที่นี่เท่านั้นที่นับได้เป็นวินาทีนับจากช่วงเวลาที่ปัญหาเกิดขึ้นจนถึงขั้นเสื่อมโทรมที่บริการเริ่มรู้สึก ซึ่งหมายความว่าผู้ใช้อาจพลาดบางสิ่งบางอย่างไป
มีโซลูชันแบบคลาสสิกสองโซลูชันที่เสริมซึ่งกันและกัน ประการแรกคือบริการที่พยายามใส่ฟางเข้าไปและแก้ไขปัญหาเช่นนี้: “มาปรับแต่งบางอย่างในสแต็ก TCP กันดีกว่า มาทำการหมดเวลาในระดับแอปพลิเคชันหรือเซสชัน TCP ระยะยาวด้วยการตรวจสุขภาพภายในกันเถอะ” ปัญหาคือวิธีแก้ปัญหาดังกล่าว: ก) ไม่ปรับขนาดเลย; b) มีการตรวจสอบไม่ดีนัก นั่นคือแม้ว่าบริการจะกำหนดค่า TCP Stack ในลักษณะที่ทำให้ดีขึ้นโดยไม่ตั้งใจ ประการแรกไม่น่าจะใช้ได้กับแอปพลิเคชันทั้งหมดและศูนย์ข้อมูลทั้งหมด และประการที่สอง เป็นไปได้มากว่าจะไม่เข้าใจว่าได้ทำเสร็จแล้ว อย่างถูกต้องและสิ่งที่ไม่ นั่นคือใช้งานได้ แต่ใช้งานได้ไม่ดีและไม่ปรับขนาด และหากเกิดปัญหาเครือข่ายใครจะตำหนิ? แน่นอนว่า นค. นค.ทำอะไร?
บริการหลายอย่างเชื่อว่าในงาน NOC เกิดขึ้นเช่นนี้ แต่พูดตามตรงไม่ใช่แค่นั้นเท่านั้น
NOC ในรูปแบบคลาสสิกมีส่วนร่วมในการพัฒนาระบบตรวจสอบจำนวนมาก เหล่านี้เป็นทั้งการตรวจสอบกล่องดำและกล่องสีขาว เกี่ยวกับตัวอย่างการติดตามกระดูกสันหลังกล่องดำ Alexander Klimenko ใน Next Hop สุดท้าย อย่างไรก็ตาม การตรวจสอบนี้ใช้งานได้ แต่การตรวจสอบในอุดมคติก็ยังต้องมีการหน่วงเวลา โดยปกติจะใช้เวลาไม่กี่นาที หลังจากที่ดับลงแล้ว วิศวกรที่ปฏิบัติหน้าที่ต้องใช้เวลาในการตรวจสอบการทำงานอีกครั้ง ระบุตำแหน่งปัญหา และดับไฟบริเวณที่เกิดปัญหา นั่นคือในกรณีที่ดีที่สุด การรักษาปัญหาจะใช้เวลา 5 นาที ในกรณีที่เลวร้ายที่สุดคือ 20 นาที หากไม่ชัดเจนว่าความเสียหายเกิดขึ้นที่ใด เห็นได้ชัดว่าตลอดเวลานี้ - 5 หรือ 20 นาที - บริการของเราจะได้รับผลกระทบต่อไปซึ่งอาจไม่ดี
คุณอยากจะรับอะไรจริงๆ? เรามีหลายวิธี และปัญหาก็เกิดขึ้นแน่นอนเพราะกระแส TCP ที่โชคร้ายยังคงใช้เส้นทางเดิม เราต้องการบางสิ่งบางอย่างที่จะช่วยให้เราสามารถใช้หลายเส้นทางภายในการเชื่อมต่อ TCP เดียว ดูเหมือนว่าเราจะมีทางออก มี TCP ซึ่งเรียกว่า TCP แบบหลายเส้นทาง นั่นคือ TCP สำหรับหลายเส้นทาง จริงอยู่ที่ได้รับการพัฒนาเพื่องานที่แตกต่างไปจากเดิมอย่างสิ้นเชิง - สำหรับสมาร์ทโฟนที่มีอุปกรณ์เครือข่ายหลายตัว เพื่อเพิ่มการถ่ายโอนหรือสร้างโหมดหลัก/สำรอง จึงมีการพัฒนากลไกที่สร้างหลายเธรด (เซสชัน) ให้กับแอปพลิเคชันอย่างโปร่งใส และช่วยให้คุณสามารถสลับระหว่างเธรดเหล่านั้นได้ในกรณีที่เกิดความล้มเหลว หรืออย่างที่ฉันพูดไป เพิ่มสตรีคให้สูงสุด
แต่มีความแตกต่างกันนิดหน่อยที่นี่ เพื่อให้เข้าใจว่ามันคืออะไร เราจะต้องดูว่าเธรดถูกสร้างขึ้นมาอย่างไร
มีการติดตั้งเธรดตามลำดับ เธรดแรกจะถูกติดตั้งก่อน เธรดที่ตามมาจะถูกตั้งค่าโดยใช้คุกกี้ที่ได้รับการตกลงไว้แล้วภายในเธรดนั้น และนี่คือปัญหา
ปัญหาคือถ้าเธรดแรกไม่สร้างตัวเอง เธรดที่สองและสามจะไม่เกิดขึ้น นั่นคือ TCP แบบหลายเส้นทางไม่สามารถแก้ปัญหาการสูญเสียแพ็กเก็ต SYN ในโฟลว์แรกได้ และหาก SYN สูญหาย TCP แบบหลายเส้นทางจะกลายเป็น TCP ปกติ ซึ่งหมายความว่าในสภาพแวดล้อมของศูนย์ข้อมูล จะไม่ช่วยให้เราแก้ไขปัญหาความสูญเสียในโรงงาน และเรียนรู้การใช้หลายเส้นทางในกรณีที่เกิดความล้มเหลว
มีอะไรช่วยเราได้บ้าง? จากชื่อเรื่องแล้วบางท่านเดาได้ว่าช่องสำคัญในเรื่องราวต่อไปของเราคือช่องส่วนหัวของป้ายกำกับโฟลว์ IPv6 อันที่จริงนี่คือฟิลด์ที่ปรากฏใน v6 แต่ไม่ได้อยู่ใน v4 มันกินพื้นที่ 20 บิต และมีการถกเถียงกันเรื่องการใช้งานมาเป็นเวลานาน สิ่งนี้น่าสนใจมาก - มีข้อพิพาทมีบางอย่างได้รับการแก้ไขภายใน RFC และในเวลาเดียวกันการใช้งานก็ปรากฏในเคอร์เนล Linux ซึ่งไม่มีการบันทึกไว้ที่ใดเลย
ฉันขอเชิญคุณไปกับฉันในการสอบสวนเล็กน้อย เรามาดูกันว่าเกิดอะไรขึ้นในเคอร์เนล Linux ในช่วงไม่กี่ปีที่ผ่านมา
ปี 2014 วิศวกรจากบริษัทขนาดใหญ่และเป็นที่เคารพแห่งหนึ่งได้เพิ่มฟังก์ชันการทำงานของเคอร์เนล Linux โดยขึ้นอยู่กับค่าโฟลว์เลเบลบนแฮชของซ็อกเก็ต พวกเขากำลังพยายามแก้ไขอะไรที่นี่ สิ่งนี้เกี่ยวข้องกับ RFC 6438 ซึ่งกล่าวถึงปัญหาต่อไปนี้ ภายในศูนย์ข้อมูล IPv4 มักจะถูกห่อหุ้มไว้ในแพ็กเก็ต IPv6 เนื่องจากตัวโรงงานเองคือ IPv6 แต่ IPv4 จะต้องได้รับจากภายนอก เป็นเวลานานที่มีปัญหากับสวิตช์ที่ไม่สามารถดูภายใต้ส่วนหัว IP สองตัวเพื่อไปที่ TCP หรือ UDP และค้นหา src_ports, dst_ports ที่นั่น ปรากฎว่าแฮชนั้นเกือบจะได้รับการแก้ไขแล้วหากคุณดูที่ส่วนหัว IP สองอันแรก เพื่อหลีกเลี่ยงปัญหานี้ เพื่อให้การปรับสมดุลของการรับส่งข้อมูลแบบห่อหุ้มนี้ทำงานอย่างถูกต้อง จึงเสนอให้เพิ่มแฮชของแพ็กเก็ตที่ห่อหุ้ม 5 สิ่งอันดับเข้ากับค่าของฟิลด์ป้ายกำกับโฟลว์ โดยประมาณสิ่งเดียวกันนี้เกิดขึ้นกับแผนการห่อหุ้มอื่นๆ สำหรับ UDP สำหรับ GRE ส่วนอย่างหลังใช้ฟิลด์คีย์ GRE ไม่ทางใดก็ทางหนึ่ง เป้าหมายที่นี่ชัดเจน และอย่างน้อย ณ เวลานั้น มันก็มีประโยชน์
ในปี 2015 แพตช์ใหม่มาจากวิศวกรผู้เป็นที่เคารพคนเดิม เขาน่าสนใจมาก มันบอกว่าต่อไปนี้ - เราจะสุ่มแฮชในกรณีที่เหตุการณ์การกำหนดเส้นทางเป็นลบ เหตุการณ์การกำหนดเส้นทางเชิงลบคืออะไร? นี่คือ RTO ที่เราคุยกันไปก่อนหน้านี้ กล่าวคือ การสูญเสียส่วนท้ายของหน้าต่างถือเป็นเหตุการณ์เชิงลบอย่างแท้จริง จริงอยู่ที่มันค่อนข้างยากที่จะเดาว่านี่คือสิ่งนี้
ปี 2016 เป็นอีกหนึ่งบริษัทที่มีชื่อเสียงและใหญ่โตเช่นกัน โดยจะแยกชิ้นส่วนไม้ค้ำยันสุดท้ายและทำให้แฮชซึ่งก่อนหน้านี้เราได้สุ่มไว้ บัดนี้มีการเปลี่ยนแปลงสำหรับการส่งสัญญาณ SYN ซ้ำแต่ละครั้ง และหลังจากหมดเวลา RTO แต่ละครั้ง และในจดหมายฉบับนี้ เป็นครั้งแรกและครั้งสุดท้ายที่มีการระบุเป้าหมายสูงสุด - เพื่อให้แน่ใจว่าการรับส่งข้อมูลในกรณีที่เกิดการสูญเสียหรือความแออัดของช่องสัญญาณมีความสามารถในการเปลี่ยนเส้นทางอย่างนุ่มนวลและใช้หลายเส้นทาง แน่นอนว่าหลังจากนี้ก็มีสิ่งพิมพ์มากมาย คุณสามารถค้นหาได้ง่าย
แม้ว่าจะไม่ได้ แต่คุณทำไม่ได้เนื่องจากไม่มีการตีพิมพ์ในหัวข้อนี้เลย แต่เรารู้!
และถ้าคุณไม่เข้าใจสิ่งที่ทำไปแล้วฉันจะบอกคุณตอนนี้
ทำอะไรไปแล้ว มีการเพิ่มฟังก์ชันการทำงานใดบ้างในเคอร์เนล Linux? txhash เปลี่ยนเป็นค่าสุ่มหลังจากแต่ละเหตุการณ์ RTO นี่เป็นผลลัพธ์เชิงลบอย่างมากของการกำหนดเส้นทาง แฮชขึ้นอยู่กับ txhash นี้ และป้ายกำกับโฟลว์ขึ้นอยู่กับแฮช skb มีการคำนวณฟังก์ชันบางอย่างที่นี่ ไม่สามารถวางรายละเอียดทั้งหมดไว้ในสไลด์เดียวได้ หากใครสงสัยสามารถเข้าไปตรวจสอบเคอร์เนลโค้ดได้เลย
มีอะไรสำคัญที่นี่? ค่าของช่องป้ายกำกับโฟลว์จะเปลี่ยนเป็นตัวเลขสุ่มหลังจาก RTO แต่ละรายการ สิ่งนี้ส่งผลต่อสตรีม TCP ที่โชคร้ายของเราอย่างไร
หาก SACK เกิดขึ้น จะไม่มีการเปลี่ยนแปลงใดๆ เนื่องจากเรากำลังพยายามส่งแพ็กเก็ตที่ทราบที่สูญหายอีกครั้ง จนถึงตอนนี้ดีมาก
แต่ในกรณีของ RTO หากเราได้เพิ่มป้ายกำกับโฟลว์ให้กับฟังก์ชันแฮชบน ToR แล้ว การรับส่งข้อมูลอาจใช้เส้นทางอื่น และยิ่งมีช่องทางมากเท่าไรก็ยิ่งมีโอกาสพบเส้นทางที่ไม่ได้รับผลกระทบจากความล้มเหลวในอุปกรณ์เฉพาะมากขึ้นเท่านั้น
ปัญหาหนึ่งยังคงอยู่ - RTO แน่นอนว่ายังมีเส้นทางอื่นอยู่ แต่ต้องเสียเวลาไปมาก 200ms ถือว่าเยอะมาก วินาทีนั้นช่างดุร้ายจริงๆ ก่อนหน้านี้ ฉันพูดถึงการหมดเวลาที่มีการกำหนดค่าบริการไว้ ดังนั้นวินาทีคือการหมดเวลาซึ่งโดยปกติจะกำหนดค่าโดยบริการในระดับแอปพลิเคชันและในกรณีนี้บริการจะค่อนข้างถูกต้องด้วยซ้ำ ฉันขอย้ำอีกครั้งว่า RTT ที่แท้จริงภายในศูนย์ข้อมูลสมัยใหม่นั้นอยู่ที่ประมาณ 1 มิลลิวินาที
คุณสามารถทำอะไรกับการหมดเวลา RTO? การหมดเวลาซึ่งรับผิดชอบ RTO ในกรณีที่แพ็กเก็ตข้อมูลสูญหายสามารถกำหนดค่าได้ค่อนข้างง่ายจากพื้นที่ผู้ใช้: มียูทิลิตี้ IP และหนึ่งในพารามิเตอร์มี rto_min เดียวกัน เมื่อพิจารณาว่า RTO นั้นจำเป็นต้องได้รับการปรับไม่ใช่ทั่วโลก แต่สำหรับคำนำหน้าที่กำหนด กลไกดังกล่าวก็ดูค่อนข้างจะใช้งานได้
จริงด้วย SYN_RTO ทุกอย่างค่อนข้างแย่ลง มันถูกตอกย้ำโดยธรรมชาติ เคอร์เนลมีค่าคงที่ 1 วินาทีเท่านั้นเอง คุณไม่สามารถเข้าถึงได้จากพื้นที่ผู้ใช้ มีทางเดียวเท่านั้น
eBPF มาช่วยเหลือ พูดง่ายๆ ก็คือโปรแกรม C เล็กๆ เหล่านี้ สามารถแทรกลงใน hooks ในตำแหน่งต่างๆ ในการดำเนินการของเคอร์เนลสแต็กและสแต็ก TCP ซึ่งคุณสามารถเปลี่ยนการตั้งค่าจำนวนมากได้ โดยทั่วไป eBPF ถือเป็นแนวโน้มระยะยาว แทนที่จะตัดพารามิเตอร์ sysctl ใหม่หลายสิบตัวและขยายยูทิลิตี้ IP การเคลื่อนไหวกำลังมุ่งสู่ eBPF และขยายฟังก์ชันการทำงาน เมื่อใช้ eBPF คุณสามารถเปลี่ยนการควบคุมความแออัดและการตั้งค่า TCP อื่นๆ แบบไดนามิกได้
แต่สิ่งสำคัญสำหรับเราคือสามารถใช้เพื่อเปลี่ยนค่า SYN_RTO ได้ นอกจากนี้ยังมีตัวอย่างที่โพสต์ต่อสาธารณะ: . นี่ทำอะไรไปแล้วบ้าง? ตัวอย่างนี้ใช้งานได้ แต่ในตัวมันเองนั้นหยาบมาก สมมติว่าภายในศูนย์ข้อมูลเราเปรียบเทียบ 44 บิตแรก หากตรงกัน แสดงว่าเราอยู่ในศูนย์ข้อมูล และในกรณีนี้เราเปลี่ยนค่าการหมดเวลาของ SYN_RTO เป็น 4ms งานเดียวกันสามารถทำได้อย่างหรูหรายิ่งขึ้น แต่ตัวอย่างง่ายๆ นี้แสดงให้เห็นว่านี่คือ a) เป็นไปได้; b) ค่อนข้างง่าย
เรารู้อะไรบ้างแล้ว? ความจริงที่ว่าสถาปัตยกรรมระนาบช่วยให้สามารถปรับขนาดได้ กลับกลายเป็นว่ามีประโยชน์อย่างยิ่งสำหรับเราเมื่อเราเปิดใช้งานป้ายกำกับโฟลว์บน ToR และรับความสามารถในการโฟลว์รอบๆ พื้นที่ที่มีปัญหา วิธีที่ดีที่สุดในการลดค่า RTO และ SYN-RTO คือการใช้โปรแกรม eBPF คำถามยังคงอยู่: ปลอดภัยไหมที่จะใช้ป้ายกำกับโฟลว์เพื่อปรับสมดุล และมีความแตกต่างกันนิดหน่อยที่นี่
สมมติว่าคุณมีบริการบนเครือข่ายของคุณที่ใช้งานแบบ Anycast น่าเสียดายที่ฉันไม่มีเวลาอธิบายรายละเอียดว่า Anycast คืออะไร แต่เป็นบริการแบบกระจายที่มีเซิร์ฟเวอร์ทางกายภาพที่แตกต่างกันซึ่งสามารถเข้าถึงได้ผ่านที่อยู่ IP เดียวกัน และนี่คือปัญหาที่เป็นไปได้: เหตุการณ์ RTO สามารถเกิดขึ้นได้ไม่เพียงแต่เมื่อมีการจราจรผ่านแฟบริคเท่านั้น นอกจากนี้ยังสามารถเกิดขึ้นได้ที่ระดับบัฟเฟอร์ ToR: เมื่อมีเหตุการณ์ incast เกิดขึ้น ก็สามารถเกิดขึ้นได้บนโฮสต์เมื่อโฮสต์ทำบางสิ่งบางอย่างรั่วไหล เมื่อเหตุการณ์ RTO เกิดขึ้นและเปลี่ยนป้ายกำกับโฟลว์ ในกรณีนี้ การรับส่งข้อมูลสามารถไปที่อินสแตนซ์ Anycast อื่นได้ สมมติว่านี่คือ anycast แบบมีสถานะ ซึ่งมีสถานะการเชื่อมต่อ - อาจเป็น L3 Balancer หรือบริการอื่นๆ จากนั้นปัญหาก็เกิดขึ้น เนื่องจากหลังจาก RTO การเชื่อมต่อ TCP มาถึงเซิร์ฟเวอร์ ซึ่งไม่รู้อะไรเลยเกี่ยวกับการเชื่อมต่อ TCP นี้ และถ้าเราไม่มีการแชร์สถานะระหว่างเซิร์ฟเวอร์ anycast การรับส่งข้อมูลดังกล่าวจะถูกยกเลิกและการเชื่อมต่อ TCP จะเสียหาย
คุณสามารถทำอะไรที่นี่? ภายในสภาพแวดล้อมที่มีการควบคุม ซึ่งคุณเปิดใช้งานการปรับสมดุลโฟลว์เลเบล คุณจะต้องบันทึกค่าของโฟลว์เลเบลเมื่อเข้าถึงเซิร์ฟเวอร์ anycast วิธีที่ง่ายที่สุดคือทำผ่านโปรแกรม eBPF เดียวกัน แต่นี่คือจุดสำคัญมาก - จะทำอย่างไรถ้าคุณไม่ใช้งานเครือข่ายศูนย์ข้อมูล แต่เป็นผู้ให้บริการโทรคมนาคม? นี่เป็นปัญหาของคุณเช่นกัน: เริ่มต้นด้วย Juniper และ Arista บางเวอร์ชัน โดยจะรวมป้ายกำกับโฟลว์ไว้ในฟังก์ชันแฮชตามค่าเริ่มต้น - พูดตามตรงด้วยเหตุผลที่ไม่ชัดเจนสำหรับฉัน นี่อาจทำให้คุณยกเลิกการเชื่อมต่อ TCP จากผู้ใช้ที่ผ่านเครือข่ายของคุณ ดังนั้นฉันขอแนะนำให้ตรวจสอบการตั้งค่าเราเตอร์ของคุณที่นี่
ไม่ทางใดก็ทางหนึ่งสำหรับฉันดูเหมือนว่าเราพร้อมที่จะไปสู่การทดลองแล้ว
เมื่อเราเปิดใช้งานป้ายกำกับโฟลว์บน ToR และเตรียมตัวแทน eBPF ซึ่งขณะนี้ใช้งานอยู่บนโฮสต์ เราตัดสินใจว่าจะไม่รอให้เกิดความล้มเหลวครั้งใหญ่ครั้งต่อไป แต่จะดำเนินการระเบิดแบบควบคุม เราใช้ ToR ซึ่งมีสี่อัปลิงก์ และตั้งค่าดรอปในหนึ่งในนั้น พวกเขาวาดกฎและพูดว่า - ตอนนี้คุณกำลังสูญเสียแพ็กเก็ตทั้งหมด อย่างที่คุณเห็นทางด้านซ้าย เรามีการตรวจสอบต่อแพ็กเก็ต ซึ่งลดลงเหลือ 75% นั่นคือ 25% ของแพ็กเก็ตสูญหาย ทางด้านขวาคือกราฟของบริการที่อยู่เบื้องหลัง ToR นี้ โดยพื้นฐานแล้ว นี่คือกราฟการรับส่งข้อมูลของอินเทอร์เฟซกับเซิร์ฟเวอร์ภายในแร็ค อย่างที่คุณเห็น พวกมันจมลงไปอีก เหตุใดราคาจึงลดลง ไม่ใช่ 25% แต่ในบางกรณีลดลง 3-4 เท่า หากการเชื่อมต่อ TCP โชคไม่ดี ก็จะพยายามเข้าถึงผ่านทางแยกที่เสียหายต่อไป สิ่งนี้รุนแรงขึ้นจากพฤติกรรมทั่วไปของบริการภายใน DC - สำหรับคำขอของผู้ใช้หนึ่งคำขอ N คำขอไปยังบริการภายในจะถูกสร้างขึ้น และการตอบสนองจะไปที่ผู้ใช้เมื่อแหล่งข้อมูลทั้งหมดตอบสนอง หรือเมื่อเกิดการหมดเวลาในแอปพลิเคชัน ระดับซึ่งยังต้องมีการกำหนดค่า นั่นคือทุกอย่างแย่มากมาก
ขณะนี้เป็นการทดสอบเดียวกัน แต่เปิดใช้ค่าป้ายกำกับโฟลว์แล้ว อย่างที่คุณเห็น ทางด้านซ้ายการตรวจสอบแบทช์ของเราลดลง 25% เท่าเดิม สิ่งนี้ถูกต้องอย่างแน่นอน เนื่องจากไม่ทราบอะไรเลยเกี่ยวกับการส่งสัญญาณซ้ำ โดยจะส่งแพ็กเก็ตและเพียงนับอัตราส่วนของจำนวนแพ็กเก็ตที่ส่งและสูญหาย
และทางขวามือคือตารางการให้บริการ คุณจะไม่พบผลกระทบของข้อต่อที่มีปัญหาที่นี่ ในเสี้ยววินาทีเดียวกันนั้น การรับส่งข้อมูลจะไหลจากพื้นที่ที่มีปัญหาไปยังอัปลิงก์ที่เหลืออีกสามรายการที่ไม่ได้รับผลกระทบจากปัญหา เรามีเครือข่ายที่รักษาตัวเองได้
นี่เป็นสไลด์สุดท้ายของฉัน ถึงเวลาสรุปแล้ว ตอนนี้ ฉันหวังว่าคุณจะรู้วิธีสร้างเครือข่ายศูนย์ข้อมูลที่สามารถซ่อมแซมตัวเองได้ คุณไม่จำเป็นต้องผ่านไฟล์เก็บถาวรเคอร์เนล Linux และค้นหาแพตช์พิเศษที่นั่น คุณรู้ว่าป้ายกำกับ Flow ในกรณีนี้ช่วยแก้ปัญหาได้ แต่คุณต้องเข้าใกล้กลไกนี้อย่างระมัดระวัง และฉันขอย้ำอีกครั้งว่าหากคุณเป็นผู้ให้บริการโทรคมนาคม คุณไม่ควรใช้โฟลว์เลเบลเป็นฟังก์ชันแฮช มิฉะนั้น คุณจะรบกวนเซสชันของผู้ใช้ของคุณ
วิศวกรเครือข่ายจะต้องผ่านการเปลี่ยนแปลงแนวคิด: เครือข่ายไม่ได้เริ่มต้นจาก ToR ไม่ใช่จากอุปกรณ์เครือข่าย แต่เริ่มต้นจากโฮสต์ ตัวอย่างที่ชัดเจนพอสมควรคือวิธีที่เราใช้ eBPF ทั้งเพื่อเปลี่ยน RTO และแก้ไขโฟลว์เลเบลไปยังบริการ Anycast
กลไกฉลากโฟลว์เหมาะสำหรับการใช้งานอื่นๆ ภายในส่วนการจัดการที่ได้รับการควบคุมอย่างแน่นอน นี่อาจเป็นการรับส่งข้อมูลระหว่างศูนย์ข้อมูล หรือคุณสามารถใช้กลไกดังกล่าวในลักษณะพิเศษในการจัดการการรับส่งข้อมูลขาออกได้ แต่ฉันจะบอกคุณเกี่ยวกับเรื่องนี้ฉันหวังว่าในครั้งต่อไป ขอบคุณมากสำหรับความสนใจของคุณ
ที่มา: will.com