OneFS cung cấp cơ chế lưu trữ đệm cho các lần ghi đồng bộ – hoặc các lần ghi yêu cầu xác nhận ghi ổn định để trả về cho máy khách. Chức năng này được gọi là Endurant Cache hoặc EC.
EC hoạt động kết hợp với bộ đệm ghi OneFS hoặc coalescer để thu thập, bảo vệ và tổng hợp các lần ghi NFS đồng bộ nhỏ. Các khối ghi đến được dàn dựng thành NVRAM, đảm bảo tính toàn vẹn của lần ghi, ngay cả trong trường hợp không mong muốn là mất điện của một nút. Hơn nữa, EC cũng tạo nhiều bản sao dữ liệu được phản chiếu, đảm bảo hơn nữa khả năng bảo vệ khỏi các lỗi của một nút và nếu muốn, nhiều nút.
EC cải thiện độ trễ liên quan đến ghi đồng bộ bằng cách giảm thời gian xác nhận lại cho máy khách. Quy trình này loại bỏ các hoạt động Đọc-Sửa đổi-Ghi (RMW) khỏi đường dẫn độ trễ xác nhận, đồng thời tận dụng coalescer để tối ưu hóa các lần ghi vào đĩa. EC cũng được kết hợp chặt chẽ với quy trình I/O đa luồng (Multi-writer) của OneFS, để hỗ trợ các lần ghi đồng thời từ nhiều luồng ghi máy khách vào cùng một tệp. Và thiết kế của EC đảm bảo rằng các lần ghi được lưu trong bộ nhớ đệm không ảnh hưởng đến hiệu suất chụp nhanh.
Bộ nhớ đệm bền bỉ sử dụng ghi nhật ký ghi để kết hợp và bảo vệ các lần ghi nhỏ ở các offset ngẫu nhiên thành các lần ghi tuyến tính 8KB. Để đạt được điều này, các lần ghi sẽ chuyển đến các tệp được phản chiếu đặc biệt hoặc ‘Logstore’. Phản hồi cho yêu cầu ghi ổn định có thể được gửi sau khi dữ liệu được cam kết với logstore. Logstore có thể được ghi vào bởi nhiều luồng từ cùng một nút và được tối ưu hóa cao để cho phép ghi đồng thời có độ trễ thấp.
Lưu ý rằng nếu một lệnh ghi sử dụng EC, thì cũng phải sử dụng coalescer. Nếu coalescer bị vô hiệu hóa trên một tệp, nhưng EC được bật, coalescer vẫn sẽ hoạt động với tất cả dữ liệu được EC hỗ trợ.
Vậy thì trình tự ghi bộ nhớ đệm bền bỉ trông như thế nào?
Giả sử một máy khách NFS muốn ghi một tệp vào cụm PowerScale qua NFS với cờ O_SYNC được đặt, yêu cầu xác nhận ghi đồng bộ hoặc đã xác nhận. Sau đây là trình tự các sự kiện xảy ra để tạo điều kiện cho việc ghi ổn định.
1. Một máy khách được kết nối với nút 3 bắt đầu quá trình ghi bằng cách gửi các khối cấp độ giao thức. 4K là kích thước khối tối ưu cho bộ đệm bền bỉ.

2. Các lệnh ghi của máy khách NFS được lưu trữ tạm thời trong phần write coalescer của RAM của nút 3. Write Coalescer tổng hợp các khối chưa cam kết để OneFS có thể, lý tưởng nhất là, ghi ra các nhóm bảo vệ đầy đủ khi có thể, giảm độ trễ trên các giao thức cho phép ghi “không ổn định”. Ghi vào RAM có độ trễ ít hơn nhiều so với ghi trực tiếp vào đĩa.
3. Khi đã ở trong bộ hợp nhất ghi, tiến trình ghi nhật ký bộ đệm bền bỉ sẽ ghi các bản sao phản chiếu của các khối dữ liệu song song với Tệp nhật ký EC.
Mức độ bảo vệ của các tệp nhật ký EC được sao chép giống với mức độ bảo vệ của dữ liệu được ghi bởi máy khách NFS.

4. Khi các bản sao dữ liệu được nhận vào Tệp nhật ký EC, một lệnh ghi ổn định tồn tại và một xác nhận ghi (ACK) được trả về máy khách NFS xác nhận lệnh ghi ổn định đã xảy ra. Máy khách cho rằng lệnh ghi đã hoàn tất và có thể đóng phiên ghi.

5. Sau đó, write coalescer xử lý tệp giống như một lần ghi không phải EC tại thời điểm này. Write coalescer sẽ điền và thường xuyên được xả khi cần thiết như một lần ghi không đồng bộ vào trình quản lý phân bổ khối (BAM) và các quy trình đường dẫn ghi an toàn BAM (BSW).
6. Tệp được chia thành 128K đơn vị dữ liệu dải (DSU), tính toán bảo vệ chẵn lẻ (FEC) và tạo các đơn vị dữ liệu dải FEC (FSU).

