ฉันจะปรับใช้คลัสเตอร์ haproxy ที่ปรับขนาดได้และเชื่อถือได้บน Amazon EC2 ได้อย่างไร

เราต้องการฟังก์ชั่นขั้นสูงมากกว่าที่ ELB ให้ (ส่วนใหญ่เป็นการตรวจ L7) แต่ก็ไม่ชัดเจนว่าจะจัดการกับสิ่งต่าง ๆ เช่นการเต้นของหัวใจและความพร้อมใช้งานสูงด้วย haproxy โดยใช้ EC2 มีความเป็นไปได้สูงที่เราต้องการโหนด Haproxy 3 โหนดขึ้นไปในคลัสเตอร์ดังนั้นการเต้นของหัวใจที่ง่ายระหว่างสองโหนดจะไม่ทำงาน

ดูเหมือนว่าจะมีเลเยอร์ heartbeat อยู่ข้างหน้าโหนด haproxy อาจเป็นไปได้ใช้ IPVS ได้ แต่จัดการกับการเปลี่ยนแปลงการกำหนดค่าเมื่อมีการเปลี่ยนแปลงคลัสเตอร์ EC2 (ไม่ว่าจะเป็นการเปลี่ยนแปลงโดยเจตนาเช่นการขยายหรือโดยไม่ตั้งใจ) โหนด EC2) ดูเหมือนไม่น่ารำคาญ

โซลูชันจะครอบคลุมโซนความพร้อมใช้งานอย่างน้อยสองโซน

ในการตอบคำถาม Qs: ไม่เซสชันไม่เหนียวเหนอะ และใช่เราต้องการ SSL แต่ในทางทฤษฎีสามารถจัดการได้โดยการตั้งค่าอื่นทั้งหมด - เราสามารถกำหนดปริมาณการใช้งาน SSL ไปยังตำแหน่งอื่นนอกเหนือจากปริมาณข้อมูลที่ไม่ใช่ SSL

ตกลงฉันไม่เคยสร้างโซลูชันการปรับสมดุลโหลด AWS ด้วยการรับส่งข้อมูลในระดับของ SmugMug ด้วยตนเอง แต่เพียงแค่คิดถึงทฤษฎีและบริการของ AWS แนวคิดสองสามข้อที่อยู่ในใจ

คำถามต้นฉบับหายไปบางสิ่งที่มีแนวโน้มที่จะส่งผลกระทบต่อการออกแบบสมดุลภาระ:

1. ช่วงเหนียวหรือไม่? เป็นที่นิยมมากกว่าที่จะไม่ใช้เซสชันที่ติดหนึบและปล่อยให้ตัวโหลดบาลานเซอร์ (LB's) ทั้งหมดใช้ round robin (RR) หรือเลือกแบ็กเอนด์แบบสุ่ม RR หรือการเลือกแบ็กเอนด์แบบสุ่มนั้นง่ายปรับขนาดได้และให้การกระจายโหลดที่สม่ำเสมอในทุกสถานการณ์
2. SSL หรือไม่? ไม่ว่า SSL จะถูกใช้งานหรือไม่และโดยทั่วไปแล้วเปอร์เซ็นต์ของคำขอจะมีผลต่อการออกแบบการปรับสมดุลโหลด มักจะดีกว่าที่จะยกเลิก SSL ให้เร็วที่สุดเพื่อลดความยุ่งยากในการจัดการใบรับรองและป้องกันไม่ให้ SSL CPU โหลดจากเว็บแอปพลิเคชันเซิร์ฟเวอร์

ฉันตอบจากมุมมองของวิธีการทำให้ชั้นสมดุลภาระตัวเองพร้อมใช้งานสูง การทำให้แอ็พพลิเคชันเซิร์ฟเวอร์ HA นั้นดำเนินการเสร็จสิ้นด้วยการตรวจสอบสถานะที่มีอยู่ในโหลดบาลานซ์ L7 ของคุณ

ตกลงแนวคิดสองข้อที่ควรใช้:

1) "วิธี AWS":

• ชั้นแรกที่ด้านหน้าใช้ ELB ในโหมด L4 (TCP / IP)
• ชั้นที่สองใช้อินสแตนซ์ EC2 กับตัวโหลดบาลานซ์ L7 ที่คุณเลือก (nginx, HAProxy, Apache และอื่น ๆ )

