26
4
CFSDN nhấn mạnh vào giá trị tạo ra nguồn mở và chúng tôi cam kết xây dựng nền tảng chia sẻ tài nguyên để mọi nhân viên CNTT có thể tìm thấy thế giới tuyệt vời của bạn tại đây.
Bài viết blog CFSDN này đánh giá hiệu suất và chi phí của CephFS trên các máy chủ mật độ cao. Nó được tác giả sưu tầm và biên soạn. Nếu bạn quan tâm đến bài viết này, hãy nhớ thích nó.
Trong vài năm tới, lượng lớn dữ liệu mà Máy Va chạm Hạt Lớn thu được sẽ đặt ra yêu cầu cao hơn về thông lượng, dung lượng và độ bền lưu trữ của CERN. Công nghệ tiên tiến nhất trong các hệ thống lưu trữ nguồn mở thể hiện khả năng hấp dẫn và sự trưởng thành. Đồng thời, chúng tôi cũng tập trung vào câu hỏi liệu các thành phần này có đóng vai trò như thế nào trong các hệ thống lưu trữ vật lý trong tương lai hay không và như thế nào.
Phần mềm có sẵn thiếu các tính năng nâng cao quan trọng và có ít bằng chứng về hiệu quả của phần cứng tối ưu hóa chi phí quan trọng đối với dự án vật lý LHC; tuy nhiên, một giải pháp hoàn chỉnh có thể được xây dựng bằng cách xếp các cổng dành riêng cho HEP lên trên các cổng mở; nguồn sản phẩm. Trong bài viết này, chúng tôi mô tả và đánh giá hệ thống lưu trữ cụm nguồn mở mới, CEPFS, kết hợp với EOS, một giải pháp lưu trữ hiệu suất cao, chi phí thấp được CERN thiết kế để thu thập dữ liệu LHC.
CephFS là một hệ thống tệp cụm hiện đại, đóng vai trò thay thế NFS trong các tình huống điện toán điển hình trong một trung tâm dữ liệu duy nhất, bao gồm các thư mục chính, khu vực tổ chức HPC hoặc bộ nhớ dùng chung cho các ứng dụng phân tán khác. Phần mềm triển khai kiến trúc mở rộng quy mô cho dữ liệu và siêu dữ liệu IOPS: dữ liệu và siêu dữ liệu được lưu giữ trong bộ lưu trữ đối tượng phân tán RADOS và siêu dữ liệu được quản lý bởi một số lượng nhỏ máy chủ MDS có thể thay thế.
Công suất và hiệu suất có thể được tăng lên một cách linh hoạt mà không có thời gian ngừng hoạt động: công suất thô và IOPS được mở rộng bằng cách thêm máy chủ vào chương trình phụ trợ RADOS và siêu dữ liệu được mở rộng bằng cách phân bổ lại cây con hệ thống tệp cho máy chủ MDS mới. RADOS cung cấp khả năng lưu trữ đối tượng liên tục bằng cách sử dụng các bản sao (thường là 3 bản sao) hoặc mã sửa lỗi, chẳng hạn như sử dụng bốn sọc dữ liệu và hai sọc chẵn lẻ (EC4,2). RADOS sử dụng CRUSH để đặt các đối tượng vào các miền lỗi: bằng cách này, hệ thống có thể được thiết kế để chịu đựng các lỗi ở đĩa, máy chủ, giá đỡ, nguồn điện hoặc mức chuyển đổi.
CephFS được thiết kế để cung cấp sự đảm bảo tính nhất quán giống như hệ thống tệp cục bộ. Để đạt được điều này, MDS ủy quyền một loạt chức năng IO cho máy khách, cho phép thực thi đồng bộ hoặc không đồng bộ các hoạt động POSIX khác nhau dựa trên nhu cầu thời gian thực để truy cập song song vào các thư mục và tệp. Ví dụ: một tệp được mở bởi một trình ghi mà không có ứng dụng khách nào khác có thể được ghi nhanh chóng thông qua bộ đệm ứng dụng khách và chỉ tồn tại định kỳ, trong khi một tệp có chức năng ghi/đọc đồng thời phải được duy trì đồng bộ và ứng dụng khách không được phép lưu vào bộ nhớ đệm Đọc.
CERN đã chạy nhiều cụm CephFS trong sản xuất kể từ năm 2017 và tính đến năm 2021, chúng tôi đang sử dụng CephFS trong ba môi trường:
Trong những môi trường này, CephFS đã chứng minh được tính mạnh mẽ và hiệu suất của mình qua nhiều năm hoạt động. Các cụm Ceph này và các cụm Ceph khác tại CERN đã gặp phải một số lần ngừng hoạt động bên ngoài và trải qua ba chu kỳ mua sắm phần cứng: trong giai đoạn này, chúng tôi nhận thấy một số sự cố liên quan đến tính khả dụng, mất mát hoặc hỏng dữ liệu.
Bất chấp những ưu điểm này, CephFS hiện bị giới hạn tại CERN trong các trường hợp sử dụng được liệt kê trước đó vì nó thiếu một số tính năng quan trọng đối với cộng đồng vật lý năng lượng cao:
Ngoài ra, CephFS chưa được thử nghiệm rộng rãi tại CERN với việc thu thập dữ liệu LHC thông lượng cao, chẳng hạn như tốc độ ghi vượt quá 20GiB/s.
EOS là một hệ thống lưu trữ quy mô lớn do CERN phát triển, hiện cung cấp dung lượng 350 PB cho các thí nghiệm vật lý và người dùng thông thường của cơ sở hạ tầng CERN. Kể từ lần triển khai đầu tiên vào năm 2010, EOS đã phát triển và thích ứng với những thách thức do yêu cầu về dung lượng lưu trữ ngày càng tăng.
EOS được triển khai dưới dạng plug-in của khung XRootD. Các tệp được lưu trữ bằng cách sử dụng mã sao chép hoặc sửa lỗi và QuarkDB được sử dụng làm chương trình phụ trợ bền vững. Dịch vụ MGM ngoại vi cung cấp quyền truy cập được lưu vào bộ nhớ đệm vào các không gian tên và siêu dữ liệu khác. Các nút lưu trữ chạy một hoặc nhiều dịch vụ FST để cung cấp quyền truy cập vào dữ liệu được lưu trữ trên các hệ thống tệp được cài đặt cục bộ (FileIO [posix]) hoặc bộ lưu trữ từ xa (XrdIo [giao thức gốc], DavixIo [Webdav/S3]). Đối với hệ thống tệp Linux, các tệp được tổ chức thành các nút.
Dịch vụ MGM chuyển đổi tên đường dẫn logic thành inode và máy chủ FST lưu trữ tất cả dữ liệu theo tên inode. Không gian tên trên hệ thống tệp FST cục bộ hoặc từ xa được tổ chức bằng cách sử dụng các thư mục tiền tố băm inode đơn giản và tên inode thập lục phân để xây dựng đường dẫn vật lý đến số inode nhất định. Các tính năng bắt buộc duy nhất của hệ thống tệp cục bộ FST là ngữ nghĩa POSIX cơ bản và các thuộc tính mở rộng.
Do đó, việc thay thế hệ thống tệp FST cục bộ bằng CephFS rất đơn giản. Trong trường hợp này, dữ liệu được truy cập thông qua FST sử dụng hệ thống tệp CephFS từ xa. Trong mô hình triển khai như vậy, tính dự phòng và tính sẵn sàng cao của dữ liệu được ủy quyền cho lớp CephFS và EOS được định cấu hình để lưu trữ các tệp có bố cục một bản sao.
Phần phụ trợ bao gồm tám máy chủ đĩa, mỗi máy chủ có các thông số kỹ thuật sau:
Những máy chủ đĩa mật độ cao này chưa được đưa vào sử dụng sản xuất tại CERN. Hiện tại, EOS sử dụng các máy chủ có bốn khung 24 đĩa được kết nối với giao diện người dùng có bộ nhớ 192 GiB. Do cần có lượng bộ nhớ lớn cho mỗi Ceph OSD, các hệ thống EOS 96 đĩa này yêu cầu phân cụm đĩa hoặc bộ nhớ bổ sung. Ngược lại, các máy chủ mật độ cao được đánh giá trong PoC của chúng tôi là lý tưởng vì chúng cung cấp 3 GiB bộ nhớ cho mỗi OSD.
Trên phần cứng này, chúng tôi đã cài đặt Ceph bằng Octopus phiên bản 15.2.8. Mỗi máy chủ đều có sẵn đĩa để chạy 61 Ceph OSD: HDD và SSD để lưu trữ nhóm dữ liệu và siêu dữ liệu CephFS tương ứng. Một máy ảo máy chủ đĩa không cục bộ hoạt động như MON, MGR và MDS của cụm. CephFS được định cấu hình với các thư mục cấp cao nhất, mỗi thư mục được hỗ trợ bởi một nhóm RADOS khác nhau và mã hóa xóa và CRUSH được định cấu hình như sau:
Ngoài ra, chúng tôi đã đánh giá tác động của kích thước đối tượng đến hiệu suất bằng cách sử dụng các thuộc tính mở rộng bố cục tệp của CephFS. Các nhóm vị trí RADOS được cân bằng theo độ lệch tối đa của từng OSD.
Hình 1.
Quá trình thiết lập đã được thử nghiệm bằng cách sử dụng tám máy chủ đĩa phụ trợ (khối 1-8) chạy Ceph OSD và tám giao diện người dùng (khối 9-16) chạy kernel EOS FST và CephFS. MGM và MDS xử lý siêu dữ liệu của EOS và CephFS tương ứng. Siêu dữ liệu CephFS được lưu trữ trên SSD, trong khi các đối tượng dữ liệu được lưu trữ trên HDD.
Chúng tôi đã sử dụng tám máy giống hệt khác làm nút EOS FST và cài đặt CephFS bằng máy khách kernel đi kèm với CentOS 8.2. Đối với mỗi FST, chúng tôi đã tạo một thư mục dữ liệu riêng trong thư mục gắn kết CephFS và định cấu hình chúng thành tám hệ thống tệp EOS. Thiết lập được hiển thị trong Hình 1, trong khi Hình 2 và 3 hiển thị cấu hình hệ thống tệp và không gian EOS.
Hình 2.
Cấu hình không gian ceph được cung cấp bởi tám khung gắn CephFS:
Hình 3.
Cấu hình hệ thống tệp của 8 mount CephFS trong không gian ceph của EOS.
Chúng tôi đã thực hiện hai bộ điểm chuẩn để đánh giá hiệu suất của các dịch vụ phụ trợ CephFS và giao diện người dùng EOS:
Mỗi điểm chuẩn sử dụng 10 luồng song song trên mỗi ngàm ceph (tổng cộng 80 luồng) để tạo/ghi hoặc đọc các tệp có dung lượng 2 GB mỗi luồng. Điểm chuẩn thường được thực thi trong vài giờ để quan sát hoạt động ổn định; để kiểm tra mức độ suy giảm hiệu suất, chúng tôi cũng kiểm tra khả năng hỗ trợ khi CephFS được lấp đầy 95%. Trong các điểm chuẩn giao diện người dùng, số lượng luồng đồng thời có thể dao động tùy thuộc vào thiết kế. Số luồng trung bình trên mỗi lần gắn máy khách lại được định cấu hình thành 10. Chúng tôi cũng đã điều chỉnh các tham số kích thước đối tượng RADOS để cải thiện hiệu suất ghi cho từng bố cục được mã hóa xóa.
Chúng tôi đã điểm chuẩn bộ điều khiển gốc và tốc độ mạng. Trong điều kiện tải tối ưu, cả hai đường dẫn IO đều đáp ứng thông số thiết kế là 12 GiB/s. Ngoài ra, chúng tôi đã đo giới hạn của một máy khách hạt nhân CephFS duy nhất; tốc độ đọc và ghi lên tới 6 GiB/s. Hình 4 cho thấy thông lượng ghi tỷ lệ tuyến tính với số lượng máy khách cho đến khi 6 trên 8 nút máy khách đạt hiệu suất ghi cụm tối đa. Hình 5 cũng cho thấy rằng khi thực hiện đủ công việc đồng thời, thông lượng đọc không bị giới hạn ở máy khách: ban đầu, việc đọc sẽ mở rộng theo kiểu tuyến tính và sau đó hiển thị đường cong giảm dần, rất có thể là do thời gian tìm đĩa tăng lên khi số lượng đồng thời tăng lên. của các luồng.
Hình 4.
Chia tỷ lệ hiệu suất cho việc ghi với số lượng nút máy khách bằng cách sử dụng EC16,2;64M. Viết thang đo thông lượng theo số lượng client cho đến khi có 6 trên 8 client chạy đồng thời:
Hình 5.
Chia tỷ lệ hiệu suất với số lượng nút máy khách đọc bằng EC16,2;64M. Hiệu suất đọc bắt đầu tăng theo tỷ lệ tuyến tính nhưng giảm dần trên 3 luồng đồng thời.
Hình 6 cho thấy sự phụ thuộc của hiệu suất ghi tương đối vào mức sử dụng ổ đĩa: hiệu suất 100% tương đương với 31 GiB/s. Sự xuống cấp phù hợp với mức tăng IO chờ đợi trên các nút OSD được quan sát thấy.
Hình 6.
Mối tương quan giữa hiệu suất ghi với tổng mức sử dụng CephFS. Hiệu suất cao nhất đạt được khi CephFS phụ trợ đầy từ 0 đến 50%, nhưng mức sử dụng trên 75% sẽ làm giảm hiệu suất.
Bảng 1, Hình 7 và 8 tóm tắt hiệu suất ghi được đo cho các bố cục mã sửa lỗi khác nhau và kích thước đối tượng có mức sử dụng không gian dưới 10%. Bảng 2, Hình 9 và 10 tóm tắt hiệu suất đọc được đo cho các bố cục mã xóa, kích thước đối tượng và kích thước khối đọc khác nhau với mức sử dụng không gian dưới 10%. Cả hai bảng đều hiển thị thời gian trung bình để tải lên hoặc tải xuống tệp 2 GiB chạy 80 lệnh dd song song trên 8 nút máy khách. Mỗi điểm chuẩn sử dụng 8000 tệp và 16 TiB dữ liệu. Ngoài ra, độ lệch chuẩn, tốc độ dòng trung bình, phân vị thứ 99 và thời gian IO tối đa được hiển thị.
Rõ ràng là phát trực tuyến hiệu suất cao ưu tiên kích thước khối lớn. EC16,2 cung cấp thông lượng ghi cao nhất vì nó có tải chẵn lẻ nhỏ nhất so với cấu hình EC8,2 hoặc EC4,2, tuy nhiên, các kích thước khối này có đuôi dài do phương sai tăng lên trong phân bổ đối tượng; Hiệu ứng của kích thước khối thậm chí còn rõ rệt hơn khi đọc. Cài đặt đọc trước mặc định cho các lần gắn kernel là 8 MiB; kích thước khối lớn hơn mức này sẽ giúp cải thiện thông lượng đọc. Tác động của kích thước đối tượng cũng sẽ hiển thị trên các lần đọc, vì dự kiến sẽ có nhiều lượt tìm kiếm đĩa hơn trên mỗi GiB được phân phối.
Bảng 1 Hiệu suất ghi cho các bố cục mã hóa xóa khác nhau (ECk,m) và kích thước đối tượng (; s M). Thời gian và tốc độ IO được hiển thị trên mỗi luồng tệp 2 GiB và 80 luồng IO đồng thời:
Hình 7.
Phần đuôi hiệu suất ghi: Đường màu đỏ hiển thị thời gian tải lên trung bình, giới hạn hộp hiển thị phân vị thứ 99 và giới hạn lỗi hiển thị thời gian tải lên tối đa được quan sát đối với bố cục mã hóa xóa nhất định. Dựa trên dữ liệu trong Bảng 1:
Hình 8.
Tốc độ ghi trung bình và độ lệch chuẩn cho các bố cục mã hóa xóa khác nhau, dựa trên dữ liệu trong Bảng 1.
Bảng 2 Đọc các phép đo hiệu suất cho các bố cục mã xóa khác nhau (ECk,m), kích thước đối tượng (; s M) và kích thước khối dd (, b M):
Thời gian và tốc độ IO được hiển thị dưới dạng 80 luồng song song trên mỗi luồng tệp 2 GiB. Sử dụng cài đặt đọc trước kernel mặc định là 8 MiB.
Hình 9.
Phần đuôi hiệu suất đọc: Đường màu đỏ hiển thị thời gian tải xuống trung bình, giới hạn hộp hiển thị phân vị thứ 99 và giới hạn lỗi là thời gian tải xuống tối đa được quan sát đối với bố cục mã hóa xóa nhất định. Dựa trên dữ liệu trong Bảng 2.
Hình 10.
Tốc độ đọc trung bình và độ lệch chuẩn cho các bố cục mã hóa xóa khác nhau dựa trên dữ liệu trong Bảng 2.
Bảng 3, được hiển thị trong Hình 11, cho thấy tác động của việc truy cập CephFS thông qua EOS dưới dạng dịch vụ ngoại vi. Hiệu suất tổng thể không thay đổi, nhưng việc sử dụng giao thức XRootD sẽ làm tăng hiệu ứng đuôi do lập lịch ghi luồng không công bằng. Những hiệu ứng đuôi này có thể được loại bỏ bằng cách giới hạn mỗi luồng ở một máy khách danh nghĩa 325/350 MiB/s. Hiệu suất đọc thực sự được hưởng lợi từ giao diện người dùng, vì kích thước khối được sử dụng trong quá trình truyền EOS lớn hơn so với so sánh cơ bản của chương trình phụ trợ CephFS gốc.
Bảng 3 So sánh hiệu suất phụ trợ CephFS gốc và quyền truy cập dịch vụ thông qua giao diện EOS cho các bố cục mã hóa xóa khác nhau (ECk, m), kích thước đối tượng (; s M) và kích thước khối IO (, b M):
Khi sử dụng EOSaa và EOSbb, chúng tôi giới hạn ứng dụng khách ở mức tương ứng là 325 MiB/s và 350 MiB/s.
Hình 11.
Trực quan hóa tác động của việc thêm giao diện người dùng EOS vào phụ trợ CephFS dựa trên dữ liệu trong Bảng 3.
Trong quá trình đánh giá hiệu suất, chúng tôi đã gặp phải một số vấn đề với cấu hình Ceph mặc định và các cảnh báo dưới mức tối ưu:
Máy khách giới hạn số byte khi truyền Theo mặc định, máy khách librados giới hạn số lần ghi nhanh chóng ở mức 100MiB. Chúng tôi nhận thấy rằng giới hạn này thường xuyên bị đạt đến, do đó hạn chế hiệu suất ghi có thể đạt được. Việc đặt objecter_inflight_op_bytes thành 10485760000 sẽ loại bỏ giới hạn nhân tạo này.
Điều chỉnh gọi lại giới hạn MDS Quy trình fsck của EOS được sử dụng để kiểm tra tính nhất quán của không gian tên EOS và bộ lưu trữ CEPFS phía sau. Quá trình này gây áp lực liên tục lên MDS để đếm tất cả các tệp nhanh nhất có thể, điều này có thể dẫn đến tình huống khách hàng nhận được CAP nhanh hơn mức MDS có thể yêu cầu thu hồi, khiến MDS phát sinh lỗi hết bộ nhớ . Cải thiện cài đặt thu hồi giới hạn mặc định, tăng hiệu quả tỷ lệ cấp/thu hồi giới hạn lên hơn 5 lần và được cộng đồng thượng nguồn đề xuất và chấp nhận. Ngoài ra, EOS fsck hiện có thể được điều chỉnh để quét các không gian tên theo các khoảng thời gian có thể định cấu hình.
Một OSD có độ trễ cao duy nhất đã có tác động nghiêm trọng: Trong các thử nghiệm của chúng tôi, hiệu suất ghi trên toàn cụm đã giảm từ mức danh nghĩa 25 GiB/s xuống dưới 5 GiB/s. Sau khi khắc phục sự cố, người ta nhận thấy rằng kết nối SATA vật lý của một ổ cứng HDD kém và yêu cầu IO tối thiểu mất trung bình hơn 2 giây. Khi đĩa được xóa khỏi cụm, hiệu suất dự kiến sẽ được khôi phục. Loại vấn đề này chưa từng xảy ra trong quá trình sản xuất tại CERN trước đây. Vì Ceph hiện không phát hiện và cảnh báo về những vấn đề như vậy nên chúng tôi hiện đang phát triển một công cụ thăm dò bên ngoài để cảnh báo khi phát hiện thấy độ trễ OSD bất thường và sẽ cung cấp công cụ này ngược dòng nếu nó tỏ ra hữu ích.
Thiết lập dựa trên máy chủ đĩa mật độ cao được đánh giá mang lại hiệu suất tuyệt vời theo nhiều sơ đồ mã hóa xóa khác nhau và cho phép mỗi nút phân phối tải dữ liệu đọc và ghi lên tới 4 GiB/s để truy cập phát trực tuyến. Sự suy giảm hiệu suất lớn xảy ra khi mức sử dụng CephFS tăng lên phải được tính đến khi lập kế hoạch dịch vụ và ngưỡng không gian trống tối đa an toàn mà không có rủi ro vận hành khi xảy ra lỗi phần cứng đòi hỏi nhiều trải nghiệm thực tế hơn. Chúng tôi đã thử nghiệm sử dụng tính năng cân bằng dữ liệu upmap để lấp đầy CEPFS sao lưu lên tới 95% dung lượng nhằm sử dụng đĩa thống nhất.
Hiệu suất ghi mã sửa lỗi được thực hiện gần giới hạn của kết nối mạng; cả CPU và ổ đĩa đều không bão hòa ở mức thông lượng cao nhất này. Các tắc nghẽn đọc rõ ràng hơn; chúng có thể bị chi phối bởi độ trễ tìm kiếm đĩa đĩa. Lưu lượng đọc và ghi của mô hình IO mã sửa lỗi CephFS đã tăng gần gấp đôi. Khi thử nghiệm với các khối lớn để ghi, đầu vào mạng trên một nút duy nhất đạt tốc độ ấn tượng 9 GiB/s, trong khi lưu lượng gửi đi là 5 GiB/s và đầu ra đĩa là 5 GiB/s.
Để tận dụng tổng băng thông IO đĩa có sẵn trên mỗi máy chủ (10 GiB/s), số kết nối mạng phải được tăng gấp đôi. Hơn nữa, ngoài các kết quả được báo cáo, chúng tôi cũng điều tra các trường hợp sử dụng đọc và ghi đồng thời. CephFS ưu tiên băng thông có sẵn để ghi, để lại băng thông còn lại cho việc đọc; lập lịch IO do người viết ưu tiên thực sự là hành vi lý tưởng cho hầu hết các trường hợp sử dụng.
Giao diện người dùng EOS có rất ít tác động đến hiệu suất IO tổng thể. Việc tăng số lần ghi cần được điều tra dựa trên việc triển khai lập lịch luồng không cân bằng bên trong máy chủ XRootD.
Về lý thuyết, có thể đặt EOS FST và Ceph OSD trên cùng một máy chủ, nhưng điều này đòi hỏi phải cài đặt CephFS trên nút OSD: việc cài đặt như vậy có thể gây ra bế tắc kernel nếu xảy ra áp lực bộ nhớ. Mô hình cổng/lưu trữ siêu hội tụ yêu cầu một số thử nghiệm bổ sung trong các tình huống tải cao.
Thiết lập kết hợp CEPFS+EOS là một cách đơn giản để kết hợp các khả năng IO song song hiệu suất cao của CephFS với các tính năng nâng cao do EOS cung cấp. Điều này bao gồm bảo mật mạnh mẽ, truy cập WAN hiệu quả bằng cách sử dụng giao thức XRootD và HTTP(S), quản lý quyền và hạn ngạch mở rộng, vận chuyển bên thứ ba, ủy quyền mã thông báo, hỗ trợ tổng kiểm tra, phụ trợ băng tùy chọn, v.v.
Khi thiết kế các dịch vụ lai sử dụng công nghệ 100Gig-E, phải đặc biệt chú ý đến mạng trong OSD mặt sau, cũng như các giới hạn IO của từng nút mặt trước. Chúng tôi đã cố gắng đạt được tốc độ ghi lên tới 4,5 GiB/giây và 6 GiB/giây đọc với FST một cổng với một giá trị hạt nhân CephFS. Khi sử dụng bộ lưu trữ LHC tại CERN, chúng tôi quan sát thấy tỷ lệ đọc-ghi thông thường là 10:1. Do đó, việc thêm chức năng chuyển hướng đến cục bộ vào EOS có thể là một lựa chọn thú vị trong các tình huống mà CephFS có thể được gắn với quyền truy cập mở để đọc trên các nút máy khách.
Chuyển hướng cục bộ có thể phụ thuộc vào cài đặt quyền của từng thư mục. Bản thân giá trị gắn kết CephFS cũng có thể được kích hoạt trong plugin XRootD dựa trên phản hồi chuyển hướng có chứa khóa xác thực cephx cho giá trị gắn kết chỉ đọc CephFS được yêu cầu. Khi quyền truy cập tệp thưa thớt, mô hình cổng FST sẽ cung cấp một lớp bộ nhớ đệm bổ sung để chuyển đổi quyền truy cập thưa thớt của máy khách thành lưu lượng truy cập phụ trợ trực tuyến. Điều này đòi hỏi phải có những điều chỉnh phù hợp đối với cài đặt đọc trước gắn kết CephFS.
Mô hình dịch vụ được đề xuất cho phép phân cụm nhiều thiết lập CephFS độc lập với các miền lỗi độc lập và chất lượng dịch vụ khác nhau đằng sau một miền quản lý duy nhất. Nó cho phép các nhà khai thác thực hiện di chuyển phần cứng minh bạch giữa các hệ thống CephFS từ chương trình phụ trợ cũ sang chương trình phụ trợ mới bằng cách sử dụng các công cụ quản lý EOS và quá trình vận chuyển của bên thứ ba mà không làm gián đoạn việc sử dụng sản xuất.
Chúng tôi đã xác minh thiết lập này cho các hoạt động của luồng IO. Sự sẵn có của các trường hợp sử dụng phân tích vật lý thưa thớt sẽ là bước xác nhận tiếp theo. Ngoài ra, hình phạt phân mảnh dự kiến sau khi lão hóa qua một số chu kỳ điền/xóa vẫn chưa được đánh giá. Chúng tôi đã chứng minh rằng CephFS có thể được sử dụng để truyền phát IO thông lượng cao mà không cần chỉ định ổ SSD cho siêu dữ liệu BlueStore block.db. Yêu cầu chính để chạy các máy chủ dung lượng cao là ít nhất 3 GiB bộ nhớ cho mỗi OSD (HDD).
Nói tóm lại, CephFS + EOS là một giải pháp khả thi kết hợp các khái niệm lưu trữ đối tượng của Ceph và khả năng dịch vụ nâng cao của EOS một cách rất đơn giản. Chúng ta cần cân bằng giữa sự phức tạp và chi phí của dịch vụ với lợi ích.
Văn bản gốc: https://link.springer.com/article/10.1007/s41781-021-00071-1.
Tác giả: Chu Tương.
Kiến trúc sư điện toán đám mây cao cấp, giảng viên chính thức của OpenStack được mời. Có kinh nghiệm xây dựng và quản lý hàng chục nghìn máy chủ đám mây và hàng chục kho lưu trữ phân tán PB.
Địa chỉ gốc: https://mp.weixin.qq.com/s/lOZ04ayUFxa6d7MGjqpVuw.
Cuối cùng, bài viết về việc đánh giá hiệu suất và chi phí của CephFS trên các máy chủ mật độ cao kết thúc tại đây. Nếu bạn muốn biết thêm về việc đánh giá hiệu suất và chi phí của CephFS trên các máy chủ mật độ cao, vui lòng tìm kiếm bài viết CFSDN. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .
26
4
0
Trung tâm cá nhân
Điều phát hành
từ bỏ
Tôi là một lập trình viên xuất sắc, rất giỏi!