SAN NAS DAS คืออะไร? เปรียบเทียบ Storage ระดับองค์กร iSCSI, FC, NFS สำหรับ IT 2026

บทนำ: ทำไม Enterprise Storage ถึงเป็นหัวใจของระบบ IT องค์กร?

ในยุคที่ข้อมูลคือทรัพย์สินที่มีค่าที่สุดขององค์กร ระบบจัดเก็บข้อมูล (Storage) ไม่ใช่แค่ “ฮาร์ดดิสก์ในเครื่อง” อีกต่อไป แต่เป็น โครงสร้างพื้นฐานระดับ Enterprise ที่ต้องรองรับการเข้าถึงข้อมูลจากหลายร้อยหลายพันเครื่องพร้อมกัน ต้องมีความเร็วสูง ความเสถียรสูง และป้องกันข้อมูลสูญหายได้อย่างสมบูรณ์ ไม่ว่าจะเป็นฐานข้อมูล ERP, ไฟล์วิดีโอ, ระบบ Email หรือ Virtual Machine ทุกอย่างล้วนพึ่งพาระบบ Storage ทั้งสิ้น

คำว่า DAS, NAS และ SAN เป็นสถาปัตยกรรม Storage สามแบบหลักที่คนทำงาน IT ต้องเข้าใจ แต่หลายคนยังสับสนว่าต่างกันอย่างไร ใช้เมื่อไหร่ ตัวไหนเหมาะกับงานอะไร บทความนี้จะอธิบายทุกอย่างตั้งแต่พื้นฐานจนถึงระดับ implementation จริง ครอบคลุม protocol ต่างๆ เช่น Fibre Channel, iSCSI, FCoE, NFS, SMB/CIFS รวมถึงเรื่อง RAID, Thin Provisioning, Deduplication, Snapshot, Replication และ Software-Defined Storage

ส่วนที่ 1: DAS (Direct-Attached Storage) คืออะไร?

1.1 หลักการทำงานของ DAS

DAS หรือ Direct-Attached Storage คือรูปแบบ Storage ที่เชื่อมต่อโดยตรงกับ Server หรือ Workstation เครื่องเดียว โดยไม่ผ่าน Network ตัวอย่างที่ง่ายที่สุดคือ ฮาร์ดดิสก์ภายในเครื่อง PC หรือ External Hard Drive ที่เสียบ USB แต่ในระดับ Enterprise DAS มักเป็น ตู้ Disk Enclosure ภายนอก ที่เชื่อมต่อกับ Server ผ่าน interface ความเร็วสูง เช่น SAS (Serial Attached SCSI)

สถาปัตยกรรม DAS:
  ┌──────────────┐     SAS Cable      ┌──────────────────────┐
  │   Server A   │ ──────────────────► │   Disk Enclosure     │
  │              │                     │   (12 x SAS HDD)     │
  └──────────────┘                     │   RAID Controller    │
                                       └──────────────────────┘
  * Server A เข้าถึงได้โดยตรง
  * Server อื่นเข้าถึงไม่ได้ (ยกเว้น share ผ่าน OS)

1.2 Interface ที่ใช้กับ DAS

DAS ระดับ Enterprise ใช้ interface หลายแบบ:

• SAS (Serial Attached SCSI): มาตรฐานหลักสำหรับ Enterprise DAS ปัจจุบัน SAS-4 ให้ความเร็ว 22.5 Gbps per lane รองรับ multi-path และ dual-port สำหรับ High Availability
• SATA: ใช้สำหรับ disk ราคาประหยัด ความเร็วสูงสุด 6 Gbps ไม่รองรับ dual-port แต่ SAS controller สามารถใช้ disk SATA ได้ (reverse compatibility)
• NVMe (Non-Volatile Memory Express): interface สำหรับ SSD ความเร็วสูง ใช้ PCIe bus โดยตรง ให้ latency ต่ำมาก เหมาะกับงาน database ที่ต้องการ IOPS สูง
• USB/Thunderbolt: ใช้กับ external storage ขนาดเล็ก ไม่เหมาะกับ Enterprise

1.3 ข้อดีและข้อจำกัดของ DAS

ข้อดี:

• ง่ายในการติดตั้งและจัดการ — เสียบสาย, format, ใช้งานได้เลย
• ราคาถูกที่สุดเมื่อเทียบกับ NAS/SAN ในระดับเดียวกัน
• Performance สูงเพราะไม่มี network overhead — data ผ่าน SAS/NVMe โดยตรง
• ไม่ต้องมี network infrastructure เพิ่มเติม

ข้อจำกัด:

• เข้าถึงได้จาก Server ที่เชื่อมต่อเท่านั้น — ไม่สามารถ share ให้ Server อื่นได้ง่ายๆ (ต้องทำ file sharing ผ่าน OS)
• ขยาย capacity ยาก — ต้องเพิ่ม disk ที่ตัว enclosure หรือเพิ่ม enclosure ใหม่
• ไม่รองรับ features ขั้นสูง เช่น snapshot, replication, thin provisioning (ขึ้นอยู่กับ RAID controller)
• เป็น single point of failure ถ้าไม่มี redundancy — ถ้า Server ตาย storage ก็เข้าถึงไม่ได้

1.4 เมื่อไหร่ควรใช้ DAS?

DAS เหมาะกับสถานการณ์เหล่านี้:

• Server เดี่ยวที่ต้องการ local storage ความเร็วสูง เช่น database server ที่ต้องการ IOPS สูงสุด
• งบประมาณจำกัด ต้องการ storage เยอะแต่ไม่ต้อง share ข้ามเครื่อง
• ระบบ backup ที่ใช้ tape library หรือ disk-to-disk backup ในเครื่องเดียว
• Workstation สำหรับ video editing ที่ต้องการ bandwidth สูง

ส่วนที่ 2: NAS (Network-Attached Storage) คืออะไร?

2.1 หลักการทำงานของ NAS