ข้อดี / ความคิด:ตัวโหลดบาลานซ์ L7 สามารถเป็น EC2 AMI ที่ค่อนข้างง่ายซึ่งถูกโคลนทั้งหมดจาก AMI เดียวกันและใช้การกำหนดค่าเดียวกัน ดังนั้นเครื่องมือของ Amazon สามารถรองรับความต้องการ HA ทั้งหมด: ELB ตรวจสอบโหลดบาลานซ์ L7 หาก L7 LB เสียชีวิตหรือไม่ตอบสนอง ELB & Cloudwatch จะวางไข่อินสแตนซ์ใหม่โดยอัตโนมัติและนำไปไว้ในกลุ่ม ELB

2) "DNS round robin ด้วยวิธีการตรวจสอบ:"

• ใช้ DNS round robin แบบพื้นฐานเพื่อรับการแจกจ่ายโหลดแบบหยาบผ่านที่อยู่ IP สองแห่ง สมมติว่าคุณเผยแพร่ 3 ที่อยู่ IP สำหรับเว็บไซต์ของคุณ
• IP ทั้ง 3 ข้อนี้เป็นที่อยู่ IP ของ AWS Elastic (EIA) ซึ่งเชื่อมโยงกับอินสแตนซ์ EC2 พร้อมตัวโหลดบาลานซ์ L7 ที่คุณเลือก
• หาก EC2 L7 LB ตายตัวแทนผู้ใช้ (เบราว์เซอร์) ที่เข้ากันได้ควรใช้ IP อื่นอย่างใดอย่างหนึ่งแทน
• ตั้งค่าเซิร์ฟเวอร์การมอนิเตอร์ภายนอก ตรวจสอบ 3 EIPs แต่ละรายการ หากไม่ตอบสนองให้ใช้เครื่องมือบรรทัดคำสั่งของ AWS และสคริปต์บางอย่างเพื่อย้าย EIP ไปยังอินสแตนซ์ EC2 อื่น

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

3) DNS RR ไปยังเซิร์ฟเวอร์ HA คู่หนึ่ง:

โดยทั่วไปนี่คือข้อเสนอแนะของ Don เกี่ยวกับการเต้นของหัวใจอย่างง่ายระหว่างเซิร์ฟเวอร์หนึ่งคู่ แต่จะทำให้ง่ายขึ้นสำหรับที่อยู่ IP หลายแห่ง

• ใช้ DNS RR เผยแพร่ที่อยู่ IP จำนวนหนึ่งสำหรับบริการ ตามตัวอย่างข้างต้นสมมติว่าคุณเผยแพร่ 3 IP
• IP แต่ละตัวเหล่านี้ไปที่เซิร์ฟเวอร์ EC2 หนึ่งคู่ดังนั้นรวม 6 อินสแตนซ์ EC2
• แต่ละคู่เหล่านี้ใช้ Heartbeat หรือโซลูชัน HA อื่นร่วมกับเครื่องมือ AWS เพื่อให้ 1 ที่อยู่ IP อยู่ในการกำหนดค่าที่ใช้งาน / passive
• แต่ละอินสแตนซ์ EC2 มีตัวโหลดบาลานซ์ L7 ที่คุณเลือกติดตั้ง

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

สรุป:อีกครั้งฉันไม่ได้ลองสิ่งนี้ในการผลิต ตัวเลือกเดียวกับ ELB ในโหมด L4 และอินสแตนซ์ EC2 ที่จัดการด้วยตนเองเนื่องจาก L7 LBs ดูเหมือนจะสอดคล้องกับจิตวิญญาณของแพลตฟอร์ม AWS มากที่สุดและที่ Amazon มีแนวโน้มที่จะลงทุนและขยายในภายหลัง นี่อาจเป็นตัวเลือกแรกของฉัน

หากคุณไม่ได้ทำเซสชันที่เหนียวเหนอะหรือถ้าคุณกำลังใช้สไตล์ Tomcat / apache (ผนวก ID ของโหนดไปที่ sessionid ซึ่งต่างจากการจัดเก็บสถานะใน LB) ดังนั้นฉันจะใช้ ELB ต่อหน้ากลุ่มของ haproxies ELB มีระบบตรวจสุขภาพในตัวดังนั้นคุณสามารถให้มันตรวจสอบ haproxies และถอดมันออกจากสระได้ มีจำนวนน้อยกว่าในการตั้งค่ามากกว่าความล้มเหลวของสัญญาณ

เท่าที่มีการเปลี่ยนแปลงการเผยแพร่ฉันไม่มีคำตอบที่ดี Puppet นั้นยอดเยี่ยมสำหรับการกำหนดค่าเริ่มต้นและการนำการเปลี่ยนแปลงมาใช้ แต่สำหรับการเพิ่ม / ลบโหนด

ฉันไม่ได้ใช้ด้วยตัวเอง แต่ฉันเห็นผู้คนมากมายพูดถึงการใช้หุ่นเชิดเพื่อจัดการปัญหาเหล่านี้ใน EC2