סטנדרטים פתוחים ב-NFV: הבחירה בגישה היברידית
מאת: צ'ארלי אשטון, 21.7.16, 09:06
 
ה-NFV מספק הרחבה דינמית של תהליכים ומשאבי רשת, ברשתות תקשורת מכל סוג. אחת הדרישות הקריטיות להפעלה יעילה של NFV היא "פתיחות" ופיתוח בסביבת קוד פתוח. פתרונות פתוחים ו/או בעלי יכולת פעילות הדדית בין מערכות, יכולים להגדיל משמעותית את מספר ספקי התוכנה, דבר המגביר חדשנות, מוריד עלויות ומוביל למערכות NFV עתירות ביצועים.

משמעות הצמיחה האקספוננציאלית בתעבורת נתונים, כמו זו המגיעה מהזרמת וידאו ומהתרחבות של קשרים חדשים עבור ה-IoT (אינטרנט של הדברים), היא אתגר גדול מתמיד לספקי שירות, במטרה לטפל בביקוש הגדל במהירות לרוחב פס.

בנוסף, ספקי שירות מחפשים דרכים להפחית את השקעות ההון והוצאות התפעול שלהם, תוך הפעלה במקביל של שירותים, שייצרו תזרימי הכנסה עתידיים.
 
היסטורית, תשתיות רשתות הטלקום התבססו על תוכנה קניינית, שפעלה על חומרה ייעודית, שנבנתה במיוחד עבור פעולה אחת ויחידה. אך היום, חברות הטלקום וספקי שירותי רשת בוחנים Network Functions Virtualization NFV - לחידוש וטרנספורמציית הרשתות שלהם.
 
התפיסה המרכזית של NFV היא תכנון, פריסה וניהול של שירותים באמצעות הפרדת פונקציות רשת מהחומרה הייעודית עליה הן פועלות. כך, מתבצעת וירטואליזציה של מספר אפליקציות ופונקציות רשת, תוך הרצתן בתוכנה על בסיס פלטפורמות שרתים סטנדרטיות. הדבר מאפשר גם יכולת גידול בכמות היישומים.
 
חשוב לציין, שאחת הדרישות הקריטיות להפעלה יעילה של NFV היא "פתיחות". פתרונות פתוחים ו/או בעלי יכולת פעילות הדדית בין מערכות, יכולים להגדיל משמעותית את מספר ספקי התוכנה, דבר המגביר חדשנות. שימוש באסטרטגיה פתוחה משמעותו גם, שיצרני ציוד טלקוםTEMs -  יכולים לפתח פתרונות חדשים מהר יותר, תוך הפחתה אפשרית של עלויות פיתוח.
 
OPNFV
פרויקט Open Platform for NFV - OPNFV, שהושק בספטמבר 2014, הוא פלטפורמת ייחוס בקוד פתוח, שנועדה להאיץ את ההשקה של פתרונות ושירותי NFV.

OPNFV פועל תחת Linux Fundation, כשהיעד המרכזי שלו הוא להטמיע את מפרטי ETSI עבור NFV.
 
שניים מהעקרונות הבסיסיים של פרויקט OPNFV (באיור להלן) הם:
 
שיתוף פעולה בין חברות הפועלות ברחבי הEcosystem-  של NFV בסביבת קוד פתוח, דבר שצפוי להביא לתוכנת ייחוס  באיכות גבוהה, אותה ניתן לשלב בתוך פתרונות מסחריים.
 
העיקרון השני: פתרונות הממנפים את קוד ה-OPNFV, שיהפכו לזמינים בשוק מהר בהרבה מאשר אלה, שפותחו מהיסוד, או כאלה, שהחלו בפרויקטים ארגוניים.

סקירה של פלטפורמת OPNFV מוצגת באיור.
     
המיקוד הראשוני של פרויקט OPNFV הוא בתשתית NFV (NFVI) ותוכנת ניהול תשתית וירטואלית - VIM. את אלה ניתן להטמיע באמצעות שילוב רכיבים מפרויקטים שונים, בהם: OpenDaylight, OpenStack, Ceph Storage, KVM, Open vSwitch ו- Linux.