NAS หรือ Network-Attached Storage คือ Storage ที่เชื่อมต่อกับ Network (LAN) และให้บริการ File-Level Access ผ่าน protocol เช่น NFS, SMB/CIFS พูดง่ายๆ NAS คือ “เครื่อง Server ที่ออกแบบมาเพื่อแชร์ไฟล์โดยเฉพาะ” ผู้ใช้ทุกคนในเครือข่ายสามารถเข้าถึง file share บน NAS ได้เหมือน mapped drive หรือ mount point

สถาปัตยกรรม NAS:
  ┌──────────┐                    ┌──────────────────────────┐
  │ Server A │ ────┐              │       NAS Device          │
  ├──────────┤     │   Ethernet   │  ┌────────────────────┐  │
  │ Server B │ ────┼──(10GbE)───► │  │ NAS OS (DSM/QTS)   │  │
  ├──────────┤     │   Switch     │  │ NFS / SMB shares    │  │
  │ Client C │ ────┘              │  │ RAID (4-24 disks)   │  │
  └──────────┘                    │  └────────────────────┘  │
                                  └──────────────────────────┘
  * ทุกเครื่องเข้าถึงได้ผ่าน Network
  * Access ระดับ File (File-Level)

2.2 NAS Protocols: NFS vs SMB/CIFS

NAS ให้บริการ file sharing ผ่าน 2 protocol หลัก:

NFS (Network File System):

• พัฒนาโดย Sun Microsystems สำหรับ Unix/Linux เป็นหลัก
• เวอร์ชันปัจจุบัน NFSv4.2 รองรับ ACL, encryption, parallel NFS (pNFS)
• ใช้มากใน Linux Server, VMware ESXi (NFS datastore), container storage
• ข้อดี: overhead ต่ำ, performance ดีกับ Linux workload, ง่ายในการ mount
• ข้อเสีย: จัดการ permission ซับซ้อนกว่า SMB ในบาง scenario, Windows support ไม่ดีเท่า SMB

SMB/CIFS (Server Message Block):

• มาตรฐานของ Microsoft สำหรับ Windows file sharing
• เวอร์ชันปัจจุบัน SMB 3.1.1 รองรับ encryption, multichannel, SMB Direct (RDMA)
• ใช้มากใน Windows environment, office file sharing, home directory
• ข้อดี: integration กับ Active Directory ได้ดีมาก, Windows client ใช้ได้ native
• ข้อเสีย: overhead สูงกว่า NFS เล็กน้อย, chatty protocol (ส่ง packet เยอะ)

เปรียบเทียบ NFS vs SMB:
คุณสมบัติ          | NFS v4.2        | SMB 3.1.1
-------------------|-----------------|------------------
OS หลัก            | Linux/Unix      | Windows
Authentication     | Kerberos/AUTH   | AD/Kerberos
Encryption         | รองรับ           | AES-128-GCM
Multichannel       | pNFS            | SMB Multichannel
Performance        | ดีกว่าเล็กน้อย   | ดี (RDMA support)
Lock Management    | NLM/v4 lease    | Opportunistic Lock
Use Case หลัก      | VMware/Linux    | Windows/Office

2.3 NAS ระดับ Enterprise: Synology vs QNAP vs อื่นๆ

สำหรับองค์กรขนาดกลางถึงใหญ่ มี NAS vendor หลายรายให้เลือก:

Synology (RackStation Series):

• รุ่น RS3621xs+ รองรับ 12 bay, Xeon D-1541, 10GbE x2, สเกลได้ถึง 36 bay
• DSM (DiskStation Manager) ใช้งานง่าย มี UI สวย จัดการผ่าน web browser
• รองรับ Active Directory integration, Snapshot Replication, Hyper Backup
• มี Synology C2 Cloud สำหรับ hybrid cloud backup
• เหมาะกับ SMB ถึง mid-enterprise ที่ต้องการ NAS ใช้งานง่าย

QNAP (Enterprise Series):

• รุ่น TS-h3088XU-RP รองรับ 30 bay (24 HDD + 6 SSD), Xeon W, 25GbE
• QuTS hero ใช้ ZFS file system — รองรับ inline dedup, compression, self-healing
• รองรับ iSCSI target, virtualization (VM ใน NAS), container station
• มี QTier สำหรับ auto-tiering ระหว่าง SSD กับ HDD
• เหมาะกับองค์กรที่ต้องการ NAS มี feature เยอะ ราคาคุ้มค่า

NetApp FAS/AFF Series:

• NAS ระดับ Enterprise เต็มรูปแบบ รองรับ NFS/SMB/iSCSI/FC ในตัวเดียว (Unified Storage)
• ONTAP OS มี feature ขั้นสูง: FlexClone, SnapMirror, MetroCluster
• สเกลได้มหาศาล รองรับ petabyte-scale
• ราคาสูง เหมาะกับ enterprise ขนาดใหญ่

2.4 การติดตั้ง NAS ระดับ Enterprise — Step by Step

ตัวอย่างการ setup NAS Enterprise ด้วย Synology RackStation:

ขั้นตอนที่ 1: วางแผน Hardware

• เลือกรุ่นที่รองรับจำนวน bay ที่ต้องการ (คำนวณ capacity + growth 3-5 ปี)
• เลือก disk: SAS HDD สำหรับ capacity, SATA SSD สำหรับ cache, NVMe สำหรับ high-performance
• เตรียม network: 10GbE ขั้นต่ำสำหรับ enterprise, แนะนำ 25GbE ขึ้นไป
• ใส่ RAM เพิ่มถ้าจะใช้ feature ขั้นสูง (deduplication, VM, container)

ขั้นตอนที่ 2: ติดตั้ง Disk และ RAID

• ใส่ disk ทั้งหมดเข้า bay, เปิดเครื่อง
• เลือก RAID level: SHR-2 (Synology Hybrid RAID 2 disk protection) หรือ RAID 6 สำหรับ enterprise
• สร้าง Storage Pool และ Volume
• เปิด SSD Cache ถ้ามี SSD สำหรับ read/write cache

ขั้นตอนที่ 3: Network Configuration

