Ceph: เส้นทางสู่ 1 TiB/s

Ceph: เส้นทางสู่ 1TiB/s

• บทความที่บอกเล่าเส้นทางการปรับปรุงประสิทธิภาพของคลัสเตอร์ Ceph โดยผ่านกระบวนการดีบักอันยาวนานและการปรับแต่งประสิทธิภาพ จนสามารถทำความเร็วในการประมวลผลข้อมูลได้ถึง 1TiB/s
• แชร์ปัญหาทางเทคนิคหลากหลายรูปแบบและแนวทางแก้ไขที่เกิดขึ้นระหว่างที่บริษัทชื่อ Clyso ช่วยสร้างคลัสเตอร์ Ceph ขนาด 10 เพตะไบต์บนพื้นฐาน NVMe
• เครือข่ายของลูกค้ามีความเร็วสูงมาก และเป็นหนึ่งในการตั้งค่า Ethernet ที่เร็วที่สุด

คำขอบคุณ

• กล่าวขอบคุณลูกค้าของ Clyso ซึ่งความร่วมมือของพวกเขาทำให้สามารถแบ่งปันประสบการณ์นี้กับชุมชน Ceph ได้
• ขอบคุณ IBM/Red Hat และ Samsung ที่จัดหาฮาร์ดแวร์สำหรับใช้ในการทดสอบเปรียบเทียบ
• ขอบคุณผู้มีส่วนร่วมใน Ceph สำหรับความพยายามในการทำให้ Ceph เป็นซอฟต์แวร์ที่ยอดเยี่ยม

การตั้งค่าคลัสเตอร์

• ลูกค้าเสนอให้ใช้โหนดแบบ dual-socket ขนาด 2U จำนวน 34 เครื่องกระจายอยู่ใน 17 แร็ก แต่ Clyso ได้นำเสนอหลายรูปแบบที่ใช้โหนดขนาดเล็กกว่า
• สุดท้ายได้เลือกสถาปัตยกรรมของ Dell เพื่อลดต้นทุน พร้อมให้แบนด์วิดท์หน่วยความจำที่เร็วขึ้น ทรัพยากร CPU มากขึ้น และปริมาณงานเครือข่ายที่สูงขึ้น
• เมื่อล้มเหลวที่ระดับโหนด ผลกระทบต่อการกู้คืนคลัสเตอร์จะลดลงเหลือครึ่งหนึ่ง

การตั้งค่าการทดสอบ

• ใช้ CBT เพื่อดีพลอยคลัสเตอร์ Ceph ชั่วคราวและรันการทดสอบ FIO
• ใช้การทดสอบ FIO แบบอิงไลบรารีเพื่อแบ่งคลัสเตอร์ออกเป็นหน่วยเล็ก ๆ และเปรียบเทียบกับผลก่อนหน้า
• ทดสอบทั้ง replication 3X และ erasure coding 6+2 รวมถึงทดสอบ message version 2 ในโหมดเข้ารหัสและโหมด secure

ข้อควรระวังเกี่ยวกับจำนวน PG

• ทดสอบเชิงทดลองว่าจำนวน PG ส่งผลต่อประสิทธิภาพอย่างไร
• แม้จำนวน PG ที่สูงอาจส่งผลบวกต่อประสิทธิภาพ แต่ในสภาพแวดล้อม production จริงต้องพิจารณาร่วมกับการตั้งค่าอื่น ๆ

จุดที่เริ่มต้นได้ยาก

• หลังจากล็อกอินเข้าเครื่องฮาร์ดแวร์ครั้งแรก ก็พบปัญหาในการแก้ไขสถานการณ์เพราะประสิทธิภาพต่ำกว่าที่คาดไว้
• การทดสอบประสิทธิภาพช่วงแรกออกมาดี แต่เมื่อทดสอบโดยใช้ OSD หลายตัวกลับเกิดการลดลงของประสิทธิภาพ

พฤติกรรมประหลาด

• ระหว่างรันชุดการทดสอบ OSD หลายรูปแบบ พบว่ามีแพตเทิร์นแปลก ๆ ในประสิทธิภาพ
• สังเกตว่าระบบจะมีประสิทธิภาพลดลงหลังการทดสอบแบบ multi-OSD แล้วค่อยฟื้นกลับมาอีกครั้งหลังผ่านไปหลายชั่วโมง

วิธีแก้ไขสามอย่าง

