Distributed File Systems

1คุณสมบัติที่ File Service ต้องมี

2กรณีศึกษา: NFS (Network File System)

Client: /usr/staff (mount point)
             |
           [VFS]
             |
     NFS Protocol (RPC)
             |
Server 2: /export/people (ไดเรกทอรีจริง)

NFS Server เป็น Stateless Protocol

Caching และปัญหา Consistency

เพื่อประสิทธิภาพ NFS client จะ cache ข้อมูลไฟล์ไว้ท้องถิ่น — แต่ก็เกิดคำถามว่า cache นั้น "เก่า" หรือยังถูกต้อง client ตรวจสอบด้วยการเทียบ timestamp ของไฟล์ที่ server กับที่ cache ไว้ ถ้า server มี timestamp ใหม่กว่า cache จะถูก invalidate

3กรณีศึกษา: AFS (Andrew File System)

4ทันสมัย: จาก NFS/AFS สู่ Big Data Storage และ Object Storage

5File Abstraction ซ่อนอะไรไว้บ้าง

ผู้ใช้เห็นชื่อ path, byte sequence, directory และ operation เช่น open/read/write/close แต่ distributed file system ต้องแปลงสิ่งเหล่านี้เป็น metadata lookup, permission check, cache, network request, block/object placement และ recovery ความเรียบง่ายของไฟล์จึงเป็น abstraction ที่มีระบบขนาดใหญ่อยู่ข้างใต้

File Service Model

แยก flat file service จัด content ตาม file ID, directory service map ชื่อไป file ID และ client module ให้ API เหมือน local file การแยกนี้ทำให้ rename path ไม่ต้องย้าย content และ file handle ไม่จำเป็นต้องฝัง path ซึ่งอาจเปลี่ยน

Stateful กับ Stateless Server

Stateful server จำ open file, offset, lock และ session ทำ operation กระชับ/semantic ใกล้ local แต่ failover/recovery ต้องกู้ state Stateless server ให้ request มี file handle, offset, length ครบ ทำ retry/failoverง่ายกว่าแต่ token/request ใหญ่และ operation บางแบบต้องสร้าง state เพิ่ม

6File Identifier และ Handle ที่ไม่พังเมื่อ Rename

ถ้า handle ใช้ path ตรง การ rename directory ทำ open handle ทั้งหมดเสีย ระบบจึงใช้ opaque file handle ที่รวม filesystem ID, file ID/inode และ generation number Generation ป้องกัน stale handle เมื่อ inode number ถูก reuse หลังลบไฟล์

Opaque หมายถึง client ไม่ควรตีความ field เอง Server ตรวจ authenticity/validity ได้ ถ้า handle เดา/แก้ได้ ผู้ใช้ข้าม permission หรือเข้าถึงไฟล์อื่น Security ต้องผูก credential กับ request ไม่ถือว่ามี handle แปลว่ามีสิทธิ์ตลอดไป

7Semantics ของการแชร์ไฟล์

เมื่อสอง client เปิดไฟล์เดียวกัน คำถามคือ write ของคนหนึ่งมองเห็นเมื่อใด Local UNIX มักให้ read เห็น write ตามลำดับระบบใกล้เคียงกัน แต่ cache แบบกระจายทำ guarantee นี้แพง จึงมี session semantics, immutable-file semantics หรือ explicit consistency model

คำว่า “ไฟล์เดียวกัน” จึงยังไม่บอกว่าผู้ใช้สองคนเห็น byte เดียวกัน ณ ทุกเวลา Application ต้องรู้ semantics โดยเฉพาะ lock file, configuration และงานที่หลาย worker append/rename พร้อมกัน

Close-to-Open Consistency

NFS สมัยใหม่มักพยายามให้เมื่อ client A close หลังเขียน แล้ว client B open ภายหลัง B เห็นข้อมูลใหม่ แต่ client ที่เปิดค้างอาจ cache ต่อ และเวลาตรวจ attribute มีผล เป็น compromise ระหว่าง UNIX semantics กับ performance

8Caching: อ่านเร็วขึ้นด้วยการยอมมีความจริงหลายสำเนา

