ที่อยู่ปลายทางสำหรับเลเยอร์ 3 LACP ทำงานได้อย่างไรและโดยเฉพาะ

จากคำถามก่อนหน้านี้เมื่อปีที่แล้ว ( Multiplexed 1 Gbps Ethernet? ) ฉันออกไปและตั้งค่าแร็คใหม่ด้วย ISP ใหม่พร้อมลิงก์ LACP ทั่วทุกที่ เราต้องการสิ่งนี้เพราะเรามีเซิร์ฟเวอร์ส่วนบุคคล (แอปพลิเคชั่นหนึ่งตัว, IP หนึ่งตัว) ที่ให้บริการคอมพิวเตอร์ไคลเอนต์นับพันทั่วอินเทอร์เน็ตเกินกว่า 1Gbps สะสม

แนวคิด LACP นี้ควรจะให้เราทำลายสิ่งกีดขวาง 1Gbps โดยไม่ต้องเสียเงินมหาศาลกับสวิตช์ 10Gee และ NIC น่าเสียดายที่ฉันพบปัญหาเกี่ยวกับการกระจายการรับส่งข้อมูลขาออก (สิ่งนี้แม้จะมีคำเตือนของ Kevin Kuphal ในคำถามที่เชื่อมโยงข้างต้น)

เราเตอร์ของ ISP นั้นเป็น Cisco จากบางประเภท (ฉันอนุมานได้ว่าจากที่อยู่ MAC) สวิตช์ของฉันคือ HP ProCurve 2510G-24 และเซิร์ฟเวอร์ก็คือ HP DL 380 G5 ที่ใช้ Debian Lenny เซิร์ฟเวอร์ตัวเดียวคือโหมดแสตนด์บาย แอปพลิเคชันของเราไม่สามารถทำคลัสเตอร์ได้ นี่คือแผนภาพเครือข่ายที่เรียบง่ายซึ่งรวมโหนดเครือข่ายที่เกี่ยวข้องทั้งหมดด้วย IP, MAC และอินเทอร์เฟซ

ในขณะที่มันมีรายละเอียดทั้งหมดมันค่อนข้างยากที่จะทำงานและอธิบายปัญหาของฉัน ดังนั้นเพื่อความเรียบง่ายนี่คือแผนภาพเครือข่ายที่ลดลงไปยังโหนดและการเชื่อมโยงทางกายภาพ

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

ด้วยการค้นหาของ google และเวลา RTMF จำนวนมากเกี่ยวกับการเชื่อม NIC ของลินุกซ์ฉันค้นพบว่าฉันสามารถควบคุมการเชื่อม NIC โดยการปรับเปลี่ยน /etc/modules

# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1

loop

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

เราต้องการปริมาณการใช้งานที่มากกว่าทั้งการเชื่อมโยงทางกายภาพ หลังจากอ่านและอ่านคู่มือการจัดการและการกำหนดค่าของ 2510G-24 ฉันพบว่า:

[LACP ใช้] คู่ที่อยู่ปลายทาง (SA / DA) สำหรับการกระจายทราฟฟิกขาออกบนลิงก์ที่มีลำต้น SA / DA (ที่อยู่ต้นทาง / ที่อยู่ปลายทาง) ทำให้สวิตช์กระจายการรับส่งข้อมูลขาออกไปยังลิงก์ภายในกลุ่มลำตัวบนพื้นฐานของคู่ที่มา / ปลายทาง นั่นคือสวิตช์จะส่งทราฟฟิกจากแหล่งที่อยู่เดียวกันไปยังที่อยู่ปลายทางเดียวกันผ่านลิงก์ที่มีลำต้นเดียวกันและส่งทราฟฟิกจากแหล่งที่อยู่เดียวกันไปยังที่อยู่ปลายทางที่แตกต่างกันผ่านลิงก์ที่แตกต่างกัน ลิงก์ในลำต้น

