תשתית ממוקדת אפליקציות. ארכיטקטורת הרשת של העתיד - מהספקולציות לפעולה

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

אתה יכול ללמוד עוד על ארכיטקטורת הרשת החדשה בסנט פטרסבורג במאי 2019. כל הפרטים נמצאים קשר. הירשם!

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

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

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

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

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

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

1. רשת המבוססת על מתגי Nexus.
2. אשכול בקר APIC;
3. פרופילי יישומים;

בואו נסתכל על כל רמה ביתר פירוט – ונעבור מפשוט למורכב.

רשת המבוססת על מתגי Nexus
הרשת במפעל ACI דומה למודל ההיררכי המסורתי, אך היא הרבה יותר פשוטה לבנייה. מודל Leaf-Spine משמש לארגון הרשת, שהפכה לגישה מקובלת להטמעת רשתות הדור הבא. מודל זה מורכב משתי רמות: עמוד שדרה ועלה, בהתאמה.

רמת עמוד השדרה אחראית רק לביצועים. הביצועים הכוללים של מתגי עמוד השדרה שווים לביצועים של הבד כולו, ולכן יש להשתמש במתגים עם יציאות 40G ומעלה ברמה זו.
מתגי עמוד השדרה מתחברים לכל המתגים ברמה הבאה: מתגי עלה, אליהם מחוברים מארחים קצה. התפקיד העיקרי של מתגי Leaf הוא קיבולת יציאות.

לפיכך, בעיות קנה מידה נפתרות בקלות: אם אנחנו צריכים להגדיל את תפוקת הבד, אנחנו מוסיפים מתגי Spine, ואם אנחנו צריכים להגדיל את קיבולת היציאה, אנחנו מוסיפים Leaf.
עבור שתי הרמות, נעשה שימוש במתגים מסדרת Cisco Nexus 9000, אשר עבור Cisco הם הכלי העיקרי לבניית רשתות מרכזי נתונים, ללא קשר לארכיטקטורה שלהם. עבור שכבת השדרה, נעשה שימוש במתגי Nexus 9300 או Nexus 9500, ועבור Leaf רק Nexus 9300.
מגוון הדגמים של מתגי Nexus המשמשים במפעל ACI מוצג באיור למטה.

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

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

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

• נמל פיזי
• יציאה לוגית (קבוצת יציאות על מתג וירטואלי)
• מזהה VLAN או VXLAN
• כתובת IP או רשת משנה IP
• תכונות שרת (שם, מיקום, גרסת מערכת הפעלה וכו')

עבור האינטראקציה של EPGs שונים, מסופקת ישות הנקראת חוזים. החוזה מגדיר את מערכת היחסים בין ה-EPGs השונים. במילים אחרות, החוזה מגדיר איזה שירות EPG אחד מספק ל-EPG אחר. לדוגמה, אנו יוצרים חוזה המאפשר לתעבורה לזרום בפרוטוקול HTTPS. לאחר מכן, אנו מתחברים לחוזה זה, למשל, EPG Web (קבוצה של שרתי אינטרנט) ו-EPG App (קבוצה של שרתי יישומים), ולאחר מכן שתי קבוצות המסופים הללו יכולות להחליף תעבורה באמצעות פרוטוקול HTTPS.

האיור שלהלן מתאר דוגמה להגדרת תקשורת בין EPGs שונים באמצעות חוזים בתוך אותו ANP.

יכולים להיות כל מספר של פרופילי יישומים בתוך מפעל ACI. בנוסף, חוזים אינם קשורים לפרופיל יישום ספציפי; ניתן (וצריך) להשתמש בהם לחיבור EPGs ב-ANPs שונים.

למעשה, כל אפליקציה שדורשת רשת בצורה כזו או אחרת מתוארת בפרופיל משלה. לדוגמה, הדיאגרמה שלמעלה מציגה את הארכיטקטורה הסטנדרטית של אפליקציה תלת-שכבתית, המורכבת ממספר N של שרתי גישה חיצוניים (Web), שרתי יישומים (App) ושרתי DBMS (DB), וכן מתארת ​​את כללי האינטראקציה בין אוֹתָם. בתשתית רשת מסורתית, זו תהיה מערכת כללים שנכתבת על פני המכשירים השונים בתשתית. בארכיטקטורת ACI, אנו מתארים כללים אלה בתוך פרופיל יישום יחיד. ACI, באמצעות פרופיל אפליקציה, מקל בהרבה על יצירת מספר רב של הגדרות במכשירים שונים על ידי קיבוץ כולן לפרופיל יחיד.
התמונה למטה מציגה דוגמה מציאותית יותר. פרופיל יישום Microsoft Exchange עשוי ממספר EPGs וחוזים.

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

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

לפיכך, סיסקו מיישמת את הרעיון של רשת מרכזי נתונים מהדור הבא. רוצה לראות את זה בעצמך? בואו להפגנה תשתית ממוקדת אפליקציות בסנט פטרסבורג ולעבוד עם רשת מרכזי הנתונים של העתיד עכשיו.
ניתן להירשם לאירוע по ссылке.

מקור: www.habr.com