• ตั้ง Static IP สำหรับ management interface
• ทำ Link Aggregation (LACP) ถ้ามี NIC หลายพอร์ต
• ตั้ง Jumbo Frames (MTU 9000) สำหรับ 10GbE เพื่อเพิ่ม throughput
• ตั้ง DNS, NTP, Domain join

ขั้นตอนที่ 4: File Sharing Setup

• สร้าง Shared Folder ตามโครงสร้างองค์กร
• Join Active Directory domain สำหรับ centralized authentication
• ตั้ง permission ตาม AD group: Read/Write/No Access per folder
• เปิด NFS สำหรับ Linux/VMware, SMB สำหรับ Windows

ขั้นตอนที่ 5: Protection และ Monitoring

• ตั้ง Snapshot schedule: ทุก 1 ชม. สำหรับ data สำคัญ, ทุก 4 ชม. สำหรับ data ทั่วไป
• ตั้ง Hyper Backup ไปยัง remote NAS หรือ Cloud (S3, Azure Blob)
• เปิด SNMP สำหรับ monitoring ด้วย Zabbix/PRTG
• ตั้ง Email/SMS alert สำหรับ disk failure, temperature, fan

ส่วนที่ 3: SAN (Storage Area Network) คืออะไร?

3.1 หลักการทำงานของ SAN

SAN หรือ Storage Area Network คือ Network เฉพาะทาง ที่ออกแบบมาเพื่อเชื่อมต่อ Server กับ Storage โดยเฉพาะ แตกต่างจาก NAS ที่ให้ File-Level Access SAN ให้ Block-Level Access ซึ่งหมายความว่า Server เห็น Storage บน SAN เหมือนกับเป็น “ฮาร์ดดิสก์ภายใน” ของตัวเอง สามารถ format, partition และจัดการได้เหมือน local disk

สถาปัตยกรรม SAN:
  ┌──────────┐    ┌─────────────┐    ┌──────────────────────────┐
  │ Server A │    │             │    │     SAN Storage Array     │
  │ (HBA)    │────│  FC Switch  │────│  ┌───────────────────┐   │
  ├──────────┤    │  (Fabric)   │    │  │ Controller A      │   │
  │ Server B │────│             │────│  │ Controller B (HA) │   │
  │ (HBA)    │    │             │    │  │ Disk Shelves      │   │
  ├──────────┤    └─────────────┘    │  │ (100+ disks)      │   │
  │ Server C │────────────────────── │  └───────────────────┘   │
  │ (iSCSI)  │    IP Network         └──────────────────────────┘
  └──────────┘
  * Block-Level Access (เห็นเป็น disk)
  * Dedicated network สำหรับ storage traffic

3.2 SAN Protocols: Fibre Channel, iSCSI, FCoE

SAN ใช้ protocol หลายแบบในการสื่อสาร:

Fibre Channel (FC):

• Protocol มาตรฐานสำหรับ SAN ที่ใช้มายาวนาน เป็น lossless protocol ที่ออกแบบมาเพื่อ storage โดยเฉพาะ
• ความเร็ว: 8/16/32/64 Gbps (Gen 5 = 32G, Gen 6 = 64G, Gen 7 = 128G กำลังพัฒนา)
• ต้องใช้ hardware เฉพาะ: HBA (Host Bus Adapter) ในฝั่ง Server และ FC Switch (เช่น Brocade, Cisco MDS) สำหรับ Fabric
• ข้อดี: latency ต่ำมาก, lossless, reliable, proven technology
• ข้อเสีย: ราคาแพง (HBA + FC Switch + SFP ราคาสูง), ต้องมีทักษะเฉพาะในการจัดการ

iSCSI (Internet Small Computer Systems Interface):

• Protocol ที่ห่อ SCSI commands ไว้ใน TCP/IP packets ทำให้สามารถใช้ Ethernet Network ธรรมดา สำหรับ SAN ได้
• ใช้ 10GbE/25GbE/100GbE Ethernet — ไม่ต้องซื้อ FC Switch แพงๆ
• มี 2 แบบ: Software iSCSI Initiator (ใช้ CPU ของ Server) และ Hardware iSCSI HBA (offload ให้ NIC ทำ)
• ข้อดี: ราคาถูกกว่า FC มาก, ใช้ Ethernet infrastructure ที่มีอยู่แล้ว, ง่ายในการ setup
• ข้อเสีย: performance อาจต่ำกว่า FC เล็กน้อย (TCP overhead), อาจมี latency สูงกว่าถ้า network congestion

FCoE (Fibre Channel over Ethernet):

• เทคโนโลยีที่รวม FC traffic เข้ากับ Ethernet โดยใช้ Converged Network Adapter (CNA)
• ลดจำนวนสาย cable — ใช้ Ethernet cable เส้นเดียวสำหรับทั้ง LAN และ SAN traffic
• ต้องใช้ DCB (Data Center Bridging) switch ที่รองรับ lossless Ethernet
• ข้อดี: ลด cable, ลด switch, converged infrastructure
• ข้อเสีย: ซับซ้อน, ต้องการ switch ที่รองรับ DCB, ความนิยมลดลงเพราะ NVMe-oF มาแทน

NVMe-oF (NVMe over Fabrics):

• เทคโนโลยีล่าสุดที่ส่ง NVMe commands ผ่าน network fabric (FC, RoCE, TCP)
• ให้ latency ต่ำใกล้เคียง local NVMe SSD — เหมาะกับ workload ที่ต้องการ ultra-low latency
• กำลังเป็นอนาคตของ SAN protocol ในปี 2026+

เปรียบเทียบ SAN Protocols:
Protocol    | Speed         | Infrastructure      | Latency  | Cost
------------|---------------|---------------------|----------|---------
FC 32G      | 32 Gbps       | HBA + FC Switch     | ต่ำมาก    | สูง
FC 64G      | 64 Gbps       | HBA + FC Switch     | ต่ำมาก    | สูงมาก
iSCSI       | 10-100 Gbps   | NIC + Ethernet SW    | ปานกลาง  | ต่ำ
FCoE        | 10-100 Gbps   | CNA + DCB Switch    | ต่ำ       | ปานกลาง
NVMe-oF     | 25-100 Gbps   | SmartNIC + Switch   | ต่ำสุด    | สูง

