מארג רשת למרכז הנתונים של Cisco ACI - לסיוע למנהל

בעזרת החלק הקסום הזה של סקריפט Cisco ACI, אתה יכול להגדיר רשת במהירות.

מפעל הרשת של מרכז הנתונים של Cisco ACI קיים כבר חמש שנים, אבל Habré לא ממש סיפר על זה כלום, אז החלטתי לתקן את זה קצת. אני אגיד לך מניסיוני מה זה, מה השימוש בו והיכן יש לו מגרפה.

מה זה ומאיפה זה הגיע?

עד שהוכרזה ACI (Application Centric Infrastructure) ב-2013, המתחרים התקדמו בגישות מסורתיות לרשתות מרכזי נתונים משלושה צדדים בבת אחת.

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

לבקר הזה יהיה חזון אחד של כל מה שקורה, ועל סמך זה יתכנת את החומרה של כל המתגים ברמת הכללים לעיבוד זרימות ספציפיות.
מצד שני, פתרונות שכבת-על אפשרו ליישם את מדיניות הקישוריות והאבטחה הנדרשת ללא שינויים כלל ברשת הפיזית, תוך בניית מנהרות תוכנה בין מארחים וירטואליים. הדוגמה המוכרת ביותר לגישה זו הייתה Nicira, שעד אז כבר נרכשה על ידי VMWare תמורת 1,26 מיליארד דולר והולידה את ה-VMWare NSX הנוכחי. קצת פיקנטיות של המצב נוספה על ידי העובדה שהמייסדים השותפים של ניקירה היו אותם אנשים שעמדו בעבר במקור של OpenFlow, עכשיו אמרו שכדי לבנות מפעל מרכז נתונים OpenFlow אינו מתאים.

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

ACI הפכה ל"תגובה הא-סימטרית" של סיסקו (ליתר דיוק, חברת Insieme שלה, שהוקמה על ידי עובדיה לשעבר) לכל האמור לעיל.

מה ההבדל עם OpenFlow?

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

ACI משתמש בגישה ההפוכה: כמובן, יש גם בקר, אבל המתגים מקבלים ממנו מדיניות הצהרתית ברמה גבוהה, והמתג עצמו מבצע את העיבוד שלהם לפרטי הגדרות ספציפיות בחומרה. ניתן לאתחל את הבקר או לכבות אותו לחלוטין, ושום דבר רע לא יקרה לרשת, מלבד, כמובן, חוסר השליטה ברגע זה. מעניין לציין כי ישנם מצבים ב-ACI שבהם עדיין נעשה שימוש ב-OpenFlow, אך באופן מקומי בתוך המארח עבור תכנות Open vSwitch.

ACI בנויה כולה על העברת שכבת-על מבוססת VXLAN, אך כוללת את הובלת ה-IP הבסיסית כחלק מפתרון יחיד. סיסקו כינתה את המונח "שכבת-על משולבת". כנקודת סיום לשכבות-על ב-ACI, ברוב המקרים, נעשה שימוש במתגי מפעל (הם עושים זאת במהירות קישור). מארחים אינם נדרשים לדעת דבר על המפעל, אנקפסולציה וכו', אולם במקרים מסוימים (לדוגמה, כדי לחבר מארחים של OpenStack), ניתן להביא אליהם תעבורת VXLAN.

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

שבבים מ-Broadcom שימשו בעבר את סיסקו במתגים מסדרת Nexus 3000. במשפחת ה-Nexus 9000, שפורסמה במיוחד לתמיכה ב-ACI, יושם במקור דגם היברידי, שנקרא Merchant +. המתג השתמש בו זמנית גם בשבב החדש של Broadcom Trident 2 וגם בשבב משלים שפותח על ידי סיסקו, שמיישם את כל הקסם של ACI. ככל הנראה, הדבר איפשר לזרז את יציאת המוצר ולהוזיל את תג המחיר של המתג לרמה הקרובה לדגמים המבוססים פשוט על Trident 2. גישה זו הספיקה לשנתיים-שלוש הראשונות של משלוחי ACI. במהלך תקופה זו, סיסקו פיתחה והשיקה את הדור הבא של Nexus 9000 על שבבים משלה עם יותר ביצועים וערכת תכונות, אך באותה רמת מחיר. מפרט חיצוני מבחינת אינטראקציה במפעל נשמר לחלוטין. יחד עם זאת, המילוי הפנימי השתנה לחלוטין: משהו כמו refactoring, אבל עבור ברזל.

