المطورين من Cloudflare حول تنفيذ العمل لتحسين أداء تشفير القرص في Linux kernel. ونتيجة لذلك، كانوا على استعداد للنظام الفرعي وCrypto API، التي أتاحت مضاعفة إنتاجية القراءة والكتابة في الاختبار الاصطناعي، بالإضافة إلى خفض زمن الوصول إلى النصف. عند الاختبار على أجهزة حقيقية، تم تقليل حمل التشفير إلى المستوى الذي تم ملاحظته تقريبًا عند العمل مع قرص بدون تشفير البيانات.
يستخدم Cloudflare dm-crypt لتشفير البيانات الموجودة على أجهزة التخزين المستخدمة لتخزين المحتوى مؤقتًا على CDN. يعمل Dm-crypt على مستوى جهاز الكتلة ويقوم بتشفير طلبات الإدخال/الإخراج وفك تشفير طلبات القراءة، ويعمل كطبقة بين جهاز الكتلة وبرنامج تشغيل نظام الملفات.
لتقييم أداء dm-crypt باستخدام الحزمة قمنا بقياس سرعة العمل مع الأقسام المشفرة وغير المشفرة على قرص ذاكرة الوصول العشوائي (RAM) الموجود في ذاكرة الوصول العشوائي (RAM) للتخلص من التقلبات في أداء القرص والتركيز على أداء التعليمات البرمجية. بالنسبة للأقسام غير المشفرة، ظل أداء القراءة والكتابة عند 1126 ميجابايت/ثانية، ولكن السرعة انخفضت عند تمكين التشفير في الوقت 7 وبلغت 147 ميجابايت / ثانية.
في البداية، نشأت الشكوك حول استخدام خوارزميات غير فعالة في نظام تشفير النواة. لكن الاختبارات استخدمت أسرع خوارزمية، aes-xts، مع 256 مفتاح تشفير، والتي يكون أداؤها عند تشغيل "معيار cryptsetup" أكثر من ضعف النتيجة التي تم الحصول عليها عند اختبار قرص ذاكرة الوصول العشوائي. لم تسفر التجارب على أعلام dm-crypt لضبط الأداء عن نتائج: عند استخدام علامة "--perf-same_cpu_crypt"، انخفض الأداء حتى إلى 136 ميجابايت/ثانية، وعند تحديد علامة "--perf-submit_from_crypt_cpus" زاد فقط إلى 166 ميجابايت/ثانية.
أظهر تحليل أعمق لمنطق التشغيل أن dm-crypt ليس بهذه البساطة كما يبدو - عندما يصل طلب كتابة من برنامج تشغيل FS، لا يقوم dm-crypt بمعالجته على الفور، ولكنه يضعه في قائمة الانتظار "kcryptd"، والتي لم يتم تحليلها على الفور، ولكن عندما تكون لحظة مناسبة. من قائمة الانتظار، يتم إرسال الطلب إلى Linux Crypto API لإجراء التشفير. ولكن نظرًا لأن Crypto API تستخدم نموذج تنفيذ غير متزامن، فلا يتم تنفيذ التشفير أيضًا على الفور، ولكن يتم تجاوز قائمة انتظار أخرى. بعد اكتمال التشفير، قد يحاول dm-crypt فرز طلبات الكتابة المعلقة باستخدام شجرة البحث . في النهاية، يلتقط مؤشر ترابط kernel منفصل مرة أخرى، مع تأخير معين، طلبات الإدخال / الإخراج المتراكمة ويرسلها إلى مكدس جهاز الكتلة.
عند القراءة، يضيف dm-crypt أولاً طلبًا إلى قائمة الانتظار "kcryptd_io" لتلقي البيانات من محرك الأقراص. وبعد مرور بعض الوقت، تصبح البيانات متاحة ويتم وضعها في قائمة انتظار "kcryptd" لفك التشفير.
يرسل Kcryptd طلبًا إلى Linux Crypto API، الذي يقوم بفك تشفير المعلومات بشكل غير متزامن. لا تمر الطلبات دائمًا عبر جميع قوائم الانتظار، ولكن في أسوأ السيناريوهات، ينتهي طلب الكتابة في قوائم الانتظار حتى 4 مرات، وطلب القراءة حتى 3 مرات. تؤدي كل ضربة إلى قائمة الانتظار إلى حدوث تأخيرات، وهو السبب الرئيسي للانخفاض الكبير في أداء dm-crypt.
يرجع استخدام قوائم الانتظار إلى الحاجة إلى العمل في الظروف التي تحدث فيها الانقطاعات. في عام 2005، عندما تم تنفيذ نموذج التشغيل الحالي القائم على قائمة الانتظار لـ dm-crypt، لم تكن واجهة برمجة تطبيقات Crypto غير متزامنة بعد. بعد نقل Crypto API إلى نموذج تنفيذ غير متزامن، بدأ استخدام الحماية المزدوجة بشكل أساسي. تم أيضًا تقديم قوائم الانتظار لتوفير استهلاك مكدس النواة، ولكن بعد زيادتها في عام 2014، فقدت هذه التحسينات أهميتها. تم تقديم قائمة انتظار إضافية "kcryptd_io" للتغلب على الاختناق الناتج عن انتظار تخصيص الذاكرة عند وصول عدد كبير من الطلبات. في عام 2015، تم تقديم مرحلة فرز إضافية، حيث يمكن إكمال طلبات التشفير على الأنظمة متعددة المعالجات خارج الترتيب (بدلاً من الوصول المتسلسل إلى القرص، تم تنفيذ الوصول بترتيب عشوائي، ولم يعمل برنامج جدولة CFQ بكفاءة). حاليًا، عند استخدام محركات أقراص SSD، فقد الفرز معناه، ولم يعد جدولة CFQ مستخدمًا في النواة.
بالنظر إلى أن محركات الأقراص الحديثة أصبحت أسرع وأكثر ذكاءً، تمت مراجعة نظام توزيع الموارد في Linux kernel وتم إعادة تصميم بعض الأنظمة الفرعية، مهندسو Cloudflare يحتوي dm-crypt على وضع تشغيل جديد يلغي استخدام قوائم الانتظار غير الضرورية والمكالمات غير المتزامنة. يتم تمكين الوضع من خلال علامة منفصلة "force_inline" ويجلب dm-crypt إلى شكل وكيل بسيط يقوم بتشفير وفك تشفير الطلبات الواردة. تم تحسين التفاعل مع Crypto API من خلال الاختيار الصريح لخوارزميات التشفير التي تعمل في الوضع المتزامن ولا تستخدم قوائم انتظار الطلبات. للعمل بشكل متزامن مع Crypto API كان هناك وحدة تسمح لك باستخدام FPU/AES-NI للتسريع وإعادة توجيه طلبات التشفير وفك التشفير مباشرة.
ونتيجة لذلك، عند اختبار قرص ذاكرة الوصول العشوائي (RAM)، كان من الممكن مضاعفة أداء dm-crypt - حيث زاد الأداء من 294 ميجابايت/ثانية (2 × 147 ميجابايت/ثانية) إلى 640 ميجابايت/ثانية، وهو قريب جدًا من أداء التشفير المجرد (696 ميجابايت / ثانية).
عند اختبار التحميل على خوادم حقيقية، أظهر التنفيذ الجديد أداءً قريبًا جدًا من التكوين الذي يعمل بدون تشفير، ولم يكن لتمكين التشفير على الخوادم التي تحتوي على ذاكرة التخزين المؤقت Cloudflare أي تأثير على سرعة الاستجابة. في المستقبل، تخطط Cloudflare لنقل التصحيحات المعدة إلى Linux kernel الرئيسي، ولكن قبل ذلك، ستحتاج إلى إعادة صياغة، حيث تم تحسينها لتحميل معين ولا تغطي جميع مجالات التطبيق، على سبيل المثال، التشفير على المستوى المنخفض - الأجهزة المدمجة بالطاقة.
المصدر: opennet.ru