בימים בהם רשתות התקשורת שלנו עמוסות בתעבורת נתונים (שרק הולכת וגדלה) יש צורך בפתרונות הולמים. למשל? ארכיטקטורות של מעבדים מרובי ליבות והתקני תשתית לרשתות מהדור הבא
מאת: סריניוואסה אדפאלי ורקש ג’והן, Freescale Semiconductor
רשתות התקשורת חוות בימים אלה ממש ‘התפוצצות של תעבורה’, במלוא מובן המילה. מדי חודש מופיעים ברשת מיליוני אתרי אינטרנט חדשים, שנה אחר שנה, אנו עדים לשימוש מתרחב והולך בטלפונים חכמים [smart phone], שבתורם מרחיבים הן את נפח תעבורת הנתונים והן את תעבורת הקול. שירותים של נתוני קול ונתוני וידיאו עוברים מיזוג. רשתות חברתיות מתפשטות במהירות והדחיפה לכיוון של מחשוב בעננים [cloud computing] הולכת ומואצת. תקשורת וידיאו ווידיאו–צ’אט, הנחשבים יישומים “זוללי” רוחב פס, יהפכו בעתיד לעניין שבשגרה.
באופן מסורתי היה מקובל שרשתות מבוססות מיתוג מעגלים העבירו את תעבורת הקול, ורשתות מיתוג חבילות העבירו נתונים. כיום, רשתות מבוססות מיתוג מעגלים הופכות במהירות להיות עניין השייך לעבר. רשתות מיתוג חבילות מעבירות תעבורה של קול, וידיאו ושל נתונים. בניגוד לתעבורת נתונים אופיינית, התעבורה של קול ווידיאו תלויה בזמן, ולכן גורמים כמו קיצור זמן האחזור [latency] וריצוד [jitter] הופכים להיות בעלי חשיבות גבוהה. כעת, הוטל על התקני תשתית רשתות להתמודד עם מגוון בעיות, כמו למשל, קביעת עדיפות של חבילות קול וחבילות וידיאו, קיצור של זמני אחזור, ריצוד ומניעת מעבר של חבילות “שאינן לפי הסדר” במחזורים [session] של שיחת אודיו או שיחת וידיאו. ובנוסף, אנו מצפים שהתקנים אלו יטפלו בסיווגי שירות שקשורים בהסכמים של רמות שירות ובוויסות [throttling] של תעבורה לא רצויה, כמו למשל הורדות ברשת מעמית לעמית [peer to peer], גילוי וסיכול התקפות על הרשתות וכיו”ב. לא רק שכמות התעבורה גדלה במידה רבה, גם תהליך העיבוד המתבצע על חבילה יחידה התרחב, בהתאמה. כל אלו ודברים נוספים הוכיחו עצמם כגורמים שיוצרים עומס משמעותי על תשתית הרישות ועל התקשורת במונחים של קיבולת, עלות, איכות של שירות, וחשוב באותה מידה – גם במונחים של הזמן הנדרש כדי להסתגל לשינוי.
הגישות הקודמות
בעבר נהגו יצרנים של התקני תשתית רישות להשתמש במעבדי ASIC המיועדים לשימושים מיוחדים, על מנת לעמוד באתגרים הכרוכים בעומסי התעבורה המתרחבים והולכים, במיזוג של קול, וידיאו ונתונים ובאבטחת התעבורה. בגישה זו, המעבדים לשימושים כלליים נותרו כדי לטפל בעיבוד במישור הניהול והבקרה, שעה שמעגלי ASIC טיפלו בחלק העיקרי של עיבוד החבילות. על אף שבאמצעות גישה זו ניתן היה לעמוד בדרישות האתגרים, היא הציבה בפני יצרנים של ציוד רשתות קבוצה חדשה של בעיות. כל הרחבה חדשה שנוספה לעיבוד החבילות, כל שינוי במפרטי הפרוטוקולים או תיקון בעיות בלוגיקת הטיפול בחבילות, גרמו למחזורים ארוכים באספקת המוצרים ולעלויות פיתוח גבוהות יותר מאשר קודם לכן, אשר היו כרוכות בסבבים חוזרים ונשנים לניפוי שגיאות של מעבדי ASIC.
בעיות מובנות אלו הקשורות לגישת ASIC הניעו את התעשייה לחפש חלופה מעשית שעלותה נמוכה, שהתגשמה בצורת דור חדש של מעבדים ייעודיים וניתנים לתכנות, שנקראו “מעבדי רשתות” ו”מעבדי תקשורת“. מעבדי הרשתות נועדו לבצע משימות רישות וניתנו לתכנות באמצעות שפת קוד–מיקרו מיוחדת. הבעיות שהיו קשורות במעגלי ASIC נפתרו בזכות יכולת תכנות זו. מעבדים אלו שרתו באופן נאמן, פחות או יותר, את המטרות שלשמן הם נועדו, אך העלויות והמורכבויות הכרוכות בשימוש בהם לא פחתו במידה שיצרני הציוד רצו. התכנות בקידוד המיקרו של מעבדים אלו הוא משימה למומחים וגוזל זמן רב באופן משמעותי לצורך בדיקה וניפוי שגיאות. כמו כן, משאבי היכולת והפונקציונליות המועברים למעבד כזה יהיו מוגבלים עד אשר גרסה חדשה של מעבד תופיע בשוק. לעת עתה, בעיות של תאימות לאחור, שינויי קוד ומחזורי בדיקה עדיין מהווים בעיה.
גישת הליבות המרובות
גישה חדשה, שהיא למעשה גישת כלאיים, באה לשלב בקרים מרובי מעבדים במישורי הבקרה והנתונים. השילוב של מנועי האצה מרובים וליבות מרובות לשימוש כללי עם ביזור גרעיני [granular] של יכולות עומס העבודה, הופך את השבבים מרובי הליבות לאפשרות מעשית עבור יצרני ההתקנים לתשתיות של רשתות. ניתן להפעיל קוד מסורתי [legacy] שנוצר באמצעות כלי מהדרים מסורתיים, ליצור קוד עבור כל פונקציונליות שנדרשת לביצוע במלואה בתוכנה, ולשדרג את הביצועים בעזרת ליבות מרובות. המשמעות של ההסתגלות לשינוי יכולה להיות שימוש בשבבי ריבוי ליבות בעלי צפיפות גבוהה של ליבות ותוספת של פונקציונליות חדשה באמצעות שפת תכנות לשימוש כללי, כדוגמת שפת “C”. מעבדים מרובי ליבות, בצירוף יכולות של “מפקח העל” [hypervisor] בחומרה, תומכים בריבוי של קובצי דמות בביזור על פני הליבות ומפשטים את המימוש של מישור הבקרה ואת המימוש של מישור הנתונים בשבבים מרובי ליבות. גישה זו חוסכת עלות ומקטינה את דרישות ההספק, ובמקביל גם מספקת גמישות וביצועים. בגישת ריבוי הליבות, מפתחי ציוד תשתיות לרשתות יכולים להקצות ליבה אחת או יותר לעיבוד במישור הבקרה ובמישור הנתונים. חלוקה של הליבות בין המישורים תלויה בפרישת היישום ובפרישת המטרה.
גישת מעגלי ASIC ומעבדי רשתות ייעודיים למישור הנתונים מספקת בקרת חבילות שלמה ליישומי מישור הנתונים ומשיגה בכך ביצועים והתנהגות זמן אמת עבור יישומים תלויי זמן. בגישת הליבות המרובות, עיבוד חבילות דומה צפוי לענות על דרישות האתגרים. אנו מאמינים שחלק ממרכיבי המבנה הקריטיים הנדרשים הם: שימוש במערכות הפעלה “הפועלת ישירות בחומרה” [Bare-Metal], פעולה עד השלמה [RTC], ביזור אחיד של התעבורה על פני הליבות ושימוש מזערי בפעולות נעילה.
מערכת הפעלה הפועלת ישירות בחומרה
בשל אופיין של מערכות הפעלה לשימוש כללי, התקורה הכרוכה בהן הופכלת להיות רבה למדי. דוגמאות לכך כוללות את התקורה הקשורה לפסיקות [interrupt] – מערכות הפעלה לשימוש כללי פועלות בדרך כלל על אירועים חיצוניים, כולל הגעה של חבילות באמצעות פסיקות. בקרת החבילות מתבצעת בדרך כלל על ידי מערכת ההפעלה ומספקת נקודות עיגון עבור יישומי עיבוד החבילות. בנוסף, למפתחי יישומים אין אפשרות לשלוט ברבות מבין משימות התחזוקה במערכות הפעלה לשימוש כללי, או שבאופן חלקי אין למפתחים אפשרות לקבוע עדיפות למשימות אלו, ובכך הן גורמות לזמן אחזור נוסף ולריצוד מוגדל בשעה שמתבצעות משימות תחזוקה. מערכת הפעלה הפועלת ישירות בחומרה היא הבחירה הנכונה עבור יישומי עיבוד חבילות. מערכת הפעלה הפועלת ישירות בחומרה היא למעשה אוסף של פונקציות ספריה שמאיצות את הפיתוח של יישומי עיבוד חבילות. פעולה שמתבצעת באופן ישיר בחומרה עם מודל פעולה עד השלמה, פועלת בצורה הטובה ביותר עבור יישומי מישור הנתונים.
עיבוד בפעולה עד השלמה באופן ישיר בחומרה
במודל פעולה עד השלמה, ליבה שקולטת חבילה לא תשחרר את הבקרה עד לשידור החבילה, או עד אשר החבילה נמסרת לאחד ממאיצי החמרה. הקוד שפועל בכל ליבה הופך בהכרח להיות לולאה הממתינה לאירוע (כמו למשל כניסה של חבילה) בדרך של תשאול
[polling] ומעבדת את האירוע, כאשר הוא קיים.
מודל הפעולה באופן ישיר בחומרה עם פעולה עד השלמה מציע יתרונות משמעותיים בביצועים בהשוואה ליישום בתוכנה מסורתית שפועל במערכת הפעלה לשימוש כללי. אין תקורה של מערכת ההפעלה או זמני אחזור של פסיקות עבור העברת חבילות ויש בקרה מלאה על קביעת לוחות הזמנים של החבילות ועל הטיפול בהן. בנוסף, הקוד משתמש בצורה הטובה ביותר בהיררכית זיכרון המטמון [cache] שמוסיפה ומשתפרת על ידי אגירה של נתונים והקשרים חשובים של חבילות בזיכרון המטמון ו”חימומו” באמצעות חומרה של ריבוי ליבות. מאחר שיישום עיבוד חבילות הוא היישום היחיד במישור הנתונים, הוא יכול לנצל את חומרת המאיץ ללא התקורה הנקשרת לדרייברים לשימושים כלליים. בתלות בסוג היישום, לא יהיה זה נדיר לצפות לשיפור של פי שניים או פי שלושה בביצועים, לעומת גישה שמשתמשת במערכת הפעלה לשימוש כללי שבה פועל היישום.
האצת נתיב הנתונים
לא כל היכולות של מעבדים מרובי ליבות שוות. כאשר משתמשים במעבדים מרובי ליבות עבור מישור הנתונים, או מצפים ליכולות של “האצת נתיב הנתונים” הבאות מהמעבדים מרובי הליבות. יצרני התקנים לתשתיות של רשתות צריכים לחפש את ההיבטים החשובים הבאים:
∞ יכולת חלוקת תעבורה: ניתן לצפות ממעבדים מרובי ליבות שיספקו יכולות הבאות להבטיח שנעשה שימוש מלא בליבות. חלוקת תעבורה בחומרה היא אחת היכולות שיצרני ציוד מחפשים. חשוב גם שאמות המידה לחלוקת התעבורה יימצאו בשליטה של יישום מישור הנתונים, על ידי תכנות שלהם בתוך החומרה לחלוקה של תעבורה נכנסת. בין הדוגמאות נמצאות חלוקה מבוססת VLAN, חלוקה מבוססת 5 רשומות קבועות [tuple], חלוקה מבוססת אינדקס פרמטר אבטחה IPsec [SPI] או כל שילוב שלהם.
∞ קביעת עדיפות של התעבורה הנכנסת: על מנת לשמור על זמן אחזור קצר וריצוד נמוך עבור חבילות אודיו ווידיאו ובמקביל, להבטיח שתמיד תהיה גישה לתעבורת הניהול גם במקרים של התקפות DDOS, חשוב שהמעבדים מרובי הליבות יספקו עזרים לקביעת עדיפויות של תעבורה נכנסת. יש להעביר לליבות תעבורה בעלת עדיפות גבוהה על פני תעבורה בעלת עדיפות רגילה או נמוכה. ניתן לצפות שמעבדים מרובי ליבות יהיו ניתנים לתכנות כדי להגדיר את אמות המידה לקביעת העדיפויות.
∞ קביעת מדיניות של תעבורה: חיסכון במחזורי יע”מ [CPU] הוא אחד ההיבטים החשובים. כל התעבורה שאינה רצויה או התעבורה שחורגת מערכי סף מוגדרים אמורה שלא להיראות על ידי הליבות. יש לחפש את תכונת קביעת המדיניות של התעבורה בחומרת המעבד כדי שיוכל להגן על עצמו מפני מצב של הצפה בתעבורה.
∞ האצת אבטחה: שיטות לאבטחת נתונים כדוגמת IPsec, MACsec ו–SSL/TLS פרושות כיום בצורה נרחבת בהתקני תשתית רבים. מאחר שמעורבת בהן הצפנה, הן צורכות משאבי מחשוב רבים. מעבדים מרובי ליבות אמורים לספק אינטגרציה עם מנועי האצה כדי להסיר מהליבות את העומס של פעולות אלו, שצורכות משאבי מחשוב רבים. חלק מהמעבדים מרובי הליבות כמו למשל משפחות המעבדים P3 ו–P4 של Freescale מתקדמים צעד אחד קדימה ומספקים הסרה מלאה של עומס הפרוטוקולים (כימוס
[encapsulation] וגילוי מכימוס [decapsulation] של כותרת הפרוטוקולים IPsec, MACsec, SRTP ו–SSL ופונקציות נוספות ייחודיות לפרוטוקול) ומשאירים מחזורים נוספים כדי שהליבות יוכלו לבצע משימות חשובות אחרות.
∞ ניהול תורים וניהול מאגר זיכרון: לכל יישום של עיבוד חבילות רשת נדרש ניהול חופשי של מאגר הזיכרון [buffer] בפעולות כמו הקצאה ושחרור של בלוקים בזיכרון. כמו כן, ליישומי מישור הנתונים נדרש ניהול תורים כדי להעביר חבילות למנועי חומרה שונים או לליבות אחרות כדי לטפל במשימות מסוימות. אולי הפעולות הכרוכות בניהול תורים ובניהול של זיכרון חופשי לא נראות עמוסות, אך הן צורכות מחזורי יע”מ משמעותיים כשמבצעים אותן שוב ושוב ולעתים קרובות. המפתחים של יישומי מישור הנתונים מברכים תמיד כל תמיכה של חומרה בפעולות אלו.
לסיכום, מעבדים מרובי ליבות הופכים להיות הבחירה הנכונה העיקרית של יצרני ההתקנים לתשתיות של רשתות שמבקשים לממש ארכיטקטורות מבוססות מישור בקרה ומישור נתונים. תמיכה ב”מפקח על” בחומרת מעבדים מרובי ליבות מפשטת את השימוש בשבב מרובה ליבות עבור מישור הבקרה ועבור מישור הנתונים, ומובילה לחיסכון בעלות. תמיכה בהאצת נתיב הנתונים בחומרה בשילוב עם “מערכת הפעלה הפועלת ישירות בחומרה” ועם מודל התוכנה “פעולה עד להשלמה” מסייעת ליצרנים לעבור בבטחה ממעגלי ASIC וממעבדי רשתות ייעודיים למעבדים מרובי ליבות ועדיין לעמוד בדרישות התפוקה, בזמן האחזור והריצוד של הרשתות של ימינו.