ออกแบบ Multi-Site Cluster สำหรับหลายสาขาและหลาย Data Center

① Multi-Site Cluster คืออะไร

Multi-Site Cluster คือการนำ Cluster เดียว

กระจายอยู่มากกว่าหนึ่งสถานที่

ตัวอย่าง

Data Center A
Bangkok

และ

Data Center B
Khon Kaen

หรือ

Primary Site

ร่วมกับ

Disaster Recovery Site

โดยทุก Node ยังคงทำงานเป็น Cluster เดียวกัน

ช่วยเพิ่มความพร้อมใช้งานและรองรับ Disaster Recovery


② ทำไมองค์กรขนาดใหญ่จึงใช้ Multi-Site Cluster

ปัญหาของ Cluster แบบ Site เดียว

คือ

Site Failure

หากเกิด

  • ไฟดับ
  • น้ำท่วม
  • ไฟไหม้
  • Network Outage

Cluster ทั้งหมดอาจหยุดทำงาน

Multi-Site Cluster ถูกออกแบบมาเพื่อแก้ปัญหานี้


③ เป้าหมายของ Multi-Site Cluster

ระบบที่ดีควรมี

✅ Site Resilience

✅ Disaster Recovery

✅ Business Continuity

✅ High Availability

✅ Geographic Redundancy

เพื่อให้ธุรกิจดำเนินต่อได้แม้ Site หนึ่งล่ม


④ Site Architecture พื้นฐาน

ตัวอย่าง

Site A
Host01
Host02
Host03
Site B
Host04
Host05
Host06

ทุก Node

ทำงานร่วมกันภายใต้ Cluster เดียว


⑤ Active-Active กับ Active-Passive

มี 2 รูปแบบหลัก

Active-Active

ทั้งสอง Site

ให้บริการพร้อมกัน

ข้อดี

✅ ใช้ทรัพยากรคุ้มค่า

ข้อเสีย

❌ ซับซ้อนกว่า


Active-Passive

Site หลักทำงาน

Site สำรองรอรับงาน

ข้อดี

✅ บริหารง่าย

ข้อเสีย

❌ ทรัพยากรบางส่วนไม่ได้ใช้งาน


⑥ วางแผน Latency ให้ดี

Multi-Site Cluster

ต้องพิจารณา

Latency

อย่างจริงจัง

โดยทั่วไป

Microsoft แนะนำ

Latency ต่ำที่สุดเท่าที่เป็นไปได้

โดยเฉพาะ

  • Storage Replication
  • Live Migration

⑦ Site-to-Site Connectivity

ควรมี

อย่างน้อย

2 Independent Links

ระหว่าง Site

ตัวอย่าง

MPLS

ร่วมกับ

Internet VPN

เพื่อป้องกัน Single Point of Failure


⑧ Storage Replication

หัวใจสำคัญของ Multi-Site Cluster

คือ

Storage Replication

ตัวเลือกยอดนิยม

Storage Replica

ใน Windows Server 2025

หรือ

SAN Replication

จากผู้ผลิต Storage


⑨ Synchronous Replication

ข้อมูลถูกเขียนทั้งสอง Site พร้อมกัน

ข้อดี

✅ RPO = 0

ข้อเสีย

❌ ต้องใช้ Latency ต่ำมาก

เหมาะกับ Site ที่อยู่ใกล้กัน


⑩ Asynchronous Replication

ข้อมูลถูกส่งตามหลัง

ข้อดี

✅ รองรับระยะทางไกล

ข้อเสีย

❌ อาจสูญเสียข้อมูลบางส่วน

เหมาะกับ DR Site ต่างจังหวัดหรือข้ามประเทศ


⑪ Quorum Design สำหรับ Multi-Site

สิ่งสำคัญมาก

คือ

Quorum

ตัวอย่าง

Site A
3 Votes
Site B
3 Votes

ร่วมกับ

Cloud Witness

ช่วยป้องกัน

Split Brain

ได้อย่างมีประสิทธิภาพ


⑫ Cloud Witness

Windows Server 2025

รองรับ

Cloud Witness

ผ่าน Microsoft Azure

ข้อดี

✅ ติดตั้งง่าย

✅ ราคาถูก

✅ ลดความซับซ้อน

จึงเป็นตัวเลือกยอดนิยมในปัจจุบัน


⑬ Live Migration ระหว่าง Site

สามารถย้าย VM

ระหว่าง Data Center ได้

ผ่าน

Live Migration

แต่ควรมี

  • Bandwidth เพียงพอ
  • Latency ต่ำ
  • Network Redundancy

เพื่อให้การย้าย VM ราบรื่น


⑭ Disaster Recovery Scenario

ตัวอย่าง

หาก

Site A

ล่มทั้งหมด

Cluster จะย้าย Service ไป

Site B

โดยอัตโนมัติ

ช่วยลด Downtime ของธุรกิจ

อย่างมาก


⑮ Monitoring Multi-Site Cluster

ควรติดตาม

✅ Replication Status

✅ Latency

✅ Cluster Health

✅ Failover Event

✅ Storage Health

อย่างต่อเนื่อง


⑯ Security Best Practice

ควรใช้

✅ MFA

✅ Tiered Administration

✅ PAW

✅ Network Segmentation

✅ Encryption

โดยเฉพาะ

Traffic ระหว่าง Site


⑰ ข้อผิดพลาดที่พบบ่อย

❌ ไม่มี DR Plan

❌ ใช้ Link เดียว

❌ ไม่มี Quorum Design

❌ Replication ไม่เพียงพอ

❌ ไม่เคยทดสอบ Failover

❌ ไม่มี Monitoring

❌ ไม่มี Runbook


⑱ ตัวอย่าง Architecture ระดับ Enterprise

Site A
Host01
Host02
Host03

Storage Replica

Site B
Host04
Host05
Host06

และใช้

Cloud Witness

สำหรับ Quorum


⑲ แนวทางที่องค์กรระดับโลกนิยมใช้

องค์กรระดับ Enterprise มักใช้

Multi-Site Cluster

ร่วมกับ

Storage Replica
Cloud Witness
Geo Redundancy
Disaster Recovery Testing

เพื่อรองรับเหตุการณ์ระดับ Data Center Failure


⑳ สรุป

Multi-Site Cluster เป็นโครงสร้างพื้นฐานที่ช่วยให้องค์กรสามารถรับมือกับเหตุการณ์ที่กระทบทั้ง Site ได้อย่างมีประสิทธิภาพ ไม่ว่าจะเป็นภัยพิบัติหรือความล้มเหลวของ Data Center การออกแบบที่ดีต้องคำนึงถึง Replication, Connectivity, Quorum และ Disaster Recovery Testing ควบคู่กัน

จากประสบการณ์ของ comsiam องค์กรจำนวนมากมี Cluster ที่แข็งแรงภายใน Data Center เดียว แต่ไม่มีแผนรองรับเมื่อ Site ทั้ง Site หยุดทำงาน และ comsiam มักแนะนำให้เริ่มต้นจาก Storage Replica, Cloud Witness และ DR Testing อย่างน้อยปีละ 2 ครั้ง เพื่อให้มั่นใจว่าเมื่อเกิดเหตุจริง ระบบจะสามารถกลับมาให้บริการได้ตาม SLA ที่กำหนด

คำถามชวนคิด

หาก Data Center หลักขององค์กรหยุดทำงานทั้งศูนย์ในคืนนี้ คุณมั่นใจหรือไม่ว่าระบบสำคัญทั้งหมดจะสามารถย้ายไปยัง Site สำรองได้ภายในเวลาที่ธุรกิจยอมรับได้?