ตัวปรับสมดุลโหลดจะพอดีกับศูนย์ข้อมูลที่มีปริมาณงานสูงกว่าที่พวกเขาสามารถจัดการได้อย่างไร

10

คุณมีศูนย์ข้อมูลที่ได้มาตรฐานในการเชื่อมต่อ 10GE ด้วยการพูดถึง Nexus 7000 ในแกน, Nexus 5000 ที่การรวมตัวและตัวขยายแฟบริคบางส่วนสำหรับขอบไปยังเซิร์ฟเวอร์ (ฉันใช้เกียร์ Cisco เป็นตัวอย่างเพราะนี่คือสิ่งที่อยู่ในห้องปฏิบัติการเฉพาะของฉัน) มีตัวโหลดบาลานซ์ ACE 4710 บางตัวห้อยอยู่ที่ Nexus 5000 ของคุณ แต่สิ่งเหล่านี้มีเพียงอินเตอร์เฟส 1GE การเชื่อมต่อสวิตช์ทั้งหมดของคุณคือ 10GE ซึ่งจำเป็นสำหรับการรับส่งข้อมูลขนาดใหญ่ทางตะวันออก - ตะวันตก (VM-to-VM) ในศูนย์ข้อมูลเสมือนจริงที่ทันสมัย

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

โดยพื้นฐานแล้วฉันรู้ว่าโหลดบาลานเซอร์จะถูกใช้ในไคลเอนต์ - เซิร์ฟเวอร์ (ทิศเหนือ - ใต้) และสิ่งต่าง ๆ เช่น HTTP GET ไม่จำเป็นต้องมี 10GE แต่มีสถานการณ์ที่โหลดบาลานเซอร์ 1GE ของคุณสามารถรับได้อย่างอื่น - เส้นทางการจราจร 10GE และทำให้เกิดปัญหากับสิ่งต่าง ๆ เช่น vMotion (เช่น)?

load-balancer

— แมวมอง
แหล่งที่มา

1

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

— Brett Lykins

นี่ไม่ใช่สภาพแวดล้อมการผลิตจริง แต่เป็นสถานการณ์ "แล็บ" จริงที่มีอุปกรณ์เหล่านี้โดยเฉพาะ โดยทั่วไปแล้วคำถามของฉันคือเนื่องจากปริมาณการรับส่งข้อมูลของศูนย์ข้อมูลทั่วไปคุณจะมั่นใจได้อย่างไรว่า load balancer ไม่กลายเป็นปัญหาคอขวดในการออกแบบของคุณ สิ่งนี้เล่นกับการออกแบบของคุณเช่นถ้าศูนย์ข้อมูลของคุณเป็นแบบหลายเทียร์ในระดับใดที่คุณทำโหลดบาลานซ์ ฯลฯ ในตัวอย่างเฉพาะของฉันซึ่งฉันไม่สามารถเปลี่ยนแปลงได้เนื่องจากไม่ใช่การออกแบบของฉัน อุปกรณ์ ACE ติดอาวุธ Nexus 5000 ที่มีประสิทธิภาพมากกว่า

— ยาม

6

เครื่องถ่วงโหลดไม่ได้กลายเป็นคอขวดในสภาพการจราจรบางอย่างหรือไม่?

แน่นอน แต่นี่ไม่ใช่กรณีในเครือข่ายที่ได้รับการออกแบบมาอย่างดี

คุณควรจะสามารถออกแบบเครือข่ายของคุณในแบบที่จะช่วยให้การรับส่งข้อมูลภายในเซิร์ฟเวอร์ของคุณไปยังเซิร์ฟเวอร์ส่วนใหญ่ ("ตะวันออก - ตะวันตก" ตามที่คุณวางไว้) แม้ว่ามันจะต้องข้ามแกนกลางหรือระหว่างศูนย์ข้อมูล

ในขณะที่บ่อยครั้งที่ load balancer เป็นเกตเวย์เริ่มต้นสำหรับเซิร์ฟเวอร์ที่อยู่ด้านหลังฉันได้เห็นการติดตั้งที่ routing protocol (เช่น OSPF หรือ RIP) ถูกเรียกใช้เพื่อให้ทราฟฟิก "East-west" หลีกเลี่ยง load balancer หรือในการปรับใช้ขนาดเล็ก ที่ใช้เส้นทางคงที่

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

— YLearn
แหล่งที่มา

4

จริง หากมี LB ในเส้นทาง vMotion ของคุณแสดงว่าคุณล้มเหลวในฐานะวิศวกร

— Ricky Beam

"... มีวิธีการโหลดบาลานซ์ในโหลดบาลานเซอร์หลายตัวด้วยเช่นกัน" - เช่นการเลือกโหลดบาลานเซอร์เครือข่ายจาก DNS หรือไม่

— Andrei Rînea

2

นี่เป็นคอขวดและจะ จำกัด ปริมาณงานของคุณไว้ที่ "จุดอ่อนในการเชื่อมโยง" ซึ่งเป็น LBs ของคุณ อย่างไรก็ตามคุณสามารถหลีกเลี่ยงได้ หากคุณใช้สิ่งที่เรียกว่า "switchback" หรือ "direct server return" คุณสามารถทำ async traffic flow วิธีการทำงานคือ:

a) ไคลเอนต์ทำการร้องขอ http ถึง 2.2.2.2

b) LB ตอบคำถามใน 2.2.2.2 และส่งคำร้องขอขาเข้าไปยังเซิร์ฟเวอร์ - เนื่องจาก LB และเซิร์ฟเวอร์อยู่ใน LAN เดียวกันจึงทำที่ชั้น 2

c) เซิร์ฟเวอร์ยอมรับการเชื่อมต่อที่เข้ามานี้เนื่องจาก IP 2.2.2.2 อยู่ในอินเตอร์เฟสลูปแบ็กที่ใช้นามแฝง (ไม่เช่นนั้นจะวางแพ็กเก็ตที่ไม่ตรงกับอินเตอร์เฟส)

d) เซิร์ฟเวอร์ตอบสนองโดยตรงกับลูกค้า

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

ไชโย

--tc

— โทมัสแคนนอน
แหล่งที่มา

1

โปรดทราบว่าการทำเช่นนี้เหมาะสำหรับกลุ่ม L4 เท่านั้น สำหรับกลุ่ม L7 สิ่งนี้จะทำลายการเขียนส่วนหัวการแทรกคุกกี้ (การคงอยู่) การเลิกใช้ SSL การจับคู่ URL ใด ๆ และคุณลักษณะขั้นสูงอื่น ๆ เพิ่มเติมของโหลดบาลานซ์จำนวนมาก

— YLearn