High Availability ด้วย Sticky Session Replication
คู่มือนี้เรียบเรียงสำหรับ Ruk-Com PaaS หน้าจอและตัวเลือกอาจแตกต่างตามเวอร์ชันและสิทธิ์ของบัญชี
ตรวจสอบ Environment, Region, สิทธิ์บัญชี และสำรองค่าปัจจุบันก่อนดำเนินการกับระบบจริง
วัตถุประสงค์
บทความนี้อธิบายการใช้งาน High Availability ด้วย Sticky Session Replication บน Ruk-Com Cloud PaaS โดยจัดลำดับขั้นตอนและจุดตรวจสอบสำหรับการนำไปใช้งานจริง
ก่อนเริ่มดำเนินการ
- เข้าสู่ระบบด้วยบัญชีที่มีสิทธิ์จัดการ Environment ที่เกี่ยวข้อง
- ตรวจสอบชื่อ Environment, Region และ Resource เป้าหมายก่อนบันทึกการเปลี่ยนแปลง
- สำรองข้อมูลหรือกำหนดแผนย้อนกลับก่อนแก้ไขระบบ Production
Ruk-Com Cloud จัดเตรียมการจำลอง Session อัตโนมัติระหว่าง Server Tomcat, GlassFish และ Jetty เพื่อให้ Application เว็บมีความพร้อมใช้งานสูงภายใน Java Cluster
การจำลอง Session เป็นกลไกที่ใช้ในการจำลองข้อมูลที่จัดเก็บไว้ใน Session ระหว่าง Instance ต่างๆซึ่งจะต้องเป็นส่วนหนึ่งของ Cluster เดียวกัน เมื่อเปิดใช้งานการจำลองแบบ Session ใน Cluster environment ข้อมูล Session ทั้งหมดจะถูกคัดลอกบน Instance ที่จำลอง (ทำสำเนาใหม่) การดำเนินการจำลอง Session จะไม่คัดลอก attributes ที่ไม่สามารถทำให้เป็นอนุกรมใน Session และข้อมูลเฉพาะของ Instance การจำลองแบบ Session ที่มีความน่าเชื่อถือ ความสามารถในการปรับขนาด และความสามารถในการรองรับ failover ที่สมบูรณ์แบบ
กระบวนการจำลองใน Ruk-Com Cloud ด้วย multicast มีข้อดีดังต่อไปนี้:
- การแลกเปลี่ยน Session ระหว่าง Node ผ่าน local net;
- ไม่จำเป็นต้องใช้โปรแกรมประเภท memcache เพิ่มเติมทำให้ระบบมีจุดทำลายน้อยลง
วิธีเปิดใช้งานการจำลองแบบ Session
หากต้องการใช้การจำลองใน Ruk-Com Cloud คุณสามารถทำตามข้อมูลต่อไปนี้:
เข้าสู่ระบบ Com Cloud แล้วคลิก New Environment
เลือก Application Server ที่คุณต้องการและเปิด High-Availability ดังภาพด้านล่าง:
ในขณะที่สร้าง environment การดำเนินการทั้งหมดจะแสดงใน Tasks:
เมื่อติดตั้ง environment เสร็จแล้วคุณจะเห็น environment ปรากฏดังภาพด้านล่าง:
กระบวนการทำงาน
เมื่อผู้ใช้ส่งคำขอครั้งแรกไปยังเว็บ ApplicationLoad Balancer (NGINX) คำขอนั้นจะเปลี่ยนเส้นทางไปยัง Server ใด Server หนึ่งภายใน Cluster โดยตลอด Session ผู้ใช้จะยังคงทำงานกับ Instance ของ Application Server เดียวกันต่อไป (เรียกว่า Sticky Sessions) ซึ่งเห็นได้ชัดว่า Instance อื่นใน Cluster ยังทำงานได้ครึ่งหนึ่ง
หาก Instance ใดล้มเหลว ผู้ใช้ที่อยู่ใน Instance นั้นจะถูกสลับไปยัง Instance อื่นใน Cluster นี้โดยอัตโนมัติการจำลองแบบ ทำให้ Instance อื่นมี Session ทั้งหมดของ Instance ที่ล้มเหลวอยู่แล้ว ดังนั้นผู้ใช้ปลายทางจะไม่สังเกตเห็นการเปลี่ยนแปลงใดๆ ในกรณีที่ทั้งสอง Instance ใน Cluster เกิดความล้มเหลวซึ่งไม่น่าจะเป็นไปได้สูง ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง Cluster อื่น (หากมีหลายรายการ)
นอกจากนี้ผู้ใช้ยังสามารถเปิด/ปิดการจำลองภายใน environment ที่สร้างไว้แล้วได้โดยการเปลี่ยน topology