การใช้งาน NVMe-oF: การแยกสถาปัตยกรรม Storage สำหรับการติดตั้ง GPU 100,000 ตัว

อัปเดตเมื่อวันที่ 8 ธันวาคม 2025

อัปเดตธันวาคม 2025: การนำ NVMe-oF มาใช้กำลังเร่งตัวขึ้นพร้อมกับไดรฟ์ PCIe Gen5 ที่ให้ความเร็ว 14GB/s และ Fabric 400GbE ที่กำลังกลายเป็นมาตรฐาน ข้อกำหนด NVMe 2.0 ได้รับการรับรองแล้วพร้อมการรองรับ multi-path และ zoned namespace ที่ดีขึ้น NVIDIA BlueField-3 DPUs ช่วยให้ NVMe-oF ทำงานด้วยการเร่งความเร็วระดับฮาร์ดแวร์ที่ throughput 400Gb/s Computational storage กำลังเกิดขึ้นสำหรับการประมวลผลข้อมูลล่วงหน้าก่อนถ่ายโอนไปยัง GPU ซึ่งลดความต้องการ bandwidth ลง 40-60% สำหรับ workload เฉพาะบางประเภท

Recommendation engine ของ ByteDance ครอบคลุม GPU 100,000 ตัวใน 12 data center แต่สามารถใช้งาน storage ได้ถึง 94% ผ่านเทคโนโลยี NVMe over Fabric ที่รวม flash storage 85 petabyte เป็น namespace เดียวที่ GPU ใดก็เข้าถึงได้ด้วย throughput 180GB/s และ latency 5 ไมโครวินาที¹ ก่อนหน้านี้บริษัทเทคโนโลยีจีนแห่งนี้จัดสรร storage แบบตายตัวให้กับเซิร์ฟเวอร์ GPU แต่ละตัว ทำให้มีความจุว่างเปล่า 40% ในขณะที่โหนดอื่นขาดแคลนพื้นที่ สถาปัตยกรรม NVMe-oF ของพวกเขาตอนนี้จัดสรร storage block ให้กับ GPU ตามความต้องการแบบไดนามิก ขจัดค่าใช้จ่ายการซื้อ SSD ซ้ำซ้อนมูลค่า 42 ล้านดอลลาร์ ในขณะที่เพิ่มความเร็วการ train โมเดลขึ้น 2.3 เท่าผ่านการจัดวางข้อมูลที่เหมาะสม สถาปัตยกรรม direct-attached storage แบบดั้งเดิมล้มเหลวในระดับ hyperscale—เมื่อจัดการ GPU 100,000 ตัว ความสามารถในการแยก storage ออกจาก compute คือความแตกต่างระหว่างการขยายแบบเชิงเส้นกับความซับซ้อนแบบเอกซ์โพเนนเชียล

NVMe over Fabric ขยายโปรโตคอล NVMe ข้าม network fabric ทำให้สามารถเข้าถึง storage ระยะไกลด้วยประสิทธิภาพใกล้เคียงกับ local องค์กรที่ใช้งาน NVMe-oF รายงานการใช้งาน storage 85-95% เทียบกับ 50-60% สำหรับการกำหนดค่าแบบ direct-attached ในขณะที่รักษา latency ต่ำกว่า 10 ไมโครวินาที² เทคโนโลยีนี้รองรับโปรโตคอล transport หลายตัว รวมถึง RDMA over Converged Ethernet (RoCE), InfiniBand, Fibre Channel และ TCP โดยการติดตั้ง RoCE ครองตลาดโครงสร้างพื้นฐาน AI เนื่องจาก Ethernet มีใช้งานอยู่แพร่หลาย สถาปัตยกรรม storage แบบ disaggregated ลดค่าใช้จ่ายด้านทุน 35-45% ผ่านการใช้งานที่ดีขึ้น ทำให้สามารถขยาย compute และ storage resources อย่างอิสระ และให้ความยืดหยุ่นในการดำเนินงานที่เป็นไปไม่ได้กับสถาปัตยกรรมแบบดั้งเดิม

พื้นฐานโปรโตคอล NVMe-oF

