Storage Area Network (SAN) นั้นเริ่มมีการใช้งานเชิงพาณิชย์ตั้งแต่ปี 1997 และมีการใช้งานเรื่อยมา เพราะในยุคนั้น การทำทุกอย่างให้รวมศูนย์นั้นกำลังได้รับความนิยม แต่หลังจากการเข้ามาของ Hyper-Converged Infrastructure (HCI) ประมาณปี 2010 ทำให้แนวคิดเรื่องการใช้ storage เริ่มเปลี่ยนไป เพราะการใช้งานแบบกระจายนั้น ทำให้เราได้ การรองรับความเสียหายของข้อมูลได้ดีกว่า ควบคุมการกระจายได้ดี และ มีความยืดหยุ่นสูง ในขณะเดียวกันความต้องการที่จะควบคุมทุกอย่างด้วย Software ก็เริ่มมีการพัฒนาขึ้นเรื่อยๆ ดังนั้นหากจะกล่าวได้ว่า ในวงการ IT สมัยใหม่ โดยเฉพาะในโลกของ Cloud-Native, HCI และ Containerization มีเหตุผลที่ SAN เริ่มถูกลดบทบาทลงอย่างมาก จึงเป็นเรื่องที่ไม่ผิดนัก เรามาดูกันว่าทำไม

ทำไม SAN จึงถือว่า “ไม่เหมาะ” กับยุคปัจจุบัน
1. แพงเกินไปเมื่อเทียบกับเทคโนโลยีทางเลือก : SAN ต้องพึ่งพา ฮาร์ดแวร์เฉพาะทาง เช่น Fibre Channel Switch, HBA, RAID Controller และ SAN Storage Arrays ที่มีราคาสูงมาก และยัง ต้องใช้ Storage Admin ที่มีความรู้เฉพาะด้าน (specialist) ทำให้มีต้นทุนบุคลากรสูงขึ้นด้วย
เมื่อเทียบกับ Software-Defined Storage (SDS) เช่น Ceph, GlusterFS หรือ ZFS ที่รันบนเซิร์ฟเวอร์ทั่วไป (commodity hardware) แล้ว SAN มักจะแพงกว่าอย่างมีนัยสำคัญ

2. ไม่สอดคล้องกับแนวทาง Hyper-Converged (HCI) : โลกยุคใหม่มุ่งสู่ HCI ที่รวม compute + storage + network ไว้ใน node เดียวกัน (เช่น Proxmox + Ceph) แต่ SAN แยก Storage ออกจาก Compute อย่างเด็ดขาด ซึ่งขัดแย้งกับแนวคิด “scale-out” แบบ horizontal
SAN มีสเกลที่จำกัด (scale-up) หรือการขยายในแนวตั้ง หากต้องขยายระบบต้องอัพเกรด storage array เดิมแทนที่จะเพิ่ม node ใหม่ง่าย ๆ

3. ไม่เหมาะกับ Cloud-Native / Container Workload : Container เช่น Kubernetes ต้องการ storage แบบ dynamic, scalable, และสามารถใช้ block หรือ file ได้ตาม workload แต่ SAN ให้ block storage อย่างเดียว (เช่น iSCSI, FC) ซึ่งไม่ flexible เท่า SDS ที่ให้ทั้ง block, object, และ file และการผูก volume ใน container ecosystem เช่น CSI (Container Storage Interface) ก็ไม่สนับสนุน SAN แบบ native ได้ดีนัก

4. ข้อจำกัดด้าน Network และ Latency : SAN มักจะใช้ Fibre Channel ซึ่งมีความเร็วสูงก็จริง แต่ แพงมาก, ซับซ้อน ผูกขาดกับเจ้าใดเจ้าหนึ่ง และ ไม่ scale ได้ดีนัก ในยุคที่ network 25/40/100 GbE กลายเป็นมาตรฐานใน datacenter ไปแล้ว นอกจากนั้นแล้ว SAN ที่ใช้ iSCSI บน Ethernet ก็ยังสู้การ optimize ของ SDS ที่ออกแบบมาสำหรับ TCP/IP ไม่ได้

5. ซับซ้อนในการบริหารจัดการ : ต้องมีการจัด zoning, masking, LUN mapping ฯลฯ ซึ่งต้องการความชำนาญเฉพาะ และ การขยาย, สำรองข้อมูล, replicate ต้องทำผ่านเครื่องมือเฉพาะของ vendor รายใดๆ ซึ่งเทียบกับการผูกขาดนั่นเอง หากเทียบกับ Ceph/ZFS ที่จัดการผ่าน CLI หรือ API ได้ง่ายกว่าและสามารถ Integrate กับระบบ automation เช่น Ansible, Terraform ได้ง่าย

การใช้งาน SAN และ Proxmox VE
การใช้ SAN กับ Proxmox VE Cluster นั้น “สามารถทำได้” แต่ในยุคปัจจุบันถือเป็น แนวทางที่ควรหลีกเลี่ยง ด้วยเหตุผลหลายประการที่เกี่ยวข้องกับ สถาปัตยกรรม, ความยืดหยุ่น, ความซับซ้อนในการบริหาร และต้นทุน

