เพิ่งดูเป็น Elastic Load Balancers ในขณะที่ฉันเข้าใจว่าพวกเขาทำเพียงรอบโรบินกระจายการเชื่อมต่อไปยังเซิร์ฟเวอร์ที่อยู่เบื้องหลังพวกเขาอย่างสม่ำเสมอ แล้วจะเกิดอะไรขึ้นถ้าคุณมีอินสแตนซ์ขนาดต่างกันหลัง ELB มันส่งการเชื่อมต่อไปยังอินสแตนซ์ที่มีขนาดใหญ่ขึ้นหรือส่งต่อการเชื่อมต่ออย่างสม่ำเสมอซึ่งหมายความว่าคุณไม่ควรใช้อินสแตนซ์ที่มีขนาดต่างกัน
คำตอบ:
ในขณะที่ฉันเข้าใจว่าพวกเขาทำเพียงรอบโรบินกระจายการเชื่อมต่อไปยังเซิร์ฟเวอร์ที่อยู่เบื้องหลังพวกเขาอย่างสม่ำเสมอ
ฉันคิดว่า - แต่ก็ค่อนข้างไม่ดี - โชคไม่ดีที่เอกสารการกำหนดเส้นทางของAmazon ELBนั้นขาดความเป็นจริงดังนั้นเราจึงต้องรวบรวมบางชิ้นเพื่อสรุป นี่เป็นเพียงส่วนเดียวจากคู่มือนักพัฒนา Load Balancing ที่ฉันรู้จักดูหัวข้อSticky Sessionsในภาพรวมของ Elastic Load Balancing :
โดยค่าเริ่มต้น balancer โหลดเส้นทางแต่ละคำขออิสระเช่นแอพลิเคชันที่มีภาระน้อยที่สุด อย่างไรก็ตามคุณสามารถใช้คุณสมบัติเซสชันเหนียว (หรือเรียกอีกอย่างว่าเซสชันสัมพันธ์) ซึ่งช่วยให้โหลดบาลานเซอร์ผูกเซสชันของผู้ใช้กับอินสแตนซ์ของแอปพลิเคชันเฉพาะ สิ่งนี้ทำให้มั่นใจได้ว่าคำขอทั้งหมดที่มาจากผู้ใช้ในระหว่างเซสชันจะถูกส่งไปยังอินสแตนซ์ของแอปพลิเคชันเดียวกัน [เน้นเหมือง]
ตอนนี้โหลดที่เล็กที่สุดหมายความว่าอะไรกันแน่? อีกครั้งคำอธิบายเดียวที่ฉันรู้คือการตอบสนองของทีม AWS ที่คลุมเครือตั้งแต่ปี 2009 ถึงกลยุทธ์ของ ELB :
ELB ติดตามการร้องขอ (หรือการเชื่อมต่อในกรณีของ TCP) อย่างโดดเด่นในแต่ละอินสแตนซ์ จะไม่ตรวจสอบการใช้ทรัพยากร (เช่น CPU หรือหน่วยความจำ) ในแต่ละอินสแตนซ์ ขณะนี้ ELB จะปัดเศษเข้าไปในกลุ่มที่เชื่อว่ามีคำขอที่ค้างน้อยที่สุด [เน้นเหมือง]
สิ่งนี้มีเหตุผลมากมายเกี่ยวกับสถาปัตยกรรมระบบและกรณีการใช้งานที่ได้รับการแก้ไข แต่เห็นได้ชัดว่าไม่ได้ให้ความโปร่งใสและ / หรือการควบคุมการกำหนดเส้นทางที่คุณอาจต้องการหรือจำเป็นสำหรับสถานการณ์ HA ขั้นสูง
โปรดทราบว่าขึ้นอยู่กับการตีความสิ่งนี้อาจจะใช่หรือไม่ใช่ขัดแย้งกับการตอบสนองของทีม AWS เมื่อเร็ว ๆ นี้เกี่ยวกับการทำBalanced Elastic Balancing - นโยบายการกระจายโหลด :
Round-robin เข้ามาเล่น แต่เซสชันไคลเอนต์มักไม่ให้เกียรติกับแคชของ TTL หรือ DNS เพื่อให้คุณได้ผลลัพธ์ที่เบ้และการแจกแจงที่ไม่สม่ำเสมอ ELB จะไม่มีผลต่ออินสแตนซ์ของการรับส่งข้อมูล / การร้องขอที่ได้รับในการตัดสินใจกำหนดเส้นทางการจราจร [เน้นเหมือง]
ของหลักสูตรดังกล่าวข้างต้นแก้ไขเพิ่มเติมกับเอกสารอย่างถูกต้องโปร่งใสและสามารถควบคุมการตรวจสุขภาพซึ่งจะช่วยให้คุณใช้ประโยชน์บางอย่างที่จะ (อาจชั่วคราว) กรณีลบจากการถูกรวมอยู่ในสายงานการผลิตในสถานที่แรกเช่นสรุปในการตอบสนอง AWS ดังกล่าวทีมELB กลยุทธ์เช่นกัน:
ตัวโหลดบาลานซ์ตรวจสอบสถานะของอินสแตนซ์ของคุณที่ลงทะเบียนกับโหลดบาลานซ์ของคุณ เมื่อตัวโหลดบาลานซ์ตรวจพบปัญหากับอินสแตนซ์มันจะหยุดกระจายทราฟฟิกไปยังมัน เมื่ออินสแตนซ์นั้นแข็งแรงอีกครั้งตัวโหลดบาลานซ์จะเริ่มการกระจายทราฟฟิกใหม่ กระบวนการนี้อนุญาตให้แอปพลิเคชันของคุณตอบกลับโดยอัตโนมัติต่ออินสแตนซ์ที่ล้มเหลวโดยที่คุณไม่ต้องเกี่ยวข้องกับการกำหนดค่าเฮลช์เช็ค
ในขณะที่ผิดปกติอย่างแน่นอนผมไม่เห็นว่าทำไม ELB ไม่ควรทำงานร่วมกับสระว่ายน้ำที่แตกต่างกันของAmazon EC2 ประเภทเช่นเป็นอย่างดี - ฉันไม่ได้พยายามนี้เองและแม้ว่าจะแนะนำทั้งการตรวจสอบ Balancer การโหลดของคุณโดยใช้ CloudWatchเช่นเดียวกับการตรวจสอบ อินสแตนซ์ EC2 ส่วนบุคคลของคุณและเชื่อมโยงผลลัพธ์เพื่อรับข้อมูลเชิงลึกและความเชื่อมั่นที่เกี่ยวข้องในการตั้งค่าดังกล่าวในที่สุด
ขึ้นอยู่กับคำสั่งที่ทำขึ้นจนถึงปัจจุบันอัลกอริทึมการกระจายง่ายมาก
ส่วนหน้าของ ELB นั้นมักจะเป็นอินสแตนซ์ของ ELB มากกว่าหนึ่งตัวและการกระจายนั้นเป็นแบบปัดเศษ
ส่วนท้าย (อินสแตนซ์ของคุณ) อ้างว่าเป็น:
ELB ติดตามการร้องขอ (หรือการเชื่อมต่อในกรณีของ TCP) อย่างโดดเด่นในแต่ละอินสแตนซ์ จะไม่ตรวจสอบการใช้ทรัพยากร (เช่น CPU หรือหน่วยความจำ) ในแต่ละอินสแตนซ์ ขณะนี้ ELB จะปัดเศษเข้าไปในกลุ่มที่เชื่อว่ามีคำขอที่ค้างน้อยที่สุด
สิ่งนี้จะอนุมานได้ว่าหากอินสแตนซ์ที่ใหญ่กว่ามีคำขอที่ค้างน้อยกว่าปริมาณการใช้งานเพิ่มเติมจะถูกกำหนดเส้นทาง ไม่มีวิธีรับประกันสิ่งนี้