3.3 SAN Architecture: ส่วนประกอบหลัก

ระบบ SAN ประกอบด้วยส่วนสำคัญหลายส่วน:

1. HBA (Host Bus Adapter):

• การ์ดที่ติดตั้งใน Server สำหรับเชื่อมต่อกับ SAN Fabric
• FC HBA: Broadcom (Emulex), Marvell (QLogic) เป็น vendor หลัก
• ติดตั้ง 2 HBA per server สำหรับ multipath redundancy
• แต่ละ HBA มี WWN (World Wide Name) ซึ่งเป็น unique identifier เหมือน MAC Address

2. FC Switch / SAN Fabric:

• Switch เฉพาะทางสำหรับ Fibre Channel traffic
• Brocade (Broadcom): รุ่น G720, G730 เป็นที่นิยม
• Cisco MDS Series: MDS 9148T, 9396T สำหรับ Cisco shop
• ติดตั้งอย่างน้อย 2 switch (Fabric A + Fabric B) สำหรับ redundancy
• ทำ Zoning เพื่อควบคุมว่า Server ไหนเห็น Storage LUN ไหน

3. Storage Array / Controller:

• หัวใจของระบบ SAN คือ Storage Array ที่มี controller อย่างน้อย 2 ตัว (active-active หรือ active-passive)
• Controller ทำหน้าที่ประมวลผล I/O, จัดการ RAID, cache, snapshot, replication
• Disk Shelves (ตู้ disk) เชื่อมต่อกับ controller ผ่าน SAS backend
• สามารถผสม disk type ได้: SAS HDD, SAS SSD, NVMe SSD

4. LUN (Logical Unit Number):

• LUN คือ “virtual disk” ที่ถูกสร้างจาก physical disks บน Storage Array
• Admin สร้าง LUN ขนาดที่ต้องการ แล้ว map (present) ให้ Server ที่ต้องการ
• Server เห็น LUN เป็น disk ธรรมดา สามารถ format เป็น NTFS, ext4, VMFS ได้
• ตัวอย่าง: สร้าง LUN 500GB map ให้ ESXi host เป็น VMFS datastore

3.4 การ Setup iSCSI SAN — Step by Step

ตัวอย่างการติดตั้ง iSCSI SAN สำหรับ VMware ESXi:

ขั้นตอนที่ 1: เตรียม Network

# สร้าง VLAN เฉพาะสำหรับ iSCSI traffic
VLAN 100: iSCSI Fabric A (10.10.100.0/24)
VLAN 101: iSCSI Fabric B (10.10.101.0/24)

# ตั้ง Switch port สำหรับ iSCSI
- Enable Jumbo Frames (MTU 9000)
- Enable Flow Control (send + receive)
- Disable Spanning Tree Portfast
- แยก traffic iSCSI ออกจาก LAN traffic ปกติ

ขั้นตอนที่ 2: Configure Storage Array (iSCSI Target)

# บน Storage Array (เช่น Dell PowerStore, NetApp)
1. สร้าง iSCSI Portal: กำหนด IP address สำหรับ iSCSI port
   - Portal A1: 10.10.100.10
   - Portal A2: 10.10.100.11
   - Portal B1: 10.10.101.10
   - Portal B2: 10.10.101.11

2. สร้าง Storage Pool จาก physical disks
3. สร้าง LUN จาก Storage Pool:
   - LUN0: 2TB (VMFS Datastore 1)
   - LUN1: 2TB (VMFS Datastore 2)

4. สร้าง Host entry และ map LUN ให้ ESXi hosts
   - ใช้ IQN (iSCSI Qualified Name) ของแต่ละ ESXi host

ขั้นตอนที่ 3: Configure ESXi (iSCSI Initiator)

# บน ESXi host
1. สร้าง VMkernel port สำหรับ iSCSI:
   - vmk1: 10.10.100.20 (VLAN 100) - Fabric A
   - vmk2: 10.10.101.20 (VLAN 101) - Fabric B

2. เปิด Software iSCSI Adapter
3. ตั้ง Network Port Binding: bind vmk1 + vmk2 กับ iSCSI adapter
4. เพิ่ม iSCSI Target Portal: 10.10.100.10, 10.10.101.10
5. Rescan storage adapter — จะเห็น LUN ที่ถูก map มา
6. Format LUN เป็น VMFS 6 datastore

ขั้นตอนที่ 4: Multipath Configuration

# ตั้ง multipath policy สำหรับ LUN
esxcli storage nmp device set --device=naa.xxx --psp=VMW_PSP_RR
# VMW_PSP_RR = Round Robin — กระจาย I/O ไปทุก path เท่าๆ กัน
# VMW_PSP_MRU = Most Recently Used — ใช้ path เดิมจนกว่าจะ fail
# VMW_PSP_FIXED = Fixed — ใช้ path ที่กำหนดเสมอ

ส่วนที่ 4: DAS vs NAS vs SAN — เปรียบเทียบแบบละเอียด

4.1 ตารางเปรียบเทียบครบทุกมิติ

คุณสมบัติ          | DAS              | NAS               | SAN
-------------------|------------------|-------------------|-------------------
Access Level       | Block            | File              | Block
Protocol           | SAS/SATA/NVMe    | NFS/SMB/CIFS      | FC/iSCSI/FCoE
Network             | ไม่ต้อง           | Ethernet (LAN)     | FC/Ethernet (แยก)
Sharing            | 1 Server         | หลาย Clients      | หลาย Servers
Performance        | สูง (direct)     | ปานกลาง-สูง       | สูงมาก
Scalability        | จำกัด            | ปานกลาง            | สูงมาก
Cost               | ต่ำ              | ปานกลาง            | สูง
Complexity         | ง่าย             | ปานกลาง            | ซับซ้อน
Best For           | Single server    | File sharing      | Database, VM
Boot from Storage  | ได้              | ได้ (PXE/iSCSI)    | ได้ (SAN Boot)
Snapshot/Replication | จำกัด          | ได้                | ได้ (advanced)
Typical Use Case   | Local DB, backup | Shared files, NFS  | VMware, Oracle, SAP