Cache ได้หลายชั้น: application, page cache, client disk/memory, gateway, server buffer และ storage controller ทุกชั้นลด latency/network แต่เพิ่มคำถาม invalidation, durability และ observability ผู้ใช้เรียก write success อาจหมายถึงถึง client cache, server memory หรือ disk แล้วต่างกัน

Polling, Callback และ Lease

Polling ให้ client ถาม metadata เป็นระยะ ง่ายและทน callback หายแต่มี stale window/query load Callback ให้ server แจ้ง invalidate ลด stale/traffic แต่ server ต้องจำ client และ recovery เมื่อ callback state หาย Lease ให้ callback/permission มีอายุจำกัด หลังหมดต้อง renew จึงจำกัด stale state แม้ message invalidate หาย

False Sharing และ Small Write

ถ้า cache เป็น block/whole file ผู้ใช้แก้คนละช่วงแต่ invalidation ทั้งก้อน ทำให้ ping-pong cache Workload ที่หลาย client เขียนไฟล์เดียวจึงไม่เหมาะกับ whole-file caching อาจต้องแบ่ง object/log/partition ใหม่แทน tuning TTL

9NFS: Stateless เริ่มต้นและวิวัฒนาการ

NFS รุ่นแรกใช้ RPC และ stateless server Client ส่ง file handle, offset, count ในแต่ละ request ทำให้ server restart แล้ว client retry ได้โดยไม่ reopen session Operation ต้องออกแบบ idempotent หรือมี duplicate request handling เช่น write ที่ offset เดิมด้วย data เดิม

อย่างไรก็ตาม file locking, exactly-once-like behavior และ performance ทำให้รุ่นหลังเพิ่ม state NFSv4 รวม protocol, stateful open/lock, lease, compound operation และ security ดีขึ้น บทเรียนคือ stateless/stateful ไม่ใช่ศาสนา ระบบวิวัฒนาการตาม semantics ที่ต้องให้

Mount และ Namespace

Mount protocol ทำ remote filesystem ปรากฏใน local namespace Client อาจเห็นโครงต่างกันตาม mount config จึงไม่มี global namespace เดียวโดยธรรมชาติ Automount ลด dependency ตอน boot แต่ lookup ครั้งแรกมี latency/failure เพิ่ม

At-least-once RPC กับ File Operation

Read ที่ offset เดิม idempotentถ้า file versionไม่เปลี่ยน แต่ CREATE ที่สร้างชื่อใหม่หรือ REMOVE ต้องรับ duplicate/response loss Protocol ใช้ transaction ID/cache reply หรือกำหนด operation semantics เพื่อไม่สร้างผลซ้ำ การ retry network call ผูกกับ file consistency และ concurrent change จึงไม่ง่ายเท่ารันคำสั่งเดิม

10AFS: Whole-File Cache และ Callback

AFS ออกแบบเพื่อมหาวิทยาลัยที่มี client จำนวนมากและ workload อ่านมาก เปิด/ปิดไฟล์ไม่ถี่ ใช้ whole-file caching บน local disk และ callback จาก server เมื่อไฟล์ถูกแก้ ลด server load และ network หลัง cache warm

Session semantics ทำให้ write ของ client แพร่ตอน close หากสอง client แก้พร้อมกันอาจ last-close-wins หรือ conflict ตาม implementation จึงไม่เหมาะ database file หรือ shared-write heavy workload ความสำเร็จของ AFS มาจาก fit กับ workload ไม่ใช่ whole-file cache ดีทุกกรณี

11Metadata กับ Data Path

Distributed filesystem สมัยใหม่มักแยก metadata service (namespace, permission, mapping) จาก data server ที่เก็บ block/chunk Client ถาม metadata แล้วอ่าน data ตรง ลดคอขวด แต่ metadata ยังเป็นจุดสำคัญต่อ create/rename/list และต้อง replicate/partition

Small Files Problem

ถ้าไฟล์เล็กจำนวนมาก metadata operation และ inode/object overhead ครองต้นทุน ระบบที่เหมาะไฟล์ใหญ่แบบ HDFS อาจทำงานแย่กับไฟล์ล้านไฟล์ขนาด KB แนวทางคือรวมเป็น container/sequence file, database/object store ที่เหมาะ หรือ partition metadata ไม่ใช่เพียงเพิ่ม data node

12GFS/HDFS: ออกแบบจาก Workload ไม่เลียนแบบ Local Disk