יחד עם ה-APIs שלו, ה-NFVI ורכיבי תוכנת VIM, תיווצר התשתית הבסיסית הדרושה לאירוח פונקציות רשת וירטואליות -VNF  וההתממשקות לניהול ו-Orchestration (MANO). הנהנים העיקריים מ-OPNFV צפויים להיות ספקי שירות, אבל ייהנו ממנו גם מפתחי תוכנת VNF עם ממשקים סטנדרטיים, שמקדמים ניידות ופעולה בין מערכתית.
 
גרסת OPNFV הראשונה שוחררה ביוני 2015, תחת שם הקוד 'Arno'. המהדורה כללה רכיבי NFVI ו-VIM והתמקדה מאוד במפתחי VNF. השילוב אפשר גם להפעיל ולקשר VNFs בארכיטקטורת ענן, על בסיס OpenStack ו-OpenDaylight. הגרסה השנייה, תחת שם הקוד 'Brahmaputra', הייתה הראשונה 'המוכנה למעבדה'. היא כוללת שדרוגים רבים בתחומים כגון התקנה, אינטגרציה מתמשכת, תיעוד משופר ודוגמאות של תרחישי מבחן.
 
אתגרים
סקר עצמאי, שנערך לאחרונה (ע"י  Telecom TV), שאל יצרני ציוד טלקום - TEMs, ספקי שירות - CSPs ויצרני תוכנה, מה הם השיקולים החשובים ביותר בעת פריסת NFV ברשת מסחרית. המסקנה, שעלתה מהסקר הייתה, ש-2 השיקולים החשובים ביותר הם פתרונות בעלי יכולת שילוב הדדית ממספר ספקים והדרישה לאמינות וזמינות ברמת ספקי טלקום.
 
כדי להבטיח, שלפתרונות יש יכולת שילוב הדדית עם אחרים, על ספקי NFV להיות מודעים באופן מלא לסטנדרטים של NFV, שהוגדרו ע"י יוזמת ETSI, מאחר שיותר ויותר מדובר בתאימות בין מערכתית מול חברות אחרות בעולם ה-NFV. למרות שסטנדרטים פתוחים מונעים נעילה לספק מסוים ע"י פיתוח של פתרונות תואמים ובעלי יכולת שילוב הדדית ממספר חברות, ספקי שירות ישלבו בדרך כלל מוצרים של יותר מאשר ספק אחד במסגרת הפתרון המלא הניתן לפריסה. המשמעות היא, שספקי שירות ידרשו הוכחה, שמוצרים יעבדו יחדיו בצורה חלקה.
 
הנקודה הבאה היא אמינות וזמינות ברמת ספק טלקום ויש לה חשיבות גדולה. התעשייה דורשת מ-OPNFV להתבסס על קוד פתוח. עם זאת, לקהילת הקוד הפתוח אין עדיין יכולות זמינות גבוהה וביצועים, שהן הכרחיות לפלטפורמה ברמת ספקי טלקום העומדות במינימום ההכרחי של 5 תשיעיות (99.999%) או 6 תשיעיות (99.9999%). הטמעות NFV תידרשנה לתוכנת וירטואליזציה ברמת ספקי טלקום כדי לספק יכולת תעבורה בזמן אמת, כמו גם את יכולות הגידול הדרושות כדי לטפל במיליארדי מכשירים חדשים מקושרים וביצירת כמויות הולכות וגדלות של תעבורת נתונים.
 
ביצועים, גידול ודרישות אבטחה הם יותר קשיחים עבור מיתוג וירטואלי ברשת של ספק שירות. לדוגמא, ל-Open vSwitch - OVS יש כרגע מגבלות תכנון, שבאות לביטוי ביכולת גידול, יעילות וביצועים נחותות יותר. בנוסף, מהדורות Arno ו-Brahmaputra אינן כוללות תכונות התורמות לאספקת אמינות ברמת ספקי טלקום בפלטפורמת ה-NFVI.
 
נושא מרכזי שלישי, הוא הצורך, שקיים בתעשייה, לגמישות ובידול של פלטפורמות במונחי עמידה בדרישות ובביצועים ברמת ספקי טלקום ולא רק בדרישות של אפליקציית NFV. תוכנה של ספק ספציפי תהיה לעתים עדיפה או תספק יכולות, שאינן זמינות בתוכנת קוד פתוח. לכן, תוכנה קניינית יכולה לספק לספקי שירות ו-TEMs יתרון תחרותי.
 
גישה היברידית
לסיכום, צריך להיות ברור כי ישנם יתרונות רבים של הבטחת  סטנדרטים פתוחים דה פקטו עבור NFV .
 
OPNFV מספק תוכנת התייחסות באיכות גבוהה, שיכולה להשתלב לתוך פתרונות מסחריים. זה גם אומר, שפתרונות הממנפים את OPNFV יכולים להיות זמינים לשוק מהר יותר באופן משמעותי. עם זאת, באופן כללי, טכנולוגיות שרתים ומחשוב ארגוני, שמבוססות על 100% פתרונות קוד פתוח, לא נועדו לעמוד בדרישות המחמירות של רשתות ספקי הטלקום. לקהילת הקוד הפתוח פשוט אין את היכולות לספק זמינות גבוהה וביצועים ההכרחיות עבור מפעילי הטלקום.
 
בנוסף, חשוב, שתהיה ל-TEMs ו-CSPs יכולת בידול לפלטפורמות שלהם. כל זה אומר, שהפתרון האופטימלי חייב להיות גישה היברידית מבוססת על תקני ומפרטי OPNFVETSI  פתוחים, ובמקביל לקחת את המיטב מפתרונות של יצרנים ספציפיים כדי לקדם חדשנות בשוק. בעת בחירת פתרונות NFV, על TEMs ו-CSPs לשקול את אותם ספקי תוכנה המטמיעים גישה היברידית זאת בהיצע מוצרי ה-NFV שלהם.

בעולם אידיאלי, מה שנדרש הוא פלטפורמת NFV מוכנה ל-VNF, שכוללת מוצרי תוכנה וחומרה מובילים בתעשייה, שמראש בוצעה בהם אינטגרציה, קיבלו אישורים, והם תואמים ב-100% לכל תקני API רלוונטיים כגון ETSI MANO, OpenStack  ו-KVM. ראוי גם להשתמש בארכיטקטורת plug-in פתוחה עבור OpenStack, לתמיכה ביכולת הפעולה ההדדית של רכיבי קוד פתוח סטנדרטיים, ובתוכנה מותאמת תואמת- API.
 
באופן אידיאלי, פלטפורמה זו גם צריכה לבוא מספק, שהוא חלק מיוזמת ETSI NFV, וסייע להגדיר ולעצב את המפרטים. בנוסף, על הפלטפורמה גם לענות על דרישות ביצועים הכרחיות, שנדרשות עבור מיתוג ברמת ספקי טלקום בתחומים מרכזיים, שאינם מקבלים מענה מפתרונות מבוססים על סטנדרטים פתוחים כגון vSwitch OVS .
 
כמו כן, נדרשים מוצרים קנייניים העונים למגבלות של OVS תוך אספקת יכולת גידול רבה יותר ויעילות ביצועים, שדרושות כדי לשלול את האפשרות של נעילה לספק ספציפי, ולספק פתיחות דרך השימוש בממשקי תכנות יישומים (APIs) ו-OpenStack  לדוגמא, כדי לספק את הרמה הנדרשת של הפשטה.
 
יצרני תוכנה, שיכולים להתבסס על היסודות של 'הפתוח' יחד עם רמות הביצועים אותן מספק 'הקנייני', הם אלה המאפשרים ל-CSPs ו-TEMs לספק את הדור הבא של רשתות ומערכות NFV פתוחות עתירות ביצועים.
 
מאת: צ'ארלי אשטון, יולי 2016.
מנהל פיתוח עסקי בכיר בחברת ווינד ריבר
ווינד ריבר בישראל - חברת ScaleIL - כאן.