CEPH!

Objects Storage architecture and mechanisms.

Ceph เป็นทางเลือกสำหรับการสร้าง Storage แบบ Opensource (คือฟรี) ใช้งานได้ทั้งเป็น object , block (mount ใส่ vm)และ file system (mount ใส่ os)

การทำงานในการเก็บข้อมูลมันทำดังนี้

โดยใช้ CRUSH เป็น algorithm ในการทำ SCALABILITY และ HIGH AVAILABILITY

http://ceph.com/papers/weil-crush-sc06.pdf

การทำงานของมันคือ

  • สร้าง Node ขึ้นมา 4 แบบ คือ Admin node, OSD node, MDS node และ Monitor node
  • OSD คือ Object storage daemon เป็นส่วนที่จะใช้เก็บข้อมูล โดย OSD node จะมีส่วนสำคัญ 3 ส่วนคือ OS, Journal และ OSD
  • 1 OSD คือ 1 disk และเก็บ object ได้ 1 ตัว เพราะฉะนั้นถ้าต้องการ distribute ไฟล์กี่ชิ้น ต้องการ replicate ไปกี่ที่ ก็ดูตรงนี้ ซึ่ง crush จะจัดการให้ อนาคตถ้าเพิ่ม OSD node เข้าไปก็สามารถ rebalance มันได้
  • Journal คือ ส่วนที่เอาไว้เพิ่มความเร็วในการเขียนและความมั่นคงของข้อมูล
Ceph OSDs use a journal for two reasons: speed and consistency.
Speed: The journal enables the Ceph OSD Daemon to commit small writes quickly. Ceph writes small, random i/o to the journal sequentially, which tends to speed up bursty workloads by allowing the backing filesystem more time to coalesce writes. The Ceph OSD Daemon’s journal, however, can lead to spiky performance with short spurts of high-speed writes followed by periods without any write progress as the filesystem catches up to the journal.
Consistency: Ceph OSD Daemons require a filesystem interface that guarantees atomic compound operations. Ceph OSD Daemons write a description of the operation to the journal and apply the operation to the filesystem. This enables atomic updates to an object (for example, placement group metadata). Every few seconds–between filestore max sync interval and filestoremin sync interval–the Ceph OSD Daemon stops writes and synchronizes the journal with the filesystem, allowing Ceph OSD Daemons to trim operations from the journal and reuse the space. On failure, Ceph OSD Daemons replay the journal starting after the last synchronization operation.
  • เพราะฉะนั้นถ้าทำตามรูป จะใช้ 5 disks โดยมี 1 OS, 1 Journal และ 3 OSDs โดย Journal จะถูก recommend ให้ใช้ SSD (แต่เราไม่มี แค่แบ่ง disk เทสบน VM ก็ลำบากแล้ว T-T )
Ceph best practices dictate that you should run operating systems, OSD data and OSD journals on separate drives.
  • MDS คือ Metadata server เอาไว้เก็บข้อมูลเพื่อใช้งานระบบ file system
The purpose of the MDS is to store all the filesystem metadata (directories, file ownership, access modes, etc) in high-availability Ceph Metadata Servers.
  • อย่าลืมใช้ NTP ตั้งเวลาให้ตรงกัน (เราใช้ virtual box ถ้า sleep เครื่องไว้แล้วเปิดมาใหม่ เวลามันชอบเอ๋อแต่ละเครื่องไม่ตรงกันเลย)
  • เราสามารถ deploy OSD, MDS และ Monitor mode จาก Admin node ได้เลย หลังจาก deploy แล้วก็ไล่เซ็ตอัพให้ครบ ก็จะใช้งานได้แล้ว

สรุป

การเก็บไฟล์จะถูกแบ่งเป็นชิ้น (distribute) เป็น object ด้วย crush โดย 1 ชิ้นจะถูกเก็บอยู่บน 1 OSD ถ้าทำ replicate กี่ copy ก็ใส่ไปตรง osd pool default size ใน ceph.conf ตอน deploy หรือไปแก้ใน crush map

http://docs.ceph.com/docs/master/install/manual-deployment/
http://docs.ceph.com/docs/master/rados/operations/crush-map/

การใช้งาน ceph เหมือนการใช้งาน multi-tools คือ ใช้ได้หลายแบบ ประหยัดค่าใช้จ่ายเพราะเป็น opensource แต่ config ยาก คือทำๆไปแล้วมึน ถ้าต้องการให้ง่ายขึ้น ถ้าใช้ร่วมกับ ansible น่าจะง่ายขึ้นมาก (ยังไม่เคยลองใช้ ansible จริงจังเลย หวังว่าจะมีเวลาได้ลองเร็วๆนี้)

ปัญหาคือถ้าจะเทียบกับพวก software ระดับ enterprise แพงๆ ในการใช้ block อย่างเดียว performance ยังห่างไกลกันมาก เช่น การเทียบกับ ScaleIO ของ EMC

https://www.openstack.org/summit/tokyo-2015/videos/presentation/emc-battle-of-the-titans-real-time-demonstration-of-ceph-vs-scaleio-performance-for-block-storage
https://www.sebastien-han.fr/blog/2014/02/17/ceph-io-patterns-the-bad/
https://www.sebastien-han.fr/blog/2014/02/24/ceph-io-patterns-the-ugly/

เพราะฉะนั้น เราขอจบไว้ตรงนี้ ขอเอาเวลาไปโฟกัสกับการย้ายระบบ DB จาก sql ที่เสียเงินแพงๆ พวก oracle หรือ mssql ไปไว้บน opensource ทั้ง sql และ nosql บน cloud ก่อนแล้วกัน ถ้า ceph หรือ openstack (ทำไว้นานแล้วตั้งแต่ยังไม่เริ่มเขียนบล๊อคนี้ไว้จะลองทำใหม่ค่อยเอามาลงเพิ่ม) มีอะไรอัพเดตที่น่าสนใจอาจจะลองมาดูกันอีกที

แถม

เราไม่ได้บอกว่า Ceph ไม่ได้หรืออย่างไรนะ เราเชื่อว่าการใช้งาน Openstack + Ceph บน hyper-converdged ที่สามารถกำหนด (provision) IOPS ได้ ร่วมกับการออกแบบระบบ backup/DR ที่รอบคอบ และมีการทดสอบ failover ตามที่ควรมี จะทำให้ใช้ทรัพยากรได้อย่างคุ้มค่า มีความมั่นคงสูง ต้นทุนการสร้าง Private Cloud จะลดลงอย่างมหาศาล และการทำ IT Transformation จะทำได้อย่างมีประสิทธิภาพมากๆ

แต่จากประสบการณ์ เรายังไม่เคยเห็นองค์กรไหนในเมืองไทยพอจะทำได้เลย ด้วยหลายๆสาเหตุ โดยสาเหตุที่สำคัญที่สุดที่ทำให้ไม่สามารถทำได้คือ “คน” การจะทำอะไรแบบนี้ต้องพึ่งบุคลากรของตัวเองให้มากที่สุด เพราะถ้ายังอาศัย SI หรือ Vendor เข้ามาทำให้ ก็ต้องจ่ายเงินค่าแรง ค่า licenses อย่างเกินควรต่อไป


One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.