โหลดบาลานเซอร์ที่ใช้ร่วมกัน

วัตถุประสงค์

บทความนี้อธิบายการใช้งาน โหลดบาลานเซอร์ที่ใช้ร่วมกัน บน Ruk-Com Cloud PaaS โดยจัดลำดับขั้นตอนและจุดตรวจสอบสำหรับการนำไปใช้งานจริง

ก่อนเริ่มดำเนินการ

• เข้าสู่ระบบด้วยบัญชีที่มีสิทธิ์จัดการ Environment ที่เกี่ยวข้อง
• ตรวจสอบชื่อ Environment, Region และทรัพยากรเป้าหมายก่อนบันทึกการเปลี่ยนแปลง
• สำรองข้อมูลหรือกำหนดแผนย้อนกลับก่อนแก้ไขระบบ Production

Ruk-Com Cloud แพลตฟอร์มจัดเตรียม Shared Load Balancer (ตัวแก้ไข) ให้กับคุณโดยแสดงถึงพร็อกซีเซิร์ฟเวอร์ NGINXระหว่างฝั่ง client (เช่น เบราว์เซอร์) และแอปพลิเคชันของคุณซึ่งปรับใช้กับ Ruk-Com Cloud

กระบวนการ Shared LB จะประมวลคำขอที่เข้ามาทั้งหมดโดยจะส่งไปยังชื่อโดเมนของ environment โดเมนของสภาพแวดล้อม ({user_domain}.{Hoster_domain}) ซึ่งจุดเข้าใช้งาน (balancer, application server หรือแม้แต่ database) ที่ไม่ได้แนบไอพีสาธารณะที่อยู่

LB ที่ใช้ร่วมกันจะประมวลผลคำขอที่ส่งไปยังแอปพลิเคชันทั้งหมดซึ่งอยู่ภายใน hardware node เดียวกันเพื่อป้องกันการโจมตีจากดีดอสโดย Shared Load Balancer จะจำกัดการเชื่อมต่อพร้อมกัน 50 รายการต่อ source address ที่ขอเข้ามา

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

ด้วยเหตุนี้ทำให้มีจุดเข้าใช้งานหลายจุดสำหรับ environment ของผู้ใช้ทำให้ใช้งานพร้อมกันได้โดยวิธีนี้โหลดที่เข้ามาจะถูกกระจายอย่างมีประสิทธิภาพ

หมายเหตุ:เราแนะนำให้ใช้ Shared Resolver สำหรับ dev และ test environment และสำหรับ production environment ที่มีจุดประสงค์เพื่อจัดการกับการใช้งานสูงควรใช้ public IP ของคุณเองเพื่อรับและประมวลผลคำขอ นอกจากนี้ยังอนุญาตให้ใช้ตัวเลือกเพิ่มเติมจำนวนหนึ่งกับแอปพลิเคชันของคุณซึ่งอาจช่วยให้ปลอดภัยยิ่งขึ้น (เช่น Custom SSL) และตอบสนอง (ผ่านการแนบโดเมนที่กำหนดเอง)

การตรวจสอบ Backend Health ด้วย Shared Load Balancer

Jelastic Shared Load Balancer ตรวจสอบสภาพของเซิร์ฟเวอร์อย่างต่อเนื่อง โดยตรวจสอบโมดูลNGINX อัปสตรีมด้วยการตั้งค่าต่อไปนี้:

check interval=15000 rise=2 fall=3 timeout=2000 default_down=false;

ด้วยวิธีนี้คอนเทนเนอร์ทั้งหมดจะ "up" ตั้งแต่เริ่มต้น ระบบจะตรวจสอบความพร้อมใช้งานทุกๆ 15 วินาที หากคอนเทนเนอร์ไม่ตอบกลับภายใน 2 วินาทีจะถือว่าการตรวจสอบล้มเหลวและหากล้มเหลวติดต่อกัน 3 ครั้งจะเปลี่ยนเครื่องหมายที่โหนดเป็น "down" ในขณะที่ตรวจสอบสำเร็จสองครั้งติดต่อกัน - เป็น "up"

สำหรับการกระจายทราฟฟิกภายใน environment ที่แยกจากกัน load balancer node จะถูกเพิ่มลงใน topolopy โดยอัตโนมัติเมื่อมีการตั้งค่าจำนวนอินสแตนซ์แอปพลิเคชันเซิร์ฟเวอร์มากกว่าหนึ่งรายการ (ขยายแบบแนวนอน) Ruk-Com Cloud PaaS จัดเตรียม 4 load balancer stacks คุณสามารถเลือกได้ซึ่งแต่ละสแต็กจะมีการกำหนดค่าเฉพาะสำหรับการตรวจเช็คสภาพ:

