โหลดสมดุล Apache ในงบประมาณหรือไม่

ฉันพยายามที่จะเข้าใจแนวคิดของการทำ load balancing เพื่อให้แน่ใจว่ามีความพร้อมใช้งานและความซ้ำซ้อนเพื่อให้ผู้ใช้มีความสุขเมื่อสิ่งต่าง ๆ ผิดพลาดมากกว่าการทำ load balancing เพื่อให้ความเร็วในการ blistering แก่ผู้ใช้หลายล้านคน

เราอยู่ในงบประมาณและพยายามที่จะยึดติดกับสิ่งที่มีความรู้มากมายดังนั้นการใช้งาน Apache บน Ubuntu VPS ดูเหมือนว่าเป็นกลยุทธ์จนกว่าเครื่องมือค้นหาที่มีชื่อเสียงบางรายได้มาให้เรา ( รวมถึงการประชดเสาร์โปรดทราบ )

อย่างน้อยสำหรับฉันมันเป็นป่าที่สมบูรณ์ของโซลูชั่นที่แตกต่างกัน Apaches เอง mod_proxy & HAproxy เป็นสองสิ่งที่เราค้นพบโดยการค้นหา google อย่างรวดเร็ว แต่ไม่มีประสบการณ์ในการทำโหลดบาลานซ์ฉันไม่รู้ว่าอะไรจะเหมาะกับสถานการณ์ของเราหรือสิ่งที่เราจะดูแลในขณะที่เลือกวิธีแก้ปัญหาของเรา กังวลเรื่องความพร้อมใช้งาน

ตัวเลือกที่ดีที่สุดสำหรับเราคืออะไร? เราควรทำอย่างไรเพื่อให้มีความพร้อมในการใช้งานสูงในขณะที่อยู่ในงบประมาณของเรา

โซลูชันที่ฉันใช้และสามารถนำไปใช้กับ VPS ได้อย่างง่ายดายมีดังต่อไปนี้:

• DNS เป็น round-robin'ed (sp?) ถึง 6 ที่อยู่ IP ที่ถูกต้อง
• ฉันมี load balancer 3 ตัวที่มีการกำหนดค่าเหมือนกันและใช้corosync / pacemakerเพื่อแจกจ่ายที่อยู่ ip 6 ที่เท่ากัน (เพื่อให้แต่ละเครื่องได้รับ 2 adresses)
• ตัวโหลดบาลานซ์แต่ละตัวมีการกำหนดค่าnginx + varnish Nginx จัดการกับการรับการเชื่อมต่อและทำการเขียนใหม่และการให้บริการแบบสแตติกและส่งกลับไปยังวานิชที่ทำโหลดบาลานซ์และแคช

ซุ้มประตูนี้มีข้อดีดังต่อไปนี้ตามความเห็นของฉัน:

1. corosync / pacemaker จะกระจายที่อยู่ IP ในกรณีที่ LB ตัวใดตัวหนึ่งล้มเหลว
2. nginx สามารถใช้เพื่อให้บริการ SSL, ไฟล์บางประเภทโดยตรงจากระบบไฟล์หรือ NFS โดยไม่ต้องใช้แคช (วิดีโอขนาดใหญ่, ไฟล์เสียงหรือไฟล์ขนาดใหญ่)
3. วานิชเป็นเครื่องถ่วงน้ำหนักที่ดีมากรองรับน้ำหนักตรวจสุขภาพแบ็กเอนด์และทำงานที่โดดเด่นในฐานะพร็อกซีย้อนกลับ
4. ในกรณีที่จำเป็นต้องใช้ LB มากขึ้นในการจัดการปริมาณการใช้งานเพียงเพิ่มเครื่องจักรเข้ากับคลัสเตอร์และที่อยู่ IP จะถูกปรับสมดุลระหว่างเครื่องทั้งหมด คุณสามารถทำได้โดยอัตโนมัติ (การเพิ่มและลบตัวโหลดบาลานซ์) นั่นเป็นเหตุผลที่ฉันใช้ 6 ips สำหรับเครื่องจักร 3 เครื่องเพื่อให้มีพื้นที่สำหรับการเติบโต

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