GFS/HDFS สมมุติ commodity failure, ไฟล์ใหญ่มาก, streaming read และ append มากกว่า random overwrite ใช้ chunk/block ใหญ่ metadata กลาง และ replication หลาย node การลด POSIX semantics บางส่วนช่วย throughput/scale เพราะไม่ต้องประสานทุก small update แบบ filesystem ทั่วไป

Replica Placement และ Rack Awareness

สามสำเนาบน rack เดียวไม่ทน rack failure ระบบกระจาย replica ข้าม failure domain แต่ให้บางสำเนาใกล้ writer/read เพื่อ performance ต้องสมดุล durability กับ cross-rack bandwidth และ capacity skew เมื่อ node เสีย re-replication สร้าง traffic สูง จึง throttle ไม่ให้ recovery ทำระบบล่มซ้ำ

13Ceph และการคำนวณตำแหน่งแทน Lookup กลาง

Ceph ใช้ CRUSH map คำนวณ object placement จาก topology/failure domain ลด central lookup สำหรับทุก object Client/OSD รู้ cluster map version และคำนวณตำแหน่งได้ เมื่อ membership เปลี่ยน map ใหม่ทำให้ย้ายข้อมูลบางส่วน

นี่เชื่อม Naming กับ placement: object ID resolve ผ่านฟังก์ชันและ versioned topology ไม่ใช่ directory lookup ทีละ object แต่ stale map ยังต้อง redirect/refresh และ rebalancing มีต้นทุน network

14Object Storage ไม่ใช่ Filesystem ที่เปลี่ยนชื่อ API

Object store ใช้ bucket/key/object ไม่มี open file descriptor และ random byte update แบบ POSIX โดยทั่วไป operation คือ PUT/GET/DELETE object ทั้งก้อน Metadata/HTTP API และ massive flat namespace ทำให้ scale/geo access ดี แต่ rename directory อาจเป็น copy+delete เพราะ key เป็นชื่อ object

Consistency ของ Object Store

ระบบเก่าหลายแห่งให้ eventual consistency บาง operation แต่บริการปัจจุบันบางรายให้ strong read-after-write/list ภายใน region ต้องอ่าน contract ปัจจุบัน ไม่ใช้ stereotype ว่า object store eventual เสมอ ถึง strong metadata consistency ก็ยังมี CDN/client cache และ cross-region replication lag อีกชั้น

Multipart Upload และ Orphan

ไฟล์ใหญ่แบ่ง part upload ขนานแล้ว complete หาก client หาย part ค้างกินพื้นที่ ต้อง lifecycle cleanup ETag อาจไม่ใช่ MD5 ใน multipart/encryption จึงไม่ควรตีความเป็น content hash โดยไม่อ่าน semantics

15Durability, Availability และ Backup เป็นคนละเรื่อง

Replication ช่วยเมื่อ disk/node เสียและเพิ่ม availability แต่ถ้าผู้ใช้ลบผิดหรือ ransomware เขียนทับ replica ทุกตัวอาจทำตามอย่างถูกต้อง Backup/versioning/immutable retention ช่วยย้อนเวลา Durability บอกโอกาสข้อมูลไม่สูญ Availability บอกเข้าถึงได้ตอนนี้ ทั้งสองไม่เท่ากับ correctness หรือ backup

Checksums และ Silent Corruption

Disk/network อาจคืน byte ผิดโดยไม่ crash End-to-end checksum ต่อ block/object ตรวจ corruption แล้วอ่าน replica อื่น/repair แต่ถ้า application ส่งข้อมูลผิดพร้อม checksum ที่ถูก storage ไม่รู้ ต้องมี validation ในแต่ละขอบเขตและ scrubbing ตรวจข้อมูลที่ไม่ถูกอ่านนาน

16Locking และ Concurrent Write ใน File System

Advisory lock ทำงานเมื่อ application ทุกตัวร่วมมือ Mandatory lock บังคับโดยระบบแต่มี portability/semantics ต่าง Network partition และ client crash ทำ lock ค้าง จึงใช้ lease/lock reclaim และ fencing token ในระบบที่ resource ภายนอกต้องปฏิเสธ writer เก่า