כיצד פועלת ארכיטקטורת Cisco ACI

במקרה הפשוט ביותר, ACI בנויה על הטופולוגיה של רשת Klose, או, כפי שאומרים לעתים קרובות, Spine-Leaf. מתגים ברמת עמוד השדרה יכולים להיות בין שניים (או אחד, אם לא אכפת לנו מסובלנות לתקלות) לשישה. בהתאם לכך, ככל שיהיו יותר מהם, סובלנות התקלות גבוהה יותר (כך יורדת רוחב הפס והאמינות במקרה של תאונה או תחזוקה של Spine אחד) והביצועים הכוללים. כל החיבורים החיצוניים עוברים למתגים ברמת העלים: אלה שרתים, ועגינה עם רשתות חיצוניות דרך L2 או L3, וחיבור בקרי APIC. באופן כללי, עם ACI, לא רק קונפיגורציה, אלא גם איסוף סטטיסטיקות, ניטור כשלים וכדומה - הכל נעשה דרך ממשק הבקרים, מהם יש שלושה ביישומים בגודל סטנדרטי.

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

מבחינה פנימית, המפעל משתמש בהובלת IP, כך שאין בו Spanning Tree ושאר זוועות העבר: כל הקישורים מעורבים, וההתכנסות במקרה של כשלים מהירה מאוד. התעבורה במארג מועברת דרך מנהרות המבוססות על VXLAN. ליתר דיוק, סיסקו עצמה קוראת ל-iVXLAN encapsulation, והיא שונה מ-VXLAN רגילה בכך שהשדות השמורים בכותרת הרשת משמשים להעברת מידע שירות, בעיקר על הקשר של תעבורה לקבוצת EPG. זה מאפשר לך ליישם את כללי האינטראקציה בין קבוצות בציוד, תוך שימוש במספרים שלהם באותו אופן שבו משתמשים בכתובות ברשימות גישה רגילות.

מנהרות מאפשרות למתוח גם מקטעי L2 וגם מקטעי L3 (כלומר VRF) דרך תעבורת ה-IP הפנימית. במקרה זה, שער ברירת המחדל מופץ. המשמעות היא שכל מתג אחראי על ניתוב התנועה הנכנסת למארג. מבחינת לוגיקה של זרימת תעבורה, ACI דומה למארג VXLAN/EVPN.

אם כן, מה ההבדלים? כל דבר אחר!

ההבדל מספר אחד שאתה נתקל ב-ACI הוא האופן שבו שרתים מחוברים לרשת. ברשתות מסורתיות, ההכללה של שרתים פיזיים ומכונות וירטואליות כאחד עוברת ל-VLAN, וכל השאר רוקד מהם: קישוריות, אבטחה וכו'. ב-ACI משתמשים בעיצוב שסיסקו מכנה EPG (End-point Group), שממנו אין מקום לברוח. האם אפשר להשוות את זה ל-VLAN? כן, אבל במקרה הזה יש סיכוי לאבד את רוב מה ש-ACI נותן.

לגבי EPG, כל כללי הגישה מנוסחים, וב-ACI משתמשים בעקרון "הרשימה הלבנה" כברירת מחדל, כלומר מותרת רק תעבורה שהמעבר שלה מותר במפורש. כלומר, נוכל ליצור את קבוצות ה-EPG "Web" ו-"MySQL" ולהגדיר כלל המאפשר תקשורת ביניהן רק בפורט 3306. זה יעבוד בלי להיות קשור לכתובות רשת ואפילו בתוך אותה רשת משנה!

יש לנו לקוחות שבחרו ב-ACI בדיוק בגלל התכונה הזו, שכן היא מאפשרת להגביל גישה בין שרתים (וירטואלית או פיזית - זה לא משנה) בלי לגרור אותם בין רשתות משנה, כלומר בלי לגעת בכתובת. כן, כן, אנחנו יודעים שאף אחד לא רושם כתובות IP בתצורות יישומים ביד, נכון?

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

איך שרתים נכנסים לקבוצות האלה? אם אלו שרתים פיזיים או משהו שנכלל ברשת קיימת שלתוכה יצרנו טראנק של VLAN, אז כדי למקם אותם ב-EPG, תצטרכו להצביע על יציאת המתג ועל ה-VLAN המשמשים בה. כפי שאתה יכול לראות, רשתות VLAN מופיעות במקום שאינך יכול להסתדר בלעדיהם.

