Cập nhật!. Trong phần bình luận, một độc giả đề nghị thử (có thể anh ấy đang tự mình nghiên cứu) nên tôi đã thêm một phần về giải pháp này. Tôi cũng đã viết , bởi vì quá trình này rất khác so với phần còn lại.
Thành thật mà nói, tôi đã từ bỏ và từ bỏ (ít nhất là ở thời điểm hiện tại). tôi sẽ sử dụng . Tại sao? Vì lưu trữ! Ai có thể nghĩ rằng tôi lại mày mò về bộ nhớ nhiều hơn là với chính Kubernetes. tôi sử dụng bởi vì nó rẻ và hiệu suất tốt và ngay từ đầu tôi đã triển khai các cụm bằng cách sử dụng . Tôi chưa thử các dịch vụ Kubernetes được quản lý từ Google/Amazon/Microsoft/DigitalOcean, v.v., v.v., vì tôi muốn tự mình tìm hiểu mọi thứ. Tôi cũng là người tiết kiệm.
Vì vậy, đúng vậy, tôi đã dành rất nhiều thời gian để cố gắng quyết định nên chọn bộ lưu trữ nào khi đánh giá một ngăn xếp Kubernetes khả thi. Tôi thích các giải pháp nguồn mở hơn, không chỉ vì giá cả mà còn xem xét một số tùy chọn trả phí vì tò mò vì chúng có các phiên bản miễn phí với những hạn chế. Tôi đã ghi lại một số con số từ các thử nghiệm gần đây khi so sánh các tùy chọn khác nhau và chúng có thể hữu ích với những người đang tìm hiểu về bộ lưu trữ Kubernetes. Mặc dù hiện tại cá nhân tôi đã nói lời tạm biệt với Kubernetes. Tôi cũng muốn đề cập đến , có thể cung cấp trực tiếp khối lượng Hetzner Cloud, nhưng tôi chưa thử. Tôi đã xem xét bộ lưu trữ được xác định bằng phần mềm đám mây vì tôi cần sao chép và khả năng gắn nhanh các ổ đĩa liên tục vào bất kỳ nút nào, đặc biệt trong trường hợp nút bị lỗi và các tình huống tương tự khác. Một số giải pháp cung cấp ảnh chụp nhanh theo thời điểm và sao lưu ngoài trang web, rất thuận tiện.
Tôi đã thử nghiệm 6-7 giải pháp lưu trữ:
Như tôi đã nói Sau khi thử nghiệm hầu hết các tùy chọn trong danh sách, ban đầu tôi quyết định chọn OpenEBS. OpenEBS rất dễ cài đặt và sử dụng, nhưng thành thật mà nói, sau khi thử nghiệm với dữ liệu thực đang tải, tôi rất thất vọng với hiệu suất của nó. Đây là nguồn mở và các nhà phát triển tự mình làm việc luôn rất hữu ích khi tôi cần sự giúp đỡ. Thật không may, nó có hiệu suất rất kém so với các lựa chọn khác nên các cuộc thử nghiệm phải được chạy lại. OpenEBS hiện có 3 công cụ lưu trữ, nhưng tôi đang đăng kết quả điểm chuẩn cho cStor. Tôi chưa có số cho Jiva và LocalPV.
Tóm lại, Jiva nhanh hơn một chút và LocalPV nói chung là nhanh, không tệ hơn so với điểm chuẩn đĩa trực tiếp. Vấn đề với LocalPV là ổ đĩa chỉ có thể được truy cập trên nút nơi nó đã được chuẩn bị và không có sự sao chép nào cả. Tôi gặp một số vấn đề khi khôi phục bản sao lưu qua trên một cụm mới vì tên nút khác nhau. Nếu chúng ta nói về việc sao lưu, cStor có , nhờ đó bạn có thể tạo bản sao lưu ảnh chụp nhanh bên ngoài trang web tại một thời điểm, thuận tiện hơn so với sao lưu cấp tệp bằng Velero-Restic. tôi đã viết , để giúp quản lý bản sao lưu và khôi phục dễ dàng hơn bằng plugin này. Nhìn chung, tôi thực sự thích OpenEBS, nhưng hiệu suất của nó...
Rook cũng là nguồn mở và khác với các tùy chọn còn lại trong danh sách ở chỗ nó là bộ điều phối lưu trữ thực hiện các tác vụ quản lý lưu trữ phức tạp với các chương trình phụ trợ khác nhau, ví dụ: , và những thứ khác, giúp đơn giản hóa công việc rất nhiều. Tôi gặp vấn đề với EfgeFS khi dùng thử nó vài tháng trước, vì vậy tôi chủ yếu thử nghiệm với Ceph. Ceph không chỉ cung cấp lưu trữ khối mà còn cung cấp lưu trữ đối tượng tương thích với S3/Swift và hệ thống tệp phân tán. Điều tôi thích ở Ceph là khả năng phân tán dữ liệu ổ đĩa trên nhiều đĩa để ổ đĩa có thể sử dụng nhiều dung lượng đĩa hơn mức có thể chứa trên một đĩa đơn. Thật thoải mái. Một tính năng thú vị khác là khi bạn thêm đĩa vào một cụm, nó sẽ tự động phân phối lại dữ liệu trên tất cả các đĩa.
Ceph có ảnh chụp nhanh, nhưng theo tôi biết, chúng không thể được sử dụng trực tiếp trong Rook/Kubernetes. Đúng là tôi không đi sâu vào vấn đề này. Nhưng không có bản sao lưu bên ngoài trang web, vì vậy bạn sẽ phải sử dụng thứ gì đó với Velero/Restic, nhưng chỉ có bản sao lưu cấp tệp chứ không có ảnh chụp nhanh theo thời điểm. Điều tôi thực sự thích ở Rook là làm việc với Ceph dễ dàng như thế nào - nó ẩn hầu hết mọi thứ phức tạp và cung cấp các công cụ để nói chuyện trực tiếp với Ceph để khắc phục sự cố. Thật không may, trong quá trình kiểm tra căng thẳng về khối lượng Ceph, tôi liên tục gặp vấn đề với , khiến Ceph trở nên bất ổn. Vẫn chưa rõ đây là lỗi của chính Ceph hay là vấn đề trong cách Rook quản lý Ceph. Tôi đã mày mò cài đặt bộ nhớ và nó đã tốt hơn nhưng vấn đề vẫn chưa được giải quyết hoàn toàn. Ceph có hiệu suất khá tốt, như bạn có thể thấy trong các điểm chuẩn bên dưới. Nó cũng có một bảng điều khiển tốt.
Tôi thực sự thích Longhorn. Theo tôi, đây là một giải pháp đầy hứa hẹn. Đúng vậy, bản thân các nhà phát triển (Rancher Labs) thừa nhận rằng nó chưa phù hợp với môi trường làm việc và điều này cho thấy. Đó là nguồn mở và có hiệu suất tốt (mặc dù họ chưa tối ưu hóa nó), nhưng các ổ đĩa mất rất nhiều thời gian để kết nối với nhóm và trong trường hợp xấu nhất, phải mất 15-16 phút, đặc biệt là sau khi khôi phục một bản sao lưu lớn hoặc nâng cấp khối lượng công việc. Nó có các ảnh chụp nhanh và bản sao lưu bên ngoài của những ảnh chụp nhanh này, nhưng chúng chỉ áp dụng cho các ổ đĩa, vì vậy bạn vẫn sẽ cần thứ gì đó như Velero để sao lưu các tài nguyên khác. Sao lưu và khôi phục rất đáng tin cậy, nhưng khá chậm. Nghiêm túc mà nói, cực kỳ chậm. Mức sử dụng CPU và tải hệ thống thường tăng đột biến khi làm việc với lượng dữ liệu trung bình trong Longhorn. Có bảng điều khiển thuận tiện để quản lý Longhorn. Tôi đã nói rằng tôi thích Longhorn nhưng nó cần phải cải thiện một chút.
StorageOS là sản phẩm trả phí đầu tiên trong danh sách. Nó có phiên bản dành cho nhà phát triển với kích thước lưu trữ được quản lý giới hạn là 500GB, nhưng tôi không nghĩ có giới hạn về số lượng nút. Bộ phận bán hàng nói với tôi rằng chi phí bắt đầu từ 125 USD mỗi tháng cho 1 TB, nếu tôi nhớ không lầm. Có một bảng điều khiển cơ bản và một CLI tiện lợi, nhưng có điều gì đó kỳ lạ đang xảy ra với hiệu suất: trong một số điểm chuẩn thì nó khá tốt, nhưng trong bài kiểm tra căng thẳng về âm lượng, tôi không thích tốc độ chút nào. Nói chung là không biết nói gì. Vì vậy, tôi thực sự không hiểu nhiều. Không có bản sao lưu bên ngoài trang web nào ở đây và bạn cũng sẽ phải sử dụng Velero với Restic để sao lưu các ổ đĩa. Thật kỳ lạ, vì sản phẩm được trả tiền. Và các nhà phát triển không hào hứng giao tiếp trên Slack.
Tôi biết đến Robin trên Reddit từ giám đốc kỹ thuật của họ. Tôi chưa bao giờ nghe nói về anh ấy trước đây. Có lẽ vì tôi đang tìm kiếm giải pháp miễn phí nên Robin được trả tiền. Họ có phiên bản miễn phí khá hào phóng với 10TB dung lượng lưu trữ và ba nút. Nhìn chung, sản phẩm khá tốt và có nhiều tính năng tốt. Có một CLI tuyệt vời, nhưng điều thú vị nhất là bạn có thể chụp nhanh và sao lưu toàn bộ ứng dụng (trong bộ chọn tài nguyên, đây được gọi là bản phát hành Helm hoặc “ứng dụng linh hoạt”), bao gồm cả khối lượng và các tài nguyên khác, do đó bạn có thể làm mà không cần Velero. Và mọi thứ sẽ tuyệt vời nếu không có một chi tiết nhỏ: nếu bạn khôi phục (hoặc "nhập", như cách gọi của Robin) một ứng dụng trên một cụm mới - ví dụ: trong trường hợp khôi phục sau thảm họa - khôi phục, tất nhiên là có tác dụng nhưng việc tiếp tục sao lưu ứng dụng thì bị cấm. Điều này đơn giản là không thể thực hiện được trong phiên bản này, như các nhà phát triển đã xác nhận. Nói một cách nhẹ nhàng thì điều này có vẻ lạ, đặc biệt khi xét đến các ưu điểm khác (ví dụ: sao lưu và khôi phục cực kỳ nhanh). Các nhà phát triển hứa sẽ sửa chữa mọi thứ trong phiên bản tiếp theo. Hiệu suất nói chung là tốt, nhưng tôi nhận thấy một điều kỳ lạ: nếu tôi chạy điểm chuẩn trực tiếp trên ổ đĩa được gắn vào máy chủ, tốc độ đọc sẽ nhanh hơn nhiều so với việc chạy cùng một ổ đĩa từ bên trong nhóm. Tất cả các kết quả khác đều giống nhau, nhưng về mặt lý thuyết sẽ không có sự khác biệt. Mặc dù họ đang nghiên cứu nó nhưng tôi vẫn khó chịu về vấn đề khôi phục và sao lưu - tôi nghĩ cuối cùng tôi đã tìm được giải pháp phù hợp và thậm chí tôi sẵn sàng trả tiền cho giải pháp đó khi tôi cần thêm dung lượng hoặc nhiều máy chủ hơn.
Tôi không có nhiều điều để nói ở đây. Đây là một sản phẩm trả phí, không kém phần ngầu và đắt tiền. Hiệu suất chỉ đơn giản là tuyệt vời. Đây là chỉ số tốt nhất cho đến nay. Slack nói với tôi rằng giá bắt đầu ở mức 205 USD mỗi tháng cho mỗi nút, như được liệt kê trên GKE Marketplace của Google. Không biết mua trực tiếp có rẻ hơn không. Dù sao thì tôi cũng không đủ khả năng chi trả, vì vậy tôi rất rất thất vọng vì giấy phép dành cho nhà phát triển (tối đa 1 TB và 3 nút) thực tế vô dụng với Kubernetes trừ khi bạn hài lòng với việc cung cấp tĩnh. Tôi đã hy vọng rằng giấy phép số lượng lớn sẽ tự động hạ cấp xuống nhà phát triển khi kết thúc thời gian dùng thử, nhưng điều đó đã không xảy ra. Giấy phép nhà phát triển chỉ có thể được sử dụng trực tiếp với Docker và cấu hình trong Kubernetes rất cồng kềnh và hạn chế. Tất nhiên, tôi thích nguồn mở hơn, nhưng nếu có tiền, tôi chắc chắn sẽ chọn Portworx. Cho đến nay, hiệu suất của nó đơn giản là không thể so sánh với các tùy chọn khác.
Tôi đã thêm phần này sau khi bài đăng được xuất bản, khi một độc giả đề nghị dùng thử Linstor. Tôi đã thử nó và tôi thích nó! Nhưng chúng ta vẫn cần đào sâu hơn. Bây giờ tôi có thể nói rằng hiệu suất không tệ (tôi đã thêm kết quả benchmark bên dưới). Về cơ bản, tôi nhận được hiệu suất tương tự như đĩa trực tiếp mà không cần bất kỳ chi phí nào. (Đừng hỏi trực tiếp tại sao Portworx có số liệu tốt hơn điểm chuẩn ổ đĩa. Tôi không biết. Tôi đoán là có phép thuật.) Vì vậy, Linstor có vẻ rất hiệu quả cho đến nay. Nó không khó cài đặt nhưng cũng không dễ như các tùy chọn khác. Trước tiên, tôi phải cài đặt Linstor (mô-đun hạt nhân và các công cụ/dịch vụ) cũng như định cấu hình LVM để hỗ trợ cung cấp nhanh và kết xuất nhanh bên ngoài Kubernetes, trực tiếp trên máy chủ, sau đó tạo các tài nguyên cần thiết để sử dụng bộ nhớ từ Kubernetes. Tôi không thích nó không hoạt động trên CentOS và tôi phải sử dụng Ubuntu. Tất nhiên, không tệ lắm, nhưng hơi khó chịu, vì tài liệu (nhân tiện, tài liệu này rất xuất sắc) đề cập đến một số gói không thể tìm thấy trong kho Epel được chỉ định. Linstor có các ảnh chụp nhanh nhưng không có bản sao lưu bên ngoài trang web, vì vậy ở đây một lần nữa tôi phải sử dụng Velero với Restic để sao lưu các ổ đĩa. Tôi thích ảnh chụp nhanh thay vì sao lưu ở cấp độ tệp, nhưng điều này có thể được chấp nhận nếu giải pháp hiệu quả và đáng tin cậy. Linstor là nguồn mở nhưng có hỗ trợ trả phí. Nếu tôi hiểu đúng thì có thể sử dụng không hạn chế, kể cả khi bạn không có hợp đồng hỗ trợ, nhưng điều này cần phải làm rõ. Tôi không biết Linstor đã được thử nghiệm như thế nào đối với Kubernetes, nhưng bản thân lớp lưu trữ nằm ngoài Kubernetes và rõ ràng là giải pháp này chưa xuất hiện ngày hôm qua, vì vậy có lẽ nó đã được thử nghiệm trong điều kiện thực tế. Có giải pháp nào ở đây có thể khiến tôi thay đổi ý định và quay lại Kubernetes không? Tôi không biết. Chúng ta vẫn cần đào sâu hơn và nghiên cứu nhân rộng. Hãy xem nào. Nhưng ấn tượng đầu tiên là tốt. Tôi chắc chắn thích sử dụng cụm Kubernetes của riêng mình thay vì Heroku để có nhiều tự do hơn và học hỏi những điều mới. Vì Linstor không dễ cài đặt như những loại khác nên tôi sẽ sớm viết một bài về nó.
Điểm chuẩn
Thật không may, tôi không ghi chú nhiều về sự so sánh vì tôi không nghĩ mình sẽ viết về nó. Tôi chỉ có kết quả từ các điểm chuẩn fio cơ bản và chỉ dành cho các cụm nút đơn, vì vậy tôi chưa có số liệu cho các cấu hình được sao chép. Nhưng từ những kết quả này, bạn có thể biết sơ bộ về những gì mong đợi từ mỗi tùy chọn, vì tôi đã so sánh chúng trên cùng một máy chủ đám mây, 4 lõi, RAM 16 GB và có thêm 100 GB ổ đĩa cho các ổ đĩa được thử nghiệm. Tôi đã chạy điểm chuẩn ba lần cho mỗi giải pháp và tính kết quả trung bình, đồng thời đặt lại cài đặt máy chủ cho từng sản phẩm. Tất cả điều này hoàn toàn không khoa học, chỉ để bạn có một ý tưởng chung chung. Trong các thử nghiệm khác, tôi đã sao chép 38 GB ảnh và video từ ổ đĩa để kiểm tra khả năng đọc và viết, nhưng than ôi, tôi đã không lưu các con số. Tóm lại: Portworkx nhanh hơn nhiều.
Đối với điểm chuẩn âm lượng, tôi đã sử dụng bảng kê khai này:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4Trước tiên, tôi tạo một ổ đĩa với lớp lưu trữ thích hợp và sau đó thực hiện công việc với fio ở hậu trường. Mình lấy 1 GB để ước tính hiệu năng và không phải chờ đợi quá lâu. Dưới đây là kết quả:
Tôi đã đánh dấu giá trị tốt nhất cho từng chỉ số bằng màu xanh lá cây và giá trị tệ nhất bằng màu đỏ.
Kết luận
Như bạn có thể thấy, trong hầu hết các trường hợp, Portworx hoạt động tốt hơn những trường hợp khác. Nhưng đối với tôi nó đắt tiền. Tôi không biết Robin giá bao nhiêu, nhưng họ có phiên bản miễn phí tuyệt vời, vì vậy nếu bạn muốn một sản phẩm trả phí, bạn có thể dùng thử (hy vọng họ sẽ sớm khắc phục được sự cố với khôi phục và sao lưu). Trong số ba ứng dụng miễn phí, tôi gặp ít vấn đề nhất với OpenEBS, nhưng hiệu suất của nó rất tệ. Thật đáng tiếc là tôi đã không lưu được nhiều kết quả hơn, nhưng tôi hy vọng những con số và nhận xét của tôi sẽ giúp ích cho bạn.
Nguồn: www.habr.com