การแก้ไฟล์ร่วมแบบ collaboration มักไม่ใช้ byte-range lock ตลอด session แต่ใช้ operation log, version, OT/CRDT หรือ merge เพราะผู้ใช้ออฟไลน์และ conflict เชิงความหมาย Lock เป็นเครื่องมือหนึ่ง ไม่ใช่คำตอบทุก shared document

17Performance: อ่านคำว่า Throughput ให้ครบเส้นทาง

ประสิทธิภาพขึ้นกับ metadata lookup, cache hit, network, serialization, block size, disk, replication acknowledgment และ queue งาน sequential ใหญ่ได้ throughput สูง แต่งาน random small files ติด metadata/IOPS แม้ bandwidth เหลือ

Tail Latency และ Fan-out

อ่านไฟล์กระจายหลาย chunk พร้อมกันเสร็จเมื่อ chunk ช้าที่สุดเสร็จ ยิ่ง fan-out มากโอกาสเจอ slow node สูง ระบบใช้ speculative read/hedged request บางกรณีแต่เพิ่ม load ต้องควบคุมและยกเลิกสำเนา

18Failure Scenarios ที่ต้องซ้อม

19Workshop: เปรียบเทียบ Cache Semantics

1. ใช้ shared filesystem หรือจำลอง server/client สองตัว เปิดไฟล์เดียวกัน
2. ให้ A เขียนโดยไม่ close/fsync แล้ว B อ่าน บันทึกสิ่งที่เห็น
3. close แล้วอ่านใหม่ แยก close-to-open จาก open handle เดิม
4. ตัด network ระหว่าง dirty write แล้ว reconnect ดู conflict/retry
5. แก้ไฟล์พร้อมกันสอง client ทดสอบ last-writer/last-close behavior
6. วัด cold cache กับ warm cache ทั้ง latency และ network bytes
7. ทำ server restart ตรวจ handle, lock และ retry
8. ทดสอบไฟล์ใหญ่หนึ่งไฟล์เทียบไฟล์เล็กจำนวนมาก

20แนวทางเลือก Storage จาก Semantics ก่อนชื่อผลิตภัณฑ์

1. ต้องการ POSIX/random update หรือ object API พอ
2. ไฟล์เล็ก/ใหญ่ จำนวนเท่าใด read/write/append pattern อย่างไร
3. ผู้เขียนพร้อมกันกี่คนและต้องเห็น write เมื่อใด
4. durability, RPO, RTO และ failure domain คืออะไร
5. metadata operation/list/rename สำคัญแค่ไหน
6. compute อยู่ใกล้ data หรือข้าม region/Internet
7. ต้อง version, retention, audit และ encryption/key control อย่างไร
8. ทีมดูแล restore/rebalance/upgrade ได้มากน้อยเพียงใด

อย่าเลือก HDFS เพราะข้อมูลเรียกว่า Big Data หรือเลือก object store เพราะ scale ได้สูงถ้า application ต้อง random update และ rename atomic บ่อย เทคโนโลยีที่ดีใน workload หนึ่งอาจเป็น abstraction ที่ฝืนในอีก workload การแปลง API ด้วย gateway ไม่ได้ทำให้ semantics เปลี่ยนตาม

21ทบทวนแกนสำคัญก่อนกรณีศึกษา

Distributed File System ทำให้ namespace และ file API ที่คุ้นเคยทำงานข้าม network แต่ต้องตัดสิน stateful/stateless, handle identity, cache consistency, write visibility, durability และ failure recovery NFS กับ AFS เลือก trade-off ตาม workload ต่างกัน จึงเป็นกรณีศึกษาวิธีออกแบบมากกว่ารายชื่อระบบเก่า

ระบบข้อมูลขนาดใหญ่ยอมลด POSIX semantics บางส่วนเพื่อ block ใหญ่, streaming และ replication ส่วน object storage เปลี่ยน abstraction เป็น immutable-ish object ผ่าน API ทำให้ scale มหาศาลแต่ random update/rename มีความหมายต่าง Replication ไม่ใช่ backup และ cache freshness ไม่ได้ฟรี

ขั้นตอนถัดไปคือ Replication เราจะยกสำเนาที่แฝงอยู่ใน cache/file systemขึ้นมาเป็นหัวข้อหลัก ว่าจะวาง replica ที่ไหน เลือก primary/quorum อย่างไร รับมือ concurrent update และกำหนด consistency model ที่ applicationเข้าใจได้อย่างไร