אם השרתים הם מכונות וירטואליות, אז מספיק להתייחס לסביבת הוירטואליזציה המחוברת, ואז הכל יקרה מעצמו: תיווצר קבוצת יציאות (במונחים של VMWare) לחיבור ה-VM, ה-VLANs או VXLANs הדרושים יוקצו, הם יירשמו ביציאות המתג הדרושות וכו'. לכן, למרות ש-ACI בנויה סביב רשת פיזית, חיבורים לשרתים וירטואליים נראים הרבה יותר פשוטים מאשר לשרתים פיזיים. ל-ACI כבר יש קישוריות מובנית עם VMWare ו-MS Hyper-V, כמו גם תמיכה ב-OpenStack ו-RedHat Virtualization. מנקודה כלשהי ואילך הופיעה גם תמיכה מובנית בפלטפורמות קונטיינר: Kubernetes, OpenShift, Cloud Foundry, בעוד שזה נוגע הן ליישום מדיניות והן לניטור, כלומר, מנהל הרשת יכול לראות מיד על אילו מארחים על אילו פודים עובדים לאילו קבוצות הם נופלים.

בנוסף להיכלל בקבוצת פורטים מסוימת, לשרתים וירטואליים יש מאפיינים נוספים: שם, תכונות וכו', שיכולים לשמש כקריטריונים להעברתם לקבוצה אחרת, למשל, כאשר משנים את שמו של VM או מופיעה תג נוסף ב- זה. סיסקו קוראת לזה קבוצות מיקרו-פילוח, אם כי, בגדול, העיצוב עצמו עם היכולת ליצור מקטעי אבטחה רבים בצורה של EPGs באותה תת-רשת הוא גם די מיקרו-פילוח. ובכן, המוכר יודע טוב יותר.

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

באופן כללי, היגיון הבקרה ב-ACI אינו דומה כלל למה שאתה פוגשים בדרך כלל
ברשתות מסורתיות מאותה סיסקו: ממשק התוכנה הוא ראשי, וה-GUI או ה-CLI הם משניים, מכיוון שהם עובדים דרך אותו API. לכן, כמעט כל מי שמעורב ב-ACI, לאחר זמן מה, מתחיל לנווט במודל האובייקטים המשמש לניהול ולהפוך משהו לאוטומטי שיתאים לצרכים שלהם. הדרך הקלה ביותר לעשות זאת היא מ-Python: יש כלים מוכנים נוחים לכך.

הבטיח מגרפה

הבעיה העיקרית היא שהרבה דברים ב-ACI נעשים אחרת. כדי להתחיל לעבוד עם זה כרגיל, אתה צריך להתאמן מחדש. זה נכון במיוחד עבור צוותי תפעול רשת בלקוחות גדולים, שבהם מהנדסים "רושמים VLAN" במשך שנים לפי דרישה. העובדה שעכשיו רשתות VLAN אינן עוד רשתות VLAN, ואתה לא צריך ליצור רשתות VLAN ביד כדי להקים רשתות חדשות במארחים וירטואליים, מעיפה לחלוטין את הגג של אנשי רשת מסורתיים וגורמת להם להיאחז בגישות מוכרות. יש לציין שסיסקו ניסתה להמתיק מעט את הגלולה והוסיפה לבקר CLI "כמו NXOS", המאפשר לבצע קונפיגורציה מממשק דומה למתגים מסורתיים. אבל עדיין, כדי להתחיל להשתמש ב-ACI כרגיל, אתה צריך להבין איך זה עובד.

מבחינת המחיר, בקנה מידה גדול ובינוני, רשתות ACI למעשה אינן שונות מרשתות מסורתיות על ציוד של סיסקו, שכן אותם מתגים משמשים לבנייתן (Nexus 9000 יכול לעבוד ב-ACI ובמצב מסורתי והפכו כעת לעיקרי "סוס עבודה" לפרויקטים חדשים של מרכז נתונים). אבל עבור מרכזי נתונים של שני מתגים, הנוכחות של בקרים וארכיטקטורת Spine-Leaf, כמובן, מורגשת. לאחרונה הופיע מפעל Mini ACI, בו שניים משלושת הבקרים מוחלפים במכונות וירטואליות. זה מקטין את ההבדל בעלויות, אבל זה עדיין נשאר. אז עבור הלקוח, הבחירה מוכתבת על ידי כמה הוא מעוניין בתכונות אבטחה, אינטגרציה עם וירטואליזציה, נקודת שליטה אחת וכו'.

מקור: www.habr.com