ฉันก็รู้ว่าคุณถามถึง apache แต่วันนั้นเรามีเครื่องมือเฉพาะที่เหมาะสมกับงาน (เช่น nginx และ varnish) ปล่อยให้ Apache ใช้งานแอพพลิเคชั่นบนแบ็กเอนด์และให้บริการโดยใช้เครื่องมืออื่น ๆ (ไม่ใช่ว่า apache ไม่สามารถทำโหลดบาลานซ์ที่ดีหรือใช้งานแบบย้อนกลับได้มันเป็นเพียงคำถามของการถ่ายชิ้นส่วนต่างๆ มันแชร์)

HAproxy เป็นทางออกที่ดี การกำหนดค่าค่อนข้างตรงไปตรงมา

คุณจะต้องใช้ VPS อื่นเพื่อนั่งอยู่หน้า VPS อื่นอย่างน้อย 2 ตัว ดังนั้นสำหรับการโหลดบาลานซ์ / ล้มเหลวคุณต้องมีอย่างน้อย 3 VPS

บางสิ่งที่ควรคำนึงถึงก็คือ:

1. การยกเลิก SSL หากคุณใช้ HTTPS: // การเชื่อมต่อนั้นควรยุติที่ load balancer ด้านหลัง load balancer มันควรผ่าน traffic ทั้งหมดผ่านการเชื่อมต่อที่ไม่ได้เข้ารหัส

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

3. ข้อมูลเซสชั่น แต่ละเครื่องในการกำหนดค่าโหลดบาลานเซอร์ของคุณจะต้องสามารถเข้าถึงข้อมูลเซสชันของผู้ใช้เพราะคุณไม่เคยรู้ว่าพวกเขาจะตีเครื่องอะไร

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

ดังนั้นฉันจึงอยู่ในรองเท้าของคุณนั่นเป็นปัญหากับเว็บไซต์ที่ไม่กี่ร้อยต่อวันกับการทำงานจริง มันซับซ้อนอย่างรวดเร็ว หวังว่าจะให้อาหารคุณคิด :)

คะแนนของฉันสำหรับLinux Virtual Serverในฐานะตัวโหลดบาลานซ์ สิ่งนี้ทำให้ผู้กำกับ LVS เป็นจุดเดียวของความล้มเหลวเช่นเดียวกับคอขวด

1. ปัญหาคอขวดของฉันไม่ได้เป็นปัญหา ขั้นตอนการเปลี่ยนเส้นทาง LVS คือเลเยอร์ -3 และถูกที่สุด (คำนวณ) อย่างยิ่ง
2. จุดเดียวของความล้มเหลวควรได้รับการจัดการโดยมีผู้อำนวยการที่สองกับสองควบคุมโดยลินุกซ์ HA

สามารถลดต้นทุนลงได้โดยให้ผู้กำกับคนแรกอยู่ในเครื่องเดียวกับโหนด LVS ตัวแรกและผู้อำนวยการคนที่สองบนเครื่องเดียวกับโหนด LVS ตัวที่สอง โหนดที่สามและโหนดต่อมาคือโหนดบริสุทธิ์โดยไม่มีนัยยะของ LVS หรือ HA

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

แล้วเชนนี้ล่ะ

round robin dns> haproxy บนทั้งสองเครื่อง> nginx เพื่อแยกไฟล์คงที่> apache

อาจใช้ ucarp หรือ heartbeat เพื่อให้แน่ใจว่า haproxy ตอบเสมอ Stunnel จะนั่งอยู่หน้า haproxy ถ้าคุณต้องการ SSL ด้วย

