ตัวโหลดบาลานซ์จะส่งคืนอะไร


12

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

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

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


คำตอบ:


13

end-IP ไม่ได้รับการเผยแพร่ กระบวนการทำงานในลักษณะที่ลูกค้า (ผู้ใช้ที่กดปุ่มบาลานเซอร์) เชื่อว่าพวกเขากำลังสื่อสารกับบาลานเซอร์ขณะพูดคุยกับโหนดจริง

ในคำอธิบายง่ายๆธุรกรรมส่วนใหญ่ทำงานดังนี้

  1. ผู้ใช้ทำการร้องขอไปยังตัวโหลดบาลานซ์
  2. ตัวสร้างสมดุลจะตัดสินใจว่าโหนดใดเหมาะสมที่สุด (ขึ้นอยู่กับกลยุทธ์ที่คุณใช้ในการปรับสมดุล) และ IP ปลายทาง (เปลี่ยน) choses (เปลี่ยน)
  3. (นี่คือที่ที่เวทมนตร์เกิดขึ้น) โหนดได้รับการร้องขอยอมรับการเชื่อมต่อและตอบกลับไปที่บาลานเซอร์
  4. balancer เปลี่ยน IP การตอบสนองกลับไปเป็น virtual หนึ่งใน balancer และส่งต่อการตอบสนองต่อผู้ใช้
  5. สวัสดี, ผู้ใช้รับการตอบสนองกับ IP ของการร้องขอเริ่มต้น, แม้ว่ามันจะถูกประมวลผลจริงที่อื่น

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


4

Lad balancer ทำงานบนเลเยอร์ 4 OSI มัน decapsulate แพ็กเก็ตจนกว่าหมายเลขพอร์ตแล้วกำกับแพ็กเก็ตด้วยหนึ่งใน 3 โหมด

ตัวโหลดบาลานซ์สามารถทำงานใน 3 โหมด: 1. การกำหนดเส้นทางโดยตรง ในโหมดนี้เซิร์ฟเวอร์ reals ของคุณใช้ IP สาธารณะ balancer ได้รับแพ็กเก็ตและ decapsulate จนกระทั่งเลเยอร์ 4 หากตรงกับกฎของ load balance มันจะเปลี่ยนเส้นทางแพ็กเก็ต (โดยไม่มีการแก้ไข) ไปยังหนึ่งใน realserver Realserver มีที่อยู่นามแฝงเหมือนกันกับที่อยู่ของ loadbalance ดังนั้นเมื่อ realserver ได้รับแพ็กเก็ตที่มีปลายทาง xxx.xxx.xxx.xxx จะกำหนดแพ็กเก็ตนั้นให้ตรงกับที่อยู่ของเขา (นามแฝง) และจากนั้นคำขอการตอบกลับเซิร์ฟเวอร์จริงไปยังไคลเอนต์โดยตรง (ไม่ใช่ผ่านการโหลดบาลานซ์)

2. NAT ในโหมดนี้แพ็คเก็ตเปลี่ยนเส้นทางไปยัง realserver ด้วยการแก้ไขที่อยู่ปลายทาง ที่อยู่ปลายทางจะถูกแทนที่ด้วยที่อยู่ realserver (NAT) ในโหมดนี้เซิร์ฟเวอร์ reals ของคุณไม่ต้องการ IP สาธารณะก็สามารถใช้เครือข่ายท้องถิ่นของคุณ และจากนั้นแพ็คเก็ตจะถูกส่งไม่มีที่อยู่ปลายทางใหม่ เมื่อ realserver ได้รับแพ็คเก็ตมันจะตอบกลับไปยังไคลเอนต์ที่อยู่เกตเวย์คำขอราง (loadbalance) ในโหมดนี้โหลดบาลานซ์ของคุณใช้เป็นเราเตอร์และเกตเวย์ของเซิร์ฟเวอร์ reals ของคุณ

3. Tunnel ในโหมดนี้แพ็กเก็ตจะถูกส่งสัญญาณด้วยที่อยู่ src-dst ใหม่ (เช่น vpn) เพื่อส่งแพ็กเก็ตไปยัง realserver เมื่อได้รับแพ็คเก็ตใน realserver realserver จะได้รับการตอบกลับผ่านไปป์ที่ tunneled เพื่อ loadbalance จากนั้นการจัดส่งโหลดบาลานซ์จะตอบกลับที่อยู่ต้นทางของคำขอจริง

สำหรับ HTTPS / SSL loadbalance ไม่ได้ประมวลผลให้โหลดกระบวนการดุลจนกระทั่งเลเยอร์ 4 OSI เลเยอร์ 5 ด้านบนจะดำเนินการใน realserver ดังนั้น TCP 3 จึงมีวิธี hanshake, SSL / HTTPS จะประมวลผลใน realserver Loadbalance ผู้อำนวยการของแพ็กเก็ตเท่านั้น

ฉันหวังว่าคำอธิบายเล็ก ๆ ของฉันจะช่วยอะไรบางอย่าง


ดูเหมือนว่าคุณกำลังพูดถึงเลเวลที่นี่ แต่ไม่จำเป็นว่าวิธีการปรับสมดุลภาระงาน http (s) ลองดูที่ haproxy แอพนี้ทำการโหลดบาลานซ์ใน userland และใช้ประโยชน์จากฟังก์ชั่นการกำหนดเส้นทางแบ็กเอนด์ที่ดี
Friek

ในดาต้าเซ็นเตอร์ของฉันฉันใช้ lvs เพื่อโหลดยอดคงเหลือของบริการแอพ https ของฉันและมันทำงานและทำงานได้ดี
dek.tiram

ขอโทษที่ฉันไม่รู้ แต่ "lvs" คืออะไร? เป็นคู่แข่งกับ haproxy หรือไม่?
smaili

Haproxy ยังใช้เลเวล ฉันใช้ปิรันย่าซึ่งใช้เลเวลสำหรับกระบวนการหลักด้วย
dek.tiram

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

-1

ตัวโหลดบาลานซ์อาจเป็นเราเตอร์หรือพร็อกซีย้อนกลับ:

LVS เป็นโมดูลโหลดบาลานซ์เลเยอร์ 4 (อิงตามการกำหนดเส้นทาง) ตามมาตรฐานอุตสาหกรรมสำหรับเคอร์เนล Linux มันถูกใช้ในเครื่องถ่วงโหลดเชิงพาณิชย์หลายประเภทรวมถึง Barracuda, Loadbalancer.org และ Kemp Technologies Barracuda และ Loadbalancer.org ยังใช้ HAProxy สำหรับการทำโหลดบาลานซ์เลเยอร์ 7 ( reverse proxy based )

ps ฉันลืมสิ่งนี้ไม่แสดงว่าฉันมาจากไหน


1
เมื่อโพสต์ลิงก์ไปยังแหล่งข้อมูลภายนอกคน ๆ หนึ่งคาดว่าจะเปิดเผยความร่วมมือดูที่จะไม่เป็นผู้ส่งสแปมได้อย่างไร
gnat
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.