NVMe over Fabric รักษาประสิทธิภาพของโปรโตคอล NVMe ในขณะที่ขยายไปยัง network transport ต่างๆ โปรโตคอลนี้รักษาชุดคำสั่งที่กระชับของ NVMe สถาปัตยกรรม queue แบบขนาน และโมเดล interrupt-driven ในขณะที่เพิ่ม overhead เพียงเล็กน้อยสำหรับ network transport การทำธุรกรรม NVMe-oF โดยทั่วไปเพิ่ม latency เพียง 2-8 ไมโครวินาทีเมื่อเทียบกับ local NVMe ให้ประสิทธิภาพ 95% ของ SSD ภายในเครื่องผ่านเครือข่ายที่กำหนดค่าอย่างเหมาะสม³

ตัวเลือก transport กำหนดลักษณะประสิทธิภาพและความซับซ้อนในการติดตั้ง:

NVMe over RoCE v2 ครองการติดตั้งระดับองค์กรเนื่องจากใช้โครงสร้างพื้นฐาน Ethernet ที่มีอยู่ได้ RoCE (RDMA over Converged Ethernet) ให้ kernel bypass และ zero-copy transfer ทำให้ latency ต่ำกว่า 5 ไมโครวินาที การกำหนดค่า lossless Ethernet โดยใช้ Priority Flow Control ป้องกันการสูญเสียแพ็กเก็ต Ethernet switch มาตรฐานรองรับ RoCE ด้วย firmware ที่เหมาะสม การติดตั้งต้องมีการปรับแต่ง Quality of Service อย่างระมัดระวังเพื่อป้องกันความแออัด

NVMe over InfiniBand ให้ latency ต่ำที่สุดที่ 2-3 ไมโครวินาที แต่ต้องการโครงสร้างพื้นฐานเฉพาะทาง การควบคุมการไหลแบบ credit-based ของ InfiniBand รับประกันการส่งแบบ lossless โดยไม่มีความซับซ้อนของ PFC การจัดการความแออัดในตัวป้องกันการลดลงของประสิทธิภาพภายใต้โหลด ค่าใช้จ่ายที่สูงขึ้นจำกัดการนำไปใช้กับการติดตั้งที่ต้องการประสิทธิภาพสูง รองรับ GPU Direct Storage แบบ native เพื่อเพิ่ม throughput สูงสุด

NVMe over TCP ให้ความเข้ากันได้สูงสุดโดยใช้เครือข่าย TCP/IP มาตรฐาน การใช้งานเป็นซอฟต์แวร์เท่านั้นไม่ต้องใช้ฮาร์ดแวร์พิเศษ Latency อยู่ในช่วง 15-50 ไมโครวินาทีขึ้นอยู่กับสภาพเครือข่าย การควบคุมความแออัดและการส่งซ้ำของ TCP เพิ่ม overhead เหมาะสำหรับ storage tier ที่เน้นความจุซึ่งค่าใช้จ่ายสำคัญกว่าประสิทธิภาพ

NVMe over Fibre Channel ใช้ประโยชน์จากโครงสร้างพื้นฐาน SAN ที่มีอยู่ในสภาพแวดล้อมองค์กร การส่งแบบ lossless และ zoning ของ FC ให้การแยก storage Latency โดยทั่วไปวัดได้ 10-20 ไมโครวินาที จำกัดที่ 32Gbps ในปัจจุบันขณะที่ Ethernet ถึง 400Gbps ใช้เป็นหลักสำหรับการเปลี่ยนสภาพแวดล้อม FC เดิมไปสู่ NVMe

การออกแบบสถาปัตยกรรมสำหรับขนาด 100,000 GPU

การขยาย NVMe-oF ไปยัง 100,000 GPU ต้องการสถาปัตยกรรมแบบลำดับชั้นที่มีหลายระดับการรวม:

Leaf-Spine Storage Fabric: โหนด storage เชื่อมต่อกับ leaf switch ที่ 100-200GbE แต่ละ leaf จัดการโหนด storage 32-48 ตัวด้วย oversubscription 2:1 Spine switch เชื่อมต่อ leaf โดยใช้ลิงก์ 400-800GbE Spine layer แบบ non-blocking ป้องกันความแออัดระหว่าง leaf การติดตั้งโดยทั่วไปใช้ 4-8 spine สำหรับความซ้ำซ้อนและ bandwidth

