Haim Cohen, Freescale
כמערכת הפעלה למטרות כלליות, Linux לא תוכננה להפעלה יעילה ולתפוקה גבוהה של תנועה ברשת. בנוסף לכך, אם Linux מיועדת להפעלת המערכת בפלטפורמה מרובת-ליבות, תפוקת המערכת תהיה נמוכה בהרבה מזו של היכולות של חומרת SoC. סוגיה זו של תת-ניצול של יכולות חומרה נובעת מהעובדה שערמת המידע הסטנדרטית ברשת של Linux היא ערמת מידע גנרית עם תקורה גבוהה בהרבה, ולכן מפחיתה את ביצועי המערכת כולה בהשוואה ליכולת של החומרה הבסיסית. מאמר זה דן בסוגיות ומציע פתרון. כמו כן, נציג דוגמה לארכיטקטורת תוכנה משופרת המיושמת בחומרה של מעבד עם ליבה כפולה ונתוני מנות מידע בפועל המשמשים להערכת ביצועים.
Linux זוכה לשימוש נרחב במוצרי רשת. Linux ומערכות הפעלה אחרות הן גנריות ועליהן לטפל בסוגים שונים של יישומים. לכלליות תמיד נלווה מחיר.
לדוגמה, תהליך העברה של מנות IP ב-Linux עובר שכבות רבות של תוכנה מקבלת המנה ועד לשידור המנה. לשכבות גבוהות אלה של מערכות ההפעלה אין שליטה על תכונות החומרה (מעבד ומאיץ). שכבות אלה מוסיפות למחזורים. מכיוון ששכבות תוכנה רבות כרוכות בעניין, השימוש במטמון אינו טוב במיוחד. ובנוסף לכך, העברות הקשר ונעילות (במעבדים מרובי-ליבות) בשכבות גנריות אלה ישתמשו במחזורי ליבה נוספים.
ערמת רשת של OS משתמשת בשירות OS ומעבירה בירושה את המגבלות של OS, כגון תעדוף, איומים, טיימרים ונעילות. מגבלות OS אלה גורמות לצווארי בקבוק בביצועים כגון החמצות מטמון L1/L2 של המעבד, שגיאות בחיזוי קווי צינור ומחסור במדרגיות עקב הנעילות. בנוסף לכך, הן גורמות גם למורכבויות נוספות בפיתוח, כגון השימוש בנעילות בליבה או
(Read Copy Update) בגרסאות אחרונות מסוימות של Linux Kernel 2.6.
ניתן לבצע מספר סוגים של אופטימיזציה ב-Linux כדי לשפר את היכולות הכוללות של עיבוד מנות. היא יכולה להיות ערמת רשת, אופטימיזציה לחומרה מסוימת, מזעור טיפול בהפרעות וכיוצא באלה. אף שערמת רשת משופרת של Linux בארכיטקטורות מסוג SMP יכולה לשפר במידה משמעותית את הביצועים, לא ניתן למדרג אותה מכיוון שכל מנות המידע מנוהלות על ידי ערמת ה-OS, שיש לה מגבלות רבות. לא נוכל להעריך בקלות את התקורה, אך ניתן לראות בעיה זו על ידי הגדלת מספר הליבות, ואז רואים שהביצועים לא גדלים באופן ליניארי עם מספר הליבות. הדוגמה הטובה ביותר היא אמת מידה Linux IPsec, שמראה שערמת המידע לא עוברת מדרוג מעבר לשתי ליבות. בעיה זו אינה ספציפית ל-Linux. המורכבויות המתגברות של פיתוח מובילות להאטה בהעברה של יישומי רשת במעבדים מרובי-ליבות ביעילות.
עם זאת, בכל הפתרונות האפשריים, עדיין בלתי אפשרי להעלות את ביצועי הרשת הספציפיים ליישום אל היכולת של החומרה הבסיסית ולהצדיק את העלות.
עיבוד נתיב נתונים
הפתרון הפשוט לבעיות אלה הוא לכתוב מחדש את ערמת הרשת של Linux. אך לא מדובר במשימה קלה, במיוחד אם מתחשבים בקבלה הרחבה ההולכת וגדלה של מערכת הפעלה כמו Linux, ייתכן שלא יהיה אפשרי להחזיק מערכת הפעלה נוספת רק לעיבוד רשת.
יש לעשות כאן משהו שונה. ביישום טיפוסי לעיבוד רשת יכולות להיות אלפי זרימות. כל הזרימות נוצרות כשוות. לאחר שההגדרה הראשונית/אימות ראשוני, רוב הזרימות האלה דורשות עיבוד פשוט ודטרמיניסטי. על ידי זיהוי זרימות כאלה ושמירתן במטמון ועל ידי עיבוד מנות מידע כאלה בהקשר נפרד וממוטב היטב, ניתן להעביר זרימות כאלה למסלול מהיר.
ניתן לחלק כל עיבוד מנות כך:
נתיב השליטה דורש עיבוד רב יותר ויש לו זמן אחזור אינהרנטי ארוך יותר מנתיב הנתונים. נתיב השליטה דורש 90% מהקוד ונמצא בשימוש 10% מהזמן.
נתיב הנתונים דורש עיבוד מהיר ויעיל של מנות מידע. נתיב הנתונים דורש 10% בלבד מהקוד ונמצא בשימוש 90% מהזמן.
השאלה המובנת מאליה היא כיצד ניתן להאיץ את עשרת האחוזים האלה מקוד עיבוד הנתונים?
נתיב מהיר או מאיץ נתיב נתונים הוא התשובה לבעיה זו. נתיב מהיר אינו דבר חדש. הוא אומץ על ידי ספקי רשת במשך זמן רב. נתיב מהיר הוא ספציפי ליישומים הפועלים בהתקני רשת. לדוגמה, בהתקני רשת, ניתן ליישם נתיב מהיר בחומת אש, IPsec VPN, QoS ובהעברה, בין היתר.
יש סוגים שונים של יישומי נתיב מהיר בתעשייה כיום.
יישומי נתיב מהיר מבוססי ASIC.
יישום נתיב מהיר המבוסס על מעבד רשת
מישור שליטה ומישור נתונים בליבות מסוימות המפעילות CP וליבות מסוימות המפעילות Bare Metal DP או נתיב מהיר מנהלי.
נתיב מהיר מבוסס מנהל התקן רשת של Linux להתקנים המשתמשים ב-Linux SMP.
יש מספר יתרונות וחסרונות לגישות השונות של נתיב מהיר אך הרעיון הבסיסי נשאר זהה. בצע את העבודה השגרתית של עיבוד מנות בנתיב מהיר ותן לנתיב הרגיל לטפל בהגדרת חיבורים, חיבורים מיוחדים, מנות שליטה, מסד נתוני ליבה וכדומה. פתרונות המבוססים על חומרה מלווים בעלות – הן עלות ייצור והן צריכת חשמל. פער הביצועים בין הנתיב המהיר המבוסס על ניהול ובין נתיב מהיר של תוכנה המבוסס על Linux ניתן לגישור באמצעות תכנון חכם.
(הערה: אנחנו מגבילים את הדיונים במאמר זה לנתיב מהיר תוכנה מבוסס Linux בלבד.)
האצת נתיב נתונים באמצעות נתיב מהיר
מהן הדרישות שיש לזכור בעת תכנון מודול האצה של נתיב נתונים בתוכנה – במילים אחרות, נתיב מהיר המבוסס על תוכנה:
עליו להיות ספציפי ליישום: גודל אחד לא מתאים לכולם.
יש להימנע מחיפושים מרובים: שמור את כל המידע על סיווג ועיבוד של זרימות במקום אחד.
מינוף הפונקציונליות של חומרה בתוכנה כגון שימוש ב-hashing, חישוב בדיקת סיכום, קריפטוגרפיה, סיווג, תזמון כדי לספק תפוקה גבוהה יותר. נתיבים מהירים פועלים בקרבת החומרה הבסיסית ואמורה להיות להם גישה לכל תכונות החומרה.
הנתיב המהיר ממוטב תמיד לסוג ספציפי של חומרה, אך ניתן ליצור גם ארכיטקטורת שכבה. עליו לנצל את כל התכונות מבלי לחשוש לגבי איבוד כלליות. מכיוון שאמור להיות לו זיכרון קטן יותר וטביעת רגל קטנה יותר של הקוד, ייתכן שתיפגע הכלליות בין כל התקני החומרה.
הטמעות נתיב מהיר פועלות לפי מודל הפעלה-עד-לסיום. כך מופחת מעבר בין הקשרים ויש שימוש טוב יותר במטמון.
בזכות טביעת הרגל הקטנה, רוב הקודים של נתיב מהיר עשויים להתאים למטמון מעבדים L1.
נעילות הן הפגיעה העיקרית בביצועים. בצע את ההטמעות כך שיהיו חסרות נעילה עד כמה שאפשר. השתמש ביחידות RCU ובמבני נתונים חכמים אחרים כדי למנוע נעילה בנתיב לעיבוד מנות מידע.
השתמש בשיטות כגון הפרעה למיזוג והיגוי מנות כדי לשמור על איזון הולם במערכת.
מינוף של מחזור מאגרים להפעלת מהירה יותר של הזיכרון.
שימוש באגירה ונעילה של המטמון משפר את הביצועים.
אלגוריתם יעיל וממוטב לחיפוש בטבלאות עם חיזוי הוראות להפחתת האחזור בחיפוש במסד נתונים. יישור מטמון של מבנה הטבלאות עוזר גם הוא.
ASF – נתיב מהיר ספציפי ליישום
המטרה של נתיב מהיר ספציפי ליישום (ASF) זה אינה להחליף את ערמת הרשת המלאה של Linux אלא להאיץ את עיבוד המנות של הפונקציונליות בשימוש הנפוץ ביותר, כגון העברת IPv4, NAT, חומת אש, IPSEC ו-QoS. עיבוד רשת stateful חכם עדיין ממשיך להתרחש בערמת רשת Linux, כאשר עיבוד מנות stateless מהיר יתבצע ב-ASF. אך מצב זה לא מונע שימוש ב-stateful ASF.
ניתן לחלק הטמעת ASF לשלושה מרכיבים:
1. מנוע מנות ASF: מעבד מנות נתונים בפועל שפועל באינטראקציה הדוקה עם הרשת ומנהלי התקנים של אבטחה לצורך טיפול ועיבוד של מנות.
2. רכיבי API של ASF: כדי להגדיר את פרטי השליטה במנוע מנות ASF. המטרה של רכיבי API אלה היא לספק ממשק גנרי לתצורת ASF, שבה ASF יכול להיות מכל סוג או שניתן לממשק לוגיקת בקרה של ASF עם כל ערמת רשת אחרת או מערכת הפעלה אחרת.
3. לוגיקת בקרה ASF: התממשקות עם ערמת הרשת של Linux כדי להעביר את פרטי בקרת המנות הנדרשים ושימוש ברכיבי API של תצורת ASF כדי להגדיר את מנוע מנות ASF.
כל המנות הנכנסות למערכת מועברות ממנהל התקן Ethernet למודול ASF. במודול ASF, זרימת מנות נתונה (המבוססות על פרטי כותרת L2/L3/L4) נבדקת בטבלאות חיפוש ASF, שמאוכלסות באמצעות מודול בקרת ASF. אם זרימה מתאימה נמצאה למנה שהתקבלה, היא מעובדת בהתאם לפעולה שהוגדרה עבור זרימה זו ומועברת לממשק יציאה מוגדר או מסתיימת באופן מקומי.
המנות לזרימות שאינן מוגדרות מועברות לערמת הרשת של Linux לצורך עיבוד בנתיב נורמלי. בערמת רשת של Linux נערך חיפוש במנות אלה אחר הזנה תואמת בטבלאות חיפוש שונות של Linux, כגון socket, ניתוב FIB, מטמון ניתוב, מדיניות IPsec ומסד נתוני SA. אם נמצאים כללים, מנות מעובדות בהתאם להטמעה Linux ובנוסף לכך, אם קריטריוני התאמה מתאימים, זרימות אלה מועברות ל-ASF כך שמנות שיגיעו בהמשך לאותן זרימות מעובדות דרך ASF.
הפונקציונליות הבסיסית של מודול ASF היא שיש סדרה של כללים שהוגדרו ועיבוד של המנות הנכנסות על בסיסי הכללים שהוגדרו. כאשר מנה מתקבלת בממשק הקבלה של ASF, היא תנותח ויתבצע חיפוש (כפי שניתן לראות בתרשים 3) כדי לבדוק אם היא מתאימה לכלל קיים כלשהו. אם יש התאמה, המנה מעובדת דרך ASF; אחרת היא חוזרת לנתיב איטי דרך ערמת הרשת של Linux.
טבלה 1 מציגה דוגמה לכמה מיישומי הרשת שבהם נתיב נתונים מטופל ב-ASF ונתיב בקרה נמצא בערמת רשת של Linux:
פרטי בקרה מועברים מערמת רשת Linux
מודול בקרת ASF מתממשק עם ערמת רשת של Linux בנקודות פונקציה שונות.
1. טבלת ניתוב/שכנים: למידע על העברת IPv4
2. מודול IP conntrack: למעקב אחר חיבורי L3/L4
3. מסגרת עבודה XFRM: מנהל מפתחות IPsec להעברת הפעלות IPsec
4. מסגרת עבודה QoS: להעברת תצורה של דיסציפלינה של תורים. היא כוללת כללים של תזמון, מדיניות וסיווג, ותצורות של פרמטרים אחרים ב-ASF.
ניתן להשתמש בכלי חלל המשתמש הקיימים ב-Linux, כגון Iproute2, כלי ipsec, iptables, tc ו vconfig בצורה חלקה כדי להגדיר את ערמת הרשת של Linux. מישור הבקרה של ASF יקבל את המידע הדרוש מנקודות הפונקציה שהוזכרו לעיל בליבת Linux או שהוא ישתמש בתצורות בחלל המשתמש בממשק Netlink.
נבדוק בפירוט רב יותר חלק מדוגמאות אלה:
העברת IPv4: IPFwd הוא יישום העברה המבוסס על ניתוב ipv4. הוא יכול להעביר מנות ממשק Ethernet אחד לממשק Ethernet אחר בכתובת IP של המקור, כתובת IP של יעד ושדות ToS. את הניתוב ניתן להוסיף או למחוק באופן דינמי/סטטי.
ב-Linux, בכל פעם שמנה שאמורה להיות מועברת פוגעת במטמון הניתוב, מידע ההעברה מחולץ מערך טבלת הניתוב. בנקודה זו, זרימת ההעברה מועברת ל-ASF אם היא עדיין לא הועברה. בהיעדר מסגרת עבודה קיימת לקבלת מידע בקרה, ניתן להוסיף ווים למודולים של ניתוב ip ב-Linux (כגון route.c).
מצד שני, ASF מבצע את הפעולות הבאות בכל מנה שעוסקת בהעברת IPv4:
ניתוח
חיפוש וסיווג
הפחתת TTL עם בדיקת סיכום IP
העברה המבוססת על ToS.
תוסף של עדכון כותרת שכבה 2 (Ethernet וכו’)
NAT/NAPT/חומת אש: אין צורך לטפל בכל זרימה וזרימה ב-ASF. ה-TCP ו-UDP בשימוש הנפוץ ביותר ניתנים לעיבוד ב-ASF ובשאר הרימות ניתן לטפל בערמת רשת של Linux. בזרימות ה-TCP/UDP שדורשות עיבוד מיוחד עדיין ניתן לטפל ב-Linux; לדוגמה, מנות המבוססות על שער שכבת יישום.
מודול בקרת ASF מעביר את זרימות ה-NAT אל ASF מ-Linux שמזוהות על ידי מידע של 5 שורות, הכולל IP של מקור, IP של יעד, יציאת מקור, יציאת יעד ופרוטוקול. כל המנות הנכנסות למודול ASF מנותחות ומותאמות כנגד זרימות אלה. אם הזרימות נמצאות, כותרות L2 ו-L3 משתנות בהתאם לזרימות המוגדרות ומועברות לממשקים מוגדרים.
לוגיקת הבקרה של ASF רושמת במערכת המשנה של מודיע conntrack של Linux ומאזינה לאירועי חיבור. כאשר האירועים מובטחים, לוגיקת הבקרה מחלצת את המידע הרלוונטי ממבנה האירועים של המודיע בתכנות בפרמטרים של המסווג, מעקב מצב TCP ומנגנון בדיקת חותמת זמן.
מודול בקרת ASF מקבל אירועי מודיע מ-netfilter או ממערכת IP conntrack בכל פעם שחיבורים חדשים נקבעים או חיבורים קיימים מעודכן או מושמדים/מתיישנים על ידי מערכת conntrack של Linux. לכל חיבור חדש שבו הושגה לחיצת ידיים דו-כיוונית והחיבור מועבר למצב ‘מובטח’ על ידי conntrack, אירוע מובטח יתקבל על ידי מודול החיבור, שיפעיל את המנגנון הפנימי שלו כדי להעביר את החיבור אל ASF. מכיוון שרק מידע של L3/L4 התקבל באירוע המודיע, הוא יבצע חיפוש בניתוב הליבה ובטבלאות שכנים/ARP לקבלת מידע על L2 כגון כתובת MAC, יציאות יוצאות/נכנסות וכדומה, הדרוש להעברת החיבור.
לכל אירוע חיבור מובטח, מודול בקרת ASF יקבל גם יידע על המצב והרצף הנוכחי של החיבור, שיידרש לבדיקת חומת אש stateful ובדיקת רצף TCP. מידע זה יתקבל עבור כל אחת מהזרימות הדו-כיווניות, שיחדיו יוצרות חיבור.
תהליך הפירוק של חיבורים שנוצרו מטופל בדרך הבאה: לאחר שחיבור מושמד על ידי מערכת IP conntrack, מודול בקרת ASF יקבל אירוע DESTROY (השמד) ותזמון המתאים ללוח עבודה כדי להסיר ערכים מטבלת הזרימה המקומית של ASF.
עיבוד IPSEC: מודול בקרת ASF מטפל בהעברת פריטי מדיניות הקשורים ל-IPsec (SPD), שיוכי אבטחה (SA) ומידע הקשור לזרימה. הוא רושם במנהל מפתחות IPsec לקבלת המדיניות ואירועי הוספה/מחיקה/שינוי של SA; הוא מחלץ את המידע הרלוונטי ומגדיר את הגורם המכיל של המדיניות ופרטי SA ב-ASF באמצעות API של ASF. הוא מספק גם את פונקציות העזרה ל-IPV4 או לחומת האש. פונקציות אלה של עזרה בודקות שהזרימה מועברות עבור מדיניות IPsec.
סיום IP מקומי: ASF ניתן גם לשימוש להאצת עיבוד המנה עבור תנועה מסיימת/מתחילה מקומית ספציפית בחלל המשתמשים. ניתן להשתמש ב-ASF כדי לספק ממשק סיום אפס עותקים בחלל המשתמשים עם גישה ישירה למנה עם מנהל התקן Ethernet עבור יציאות UDP/כתובות IP המוגדרות.
שיטות עבודה מומלצות
האצת ביצוע מנות בהתקן מרובה ליבות היא בעיה בעלת ממדים רבים. קל בהרבה לספק אמות מידה של ביצועים מצוינים ביישום פשוט וספציפי, למשל העברת IP דו-כיוונית. אך יישומים בשטח הם מורכבים בהרבה לטיפול במונחים של פונקציונליות וביצועים. עיבוד מנות יעיל דורש שילוב של שיטות עבודה מומלצות בתכנון הכוללות:
ארכיטקטורה ממוטבת וייעודית המבוססת על נתיב מהיר שיכולה למדרג באופן ליניארי על פני מספר ליבות.
סנכרון שקוף בין מישור הבקרה, הנתיב האטי והנתיב המהיר.
השיטות המתוארות במאמר זה מיושמות ומוערכות בסדרת פלטפורמות QorIQ מרובות ליבה של Freescale . ניסויים אלה מראים שבאמצעות הגישות המוזכרות לעיל ניתן להאיץ תפוקת רשת פי 2 עד פי 10 בגודלי מנות קטנים. בגודלי מנות גדולים, נצפה ראיון במונחים של הפחתת השימוש הכולל במעבד. שיפור מדרוג מרובה-ליבות נראה גם הוא בטווח של 10 עד 30%.