4.2 เลือกอะไรดี? Decision Matrix

ใช้ decision matrix นี้ในการเลือก:

• ต้องการ shared file access สำหรับ user ทั่วไป → NAS (SMB share)
• ต้องการ datastore สำหรับ VMware/Hyper-V → SAN (iSCSI/FC) หรือ NAS (NFS)
• ต้องการ high-performance database storage → SAN (FC) หรือ DAS (NVMe)
• งบจำกัด แต่ต้อง share storage → NAS (Synology/QNAP)
• ต้องการ storage สำหรับ 1 server เท่านั้น → DAS
• ต้องการทั้ง Block + File access → Unified Storage (NetApp, Dell) ที่รองรับทั้ง NAS + SAN

ส่วนที่ 5: RAID สำหรับ Enterprise Storage

5.1 RAID Levels ที่ใช้ในองค์กร

RAID (Redundant Array of Independent Disks) คือเทคโนโลยีการรวม disk หลายตัวเข้าด้วยกันเพื่อเพิ่ม performance และ/หรือ protection ในระดับ Enterprise ใช้ RAID levels ดังนี้:

RAID Level | Disks ขั้นต่ำ | Protection      | Usable Capacity    | Performance
-----------|-------------|-----------------|--------------------|--------------
RAID 0     | 2           | ไม่มี            | 100%               | สูงสุด (R+W)
RAID 1     | 2           | 1 disk fail     | 50%                | Read ดี
RAID 5     | 3           | 1 disk fail     | (N-1)/N            | Read ดี, Write ปานกลาง
RAID 6     | 4           | 2 disk fail     | (N-2)/N            | Read ดี, Write ช้ากว่า RAID 5
RAID 10    | 4           | 1 disk/mirror   | 50%                | สูง (R+W)
RAID 50    | 6           | 1 disk/group    | ขึ้นกับ config      | ดี (balanced)
RAID 60    | 8           | 2 disk/group    | ขึ้นกับ config      | ดี (most protected)

RAID 0 (Striping): กระจาย data ไปทุก disk — เร็วที่สุดแต่ไม่มี protection เลย disk ตัวเดียวพังก็สูญหายหมด ใช้เฉพาะงานที่ไม่สำคัญหรือ temp data

RAID 1 (Mirroring): ทำสำเนาข้อมูลเหมือนกันทุก disk เสีย capacity 50% แต่ป้องกันได้ 1 disk fail ใช้สำหรับ OS disk หรือ boot drive

RAID 5 (Striping + Parity): กระจาย data + parity ไปทุก disk ป้องกันได้ 1 disk fail ใช้ capacity ดีกว่า RAID 1 แต่ ไม่แนะนำสำหรับ disk ขนาดใหญ่ (4TB+) เพราะเวลา rebuild นาน และถ้า disk ตัวที่ 2 พังระหว่าง rebuild จะสูญหายหมด

RAID 6 (Double Parity): เหมือน RAID 5 แต่มี parity 2 ชุด ป้องกันได้ 2 disk fail พร้อมกัน แนะนำสำหรับ enterprise ที่ใช้ HDD ขนาดใหญ่

RAID 10 (Mirror + Stripe): รวม RAID 1 กับ RAID 0 — mirror ก่อน แล้ว stripe ทับ ให้ performance สูงสุดพร้อม protection ดี เสีย capacity 50% เหมาะกับ database ที่ต้องการ high IOPS

RAID 50/60: RAID 5 หรือ 6 หลายชุด stripe ข้ามกัน ใช้ใน large storage array ที่มี disk หลายสิบหลายร้อยตัว ให้ balance ระหว่าง protection, capacity และ performance

5.2 Hot Spare และ RAID Rebuild

ใน enterprise storage ต้องมี Hot Spare คือ disk สำรองที่พร้อมแทนที่ disk ที่เสียทันที โดยไม่ต้องเปลี่ยนด้วยมือ:

• Dedicated Hot Spare: กำหนด disk สำรองเฉพาะ RAID group ใดกลุ่มหนึ่ง
• Global Hot Spare: disk สำรองที่ใช้ได้กับทุก RAID group
• แนะนำ: มี hot spare อย่างน้อย 1 ตัวต่อทุก 20 disk หรือ 1 ตัวต่อ RAID group

RAID Rebuild Time: เวลา rebuild ขึ้นอยู่กับขนาด disk, I/O load, RAID level ตัวอย่าง: RAID 6 ด้วย 8TB HDD อาจใช้เวลา rebuild 24-72 ชั่วโมง ระหว่าง rebuild performance จะลดลงอย่างมาก

ส่วนที่ 6: Thin Provisioning, Deduplication และ Compression

6.1 Thin Provisioning คืออะไร?

Thin Provisioning คือเทคนิคที่ทำให้ LUN/Volume ใช้เนื้อที่จริงเท่าที่มีข้อมูลจริงเท่านั้น แม้ว่าจะกำหนดขนาดไว้ใหญ่ก็ตาม:

Thick Provisioning (แบบเดิม):
  LUN ขนาด 1TB → จองเนื้อที่จริง 1TB ทันที
  แม้ใช้จริงแค่ 100GB ก็เปลืองเนื้อที่ 1TB

Thin Provisioning (แบบใหม่):
  LUN ขนาด 1TB → จองเนื้อที่จริงตาม data ที่เขียน
  ใช้จริง 100GB → ใช้เนื้อที่จริงแค่ 100GB
  ประหยัดได้ 900GB!

ข้อควรระวัง: ต้อง monitor capacity อย่างใกล้ชิด ถ้า over-provision มากเกินไปแล้ว disk เต็มจริง จะเกิดปัญหา — LUN ทุกตัวจะ error พร้อมกัน ควรตั้ง alert ที่ 80% usage

