Auto-tiering Ceph Object Storage - PART 1
Mở đầu
Các hệ thống object storage tương thích S3 nhìn chung đều có khả năng lưu object vào những tier khác nhau với đặc tính khác nhau, nhờ đó bạn có được sự kết hợp tối ưu giữa chi phí và hiệu năng phù hợp với nhu cầu của từng application workload. Trong thuật ngữ S3, các storage tier được gọi là ‘Storage Classes’; ví dụ trên AWS có storage class “STANDARD” cho mục đích sử dụng phổ thông, và các storage class thấp hơn như “DEEP_ARCHIVE” và “GLACIER” dành cho các use case backup và archive.
Khả năng lưu trữ tương thích S3 của Ceph cũng cho phép bạn tự tạo Storage Class riêng, và theo mặc định Ceph tự động tạo một storage class duy nhất tên là “STANDARD” để tương ứng với tier mặc định mà AWS cung cấp.
Trong loạt bài blog gồm 3 phần này, chúng ta sẽ đi sâu vào auto-tiering cho object storage với Ceph và tìm hiểu một chút về Lua scripting trong quá trình đó — tôi nghĩ bạn sẽ thấy phần scripting này khá dễ tiếp cận, ngay cả khi trước đây bạn chưa từng dùng hay nghe tới Lua:
- PART 1 - Những khái niệm nền tảng về Ceph object storage và lý do bạn muốn thiết lập nhiều storage class khác nhau
- PART 2 - Cách dùng Lua scripting để tự động gán object vào các storage class khác nhau dựa trên kích thước
- PART 3 - Lua scripting nâng cao hơn để khớp object với storage class một cách động, dựa trên việc so khớp regex với tên object
Ceph Object Storage Basics — Những khái niệm nền tảng về Ceph object storage
Một Ceph object storage cluster gồm hai pool lưu trữ chính: một cho metadata và một cho data.
Metadata pool lưu index của toàn bộ object của mọi bucket, và tên pool này có chứa “rgw.bucket.index”. Về bản chất, bucket index pool là một tập hợp các database — mỗi bucket một database — chứa danh sách mọi object trong bucket đó cùng thông tin về vị trí của từng chunk dữ liệu (RADOS object) tạo nên mỗi S3 object.
Data pool thường có chứa “rgw.buckets.data” trong tên, và lưu toàn bộ các block dữ liệu thực tế (RADOS object) cấu thành mỗi S3 object trong cluster của bạn.
Metadata trong bucket index pool cần nằm trên storage nhanh, phù hợp với các thao tác đọc/ghi nhỏ (IOPS), bởi nó về cơ bản là một tập hợp database. Vì vậy (và vì nhiều lý do kỹ thuật khác nằm ngoài phạm vi bài viết này), pool này bắt buộc phải được cấu hình với layout replica và lý tưởng nhất là đặt trên media all-flash. Flash storage cho bucket index pool cũng quan trọng vì các bucket phải định kỳ thay đổi kích thước bucket index database của mình (dựa trên RocksDB) để mở rộng, tạo thêm chỗ cho object metadata khi bucket lớn dần. Quá trình này gọi là “resharding”, diễn ra hoàn toàn tự động ở phía sau, nhưng resharding có thể ảnh hưởng rất lớn tới hiệu năng cluster nếu bucket index pool đặt trên HDD thay vì flash.
Ngược lại, data pool (ví dụ default.rgw.buckets.data) thường lưu các chunk dữ liệu lớn, có thể ghi hiệu quả lên HDD. Đây chính là chỗ mà layout erasure coding phát huy thế mạnh, mang lại mức tăng đáng kể về dung lượng khả dụng (thường 66% hoặc hơn, so với 33% khả dụng khi dùng replica=3). Erasure coding cũng cho hiệu năng ghi rất tốt khi bạn làm việc với những object đủ lớn (nói chung là từ 4MB trở lên, nhưng lý tưởng là từ 64MB trở lên), vì mức write amplification trên network khi dùng erasure coding thấp hơn nhiều (~125% lưu lượng N/S của client) so với layout dựa trên replica (300% lưu lượng N/S của client).
Object Storage Zones and Zone Groups — Zone và Zone Group trong object storage
Một zone chứa một bản copy hoàn chỉnh của toàn bộ S3 object của bạn, và các object đó có thể được mirror toàn bộ hoặc một phần sang các zone khác. Khi bạn muốn mirror mọi thứ sang một zone khác, bạn đặt các zone cần mirror với nhau vào cùng một Zone Group. Thông thường tên của Zone Group cũng chính là tên của S3 realm, chẳng hạn “us” hay “eu”, còn zone sẽ có tên kiểu “us-east-1” hoặc “us-west-1” — vay mượn từ một số tên zone phổ biến của AWS. Khi thiết lập Ceph object storage để dùng với các sản phẩm như Veritas Netbackup, chúng tôi khuyến nghị dùng tên zone theo kiểu AWS như “us-east-1” để đảm bảo tương thích, vì một số sản phẩm tìm đúng các tên zone và realm quen thuộc của AWS. Một cluster được thiết lập với zone “us-east-1” và zone group (đồng thời là realm) “us” sẽ trông như thế này.
Object Storage Classes — Storage class trong object storage
Storage class cho chúng ta một cách để tag object nhằm đưa chúng vào data pool mà mình chọn. Khi bạn thiết lập một cluster với một data pool duy nhất như ở trên, bạn sẽ có một storage class duy nhất map tới nó tên là “STANDARD”, và cluster của bạn sẽ trông như thế này.
Auto-tiering via Multiple Storage Classes — Auto-tiering bằng nhiều storage class
Giờ ta đến phần cốt lõi của bài viết. Sẽ thế nào nếu dữ liệu của bạn không chỉ gồm các object lớn, mà bạn có hàng triệu hoặc hàng tỷ object nhỏ lẫn với các object lớn? Bạn muốn dùng erasure coding cho các object lớn, nhưng cách đó sẽ gây lãng phí và tốn kém với những object nhỏ (ví dụ 1K đến 64K). Còn nếu bạn dùng replica=3 làm layout cho data pool thì bạn chỉ có 33% dung lượng khả dụng, sẽ hết chỗ và cần lượng storage nhiều gấp ba. Đây là lúc nhiều data pool phát huy tác dụng. Không cần mua thêm storage, chúng ta có thể dùng chung media nền (các OSD) với những pool hiện có và tạo thêm data pool mới để có thêm lựa chọn về layout. Dưới đây là ví dụ khi ta thêm hai data pool cùng các storage class tương ứng, gọi là SMALL_OBJ cho object < 16K và MEDIUM_OBJ cho mọi thứ từ 16K đến 1MB:
Như vậy giờ ta có storage class “SMALL_OBJ” chỉ tiêu tốn vài gigabyte cho mỗi triệu object nhỏ, và có thể đọc/ghi chúng một cách hiệu quả. Ta cũng có storage class “MEDIUM_OBJ” dựa trên HDD, cũng dùng layout replica=3 giống “SMALL_OBJ”, nhưng pool này nằm trên media HDD nên ít tốn kém hơn và cho phép ta lưu khoảng một triệu object 1MB chỉ trong 1TB dung lượng. Mọi thứ còn lại sẽ được route tới storage class “STANDARD” mặc định dùng erasure coding. Cũng lưu ý rằng một số application viết cho AWS S3 sẽ không chấp nhận các tên Storage Class tùy chỉnh như “SMALL_OBJ”; vì vậy nếu gặp vấn đề tương thích, hãy thử chọn trong số các tên Storage Class định trước mà AWS sử dụng.
Users Don't Aim — Người dùng không chịu "ngắm"
Rồi, giả sử bạn đã làm hết những điều trên và có một object storage cluster được cấu hình tối ưu — nhưng giờ người dùng gọi tới báo rằng hệ thống chậm. Bạn đi tìm hiểu và phát hiện ra rằng người dùng chẳng hề nỗ lực phân loại object của họ vào đúng nhóm Storage Class (tức là không set header S3 X-Amz-Storage-Class) khi upload object. Chuyện này cũng giống như việc bắt tất cả mọi người phải sắp xếp và phân loại rác tái chế. Nhưng ở đây ta có một vũ khí bí mật, đó là Lua; và trong bài tiếp theo, chúng ta sẽ dùng vài dòng script để đưa object vào đúng Storage Class trong mọi trường hợp, để người dùng không phải làm gì cả.
(Nói tiếp theo phép so sánh với thùng rác tái chế: chúng ta sẽ có thể chỉ cần ném object về phía các thùng rác, và nó luôn rơi đúng thùng. Không cần ngắm, giống như Shane trong Stuff Made Here! 😀 )
Nguồn: https://ceph.io/en/news/blog/2024/auto-tiering-ceph-object-storage-part-1/
Nguồn tham khảo
- Auto-tiering Ceph Object Storage - PART 1 — https://ceph.io/en/news/blog/2024/auto-tiering-ceph-object-storage-part-1/
Ghi chú về nguồn
- URL fetch thành công.
- Trong bản gốc, các tiêu đề mục (Ceph Object Storage Basics, Object Storage Zones and Zone Groups, Object Storage Classes, Auto-tiering via Multiple Storage Classes, Users Don't Aim) được trình bày bằng chữ in đậm trong dòng văn bản, không phải thẻ heading. Bản dịch chuyển chúng thành heading cấp
##để tạo được mục lục có anchor link theo yêu cầu; thứ tự và nội dung giữ nguyên. Mục "Mở đầu" là phần văn bản đứng trước tiêu đề mục đầu tiên của bản gốc (bản gốc không đặt tên cho phần này). - Các đường dẫn ảnh được giữ nguyên như trong bản gốc.