ดูเหมือนว่าลิงก์ที่ถูกผูกมัดจะแสดงที่อยู่ MAC เพียงอันเดียวดังนั้นเส้นทางของเซิร์ฟเวอร์ต่อเราเตอร์ของฉันจึงต้องอยู่เหนือเส้นทางเดียวจาก switch-to-router เนื่องจากสวิตช์มองเห็น แต่มี MAC หนึ่งอัน (ไม่ใช่สองอัน - หนึ่งอันจาก แต่ละพอร์ต) สำหรับลิงก์ทั้ง LACP

เข้าใจแล้ว. แต่นี่คือสิ่งที่ฉันต้องการ:

สวิตช์ HP ProCurve ที่แพงกว่านั้นคือ 2910al ใช้ที่อยู่ต้นทางและปลายทางระดับ 3 ในแฮช จากส่วน "การกระจายทราฟฟิกขาออกข้ามลิงค์ที่มีการเชื่อมต่อแบบ Trunked" ของคู่มือการจัดการและการกำหนดค่าของ ProCurve 2910al :

การกระจายที่แท้จริงของทราฟฟิกผ่านทางลำต้นขึ้นอยู่กับการคำนวณโดยใช้บิตจากที่อยู่ต้นทางและที่อยู่ปลายทาง เมื่อมีที่อยู่ IP การคำนวณจะรวมห้าบิตสุดท้ายของที่อยู่ IP และที่อยู่ IP ปลายทางมิฉะนั้นจะใช้ที่อยู่ MAC

ตกลง. ดังนั้นเพื่อให้การทำงานในแบบที่ฉันต้องการที่อยู่ปลายทางเป็นกุญแจสำคัญเนื่องจากที่อยู่ต้นทางของฉันได้รับการแก้ไข สิ่งนี้นำไปสู่คำถามของฉัน:

การแฮชของเลเยอร์ 3 LACP นั้นทำงานอย่างไร

ฉันจำเป็นต้องรู้ที่อยู่ปลายทางที่ใช้:

• IP ของลูกค้าปลายทางสุดท้ายหรือไม่
• หรือ IP ของเราเตอร์ปลายทางส่งผ่านฟิสิคัลลิงก์ถัดไป

เรายังไม่ได้ปิดและซื้อสวิตช์เปลี่ยน โปรดช่วยฉันเข้าใจอย่างถ่องแท้ว่าที่อยู่ปลายทางสำหรับเลเยอร์ 3 LACP นั้นเป็นหรือไม่ใช่สิ่งที่ฉันต้องการ การซื้อสวิตช์ที่ไร้ประโยชน์อื่นไม่ใช่ตัวเลือก

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

การได้รับมาตรฐาน 802.3ad นั้นพิสูจน์ได้ยากเพราะฉันไม่ยอมจ่ายเงิน ต้องบอกว่าฉันสามารถรวบรวมข้อมูลบางอย่างจากแหล่งข้อมูลกึ่งทางการที่ให้ความกระจ่างแก่สิ่งที่คุณกำลังมองหา ต่อการนำเสนอนี้จาก 2007 Ottawa, ON, CA IEEE High Speed ​​Study Group การประชุมมาตรฐาน 802.3ad ไม่ได้บังคับใช้อัลกอริทึมเฉพาะสำหรับ "ผู้จำหน่ายเฟรม":

มาตรฐานนี้ไม่ได้บังคับใช้อัลกอริทึมการกระจายเฉพาะใด ๆ อย่างไรก็ตามอัลกอริธึมการกระจายใด ๆ จะต้องทำให้แน่ใจว่าเมื่อ Frame ได้รับโดย Frame Collector ตามที่ระบุไว้ใน 43.2.3 อัลกอริทึมจะต้องไม่ก่อให้เกิด a) การเรียงลำดับของเฟรมผิดพลาดซึ่งเป็นส่วนหนึ่งของการสนทนาที่กำหนด . ความต้องการด้านบนเพื่อรักษาลำดับของเฟรมนั้นเป็นไปตามการทำให้แน่ใจว่าเฟรมทั้งหมดที่ประกอบด้วยการสนทนาที่กำหนดถูกส่งผ่านลิงก์เดียวตามลำดับที่ MAC Client สร้างขึ้น ดังนั้นข้อกำหนดนี้ไม่เกี่ยวข้องกับการเพิ่ม (หรือแก้ไข) ข้อมูลใด ๆ ไปยังเฟรม MAC หรือการบัฟเฟอร์หรือการประมวลผลในส่วนของ Frame Collector ที่สอดคล้องกันเพื่อสั่งซื้อเฟรมใหม่

