/static/codemoomoo2.png

12. Distributed and Network File System (sshfs, NFS, GlusterFS)

บทความนี้กล่าวถึงระบบไฟล์แบบเครือข่ายและแบบกระจาย ตั้งแต่แนวคิดพื้นฐาน ทฤษฎี CAP โมเดลความสอดคล้อง ไปจนถึงการใช้งานจริงของ SSHFS, NFS, Samba (SMB/CIFS), GlusterFS รวมถึงทางเลือกสมัยใหม่อย่าง CephFS, MinIO, JuiceFS เพื่อเลือกใช้ให้เหมาะกับ Use Case ทั้ง Home Lab, SMB, Enterprise และ HPC

12.1 แนวคิดของ Distributed และ Network File System

ระบบไฟล์ (File System) ในยุคที่ข้อมูลกระจายอยู่ทั่วโลก ไม่ได้จำกัดอยู่แค่ดิสก์ของเครื่องเดียวอีกต่อไป แต่กลายเป็นโครงสร้างพื้นฐาน (Infrastructure) ที่เชื่อมโยงเครื่องหลายเครื่องเข้าด้วยกัน เพื่อให้สามารถแชร์ข้อมูล สร้างความพร้อมใช้งานสูง (High Availability) และรองรับการขยายขนาด (Scalability) ได้อย่างยืดหยุ่น

12.1.1 Local FS vs Network FS vs Distributed FS vs Object Storage

Local File System คือระบบไฟล์ที่อยู่บนดิสก์ของเครื่องเดียว เช่น ext4, XFS, Btrfs, NTFS, APFS โดยเคอร์เนล (Kernel) จะจัดการ Metadata, Block Allocation และ Cache ทั้งหมดบนเครื่องนั้น ๆ ข้อดีคือมีประสิทธิภาพสูง latency ต่ำ แต่ข้อเสียคือไม่สามารถแชร์กับเครื่องอื่นได้โดยตรง

Network File System (NFS) คือระบบที่อนุญาตให้เครื่อง Client เข้าถึงไฟล์บน Server ผ่านเครือข่าย โดยมองเห็นเหมือนเป็นไดเรกทอรีในเครื่องตนเอง ตัวอย่าง ได้แก่ NFS, SMB/CIFS, AFP, SSHFS โดย Server มีดิสก์จริงเพียงชุดเดียว Client หลายเครื่องอ่าน-เขียนผ่านโปรโตคอลเครือข่าย

Distributed File System (DFS) คือระบบที่ข้อมูลถูกกระจาย (Distributed) อยู่บนหลายเครื่องในรูปแบบ Cluster โดยผู้ใช้มองเห็นเป็น Namespace เดียวกัน ตัวอย่างเช่น GlusterFS, CephFS, HDFS, MooseFS, BeeGFS, Lustre การกระจายนี้ช่วยให้รองรับการขยายตัวแบบ Horizontal Scaling และทนต่อความล้มเหลวของโหนด (Fault Tolerance) ได้

Object Storage เป็นรูปแบบที่ไม่ใช้โครงสร้างไดเรกทอรีแบบดั้งเดิม แต่จัดเก็บข้อมูลเป็น "Object" พร้อม Metadata และเข้าถึงผ่าน HTTP REST API เช่น Amazon S3, MinIO, Ceph RADOS Gateway, SeaweedFS เหมาะสำหรับข้อมูลขนาดใหญ่ที่ไม่ต้องการ POSIX semantics

ตารางเปรียบเทียบเชิงสรุป:

คุณสมบัติ	Local FS	Network FS	Distributed FS	Object Storage
POSIX Compliance	เต็มรูปแบบ	เกือบเต็มรูปแบบ	บางส่วน-เต็มรูปแบบ	ไม่ใช่
Latency	ต่ำมาก (μs)	ปานกลาง (ms)	ปานกลาง-สูง	สูง (10-100ms)
Scalability	จำกัดที่เครื่องเดียว	จำกัดที่ Server	สูง (Horizontal)	สูงมาก (Petabyte+)
Fault Tolerance	RAID เท่านั้น	Single point of failure	สูง (Replication/Erasure Code)	สูงมาก
Protocol	เคอร์เนลโดยตรง	NFS, SMB, SSHFS	gluster, ceph, hdfs	HTTP/S3
Use Case	Workstation, Server	Office sharing	HPC, Big Data	Cloud-native, Backup

12.1.2 POSIX Semantics

POSIX (Portable Operating System Interface) คือมาตรฐาน IEEE ที่กำหนดพฤติกรรมของระบบปฏิบัติการแบบ Unix รวมถึงการทำงานของระบบไฟล์ ซึ่งมีคุณสมบัติสำคัญดังนี้:

Atomic Rename: การเปลี่ยนชื่อไฟล์ต้องเป็น Atomic Operation ไม่มีสถานะกลาง
File Locking: รองรับ fcntl(), flock() สำหรับล็อกไฟล์ทั้งแบบ Advisory และ Mandatory
Hard Link และ Symbolic Link: รองรับการสร้างลิงก์หลายรูปแบบ
Permission Model: ใช้รูปแบบ Owner/Group/Others พร้อม rwx และ Special Permission (SUID, SGID, Sticky)
Read-after-Write Consistency: เมื่อเขียนเสร็จ การอ่านครั้งถัดไปต้องเห็นข้อมูลใหม่ทันที
Close-to-Open Consistency: เมื่อ Client A ปิดไฟล์ Client B ที่เปิดไฟล์หลังจากนั้นต้องเห็นข้อมูลล่าสุด

ระบบไฟล์เครือข่ายแต่ละชนิดมีระดับการสนับสนุน POSIX แตกต่างกัน เช่น NFSv3 มี Cache ที่อาจทำให้เกิด Stale Data ส่วน NFSv4 ปรับปรุงด้วย Delegation และ State-ful Protocol ขณะที่ Object Storage ส่วนใหญ่ไม่สนับสนุน POSIX เลย

12.1.3 CAP Theorem (Consistency, Availability, Partition Tolerance)

CAP Theorem หรือทฤษฎีบทของ Brewer (Eric Brewer, 2000) กล่าวว่า ระบบกระจาย (Distributed System) ไม่สามารถรับประกันคุณสมบัติทั้ง 3 ข้อพร้อมกันได้ในกรณีที่เกิด Network Partition