จากรูป ท่านจะสังเกตว่า เนื่องจาก SAN นั้นจะทำให้ท่านมองเห็น LUN นั้นพร้อมกันทั้ง 3 Nodes แต่เนื่องจาก Proxmox VE นั้นไม่ได้มี File System เป็นของตนเองโดยเฉพาะ เช่นเดียวกับ VMFS ในขณะที่ Ceph ก็ออกแบบมาบนหลักการ Software Defined Storage ซึ่งแย้งกันหมด เพราะฉะนั้น หากท่านใช้ SAN เลยกลายเป็นว่า ท่านจะต้องมี อย่างน้อย 3 LUNs เพื่อให้ LUN แต่ละตัว ทำหน้าที่เป็น internal disk ของแต่ละ Node ซึ่งไม่จำเป็นและ ราคาแพง

1. ไม่สอดคล้องกับแนวคิด High Availability (HA) แบบ Proxmox VE : Proxmox VE ใช้ Corosync และ Proxmox HA Manager เพื่อจัดการ HA ซึ่งต้องการ shared storage ที่เชื่อถือได้และตอบสนองเร็ว หาก SAN มี latency หรือ I/O แขวนชั่วคราว จะทำให้ cluster เข้าใจว่า VM หยุดทำงานและอาจ fence (ปิด) node ผิดพลาด การ mount SAN แบบ LVM over iSCSI หรือ multipath มีความซับซ้อนและ เสี่ยงต่อ split-brain หรือ lock conflict

2. Proxmox VE ถูกออกแบบมาสำหรับ Shared-Nothing Architecture : แนวคิดของ Proxmox VE (โดยเฉพาะเมื่อใช้ Ceph) คือ ทุก node มี local storage ที่สามารถ replicate กันได้ ในขณะที่ SAN ทำให้ต้อง centralize I/O ทั้งหมดไปยัง storage กลาง ทำให้เกิด single point of failure
นอกจากนั้นแล้ว การใช้ Ceph (หรือ ZFS Replication) ทำให้สามารถสร้าง cluster ที่ scale-out ได้ง่ายกว่า และ node ใดล่มก็ไม่ทำให้ระบบทั้งหมดหยุด

3. ต้นทุนสูง และติด vendor lock-in : SAN ต้องใช้ฮาร์ดแวร์เฉพาะ (RAID, FC Switch, Enterprise Storage, HBA) ซึ่งมีราคาสูงมาก
และ SAN software ส่วนใหญ่เป็น proprietary เฉพาะแต่ละผู้ผลิต ทำให้ยากต่อการ integrate กับ Proxmox (ซึ่งเป็น open-source) และถ้าหาก
ถ้าต้องการ feature อย่าง snapshot, replication, thin provisioning จำเป็นต้องพึ่ง SAN vendor แทนที่จะใช้ built-in ของ Proxmox/Ceph/ZFS

4. ซับซ้อนต่อการบริหาร และ Debug : การ mount SAN LUN ให้กับหลาย node ใน Cluster ต้องจัดการ LVM, multipath, และ locking ให้ถูกต้อง เป็นเรื่องยาก และ หากมีปัญหา I/O หรือ network ระหว่าง Proxmox กับ SAN ก็จะยากต่อการวิเคราะห์และตรวจหาปัญหา อัปเดต firmware หรือเปลี่ยน config ของ SAN อาจกระทบทั้ง cluster ได้โดยไม่ตั้งใจ

5. Performance และ Scalability ไม่ดีเท่า SDS : ข้อนี้สำคัญมากเพราะ SAN แบบ iSCSI หรือ FC มี latency มากกว่า Ceph (ถ้าใช้บนเครือข่าย 10GbE ขึ้นไป) ขยาย storage ต้องทำผ่าน SAN vendor เช่น เพิ่ม LUN นอกจากแพง และไม่ยืดหยุ่น เทียบกับ Ceph: เพิ่ม node ก็เพิ่ม storage + compute ได้ทันที

6. Feature บางอย่างของ Proxmox VE ทำงานได้ดีกว่ากับ Ceph/ZFS : Live Migration, Snapshot, Backup, Replication ทำงาน “ดีที่สุด” กับ Ceph หรือ ZFS Proxmox VE มีการ Integrate กับ Ceph อย่างไร้รอยต่อ ทั้ง GUI, Monitoring, Management นอกจากนั้นท่านยังใช้ tools ของ 3rd party มาบริหารก็ได้

โดยรวมแล้วต้องบอกว่า การใช้ SAN นั้น out มากๆ แล้วในยุคที่ HCI และ Cloud กำลังเฟื่องฟู เพราะทุกอย่าง ควรจะขยายได้ในแนวราบ (horizontal) ไม่ใช่แนวตั้ง (vertical) อีกต่อไป และ ที่สำคัญราคาก็แพงมาก ๆ เหมือนกับถูกล็อกว่าต้องใช้ยี่ห้อใด ยี่ห้อหนึ่ง ซึ่งเป็นแนวคิดที่เก่าแล้ว

กรณีที่ท่านจำเป็นต้องใช้ SAN เช่นอาจจะใช้ของที่มีอยู่เดิม และ ทำงานร่วมกับ VMware ก่อนหน้านี้ ท่านสามารถศึกษา Scenario หรือ การเชื่อมต่อแบบต่างๆ ได้เพิ่มเติมโดยการดาวน์โหลด PDF ของเรา คลิกที่นี่

หากมีปัญหาในการใช้งานไม่ว่าเรื่องใด เรายินดีให้คำปรึกษาท่าน บจก. อเวสต้า เป็นตัวแทน Proxmox VE อย่างเป็นทางการ จำหน่าย ติดตั้ง บริการหลังการขาย ด้วยวิศวกรผู้เชี่ยวชาญโดยตรง ปรึกษาเราวั้นนี้ที่ Line OA : @avesta.co.th หรืออีเมล์ [email protected]

• Facebook
• Twitter
• Line