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

אם אינך בקי בהקמת רשתות מרכזי נתונים, אז אני ממליץ בחום להתחיל עם מאמרים עליהם.

כל הנושאים:

• 0. ADSM. חלק אפס. תִכנוּן
• 1. ADSM. חלק ראשון (שאחרי אפס). וירטואליזציה של רשת
• 2. ADSM. חלק שני. עיצוב רשת

השיטות המתוארות בסדרה זו צריכות להיות ישימות על כל סוג של רשת, בכל גודל, עם כל מגוון של ספקים (לא). עם זאת, אי אפשר לתאר דוגמה אוניברסלית ליישום גישות אלו. לכן, אתמקד בארכיטקטורה המודרנית של רשת DC: מפעל קלוז.
אנו נעשה DCI על MPLS L3VPN.

רשת Overlay פועלת על גבי הרשת הפיזית מהמארח (זה יכול להיות VXLAN או Tungsten Fabric של OpenStack או כל דבר אחר שדורש רק קישוריות IP בסיסית מהרשת).

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

נבחר DC כדורי בוואקום:

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

תוכן

• טופולוגיה פיזיקלית
• ניתוב
• תוכנית IP
• לאבה
• מסקנה
• קישורים שימושיים

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

בערים מגה זה פופולרי מאוד, אז אתה צריך הרבה מכונות פיזיות.

ראשית, אתאר את הרשת בערך כפי שהייתי רוצה שתהיה. ואז אני אפשט את זה עבור המעבדה.

טופולוגיה פיזיקלית

מיקומים

ל-LAN_DC יהיו 6 DCs:

• רוסיה (RU):
  • מוסקבה (msk)
  • קאזאן (kzn)

• ספרד (SP):
  • ברצלונה (BCN)
  • מלאגה (Mlg)

• סין (CN):
  • שנחאי (שא)
  • שיאן (SIA)

Inside DC (Intra-DC)

לכל ה-DC יש רשתות קישוריות פנימיות זהות המבוססות על טופולוגיית Clos.
איזה סוג של רשתות Clos הן ולמה הן בנפרד статье.

לכל DC יש 10 מתלים עם מכונות, הם ימוספרו כ A, B, C וכן הלאה.

בכל מתלה יש 30 מכונות. הם לא יעניינו אותנו.

כמו כן בכל מתלה יש מתג אליו מחוברות כל המכונות - זהו מתג החלק העליון של ה-Rack - ToR או אחרת, במונחים של מפעל Clos, נקרא לזה עלה.

תרשים כללי של המפעל.

אנחנו נתקשר אליהם XXX-עלהYאיפה XXX - קיצור בן שלוש אותיות DC, ו Y - מספר סידורי. לדוגמה, kzn-leaf11.

במאמרי ארשה לעצמי להשתמש במונחים Leaf ו-ToR בצורה קלת דעת כמילים נרדפות. עם זאת, עלינו לזכור שלא כך הדבר.
ToR הוא מתג המותקן במתלה שאליו מחוברות מכונות.
עלה הוא התפקיד של מכשיר ברשת פיזית או מתג ברמה ראשונה במונחים של טופולוגיית Cloes.
כלומר, Leaf != ToR.
אז Leaf יכול להיות מתג EndofRaw, למשל.
עם זאת, במסגרת מאמר זה עדיין נתייחס אליהם כמילים נרדפות.

כל מתג ToR מחובר בתורו לארבעה מתגי צבירה ברמה גבוהה יותר - עַמוּד הַשִׁדרָה. מתלה אחד ב-DC מוקצה עבור Spines. נקרא לזה בצורה דומה: XXX-עַמוּד הַשִׁדרָהY.

אותו מתלה יכיל ציוד רשת לקישוריות בין הנתבים DC - 2 עם MPLS על הסיפון. אבל בגדול, אלו הם אותם ה-ToRs. כלומר, מנקודת המבט של מתגי עמוד השדרה, ה-ToR הרגיל עם מכונות מחוברות או נתב ל-DCI לא משנה בכלל - רק העברה.

ToRs מיוחדים כאלה נקראים עלה-קצה. אנחנו נתקשר אליהם XXX-קָצֶהY.

זה ייראה כך.

בתרשים למעלה, למעשה הנחתי קצה ועלה באותה רמה. רשתות תלת שכבתיות קלאסיות הם לימדו אותנו להתייחס ל-uplinking (מכאן מגיע המונח) כ-uplinks. וכאן מתברר שה-DCI "uplink" יורד בחזרה, מה שעבור חלקם מעט שובר את ההיגיון הרגיל. במקרה של רשתות גדולות, כאשר מרכזי נתונים מחולקים ליחידות קטנות עוד יותר - PODשל (נקודת מסירה), הדגש יחיד Edge-PODזה עבור DCI וגישה לרשתות חיצוניות.