• แก้ปัญหาความหน่วงที่เกิดจากการสลับ CPU c-state ซึ่งช่วยเพิ่มประสิทธิภาพได้เล็กน้อย
• ปิดการใช้งาน IOMMU และทำให้ประสิทธิภาพดีขึ้นอย่างมาก
• แก้ปัญหา compile flag ของ RocksDB ทำให้ประสิทธิภาพการเขียนแบบสุ่มขนาด 4K เพิ่มขึ้นเป็นสองเท่า

สัปดาห์แรกของปี 2024

• ในวันแรกของปีใหม่ เกิดเหตุขัดข้องครั้งใหญ่ในอีกคลัสเตอร์หนึ่ง ทำให้ไม่สามารถโฟกัสกับการทดสอบประสิทธิภาพได้
• กลับมาทดสอบประสิทธิภาพอีกครั้งในวันศุกร์ และยืนยันได้ว่าคลัสเตอร์ทำงานได้ดีแม้อยู่ภายใต้โหลดสูง

รอยยิ้มแห่งโชคชะตา

• เมื่อผลการทดสอบประสิทธิภาพดีขึ้น ก็ยืนยันได้ว่าคลัสเตอร์สามารถขยายตัวได้แบบเชิงเส้น
• คลัสเตอร์ที่ประกอบด้วย 63 โหนดสามารถทำความเร็วในการประมวลผลข้อมูลได้ 635GiB/s

ดาวมรณะที่ใช้งานได้เพียงบางส่วน

• เนื่องจากมี client node ไม่เพียงพอ จึงต้องให้ OSD node ใช้ร่วมกับโปรเซส FIO
• แม้ตั้งค่าแบบนี้ ก็ยังทำประสิทธิภาพได้ใกล้ 950GiB/s

แตะ 1TiB/s

• ปรับจำนวน OSD shard และจำนวน messenger thread จนสามารถทำความเร็วในการประมวลผลข้อมูลได้ถึง 1TiB/s

การนอนหลับ; erasure coding

• หลังจากทดสอบด้วย replication 3X แล้ว ก็รีคอนฟิกคลัสเตอร์เป็น erasure coding 6+2 ซึ่งเป็นรูปแบบที่ลูกค้าจะใช้งานจริง และทำการทดสอบต่อ
• ประสิทธิภาพการอ่านสูงกว่า 500GiB/s และประสิทธิภาพการเขียนเกือบแตะ 400GiB/s

GN⁺ ความเห็น:

1. บทความนี้อธิบายกระบวนการปรับแต่งประสิทธิภาพของคลัสเตอร์ Ceph อย่างละเอียด และมอบมุมมองเชิงเทคนิคผ่านกรณีศึกษาการแก้ปัญหาที่ซับซ้อนจนไปสู่ประสิทธิภาพระดับสูง
2. แสดงให้เห็นว่าความร่วมมือกับลูกค้า ความพยายามของผู้มีส่วนร่วมในชุมชน และกลยุทธ์การปรับแต่งทั้งฮาร์ดแวร์และซอฟต์แวร์ สามารถสร้างผลลัพธ์ที่ยิ่งใหญ่ในโลกจริงได้อย่างไร
3. บทความนี้ให้ข้อมูลที่เป็นประโยชน์ไม่เพียงกับผู้เชี่ยวชาญด้านระบบจัดเก็บข้อมูลขนาดใหญ่ แต่ยังรวมถึงวิศวกรที่สนใจเรื่องการปรับแต่งประสิทธิภาพด้วย

[GN⁺]

ความคิดเห็นใน Hacker News

• ข่าวการแตะระดับ 1TB/s ของ CERN และประวัติของ Ceph
  • ผู้ใช้รายหนึ่งกล่าวถึงการที่ CERN ทำความเร็วได้ถึง 1TB/s ผ่านคลัสเตอร์ EOS โดยอธิบายว่าคลัสเตอร์นี้ใช้ HDD เป็นหลักและมีจำนวนโหนดมากกว่า อีกทั้งยังแชร์ประวัติที่น่าสนใจว่า Ceph ถือกำเนิดขึ้นที่ Dreamhost จากความจำเป็นภายในองค์กร ก่อนจะถูก Redhat เข้าซื้อกิจการในภายหลัง