คุณอาจต้องการพิจารณาการใช้ซอฟต์แวร์การจัดกลุ่มที่เหมาะสม RedHat (หรือ CentOS) คลัสเตอร์สวีทหรือของออราเคิลClusterware สิ่งเหล่านี้สามารถใช้เพื่อตั้งค่าคลัสเตอร์ที่แอ็คทีฟและสามารถใช้เพื่อรีสตาร์ทเซอร์วิสและล้มเหลวระหว่างโหนดเมื่อมีปัญหาร้ายแรง นี่คือสิ่งที่คุณกำลังมองหา

โซลูชันคลัสเตอร์ทั้งหมดเหล่านี้รวมอยู่ในสิทธิการใช้งานระบบปฏิบัติการที่เกี่ยวข้องดังนั้นคุณน่าจะประหยัดค่าใช้จ่าย พวกเขาต้องการที่เก็บข้อมูลที่ใช้ร่วมกันบางอย่าง - ทั้ง NFS mount หรือฟิสิคัลดิสก์ที่เข้าถึงได้โดยทั้งสองโหนดด้วยระบบไฟล์แบบคลัสเตอร์ ตัวอย่างของหลังจะดิสก์ SAN ที่มีการเข้าถึงโฮสต์หลายได้รับอนุญาต, รูปแบบด้วยOCFS2หรือสศค ฉันเชื่อว่าคุณสามารถใช้ดิสก์ที่ใช้ร่วมกันของ VMWare ได้

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

โดยทั่วไปคุณจะกำหนดค่าที่อยู่ IP 'ที่ใช้ร่วมกัน' เดียวที่การเข้าชมจะถูกนำไป จากนั้น apache และบริการอื่น ๆ ที่จำเป็นสามารถกำหนดได้เช่นกันและทำงานบนเซิร์ฟเวอร์ที่ใช้งานอยู่เท่านั้น ดิสก์ที่ใช้ร่วมกันจะถูกใช้สำหรับเนื้อหาเว็บทั้งหมดของคุณไฟล์ที่อัปโหลดใด ๆ และไดเรกทอรีการกำหนดค่า apache ของคุณ (ด้วย httpd.conf เป็นต้น)

จากประสบการณ์ของฉันมันใช้งานได้ดีอย่างเหลือเชื่อ

• ไม่จำเป็นต้องใช้ DNS round robin หรือตัวโหลดบาลานซ์แบบจุดเดียวของความล้มเหลวอื่น ๆ ทุกอย่างเข้ากับ IP / FQDN เดียว
• ผู้ใช้อัปโหลดไฟล์ไปยังที่เก็บข้อมูลที่ใช้ร่วมกันและไม่สนใจว่าเครื่องของคุณล้มเหลว
• นักพัฒนาอัปโหลดเนื้อหาไปยัง IP / FQDN เดี่ยวนั้นโดยไม่มีการฝึกอบรมเพิ่มเติมและจะเป็นข้อมูลล่าสุดหากล้มเหลว
• ผู้ดูแลระบบสามารถนำเครื่องออฟไลน์แก้ไข heck ออกจากมันรีบูตเครื่อง ฯลฯ จากนั้นโหนดที่ทำงานอยู่จะล้มเหลว การอัปเกรดจะใช้เวลาหยุดทำงานน้อยที่สุด
• ในตอนนี้โหนดที่ล้าสมัยสามารถถูกเก็บไว้ไม่ได้รับการแก้ไขสักระยะหนึ่งทำให้กระบวนการล้มเหลวกลับเป็นกระบวนการที่ง่ายพอ ๆ กัน (เร็วกว่าสแนปชอตของ VMWare)
• การเปลี่ยนแปลงการกำหนดค่าของ Apache จะถูกแชร์ดังนั้นจึงไม่มีอะไรแปลกเกิดขึ้นในช่วงที่ระบบล้มเหลวเนื่องจากผู้ดูแลระบบลืมที่จะทำการเปลี่ยนแปลงในกล่องออฟไลน์

