กุญแจสำคัญในการปรับขนาดเลเยอร์การโหลด HTTP คือการเพิ่มเลเยอร์อื่นของการโหลดบาลานซ์ระดับต่ำกว่า (IP หรือ TCP) ก่อน เลเยอร์นี้สามารถสร้างได้ทั้งหมดด้วยซอฟต์แวร์โอเพ่นซอร์สแม้ว่าคุณจะได้ผลลัพธ์ที่ดีกว่าถ้าคุณมีเราเตอร์ที่ทันสมัย
การไหล (เซสชัน TCP) ควรถูกแฮชโดยใช้ส่วนหัวเช่น IP ต้นทาง / ปลายทางและพอร์ต TCP เพื่อตัดสินใจว่าส่วนหน้าใดที่พวกเขาจะไป คุณต้องมีกลไกเพื่อให้แน่ใจว่าเมื่อส่วนหน้าตายก็หยุดใช้
มีกลยุทธ์ต่าง ๆ ฉันจะร่างคู่ที่ฉันใช้ในการผลิตบนไซต์ที่ให้บริการผู้ใช้หลายล้านคนเพื่อให้คุณได้รับแนวคิด มันจะยาวเกินไปที่จะอธิบายทุกอย่างในรายละเอียด แต่ฉันหวังว่าคำตอบนี้จะให้ข้อมูล / ตัวชี้เพียงพอในการเริ่มต้น ในการใช้โซลูชันเหล่านี้คุณจะต้องมีคนที่มีความรู้เกี่ยวกับระบบเครือข่ายจริงๆ
สิ่งที่ฉันอธิบายที่นี่เป็นเรื่องยากที่จะนำไปปฏิบัติมากกว่าที่อธิบายไว้ในคำตอบอื่น ๆ แต่นี่คือสิ่งที่ล้ำสมัยหากคุณมีเว็บไซต์ที่มีการดูแลการแสดงสูงที่มีปัญหาเรื่องความยืดหยุ่นและความพร้อมใช้งานมากกว่า 99.9% . หากคุณมีวิศวกรเครือข่ายแล้วก็มีค่าใช้จ่ายน้อยกว่าในการติดตั้งและใช้งาน (ทั้งแบบ capex และ opex) กว่าอุปกรณ์ load balancer และสามารถปรับขนาดได้เกือบจะไม่มีค่าใช้จ่ายเพิ่มเติม (เทียบกับการซื้อแบบใหม่มากยิ่งขึ้น เครื่องใช้ไฟฟ้าราคาแพงเมื่อคุณโตเกินรุ่นปัจจุบันของคุณ)
กลยุทธ์แรก: ด้วยไฟร์วอลล์
สมมุติว่าคุณมีเราเตอร์สองตัวที่เชื่อมต่อ ISP ของคุณ ISP ของคุณมี 2 ลิงก์ (active / passive โดยใช้ VRRP) บนเราเตอร์ของคุณคุณใช้ VRRP และคุณกำหนดเส้นทางการรับส่งข้อมูลไปยังเครือข่ายสาธารณะของคุณไปยังไฟร์วอลล์ ไฟร์วอลล์ ( FW 1และFW 2ด้านล่าง) ยังทำงานอยู่ / ไม่โต้ตอบและจะกรองการรับส่งข้อมูลและส่งแต่ละขั้นตอนไปยังเซิร์ฟเวอร์ส่วนหน้าที่ดีต่อสุขภาพ (โหลดบาลานเซอร์ HTTP ของคุณFE 1และFE 2ด้านล่าง)
+ -------------- + + -------------- +
| ISP เราเตอร์ A | | ISP เราเตอร์ B |
+ -------------- + + -------------- +
| |
== # ====================== # == (เครือข่ายสาธารณะ)
| |
+ --------------- + + --------------- +
| เราเตอร์ของคุณ | เราเตอร์ของคุณ B |
+ --------------- + + --------------- +
| |
== # ===== # ========== # ===== # == (เครือข่ายส่วนตัว RFC 1918)
| | | |
+ ------ + + ------ + + ------ + + ------ +
| FW 1 | | FE 1 | | FE 2 | | FW 2 |
+ ------ + + ------ + + ------ + + ------ +
เป้าหมายคือมีลักษณะดังนี้:
- ISP กำหนดเส้นทางการรับส่งข้อมูลไปยัง IP ของคุณไปยังเราเตอร์ที่ใช้งานอยู่ของคุณ
- เราเตอร์ของคุณกำหนดเส้นทางการรับส่งข้อมูลไปยัง VIP ที่ใช้ที่อยู่RFC 1918 วีไอพีนี้เป็นของไฟร์วอลล์ที่ใช้งานอยู่ซึ่งคล้ายกับ VRRP หากคุณใช้ OpenBSD สำหรับความต้องการไฟร์วอลล์ของคุณคุณสามารถใช้CARPซึ่งเป็นทางเลือกที่ไม่มีสิทธิบัตรสำหรับ VRRP / HSRP
- ไฟร์วอลล์ของคุณใช้ตัวกรอง (เช่น "อนุญาตเพียง 80 / tcp และ 443 / tcp ไปยังที่อยู่ IP นี้โดยเฉพาะ")
- ไฟร์วอลล์ของคุณยังทำหน้าที่เป็นเราเตอร์และส่งต่อแพ็คเก็ตไปยังส่วนหน้าแข็งแรง
- ส่วนหน้าของคุณยุติการเชื่อมต่อ TCP
ตอนนี้ความมหัศจรรย์เกิดขึ้นในขั้นตอนที่ 4 และ 5 ดังนั้นเรามาดูรายละเอียดเพิ่มเติมเกี่ยวกับสิ่งที่พวกเขาทำ
ไฟร์วอลล์ของคุณรู้รายการของส่วนหน้า ( FE 1และFE 2) และจะเลือกหนึ่งในนั้นตามลักษณะเฉพาะของโฟลว์ (เช่นโดยการแปลง IP ต้นทางและพอร์ตในส่วนหัวอื่น ๆ ) แต่มันก็ต้องทำให้แน่ใจว่ามันกำลังส่งต่อทราฟฟิกไปยังส่วนหน้าที่แข็งแรงไม่เช่นนั้นคุณจะเป็นทรัคของ blackhole ถ้าคุณใช้ OpenBSD relaydตัวอย่างเช่นคุณสามารถใช้ อะไรrelaydทำง่าย: มันตรวจสุขภาพของคุณทั้งหมด (เช่นโดยการส่งคำขอ HTTP โพรบให้พวกเขา) และเมื่อใดก็ตามที่ส่วนหน้ามีสุขภาพดีมันจะเพิ่มเข้าไปในตารางที่ไฟร์วอลล์ใช้เพื่อเลือก hop ถัดไปของแพ็กเก็ตของโฟลว์ที่กำหนด . หากส่วนหน้าล้มเหลวในการตรวจสอบสุขภาพก็จะถูกลบออกจากตารางและไม่มีแพ็กเก็ตจะถูกส่งไปอีกต่อไป เมื่อส่งต่อแพ็กเก็ตไปยังส่วนหน้าไฟร์วอลล์ทั้งหมดจะทำการสลับที่อยู่ MAC ปลายทางของแพ็กเก็ตให้เป็นส่วนที่เลือกไว้
ในขั้นตอนที่ 5 แพ็คเก็ตจากผู้ใช้จะได้รับโดย load balancer ของคุณ (ไม่ว่าจะเป็น Varnish, nginx หรืออะไรก็ตาม) ณ จุดนี้แพ็คเก็ตยังคงอยู่ในที่อยู่ IP สาธารณะของคุณดังนั้นคุณต้องนามแฝง VIP ของคุณบนอินเทอร์เฟซวนรอบ สิ่งนี้เรียกว่าDSR (Direct Server Return) เนื่องจากส่วนหน้าของคุณยุติการเชื่อมต่อ TCP และไฟร์วอลล์ในระหว่างนั้นจะเห็นเฉพาะทราฟฟิกทราฟฟิก (เฉพาะแพ็กเก็ตที่เข้ามา) เราเตอร์ของคุณจะกำหนดเส้นทางแพ็กเก็ตขาออกโดยตรงกลับไปที่เราเตอร์ของ ISP นี่เป็นสิ่งที่ดีสำหรับการรับส่งข้อมูล HTTP เนื่องจากคำขอมีขนาดเล็กกว่าการตอบสนอง เพื่อให้ชัดเจน: นี่ไม่ใช่สิ่งเฉพาะของ OpenBSD และใช้กันอย่างแพร่หลายในเว็บไซต์ที่มีการดูแลการแสดงโฆษณาสูง
gotchas:
- ผู้ใช้ปลายทางจะเชื่อมต่อกับเซิร์ฟเวอร์ส่วนหน้าของคุณโดยตรงเนื่องจากคุณใช้ DSR อาจเป็นกรณีนี้อยู่แล้ว แต่ถ้าไม่ใช่คุณจำเป็นต้องตรวจสอบให้แน่ใจว่ามีความปลอดภัยเพียงพอ
- หากคุณใช้ OpenBSD โปรดระวังว่าเคอร์เนลเป็นเธรดเดี่ยวดังนั้นประสิทธิภาพของ CPU หลักเดียวจะ จำกัด ปริมาณงานของไฟร์วอลล์ อาจเป็นปัญหาขึ้นอยู่กับชนิดของ NIC และอัตราแพ็คเก็ตที่คุณเห็น มีวิธีในการแก้ปัญหานี้ (เพิ่มเติมด้านล่างนี้)
กลยุทธ์ที่สอง: ไม่มีไฟร์วอลล์
กลยุทธ์นี้มีประสิทธิภาพมากกว่า แต่ยากกว่าในการติดตั้งเนื่องจากจะขึ้นอยู่กับข้อมูลเฉพาะของเราเตอร์ที่คุณมี แนวคิดก็คือการข้ามไฟร์วอลล์ด้านบนและให้เราเตอร์ทำงานทั้งหมดที่ไฟร์วอลล์ทำอยู่
คุณจะต้องมีเราเตอร์ที่รองรับ ACLs L3 / L4 ต่อพอร์ตBGPและECMPและการกำหนดเส้นทางตามนโยบาย (PBR) มีเพียงเราเตอร์ระดับสูงเท่านั้นที่สนับสนุนคุณสมบัติเหล่านี้และพวกเขามักจะมีค่าธรรมเนียมใบอนุญาตเพิ่มเติมในการใช้ BGP โดยทั่วไปแล้วจะยังคงราคาถูกกว่าตัวโหลดบาลานซ์ของฮาร์ดแวร์และยังปรับขยายได้ง่ายกว่า สิ่งที่ดีเกี่ยวกับเราเตอร์ระดับไฮเอนด์เหล่านี้คือพวกเขามักจะเป็นอัตราสาย (เช่นพวกเขาสามารถเชื่อมโยงได้สูงสุดแม้ในอินเทอร์เฟซ 10GbE เพราะการตัดสินใจทั้งหมดจะทำในฮาร์ดแวร์โดย ASIC)
ในพอร์ตที่คุณมี ISP ของคุณอัปโหลดให้ใช้ ACL ที่เคยอยู่ในไฟร์วอลล์ (เช่น "อนุญาต 80 / tcp และ 443 / tcp ไปยังที่อยู่ IP นี้เท่านั้น") จากนั้นให้แต่ละส่วนหน้าของคุณรักษาเซสชัน BGP กับเราเตอร์ของคุณ คุณสามารถใช้ที่ดีเยี่ยมOpenBGPD (ถ้าส่วนหน้าของคุณอยู่ใน OpenBSD) หรือQuagga เราเตอร์ของคุณจะ ECMP ปริมาณการใช้งานไปยังส่วนหน้าที่มีสุขภาพดี (เพราะพวกเขากำลังรักษาเซสชัน BGP ของพวกเขา) เราเตอร์จะกำหนดเส้นทางทราฟฟิกให้เหมาะสมโดยใช้ PBR
การปรับแต่ง
- ด้วยโซลูชันการจับคู่ไฟร์วอลล์จะดีถ้าคุณสามารถซิงโครไนซ์สถานะ TCP ข้ามไฟร์วอลล์ดังนั้นเมื่อไฟร์วอลล์หนึ่งล้มเหลวทุกอย่างจะล้มเหลวอย่างราบรื่นกับอีกอันหนึ่ง
pfsyncคุณสามารถบรรลุนี้กับ
- โปรดทราบว่า
pfsyncโดยทั่วไปแล้วจะเพิ่มอัตราแพ็กเก็ตเป็นสองเท่าในไฟร์วอลล์ของคุณ
- HTTP เป็นโปรโตคอลไร้สัญชาติจึงไม่สิ้นสุดของโลกถ้าคุณตั้งค่าการเชื่อมต่อทั้งหมดในระหว่างการ failover
pfsyncไฟร์วอลล์เพราะคุณไม่ได้ใช้
- หากคุณขยายไฟร์วอลล์มากกว่าหนึ่งครั้งคุณสามารถใช้ ECMP บนเราเตอร์ของคุณเพื่อกำหนดเส้นทางการรับส่งข้อมูลของคุณไปยังไฟร์วอลล์มากกว่าหนึ่งคู่
- หากคุณใช้ไฟร์วอลล์มากกว่าหนึ่งคู่คุณอาจทำให้พวกมันใช้งานได้ / ใช้งานอยู่ คุณสามารถทำได้โดยการให้ไฟร์วอลล์รักษาเซสชัน BGP กับเราเตอร์เหมือนกับที่ frontends จำเป็นต้องรักษาไว้ในการออกแบบที่ 2 โดยไม่มีไฟร์วอลล์
ตัวอย่างrelaydการตั้งค่า
ดู HOWTO ได้ที่https://calomel.org/relayd.html
vip = "1.2.3.4" # ที่อยู่ IP สาธารณะของคุณ
# (คุณสามารถมีได้มากกว่าหนึ่ง แต่ไม่จำเป็นต้อง)
FE1 = "10.1.2.101"
Fe2 = "10.1.2.102"
Fe3 = "10.1.2.103"
fe4 = "10.1.2.104" # คุณสามารถมีส่วนหน้าได้จำนวนเท่าใดก็ได้
int_if = "em0"
ตาราง <fe> ลองลองอีกครั้ง {$ fe1 2, ลองอีก $ fe2 2, ลองอีก $ $ fe3 2, $ fe4 ลองอีก 2}
ตาราง <fallback> {127.0.0.1}
webtraffic เปลี่ยนเส้นทาง {
ฟังบนพอร์ต $ vip 80
หมดเวลาเซสชัน 60
เส้นทางไปที่ <fe> ตรวจสอบ http "/healthcheck.html" digest "(sha1sum of healthcheck.html)" ส่วนต่อประสาน $ int_if
}