6.2 Deduplication คืออะไร?

Deduplication หรือ Dedup คือการ กำจัดข้อมูลซ้ำซ้อน ในระดับ block โดย storage จะเก็บ data block ที่เหมือนกันแค่สำเนาเดียว แล้วใช้ pointer ชี้ไปแทน:

ตัวอย่าง VDI (Virtual Desktop Infrastructure):
  VM 100 เครื่อง ใช้ Windows 11 image เดียวกัน
  ไม่มี Dedup: 100 x 40GB = 4TB
  มี Dedup: OS ส่วนที่เหมือนกัน (~35GB) เก็บแค่ 1 ชุด
  ใช้จริง: 35GB + (100 x 5GB unique) = 535GB
  ประหยัดได้: ~87%!

ประเภทของ Deduplication:

• Inline Dedup: ทำ dedup ก่อนเขียนลง disk — ประหยัดเนื้อที่ทันที แต่ใช้ CPU/RAM มาก
• Post-Process Dedup: เขียนลง disk ก่อน แล้วค่อยทำ dedup ทีหลัง (schedule) — ใช้ resource น้อยกว่า แต่ต้องมีเนื้อที่สำรองสำหรับ data ก่อน dedup

6.3 Compression

Compression คือการ บีบอัดข้อมูล ให้มีขนาดเล็กลง ก่อนเขียนลง disk:

• ใช้ algorithm เช่น LZ4 (เร็ว, compression ratio ปานกลาง) หรือ zlib/gzip (ช้ากว่า, compression ratio ดีกว่า)
• มักใช้ร่วมกับ Dedup: Dedup กำจัดซ้ำซ้อน + Compression บีบอัดส่วนที่เหลือ
• ผล: ประหยัดเนื้อที่ได้ 2:1 ถึง 5:1 ขึ้นอยู่กับ data type
• ข้อควรระวัง: data ที่ compress ได้ไม่ดี เช่น video, image, encrypted data จะไม่ได้ประโยชน์ และยังเพิ่ม CPU overhead

ส่วนที่ 7: Snapshots และ Replication

7.1 Storage Snapshot คืออะไร?

Snapshot คือ “ภาพถ่าย” ของ data ณ จุดเวลาหนึ่ง ที่ทำได้รวดเร็วมาก (มักไม่ถึงวินาที) โดยไม่ต้อง copy data ทั้งหมด:

• Snapshot ใช้ Copy-on-Write (CoW) หรือ Redirect-on-Write (RoW) technique
• CoW: เมื่อมีการเปลี่ยน data block สำเนา block เก่าจะถูก copy ไปยัง snapshot area ก่อน แล้วเขียน block ใหม่ทับ
• RoW: เมื่อมีการเปลี่ยน data block เขียน block ใหม่ไปที่ใหม่ แล้ว update pointer Snapshot ชี้ไปยัง block เก่า

Use Cases ของ Snapshot:

• Rapid Recovery: กู้ไฟล์ที่ลบหรือ corrupt ได้ทันที โดย restore จาก snapshot
• ก่อนทำ maintenance: ถ่าย snapshot ก่อน patch OS, upgrade application
• Dev/Test: clone snapshot เพื่อสร้าง environment ทดสอบ โดยไม่กระทบ production
• Ransomware protection: ถ้าโดน ransomware สามารถ rollback ไป snapshot ก่อนติดเชื้อ

Best Practice สำหรับ Snapshot:

• ตั้ง schedule ถ่าย snapshot ทุก 1-4 ชั่วโมงสำหรับ data สำคัญ
• กำหนด retention policy: เก็บกี่ snapshot, กี่วัน
• Snapshot ไม่ใช่ backup ที่แท้จริง — ถ้า storage array พัง snapshot ก็หายด้วย
• อย่าเก็บ snapshot มากเกินไป — snapshot เยอะจะทำให้ performance ลดลง

7.2 Storage Replication

Replication คือการ copy data ไปยัง storage อีกตัวหนึ่ง เพื่อ disaster recovery:

Synchronous Replication:

• ทุก write จะถูก copy ไปยัง remote storage ก่อนที่จะ acknowledge กลับไปยัง application
• RPO = 0 (ไม่สูญเสียข้อมูลเลย) แต่ latency สูงขึ้น
• เหมาะกับ site ที่อยู่ใกล้กัน (ไม่เกิน 100 km) เพราะ latency ของ network จะกระทบ performance
• ใช้สำหรับ mission-critical application เช่น banking, trading

Asynchronous Replication:

• Write acknowledge ทันที แล้ว copy ไปยัง remote storage ทีหลัง (ทุก 5-60 นาที)
• RPO = 5-60 นาที (อาจสูญเสียข้อมูลได้บ้าง)
• เหมาะกับ site ที่อยู่ไกล (ข้ามประเทศ, ข้ามทวีป)
• ไม่กระทบ performance ของ production

ส่วนที่ 8: Storage Tiering — การจัดชั้นเก็บข้อมูล

8.1 แนวคิด Storage Tiering

ไม่ใช่ data ทุกชนิดต้องการ performance เท่ากัน Storage Tiering จัดกลุ่ม data ตามความถี่การใช้งานและจัดเก็บใน media ที่เหมาะสม:

Tier 0 — Ultra-High Performance (NVMe SSD)
  ├── Database index, transaction logs
  ├── Real-time analytics
  └── Cost: ~$200/TB/month

Tier 1 — High Performance (SAS SSD)
  ├── Active databases, ERP data
  ├── Virtual machine storage
  └── Cost: ~$100/TB/month

Tier 2 — Capacity (SAS/NL-SAS HDD)
  ├── File shares, email archives
  ├── Backup data
  └── Cost: ~$30/TB/month

Tier 3 — Archive (SATA HDD / Tape / Cloud)
  ├── Compliance data, old records
  ├── Long-term backup
  └── Cost: ~$5/TB/month