כדי להקל על התפיסה בעתיד, אני עדיין אצייר Edge over Spine, בעוד שנזכור שאין אינטליגנציה על Spine ואין הבדלים בעבודה עם Leaf ו-Edge-leaf רגילים (אם כי עשויים להיות כאן ניואנסים , אבל באופן כללי זה נכון).

תוכנית של מפעל עם עלי אדג'.

השילוש של Leaf, Spine ו-Edge יוצרים רשת או מפעל תחתון.

המשימה של מפעל רשת (קרא Underlay), כפי שכבר הגדרנו ב גיליון אחרון, מאוד מאוד פשוט - לספק קישוריות IP בין מכונות הן בתוך אותו DC והן ביניהן.
לכן הרשת נקראת מפעל, בדיוק כמו, למשל, מפעל מיתוג בתוך קופסאות רשת מודולריות, עליהן תוכלו לקרוא עוד ב SDSM14.

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

המפעל הוא לחלוטין L3. אין VLAN, אין שידור - יש לנו מתכנתים כל כך נפלאים ב-LAN_DC, הם יודעים לכתוב אפליקציות שחיות בפרדיגמת L3, ומכונות וירטואליות לא דורשות Live Migration עם שימור כתובת ה-IP.

ושוב: התשובה לשאלה למה המפעל ולמה L3 נמצא בנפרד статье.

DCI - חיבור מרכז נתונים (Inter-DC)

DCI יאורגן באמצעות Edge-Leaf, כלומר, הם נקודת היציאה שלנו לכביש המהיר.
לשם הפשטות, אנו מניחים שה-DCs מחוברים זה לזה על ידי קישורים ישירים.
הבה נוציא בחשבון קישוריות חיצונית.

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

ב-Edge-Leafs, ה-underlay ממוקם ב-VPN ומועבר דרך עמוד השדרה של MPLS (אותו קישור ישיר).

זהו הדיאגרמה ברמה העליונה שאנו מקבלים.

ניתוב

לניתוב בתוך ה-DC נשתמש ב-BGP.
על תא המטען של MPLS OSPF+LDP.
עבור DCI, כלומר, ארגון קישוריות במחתרת - BGP L3VPN על MPLS.

ערכת ניתוב כללית

אין OSPF או ISIS (פרוטוקול ניתוב אסור בפדרציה הרוסית) במפעל.

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

ערכת ניתוב BGP בתוך DC

למה BGP?

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

ויש גם סעיף שלם במאמר שלי המוקדש לכך. לאן אני לוקח אותך ו אני שולח.

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

בנוסף, שימוש ב-BGP בכל מקום יאפשר לכם לא לבזבז זמן על תמיכה במספר פרוטוקולים שונים וסנכרון ביניהם.

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

מדיניות ניתוב

במתגי Leaf, אנו מייבאים קידומות ממשקי רשת Underlay לתוך BGP.
נערוך מפגש BGP בין כל זוג Leaf-Spine, שבו קידומות ה-Underlay הללו יוכרזו דרך הרשת פה ושם.

בתוך מרכז נתונים אחד, נפיץ את המפרטים שייבאנו ל-ToRe. ב-Edge-Leafs נצבור אותם ונכריז עליהם ל-DCs מרוחקים ונשלח אותם למטה ל-TORs. כלומר, כל ToR יידע בדיוק איך להגיע ל-ToR אחר באותו DC והיכן נקודת הכניסה היא להגיע ל-ToR ב-DC אחר.

ב-DCI, המסלולים ישודרו כ-VPNv4. לשם כך, ב-Edge-Leaf, הממשק כלפי המפעל ימוקם ב-VRF, נקרא לזה UNDERLAY, והשכונה עם Spine on Edge-Leaf תקום בתוך ה-VRF, ובין Edge-Leafs ב-VPNv4- מִשׁפָּחָה.

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

ב-Leaf and Spine לא נייבא Loopbacks. אנחנו צריכים אותם רק כדי לקבוע את מזהה הנתב.

אבל ב-Edge-Leafs אנחנו מייבאים אותו ל-Global BGP. בין כתובות Loopback, Edge-Leafs תקים סשן BGP במשפחת IPv4 VPN זה עם זה.

יהיה לנו עמוד שדרה OSPF+LDP בין מכשירי EDGE. הכל נמצא באזור אחד. תצורה פשוטה במיוחד.