7. Sau đó, bố cục và kế hoạch ghi được xác định và các đơn vị stripe được ghi vào L2 Cache và NVRAM của các nút tương ứng. Các tệp nhật ký EC được xóa khỏi NVRAM tại thời điểm này. OneFS sử dụng quy trình Fast Invalid Path để hủy phân bổ các tệp nhật ký EC khỏi NVRAM.

8. Các đơn vị Stripe sau đó được lưu vào đĩa vật lý.
9. Sau khi ghi vào đĩa vật lý, các bản sao của Đơn vị dữ liệu dải (DSU) và Đơn vị dữ liệu dải FEC (FSU) được tạo trong quá trình ghi sẽ được xóa khỏi NVRAM nhưng vẫn nằm trong bộ đệm L2 cho đến khi được xóa để tạo chỗ cho dữ liệu được truy cập gần đây hơn.

Về mặt bảo vệ, số lượng bản sao tệp nhật ký được EC tạo ra luôn nhiều hơn một so với mức bảo vệ trên đĩa của tệp. Ví dụ:
| Mức độ bảo vệ tập tin | Số lượng bản sao EC được sao chép |
| +1n | 2 |
| 2 lần | 3 |
| +2n | 3 |
| +2ngày:1đ | 3 |
| +3n | 4 |
| +3ngày:1n | 4 |
| +4n | 5 |
Gương EC chỉ được sử dụng nếu nút khởi tạo bị mất. Trong trường hợp không mong muốn xảy ra, các nút tham gia sẽ phát lại nhật ký EC của họ và hoàn tất việc ghi.
Nếu lệnh ghi là ứng viên EC, dữ liệu vẫn nằm trong coalescer, lệnh ghi EC được xây dựng và vùng coalescer thích hợp được đánh dấu là EC. Lệnh ghi EC là lệnh ghi vào logstore (tệp ẩn được phản chiếu) và dữ liệu được đưa vào nhật ký.
Giả sử nhật ký đủ trống, hoạt động ghi sẽ được giữ ở đó (lưu vào bộ nhớ đệm) và chỉ được chuyển vào đĩa khi nhật ký đầy, do đó tiết kiệm được hoạt động bổ sung của đĩa.
Khối lượng công việc tối ưu cho EC bao gồm các khối nhỏ đồng bộ, ghi tuần tự – ví dụ như nhật ký kiểm toán hoặc nhật ký làm lại. Trong trường hợp đó, coalescer sẽ tích lũy dữ liệu của toàn bộ nhóm bảo vệ và có thể thực hiện ghi FEC hiệu quả.
Phương pháp trung bình là tải loại khối nhỏ đồng bộ, đặc biệt là khi tốc độ I/O thấp và máy khách nhạy cảm với độ trễ. Trong trường hợp này, độ trễ sẽ giảm và nếu tốc độ I/O đủ thấp, nó sẽ không tạo ra áp lực nghiêm trọng.
Kịch bản không mong muốn là khi cụm đã bị ràng buộc bởi trục chính và khối lượng công việc lớn đến mức tạo ra nhiều áp lực tạp chí. Trong trường hợp này, EC chỉ làm mọi thứ trở nên tồi tệ hơn.
Vậy chính xác thì bạn cấu hình bộ nhớ đệm bền bỉ như thế nào?
Mặc dù được bật theo mặc định, việc đặt efs.bam.ec.mode sysctl thành giá trị ‘1’ sẽ kích hoạt Endurant Cache:
# isi_sysctl_cluster Efs.bam.ec.mode=1
EC cũng có thể được bật và tắt theo từng thư mục:
# isi set -c [bật|tắt|endurant_all|chỉ_than] <tên_thư_mục>
Để bật bộ kết hợp nhưng tắt EC, hãy chạy:
# isi thiết lập -c coal_only
Và để vô hiệu hóa hoàn toàn bộ nhớ đệm bền bỉ:
# isi_for_array –s isi_sysctl_cluster efs.bam.ec.mode=0
Giá trị trả về bằng 0 trên mỗi nút từ lệnh sau sẽ xác minh rằng EC bị vô hiệu hóa trên toàn cụm:
# isi_for_array –s sysctl efs.bam.ec.stats.write_blocks efs.bam.ec.stats.write_blocks: 0
Nếu đầu ra của lệnh này tăng dần, EC sẽ cung cấp lệnh ghi ổn định.
Xin lưu ý rằng nếu Endurant Cache bị vô hiệu hóa trên một cụm, đầu ra sysctl efs.bam.ec.stats.write_blocks trên mỗi nút sẽ không trở về 0, vì sysctl này là một bộ đếm, không phải là tốc độ. Các bộ đếm này sẽ không đặt lại cho đến khi nút được khởi động lại.
Như đã đề cập trước đó, EC áp dụng cho các thao tác ghi ổn định, cụ thể là:
- Ghi với cờ O_SYNC và/hoặc O_DIRECT được đặt
- Các tập tin trên các mount NFS đồng bộ
Khi phân tích bất kỳ vấn đề hiệu suất nào liên quan đến khối lượng công việc EC, hãy cân nhắc những điều sau:
- Khối lượng công việc có thay đổi gì không?
- Nếu nâng cấp OneFS, phiên bản trước có hỗ trợ EC không?
Nếu khối lượng công việc đã chuyển sang phần cứng cụm mới:
- Vấn đề về hiệu suất có xảy ra trong thời gian CPU sử dụng nhiều không?
- Phần nào của khối lượng công việc đang tạo ra một loạt các bản ghi ổn định?
- Có sự thay đổi lớn nào về số lượng trục chính hoặc nút không?
- Mức độ bảo vệ OneFS có thay đổi không?
- Chiến lược của SSD có giống vậy không?
Việc vô hiệu hóa EC thường được thực hiện trên toàn cụm và điều này có thể ảnh hưởng xấu đến một số thành phần quy trình làm việc. Nếu tải EC được bản địa hóa thành một tập hợp con các tệp đang được ghi, một cách thay thế để giảm nhiệt EC có thể là vô hiệu hóa bộ đệm coalescer cho một số thư mục đích cụ thể, đây sẽ là một điều chỉnh có mục tiêu hơn. Điều này có thể được cấu hình bằng lệnh isi set –c off.
Một trong những nguyên nhân có khả năng gây ra sự suy giảm hiệu suất là từ các ứng dụng tích cực xóa ghi đè và do đó tạo ra một loạt các hoạt động ‘cam kết’. Điều này có thể tạo ra các chu kỳ đọc/sửa đổi/ghi (rmw) nặng, làm tăng độ sâu hàng đợi đĩa trung bình và dẫn đến tốc độ đọc ngẫu nhiên chậm hơn đáng kể. Đầu ra lệnh CLI của giao thức thống kê isi sẽ chỉ ra liệu tỷ lệ ‘cam kết’ có cao hay không.
Cần lưu ý rằng các lệnh ghi đồng bộ không yêu cầu sử dụng tùy chọn gắn kết ‘đồng bộ’ của NFS. Bất kỳ lập trình viên nào quan tâm đến tính bền vững của lệnh ghi có thể chỉ cần chỉ định cờ O_FSYNC hoặc O_DIRECT trên thao tác open() để buộc ngữ nghĩa ghi đồng bộ cho trình xử lý tệp đó. Với Linux, các lệnh ghi sử dụng O_DIRECT sẽ được tính riêng trong đầu ra ‘mountstats’ của Linux. Mặc dù nó hầu như chỉ liên quan đến NFS, nhưng mã EC thực sự không phụ thuộc vào giao thức. Nếu các lệnh ghi là đồng bộ (ghi xuyên qua) và không thẳng hàng hoặc nhỏ hơn 8k, chúng có khả năng kích hoạt EC, bất kể giao thức nào.
Bộ nhớ đệm bền bỉ có thể mang lại lợi ích đáng kể về độ trễ cho các thao tác ghi đồng bộ ngẫu nhiên nhỏ (chẳng hạn như 4K) – mặc dù phải đánh đổi bằng một số công việc bổ sung cho hệ thống.
Tuy nhiên, bạn cần lưu ý những điều sau:
- EC không dành cho mục đích I/O tổng quát hơn.
- Có một lượng EC hữu hạn. Khi tải tăng, EC có khả năng “bị tụt hậu” và trở thành nút thắt cổ chai.
- Endurant Cache không cải thiện hiệu suất đọc vì nó chỉ là một phần của quá trình ghi.
- EC sẽ không tăng hiệu suất ghi không đồng bộ – chỉ tăng hiệu suất ghi đồng bộ.
Tác giả : Nick Trimbee

Bài viết mới cập nhật
Dell Storage Engines: Tăng tốc suy luận AI với PowerScale và ObjectScale
Giải pháp chuyển tải bộ nhớ đệm KV của Dell cho ...
Bảo vệ Nhà máy AI
Áp dụng phương pháp tiếp cận kiến trúc để bảo mật ...
Tiến lên mạnh mẽ với Dell PowerMax: Vượt mặt Hitachi VSP 5000
Dell PowerMax mang lại khả năng phục hồi, hiệu suất và ...
Đẩy nhanh đổi mới AI: Sức mạnh của quyền truy cập mở
Từ các mô hình tiên tiến đến các ứng dụng cấp ...