Pod-Based Scaling: จัดระเบียบโครงสร้างพื้นฐานเป็น pod ขนาด 1,000-2,000 GPU สำหรับโดเมนที่จัดการได้ แต่ละ pod มี storage fabric เฉพาะที่มีโหนด storage 20-40 ตัว การเชื่อมต่อระหว่าง pod ใช้ลิงก์ DCI (Data Center Interconnect) ความเร็วสูง Pod ขยายอย่างอิสระโดยไม่กระทบต่อ pod อื่น Failure domain จำกัดขอบเขตผลกระทบของการหยุดทำงาน

การกำหนดค่าโหนด Storage: เซิร์ฟเวอร์ dual-socket ที่มีไดรฟ์ NVMe 24-36 ตัวต่อโหนด NIC 200GbE dual-port สำหรับการเชื่อมต่อ fabric แบบซ้ำซ้อน RAM 512GB-1TB สำหรับ metadata caching และ buffer ความสามารถ hardware offload สำหรับการประมวลผล NVMe-oF Software-defined storage layer ที่จัดการ drive pool

สถาปัตยกรรม Namespace: Global namespace ให้มุมมอง storage แบบรวมข้ามโหนดทั้งหมด Sub-namespace แยกข้อมูล tenant หรือ application การสร้าง/ลบ namespace แบบไดนามิกโดยไม่หยุดชะงัก Thin provisioning ป้องกันการสูญเสียความจุ การแชร์ Namespace ช่วยให้ workflow แบบร่วมมือกันเป็นไปได้

การติดตั้งจริงในระดับ ByteDance: - 12 data center ที่มี GPU 8,000-10,000 ตัวต่อแห่ง - โหนด storage 2,500 ตัวให้ความจุใช้งานได้ 85PB - เครือข่าย Clos 3 ระดับที่มี spine 400GbE - Throughput รวม 180GB/s ต่อ rack - Latency เฉลี่ย 5 ไมโครวินาที - การใช้งาน storage 94%

แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้งาน

การติดตั้ง NVMe-oF ที่ประสบความสำเร็จปฏิบัติตามรูปแบบที่ได้รับการยอมรับ:

ความเป็นเลิศในการกำหนดค่าเครือข่าย: เปิดใช้งาน jumbo frame (9000 MTU) ตลอดทั้งสายเพื่อประสิทธิภาพ กำหนดค่า Priority Flow Control (PFC) บนพอร์ต switch ทั้งหมดสำหรับการส่งแบบ lossless ใช้งาน Enhanced Transmission Selection (ETS) สำหรับการจัดสรร bandwidth ติดตั้ง Data Center Bridging (DCB) สำหรับการกำหนดค่าแบบรวม ติดตามสถิติ PFC pause frame เพื่อตรวจจับความแออัด แยก storage traffic โดยใช้ VLAN หรือ overlay network

การเพิ่มประสิทธิภาพ Quality of Service: กำหนด storage traffic ให้กับ priority class สูงสุด สำรอง bandwidth ขั้นต่ำ 40% สำหรับ storage flow กำหนดค่า weighted fair queuing สำหรับ traffic class ใช้งาน rate limiting เพื่อป้องกัน flow เดียวจากการครอบงำ ติดตามการใช้งาน buffer เพื่อป้องกันการ drop ปรับพารามิเตอร์ QoS ตามรูปแบบ workload

ความซ้ำซ้อนและความพร้อมใช้งานสูง: ติดตั้งโหนด storage แบบ dual-homed ไปยัง switch แยกกัน ใช้งาน multipath I/O ด้วย path แบบ active-active กำหนดค่า automatic path failover ใน 50ms หรือน้อยกว่า ใช้ consistent hashing สำหรับการกระจายข้อมูล รักษา 3-way replication หรือ erasure coding เพื่อความทนทาน ออกแบบสำหรับความซ้ำซ้อน N+2 ที่ระดับ component