• NGINX- ตรวจสอบโดยรัน tcp อย่างง่าย (เช่น ตรวจสอบความพร้อมใช้งานของพอร์ตเซิร์ฟเวอร์ที่จำเป็น) ก่อนกำหนดเส้นทางคำขอของผู้ใช้ หากการตรวจสอบล้มเหลว จะลองโหนดถัดไปภายในเลเยอร์
• HAProxy- ตรวจสอบ tcp ปกติ (ทุกๆ 2 วินาทีโดยค่าเริ่มต้น) เก็บผลลัพธ์ในตารางของสถานะ backend และทำเป็นปัจจุบันอยู่เสมอ
• อาปาเช่ บาลานเซอร์- ไม่มีขั้นตอนการตรวจสภาพตามค่าเริ่มต้น
• วานิช- backends ทั้งหมดถูกกำหนดด้วยพารามิเตอร์ต่อไปนี้เพื่อกำหนดค่า balancer (ดังนั้นจะตรวจสอบสภาพได้หนึ่งครั้งต่อนาทีโดย 30 วินาทีหมดเวลารอ):

probe = { .url = "/"; .timeout = 30s; .interval = 60s; .window = 5; .threshold = 2; } }

จะเห็นได้ว่าการตั้งค่า health check เริ่มต้นสามารถปรับได้ด้วยตนเองตามความต้องการของคุณ (ผ่าน File Manager GUI หรือผ่าน SSH) ตามข้อกำหนดของ load balancer stack ที่เหมาะสม - อ้างอิงถึงเอกสาร NGINX, HAProxy, Apache Balancer หรือ Varnish เพื่อดูรายละเอียดเกี่ยวกับการตั้งค่าที่เป็นไปได้

ปฏิเสธการเข้าถึงผ่าน Shared Load Balancer

Ruk-Com Cloud PaaS จัดเตรียมตัวเลือกที่กำหนดไว้ล่วงหน้าเพื่อปิดใช้งานการเข้าถึง environment nodes จาก SLB โดยจะห้ามการเข้าถึงคอนเทนเนอร์บนชื่อโดเมนเริ่มต้นด้วยการคลิกเพียงครั้งเดียว (โดยไม่ต้องเพิ่ม public IP และปรับเปลี่ยน firewall) เพียงสลับปุ่ม Access via SLB ที่ topology wizard

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

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

• สามารถเข้าถึงโหนดได้จาก Shared Load Balancer ผ่านชื่อโดเมน environment โดยการใช้พอร์ตเริ่มต้น (80, 8080, 8686, 8443, 4848, 4949, 7979)
• ปุ่ม Open Browser ที่เหมาะสมจะเปิดบริการ (เช่น database admin panel)
• ลิงก์ของโหนดจะแสดงอยู่ในอีเมล (ถ้าจำเป็น)

คุณสามารถปิดใช้งานฟีเจอร์การเข้าถึงผ่าน SLB ได้ด้วยตนเอง:

• โหนดไม่สามารถเข้าถึงได้จาก Shared Load Balancer - เลเยอร์ถูกแยกออกจาก SLB
• หน้าที่เข้าถึงได้ผ่านปุ่ม Open in Browser ในแดชบอร์ดจะ return the 403 Forbidden error แทนหน้าที่ต้องการ
• ลิงก์ของโหนดไม่รวมอยู่ในอีเมล
• การเข้าถึงผ่านสสสและผ่านจุดสิ้นสุดจะไม่ได้รับผลกระทบ

เพื่อความสามารถที่จะมองเห็นได้ดีขึ้นเลเยอร์ที่ปิดใช้งาน Access via SLB จะมีป้ายกำกับที่หน้าแดชบอร์ด

การเชื่อมต่อกับโหนดดังกล่าวผ่าน URL เริ่มต้นจะตอบกลับ error ต่อไปนี้:

ในส่วนของด้านล่างนี้ เราได้เตรียมตัวอย่างการใช้งานที่พบบ่อยสำหรับฟีเจอร์นี้:

• ปิดการเข้าถึงสาธารณะผ่าน SLB ไปยังโหนดที่มีไว้สำหรับการเข้าถึงภายในเท่านั้น (เช่น database)
• ห้ามการเข้าถึงผ่าน SLB ไปยังโหนดที่มี public IP address แนบอยู่และกำหนดโดเมนเอง
• กำหนด topology ที่อนุญาตการเชื่อมต่อผ่าน load balancer ของ environment แต่ห้ามการเข้าถึงผ่าน URL โดยตรงไปยังคอนเทนเนอร์

โดยทั่วไปคุณสามารถใช้ Access via SLB ได้สำหรับการพัฒนาและการทดสอบ อย่างไรก็ตามเราแนะนำให้ปิดการใช้งานฟีเจอร์นี้สำหรับแอปพลิเคชันเวอร์ชันที่ใช้งานจริงการผลิตและใช้ public Ip กับโดเมนที่กำหนดเองแทน