Auto-Tiering: Modern storage array (เช่น Dell PowerStore, HPE Primera, Pure Storage) สามารถทำ auto-tiering ได้ โดย ย้าย data block ที่ใช้บ่อยไปยัง SSD tier อัตโนมัติ และย้าย data ที่ไม่ค่อยใช้ลง HDD tier ทำให้ได้ performance ของ SSD ในราคาของ HDD

ส่วนที่ 9: Storage Vendors — เปรียบเทียบ Enterprise Storage ยี่ห้อหลัก

9.1 Dell Technologies (Dell EMC)

• PowerStore: Midrange all-flash array รองรับ block + file, NVMe-oF, built-in dedup/compression
• PowerScale (Isilon): Scale-out NAS สำหรับ unstructured data ขนาดใหญ่ (media, healthcare, AI)
• PowerMax: High-end enterprise SAN สำหรับ mission-critical (99.9999% uptime)
• Unity XT: Unified storage (block + file) สำหรับ SMB ราคาคุ้มค่า

9.2 NetApp

• AFF A-Series: All-flash array ที่รัน ONTAP OS — unified NAS + SAN ในตัวเดียว
• FAS Series: Hybrid (SSD + HDD) สำหรับ workload ที่ต้องการ capacity
• ONTAP: OS ที่ทรงพลังที่สุดในวงการ — SnapMirror, FlexClone, MetroCluster, FabricPool (tier ไป cloud)
• Cloud Volumes ONTAP: ใช้ ONTAP บน AWS/Azure/GCP ได้

9.3 HPE (Hewlett Packard Enterprise)

• Alletra 9000 (เดิมคือ Primera): Mission-critical all-flash พร้อม 100% availability guarantee
• Alletra 6000 (เดิมคือ Nimble): Midrange storage ที่มี AI-driven predictive analytics (InfoSight)
• GreenLake: Storage as a Service — จ่ายตามการใช้งานจริง ไม่ต้องซื้อ hardware

9.4 Pure Storage

• FlashArray//X: All-NVMe flash สำหรับ block storage — Evergreen subscription ไม่ต้อง forklift upgrade
• FlashArray//C: Capacity-optimized flash สำหรับ workload ที่ต้องการ capacity มากกว่า performance
• FlashBlade: Unified fast file and object storage สำหรับ AI/ML, analytics, DevOps
• จุดเด่น: dedup/compression ratio ดีมาก (average 5:1), subscription model, ไม่ต้อง RAID rebuild

9.5 เปรียบเทียบ Vendor

Vendor        | จุดแข็ง              | จุดอ่อน              | เหมาะกับ
--------------|---------------------|---------------------|------------------
Dell EMC      | Portfolio กว้าง       | ซับซ้อน, หลายผลิตภัณฑ์  | Enterprise ทุกขนาด
NetApp        | ONTAP, Unified       | ราคาค่อนข้างสูง       | Hybrid/Multi-cloud
HPE           | InfoSight AI         | Transition จาก Nimble  | Midrange-Enterprise
Pure Storage  | Simplicity, Evergreen| ไม่มี HDD option      | All-flash, Modern

ส่วนที่ 10: Software-Defined Storage (SDS)

10.1 SDS คืออะไร?

Software-Defined Storage (SDS) คือแนวทางที่ แยก software ออกจาก hardware ทำให้สามารถใช้ hardware commodity (server ธรรมดา + disk ธรรมดา) แล้วรัน storage software ข้างบนเพื่อให้ได้ features ระดับ enterprise:

Ceph:

• Open-source distributed storage ที่รองรับทั้ง block (RBD), file (CephFS) และ object (RADOS Gateway)
• Scale-out ได้ไม่จำกัด โดยเพิ่ม node/disk เข้าไปใน cluster
• ใช้เป็น storage backend สำหรับ OpenStack, Kubernetes (CSI driver), Proxmox VE
• Self-healing: ถ้า disk/node พัง data จะ re-replicate อัตโนมัติ
• ฟรี (open-source) แต่ต้องมีทีมที่มี expertise ในการ manage

GlusterFS:

• Open-source distributed file system โดย Red Hat
• เน้น file storage (POSIX-compliant) มากกว่า block
• ง่ายกว่า Ceph ในการ setup แต่ feature น้อยกว่า
• เหมาะกับ NAS replacement, media storage, archive

VMware vSAN:

• Hyper-Converged Storage ที่รวม compute + storage ไว้ใน ESXi host เดียวกัน
• ใช้ local disk ใน ESXi host สร้าง shared datastore โดยไม่ต้อง external SAN/NAS
• จัดการผ่าน vCenter — ง่ายสำหรับ VMware shop
• รองรับ all-flash และ hybrid configuration
• ราคา license สูง

MinIO:

• Open-source object storage ที่ compatible กับ Amazon S3 API
• เหมาะกับ cloud-native application, backup target, data lake
• Performance สูงมาก — อ้างว่าเร็วกว่า S3 จริง

ส่วนที่ 11: Cloud Storage Integration

11.1 Hybrid Cloud Storage

ในปี 2026 องค์กรส่วนใหญ่ใช้ Hybrid Cloud Storage คือผสมผสาน on-premises storage กับ cloud storage:

• Cloud Tiering: ย้าย data เก่า/ไม่ค่อยใช้ขึ้น cloud อัตโนมัติ (เช่น NetApp FabricPool ย้ายไป S3/Azure Blob)
• Cloud Backup: backup data จาก on-premises ไปเก็บบน cloud (Veeam Cloud Connect, Commvault Cloud)
• Cloud DR: replicate data ไป cloud เพื่อ disaster recovery (Azure Site Recovery, AWS DRS)
• Cloud Bursting: ย้าย workload ไป cloud ในช่วง peak load

11.2 Cloud Storage Services

Service               | Type    | Use Case
----------------------|---------|---------------------------
AWS S3                | Object  | General object storage
AWS EBS               | Block   | EC2 instance storage
AWS EFS               | File    | Shared file system (NFS)
AWS FSx               | File    | Windows file server / Lustre
Azure Blob Storage    | Object  | Unstructured data
Azure Files           | File    | SMB/NFS cloud file share
Azure Managed Disks   | Block   | VM disk storage
Google Cloud Storage  | Object  | Object storage
Google Filestore      | File    | NFS file share

