ศูนย์คู่มือ Ruk-Com PaaS

คู่มือการพัฒนา Deploy และดูแล Application บน Platform

RUK-COM PAAS / APPLICATION SETTINGS

Load Balancer ที่ใช้ร่วมกัน

คู่มือนี้เรียบเรียงสำหรับ Ruk-Com PaaS หน้าจอและตัวเลือกอาจแตกต่างตามเวอร์ชันและสิทธิ์ของบัญชี

ตรวจสอบ Environment, Region, สิทธิ์บัญชี และสำรองค่าปัจจุบันก่อนดำเนินการกับระบบจริง

ปรับปรุงตามเอกสาร Platform ปัจจุบัน

ตรวจสอบชื่อเมนู ตัวเลือก และข้อกำหนดล่าสุดจากเนื้อหาภาษาอังกฤษในหน้าเดียวกันก่อนดำเนินการกับระบบจริง

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

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

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

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

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

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

ภาพประกอบขั้นตอนการใช้งาน Ruk-Com Cloud PaaS

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

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

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

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

ภาพประกอบขั้นตอนการใช้งาน Ruk-Com Cloud PaaS

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

Ruk-Com PaaS Shared Load Balancer ตรวจสอบสภาพของ Server อย่างต่อเนื่อง โดยตรวจสอบโมดูลNGINX อัปสตรีมด้วยการตั้งค่าต่อไปนี้:

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

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

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

  • NGINX- ตรวจสอบโดยรัน tcp อย่างง่าย (เช่น ตรวจสอบความพร้อมใช้งานของ Port Server ที่จำเป็น) ก่อนกำหนดเส้นทางคำขอของผู้ใช้ หากการตรวจสอบล้มเหลว จะลอง Node ถัดไปภายใน Layer
  • HAProxy- ตรวจสอบ tcp ปกติ (ทุกๆ 2 วินาทีโดยค่าเริ่มต้น) เก็บผลลัพธ์ในตารางของสถานะ backend และทำเป็นปัจจุบันอยู่เสมอ
  • อาปาเช่ Balancer- ไม่มีขั้นตอนการตรวจสภาพตามค่าเริ่มต้น
  • วานิช- backends ทั้งหมดถูกกำหนดด้วย Parameter ต่อไปนี้เพื่อกำหนดค่า 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 โดยจะห้ามการเข้าถึง Container บนชื่อ Domain เริ่มต้นด้วยการคลิกเพียงครั้งเดียว (โดยไม่ต้องเพิ่ม public IP และปรับเปลี่ยน firewall) เพียงสลับปุ่ม Access via SLB ที่ topology wizard

ภาพประกอบขั้นตอนการใช้งาน Ruk-Com Cloud PaaS

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

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

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

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

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

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

ภาพประกอบขั้นตอนการใช้งาน Ruk-Com Cloud PaaS

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

ภาพประกอบขั้นตอนการใช้งาน Ruk-Com Cloud PaaS

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

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

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