ดังนั้นอัลกอริทึมใดก็ตามที่ไดร์เวอร์สวิตช์ / NIC ใช้เพื่อแจกจ่ายเฟรมที่ส่งจะต้องเป็นไปตามข้อกำหนดที่ระบุไว้ในงานนำเสนอนั้น (ซึ่งสันนิษฐานได้ว่าเป็นการอ้างอิงจากมาตรฐาน) ไม่มีการระบุอัลกอริทึมโดยเฉพาะเฉพาะพฤติกรรมที่เข้ากันได้ที่กำหนดไว้

แม้ว่าจะไม่ได้ระบุอัลกอริทึม แต่เราสามารถดูการใช้งานเฉพาะเพื่อให้เกิดความรู้สึกว่าอัลกอริทึมดังกล่าวทำงานอย่างไร ตัวอย่างเช่นไดรเวอร์ Linux kernel "bonding" มีนโยบายแฮชการส่งผ่าน 802.3ad ที่ใช้งานฟังก์ชัน (ดูที่ bonding.txt ในไดเร็กทอรี Documentation \ networking ของซอร์สเคอร์เนล):

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

สิ่งนี้ทำให้ทั้งที่อยู่ IP ต้นทางและปลายทางรวมถึงที่อยู่ MAC ต้นทางและปลายทางส่งผลต่อการเลือกพอร์ต

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

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

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

นโยบายแฮชการส่งข้อมูลอาจนำข้อมูลเลเยอร์ 4 (หมายเลขพอร์ต TCP / UDP) มาพิจารณาด้วยเช่นกันตราบใดที่มันยังคงรักษาข้อกำหนดในมาตรฐาน 802.3ad ไว้ อัลกอริทึมดังกล่าวอยู่ในเคอร์เนล Linux ตามที่คุณอ้างอิงในคำถามของคุณ ระวังว่าเอกสารสำหรับอัลกอริทึมนั้นเตือนว่าเนื่องจากการแตกแฟรกเมนต์การรับส่งข้อมูลอาจไม่จำเป็นต้องไหลไปตามเส้นทางเดียวกันและดังนั้นอัลกอริทึมจึงไม่สอดคล้องกับ 802.3ad อย่างเคร่งครัด

น่าประหลาดใจมากเมื่อไม่กี่วันที่ผ่านมาการทดสอบของเราแสดงให้เห็นว่า xmit_hash_policy = layer3 + 4 จะไม่มีผลกระทบใด ๆ ระหว่างเซิร์ฟเวอร์ linux ที่เชื่อมต่อโดยตรงสองเครื่องการรับส่งข้อมูลทั้งหมดจะใช้พอร์ตเดียว ทั้งคู่เรียกใช้ xen พร้อม 1 บริดจ์ที่มีอุปกรณ์เชื่อมในฐานะสมาชิก ส่วนใหญ่เห็นได้ชัดว่าสะพานอาจทำให้เกิดปัญหาเพียงว่ามันไม่สมเหตุสมผลเลยเนื่องจากการใช้การแฮชที่ใช้พอร์ต IP +

ฉันรู้ว่าบางคนจัดการเพื่อผลักดัน 180MB + ผ่านลิงค์ที่ถูกผูกมัด (เช่นผู้ใช้ ceph) ดังนั้นจึงใช้งานได้ทั่วไป สิ่งที่เป็นไปได้ในการดู: - เราใช้ CentOS 5.4 แบบเก่า - ตัวอย่าง OPs หมายถึง LACP ตัวที่สอง "ปลด" การเชื่อมต่อ - นั่นทำให้รู้สึกใช่ไหม?