flowchart TB
    CAP(["CAP Theorem
เลือกได้แค่ 2 ใน 3"])
    C["Consistency
ความสอดคล้อง
ทุก Node เห็นข้อมูลเดียวกัน"]
    A["Availability
ความพร้อมใช้งาน
ทุก Request ได้รับการตอบ"]
    P["Partition Tolerance
ทนต่อการแยกเครือข่าย
ทำงานต่อได้แม้เน็ตขาด"]

    CAP --> C
    CAP --> A
    CAP --> P

    CP["CP System
HBase, MongoDB
CephFS, GlusterFS"]
    AP["AP System
Cassandra, DynamoDB
CouchDB, S3"]
    CA["CA System
Single-node DB
(ไม่ทนต่อ Partition)"]

    C --- CP
    P --- CP
    A --- AP
    P --- AP
    C --- CA
    A --- CA

    style CAP fill:#d79921,stroke:#fabd2f,color:#1d2021
    style C fill:#458588,stroke:#83a598,color:#fbf1c7
    style A fill:#98971a,stroke:#b8bb26,color:#fbf1c7
    style P fill:#cc241d,stroke:#fb4934,color:#fbf1c7
    style CP fill:#504945,stroke:#7c6f64,color:#ebdbb2
    style AP fill:#504945,stroke:#7c6f64,color:#ebdbb2
    style CA fill:#504945,stroke:#7c6f64,color:#ebdbb2

ในทางคณิตศาสตร์ สามารถแสดงเงื่อนไขนี้ได้ดังนี้:

\forall S \in DistributedSystem : S \subset⃒ {C, A, P}

โดยที่:

S หมายถึง ระบบกระจายใด ๆ
C (Consistency) ทุกโหนดอ่านได้ข้อมูลล่าสุดเหมือนกัน
A (Availability) ทุก Request ที่ส่งไปต้องได้รับการตอบกลับ (อาจไม่ใช่ข้อมูลล่าสุด)
P (Partition Tolerance) ระบบยังทำงานได้แม้เครือข่ายระหว่างโหนดแบ่งกัน

12.1.4 Consistency Model: Strong, Eventual, Causal

Strong Consistency หรือ Linearizability หมายถึง ทุก Operation ดูเหมือนทำงานทีละตัวตามลำดับเวลาจริง (Real-time order) ตัวอย่างเช่น CephFS, NFSv4 with Locking, HDFS เหมาะกับงานที่ต้องการความถูกต้องสูง เช่น Database, Banking

Eventual Consistency หมายถึง หลังจากหยุดเขียนข้อมูลในระยะเวลาหนึ่ง ทุกโหนดจะค่อย ๆ Synchronize จนเหมือนกันในที่สุด ตัวอย่างเช่น Amazon S3 (เดิม), Cassandra, DNS เหมาะกับงานที่ทนต่อความล่าช้าได้ เช่น Social Media Feed

Causal Consistency เป็นจุดกึ่งกลาง โดยจะรับประกันลำดับของ Operation ที่มีความสัมพันธ์เชิงเหตุผล (Causal Relationship) ตัวอย่างเช่น ถ้า A เขียนแล้ว B อ่านแล้วเขียน Operation ของ B จะถูกเห็นในลำดับที่ถูกต้องเสมอ

ในทางคณิตศาสตร์ สามารถจัดอันดับความเข้มงวดได้:

Linearizability \supseteq Sequential \supseteq Causal \supseteq Eventual

โดยที่ความสัมพันธ์ ⊇ หมายถึง "เข้มงวดกว่า" หรือ "รับประกันมากกว่า"

12.1.5 ประโยชน์: Shared Storage, Scalability, High Availability, DR

ระบบไฟล์แบบเครือข่ายและแบบกระจายมีประโยชน์หลัก 4 ด้าน:

Shared Storage ข้อมูลที่เข้าถึงได้จากหลายเครื่อง ทำให้ทีมงานทำงานร่วมกันได้ ลดการ Copy ข้อมูลซ้ำซ้อน เช่น โฟลเดอร์ Home directory ของผู้ใช้ในองค์กรที่ Mount มาจาก NFS Server กลาง
Scalability ขยายขนาดได้แบบ Horizontal โดยเพิ่ม Node เข้าไปใน Cluster เช่น GlusterFS สามารถเพิ่ม Brick เพื่อเพิ่มความจุและประสิทธิภาพได้แบบ Linear Scaling
High Availability (HA) ทนต่อการล้มเหลวของฮาร์ดแวร์ ผ่านการ Replicate ข้อมูล หรือใช้ Erasure Coding ตัวอย่าง CephFS ที่มี replication factor = 3 จะอยู่รอดได้แม้ Node ล้มเหลว 2 Node พร้อมกัน
Disaster Recovery (DR) การสำรองข้อมูลข้าม Site ผ่าน Geo-replication เช่น GlusterFS Geo-Replication ที่จำลองข้อมูลจาก Data Center หลักไปยัง DR Site ด้วยกลไก rsync แบบ Asynchronous

12.2 SSHFS (SSH File System)

SSHFS คือเครื่องมือที่ Mount ไดเรกทอรีจากเครื่องระยะไกลผ่านโปรโตคอล SSH โดยใช้กลไก SFTP เป็นช่องทางการสื่อสารและถ่ายโอนไฟล์ ทำให้ผู้ใช้สามารถทำงานกับไฟล์บน Server ระยะไกลได้เหมือนเป็นไดเรกทอรีในเครื่องของตนเอง

12.2.1 สถาปัตยกรรม FUSE-based

FUSE (Filesystem in Userspace) เป็นโมดูลของ Linux Kernel ที่อนุญาตให้พัฒนา File System ใน User Space แทนที่จะต้องเขียนเป็น Kernel Module ทำให้การพัฒนาง่ายขึ้นและปลอดภัยกว่า เนื่องจากบั๊กใน FUSE Driver ไม่ทำให้เคอร์เนลทั้งระบบล่ม

flowchart TB
    subgraph Client["เครื่อง Client"]
        APP["Application
(เช่น cat, vim, ls)"]
        VFS["VFS Layer
(Virtual File System)"]
        FUSE["FUSE Kernel Module"]
        SSHFS["sshfs
(User-space Daemon)"]
        SSH_C["SSH Client"]
    end

    subgraph Server["เครื่อง Server"]
        SSHD["sshd
(SSH Daemon)"]
        SFTP["SFTP Server
Subsystem"]
        FS["Local FS
(ext4/xfs)"]
    end

    APP -->|"open/read/write"| VFS
    VFS --> FUSE
    FUSE -->|"upcall"| SSHFS
    SSHFS --> SSH_C
    SSH_C -->|"encrypted channel
port 22"| SSHD
    SSHD --> SFTP
    SFTP --> FS

    style APP fill:#458588,stroke:#83a598,color:#fbf1c7
    style FUSE fill:#d79921,stroke:#fabd2f,color:#1d2021
    style SSHFS fill:#cc241d,stroke:#fb4934,color:#fbf1c7
    style SSHD fill:#98971a,stroke:#b8bb26,color:#fbf1c7
    style SFTP fill:#689d6a,stroke:#8ec07c,color:#fbf1c7

ลำดับการทำงาน (Workflow) ของ SSHFS เมื่อแอปพลิเคชันเรียก System Call เช่น open(), read(), write():

Application เรียก System Call ผ่าน VFS Layer
VFS ส่งคำขอไปยัง FUSE Kernel Module เพราะจุดเชื่อมต่อ (Mount Point) ถูกลงทะเบียนเป็น FUSE
FUSE ส่ง Up-call ไปยัง sshfs daemon ใน User Space
sshfs แปลงคำขอเป็น SFTP Protocol Message แล้วส่งผ่าน SSH ไปยัง Server
sshd บน Server เรียก SFTP Subsystem เพื่อทำงานบน Local Filesystem
ผลลัพธ์ส่งกลับมาตามเส้นทางเดิมในรูปแบบที่เข้ารหัสตลอด

12.2.2 การติดตั้ง sshfs และ Dependency (fuse)

การติดตั้งแตกต่างกันตาม Distribution ดังนี้:

# Debian / Ubuntu
sudo apt update
sudo apt install -y sshfs fuse3

# Fedora / RHEL / Rocky / AlmaLinux
sudo dnf install -y fuse-sshfs

# Arch / Manjaro / EndeavourOS
sudo pacman -S sshfs fuse3

# openSUSE
sudo zypper install sshfs fuse

# Void Linux
sudo xbps-install -S sshfs fuse

# Alpine Linux
sudo apk add sshfs fuse3

# macOS (ต้องใช้ macFUSE จาก https://osxfuse.github.io)
brew install --cask macfuse
brew install gromgit/fuse/sshfs-mac

ตรวจสอบว่าติดตั้งสำเร็จและ FUSE Module โหลดเรียบร้อย:

# ตรวจสอบเวอร์ชัน sshfs
sshfs --version

# ตรวจสอบว่าเคอร์เนลโหลด FUSE module
lsmod | grep fuse

# หากยังไม่โหลด ให้โหลดด้วยคำสั่งนี้
sudo modprobe fuse

# ตรวจสอบสิทธิ์ของ /dev/fuse (ต้องอ่าน-เขียนได้โดยผู้ใช้)
ls -l /dev/fuse
# crw-rw-rw- 1 root root 10, 229 ...

12.2.3 การ mount: `sshfs user@host:/remote /local`

รูปแบบคำสั่งพื้นฐาน:

# 1. สร้างจุดเชื่อมต่อ (Mount Point) บนเครื่อง Client
mkdir -p ~/mnt/remote-server

# 2. Mount โฟลเดอร์ /home/moo บน Server มายัง ~/mnt/remote-server
sshfs moo@192.168.1.100:/home/moo ~/mnt/remote-server

# 3. ระบบจะถาม Password (หรือใช้ SSH Key ก็ได้)
# moo@192.168.1.100's password: ********

# 4. ตรวจสอบว่า Mount สำเร็จ
df -h | grep sshfs
mount | grep fuse.sshfs

# 5. ใช้งานเหมือนไดเรกทอรีปกติ
ls ~/mnt/remote-server
echo "Hello from RMUTSV" > ~/mnt/remote-server/greetings.txt

ตัวอย่างการใช้ SSH Key เพื่อไม่ต้องป้อน Password:

# สร้าง Key Pair (หากยังไม่มี)
ssh-keygen -t ed25519 -C "moo@rmutsv"

# คัดลอก Public Key ไปยัง Server
ssh-copy-id moo@192.168.1.100

# Mount โดยระบุ Key เฉพาะ
sshfs -o IdentityFile=~/.ssh/id_ed25519 \
      moo@192.168.1.100:/home/moo \
      ~/mnt/remote-server

12.2.4 Option สำคัญ: reconnect, ServerAliveInterval, allow_other, uid, gid, cache

ตัวเลือก (Option) ที่ใช้บ่อยและสำคัญในการใช้งานจริง:

Option	คำอธิบาย	ค่าที่แนะนำ
`reconnect`	เชื่อมต่อใหม่อัตโนมัติเมื่อขาดการเชื่อมต่อ	ใส่เสมอ
`ServerAliveInterval=15`	ส่ง keep-alive ทุก 15 วินาที	15-30
`ServerAliveCountMax=3`	ตัดการเชื่อมต่อหลังไม่ตอบ 3 ครั้ง	3
`allow_other`	อนุญาตให้ผู้ใช้คนอื่นเข้าถึง mount	ตามต้องการ
`default_permissions`	ใช้ Kernel ตรวจสอบสิทธิ์	ใช้คู่กับ allow_other
`uid=1000,gid=1000`	บังคับ UID/GID ของไฟล์ที่ mount	ตามผู้ใช้จริง
`cache=yes`	เปิด attribute cache (เร็วขึ้น)	yes ในงานทั่วไป
`kernel_cache`	ใช้ kernel cache	เปิดเมื่อข้อมูลเสถียร
`compression=yes`	บีบอัดข้อมูลก่อนส่ง	yes ในเครือข่ายช้า
`transform_symlinks`	แปลง absolute symlink	ใช้กับ /etc/, /usr/
`IdentityFile=~/.ssh/key`	ระบุ private key	ตามที่ต้องการ
`Port=2222`	ระบุพอร์ต SSH ที่ไม่ใช่ 22	ตามที่ Server ใช้
`idmap=user`	แมป UID ของ Server เป็นของ Client	user หรือ none

ตัวอย่างคำสั่งครบสำหรับใช้งานจริง (Production-ready):

# Mount แบบครบเครื่อง: reconnect, keep-alive, compression, cache
sshfs moo@server.rmutsv.ac.th:/data/research \
      ~/mnt/research \
      -o reconnect \
      -o ServerAliveInterval=15 \
      -o ServerAliveCountMax=3 \
      -o compression=yes \
      -o cache=yes \
      -o kernel_cache \
      -o allow_other \
      -o default_permissions \
      -o uid=$(id -u) \
      -o gid=$(id -g) \
      -o IdentityFile=~/.ssh/id_ed25519 \
      -o Port=2222

# กรณีต้องการ Mount ตอนบูตผ่าน /etc/fstab
# เพิ่มบรรทัดนี้ในไฟล์ /etc/fstab
moo@server.rmutsv.ac.th:/data/research /home/moo/mnt/research fuse.sshfs \
  noauto,x-systemd.automount,_netdev,reconnect,identityfile=/home/moo/.ssh/id_ed25519,allow_other,default_permissions,uid=1000,gid=1000 0 0

12.2.5 การ unmount (fusermount -u / umount)

การยกเลิกการ Mount มี 3 วิธีหลัก:

# วิธีที่ 1: ใช้ fusermount (สำหรับผู้ใช้ทั่วไป ไม่ต้องใช้ root)
fusermount -u ~/mnt/remote-server

# วิธีที่ 2: ใช้ fusermount3 (FUSE 3.x)
fusermount3 -u ~/mnt/remote-server

# วิธีที่ 3: ใช้ umount (ต้อง root)
sudo umount ~/mnt/remote-server

# กรณี busy (มีไฟล์เปิดอยู่)
# 3.1 ตรวจสอบว่าโปรเซสไหนใช้อยู่
lsof | grep ~/mnt/remote-server

# 3.2 บังคับ unmount (ใช้ระวัง - อาจสูญเสียข้อมูลที่ยังไม่ flush)
fusermount -uz ~/mnt/remote-server   # lazy unmount
sudo umount -f ~/mnt/remote-server   # force unmount

# วิธีที่ 4: บน macOS ใช้ diskutil
diskutil unmount ~/mnt/remote-server

12.2.6 ข้อดี-ข้อเสียและ Use Case

ข้อดี:

Setup ง่ายและรวดเร็ว ใช้แค่ SSH ที่มักเปิดอยู่แล้ว ไม่ต้องตั้งค่า Server ใหม่
เข้ารหัสตลอดทาง (End-to-End Encryption) ปลอดภัยจาก Eavesdropping
ผ่าน Firewall ง่าย ใช้แค่พอร์ต 22 (หรือพอร์ตเดียว)
ข้าม Platform ใช้ได้ทั้ง Linux, macOS, BSD, Windows (ผ่าน WinFsp)
ไม่ต้องสิทธิ์ root ในฝั่ง Client

ข้อเสีย:

ประสิทธิภาพต่ำ เมื่อเทียบกับ NFS หรือ SMB เพราะมี Overhead ของ SSH Encryption + FUSE Context Switch
Latency สูง โดยเฉพาะเมื่อมี Round Trip หลาย ๆ ครั้ง (เช่น ls ของไดเรกทอรีใหญ่)
ไม่รองรับ File Locking ที่สมบูรณ์ ทำให้ไม่เหมาะกับฐานข้อมูลหรือ Concurrent Write
ไม่มี HA หาก Server ล่ม การ Mount จะค้างจนกว่า reconnect จะสำเร็จ

Use Case ที่เหมาะสม:

การเข้าถึงไฟล์ส่วนตัวบน VPS หรือ Workstation ที่บ้าน เช่น แก้ไข source code บน Server ผ่าน VS Code Remote
Backup script เล็ก ๆ ที่ต้องการความปลอดภัยและไม่ต้องการประสิทธิภาพสูง
Lab สำหรับการเรียนรู้ ระบบไฟล์เครือข่ายโดยไม่ต้องตั้ง Server เต็มรูปแบบ
Quick Sharing ระหว่างเครื่อง Developer หลายเครื่องในทีมเล็ก

Use Case ที่ไม่เหมาะสม:

Database storage (ใช้ NFS/iSCSI/Ceph แทน)
Workload ที่มี IOPS สูง เช่น VM Image
การแชร์ที่ต้องการ HA/Replication

12.3 NFS (Network File System)

NFS (Network File System) เป็นโปรโตคอลแชร์ไฟล์มาตรฐานในโลก Unix/Linux พัฒนาโดย Sun Microsystems ในปี 1984 และกลายเป็น RFC สำคัญที่ใช้กันทั่วโลก ปัจจุบันเป็นเครื่องมือหลักสำหรับ Shared Storage ในองค์กร, Kubernetes Persistent Volume และระบบ HPC

12.3.1 ประวัติและ Version: NFSv3, NFSv4, NFSv4.1 (pNFS), NFSv4.2

ภาพรวมประวัติของ NFS:

flowchart TB
    subgraph Era1["ยุคแรก (1984-1995)"]
        V1["NFSv1 (1984)
Sun internal"]
        V2["NFSv2 (1989)
RFC 1094
UDP, 32-bit"]
    end

    subgraph Era2["ยุคพัฒนา (1995-2010)"]
        V3["NFSv3 (1995)
RFC 1813
TCP, 64-bit, Async Write"]
        V4["NFSv4 (2003)
RFC 3530
Stateful, Compound RPC"]
    end

    subgraph Era3["ยุคปัจจุบัน (2010-)"]
        V41["NFSv4.1 (2010)
RFC 5661
pNFS, Sessions"]
        V42["NFSv4.2 (2016)
RFC 7862
Server-side Copy, Sparse"]
    end

    V1 --> V2 --> V3 --> V4 --> V41 --> V42

    style V1 fill:#928374,stroke:#7c6f64,color:#fbf1c7
    style V2 fill:#cc241d,stroke:#fb4934,color:#fbf1c7
    style V3 fill:#d65d0e,stroke:#fe8019,color:#fbf1c7
    style V4 fill:#d79921,stroke:#fabd2f,color:#1d2021
    style V41 fill:#98971a,stroke:#b8bb26,color:#fbf1c7
    style V42 fill:#458588,stroke:#83a598,color:#fbf1c7

ความแตกต่างระหว่างเวอร์ชัน:

คุณสมบัติ	NFSv3	NFSv4	NFSv4.1	NFSv4.2
ปี	1995	2003	2010	2016
Stateful	Stateless	Stateful	Stateful + Sessions	Stateful + Sessions
Transport	UDP/TCP	TCP เท่านั้น	TCP/RDMA	TCP/RDMA
Port	111 + ไดนามิก	2049 (เดียว)	2049	2049
Locking	NLM แยก	Built-in	Built-in	Built-in
Auth	AUTH_SYS	+ RPCSEC_GSS (Kerberos)	+ Kerberos	+ Kerberos
Parallel I/O	ไม่มี	ไม่มี	pNFS	pNFS
Server-side Copy	ไม่มี	ไม่มี	ไม่มี	มี (COPY op)
Sparse File	ไม่ดี	ไม่ดี	ปานกลาง	รองรับ (HOLE/DATA)
ACL	POSIX	NFSv4 ACL (เหมือน Windows)	NFSv4 ACL	NFSv4 ACL
Firewall-friendly	ไม่ดี	ดี	ดี	ดี

คำแนะนำ: ใช้ NFSv4.2 หากเป็นไปได้ เพราะมีประสิทธิภาพและความปลอดภัยดีที่สุด ส่วน NFSv3 ยังพบมากใน Legacy System และ NAS Appliance

12.3.2 สถาปัตยกรรม: rpcbind, nfsd, mountd, lockd

NFSv3 ใช้บริการหลายตัวประกอบกัน เพราะออกแบบมาบน RPC (Remote Procedure Call):

flowchart TB
    subgraph ClientNode["NFS Client"]
        APP_C["Application"]
        VFS_C["VFS"]
        NFS_C["NFS Client
(kernel module)"]
        RPC_C["RPC Layer"]
    end

    subgraph ServerNode["NFS Server"]
        RPCB["rpcbind
(port 111)
service mapper"]
        MOUNTD["rpc.mountd
(port 20048)
handles mount requests"]
        NFSD["nfsd
(port 2049)
file operations"]
        LOCKD["rpc.statd + lockd
(NLM)
file locking - NFSv3"]
        IDMAPD["rpc.idmapd
UID/GID mapping
NFSv4 only"]
        VFS_S["VFS"]
        FS["Local FS
(ext4/xfs)"]
    end

    APP_C --> VFS_C --> NFS_C --> RPC_C
    RPC_C -->|"1. RPC Lookup"| RPCB
    RPC_C -->|"2. mount export"| MOUNTD
    RPC_C -->|"3. read/write"| NFSD
    RPC_C -->|"4. lock"| LOCKD
    RPC_C -.->|"NFSv4 only"| IDMAPD
    NFSD --> VFS_S --> FS

    style RPCB fill:#cc241d,stroke:#fb4934,color:#fbf1c7
    style MOUNTD fill:#d65d0e,stroke:#fe8019,color:#fbf1c7
    style NFSD fill:#d79921,stroke:#fabd2f,color:#1d2021
    style LOCKD fill:#98971a,stroke:#b8bb26,color:#fbf1c7
    style IDMAPD fill:#458588,stroke:#83a598,color:#fbf1c7

บริการสำคัญที่ต้องเข้าใจ:

rpcbind (เดิมชื่อ portmapper) ทำหน้าที่ Map ระหว่างหมายเลขโปรแกรม RPC กับ Port จริง ฟัง Port 111 (เฉพาะ NFSv3)
rpc.mountd รับคำขอ Mount Request จาก Client และตรวจสอบ Export List
nfsd ตัวหลักที่จัดการ Read/Write Operations รันใน Kernel Space (kthread หลายตัว)
rpc.statd + rpc.lockd จัดการ File Locking (Network Lock Manager - NLM) สำหรับ NFSv3
rpc.idmapd สำหรับ NFSv4 ในการแมป UID/GID เป็น username@domain (string-based)

สำหรับ NFSv4 สถาปัตยกรรมเรียบง่ายขึ้นมาก เพราะรวมทุกอย่างไว้ใน Port 2049 พอร์ตเดียว ไม่ต้องใช้ rpcbind, mountd, lockd แยกอีกต่อไป

12.3.3 NFS Server Setup (nfs-utils / nfs-kernel-server)

บน Debian/Ubuntu:

# 1. ติดตั้ง package
sudo apt update
sudo apt install -y nfs-kernel-server

# 2. สร้างไดเรกทอรีที่จะ Export
sudo mkdir -p /srv/nfs/research-data
sudo chown nobody:nogroup /srv/nfs/research-data
sudo chmod 755 /srv/nfs/research-data

# 3. แก้ไขไฟล์ /etc/exports (ดูรายละเอียดใน 12.3.4)
echo "/srv/nfs/research-data 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)" \
    | sudo tee -a /etc/exports

# 4. Apply การเปลี่ยนแปลง
sudo exportfs -arv

# 5. เริ่มและตั้งให้บริการเริ่มทุกครั้งที่บูต
sudo systemctl enable --now nfs-kernel-server

# 6. ตรวจสอบสถานะ
sudo systemctl status nfs-kernel-server
sudo exportfs -v

บน Fedora/RHEL/Rocky/Alma:

# 1. ติดตั้ง package
sudo dnf install -y nfs-utils

# 2. สร้าง export directory
sudo mkdir -p /srv/nfs/research-data
sudo chown nobody:nobody /srv/nfs/research-data

# 3. แก้ไข /etc/exports เหมือนเดิม
sudo vi /etc/exports

# 4. เปิดบริการ
sudo systemctl enable --now nfs-server
sudo systemctl enable --now rpcbind  # สำหรับ NFSv3

# 5. เปิด Firewall
sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --reload

# 6. Apply exports
sudo exportfs -arv

บน Arch/Manjaro:

# ติดตั้ง
sudo pacman -S nfs-utils

# เปิดบริการ
sudo systemctl enable --now nfs-server
sudo exportfs -arv

12.3.4 ไฟล์ /etc/exports และ Option

ไฟล์ /etc/exports คือหัวใจของการตั้งค่า NFS Server กำหนดว่าไดเรกทอรีไหน Export ให้ใคร ด้วยสิทธิ์อะไร

โครงสร้าง:

<ไดเรกทอรี> <client1>(option1,option2,...) <client2>(option1,...)

ตัวอย่างไฟล์ /etc/exports ที่ครอบคลุม:

# /etc/exports - NFS Export Table
# โฟลเดอร์ห้องวิจัย: นักศึกษาในเครือข่าย LAB อ่าน-เขียนได้
/srv/nfs/research      192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

# โฟลเดอร์อ่านอย่างเดียว: ใช้แชร์เอกสาร reference
/srv/nfs/docs          *(ro,sync,no_subtree_check,all_squash,anonuid=65534,anongid=65534)

# Home Directory: Mount แบบ Personal โดยไม่ squash root
/home                  192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

# โฟลเดอร์เฉพาะเครื่องเดียว
/srv/nfs/private       192.168.1.50(rw,sync,no_subtree_check,root_squash)

# โฟลเดอร์ async เพื่อประสิทธิภาพ (เสี่ยงข้อมูลหายเมื่อไฟดับ)
/srv/nfs/cache         192.168.1.0/24(rw,async,no_subtree_check,no_root_squash)

# NFSv4 fsid=0 (root export, pseudo-fs)
/srv/nfs               192.168.1.0/24(rw,fsid=0,sync,no_subtree_check)
/srv/nfs/research      192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

Option สำคัญที่ต้องรู้:

Option	ความหมาย
`rw`	อ่าน-เขียนได้
`ro`	อ่านอย่างเดียว
`sync`	เขียนลงดิสก์ทันที (ปลอดภัย แต่ช้า)
`async`	เขียนแบบ buffer (เร็ว แต่เสี่ยงข้อมูลหาย)
`no_subtree_check`	ปิดการตรวจสอบ subtree (เร็ว, แนะนำ)
`subtree_check`	เปิด subtree check (เก่า, ไม่แนะนำ)
`root_squash` (default)	แมป UID 0 (root) ของ Client → nobody
`no_root_squash`	ให้ root ของ Client = root ของ Server (อันตราย)
`all_squash`	แมปทุก UID → anonymous user
`anonuid=65534`	ระบุ UID ของ anonymous user
`anongid=65534`	ระบุ GID ของ anonymous user
`secure` (default)	บังคับ Client ใช้ Port < 1024
`insecure`	อนุญาต Port > 1024 (Container บางตัวต้องใช้)
`wdelay`	รอเขียนรวมกัน (default)
`no_wdelay`	เขียนทันที
`fsid=0`	ระบุเป็น root ของ NFSv4 namespace
`crossmnt`	อนุญาตข้าม mount point
`sec=sys`	ใช้ AUTH_SYS (default)
`sec=krb5`	ใช้ Kerberos auth
`sec=krb5i`	Kerberos + integrity
`sec=krb5p`	Kerberos + privacy (encrypted)

12.3.5 คำสั่ง exportfs (-a, -r, -v)

exportfs ใช้จัดการ Export Table แบบ Dynamic โดยไม่ต้อง Restart บริการ

# Export ทุกบรรทัดในไฟล์ /etc/exports
sudo exportfs -a

# Re-export ทุกอัน (เคลียร์ของเก่า + load ใหม่)
sudo exportfs -r

# แสดง verbose
sudo exportfs -v
# /srv/nfs/research
#                 192.168.1.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,...)

# รวมกัน: re-export + verbose (ใช้บ่อยที่สุด)
sudo exportfs -arv

# Export แบบเฉพาะกิจ ไม่ใส่ใน /etc/exports
sudo exportfs -o rw,sync,no_root_squash 192.168.1.50:/srv/nfs/temp

# Unexport เฉพาะตัว
sudo exportfs -u 192.168.1.50:/srv/nfs/temp

# Unexport ทุกตัว
sudo exportfs -ua

# ดู client ที่กำลัง mount อยู่
showmount -a
# All mount points on server.local:
# 192.168.1.50:/srv/nfs/research
# 192.168.1.51:/srv/nfs/research

# ดูรายการ export ทั้งหมดบน Server (เรียกจาก client หรือ server)
showmount -e localhost
showmount -e 192.168.1.100

12.3.6 NFS Client: showmount, mount -t nfs

ติดตั้ง Package บน Client:

# Debian/Ubuntu
sudo apt install -y nfs-common

# Fedora/RHEL
sudo dnf install -y nfs-utils

# Arch
sudo pacman -S nfs-utils

ตรวจสอบและ Mount:

# 1. ตรวจสอบ exports ที่มีบน Server
showmount -e 192.168.1.100
# Export list for 192.168.1.100:
# /srv/nfs/research 192.168.1.0/24
# /srv/nfs/docs     *

# 2. สร้าง mount point
sudo mkdir -p /mnt/nfs-research

# 3. Mount แบบ NFSv4 (default ในปัจจุบัน)
sudo mount -t nfs4 192.168.1.100:/srv/nfs/research /mnt/nfs-research

# 4. Mount แบบ NFSv3
sudo mount -t nfs -o vers=3 192.168.1.100:/srv/nfs/research /mnt/nfs-research

# 5. Mount พร้อม option การปรับแต่งประสิทธิภาพ
sudo mount -t nfs4 \
    -o rw,hard,intr,rsize=1048576,wsize=1048576,timeo=600,retrans=2 \
    192.168.1.100:/srv/nfs/research /mnt/nfs-research

# 6. ตรวจสอบสถานะ
mount | grep nfs
df -h | grep nfs
nfsstat -m   # แสดง option ของ mount

12.3.7 การตั้งค่าถาวรใน /etc/fstab

เพื่อให้ Mount อัตโนมัติทุกครั้งที่บูต ให้เพิ่มบรรทัดใน /etc/fstab:

# /etc/fstab - แสดงตัวอย่างการตั้งค่า NFS
# <fs>                              <mountpoint>           <type>  <options>                                                           <dump> <pass>

# 1. NFSv4 พื้นฐาน (Mount ตอนบูต)
192.168.1.100:/srv/nfs/research     /mnt/research          nfs4    defaults,_netdev                                                    0      0

# 2. NFSv4 พร้อมปรับแต่ง (production-ready)
192.168.1.100:/srv/nfs/research     /mnt/research          nfs4    rw,hard,intr,rsize=1048576,wsize=1048576,timeo=600,_netdev          0      0

# 3. NFSv3 (สำหรับ legacy)
192.168.1.100:/srv/nfs/research     /mnt/research          nfs     vers=3,rw,hard,intr,rsize=32768,wsize=32768,_netdev                 0      0

# 4. systemd automount (Mount เฉพาะตอนใช้งาน)
192.168.1.100:/srv/nfs/research     /mnt/research          nfs4    noauto,x-systemd.automount,x-systemd.idle-timeout=300,_netdev      0      0

# 5. Soft mount (ไม่บล็อกถาวรเมื่อ Server ล่ม - ใช้ระวัง)
192.168.1.100:/srv/nfs/cache        /mnt/cache             nfs4    soft,timeo=30,retrans=2,_netdev                                     0      0

Mount Option ที่ควรเข้าใจ:

hard (default) Client จะรอจนกว่า Server กลับมา (ปลอดภัยข้อมูล)
soft Return error เมื่อ timeout (เสี่ยงข้อมูลเสียหาย ใช้กับ read-only เท่านั้น)
intr ยอมให้ Ctrl+C ขัดจังหวะการรอ (เลิกใช้ใน kernel ใหม่)
rsize=N, wsize=N ขนาด buffer อ่าน/เขียน (มาตรฐาน 1048576 = 1MB)
timeo=N timeout ในหน่วย 0.1 วินาที (600 = 60 วินาที)
retrans=N จำนวนครั้งที่ retry
_netdev บอก systemd ว่าต้องรอเครือข่ายก่อน

12.3.8 UID/GID Mapping และ idmapd

ปัญหา UID/GID ใน NFS:

NFSv3 ใช้ UID/GID เป็นตัวเลข ดังนั้นถ้า user moo บน Server มี UID = 1001 แต่บน Client มี UID = 1005 ไฟล์ที่สร้างจะมีเจ้าของไม่ตรงกัน

NFSv4 แก้ปัญหานี้ด้วย idmapd ที่แปลง UID/GID เป็น string รูปแบบ user@domain เช่น moo@rmutsv.ac.th

การตั้งค่า idmapd:

# แก้ไข /etc/idmapd.conf ทั้ง Server และ Client
sudo vi /etc/idmapd.conf

[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = rmutsv.ac.th

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = nsswitch

# Restart idmapd หลังแก้ไข
sudo systemctl restart nfs-idmapd        # ใหม่
sudo systemctl restart rpc-idmapd        # เก่า

# ตรวจสอบ
nfsidmap -d                              # ดู domain ปัจจุบัน
nfsidmap -c                              # clear cache

ทางเลือก: ใช้ LDAP, FreeIPA, Active Directory เพื่อให้ UID/GID เหมือนกันทุกเครื่อง หรือใช้ idmap=user ใน mount option

12.3.9 Performance Tuning (rsize, wsize, async)

ตัวอย่างการปรับแต่งเพื่อประสิทธิภาพสูงสุด:

# 1. ปรับ rsize/wsize ให้ใหญ่ที่สุด (NFSv4 รองรับสูงสุด 1MB)
sudo mount -t nfs4 -o rsize=1048576,wsize=1048576 \
    server:/export /mnt/nfs

# 2. เปิด async บน Server (อันตราย แต่เร็ว)
# ใน /etc/exports:
# /srv/nfs/cache 192.168.1.0/24(rw,async,no_subtree_check)

# 3. เพิ่มจำนวน nfsd thread (default 8)
# ดู
cat /proc/fs/nfsd/threads

# แก้ไขใน /etc/nfs.conf (Debian/Ubuntu)
sudo vi /etc/nfs.conf
# [nfsd]
# threads=32

# หรือแก้ไขใน /etc/sysconfig/nfs (RHEL/Fedora)
# RPCNFSDCOUNT=32

# 4. ปรับ TCP buffer
sudo sysctl -w net.core.rmem_max=134217728
sudo sysctl -w net.core.wmem_max=134217728
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"

# 5. ใช้ Jumbo Frame (MTU=9000) ในเครือข่ายภายใน
sudo ip link set eth0 mtu 9000

# 6. เปิด NFS over RDMA (ถ้ามี InfiniBand/RoCE)
sudo mount -t nfs4 -o proto=rdma,port=20049 server:/export /mnt/nfs

สูตรคำนวณค่าที่เหมาะสม:

BDP = Bandwidth \times RTT

โดยที่:

BDP (Bandwidth-Delay Product) คือขนาด buffer ที่เหมาะสมในหน่วย bytes
Bandwidth คือความเร็วเครือข่าย เช่น 1 Gbps = 125 MB/s
RTT (Round-Trip Time) วัดด้วย ping เป็น ms แล้วแปลงเป็นวินาที

ตัวอย่าง: 1 Gbps × 1 ms = 125,000,000 × 0.001 = 125,000 bytes ≈ 128 KB ดังนั้น rsize=131072 ก็เพียงพอในเครือข่าย LAN แต่ถ้าเป็น 10 Gbps ใช้ rsize=1048576

12.3.10 Security: NFSv4 with Kerberos

ปัญหาความปลอดภัยของ AUTH_SYS: Client เป็นคนบอก Server ว่าตัวเองเป็น UID อะไร โดยไม่ตรวจสอบ ทำให้ใครก็ตามที่อยู่ในเครือข่ายเดียวกันสามารถปลอม UID = 0 แล้วเข้าถึงไฟล์ทั้งหมดได้

Kerberos แก้ปัญหานี้ ด้วยการใช้ Trusted Third Party (KDC - Key Distribution Center) ออก Ticket เพื่อยืนยันตัวตน

สามระดับของ NFSv4 + Kerberos:

Level	คำอธิบาย	ความปลอดภัย	ประสิทธิภาพ
`sec=krb5`	Authentication อย่างเดียว	กลาง	ดี
`sec=krb5i`	Auth + Integrity (ป้องกัน tampering)	สูง	ปานกลาง
`sec=krb5p`	Auth + Integrity + Privacy (เข้ารหัส)	สูงสุด	ลดลง 30-50%

ตัวอย่างการตั้งค่า:

# ฝั่ง Server: /etc/exports
/srv/nfs/secure  *(rw,sync,sec=krb5p,no_subtree_check)

# ฝั่ง Client: mount
sudo mount -t nfs4 -o sec=krb5p server:/srv/nfs/secure /mnt/secure

# ตรวจสอบว่า Kerberos service ทำงาน
sudo systemctl status nfs-secure         # ใหม่
sudo systemctl status rpc-gssd           # client side
sudo systemctl status nfs-mountd         # server side

# ดู Kerberos ticket ของผู้ใช้
klist

12.4 SMB/CIFS (Samba)

Samba คือการ implement SMB (Server Message Block) / CIFS (Common Internet File System) บน Linux เพื่อให้สามารถแชร์ไฟล์และเครื่องพิมพ์กับเครื่อง Windows, macOS และ Linux อื่นได้ พัฒนาโดย Andrew Tridgell ตั้งแต่ปี 1992

12.4.1 ใช้งานร่วมกับ Windows และ macOS

Samba เป็นทางเลือกหลักเมื่อต้องการแชร์ไฟล์ในสภาพแวดล้อมที่ผสม Windows-Linux เพราะ Windows ไม่มี NFS Client built-in ใน Edition ส่วนใหญ่ และ macOS รองรับ SMB เป็น Default ตั้งแต่ macOS 10.9 Mavericks

กรณีใช้งานทั่วไป:

File Server ในสำนักงานที่มีทั้ง Windows และ macOS
การ join Linux เข้า Active Directory Domain
Network Attached Storage (NAS) เช่น Synology, QNAP, TrueNAS ที่ใช้ Samba ภายใน
การแชร์โฟลเดอร์ห้องเรียนสำหรับนักศึกษาที่ใช้ Windows

ไฟล์ตั้งค่าหลักของ Samba คือ /etc/samba/smb.conf แบ่งเป็นสอง Section หลัก: [global] (ตั้งค่าระบบทั้งหมด) และ Share Definition ([sharename])

ติดตั้ง Samba:

# Debian/Ubuntu
sudo apt install -y samba samba-common-bin

# Fedora/RHEL
sudo dnf install -y samba samba-client

# Arch
sudo pacman -S samba

ตัวอย่างไฟล์ /etc/samba/smb.conf ที่ครบถ้วน:

#======================= Global Settings =======================
[global]
   # ชื่อ workgroup (ตามเครือข่าย Windows)
   workgroup = WORKGROUP

   # คำอธิบาย Server
   server string = RMUTSV File Server

   # NetBIOS Name
   netbios name = NFS-SERVER

   # Security mode
   security = user
   map to guest = bad user

   # Log
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file

   # Performance
   socket options = TCP_NODELAY IPTOS_LOWDELAY
   read raw = yes
   write raw = yes

   # Protocol (SMB1 ปิดเพื่อความปลอดภัย)
   server min protocol = SMB2
   client min protocol = SMB2

   # Encryption (สำหรับ SMB3)
   server signing = mandatory
   smb encrypt = required

   # Interfaces (จำกัดเฉพาะ network ที่ต้องการ)
   interfaces = 127.0.0.0/8 192.168.1.0/24
   bind interfaces only = yes

#======================= Share Definitions =====================

[research]
   comment = Research Data Share
   path = /srv/samba/research
   browseable = yes
   read only = no
   guest ok = no
   valid users = @researchers
   create mask = 0660
   directory mask = 0770
   force group = researchers

[public]
   comment = Public Read-only Documents
   path = /srv/samba/public
   browseable = yes
   read only = yes
   guest ok = yes
   guest only = yes

[homes]
   comment = Home Directories
   browseable = no
   read only = no
   create mask = 0700
   directory mask = 0700
   valid users = %S

[printers]
   comment = All Printers
   path = /var/spool/samba
   browseable = no
   guest ok = no
   writable = no
   printable = yes

ทดสอบ Configuration และ Apply:

# ตรวจสอบ syntax
testparm
testparm -s   # แบบ strict

# Restart service
sudo systemctl restart smbd nmbd
sudo systemctl enable smbd nmbd

# เปิด Firewall
sudo ufw allow samba                                    # Ubuntu
sudo firewall-cmd --permanent --add-service=samba       # RHEL
sudo firewall-cmd --reload

12.4.3 smbpasswd และ User Management

Samba ใช้ฐานข้อมูลผู้ใช้แยก จาก Linux User (แต่ username ต้องตรงกัน) ด้วย Samba Password Database (tdbsam)

# 1. สร้าง Linux user ก่อน
sudo useradd -m -s /bin/bash moo

# 2. ตั้ง Samba password (สามารถต่างจาก Linux password ได้)
sudo smbpasswd -a moo
# New SMB password: ********
# Retype new SMB password: ********

# 3. Enable user
sudo smbpasswd -e moo

# 4. ตรวจสอบรายชื่อ user
sudo pdbedit -L
sudo pdbedit -Lv moo

# 5. เปลี่ยน password
sudo smbpasswd moo

# 6. ลบ user ออกจาก Samba
sudo smbpasswd -x moo

# 7. Disable user (ไม่ลบ)
sudo smbpasswd -d moo

# 8. สร้างกลุ่ม (Linux group)
sudo groupadd researchers
sudo usermod -aG researchers moo

# 9. ตั้งสิทธิ์โฟลเดอร์
sudo mkdir -p /srv/samba/research
sudo chown :researchers /srv/samba/research
sudo chmod 2770 /srv/samba/research   # SGID เพื่อให้ไฟล์ใหม่อยู่ในกลุ่ม

12.4.4 cifs-utils, smbclient, mount.cifs

ฝั่ง Linux Client:

# ติดตั้ง
sudo apt install -y cifs-utils smbclient

# 1. ดูรายการ share บน Server
smbclient -L //192.168.1.100 -U moo
# Enter MOO's password:
#         Sharename       Type      Comment
#         ---------       ----      -------
#         research        Disk      Research Data Share
#         public          Disk      Public Read-only Documents
#         IPC$            IPC       IPC Service

# 2. เชื่อมต่อแบบ Interactive (เหมือน FTP)
smbclient //192.168.1.100/research -U moo
smb: \> ls
smb: \> get filename.txt
smb: \> put localfile.txt
smb: \> exit

# 3. Mount แบบ permanent (CIFS)
sudo mkdir -p /mnt/research
sudo mount -t cifs //192.168.1.100/research /mnt/research \
    -o username=moo,password=secret,uid=$(id -u),gid=$(id -g),vers=3.0

# 4. ใช้ credentials file (ปลอดภัยกว่า)
sudo vi /etc/samba/credentials
# username=moo
# password=secret
sudo chmod 600 /etc/samba/credentials

sudo mount -t cifs //192.168.1.100/research /mnt/research \
    -o credentials=/etc/samba/credentials,uid=1000,gid=1000,vers=3.0

# 5. /etc/fstab สำหรับ auto-mount
# //192.168.1.100/research  /mnt/research  cifs  credentials=/etc/samba/credentials,uid=1000,gid=1000,vers=3.0,_netdev  0  0

ฝั่ง Windows:

# Map Network Drive ผ่าน PowerShell
New-PSDrive -Name "R" -PSProvider "FileSystem" `
            -Root "\\192.168.1.100\research" `
            -Credential (Get-Credential) -Persist

# หรือใช้ command line
net use R: \\192.168.1.100\research /user:moo *

ฝั่ง macOS:

1. Finder → Go → Connect to Server (⌘K)
2. ป้อน: smb://192.168.1.100/research
3. ใส่ Username/Password

12.4.5 SMB Version (SMB1 vs SMB2 vs SMB3)

ตารางเปรียบเทียบ:

คุณสมบัติ	SMB1 (CIFS)	SMB2	SMB2.1	SMB3	SMB3.1.1
ปี	1984	2007 (Vista)	2009 (Win7)	2012 (Win8)	2015 (Win10)
Encryption	ไม่มี	ไม่มี	ไม่มี	AES-128-CCM	AES-128-GCM, AES-256
Signing	MD5 (อ่อน)	HMAC-SHA256	HMAC-SHA256	AES-CMAC	AES-CMAC
Performance	ต่ำ	ดี	ดี	ดีมาก	ดีมาก
Multichannel	ไม่มี	ไม่มี	ไม่มี	มี	มี
RDMA (SMB Direct)	ไม่มี	ไม่มี	ไม่มี	มี	มี
Pre-auth Integrity	ไม่มี	ไม่มี	ไม่มี	ไม่มี	มี
สถานะ	ปิด (ช่องโหว่ EternalBlue/WannaCry)	Legacy	Legacy	ใช้ได้	แนะนำ

คำแนะนำ:

ปิด SMB1 ทั้งฝั่ง Server และ Client เสมอ
ใช้ SMB3.1.1 หากเป็นไปได้ (Windows 10+, Samba 4.3+, macOS 10.12+)
เปิด smb encrypt = required สำหรับการแชร์ที่มีข้อมูลสำคัญ
ใช้ Kerberos auth แทน NTLM ใน Domain Environment

# บังคับใช้ SMB3 ขึ้นไป (ใน /etc/samba/smb.conf)
[global]
   server min protocol = SMB3
   client min protocol = SMB3
   server max protocol = SMB3_11
   client max protocol = SMB3_11

12.5 GlusterFS

GlusterFS คือ Distributed File System แบบ Open Source ที่พัฒนาโดย Gluster Inc. (ปัจจุบันอยู่ใต้ Red Hat) ใช้สถาปัตยกรรมแบบ Scale-out ไม่มี Metadata Server กลาง (no SPOF) เหมาะสำหรับการเก็บข้อมูลขนาดใหญ่ระดับ Petabyte

12.5.1 สถาปัตยกรรม: Node, Brick, Volume, Trusted Storage Pool

ศัพท์สำคัญที่ต้องเข้าใจ:

Node เครื่องเซิร์ฟเวอร์ที่รัน glusterd daemon
Brick ไดเรกทอรีบนโหนดที่ใช้เก็บข้อมูลจริง เช่น server1:/data/brick1 (มักเป็น mount point ของ disk แยกต่างหาก)
Volume ชุดของ Brick ที่นำมารวมกันเป็น Logical Storage Unit ที่ผู้ใช้เห็น
Trusted Storage Pool (TSP) กลุ่มของ Node ที่ไว้ใจกัน (peers)
Translator Modular layer ของ GlusterFS ที่ผ่านข้อมูลทีละขั้น เช่น replication, distribution, encryption
Mount Point ตำแหน่งที่ Client เห็น Volume

flowchart TB
    subgraph TSP["Trusted Storage Pool"]
        subgraph N1["Node 1 (gluster1)"]
            B1["Brick 1
/data/brick1"]
            B2["Brick 2
/data/brick2"]
            G1["glusterd"]
        end
        subgraph N2["Node 2 (gluster2)"]
            B3["Brick 3
/data/brick1"]
            B4["Brick 4
/data/brick2"]
            G2["glusterd"]
        end
        subgraph N3["Node 3 (gluster3)"]
            B5["Brick 5
/data/brick1"]
            B6["Brick 6
/data/brick2"]
            G3["glusterd"]
        end
        G1 <-.->|"port 24007"| G2
        G2 <-.-> G3
        G1 <-.-> G3
    end

    V1["Volume: research-vol
(Distributed-Replicated)"]
    B1 --> V1
    B3 --> V1
    B2 --> V1
    B4 --> V1
    B5 --> V1
    B6 --> V1

    Client["GlusterFS Client
(FUSE)"]
    V1 --> Client

    style B1 fill:#458588,stroke:#83a598,color:#fbf1c7
    style B2 fill:#458588,stroke:#83a598,color:#fbf1c7
    style B3 fill:#98971a,stroke:#b8bb26,color:#fbf1c7
    style B4 fill:#98971a,stroke:#b8bb26,color:#fbf1c7
    style B5 fill:#cc241d,stroke:#fb4934,color:#fbf1c7
    style B6 fill:#cc241d,stroke:#fb4934,color:#fbf1c7
    style V1 fill:#d79921,stroke:#fabd2f,color:#1d2021
    style Client fill:#689d6a,stroke:#8ec07c,color:#fbf1c7

12.5.2 ประเภท Volume

1. Distributed Volume ไฟล์กระจายไปบน Brick ต่าง ๆ โดย Hash function ไม่มี replication ถ้า Brick หาย ไฟล์ในนั้นหาย

2. Replicated Volume ทุก Brick มีข้อมูลครบเหมือนกัน (เหมือน RAID 1) ทนต่อความเสียหาย

3. Distributed-Replicated รวมข้อดี: ไฟล์กระจาย + ทุกชุด replicate เป็นที่นิยมที่สุด (เหมือน RAID 1+0)

4. Dispersed (Erasure Coded) ใช้ Erasure Coding (เหมือน RAID 5/6) ประหยัดพื้นที่กว่า Replicate

5. Distributed-Dispersed กระจาย + Erasure Coding

ตารางสรุป:

ประเภท	จำนวน Brick ขั้นต่ำ	Capacity Efficiency	Fault Tolerance	Performance
Distributed	2	100%	0 (ไฟล์หายเมื่อ Brick หาย)	ดี (parallel)
Replicated	2 (replica 2), 3 (replica 3)	50% / 33%	1 / 2 brick failures	Read ดี, Write ช้า
Distributed-Replicated	4 (2x2), 6 (2x3)	50% / 33%	1 brick ต่อ replica set	ดี
Dispersed	6 (4+2)	67-83%	2 bricks (4+2)	ปานกลาง
Distributed-Dispersed	12 (2 x [4+2])	67-83%	2 ต่อ subset	ดี

สูตรคำนวณพื้นที่ใช้งานจริง (Distributed-Replicated):

UsableCapacity = \frac{TotalBricks \times BrickSize}{ReplicaCount}

โดยที่:

TotalBricks จำนวน Brick ทั้งหมดใน Volume
BrickSize ขนาดของแต่ละ Brick (ปกติเท่ากัน)
ReplicaCount จำนวนสำเนาที่ต้องการ (2 หรือ 3)

ตัวอย่าง: 6 Brick × 1 TB / replica 3 = 2 TB usable capacity ทนต่อ 2 brick failures พร้อมกันต่อ replica set

12.5.3 การติดตั้ง glusterd และ Peer Probe

Step 1: ติดตั้ง GlusterFS Server บนทุก Node

# Debian/Ubuntu
sudo apt install -y glusterfs-server

# Fedora/RHEL/Rocky
sudo dnf install -y centos-release-gluster
sudo dnf install -y glusterfs-server

# Arch
sudo pacman -S glusterfs

# เปิด service
sudo systemctl enable --now glusterd
sudo systemctl status glusterd

Step 2: ตั้งค่า hosts file (หรือใช้ DNS)

# /etc/hosts บนทุก Node
192.168.1.101  gluster1
192.168.1.102  gluster2
192.168.1.103  gluster3

Step 3: เปิด Firewall

# พอร์ตที่ GlusterFS ใช้
# 24007/tcp        glusterd
# 24008/tcp        management
# 49152-49251/tcp  brick (1 port per brick)
# 38465-38467/tcp  NFS export
# 2049/tcp         NFS-Ganesha

sudo ufw allow 24007:24008/tcp
sudo ufw allow 49152:49251/tcp

# RHEL/Fedora
sudo firewall-cmd --permanent --add-service=glusterfs
sudo firewall-cmd --reload

Step 4: Peer Probe (รันบน Node 1 เท่านั้น)

# Probe Node อื่น ๆ เข้ามาใน Trusted Storage Pool
sudo gluster peer probe gluster2
# peer probe: success

sudo gluster peer probe gluster3
# peer probe: success

# ตรวจสอบสถานะ
sudo gluster peer status
# Number of Peers: 2
#
# Hostname: gluster2
# Uuid: xxxxx
# State: Peer in Cluster (Connected)
#
# Hostname: gluster3
# Uuid: yyyyy
# State: Peer in Cluster (Connected)

sudo gluster pool list
# UUID                                  Hostname  State
# ...                                   gluster2  Connected
# ...                                   gluster3  Connected
# ...                                   localhost Connected

12.5.4 การสร้าง Volume

Step 5: เตรียม Brick บนทุก Node

# สร้างไดเรกทอรีสำหรับ Brick (ควรเป็น mount point ของ disk แยก)
# กรณีมีดิสก์เพิ่ม
sudo mkfs.xfs -i size=512 /dev/sdb1
sudo mkdir -p /data/brick1
echo '/dev/sdb1 /data/brick1 xfs defaults 0 0' | sudo tee -a /etc/fstab
sudo mount -a

# กรณีไม่มีดิสก์เพิ่ม (lab/test)
sudo mkdir -p /data/brick1

# สร้าง subdirectory สำหรับแต่ละ Volume (best practice)
sudo mkdir -p /data/brick1/research-vol

Step 6: สร้าง Volume

# 1. Distributed-Replicated Volume (replica 3)
sudo gluster volume create research-vol replica 3 \
    gluster1:/data/brick1/research-vol \
    gluster2:/data/brick1/research-vol \
    gluster3:/data/brick1/research-vol \
    force

# 2. Replicated Volume (replica 2 - arbiter เป็นทางเลือกป้องกัน split-brain)
sudo gluster volume create student-vol replica 3 arbiter 1 \
    gluster1:/data/brick1/student-vol \
    gluster2:/data/brick1/student-vol \
    gluster3:/data/brick1/student-vol \
    force

# 3. Distributed-Replicated (6 bricks, 2x replica 3)
sudo gluster volume create big-vol replica 3 \
    gluster1:/data/brick1/big-vol gluster2:/data/brick1/big-vol gluster3:/data/brick1/big-vol \
    gluster1:/data/brick2/big-vol gluster2:/data/brick2/big-vol gluster3:/data/brick2/big-vol \
    force

# 4. Dispersed Volume (4+2 erasure coding)
sudo gluster volume create dispersed-vol disperse 6 redundancy 2 \
    gluster1:/data/brick1/dispersed gluster1:/data/brick2/dispersed \
    gluster2:/data/brick1/dispersed gluster2:/data/brick2/dispersed \
    gluster3:/data/brick1/dispersed gluster3:/data/brick2/dispersed \
    force

# Start volume
sudo gluster volume start research-vol

# ดูข้อมูล
sudo gluster volume info research-vol
sudo gluster volume status research-vol
sudo gluster volume list

Step 7: ตั้งค่า Volume Option ที่ใช้บ่อย

# เปิด Performance options
sudo gluster volume set research-vol performance.cache-size 256MB
sudo gluster volume set research-vol performance.io-thread-count 32
sudo gluster volume set research-vol performance.write-behind-window-size 1MB

# เปิด Quick Read สำหรับไฟล์เล็ก
sudo gluster volume set research-vol performance.quick-read on

# Network Compression
sudo gluster volume set research-vol network.compression on

# Auth - จำกัด IP ที่เข้าถึงได้
sudo gluster volume set research-vol auth.allow 192.168.1.*

# ดูค่าปัจจุบัน
sudo gluster volume get research-vol all

12.5.5 การ Mount บน Client

Native (FUSE-based) Mount - แนะนำ:

# 1. ติดตั้ง client
sudo apt install -y glusterfs-client

# 2. สร้าง mount point
sudo mkdir -p /mnt/research

# 3. Mount แบบ manual
sudo mount -t glusterfs gluster1:/research-vol /mnt/research

# 4. /etc/fstab สำหรับ auto-mount
# gluster1:/research-vol /mnt/research glusterfs defaults,_netdev,backup-volfile-servers=gluster2:gluster3 0 0

# ตัวเลือก backup-volfile-servers ทำให้หาก gluster1 ล่ม Client ใช้ gluster2 หรือ gluster3 แทนได้

NFS-Ganesha Mount (สำหรับ Client ที่ไม่มี gluster client):

# ติดตั้งและเปิด NFS-Ganesha บน Server
sudo dnf install -y nfs-ganesha-gluster

# Mount จาก client (NFSv4)
sudo mount -t nfs4 -o vers=4.1 gluster1:/research-vol /mnt/research

SMB Mount (สำหรับ Windows):

# /etc/samba/smb.conf
[research]
    path = /mnt/research-gluster   # local mount ของ glusterfs
    vfs objects = glusterfs
    glusterfs:volfile_server = localhost
    glusterfs:volume = research-vol
    read only = no

12.5.6 Self-heal และ Rebalance

Self-heal คือกลไกที่ GlusterFS ตรวจสอบและซ่อมแซมความไม่สอดคล้องของข้อมูลระหว่าง Brick ใน Replica set โดยอัตโนมัติ

# ดูไฟล์ที่ต้องการ heal
sudo gluster volume heal research-vol info

# Heal ทันที (ปกติทำอัตโนมัติทุก 10 นาที)
sudo gluster volume heal research-vol

# Heal เต็มรูปแบบ (full heal)
sudo gluster volume heal research-vol full

# ดูสถิติ
sudo gluster volume heal research-vol statistics

# กรณี split-brain (ข้อมูลขัดแย้ง)
sudo gluster volume heal research-vol info split-brain

# แก้ split-brain โดยเลือก source brick
sudo gluster volume heal research-vol split-brain source-brick \
    gluster1:/data/brick1/research-vol /path/to/file

Rebalance คือการกระจายข้อมูลใหม่หลังจากเพิ่ม/ลบ Brick

# เริ่ม rebalance
sudo gluster volume rebalance research-vol start

# ดูสถานะ
sudo gluster volume rebalance research-vol status

# หยุด rebalance
sudo gluster volume rebalance research-vol stop

# Force rebalance (รวม metadata)
sudo gluster volume rebalance research-vol start force

12.5.7 การขยาย (add-brick) และลด (remove-brick) Volume

ขยาย Volume:

# 1. เตรียม Brick ใหม่บน Node
sudo mkdir -p /data/brick2/research-vol

# 2. เพิ่ม Brick (ต้องเพิ่มเป็นชุดตาม replica count)
sudo gluster volume add-brick research-vol \
    gluster1:/data/brick2/research-vol \
    gluster2:/data/brick2/research-vol \
    gluster3:/data/brick2/research-vol

# 3. Rebalance เพื่อกระจายข้อมูล
sudo gluster volume rebalance research-vol start

ลด Volume:

# 1. เริ่ม remove-brick (ย้ายข้อมูลออกก่อน)
sudo gluster volume remove-brick research-vol \
    gluster1:/data/brick2/research-vol \
    gluster2:/data/brick2/research-vol \
    gluster3:/data/brick2/research-vol \
    start

# 2. ดูสถานะการย้ายข้อมูล
sudo gluster volume remove-brick research-vol \
    gluster1:/data/brick2/research-vol \
    gluster2:/data/brick2/research-vol \
    gluster3:/data/brick2/research-vol \
    status

# 3. เมื่อ status = completed ให้ commit
sudo gluster volume remove-brick research-vol \
    gluster1:/data/brick2/research-vol \
    gluster2:/data/brick2/research-vol \
    gluster3:/data/brick2/research-vol \
    commit

12.5.8 Geo-replication สำหรับ DR

Geo-replication คือการ Replicate ข้อมูลแบบ Asynchronous จาก Master Volume ไปยัง Slave Volume ที่อยู่ต่าง Site เพื่อ Disaster Recovery

# Setup ระหว่าง Master Site (gluster1) และ DR Site (dr1)
# 1. สร้าง SSH key บน Master node
sudo ssh-keygen -f /var/lib/glusterd/geo-replication/secret.pem -N ''

# 2. กระจาย public key ไป DR site
sudo ssh-copy-id -i /var/lib/glusterd/geo-replication/secret.pem.pub \
    georeplica@dr1.rmutsv.ac.th

# 3. สร้าง geo-replication session
sudo gluster volume geo-replication research-vol \
    georeplica@dr1::dr-research-vol create push-pem

# 4. เริ่ม geo-replication
sudo gluster volume geo-replication research-vol \
    georeplica@dr1::dr-research-vol start

# 5. ดูสถานะ
sudo gluster volume geo-replication research-vol \
    georeplica@dr1::dr-research-vol status

# 6. หยุดชั่วคราว / กลับมาทำงาน
sudo gluster volume geo-replication research-vol \
    georeplica@dr1::dr-research-vol pause
sudo gluster volume geo-replication research-vol \
    georeplica@dr1::dr-research-vol resume

12.5.9 Quota และ Snapshot

Quota จำกัดพื้นที่ใช้งาน:

# เปิด Quota
sudo gluster volume quota research-vol enable

# ตั้ง Quota เฉพาะ directory
sudo gluster volume quota research-vol limit-usage /students 100GB
sudo gluster volume quota research-vol limit-usage /staff 500GB

# ตั้งจำนวนไฟล์สูงสุด (inode limit)
sudo gluster volume quota research-vol limit-objects /students 10000

# ดูสถานะ
sudo gluster volume quota research-vol list

# ลบ quota
sudo gluster volume quota research-vol remove /students

Snapshot การถ่ายภาพข้อมูล ณ เวลานั้น (ต้องใช้ thin-provisioned LVM หรือ Btrfs):

# 1. สร้าง snapshot
sudo gluster snapshot create snap-2026-04-25 research-vol

# 2. ดูรายการ snapshot
sudo gluster snapshot list
sudo gluster snapshot info

# 3. Activate snapshot (mount ได้)
sudo gluster snapshot activate snap-2026-04-25

# 4. Mount snapshot บน client (read-only)
sudo mount -t glusterfs gluster1:/snaps/snap-2026-04-25/research-vol /mnt/snap-research

# 5. ลบ snapshot
sudo gluster snapshot delete snap-2026-04-25

# 6. Restore volume จาก snapshot (ต้อง stop volume ก่อน)
sudo gluster volume stop research-vol
sudo gluster snapshot restore snap-2026-04-25
sudo gluster volume start research-vol

# 7. ตั้ง snapshot scheduling
sudo gluster snapshot config snap-max-hard-limit 50
sudo gluster snapshot config snap-max-soft-limit 80
sudo gluster snapshot config auto-delete enable

12.5.10 Monitoring (gluster top, profile)

# 1. ดู read performance ทั้ง volume
sudo gluster volume top research-vol read

# 2. ดู write performance
sudo gluster volume top research-vol write

# 3. ดู open files
sudo gluster volume top research-vol open

# 4. ดู directory ที่ถูกใช้บ่อย
sudo gluster volume top research-vol opendir

# 5. เริ่ม profile (รวบรวมข้อมูล performance)
sudo gluster volume profile research-vol start

# 6. ดูข้อมูล profile
sudo gluster volume profile research-vol info

# 7. หยุด profile
sudo gluster volume profile research-vol stop

# 8. ใช้กับ external monitoring (Prometheus + gluster-exporter)
# https://github.com/ofesseler/gluster_exporter

ตัวอย่าง Script ตรวจสอบสุขภาพ Cluster:

#!/bin/bash
# health-check-gluster.sh - ตรวจสอบสถานะ GlusterFS Cluster
# ใช้กับ cron: */5 * * * * /usr/local/bin/health-check-gluster.sh

set -euo pipefail

VOLUME="research-vol"
LOG="/var/log/gluster-health.log"
ALERT_EMAIL="admin@rmutsv.ac.th"

log() {
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] $1" >> "$LOG"
}

# 1. ตรวจสอบ peer status
PEER_DISCONNECTED=$(gluster peer status | grep -c "Disconnected" || true)
if [ "$PEER_DISCONNECTED" -gt 0 ]; then
    log "ALERT: $PEER_DISCONNECTED peer(s) disconnected"
    echo "Gluster peer disconnected!" | mail -s "GlusterFS Alert" "$ALERT_EMAIL"
fi

# 2. ตรวจสอบ volume status
if ! gluster volume status "$VOLUME" | grep -q "Online: Y"; then
    log "ALERT: Volume $VOLUME has offline brick"
fi

# 3. ตรวจสอบ heal info
HEAL_PENDING=$(gluster volume heal "$VOLUME" info | grep -c "Number of entries: [^0]" || true)
if [ "$HEAL_PENDING" -gt 0 ]; then
    log "WARNING: $HEAL_PENDING brick(s) need healing"
fi

# 4. ตรวจสอบ split-brain
SPLIT_BRAIN=$(gluster volume heal "$VOLUME" info split-brain | grep -c "Number of entries in split-brain: [^0]" || true)
if [ "$SPLIT_BRAIN" -gt 0 ]; then
    log "CRITICAL: Split-brain detected on $VOLUME"
    echo "Split-brain detected!" | mail -s "GlusterFS CRITICAL" "$ALERT_EMAIL"
fi

# 5. ตรวจสอบพื้นที่
USAGE=$(df /mnt/research | tail -1 | awk '{print $5}' | tr -d '%')
if [ "$USAGE" -gt 85 ]; then
    log "WARNING: Volume usage at ${USAGE}%"
fi

log "Health check completed"

12.6 ทางเลือกอื่น

ในยุคปัจจุบันมีระบบจัดเก็บข้อมูลแบบกระจายหลายตัวที่นิยมใช้แทน GlusterFS หรือใช้ร่วมกัน แต่ละตัวมีจุดเด่นต่างกันตาม Use Case

12.6.1 CephFS / RADOS / RBD

Ceph เป็น Software-Defined Storage ที่ออกแบบมาให้รวมความสามารถ 3 อย่าง: Object (RADOS Gateway), Block (RBD), File (CephFS) ในระบบเดียว ใช้ใน OpenStack, Kubernetes (Rook), Proxmox, OpenShift

สถาปัตยกรรม:

MON (Monitor) เก็บ Cluster Map และทำ Quorum (ต้อง odd number, แนะนำ 3-5)
OSD (Object Storage Daemon) เก็บข้อมูลจริง 1 OSD ต่อ 1 disk
MGR (Manager) จัดการ metric และ dashboard
MDS (Metadata Server) เฉพาะ CephFS เก็บ metadata ของไฟล์
RGW (RADOS Gateway) ให้ S3/Swift API

ข้อดี:

รองรับทั้ง 3 รูปแบบ storage
HA โดยธรรมชาติ (no SPOF)
ขยายได้ระดับ Exabyte
ระบบ self-healing และ self-managing

ข้อเสีย:

Complexity สูง ต้องการคนเชี่ยวชาญ
ต้องการ Hardware ค่อนข้างมาก (RAM/CPU/Network)
Latency สูงกว่า Local FS อย่างมีนัยสำคัญ

12.6.2 MinIO และ S3-compatible Object Storage

MinIO เป็น Object Storage แบบ S3-compatible ที่เน้นประสิทธิภาพสูงและ deploy ง่าย ใช้ Erasure Coding และ Bitrot Protection

# ตัวอย่างการ deploy MinIO แบบ standalone
docker run -d -p 9000:9000 -p 9001:9001 \
    --name minio \
    -e "MINIO_ROOT_USER=admin" \
    -e "MINIO_ROOT_PASSWORD=changeMe123" \
    -v /data:/data \
    quay.io/minio/minio server /data --console-address ":9001"

# Distributed mode (4 servers x 4 drives)
minio server http://server{1...4}/data{1...4}

# ใช้กับ aws cli
aws --endpoint-url http://minio:9000 s3 ls
aws --endpoint-url http://minio:9000 s3 mb s3://research-bucket
aws --endpoint-url http://minio:9000 s3 cp file.txt s3://research-bucket/

Use Case:

Backup target (เช่น Restic, BorgBackup, Velero)
Static website hosting
Container Image Registry storage
AI/ML dataset storage
Self-hosted Dropbox alternative

12.6.3 JuiceFS (FUSE + Metadata + Object Store)

JuiceFS เป็นระบบไฟล์รุ่นใหม่ที่แยก Data และ Metadata อย่างชัดเจน:

Metadata เก็บใน Database เช่น Redis, MySQL, PostgreSQL, TiKV
Data เก็บใน Object Storage เช่น S3, MinIO, Ceph RGW

ข้อดี:

POSIX-compliant สมบูรณ์
ใช้ object storage ที่มีอยู่แล้ว
Cache ใน local SSD ได้ ทำให้เร็วเหมือน local
เหมาะกับ AI/ML workload (PyTorch, TensorFlow)

# ติดตั้ง JuiceFS
curl -sSL https://d.juicefs.com/install | sh -

# Format (ครั้งแรก)
juicefs format \
    --storage minio \
    --bucket http://minio:9000/jfs \
    --access-key admin \
    --secret-key changeMe123 \
    redis://:password@redis:6379/1 \
    research-jfs

# Mount
juicefs mount redis://:password@redis:6379/1 /mnt/jfs

# ใช้งานเหมือน local FS
echo "Hello JuiceFS" > /mnt/jfs/test.txt

12.6.4 SeaweedFS

SeaweedFS เน้นจัดการ "ไฟล์เล็กจำนวนมาก" (small file storage) ได้ดีเป็นพิเศษ ออกแบบตามแนวคิด Facebook Haystack paper

สถาปัตยกรรม:

Master Server เก็บ metadata
Volume Server เก็บข้อมูลเป็น volume file
Filer เพิ่ม POSIX semantics ทับ Volume Server
S3 API มี gateway ในตัว

Use Case: Image hosting, log archival, IoT data, ML training set

12.6.5 MooseFS, BeeGFS, Lustre (HPC)

MooseFS Open source DFS คล้าย CephFS แต่ Setup ง่ายกว่า มี Master เดียว (Pro มี HA Master)

BeeGFS (เดิม FhGFS) Distributed Parallel FS ใช้แพร่หลายใน HPC ของยุโรป

Lustre มาตรฐานทองคำของ HPC ใช้ในซูเปอร์คอมพิวเตอร์ Top500 จำนวนมาก สถาปัตยกรรม: MGS (Management), MDS (Metadata), OSS (Object Storage Server)

เปรียบเทียบ HPC FS:

FS	Performance	Setup	Use Case
Lustre	สูงสุด	ซับซ้อน	Top500 supercomputer
BeeGFS	สูง	ปานกลาง	HPC, AI cluster
GPFS (IBM Spectrum Scale)	สูงมาก	ซับซ้อน + Commercial	Enterprise HPC
MooseFS	ปานกลาง	ง่าย	SMB, lab

12.6.6 OpenZFS + iSCSI / NFS export

ZFS เป็น Filesystem + Volume Manager + RAID ในตัว มีคุณสมบัติเด่น:

Snapshot (CoW) ฟรี ไม่กิน space
Compression (lz4, zstd)
Deduplication
Self-healing ผ่าน checksum
Send/Receive สำหรับ replication

# สร้าง pool
sudo zpool create -f tank raidz2 sdb sdc sdd sde sdf

# สร้าง dataset
sudo zfs create tank/research
sudo zfs set compression=zstd tank/research
sudo zfs set quota=500G tank/research

# Snapshot
sudo zfs snapshot tank/research@daily-2026-04-25
sudo zfs list -t snapshot

# Send/Receive ไปยัง DR
sudo zfs send tank/research@daily-2026-04-25 | \
    ssh dr-server zfs receive tank/research-backup

# Export ผ่าน NFS
sudo zfs set sharenfs="rw=@192.168.1.0/24" tank/research

# Export ผ่าน iSCSI (ใช้ targetcli หรือ scstadmin)

12.7 การเปรียบเทียบและการเลือกใช้

ตารางเปรียบเทียบรวมทุกระบบที่กล่าวถึง:

ระบบ	Type	POSIX	HA	Scalability	Latency	Setup	License
SSHFS	Network FS	บางส่วน	❌	❌	สูง	ง่ายมาก	GPL
NFSv4	Network FS	ดี	⚠️ (ต้อง HA setup)	จำกัด	ต่ำ	ง่าย	BSD-like
Samba/SMB	Network FS	ดี	⚠️ (ctdb)	จำกัด	ต่ำ-กลาง	ปานกลาง	GPL
GlusterFS	DFS	ดี	✅	สูง	ปานกลาง	ปานกลาง	GPL
CephFS	DFS	ดี	✅	สูงมาก	กลาง-สูง	ซับซ้อน	LGPL
MinIO	Object	❌	✅	สูงมาก	สูง	ง่าย	AGPL
JuiceFS	DFS (hybrid)	สมบูรณ์	✅	สูง	กลาง (cached)	ปานกลาง	Apache 2.0
SeaweedFS	DFS	ปานกลาง	✅	สูง	ต่ำ (small files)	ง่าย	Apache 2.0
Lustre	Parallel FS	ดี	✅	สูงมาก	ต่ำมาก	ซับซ้อนมาก	GPL
ZFS+NFS	Local + Network	ดี	⚠️	ปานกลาง	ต่ำ	ปานกลาง	CDDL

12.7.1 Performance (latency, throughput, IOPS)

Latency (เวลาตอบสนอง):

Latency = NetworkRTT + ServerProcessing + DiskIO

โดยที่:

NetworkRTT Round-Trip Time ของเครือข่าย (LAN ~0.1-1ms, WAN 10-100ms)
ServerProcessing เวลาที่ Server ใช้ประมวลผล (ขึ้นกับ CPU, scheduler)
DiskIO เวลาเข้าถึงดิสก์ (NVMe ~10μs, SSD ~100μs, HDD 5-10ms)

Throughput (ปริมาณข้อมูลต่อหน่วยเวลา):

Throughput = \min (NetworkBW, \sum DiskBW, CPULimit)

ในระบบ Distributed FS, Throughput สามารถ scale แบบ parallel โดย:

{Throughput}_{total} = N \times {Throughput}_{node} \times η

โดยที่ N คือจำนวน Node และ η คือ efficiency factor (0.6-0.95 ขึ้นกับ workload)

12.7.2 Consistency และ Availability Trade-off

ตารางสรุปคุณสมบัติ CAP ของแต่ละระบบ:

ระบบ	Consistency	Availability	Partition Tolerance	CAP Type
NFSv4	Strong	Medium (single server)	Medium	CP
GlusterFS (replica 3)	Strong (synchronous)	High	High	CP
CephFS	Strong	High	High	CP
MinIO	Strong	High	High	CP
DNS	Eventual	High	High	AP
Cassandra	Eventual/Tunable	High	High	AP
S3 (เดิม)	Eventual	High	High	AP
S3 (2020+)	Strong	High	High	CP

12.7.3 Scalability และ Hardware Requirement

Use Case	ขนาดข้อมูล	Node แนะนำ	Network	Disk
Home Lab	< 10 TB	1-3	1 GbE	HDD/SSD ผสม
Small Business	10-100 TB	3-5	1-10 GbE	RAID + HDD
Mid Enterprise	100 TB - 1 PB	5-20	10-25 GbE	SSD/NVMe
Large Enterprise	1-10 PB	20-100	25-100 GbE	NVMe + RDMA
HPC	10+ PB	100+	InfiniBand HDR	NVMe + Burst Buffer

RAM Requirement (rule of thumb):

{RAM}_{node} = BaseOS + (OSDCount \times 4 GB) + CacheSize

ตัวอย่าง: Ceph node ที่มี 12 OSDs ต้องการ RAM อย่างน้อย 4 + 12×4 + 16 = 68 GB

12.7.4 Complexity และ Operational Cost

จัดอันดับความซับซ้อนจากง่ายไปยาก:

SSHFS (5 นาที setup, no daemon, single command)
ZFS + NFS (1 ชั่วโมง setup, mature tooling)
NFSv4 (1-2 ชั่วโมง setup, well-documented)
Samba (1-2 ชั่วโมง setup, ตั้งค่ายุ่ง)
GlusterFS (1 วัน setup 3-node, ตั้งค่า peer probe + volume)
MinIO (1 ชั่วโมง standalone, 1 วัน distributed)
JuiceFS (1 วัน, ต้องตั้ง metadata DB ด้วย)
CephFS (1 สัปดาห์ + ความเชี่ยวชาญ, แนะนำใช้ cephadm/Rook)
Lustre (1 เดือน + การฝึกอบรม)

ต้นทุนการดำเนินงาน (TCO):

TCO = HardwareCost + SoftwareLicense + OpsTime + PowerCooling + Training

12.7.5 Use Case: Home Lab, Small Business, Enterprise, Cloud-native, HPC

คำแนะนำตาม Use Case:

สถานการณ์	แนะนำ	เหตุผล
เข้าถึง code บน VPS ส่วนตัว	SSHFS	ง่าย, ปลอดภัย, ใช้ SSH ที่มีอยู่
Home NAS (1-2 ผู้ใช้)	TrueNAS + SMB/NFS	GUI ดี, snapshot, replication
ห้อง Lab มหาวิทยาลัย (10-50 ผู้ใช้)	NFSv4 + AutoFS	คุ้นเคย, performance ดี, integrate AD ได้
สำนักงาน Windows-Mac-Linux	Samba + AD	รองรับทุก OS, ใช้ AD auth ได้
Self-hosted cloud (Nextcloud)	NFS + ZFS	reliable, snapshot, performance
AI/ML Training Cluster	JuiceFS + S3, Lustre, BeeGFS	parallel I/O, large file
Kubernetes Persistent Volume	Rook-Ceph, OpenEBS, Longhorn	cloud-native, dynamic provisioning
Backup Target	MinIO, Restic + S3	object storage, immutable
Video editing collaborative	NFSv4 over 10GbE	low latency, shared storage
HPC supercomputer	Lustre, BeeGFS	parallel, low latency, RDMA
Multi-cloud Object	MinIO, Ceph RGW	S3-compatible, portable
Disaster Recovery	ZFS Send/Receive, GlusterFS Geo-rep	async replication

Decision Tree สำหรับการเลือกใช้:

flowchart TD
    Start(["ต้องการ Shared Storage"])
    Q1{"ต้องการ POSIX FS?"}
    Q2{"ทุกเครื่องเป็น Linux?"}
    Q3{"ขนาดข้อมูล?"}
    Q4{"HA สำคัญ?"}
    Q5{"มีหลาย OS?"}
    Q6{"S3 compatible?"}

    Start --> Q1
    Q1 -->|"ไม่ (Object OK)"| Q6
    Q1 -->|"ใช่"| Q2
    Q2 -->|"ใช่"| Q3
    Q2 -->|"ไม่"| Q5

    Q3 -->|"< 10TB"| NFS["NFSv4 + ZFS
หรือ TrueNAS"]
    Q3 -->|"10TB - 1PB"| Q4
    Q3 -->|"> 1PB / HPC"| LUSTRE["Lustre /
BeeGFS"]

    Q4 -->|"ใช่"| GLUSTER["GlusterFS
หรือ CephFS"]
    Q4 -->|"ไม่ (single server OK)"| NFS_HA["NFS + DRBD"]

    Q5 -->|"Win + Mac + Linux"| SAMBA["Samba (SMB3)"]

    Q6 -->|"ใช่"| MINIO["MinIO /
Ceph RGW"]
    Q6 -->|"ไม่"| Q7{"ต้องการ POSIX cache?"}
    Q7 -->|"ใช่"| JUICE["JuiceFS"]
    Q7 -->|"ไม่"| SW["SeaweedFS"]

    style Start fill:#d79921,stroke:#fabd2f,color:#1d2021
    style NFS fill:#458588,stroke:#83a598,color:#fbf1c7
    style GLUSTER fill:#cc241d,stroke:#fb4934,color:#fbf1c7
    style SAMBA fill:#98971a,stroke:#b8bb26,color:#fbf1c7
    style MINIO fill:#689d6a,stroke:#8ec07c,color:#fbf1c7
    style LUSTRE fill:#b16286,stroke:#d3869b,color:#fbf1c7
    style JUICE fill:#d65d0e,stroke:#fe8019,color:#fbf1c7

สรุปสุดท้าย: การเลือกระบบไฟล์เครือข่ายและแบบกระจายควรพิจารณา 5 ปัจจัยหลัก ได้แก่ ขนาดและประเภทของข้อมูล (Data Profile), ความต้องการ POSIX semantics, ระดับ HA ที่ต้องการ, ความเชี่ยวชาญของทีมงาน (Operational Expertise) และงบประมาณ (Budget) โดยในทางปฏิบัติ มักจะใช้หลายระบบผสมกัน เช่น NFSv4 สำหรับ home directory, MinIO สำหรับ backup, GlusterFS สำหรับ application data และ ZFS local สำหรับ database ทำให้เกิด Storage Tiering ที่เหมาะกับแต่ละ workload และให้ผลลัพธ์ทั้งด้านประสิทธิภาพและต้นทุนที่ดีที่สุด

12. Distributed and Network File System (sshfs, NFS, GlusterFS)

12.1 แนวคิดของ Distributed และ Network File System

12.1.1 Local FS vs Network FS vs Distributed FS vs Object Storage

12.1.2 POSIX Semantics

12.1.3 CAP Theorem (Consistency, Availability, Partition Tolerance)

12.1.4 Consistency Model: Strong, Eventual, Causal

12.1.5 ประโยชน์: Shared Storage, Scalability, High Availability, DR

12.2 SSHFS (SSH File System)

12.2.1 สถาปัตยกรรม FUSE-based

12.2.2 การติดตั้ง sshfs และ Dependency (fuse)

12.2.3 การ mount: sshfs user@host:/remote /local

12.2.4 Option สำคัญ: reconnect, ServerAliveInterval, allow_other, uid, gid, cache

12.2.5 การ unmount (fusermount -u / umount)

12.2.6 ข้อดี-ข้อเสียและ Use Case

12.3 NFS (Network File System)

12.3.1 ประวัติและ Version: NFSv3, NFSv4, NFSv4.1 (pNFS), NFSv4.2

12.3.2 สถาปัตยกรรม: rpcbind, nfsd, mountd, lockd

12.3.3 NFS Server Setup (nfs-utils / nfs-kernel-server)

12.3.4 ไฟล์ /etc/exports และ Option

12.3.5 คำสั่ง exportfs (-a, -r, -v)

12.3.6 NFS Client: showmount, mount -t nfs

12.3.7 การตั้งค่าถาวรใน /etc/fstab

12.3.8 UID/GID Mapping และ idmapd

12.3.9 Performance Tuning (rsize, wsize, async)

12.3.10 Security: NFSv4 with Kerberos

12.4 SMB/CIFS (Samba)

12.4.1 ใช้งานร่วมกับ Windows และ macOS

12.4.2 smb.conf เบื้องต้น (global, share)

12.4.3 smbpasswd และ User Management

12.4.4 cifs-utils, smbclient, mount.cifs

12.4.5 SMB Version (SMB1 vs SMB2 vs SMB3)

12.5 GlusterFS

12.5.1 สถาปัตยกรรม: Node, Brick, Volume, Trusted Storage Pool

12.5.2 ประเภท Volume

12.5.3 การติดตั้ง glusterd และ Peer Probe

12.5.4 การสร้าง Volume

12.5.5 การ Mount บน Client

12.5.6 Self-heal และ Rebalance

12.5.7 การขยาย (add-brick) และลด (remove-brick) Volume

12.5.8 Geo-replication สำหรับ DR

12.5.9 Quota และ Snapshot

12.5.10 Monitoring (gluster top, profile)

12.6 ทางเลือกอื่น

12.6.1 CephFS / RADOS / RBD

12.6.2 MinIO และ S3-compatible Object Storage

12.6.3 JuiceFS (FUSE + Metadata + Object Store)

12.6.4 SeaweedFS

12.6.5 MooseFS, BeeGFS, Lustre (HPC)

12.6.6 OpenZFS + iSCSI / NFS export

12.7 การเปรียบเทียบและการเลือกใช้

12.7.1 Performance (latency, throughput, IOPS)

12.7.2 Consistency และ Availability Trade-off

12.7.3 Scalability และ Hardware Requirement

12.7.4 Complexity และ Operational Cost

12.7.5 Use Case: Home Lab, Small Business, Enterprise, Cloud-native, HPC

12.2.3 การ mount: `sshfs user@host:/remote /local`