22กรณีศึกษา: Write ตอบสำเร็จแล้วไฟดับ

Client เขียนไฟล์และได้รับ success แต่ข้อมูลอาจอยู่เพียง client cache, server page cache, controller cache หรือ replicated storage ระดับใดระดับหนึ่ง ถ้าไฟดับทันที ผลขึ้นกับ write policy, fsync semantics, battery-backed cache และ replication acknowledgment คำว่า success ต้องมี durability contract

Application ที่เขียน temp file, fsync, atomic rename เพื่อ publish config ต้องรู้ว่า directory metadata ต้อง sync หรือไม่ตาม filesystem หากใช้ object store PUT ใหม่ atomic ต่อ object แต่อัปเดต pointer/latest เป็น operation อีกตัว อาจมีช่วง version ใหม่อยู่แต่ยังไม่มีใครอ้างถึง หรือ pointer ชี้ก่อน objectพร้อมหากลำดับผิด

23กรณีศึกษา: Metadata Server เป็นคอขวด

Cluster มี data node จำนวนมากแต่ workload สร้าง/ลบไฟล์เล็กหลายล้านไฟล์ Throughput ไม่เพิ่มเมื่อเพิ่ม data node เพราะทุก create/list/stat ไป metadata leader ตัวเดียว Queue metadata สูง ขณะที่ disk bandwidth ว่าง นี่คือ scalability limit จาก workload decomposition ไม่ใช่ storage capacity

ทางเลือกคือ partition namespace, cache metadata, batch operation, รวม small files, เปลี่ยน abstraction เป็น object/database หรือเพิ่ม metadata replicas สำหรับ read แต่ write/rename ข้าม partition ยังต้อง coordination การเพิ่มเครื่องในชั้นผิดไม่ช่วย

24กรณีศึกษา: Split-Brain Writer

Network แบ่ง cluster เป็นสองฝั่ง ทั้งคู่คิดว่า metadata leader อีกฝั่งตายและยอม write ไฟล์เดียวกัน เมื่อ network กลับมาไม่มีวิธีรวม byte overwrite อย่างทั่วไป ต้องใช้ quorum/consensus ให้มี writer เดียว หรือ fencing epoch ที่ data node ปฏิเสธ leader token เก่า การเน้น availability ทั้งสองฝั่งเปลี่ยน semantics เป็น conflict/merge ซึ่ง applicationต้องรองรับ

25Storage Decision Record

ก่อนเลือก filesystem/object store ให้เขียน decision record ที่วัดได้ ไม่ใช่รายการ feature การ์ดโฆษณา

26Workshop เพิ่มเติม: Durability และ Recovery

1. เขียนไฟล์โดยไม่ fsync แล้ว kill process/จำลอง restart เปรียบเทียบ
2. เขียน temp+fsync+rename และตรวจ atomic visibility
3. ทำ checksum ของ block แล้วแก้ byte จำลอง corruption
4. มี replica สองชุด ทำหนึ่งชุด corrupt แล้ว repair
5. ลบไฟล์โดยผู้ใช้และพิสูจน์ว่า replication ลบตาม จากนั้น restore backup/version
6. วัด restore 1 file, 1 TB และทั้ง namespace เพื่อแยก backup มีอยู่จากกู้ทัน RTO
7. ทำ metadata unavailable แต่ data node ยังอยู่ ตรวจ operation ใดทำได้
8. จำลอง node กลับมาพร้อม state เก่าและใช้ epoch/map version ป้องกัน

27คำถามทบทวนที่เชื่อมหลายแนวคิด

1. เหตุใด stateless server recovery ง่ายขึ้น แต่ file locking ยังต้อง state
2. file handle ที่ดีแยก identity จาก path/location อย่างไร
3. session semantics ต่างจาก UNIX semantics ตรง visibility ใด
4. callback ลด polling แต่เพิ่ม state/failure recovery อย่างไร
5. เหตุใด whole-file cache เหมาะ AFS workload แต่ไม่เหมาะ database file
6. HDFS ลด POSIX semantics ใดเพื่อ throughput/scale
7. object key prefix ดูเหมือน directory แต่ rename ต่างอย่างไร
8. replication, erasure coding, snapshot และ backup ป้องกัน failure คนละชนิดอย่างไร
9. ทำไม p99 ของ read หลาย chunk ถูกกำหนดโดย slowest component
10. เพิ่ม data node แล้ว metadata workload ไม่เร็วขึ้นเพราะอะไร
11. network partition บังคับให้เลือก write availability กับ single-writer semantics อย่างไร
12. strong consistency ของ object store ยังไม่ลบ CDN/client cache stalenessอย่างไร