ส่วนที่ 12: Capacity Planning — วางแผนพื้นที่จัดเก็บ

12.1 ขั้นตอน Capacity Planning

การวางแผน capacity สำหรับ enterprise storage ต้องพิจารณาหลายปัจจัย:

1. สำรวจ Workload ปัจจุบัน:

• ข้อมูลปัจจุบันมีกี่ TB? แบ่งเป็น structured (database) และ unstructured (file) อย่างละเท่าไหร่?
• Growth rate ต่อปีเป็นเท่าไหร่? (เฉลี่ยองค์กรทั่วไปโต 20-40% ต่อปี)
• Performance requirement: IOPS, throughput, latency ที่ต้องการ

2. คำนวณ Raw vs Usable Capacity:

ตัวอย่าง: ต้องการ usable 50TB ใช้ RAID 6 (14+2)
  Disks: 16 x 4TB SAS HDD
  Raw Capacity: 16 x 4TB = 64TB
  RAID 6 Usable: 14 x 4TB = 56TB (87.5%)
  Hot Spare: 1 x 4TB = 4TB
  Usable after spare: 52TB
  หลัง format/overhead (~5%): ~49.4TB

  ถ้าใช้ Thin Provisioning + Dedup + Compression (3:1 ratio):
  Effective Capacity: ~148TB!

  แต่ต้องระวัง: อย่า over-commit เกิน 200% สำหรับ production

3. วางแผน 3-5 ปีข้างหน้า:

• คำนวณ growth: ถ้าปัจจุบัน 50TB, โต 30%/ปี → ปีที่ 3 = 50 x 1.3^3 = 110TB, ปีที่ 5 = 186TB
• ซื้อ storage ที่สเกลได้: เริ่มต้นด้วย capacity ที่ต้องการ + 20% buffer แล้วเพิ่ม shelf/disk ภายหลัง
• พิจารณา technology refresh: SSD ราคาลดลงทุกปี อาจ upgrade จาก HDD เป็น SSD ในอนาคต

12.2 Monitoring และ Alerts

หลังติดตั้ง storage แล้ว ต้อง monitor อย่างต่อเนื่อง:

• Capacity monitoring: ตั้ง alert เมื่อ usage ถึง 70% (warning) และ 85% (critical)
• Performance monitoring: IOPS, latency, throughput — ตรวจสอบว่า SLA ยังเป็นไปตามที่กำหนด
• Health monitoring: disk errors, controller status, temperature, fan speed
• Tools: ใช้ vendor management software (Dell EMC CloudIQ, NetApp Active IQ, Pure1) ร่วมกับ SNMP/Zabbix/Grafana

ส่วนที่ 13: Best Practices สำหรับ Enterprise Storage 2026

13.1 Design Best Practices

• แยก storage network ออกจาก data network เสมอ (ใช้ VLAN แยก หรือ physical network แยก)
• ใช้ multipath I/O (MPIO) ทุกกรณี — อย่างน้อย 2 path สำหรับ redundancy
• ใช้ RAID 6 หรือ RAID 10 สำหรับ enterprise ไม่ใช้ RAID 5 กับ disk ขนาดใหญ่ (4TB+)
• วาง hot spare อย่างน้อย 1 ตัวต่อ RAID group
• ใช้ dual controller (active-active) สำหรับ SAN/NAS ที่สำคัญ
• ทำ firmware upgrade ทุกไตรมาส ตาม vendor recommendation

13.2 Security Best Practices

• เปิด Encryption at Rest (self-encrypting drives หรือ software encryption)
• เปิด Encryption in Transit (IPsec สำหรับ iSCSI, TLS สำหรับ management)
• ใช้ RBAC (Role-Based Access Control) สำหรับ storage management
• ทำ immutable snapshot สำหรับ ransomware protection
• แยก management network ของ storage ออกจาก user network
• เปิด audit log สำหรับทุก admin operation

13.3 Performance Tuning

• ใช้ Jumbo Frames (MTU 9000) สำหรับ iSCSI/NFS
• ใช้ Round Robin multipath สำหรับ active-active controller
• ใช้ SSD cache/tier สำหรับ hot data
• หลีกเลี่ยงการ mix workload ที่ performance requirement ต่างกันมากใน storage pool เดียวกัน
• Monitor latency — ถ้า latency > 10ms ต้องตรวจสอบสาเหตุ (disk busy, network congestion, controller bottleneck)

สรุป: Enterprise Storage ในปี 2026

ระบบ Storage เป็นหัวใจของ IT Infrastructure ขององค์กร การเลือกสถาปัตยกรรมที่เหมาะสม (DAS, NAS หรือ SAN) ขึ้นอยู่กับ workload, budget และ scale ที่ต้องการ สิ่งสำคัญที่สุดคือการ วางแผน capacity อย่างรอบคอบ ออกแบบ redundancy ที่เพียงพอ และ monitor อย่างต่อเนื่อง

เทรนด์สำคัญในปี 2026 คือ:

• All-Flash กลายเป็นมาตรฐาน: ราคา SSD ลดลงจนคุ้มค่ากว่า HDD สำหรับ Tier 1-2 workload
• NVMe-oF: เป็นอนาคตของ SAN protocol ด้วย latency ที่ต่ำกว่า FC
• Hybrid Cloud Storage: ทุกองค์กรใช้ cloud storage ร่วมกับ on-premises
• Software-Defined Storage: Ceph, vSAN ลด dependency กับ proprietary hardware
• Storage as Code: จัดการ storage ด้วย API, Terraform, Ansible แทนการ click GUI

สำหรับคนที่อยากเรียนรู้เพิ่มเติม แนะนำให้ลอง setup iSCSI SAN ใน lab (ใช้ Windows Server iSCSI Target + ESXi) หรือลอง deploy Ceph cluster ด้วย VM 3 ตัว จะได้เข้าใจ concept ทั้ง block, file และ object storage อย่างลึกซึ้ง