การใช้งานด้านความปลอดภัย: เปิดใช้งาน IPsec หรือ TLS สำหรับการเข้ารหัสระหว่างการส่ง ใช้งานการควบคุมการเข้าถึงแบบ zone-based สำหรับการแยก ใช้ authentication key สำหรับการเชื่อมต่อ NVMe-oF ติดตั้ง microsegmentation เพื่อจำกัดการเคลื่อนที่ด้านข้าง ตรวจสอบการเข้าถึง storage ทั้งหมดเพื่อการปฏิบัติตามข้อกำหนด สแกนความปลอดภัยเป็นประจำเพื่อหาช่องโหว่

Introl ออกแบบและติดตั้งสถาปัตยกรรม NVMe-oF สำหรับโครงสร้างพื้นฐาน AI ระดับ hyperscale ทั่วพื้นที่ให้บริการทั่วโลกของเรา ด้วยความเชี่ยวชาญที่พิสูจน์แล้วในการจัดการระบบ storage แบบ disaggregated ที่รองรับ GPU ได้ถึง 100,000 ตัว⁴ ทีมของเราได้ดำเนินการติดตั้ง NVMe-oF มากกว่า 50 โครงการตั้งแต่ขนาด 1PB ถึง 100PB

เทคนิคการเพิ่มประสิทธิภาพ

การบรรลุประสิทธิภาพ NVMe-oF สูงสุดต้องการการเพิ่มประสิทธิภาพอย่างเป็นระบบ:

การปรับแต่ง CPU และ Interrupt: ตรึง interrupt ของ NVMe-oF ไว้กับ CPU core เฉพาะเพื่อหลีกเลี่ยง overhead ของ scheduler ปิดการใช้งาน CPU frequency scaling เพื่อประสิทธิภาพที่สม่ำเสมอ กำหนดค่า NUMA affinity สำหรับการเข้าถึงหน่วยความจำแบบ local เพิ่ม interrupt coalescing เพื่อลดการใช้งาน CPU เปิดใช้งาน adaptive interrupt moderation สำหรับการเพิ่มประสิทธิภาพแบบไดนามิก ติดตามการใช้งาน CPU เพื่อระบุคอขวด

การจัดการหน่วยความจำและ Buffer: จัดสรร huge page สำหรับ buffer NVMe-oF เพื่อลด TLB miss ปรับการตั้งค่าหน่วยความจำ kernel สำหรับ workload throughput สูง กำหนดค่าขนาด socket buffer ที่เหมาะสมสำหรับ network stack ใช้งาน memory pooling เพื่อลด overhead การจัดสรร ติดตามการใช้งาน memory bandwidth ป้องกัน memory fragmentation ผ่านการจัดสรรอย่างระมัดระวัง

การเพิ่มประสิทธิภาพ Storage Stack: ปรับขนาด I/O ให้ตรงกับ SSD page boundary เพื่อประสิทธิภาพ กำหนดค่า queue depth ระหว่าง 256-1024 ต่อการเชื่อมต่อ เปิดใช้งาน controller memory buffer (CMB) เพื่อลด latency ใช้งาน I/O scheduling ที่เหมาะสมกับลักษณะของ NVMe ปิดใช้งานฟีเจอร์ที่ไม่จำเป็นเช่น journaling ติดตาม SSD wear leveling และ garbage collection

การจัดวาง Workload อย่างชาญฉลาด: ใช้งาน data locality algorithm เพื่อเก็บข้อมูลที่เข้าถึงบ่อยไว้ใกล้กับ compute ใช้ consistent hashing สำหรับการกระจายข้อมูลที่คาดเดาได้ สมดุลความจุและประสิทธิภาพข้ามโหนด storage ย้ายข้อมูลตามรูปแบบการเข้าถึง แคชข้อมูลที่เข้าถึงบ่อยใน tier ที่เร็วกว่า คาดการณ์รูปแบบการเข้าถึงในอนาคตโดยใช้โมเดล ML

ตัวชี้วัดประสิทธิภาพจากการติดตั้งจริง: - การอ่านแบบสุ่ม 4KB: 15 ล้าน IOPS ต่อโหนด storage - การอ่านลำดับ 128KB: 180GB/s ต่อโหนด storage - Latency เฉลี่ย: 5-7 ไมโครวินาทีผ่าน RoCE - Tail latency (p99.9): 25 ไมโครวินาที - CPU overhead: 8-12% สำหรับ workload ที่อิ่มตัว