• ประสบการณ์ของอดีตผู้นำด้านเทคนิคและความชื่นชอบที่มีต่อ Ceph
  • ผู้ใช้รายหนึ่งย้อนเล่าประสบการณ์การทำงานเป็นผู้นำด้านเทคนิคที่ Cisco โดยตั้งค่า Kubernetes บน bare metal และทดลองใช้ GlusterFS กับ Ceph พร้อมระบุว่าเขาสนุกกับการทดลองเหล่านี้มาก นอกจากนี้ยังชื่นชมว่าบทความนี้เขียนได้ดี
• ข้อเสนอให้ลดขนาดของโหนด
  • ผู้ใช้รายหนึ่งชี้ว่าปัจจุบันระบบมีการใช้พลังงานต่อโหนดสูง และเสนอว่าควรมีความพยายามด้านวิศวกรรมเพื่อลดขนาดของโหนดลง โดยให้เหตุผลว่าจะทำให้ใช้โหนดน้อยลงก็เพียงพอ และช่วยลดผลกระทบจากความขัดข้องจุดเดียวที่กระทบดิสก์ 10 ลูกได้
• มุมมองทางประวัติศาสตร์ต่อปริมาณการจัดเก็บข้อมูลดิจิทัล
  • ผู้ใช้รายหนึ่งกล่าวว่า ภายในช่วง 60 ปีที่ผ่านมา น่าจะเคยมีวันแรกที่ทั่วโลกเก็บข้อมูลดิจิทัลรวมกันครบ 1TiB เป็นครั้งแรก และแสดงความทึ่งว่าทุกวันนี้เราสามารถเคลื่อนย้ายข้อมูลปริมาณนั้นได้ในทุก ๆ วินาที
• ประสบการณ์การเพิ่มประสิทธิภาพ Docker cache ด้วยคลัสเตอร์ Ceph
  • ผู้ใช้รายหนึ่งแชร์ประสบการณ์ว่าตนกำลังรันคลัสเตอร์จัดเก็บข้อมูล Ceph เพื่อเก็บ Docker layer cache และหลังจากย้ายจาก EBS มาเป็น Ceph แล้ว throughput ก็ดีขึ้นอย่างมาก โดยผู้ใช้นี้ระบุว่า Ceph แทบไม่ต้องดูแลรักษาเลย
• ปัญหาซอฟต์แวร์ storage controller ภายใน Kubernetes
  • ผู้ใช้รายหนึ่งกล่าวว่าปัญหาใหญ่ที่สุดของ dynamic storage ภายใน Kubernetes ไม่ได้เกี่ยวกับ I/O แต่เกิดจากซอฟต์แวร์ storage controller เมื่อเจอปัญหาจริง โดยเฉพาะตอนใช้ rook/ceph และ Longhorn ที่พบว่า PVC ใช้เวลานานมากกว่าจะ attach ได้
• การวิเคราะห์ประสิทธิภาพ 1 TiB/s เทียบกับขีดจำกัดเชิงทฤษฎีของฮาร์ดแวร์
  • ผู้ใช้รายหนึ่งวิเคราะห์ว่าประสิทธิภาพระดับ 1 TiB/s เทียบกับขีดจำกัดเชิงทฤษฎีของฮาร์ดแวร์เป็นอย่างไร และชี้ว่าเครือข่ายกำลังเป็นคอขวด นอกจากนี้ยังสรุปว่าความซับซ้อนของ Ceph สร้างภาระให้ CPU อย่างมาก และโมเดลการทำงานแบบเธรดของ OSD ยังไม่ได้รับการปรับแต่งอย่างเหมาะสม พร้อมหวังว่าจะมีการปรับปรุง
• คำขอให้เปรียบเทียบ Ceph กับเอนจินอ็อบเจ็กต์สตอเรจอื่น
  • ผู้ใช้รายหนึ่งอยากเห็นการเปรียบเทียบและ benchmark ระหว่าง Ceph กับเอนจินอ็อบเจ็กต์สตอเรจอื่น เช่น MinIO และ Garage
• คำถามเกี่ยวกับความเหมาะสมของ Ceph สำหรับทรานแซกชันดาต้าเบสและค่า IO latency
  • ผู้ใช้รายหนึ่งถามว่า Ceph เหมาะกับการใช้เป็นสตอเรจสำหรับ transactional database หรือไม่ และมี IO latency เป็นอย่างไร พร้อมแสดงความเห็นว่าอยากย้ายไปใช้ไฟล์ซิสเต็มราคาย่อมเยาที่สามารถแข่งขันกับระบบอย่างคลัสเตอร์ไฟล์ซิสเต็มของ Oracle หรือ Veritas ได้