Cloudflare הכינה תיקונים שמאיצים באופן דרמטי את הצפנת הדיסק בלינוקס

מפתחים מ-Cloudflare סיפר על ביצוע עבודה למיטוב הביצועים של הצפנת דיסק בליבת לינוקס. כתוצאה מכך, הם היו מוכנים טלאים עבור תת-מערכת dm-crypt ו-Crypto API, שאפשרו יותר מהכפלת תפוקת הקריאה והכתיבה בבדיקה הסינתטית, כמו גם להפחית את זמן ההשהיה בחצי. כאשר נבדק על חומרה אמיתית, תקורה של הצפנה צומצמה כמעט לרמה שנצפתה בעבודה עם דיסק ללא הצפנת נתונים.

Cloudflare משתמש ב-dm-crypt כדי להצפין נתונים על התקני אחסון המשמשים לאחסון תוכן במטמון ב-CDN. Dm-crypt פועל ברמת התקן הבלוק ומצפין בקשות כתיבה קלט/פלט ומפענח בקשות קריאה, ופועל כשכבה בין התקן הבלוק למנהל ההתקן של מערכת הקבצים.

כדי להעריך את הביצועים של dm-crypt באמצעות החבילה בודק קלט/פלט גמיש מדדנו את מהירות העבודה עם מחיצות מוצפנות ולא מוצפנות על דיסק RAM הממוקם ב-RAM כדי למנוע תנודות בביצועי הדיסק ולהתמקד בביצועי הקוד. עבור מחיצות לא מוצפנות, ביצועי הקריאה והכתיבה נותרו על 1126 MB/s, אך המהירות ירדה כשההצפנה הופעלה в 7 раз והסתכם ב-147 MB/s.

בתחילה התעורר חשד לגבי השימוש באלגוריתמים לא יעילים במערכת ההצפנה של הקרנל. אבל הבדיקות השתמשו באלגוריתם המהיר ביותר, aes-xts, עם 256 מפתחות הצפנה, שהביצועים שלהם בעת הפעלת "מדד cryptsetup" גבוהים יותר מפי שניים מהתוצאה שהתקבלה בעת בדיקת דיסק RAM. ניסויים עם דגלי dm-crypt לכוונון ביצועים לא הניבו תוצאות: בעת שימוש בדגל "--perf-same_cpu_crypt", הביצועים אפילו ירדו ל-136 MB/s, וכאשר ציינו את הדגל "--perf-submit_from_crypt_cpus" הוא עלה רק עד 166 MB/s.

ניתוח מעמיק יותר של ההיגיון התפעולי הראה ש-dm-crypt אינו פשוט כפי שהוא נראה - כאשר מגיעה בקשת כתיבה מהדרייבר של FS, dm-crypt לא מעבד אותה מיד, אלא מציב אותה בתור "kcryptd", אשר לא מנותח מיד, אלא ברגע שנוח. מהתור, הבקשה נשלחת ל-Linux Crypto API לביצוע הצפנה. אבל מכיוון שה-Crypto API משתמש במודל ביצוע אסינכרוני, גם ההצפנה לא מתבצעת מיד, אלא עוקפת תור אחר. לאחר השלמת ההצפנה, dm-crypt עשוי לנסות למיין בקשות כתיבה ממתינות באמצעות עץ חיפוש אדום שחור. בסוף, שרשור קרנל נפרד שוב, בהשהיה מסוימת, קולט את בקשות ה-I/O המצטברות ושולח אותן לערימת מכשיר החסימה.

בעת הקריאה, dm-crypt מוסיפה תחילה בקשה לתור "kcryptd_io" לקבלת נתונים מהכונן. לאחר זמן מה, הנתונים הופכים זמינים וממוקמים בתור "kcryptd" לפענוח.
Kcryptd שולח בקשה ל-Linux Crypto API, אשר מפענח את המידע באופן אסינכרוני. בקשות לא תמיד עוברות על כל התורים, אבל במקרה הגרוע, בקשת כתיבה מסתיימת בתורים עד 4 פעמים, ובקשת קריאה עד 3 פעמים. כל פגיעה בתור גורמת לעיכובים, שהם הסיבה העיקרית לירידה המשמעותית בביצועי dm-crypt.

השימוש בתורים נובע מהצורך לעבוד בתנאים שבהם מתרחשות הפרעות. בשנת 2005, כאשר הוטמע מודל ההפעלה הנוכחי מבוסס-תור של dm-crypt, ה-Crypto API עדיין לא היה אסינכרוני. לאחר שה-Crypto API הועבר למודל ביצוע אסינכרוני, החלה למעשה להשתמש בהגנה כפולה. כמו כן, הוכנסו תורים כדי לחסוך בצריכה של מחסנית הקרנל, אך לאחר העלייה ב-2014, האופטימיזציות הללו איבדו את הרלוונטיות שלהן. תור נוסף "kcryptd_io" הוכנס כדי להתגבר על צוואר הבקבוק וכתוצאה מכך המתנה להקצאת זיכרון כאשר מספר רב של בקשות מגיעות. בשנת 2015 הוכנס שלב מיון נוסף, שכן בקשות הצפנה במערכות מרובות מעבדים יכלו להסתיים ללא תקינות (במקום גישה רציפה לדיסק, הגישה בוצעה בסדר אקראי ומתזמן ה-CFQ לא פעל ביעילות). נכון לעכשיו, בעת שימוש בכונני SSD, המיון איבד את משמעותו, ומתזמן ה-CFQ אינו בשימוש בקרנל.

בהתחשב בכך שהכוננים המודרניים הפכו למהירים וחכמים יותר, מערכת הפצת המשאבים בקרנל הלינוקס שונתה וחלק מתתי המערכות עוצבו מחדש, מהנדסי Cloudflare הוסיף ל-dm-crypt יש מצב הפעלה חדש שמבטל את השימוש בתורים מיותרים ובשיחות אסינכרוניות. המצב מתאפשר על ידי דגל נפרד "force_inline" ומביא את dm-crypt לצורה של פרוקסי פשוט שמצפין ומפענח בקשות נכנסות. האינטראקציה עם ה-Crypto API עברה אופטימיזציה על ידי בחירה מפורשת באלגוריתמי הצפנה הפועלים במצב סינכרוני ואינם משתמשים בתורי בקשות. לעבוד סינכרוני עם ה-Crypto API היה מוּצָע מודול המאפשר לך להשתמש ב-FPU/AES-NI להאצה ומעביר ישירות בקשות הצפנה ופענוח.

כתוצאה מכך, בעת בדיקת דיסק RAM, ניתן היה להכפיל יותר מהביצועים של dm-crypt - הביצועים עלו מ-294 MB/s (2 x 147 MB/s) ל-640 MB/s, שזה קרוב מאוד ל- הביצועים של הצפנה חשופה (696 MB /s).

בעת בדיקת עומס על שרתים אמיתיים, היישום החדש הראה ביצועים קרובים מאוד לתצורה הפועלת ללא הצפנה, ולהפעלת הצפנה בשרתים עם מטמון Cloudflare לא הייתה השפעה על מהירות התגובה. בעתיד, Cloudflare מתכננת להעביר את התיקונים המוכנים לגרעין הלינוקס הראשי, אך לפני כן יהיה צורך לעבד אותם מחדש, מכיוון שהם מותאמים לעומס ספציפי ואינם מכסים את כל תחומי היישום, למשל, הצפנה על נמוכה -התקנים משובצים כוח.

מקור: OpenNet.ru