วิศวกรจาก Clyso สรุปประสบการณ์ในการสร้างคลัสเตอร์พื้นที่จัดเก็บข้อมูลโดยใช้ระบบ Ceph แบบกระจายที่ทนทานต่อข้อผิดพลาด โดยมีปริมาณงานเกินเทบิไบต์ต่อวินาที มีข้อสังเกตว่านี่คือคลัสเตอร์ที่ใช้ Ceph ตัวแรกที่สามารถบรรลุตัวบ่งชี้ดังกล่าวได้ แต่ก่อนที่จะได้รับผลลัพธ์ที่นำเสนอ วิศวกรจะต้องเอาชนะข้อผิดพลาดที่ไม่ชัดเจนหลายประการ
ตัวอย่างเช่น เพื่อเพิ่มประสิทธิภาพ 10-20% ก็เพียงพอแล้วที่จะเปิดใช้งานเซิร์ฟเวอร์ในการตั้งค่าการประหยัดพลังงานของ BIOS เพื่อให้ทำงานในโหมดประสิทธิภาพสูงสุดเท่านั้น และปิดการใช้งาน c-state (c-state เปลี่ยนพารามิเตอร์การประหยัดพลังงานขึ้นอยู่กับโหลด ซึ่งส่งผลต่อ Ceph) ปรากฎว่าเมื่อใช้ไดรฟ์ NVMe เคอร์เนล Linux ใช้เวลาจำนวนมากในการประมวลผลการล็อคการหมุนในระหว่างกระบวนการอัปเดตการแมป IOMMU การปิดใช้งาน IOMMU ในเคอร์เนลทำให้ประสิทธิภาพเพิ่มขึ้นอย่างเห็นได้ชัดในการทดสอบการเขียนและการอ่านบล็อกขนาด 4MB
ในเวลาเดียวกัน การปิดใช้งาน IOMMU ไม่ได้แก้ปัญหาประสิทธิภาพการทำงานลดลงเมื่อสุ่มเขียนบล็อกขนาด 4KB ในขณะที่ค้นหาว่าเกิดอะไรขึ้น วิศวกรก็พบกับการแก้ไขในสคริปต์ Ceph build จากโปรเจ็กต์ Gentoo และ Ubuntu ซึ่งรวมถึงการสร้างด้วยตัวเลือก RelWithDebInfo เนื่องจากมีการใช้งานโหมดเพิ่มประสิทธิภาพ “-O2” ใน GCC ซึ่งมีความสำคัญมาก เพิ่มประสิทธิภาพของ Ceph การคอมไพล์ด้วยไลบรารี TCMalloc ยังส่งผลให้ประสิทธิภาพลดลงเช่นกัน การเปลี่ยนแฟล็กการคอมไพล์และเลิกใช้ TCMalloc ส่งผลให้เวลาในการบดอัดลดลงสามเท่า และประสิทธิภาพการเขียนบล็อก 4K แบบสุ่มเพิ่มขึ้นสองเท่า ในที่สุด การตั้งค่า Reef RocksDB และกลุ่มตำแหน่ง (PG) ได้รับการปรับปรุงให้เหมาะสมยิ่งขึ้น
กลุ่มคลัสเตอร์นี้ประกอบด้วยโหนด 68 โหนด โดยอิงตาม เซิร์ฟเวอร์ คลัสเตอร์ Dell PowerEdge R6615 พร้อมซีพียู AMD EPYC 9454P 48C/96T แต่ละโหนดประกอบด้วยไดรฟ์ NVMe Dell ขนาด 15.36TB จำนวน 10 ตัว อะแดปเตอร์อีเธอร์เน็ต Mellanox ConnectX-6 100GbE สองตัว และ RAM 192GB ซอฟต์แวร์ใช้ระบบปฏิบัติการ Ubuntu 20.04.6 และ Ceph 17.2.7 คลัสเตอร์ 63 โหนดนี้รัน OSD (Object Storage Daemon ซึ่งเป็นกระบวนการทำงานเบื้องหลังที่จัดการการจัดเก็บข้อมูลบนที่เก็บข้อมูลภายในเครื่อง โดยมี OSD หนึ่งตัวต่อไดรฟ์ NVMe หนึ่งตัว) จำนวน 630 ตัว กระบวนการ MON (monitor ซึ่งตรวจสอบสถานะของคลัสเตอร์) จำนวน 3 ตัว และกระบวนการ MGR (Manager ซึ่งเป็นบริการจัดการ) จำนวน 1 ตัว ขนาดพื้นที่จัดเก็บข้อมูลคือ 8.2 PB
ทรูพุตสำหรับการดำเนินการอ่านตามลำดับของบล็อก 4M คือ 1025 GiB/s, การเขียน - 270 GiB/s เมื่อสุ่มอ่านบล็อก 4KB ประสิทธิภาพคือ 25.5 ล้านการดำเนินการอ่านต่อวินาที และ 4.9 ล้านการดำเนินการเขียน การเปิดใช้งานการเข้ารหัสจะลดปริมาณการอ่านลงเหลือประมาณ 750 GiB/s เมื่อเปิดใช้งานรหัสแก้ไขข้อผิดพลาด EC62 ปริมาณงานคือ 547 GiB/s เมื่ออ่านและ 387 GiB/s เมื่อเขียน (ความเร็วในการเขียนสูงกว่าไม่มีรหัสแก้ไข) และด้วยการเข้าถึงแบบสุ่ม 3.4M IOPS เมื่ออ่านและ 936K IOPS เมื่อเขียน .
นอกจากนี้ สังเกตได้ว่าในเดือนกันยายน คลัสเตอร์การจัดเก็บข้อมูลระดับเอ็กซาไบต์ของ CERN สามารถบรรลุปริมาณงานในระดับเทบิไบต์ต่อวินาทีที่คล้ายคลึงกัน ซึ่งดำเนินการบนพื้นฐานของการจัดเก็บข้อมูลแบบกระจายแบบเปิดของ EOS ที่สร้างขึ้นบนโปรโตคอล XRootD
ที่มา: opennet.ru