- คริสโตเฟอร์คาเรล

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

วิธีโหลดบาลานซ์ที่ง่ายที่สุดคือการจัดทำเรกคอร์ด A หลายรายการใน DNS โดยค่าเริ่มต้นที่อยู่ IP จะถูกกำหนดค่าในวิธีการปัดเศษรอบ สิ่งนี้จะส่งผลให้ผู้ใช้มีการกระจายตัวอย่างสม่ำเสมอทั่วทั้งเซิร์ฟเวอร์ สิ่งนี้ทำงานได้ดีสำหรับไซต์ไร้สัญชาติ จำเป็นต้องใช้วิธีการที่ซับซ้อนกว่านี้เล็กน้อยเมื่อคุณมีไซต์ที่เป็นรัฐ

เพื่อจัดการกับข้อกำหนดแบบ stateful คุณสามารถใช้การเปลี่ยนเส้นทาง ให้ที่อยู่สำรองของเว็บเซิร์ฟเวอร์แต่ละรายการเช่น www1, www2, www3 เป็นต้นเปลี่ยนเส้นทางการเชื่อมต่อ www เริ่มต้นไปยังที่อยู่สำรองของโฮสต์ คุณอาจจบลงด้วยปัญหาบุ๊คมาร์คด้วยวิธีนี้ แต่พวกเขาควรจะกระจายไปทั่วเซิร์ฟเวอร์

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

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

ผู้ใช้จะไม่ประสบกับความล่าช้าจนกว่าเบราว์เซอร์จะล้มเหลวไปยังที่อยู่ IP ถัดไป

การใช้บริการแบบ Restful แทนที่จะเป็นการประชุมแบบช่วงเวลาควรทำเรื่องการทำคลัสเตอร์ในส่วนหน้า ปัญหาการทำคลัสเตอร์ในด้านการจัดเก็บจะยังคงใช้

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

ทางออกที่ดีที่สุดจะขึ้นอยู่กับข้อกำหนดที่เกี่ยวข้อง

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

ฉันมักจะใช้เครื่อง OpenBSD เหมือนกันคู่หนึ่ง:

• ใช้ RelayD สำหรับการทำโหลดบาลานซ์ตรวจสอบเว็บเซิร์ฟเวอร์และจัดการเว็บเซิร์ฟเวอร์ที่ล้มเหลว
• ใช้ CARP สำหรับความพร้อมใช้งานสูงของตัวโหลดบาลานซ์เอง

OpenBSD มีน้ำหนักเบามั่นคงและปลอดภัยมาก - เหมาะสำหรับบริการเครือข่าย

• http://www.openbsd.org - เว็บไซต์หลัก
• http://www.openbsd.org/faq/pf/carp.html - เอกสารปลาคาร์พ
• https://calomel.org/relayd.html - ชุดข้อมูล howto ที่ดีใน RelayD

ในการเริ่มต้นฉันแนะนำการตั้งค่า layer3 หลีกเลี่ยงการตั้งค่าไฟร์วอลล์แทรกซ้อน (PF) นี่คือตัวอย่างไฟล์ /etc/relayd.conf ที่แสดงการตั้งค่าตัวโหลดบาลานซ์แบบธรรมดาพร้อมการตรวจสอบเว็บเซิร์ฟเวอร์แบ็กเอนด์:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

คุณได้รับ EC2 กับcloudfoundryหรืออาจจะฝักถั่วยืดหยุ่นหรือเพียงแค่เก่าธรรมดาAWS AutoScalingคิด ฉันใช้มันมาและมันก็ค่อนข้างดีและความยืดหยุ่นสามารถปรับขึ้น / ลงได้โดยไม่ต้องมีมนุษย์เข้ามาแทรกแซง

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

มันอาจเป็นการใช้เวลาของคุณให้ดีขึ้น