กระทู้นี้และเอกสารที่อ่าน ฯลฯ ฯลฯ ได้แสดงให้ฉันเห็นอะไรบ้าง:

• โดยทั่วไปทุกคนรู้มากเกี่ยวกับเรื่องนี้เป็นสิ่งที่ดีในการท่องทฤษฎีจากการเชื่อมอย่างไรหรือแม้กระทั่งมาตรฐาน IEEE ในขณะที่ประสบการณ์การปฏิบัติอยู่ใกล้กับใคร
• เอกสาร RHEL ไม่สมบูรณ์แบบที่สุด
• เอกสารประกอบการเชื่อมโยงมาจากปี 2544 และปัจจุบันยังไม่เพียงพอ
• เห็นได้ชัดว่าโหมดเลเยอร์ 2 + 3 นั้นไม่ได้อยู่ใน CentOS (มันไม่แสดงใน modinfo และในการทดสอบของเรามันลดทราฟฟิกทั้งหมดเมื่อเปิดใช้งาน)
• มันไม่ได้ช่วยให้ SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) และ RedHat (BONDING_OPTS) ทุกคนมีวิธีที่แตกต่างกันในการระบุการตั้งค่าต่อโหมดบอนด์
• โมดูลเคอร์เนล CentOS / RHEL5 คือ "ปลอดภัยของ SMP" แต่ไม่ใช่ "สามารถใช้ SMP ได้" (ดูการพูดคุยที่มีประสิทธิภาพสูงของ Facebook) - มันไม่ได้ปรับขนาดเหนือ CPU หนึ่งตัวดังนั้นด้วยการเชื่อมต่อนาฬิกา cpu ที่สูงขึ้น> หลายแกน

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

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

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

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

คุณอาจต้องการขยายขอบเขตผู้ขายสักเล็กน้อย ผู้ขายรายอื่นเช่นเครือข่ายสุดขีดสามารถแฮชกับสิ่งต่างๆเช่น:

อัลกอริธึม L3_L4— เลเยอร์ 3 และเลเยอร์ 4, ที่อยู่ IP ต้นทางและปลายทางรวมกันและหมายเลขพอร์ต TCP และ UDP ปลายทาง มีให้ในสวิตช์รุ่น SummitStack และ Summit X250e, X450a, X450e และ X650

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

แม้แต่การแปลงค่า IP ต้นทางและปลายทางก็เพียงพอที่จะหลีกเลี่ยงฮอตสปอตได้ตราบใดที่คุณไม่มีโหลดบาลานซ์ในการผสม

ฉันจะเดาว่ามันปิด IP ของลูกค้าไม่ใช่เราเตอร์ IP ต้นทางและปลายทางที่แท้จริงจะอยู่ที่ออฟเซ็ตคงที่ในแพ็คเก็ตและนั่นจะรวดเร็วกว่าที่จะทำการแฮช การเพิ่ม IP ของเราเตอร์จะต้องค้นหาจาก MAC ใช่มั้ย

เนื่องจากฉันเพิ่งกลับมาที่นี่มีบางสิ่งที่ฉันได้เรียนรู้ในตอนนี้: เพื่อหลีกเลี่ยงปัญหาผมหงอกคุณต้องมีสวิตช์ที่เหมาะสมซึ่งรองรับนโยบาย layer3 + 4 และเหมือนกันใน Linux

ในบางกรณีเครื่องพ่นเป่าลมมาตรฐานที่เรียกว่า ALB / SLB (โหมด 6) อาจทำงานได้ดีขึ้น มันใช้งานได้จริง

ตัวเองฉันพยายามใช้ 3 + 4 ถ้าเป็นไปได้เพราะฉันมักจะต้องการแบนด์วิดท์ระหว่างสองระบบที่อยู่ติดกัน

ฉันได้ลองกับ OpenVSwitch และเคยมีอินสแตนซ์ที่ทำให้การรับส่งข้อมูลหยุดชะงัก (ทุก ๆ แพ็กเก็ตแรกหายไป ... ฉันไม่รู้เลย)