זו התמונה עם ניתוב.

BGP ASN

Edge-Leaf ASN

ב-Edge-Leafs יהיה ASN אחד בכל ה-DCs. חשוב שיהיה iBGP בין Edge-Leafs, ואנחנו לא נתפס לניואנסים של eBGP. תן לזה להיות 65535. במציאות, זה יכול להיות המספר של AS ציבורי.

עמוד השדרה ASN

בעמוד השדרה יהיה לנו ASN אחד לכל DC. נתחיל כאן עם המספר הראשון מטווח ה-AS הפרטי - 64512, 64513 וכן הלאה.

למה ASN ב-DC?

בואו נחלק את השאלה הזו לשניים:

• מדוע ה-ASN זהים בכל קוצים של DC אחד?
• מדוע הם שונים ב-DCs שונים?

מדוע אותם ASNs נמצאים בכל קוצים של DC אחד?

כך ייראה ה-AS-Path של מסלול ה-underlay ב-Edge-Leaf:
[leafX_ASN, spine_ASN, edge_ASN]
כאשר תנסה לפרסם אותו בחזרה ל-Spine, הוא ימחק אותו כי ה-AS שלו (Spine_AS) כבר נמצא ברשימה.

עם זאת, בתוך ה-DC אנו מרוצים לחלוטין שמסלולי ה- Underlay שעולים ל-Edge לא יוכלו לרדת. כל התקשורת בין מארחים בתוך ה-DC חייבת להתרחש ברמת עמוד השדרה.

במקרה זה, המסלולים המצטברים של DCs אחרים בכל מקרה יגיעו בקלות ל-ToRs - ל-AS-Path שלהם יהיה רק ​​ASN 65535 - מספר AS Edge-Leafs, כי שם הם נוצרו.

מדוע הם שונים ב-DCs שונים?

תיאורטית, ייתכן שנצטרך לגרור את Loopback וכמה מכונות וירטואליות שירות בין DCs.

לדוגמה, על המארח נריץ Route Reflector או אותו VNGW (שער רשת וירטואלי), שיינעל עם TopR דרך BGP ויכריז על ה-loopback שלו, שאמור להיות נגיש מכל ה-DCs.

אז כך ייראה ה-AS-Path שלו:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

ולא צריך להיות ASN כפולים בשום מקום.

כלומר, Spine_DC1 ו-Spe_DC2 חייבים להיות שונים, בדיוק כמו leafX_DC1 ו-leafY_DC2, וזה בדיוק מה שאנחנו מתקרבים אליו.

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

ואם תהיה לנו אפשרות לא להשתמש בדברים מסוכנים, ננצל אותה.

עלה ASN

יהיה לנו ASN בודד על כל מתג Leaf ברחבי הרשת.
אנו עושים זאת מהסיבות שצוינו לעיל: AS-Path ללא לולאות, תצורת BGP ללא סימניות.

כדי שמסלולים בין ליפס יעברו בצורה חלקה, ה-AS-Path צריך להיראות כך:
[leafX_ASN, spine_ASN, leafY_ASN]
כאשר leafX_ASN ו-leafY_ASN יהיו נחמדים להיות שונים.

זה נדרש גם למצב עם הכרזה על לולאה VNF בין DCs:
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

אנו נשתמש ב-ASN של 4 בתים וניצור אותו על סמך ה-ASN של השדרה ומספר מתג העלה, כלומר כך: Spine_ASN.0000X.

זו התמונה עם ASN.

תוכנית IP

ביסודו של דבר, עלינו להקצות כתובות לחיבורים הבאים:

1. תחתית כתובות רשת בין ToR למכונה. הם חייבים להיות ייחודיים בתוך הרשת כולה, כך שכל מכונה תוכל לתקשר עם כל מכונה אחרת. התאמה מצוינת 10/8. לכל מתלה יש /26 עם רזרבה. אנו נקצה /19 לכל DC ו /17 לכל אזור.
2. קישור כתובות בין Leaf/Tor ו-Spine.

   אני רוצה להקצות אותם בצורה אלגוריתמית, כלומר לחשב אותם משמות המכשירים שצריך לחבר.

   שיהיה... 169.254.0.0/16.
   כלומר 169.254.00X.Y/31איפה X - מספר עמוד השדרה, Y — רשת P2P /31.
   זה יאפשר לך להפעיל עד 128 מתלים, ועד 10 קוצים ב-DC. כתובות קישור יכולות (ויחזרו) לחזור מ-DC ל-DC.

