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

ฉันใหม่สำหรับการทำ load balance และฉันสงสัยว่าเป็นไปได้หรือไม่ที่จะใช้ load balancer หลาย ๆ ตัวเพื่อเปลี่ยนทราฟฟิกไปยังเซิร์ฟเวอร์แอปพลิเคชันของฉัน ฉันไม่เข้าใจจริงๆว่าสามารถทำสิ่งนี้ได้อย่างไร ชื่อโดเมนไม่ควรตรงกันแบบหนึ่งต่อหนึ่งกับที่อยู่ IP ของเซิร์ฟเวอร์ (ในกรณีนี้คือ IP ของ load balancer หนึ่งตัว) หากเซิร์ฟเวอร์ load balancing แต่ละเครื่องมี IP ที่แตกต่างกันจะสามารถรับคำขอได้จากทั้ง load balancer (หรือ 10 load balancer หรือ 50 หรือ 100)

การใช้ round robin DNS นั้นไม่ค่อยดีสำหรับความพร้อมใช้งานสูง - หากเซิร์ฟเวอร์หนึ่งออฟไลน์ลูกค้าจะยังคงพยายามเชื่อมต่อกับมันและรอการหมดเวลา

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

2) ตัวโหลดบาลานซ์แบบแอคทีฟ / แอคทีฟ
IP ปริมาณการใช้งานเดียวกันถูกกำหนดค่าไว้บนตัวโหลดบาลานซ์ทั้งสองตัว (หรือมากกว่า)
ทราฟฟิกที่เข้ามาจะถูกส่งไปยังตัวโหลดบาลานซ์ทั้งหมด แต่อัลกอริทึมเลือกว่าตัวสร้างสมดุลใดที่ควรตอบสนอง
วิธีคิดง่ายๆคือคุณมี load balancer สองตัว:
เมื่อ IP ที่ร้องขอสิ้นสุดด้วยเลขคู่แล้ว load balancer A คำตอบมิฉะนั้น load balancer A จะตอบ

แน่นอนว่าโครงสร้างพื้นฐานของคุณต้องรองรับสิ่งนี้และมีค่าใช้จ่ายสูงเนื่องจากการรับส่งข้อมูล แต่ถูกยกเลิก
ข้อมูลเพิ่มเติมเช่นที่นี่: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

ความพร้อมใช้งานสูงกับ load balancer มักใช้งานโดยใช้ที่อยู่ IP เสมือนจริง (VIP) ซึ่งอนุญาตให้โฮสต์หลาย ๆ ตัว (เช่น load balancer) ตอบกลับไปยังที่อยู่ IP ทั่วไปหนึ่งในวิธีที่เป็นไปได้หลายวิธี .

มีโปรโตคอลเหล่านี้จำนวนมากซึ่งเป็นสิ่งที่ฉันเห็นมากที่สุดกับ load balancer ปกติคือVRRPและNLB (รวมถึงโปรโตคอล blackboxed แบบอึมครึมจำนวนมากในอุปกรณ์) การขยายไปยังเราเตอร์และไฟร์วอลล์หนึ่งอาจพบกับCARP , HRSP , GLSPเช่นกัน

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

การปรับสมดุลการโหลด DNS นั้นมีภาระเช่น:

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

การใช้โปรโตคอล ip เสมือนสำหรับ HA หนึ่งอาจมีทางเลือกให้ทำเช่น:

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

มีเพียงคุณเท่านั้นที่รู้ว่ากลยุทธ์และโปรโตคอลใดเหมาะสมกับสถานการณ์ของคุณที่สุด

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

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

ลองหาแอปพลิเคชั่นที่มีลักษณะการโหลดคล้ายกันเช่นที่เก็บบันทึกและแอปค้นหา ผมพบว่าหนึ่ง

พวกเขาต้องการอะไร:

1. สมดุลภาระให้กับนักสะสม
2. ให้การยอมรับข้อผิดพลาดทำให้เราสามารถนำเข้าข้อมูลต่อไปได้หากหนึ่งในนักสะสมเสียชีวิตหรือประสบปัญหา
3. ปรับขนาดตามแนวนอนพร้อมกับการเติบโตของปริมาณบันทึก

พวกเขาลองทำอะไรและเรียนรู้เกี่ยวกับ ELB:

1. ใช้งานไม่ได้ตามที่คาดไว้
2. ปัญหาความล่าช้าเนื่องจากโหลดเพิ่มขึ้น
3. สิ่งอำนวยความสะดวกการตรวจสอบไม่เพียงพอ
4. มีข้อ จำกัด มากเกินไป (เปิดพอร์ตและหมายเลขโปรโตคอล)

ทำไมพวกเขาถึงเลือกใช้ Route53:

1. "Round robin เป็นการปรับสมดุลภาระขั้นพื้นฐาน แต่มันทำงานได้ดีสำหรับเราจากจุดยืนด้านประสิทธิภาพ"
2. "เราใช้ประโยชน์จากการตรวจสุขภาพที่ล้มเหลวของเส้นทาง 53"
3. "หากมีปัญหาเกี่ยวกับตัวสะสมเส้นทาง 53 จะนำออกจากบริการโดยอัตโนมัติลูกค้าของเราจะไม่เห็นผลกระทบใด ๆ "
4. ไม่ต้องอุ่นเครื่องล่วงหน้ากับถนนหมายเลข 53

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

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

มาดูกันว่า AWS พูดว่า DNS ขัดข้องอะไร

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

เทคนิคดังกล่าวยังทำให้ ELB (ไม่จำเป็นสำหรับการบันทึก) ที่แข็งแกร่งยิ่งขึ้นอีกครั้งซึ่งเป็นไปตามการตรวจสุขภาพ RR +:

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

เรามาดูกันว่ามันทำงานอย่างไรเบื้องหลัง คำถามที่ชัดเจนคือวิธีจัดการกับการแคช DNS:

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

("http://<unique-id>.<your-domain>") 

และกำหนดทรัพยากรไวด์การ์ด

Record "*.<your-domain>" to match it.

Algolia แนะนำ "กลยุทธ์การลองส่งไคลเอ็นต์" ซึ่งใช้งานได้ดีหากลูกค้าของคุณ (JS ในกรณีของคุณ) สามารถจัดการสิ่งต่อไปนี้:

เราลงเอยด้วยการใช้กลยุทธ์การลองใหม่พื้นฐานในลูกค้า API ของเรา แต่ละไคลเอนต์ API ได้รับการพัฒนาเพื่อให้สามารถเข้าถึงเครื่องที่แตกต่างกันสามเครื่อง ระเบียน DNS ที่แตกต่างกันสามรายการแสดงถึงผู้ใช้แต่ละราย: USERIDID-1.algolia.io, USERID-2.algolia.io และ USERID-3.algolia.io การใช้งานครั้งแรกของเราคือการสุ่มเลือกหนึ่งในเรกคอร์ดแล้วลองอีกครั้งในกรณีที่ล้มเหลว