การแก้ไขปัญหาที่พบบ่อย

การติดตั้ง NVMe-oF เผชิญกับความท้าทายเฉพาะที่ต้องการวิธีแก้ปัญหาเฉพาะ:

Latency Spike สูง: อาการ: Latency เพิ่มขึ้นเป็นระยะจาก 5μs เป็น 500μs สาเหตุ: PFC storm, buffer exhaustion, TCP retransmission วิธีแก้: ปรับ PFC threshold, เพิ่ม switch buffer, แยก storage traffic การติดตาม: ติดตามระยะเวลาและความถี่ของ pause frame

Throughput ลดลง: อาการ: ประสิทธิภาพลดจาก 180GB/s เป็น 50GB/s สาเหตุ: ความแออัดของเครือข่าย, SSD thermal throttling, คอขวด CPU วิธีแก้: ใช้งาน traffic shaping, ปรับปรุงการระบายความร้อน, ขยายโหนด storage การติดตาม: วัดการใช้งานต่อลิงก์และอุณหภูมิ SSD

Connection Failure: อาการ: การเชื่อมต่อ NVMe-oF หลุดแบบสุ่ม สาเหตุ: ปัญหา authentication, network flap, บั๊กของ driver วิธีแก้: ตรวจสอบ credential, ตรวจสายเคเบิล/optic, อัปเดต driver/firmware การติดตาม: บันทึกการเปลี่ยนแปลงสถานะการเชื่อมต่อและ error counter

ความไม่สมดุลของความจุ: อาการ: บางโหนดที่ความจุ 95% ขณะที่โหนดอื่นที่ 40% สาเหตุ: การจัดวางข้อมูลไม่ดี, workload skew, การ rebalance ล้มเหลว วิธีแก้: ใช้งาน hashing ที่ดีขึ้น, ย้ายข้อมูลอย่างจริงจัง, แก้ไข automation การติดตาม: ติดตามความจุและการกระจาย IOPS ต่อโหนด

กรณีศึกษาการติดตั้งจริง

Meta - การปรับปรุงโครงสร้างพื้นฐานการ Training: - ความท้าทาย: GPU 50,000 ตัวที่มีการใช้งาน storage 60% - วิธีแก้: การติดตั้ง NVMe-oF ด้วย storage แบบ disaggregated 40PB - สถาปัตยกรรม: RoCE v2 ผ่าน Ethernet fabric 200GbE - ผลลัพธ์: การใช้งาน 90%, การ train โมเดลเร็วขึ้น 2.1 เท่า - การลงทุน: ประหยัดค่าใช้จ่าย storage 45 ล้านดอลลาร์ - นวัตกรรมสำคัญ: การจัดวางข้อมูลแบบคาดการณ์โดยใช้รูปแบบการเข้าถึง

บริษัทบริการทางการเงิน - การวิเคราะห์ Tick Data: - ขนาด: GPU 5,000 ตัวประมวลผลข้อมูลตลาด 10TB/วัน - Storage: NVMe-oF pool 5PB ที่มีการเข้าถึงต่ำกว่ามิลลิวินาที - เครือข่าย: InfiniBand fabric สำหรับ latency ที่แน่นอน - ประสิทธิภาพ: บรรลุ latency เฉลี่ย 3 ไมโครวินาที - ประโยชน์: การวิเคราะห์ข้อมูลย้อนหลัง 20 ปีแบบ real-time - สถาปัตยกรรม: Tiered storage ด้วย NVMe และ Optane PMem

บริษัทยานยนต์ไร้คนขับ - Simulation Platform: - Dataset: ภาพขับรถและข้อมูลเซนเซอร์ 100PB - โครงสร้างพื้นฐาน: GPU 8,000 ตัวด้วย storage แบบรวมศูนย์ - เทคโนโลยี: NVMe-oF over TCP สำหรับการเพิ่มประสิทธิภาพด้านค่าใช้จ่าย - Throughput: 500GB/s ag

[เนื้อหาถูกตัดสำหรับการแปล]