Nhà phát triển từ Cloudflare về việc thực hiện công việc nhằm tối ưu hóa hiệu suất mã hóa ổ đĩa trong nhân Linux. Kết quả là họ đã chuẩn bị cho hệ thống con và API Crypto, giúp tăng gấp đôi thông lượng đọc và ghi trong thử nghiệm tổng hợp, cũng như giảm một nửa độ trễ. Khi thử nghiệm trên phần cứng thực, chi phí mã hóa đã giảm xuống gần như mức quan sát được khi làm việc với ổ đĩa không mã hóa dữ liệu.
Cloudflare sử dụng dm-crypt để mã hóa dữ liệu trên các thiết bị lưu trữ dùng để lưu trữ nội dung trên CDN. Dm-crypt hoạt động ở cấp thiết bị khối và mã hóa các yêu cầu I/O ghi cũng như giải mã các yêu cầu đọc, hoạt động như một lớp giữa thiết bị khối và trình điều khiển hệ thống tệp.
Để đánh giá hiệu suất của dm-crypt bằng gói Chúng tôi đã đo tốc độ làm việc với các phân vùng được mã hóa và không được mã hóa trên đĩa RAM nằm trong RAM để loại bỏ sự biến động về hiệu suất ổ đĩa và tập trung vào hiệu suất mã. Đối với các phân vùng không được mã hóa, hiệu suất đọc và ghi vẫn ở mức 1126 MB/s, nhưng tốc độ giảm khi bật mã hóa 7 trong thời gian và lên tới 147 MB/s.
Lúc đầu, nảy sinh nghi ngờ về việc sử dụng các thuật toán kém hiệu quả trong hệ thống mật mã hạt nhân. Nhưng các bài kiểm tra đã sử dụng thuật toán nhanh nhất, aes-xts, với 256 khóa mã hóa, có hiệu suất khi chạy “điểm chuẩn cryptsetup” cao hơn gấp đôi so với kết quả thu được khi kiểm tra đĩa RAM. Các thử nghiệm với cờ dm-crypt để điều chỉnh hiệu suất không mang lại kết quả: khi sử dụng cờ “--perf-same_cpu_crypt”, hiệu suất thậm chí còn giảm xuống 136 MB/s và khi chỉ định cờ “--perf-submit_from_crypt_cpus”, nó chỉ tăng đến 166 MB/s.
Phân tích sâu hơn về logic vận hành cho thấy rằng dm-crypt không đơn giản như vẻ ngoài của nó - khi có yêu cầu ghi đến từ trình điều khiển FS, dm-crypt không xử lý nó ngay lập tức mà đặt nó vào hàng đợi “kcryptd”. không được phân tích cú pháp ngay lập tức mà vào thời điểm thuận tiện. Từ hàng đợi, yêu cầu được gửi tới Linux Crypto API để thực hiện mã hóa. Nhưng vì API Crypto sử dụng mô hình thực thi không đồng bộ nên việc mã hóa cũng không được thực hiện ngay lập tức mà bỏ qua một hàng đợi khác. Sau khi mã hóa hoàn tất, dm-crypt có thể cố gắng sắp xếp các yêu cầu ghi đang chờ xử lý bằng cây tìm kiếm . Cuối cùng, một luồng nhân riêng biệt lại, với một độ trễ nhất định, sẽ nhận các yêu cầu I/O tích lũy và gửi chúng đến ngăn xếp thiết bị khối.
Khi đọc, dm-crypt trước tiên sẽ thêm yêu cầu vào hàng đợi “kcryptd_io” để nhận dữ liệu từ ổ đĩa. Sau một thời gian, dữ liệu sẽ có sẵn và được đặt vào hàng đợi “kcryptd” để giải mã.
Kcryptd gửi yêu cầu tới API Linux Crypto để giải mã thông tin một cách không đồng bộ. Yêu cầu không phải lúc nào cũng đi qua tất cả các hàng đợi, nhưng trong trường hợp xấu nhất, yêu cầu ghi sẽ xuất hiện trong hàng đợi tối đa 4 lần và yêu cầu đọc tối đa 3 lần. Mỗi lần truy cập vào hàng đợi đều gây ra sự chậm trễ, đó là lý do chính khiến hiệu suất dm-crypt giảm đáng kể.
Việc sử dụng hàng đợi là do nhu cầu làm việc trong điều kiện xảy ra gián đoạn. Vào năm 2005, khi mô hình hoạt động dựa trên hàng đợi hiện tại của dm-crypt được triển khai, API Crypto vẫn chưa đồng bộ. Sau khi API Crypto được chuyển sang mô hình thực thi không đồng bộ, về cơ bản, biện pháp bảo vệ kép bắt đầu được sử dụng. Hàng đợi cũng được giới thiệu để tiết kiệm mức tiêu thụ ngăn xếp kernel, nhưng sau khi tăng lên vào năm 2014, những tối ưu hóa này đã mất đi tính liên quan. Một hàng đợi bổ sung "kcryptd_io" đã được giới thiệu để khắc phục tình trạng tắc nghẽn dẫn đến phải chờ cấp phát bộ nhớ khi có một số lượng lớn yêu cầu đến. Vào năm 2015, một giai đoạn sắp xếp bổ sung đã được giới thiệu, do các yêu cầu mã hóa trên hệ thống đa bộ xử lý có thể được hoàn thành không theo thứ tự (thay vì truy cập tuần tự vào đĩa, việc truy cập được thực hiện theo thứ tự ngẫu nhiên và bộ lập lịch CFQ không hoạt động hiệu quả). Hiện tại, khi sử dụng ổ SSD, việc sắp xếp đã mất đi ý nghĩa và bộ lập lịch CFQ không còn được sử dụng trong kernel.
Xét thấy các ổ đĩa hiện đại đã trở nên nhanh hơn và thông minh hơn, hệ thống phân phối tài nguyên trong nhân Linux đã được sửa đổi và một số hệ thống con đã được thiết kế lại, các kỹ sư của Cloudflare dm-crypt có chế độ hoạt động mới giúp loại bỏ việc sử dụng hàng đợi không cần thiết và các cuộc gọi không đồng bộ. Chế độ này được kích hoạt bằng một cờ riêng biệt “force_inline” và đưa dm-crypt sang dạng proxy đơn giản để mã hóa và giải mã các yêu cầu đến. Tương tác với API Crypto đã được tối ưu hóa bằng cách chọn rõ ràng các thuật toán mã hóa hoạt động ở chế độ đồng bộ và không sử dụng hàng đợi yêu cầu. Để hoạt động đồng bộ với API Crypto, cần có một mô-đun cho phép bạn sử dụng FPU/AES-NI để tăng tốc và chuyển tiếp trực tiếp các yêu cầu mã hóa và giải mã.
Kết quả là, khi kiểm tra đĩa RAM, hiệu suất của dm-crypt có thể tăng hơn gấp đôi - hiệu suất tăng từ 294 MB/s (2 x 147 MB/s) lên 640 MB/s, rất gần với hiệu suất mã hóa trần (696 MB / s).
Khi kiểm tra tải trên máy chủ thực, cách triển khai mới cho thấy hiệu suất rất gần với cấu hình chạy không mã hóa và việc bật mã hóa trên máy chủ có bộ đệm Cloudflare không ảnh hưởng đến tốc độ phản hồi. Trong tương lai, Cloudflare có kế hoạch chuyển các bản vá đã chuẩn bị sang nhân Linux chính, nhưng trước đó chúng sẽ cần phải được làm lại vì chúng được tối ưu hóa cho một tải cụ thể và không bao gồm tất cả các lĩnh vực ứng dụng, chẳng hạn như mã hóa ở mức thấp. -cấp nguồn cho các thiết bị nhúng.
Nguồn: opennet.ru