28Checklist สำหรับระบบไฟล์ที่ใช้งานจริง

• นิยาม success ของ write, close และ fsync ชัด
• ระบุ cache layer และ invalidation/lease ทุกชั้น
• file handle มี generation ป้องกัน stale reuse
• ทดสอบ concurrent writer และ rename/delete ระหว่าง open
• วัด metadata ops แยกจาก data throughput
• วาง replica ข้าม failure domain ไม่เพียงคนละ process
• มี checksum/scrubbing และ repair ที่ตรวจสอบได้
• backup แยก credential/failure domain และทดสอบ restore
• ควบคุม recovery traffic ไม่ให้กระทบ foregroundจนล้ม
• monitor capacity, inode/object count, lag, bloat, error และ tail latency
• มี quota/lifecycle ป้องกัน orphan multipart/temp/snapshot โตไม่สิ้นสุด
• เขียน consistency semantics ให้ application teamเข้าใจ ไม่ใช้คำว่า shared drive อย่างเดียว

29คำศัพท์ Storage ที่ควรแยกให้ชัด

การบอกว่า “เก็บสามสำเนาจึงปลอดภัย” ยังขาดคำถามว่าสามสำเนาอยู่ failure domain ใด ใช้ credential เดียวกันหรือไม่ ข้อมูล corrupt/delete ถูก replicate หรือไม่ และ restore ทั้ง namespace ใช้เวลาเท่าใด Storage design จึงต้องผูก guarantee กับ failure model ไม่ใช่จำนวนสำเนาอย่างเดียว

30คำถามปิดท้าย: ถ้า Abstraction รั่ว ผู้ใช้ต้องรู้อะไร

ผู้ใช้ไม่ควรต้องรู้ block placement ทุกชิ้น แต่ควรรู้ semantics ที่เปลี่ยน correctness: write สำเร็จ durable ถึงไหน client อื่นเห็นเมื่อใด concurrent write ชนะอย่างไร และ backup ย้อนกลับได้ถึงจุดใด นี่คือเส้นแบ่งระหว่างซ่อน implementation กับซ่อนข้อแลกเปลี่ยนจน application ตัดสินใจไม่ได้

เอกสาร API/operation runbook จึงควรมี consistency, durability, size/rate limits, retry/idempotency และ failure behavior ไม่ใช่เพียง mount path หรือ SDK method การใช้ filesystem interface ที่คุ้นเคยไม่ได้ทำให้ remote storage มีคุณสมบัติเท่า local diskทุกข้อ

31สรุปและขั้นตอนถัดไป

Distributed File System ทำให้ path, handle และ byte stream ที่คุ้นเคยทำงานข้าม network แต่ต้องกำหนด stateful/stateless behavior, cache visibility, write durability และ recovery ให้ชัด NFS กับ AFS จึงมีคุณค่าในฐานะตัวอย่างของการเลือก semantics ให้เหมาะ workload ไม่ใช่เพียงระบบเก่าที่ต้องจำชื่อ

ระบบอย่าง HDFS ยอมลด POSIX semantics เพื่อไฟล์ใหญ่และ streaming ส่วน object storage เปลี่ยน abstraction เป็น object API เพื่อ scale และ durability สูง Replication, erasure coding, snapshot และ backup ป้องกัน failure คนละชนิด การมีหลายสำเนาไม่ได้แปลว่าย้อน logical deletion หรือ ransomware ได้

ขั้นตอนถัดไปคือ Replication เราจะขยายจากสำเนา block/file ไปสู่หลักทั่วไปว่า replica รับ update อย่างไร เลือก primary/quorum แบบใด และ application ยอมเห็นข้อมูลเก่า/conflict ได้เพียงใด ประสิทธิภาพที่ได้จากสำเนามาพร้อม coordination และ repair ซึ่งต้องนับเป็นต้นทุนของระบบด้วย