TỔNG QUAN.
Do các bài viết trước về Ceph mình chưa nói về cách lựa chọn phần cứng cho 1 hệ thống Ceph nên bài này mình sẽ nói về vấn đề này để các bạn có hướng lựa chọn phần cứng tốt phục vụ cho hệ thống Ceph của bạn.
CÁCH LỰA CHỌN PHẦN CỨNG CHO CEPH.
Đây là một hướng dẫn về việc lựa chọn phần cứng cho hệ thống Ceph, bao gồm CPU, RAM cho các server MON và OSD.
- CPU: Công thức đưa ra cho phép tính toán số lượng tài nguyên CPU cần thiết cho mỗi OSD (Object Storage Daemon) trong hệ thống. Nói cách khác, tổng tài nguyên CPU (số lượng socket, số lượng core trên mỗi socket và tốc độ xung nhịp) chia cho số lượng OSD nên lớn hơn hoặc bằng 1. Điều này đảm bảo rằng mỗi OSD có đủ tài nguyên CPU để hoạt động.
- RAM:
- MON server: Đối với hệ thống có hiệu suất thấp, 32GB RAM có thể đủ. Tuy nhiên, nếu hệ thống cần hiệu suất cao, nên chọn 64GB RAM.OSD server: RAM cho OSD server được tính như sau: 2 GB RAM cho mỗi OSD, cộng với 1GB RAM cho mỗi 1TB disk. Nếu một OSD server sử dụng 20 ổ đĩa SSD 2TB cho mỗi OSD, tổng số RAM cho OSD server sẽ là: 20 * (2GB + (1GB * 2)) + (64GB) = 192GB RAM.
- Network: Ceph cần mạng có băng thông cao và độ trễ thấp. Nhiều hệ thống Ceph hiện tại chọn bonding 2 cổng 10GB để đảm bảo băng thông và tính HA (High Availability) của hệ thống.
- Disk:
- FileStore backend: Nếu sử dụng SAS làm OSD, thì phải dùng SSD để làm journal. Kích thước của phân vùng journal nên từ 10GB – 20GB. Nếu tạo kích thước journal lớn, cần tăng các chỉ số liên quan đến journal như filestore maximum and minimum synchronization time intervals. Tổng tải của các journal không được vượt quá giới hạn của SSD. Chỉ nên tạo 4 journal cho 1 SSD, vì vậy tỉ lệ giữa SSD dùng làm journal và OSD là 1:4. Mật độ của số OSD trên một ceph osd node cũng là một yếu tố quan trọng cho hiệu suất và dung lượng của cluster. Dung lượng của một ceph osd node nên nhỏ hơn 10% tổng dung lượng của cluster.
- BlueStore backend: Các SSD phải đảm bảo có random write iops (block 4k) > 30k. Nên sử dụng các SSD MLC để tăng khả năng chịu lỗi. Không sử dụng RAID cho các ổ đĩa dùng làm OSD.
Journal là gì?
Trong Ceph, “journal” là một kỹ thuật được sử dụng để tăng tốc độ ghi dữ liệu. Khi một yêu cầu ghi được nhận, thay vì ghi trực tiếp vào OSD (Object Storage Daemon), Ceph sẽ ghi vào journal trước. Sau đó, dữ liệu từ journal sẽ được ghi vào OSD theo cách mà tối ưu hóa hiệu suất.
Khi sử dụng SSD để làm journal, tốc độ ghi vào journal sẽ nhanh hơn nhiều so với việc ghi trực tiếp vào OSD (đặc biệt khi OSD là ổ đĩa cứng SAS hoặc SATA), do đó cải thiện hiệu suất của hệ thống.
Tuy nhiên, lưu ý rằng từ phiên bản Luminous (12.x) trở đi, Ceph đã chuyển sang sử dụng BlueStore thay vì FileStore, và không còn sử dụng journal nữa. Thay vào đó, BlueStore sử dụng RocksDB, một cơ sở dữ liệu key-value, để lưu trữ metadata và dữ liệu nhỏ.
LỰA CHỌN OS VÀ FILESYSTEM.
- Hệ điều hành: Ceph nên được triển khai trên phiên bản Ubuntu có hỗ trợ dài hạn (LTS).
- Hệ thống filesystem OSD: Daemon Ceph OSD hoạt động trên một hệ thống filesystem, có thể là XFS, EXT, hoặc thậm chí là Btrfs.Các thuộc tính mở rộng (XATTR) cung cấp thông tin nội bộ về trạng thái đối tượng, snapshot, metadata và ACL cho daemon Ceph OSD, giúp quản lý dữ liệu.Hệ thống filesystem cơ bản nên cung cấp đủ dung lượng cho XATTRs.Hầu hết các cụm Ceph sau này sử dụng BlueStore là hệ thống filesystem của Ceph, do đó không cần sử dụng các hệ thống filesystem bên ngoài.
Authentication Users.
Đây là mô tả về các người dùng xác thực và quyền hạn của họ trong một hệ thống Ceph:
- backup: Người dùng này có quyền đọc, ghi và thực thi (rwx) trên tất cả các pools. Mục đích chính của người dùng này là để sao lưu các volumes.
- images: Người dùng này có quyền đọc, ghi và thực thi (rwx) trên pool chứa các hình ảnh hệ thống OPS. Người dùng này chỉ được phép truy cập toàn quyền vào pool chứa các hình ảnh hệ thống.
- volumes: Người dùng này có quyền đọc, ghi và thực thi (rwx) trên các pool chứa volume của các instances và quyền chỉ đọc (read-only) trên image pool. Người dùng này được phép truy cập toàn quyền vào pool chứa các volumes OPS.