3. אנו מארגנים את צומת Spine-Edge-Leaf ברשתות משנה 169.254.10X.Y/31, איפה בדיוק אותו הדבר X - מספר עמוד השדרה, Y — רשת P2P /31.
4. קישור כתובות מ-Edge-Leaf לשדרת MPLS. כאן המצב שונה במקצת - המקום שבו כל החלקים מחוברים לעוגה אחת, כך ששימוש חוזר באותן כתובות לא יעבוד - אתה צריך לבחור את רשת המשנה הפנוי הבאה. לכן, בואו ניקח כבסיס 192.168.0.0/16 ואנחנו נגרוף ממנו את הפנויים.
5. כתובות Loopback. אנחנו ניתן את כל הטווח עבורם 172.16.0.0/12.
   • עלה - /25 לכל DC - אותם 128 מתלים. אנו נקצה /23 לכל אזור.
   • עמוד שדרה - /28 לכל DC - עד 16 עמוד שדרה. בואו נקצה /26 לכל אזור.
   • Edge-Leaf - /29 לכל DC - עד 8 קופסאות. בואו נקצה /27 לכל אזור.

אם אין לנו מספיק טווחים מוקצים ב-DC (ולא יהיו כאלה - אנחנו טוענים שהם היפר-scalers), אנחנו פשוט בוחרים את הבלוק הבא.

זו התמונה עם כתובת IP.

לולאות חוזרות:

קידומת
תפקיד המכשיר
אזור
זֶרֶם יָשָׁר

172.16.0.0/23
קצה
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
msk

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
BCN

172.16.0.40/29
Mlg

172.16.0.64/27
cn
 

172.16.0.64/29
שא

172.16.0.72/29
SIA

172.16.2.0/23
עמוד השדרה
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
msk

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
BCN

172.16.2.80/28
Mlg

172.16.2.128/26
cn
 

172.16.2.128/28
שא

172.16.2.144/28
SIA

172.16.8.0/21
עלה
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
msk

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
BCN

172.16.10.128/25
Mlg

172.16.12.0/23
cn
 

172.16.12.0/25
שא

172.16.12.128/25
SIA

רוֹבֶד תַחְתוֹן:

קידומת
אזור
זֶרֶם יָשָׁר

10.0.0.0/17
ru
 

10.0.0.0/19
msk

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
BCN

10.0.160.0/19
Mlg

10.1.0.0/17
cn
 

10.1.0.0/19
שא

10.1.32.0/19
SIA

לאבה

שני ספקים. רשת אחת. ADSM.

ג'וניפר + אריסטה. אובונטו. איב הישנה והטובה.

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

שני מרכזי נתונים: קאזאן וברצלונה.

• שני קוצים כל אחד: ג'וניפר ואריסטה.
• טורוס אחד (Leaf) בכל אחד - ג'וניפר ואריסטה, עם מארח אחד מחובר (בוא ניקח עבור זה Cisco IOL קל משקל).
• צומת Edge-Leaf אחד כל אחד (בינתיים רק Juniper).
• מתג אחד של סיסקו ישלוט בכולם.
• בנוסף לתיבות הרשת פועלת מכונת בקרה וירטואלית. מפעיל את אובונטו.
  יש לו גישה לכל המכשירים, הוא יריץ מערכות IPAM/DCIM, חבורה של סקריפטים של Python, Ansible וכל דבר אחר שנצטרך.

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

מסקנה

האם גם זה מקובל? האם עלי לכתוב מסקנה קצרה מתחת לכל מאמר?

אז בחרנו תלת מפלסים רשת Kloz בתוך DC, מכיוון שאנו מצפים להרבה תנועה מזרח-מערבית ורוצים ECMP.

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

בחרנו ב-BGP כפרוטוקול הניתוב עבור רשתות רשת בשל מדרגיותו וגמישות המדיניות שלו.

יהיו לנו צמתים נפרדים לארגון DCI - Edge-leaf.
לעמוד השדרה יהיה OSPF+LDP.
DCI מיושם על בסיס MPLS L3VPN.
עבור קישורי P2P, נחשב כתובות IP באופן אלגוריתמי על סמך שמות מכשירים.
אנו נקצה לולאות לפי תפקידם של המכשירים ומיקומם ברצף.
קידומות תחתית - רק במתגי Leaf ברצף על סמך מיקומם.

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

במאמר הבא נעסוק ב-Netbox - מערכת מלאי וניהול למרחב IP ב-DC.

תודה

• Andrey Glazkov aka @glazgoo להגהה ותיקונים
• Alexander Klimenko aka @v00lk להגהה ועריכה
• ארטיום צ'רנוביי עבור KDPV

מקור: www.habr.com