Liên quan đến sự phổ biến ngày càng tăng của Rook, tôi muốn nói về những cạm bẫy và vấn đề đang chờ đợi bạn trong suốt chặng đường.
Giới thiệu về bản thân: Kinh nghiệm quản trị ceph từ phiên bản búa, người sáng lập cộng đồng trong điện tín.
Để không bị vô căn cứ, mình sẽ tham khảo các bài viết được Habr chấp nhận (đánh giá theo rating) về các vấn đề với ceph. Tôi cũng gặp phải hầu hết các vấn đề trong các bài viết này. Các liên kết đến tài liệu được sử dụng nằm ở cuối bài viết.
Trong bài viết về Rook, chúng tôi đề cập đến ceph là có lý do - Rook về cơ bản là ceph được bọc trong kubernetes, có nghĩa là nó kế thừa tất cả các vấn đề của nó. Hãy bắt đầu với các vấn đề về ceph.
Đơn giản hóa việc quản lý cụm
Một trong những lợi thế của Rook là dễ dàng quản lý ceph thông qua kuberentes.
Tuy nhiên, ceph chứa hơn 1000 tham số để cấu hình, đồng thời, thông qua rook, chúng ta chỉ có thể chỉnh sửa một số ít trong số đó.
Ví dụ về dạ quang
> ceph daemon mon.a hiển thị cấu hình | wc -l
1401
Rook được định vị là một cách thuận tiện để cài đặt và cập nhật ceph
Không có vấn đề gì khi cài đặt ceph mà không có Rook - playbook ansible được viết trong 30 phút, nhưng có rất nhiều vấn đề khi cập nhật.
Trích dẫn bài viết của Krok
Ví dụ: điều chỉnh crush không hoạt động chính xác sau khi cập nhật từ hummer lên gem
> chương trình điều chỉnh ceph osd crush
{
...
"straw_calc_version": 1,
"allow_bucket_algs": 22,
"hồ sơ": "không xác định"
"optimal_tunables": 0,
...
}
Nhưng ngay cả trong các phiên bản nhỏ cũng có vấn đề.
Ví dụ: Cập nhật 12.2.6 đưa cluster vào trạng thái lỗi về sức khỏe và PG bị hỏng có điều kiện
Không cập nhật, chờ đợi và kiểm tra? Nhưng có vẻ như chúng tôi sử dụng Rook để thuận tiện cho việc cập nhật, cùng nhiều mục đích khác.
Độ phức tạp của cụm khắc phục thảm họa ở Rook
Ví dụ: OSD gặp nhiều lỗi. Bạn nghi ngờ vấn đề nằm ở một trong các tham số trong config, bạn muốn thay đổi config cho một daemon cụ thể nhưng không thể vì bạn có kubernetes và DaemonSet.
Không có cách thay thế. ceph nói với osd.Num các đường tiêm không hoạt động - OSD đang nói dối.
Gỡ lỗi khó khăn
Một số thiết lập và kiểm tra hiệu năng yêu cầu kết nối trực tiếp với ổ cắm osd của daemon. Trong trường hợp của Rook, trước tiên bạn cần tìm vùng chứa mong muốn, sau đó vào đó, tìm công cụ còn thiếu để gỡ lỗi và rất khó chịu.
Khó nâng cao OSD một cách nhất quán
Ví dụ: OSD rơi vào OOM, việc tái cân bằng bắt đầu, sau đó những cái tiếp theo rơi xuống.
Giải pháp: Nâng lần lượt OSD lên, đợi cho đến khi nó được đưa hoàn toàn vào cụm rồi nâng cái tiếp theo. (Thêm chi tiết trong báo cáo của Ceph. Giải phẫu một thảm họa).
Trong trường hợp cài đặt trần, việc này được thực hiện đơn giản bằng tay; trong trường hợp Rook và một OSD trên mỗi nút, không có vấn đề cụ thể nào; các vấn đề về nâng thay thế sẽ phát sinh nếu OSD > 1 trên mỗi nút.
Tất nhiên, chúng có thể được giải quyết, nhưng chúng tôi sử dụng Rook để đơn giản hóa mọi thứ nhưng lại trở nên phức tạp hơn.
Khó khăn trong việc lựa chọn giới hạn cho quỷ ceph
Để cài đặt ceph bằng kim loại trần, việc tính toán các tài nguyên cần thiết cho một cụm là khá dễ dàng - có sẵn các công thức và nghiên cứu. Nếu đang sử dụng CPU yếu, bạn vẫn sẽ phải chạy một số bài kiểm tra hiệu năng để tìm hiểu xem Numa là gì, nhưng nó vẫn dễ hơn Rook.
Trong trường hợp của Rook, ngoài giới hạn bộ nhớ có thể tính toán được, bạn còn có câu hỏi về việc đặt giới hạn CPU.
Và ở đây bạn sẽ phải làm việc chăm chỉ với các bài kiểm tra hiệu suất. Nếu bạn hạ thấp giới hạn, bạn sẽ nhận được một cụm chậm; nếu bạn đặt không giới hạn, bạn sẽ nhận được mức sử dụng CPU hoạt động trong quá trình tái cân bằng, điều này sẽ ảnh hưởng xấu đến các ứng dụng của bạn trong kubernetes.
Sự cố mạng v1
Đối với ceph, nên sử dụng mạng 2x10GB. Một dành cho lưu lượng khách hàng, một dành cho nhu cầu dịch vụ ceph (cân bằng lại). Nếu bạn sống với ceph trên baremetal, thì việc phân chia này được cấu hình dễ dàng, nếu bạn sống với Rook, thì việc phân chia theo mạng sẽ gây ra sự cố cho bạn, do thực tế là không phải mọi cấu hình cụm đều cho phép bạn cấp hai mạng khác nhau vào nhóm .
Sự cố mạng v2
Nếu bạn từ chối tách các mạng thì khi cân bằng lại, lưu lượng ceph sẽ làm tắc toàn bộ kênh và các ứng dụng của bạn trong kubernetes sẽ chạy chậm lại hoặc gặp sự cố. Bạn có thể giảm tốc độ tái cân bằng ceph, nhưng sau đó do quá trình tái cân bằng kéo dài, bạn sẽ tăng nguy cơ nút thứ hai rơi ra khỏi cụm thông qua đĩa hoặc OOM và đã có chế độ chỉ đọc được đảm bảo cho cụm.
Cân bằng lại lâu - độ trễ ứng dụng dài
Trích dẫn từ bài viết của Ceph. Giải phẫu của một thảm họa.
Hiệu suất cụm thử nghiệm:
Một thao tác ghi có kích thước 4 KB mất 1 ms, hiệu suất là 1000 thao tác/giây trong 1 luồng.
Một thao tác 4 MB (kích thước đối tượng) mất 22 ms, hiệu suất là 45 thao tác/giây.
Do đó, khi một trong ba miền bị lỗi, cụm ở trạng thái xuống cấp trong một thời gian và một nửa số đối tượng nóng được phân phối trên các phiên bản khác nhau, thì một nửa thao tác ghi sẽ bắt đầu bằng quá trình khôi phục bắt buộc.
Chúng tôi tính toán khoảng thời gian phục hồi bắt buộc - ghi các thao tác vào một đối tượng bị xuống cấp.
Đầu tiên, chúng tôi đọc 4 MB trong 22 mili giây, ghi 22 mili giây và sau đó trong 1 mili giây, chúng tôi ghi 4 KB dữ liệu thực tế. Tổng cộng 45 mili giây cho mỗi thao tác ghi vào một đối tượng đã xuống cấp trên ổ SSD, khi hiệu suất tiêu chuẩn là 1 mili giây - hiệu suất giảm 45 lần.
Tỷ lệ đồ vật xuống cấp mà chúng ta có càng cao thì mọi thứ càng trở nên tồi tệ hơn.
Hóa ra tốc độ tái cân bằng là rất quan trọng để cụm hoạt động chính xác.
Cài đặt máy chủ cụ thể cho ceph
ceph có thể yêu cầu điều chỉnh máy chủ cụ thể.
Ví dụ: cài đặt sysctl và cùng JumboFrame, một số cài đặt này có thể ảnh hưởng tiêu cực đến tải trọng của bạn.
Nhu cầu thực sự đối với Rook vẫn còn là một dấu hỏi
Nếu bạn ở trên đám mây, bạn có bộ nhớ từ nhà cung cấp đám mây, điều này thuận tiện hơn nhiều.
Nếu bạn đang sử dụng máy chủ của riêng mình thì việc quản lý ceph sẽ thuận tiện hơn nếu không có kubernetes.
Bạn có thuê máy chủ từ một số dịch vụ lưu trữ giá rẻ không? Sau đó, bạn sẽ có rất nhiều niềm vui với mạng, độ trễ và băng thông của nó, những điều này rõ ràng ảnh hưởng tiêu cực đến ceph.
Tổng số: Triển khai kuberentes và triển khai lưu trữ là các nhiệm vụ khác nhau với đầu vào khác nhau và các tùy chọn giải pháp khác nhau - việc trộn lẫn chúng có nghĩa là tạo ra một sự đánh đổi có thể nguy hiểm vì lợi ích của cái này hay cái kia. Sẽ rất khó để kết hợp các giải pháp này ngay cả ở giai đoạn thiết kế và vẫn còn một thời gian hoạt động.
Danh sách tài liệu đã sử dụng:
Nhưng bạn nói Ceph... anh ấy có thực sự giỏi như vậy không?
Ceph. Giải phẫu của một thảm họa
Nguồn: www.habr.com