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

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

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

תוכן

1. מטרות
   1. הרשת היא כמו אורגניזם בודד
   2. בדיקת תצורה
   3. גירסאות
   4. ניטור וריפוי עצמי של שירותים

2. אומר
   1. מערכת המלאי
   2. מערכת ניהול שטחי IP
   3. מערכת תיאור שירות רשת
   4. מנגנון אתחול המכשיר
   5. מודל תצורה של ספק-אגנוסטי
   6. ממשק מנהל התקן ספציפי לספק
   7. מנגנון להעברת תצורה למכשיר
   8. CI / CD
   9. מנגנון גיבוי וחיפוש סטיות
   10. מערכת פיקוח

3. מסקנה

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

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

בהתחלה הייתי צריך לכתוב מאמרים על רשתות בעצמי בגלל העובדה שהם לא היו ב-RuNet.

כעת לא הצלחתי למצוא מסמך מקיף שיבצע שיטתיות של גישות לאוטומציה וינתח את הטכנולוגיות הנ"ל תוך שימוש בדוגמאות מעשיות פשוטות.

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

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

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

ל-LAN DC יש 4 DCs, כ-250 מתגים, חצי תריסר נתבים וכמה חומות אש.
לא פייסבוק, אבל מספיק כדי לגרום לך לחשוב לעומק על אוטומציה.
עם זאת, יש דעה שאם יש לך יותר ממכשיר אחד, כבר יש צורך באוטומציה.
למעשה, קשה לדמיין שכל אחד יכול לחיות עכשיו בלי לפחות חבילה של תסריטי ברכיים.
למרות ששמעתי שיש משרדים שבהם כתובות IP נשמרות באקסל, וכל אחד מאלפי התקני הרשת מוגדר באופן ידני ובעל תצורה ייחודית משלו. זה, כמובן, יכול להיחשב לאמנות מודרנית, אבל רגשותיו של המהנדס בהחלט ייפגעו.

מטרות

כעת נגדיר את המטרות המופשטות ביותר:

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

בהמשך מאמר זה נבחן באילו אמצעים נשתמש, ובהמשך נבחן את המטרות והאמצעים בפירוט.

הרשת היא כמו אורגניזם בודד

הביטוי המגדיר של הסדרה, למרות שבמבט ראשון זה אולי לא נראה כל כך משמעותי: אנו נגדיר את הרשת, לא מכשירים בודדים.
בשנים האחרונות אנו רואים שינוי בדגש על התייחסות לרשת כאל ישות אחת, ומכאן תוכנה מוגדרת ברשת, רשתות מונעות כוונות и רשתות אוטונומיות.
אחרי הכל, מה צריך אפליקציות באופן גלובלי מהרשת: קישוריות בין נקודות A ו-B (טוב, לפעמים +B-Z) ובידוד מיישומים ומשתמשים אחרים.

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

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

1. ראשית אנו מתעדים שינויים במערכות
2. יצירת תצורת היעד של כל התקני הרשת
3. אנו משיקים את תוכנית עדכון תצורת הרשת, אשר מחשבת מה צריך להסיר בכל צומת, מה להוסיף, ומביאה את הצמתים למצב הרצוי.

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

בדיקת תצורה

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

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

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

ברגע שאתה מתרגל לרעיון של רשת CI/CD, בין לילה השיטה של ​​בדיקת תצורה על ידי החלתה על רשת ייצור תיראה כמו בורות של ימי הביניים המוקדמים. קצת כמו להכות בראש נפץ עם פטיש.

המשך אורגני של רעיונות על המערכת ניהול רשת ו-CI/CD הופכים לגרסה מלאה של התצורה.

גירסאות

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

נניח שהגרסה הנוכחית היא 1.0.0.
האם כתובת ה-IP של ממשק Loopback באחד מה-ToRs השתנתה? זוהי גרסה מינורית ותמוספר 1.0.1.
תיקנו את המדיניות לייבוא ​​מסלולים ל-BGP - קצת יותר ברצינות - כבר 1.1.0
החלטנו להיפטר מ-IGP ולעבור ל-BGP בלבד – זה כבר שינוי עיצובי קיצוני – 2.0.0.

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

על גרסאות סמנטיות נדבר במאמר נפרד.

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

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

ניטור וריפוי עצמי של שירותים

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

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

מה נצטרך כדי ליישם תוכניות שאפתניות שכאלה?

• יש רשימה של כל המכשירים ברשת, מיקומם, תפקידים, דגמים, גרסאות תוכנה.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• יש מערכת לתיאור שירותי רשת.
  IGP, BGP, L2/3VPN, מדיניות, ACL, NTP, SSH.
• להיות מסוגל לאתחל את המכשיר.
  שם מארח, Mgmt IP, Mgmt Route, משתמשים, RSA-Keys, LLDP, NETCONF
• הגדר את המכשיר והבא את התצורה לגרסה הרצויה (כולל ישנה).
• בדיקת תצורה
• בדוק מעת לעת את המצב של כל המכשירים עבור חריגות מהנוכחיים ודווח למי זה צריך להיות.
  בן לילה, מישהו הוסיף בשקט כלל ל-ACL.
• מעקב אחר ביצועים.

אומר

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

ויהיו עשרה מהם:

1. מערכת המלאי
2. מערכת ניהול שטחי IP
3. מערכת תיאור שירות רשת
4. מנגנון אתחול המכשיר
5. מודל תצורה של ספק-אגנוסטי
6. ממשק מנהל התקן ספציפי לספק
7. מנגנון להעברת תצורה למכשיר
8. CI / CD
9. מנגנון גיבוי וחיפוש סטיות
10. מערכת פיקוח

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

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

רכיב 1: מערכת מלאי

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

למטרותינו, נאחסן בו את המידע הבא על המכשיר:

• מספר מלאי
• כותרת/תיאור
• דגם (Huawei CE12800, Juniper QFX5120 וכו'.)
• פרמטרים אופייניים (לוחות, ממשקים וכו'.)
• תפקיד (עלה, עמוד שדרה, נתב גבול וכו'.)
• מקום (אזור, עיר, מרכז נתונים, מתלה, יחידה)
• חיבורים בין מכשירים
• טופולוגיית רשת

ברור לחלוטין שאנחנו בעצמנו רוצים לדעת את כל זה.
אבל האם זה יעזור למטרות אוטומציה?
בְּלִי סָפֵק.
לדוגמה, אנו יודעים שבמרכז נתונים נתון על מתגי Leaf, אם זה Huawei, יש להחיל ACLs לסינון תעבורה מסוימת על ה-VLAN, ואם זה Juniper, אז על יחידה 0 של הממשק הפיזי.
או שאתה צריך להפעיל שרת Syslog חדש לכל הגבולות באזור.

בו נאחסן התקני רשת וירטואליים, למשל נתבים וירטואליים או מחזירי שורש. אנחנו יכולים להוסיף שרתי DNS, NTP, Syslog ובכלל כל מה שקשור בצורה כזו או אחרת לרשת.

רכיב 2: מערכת ניהול שטחי IP

כן, וכיום יש צוותים של אנשים שעוקבים אחר קידומות וכתובות IP בקובץ אקסל. אבל הגישה המודרנית היא עדיין מסד נתונים, עם חזית קצה ב-nginx/apache, API ופונקציות נרחבות להקלטת כתובות IP ורשתות מחולקות ל-VRFs.
IPAM - ניהול כתובות IP.

למטרותינו, נאחסן בו את המידע הבא:

• VLAN
• VRF
• רשתות/רשתות משנה
• כתובות IP
• קשירת כתובות למכשירים, רשתות למיקומים ומספרי VLAN

שוב, ברור שאנו רוצים לוודא שכאשר אנו מקצים כתובת IP חדשה עבור הלולאה של ה-ToR, לא נתקל בעובדה שהיא כבר הוקצתה למישהו. או שהשתמשנו באותה קידומת פעמיים בקצוות שונים של הרשת.
אבל איך זה עוזר לאוטומציה?
קל
אנו מבקשים קידומת במערכת עם תפקיד Loopbacks, המכילה כתובות IP זמינות להקצאה - אם היא נמצאה, אנו מקצים את הכתובת, אם לא, אנו מבקשים יצירת קידומת חדשה.
או בעת יצירת תצורת מכשיר, נוכל לברר מאותה מערכת באיזו VRF הממשק צריך להיות ממוקם.
וכאשר מפעילים שרת חדש, הסקריפט נכנס למערכת, מגלה באיזה מתג נמצא השרת, באיזו יציאה ואיזו רשת משנה מוקצים לממשק - ויקצה ממנו את כתובת השרת.

הדבר מעיד על רצון לשלב בין DCIM ו-IPAM למערכת אחת כדי לא לשכפל פונקציות ולא לשרת שתי ישויות דומות.
זה מה שנעשה.

רכיב 3. מערכת לתיאור שירותי רשת

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

• תַשׁתִית
• לָקוּחַ.

הראשונים נועדו לספק קישוריות בסיסית ושליטה במכשיר. אלה כוללים VTY, SNMP, NTP, Syslog, AAA, פרוטוקולי ניתוב, CoPP וכו'.
האחרונים מארגנים את השירות עבור הלקוח: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP וכו'.
כמובן שיש גם מקרים גבוליים - איפה לכלול MPLS LDP, BGP? כן, וניתן להשתמש בפרוטוקולי ניתוב עבור לקוחות. אבל זה לא חשוב.

שני סוגי השירותים מפורקים לפרימיטיבים של תצורה:

• ממשקים פיזיים ולוגיים (תג/anteg, mtu)
• כתובות IP ו-VRF (IP, IPv6, VRF)
• ACLs ומדיניות עיבוד תעבורה
• פרוטוקולים (IGP, BGP, MPLS)
• מדיניות ניתוב (רשימות קידומות, קהילות, מסנני ASN).
• שירותי שירות (SSH, NTP, LLDP, Syslog...)
• וכו.

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

אם קצת יותר קרוב לחיים, אז נוכל לתאר את זה
למתג Leaf חייב להיות הפעלות BGP עם כל מתגי עמוד השדרה המחוברים, לייבא רשתות מחוברות לתהליך ולקבל רק רשתות מקידומת מסוימת ממתגי עמוד השדרה. הגבל את CoPP IPv6 ND ל-10 עמודים וכו'.
בתורו, עמוד השדרה מקיים מפגשים עם כל הלידים המחוברים, הפועלים כמחזירי שורש, ומקבלים מהם רק מסלולים באורך מסוים ועם קהילה מסוימת.

רכיב 4: מנגנון אתחול המכשיר

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

1. הכנס את המכשיר למערכת המלאי.
2. בחר כתובת IP לניהול.
3. הגדר גישה בסיסית אליו:
   שם מארח, כתובת IP לניהול, נתיב לרשת הניהול, משתמשים, מפתחות SSH, פרוטוקולים - telnet/SSH/NETCONF

ישנן שלוש גישות:

• הכל ידני לחלוטין. המכשיר מובא למעמד, שם אדם אורגני רגיל יכניס אותו למערכות, יתחבר לקונסולה ויגדיר אותה. יכול לעבוד על רשתות סטטיות קטנות.
• ZTP - Zero Touch Provisioning. החומרה הגיעה, קמה, קיבלה כתובת דרך DHCP, הלכה לשרת מיוחד והגדירה את עצמה.
• התשתית של שרתי המסוף, כאשר התצורה הראשונית מתרחשת דרך יציאת המסוף במצב אוטומטי.

על שלושתם נדבר במאמר נפרד.

רכיב 5: מודל תצורה אגנוסטית של ספקים

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

1. אל תסתגל לממשק ספציפי לאינטראקציה עם המכשיר. יהיה זה CLI, NETCONF, RESTCONF, SNMP - הדגם יהיה זהה.
2. אין לשמור את מספר התבניות/סקריפטים לפי מספר הספקים ברשת, ואם העיצוב משתנה יש לשנות את אותו הדבר בכמה מקומות.
3. טען את התצורה מהמכשיר (גיבוי), הכניסו אותה בדיוק לאותו דגם והשוו ישירות את תצורת היעד לזו הקיימת כדי לחשב את הדלתא ולהכין תיקון תצורה שישנה רק את החלקים הנחוצים או לזיהוי סטיות.

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

רכיב 6. ממשק דרייבר ספציפי לספק

אתה לא צריך להחמיא לעצמך בתקווה שיום אחד אפשר יהיה להגדיר ciska בדיוק באותו אופן כמו ג'וניפר, פשוט על ידי שליחת בדיוק אותן שיחות אליהם. למרות הפופולריות ההולכת וגוברת של Whiteboxes והופעת התמיכה ב-NETCONF, RESTCONF, OpenConfig, התוכן הספציפי שהפרוטוקולים הללו מספקים שונה מספק לספק, וזה אחד ההבדלים התחרותיים שלהם שהם לא יוותרו עליו כל כך בקלות.
זה בערך כמו OpenContrail ו-OpenStack, שיש להם RestAPI כממשק NorthBound שלהם, מצפים לקריאות שונות לחלוטין.

אז, בשלב החמישי, המודל הבלתי תלוי בספק חייב לקבל את הצורה שבה הוא יעבור לחומרה.
וכאן כל האמצעים טובים (לא): CLI, NETCONF, RESTCONF, SNMP פשוט.

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

רכיב 7. מנגנון להעברת תצורה למכשיר

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

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (למרות שזה חריג כי זו דרך לספק FIB, לא הגדרות)

בואו ננקד את ה-t כאן. CLI הוא מורשת. SNMP... שיעול שיעול.
RESTCONF היא עדיין חיה לא ידועה; ה- REST API נתמך כמעט על ידי איש. לכן, נתמקד ב-NETCONF בסדרה.

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

שנית, ואיזה כלים נעשה זאת?
יש כאן גם מבחר גדול:

• תסריט או פלטפורמה בכתב עצמי. בואו נתחמש את עצמנו ב-ncclient ו-asyncIO ונעשה הכל בעצמנו. מה עולה לנו לבנות מערכת פריסה מאפס?
• Ansible עם הספרייה העשירה של מודולי רשת.
• מלח עם עבודתו הדלה עם הרשת והחיבור עם נפאלם.
• בעצם נפאלם, שמכירה כמה ספקים וזהו, להתראות.
• נורניר היא חיה נוספת שננתח בעתיד.

כאן עדיין לא נבחר המועדף - נחפש.

מה עוד חשוב כאן? ההשלכות של יישום התצורה.
מוצלח או לא. האם יש עדיין גישה לחומרה או לא?
נראה ש-commit יעזור כאן באישור ואימות של מה שהורד למכשיר.
זה, בשילוב עם יישום נכון של NETCONF, מצמצם משמעותית את מגוון המכשירים המתאימים - לא הרבה יצרנים תומכים ב-commits רגילים. אבל זה רק אחד מהתנאים המוקדמים ב RFP. בסופו של דבר, אף אחד לא מודאג שאף ספק רוסי אחד לא יעמוד בתנאי הממשק 32*100GE. או שהוא מודאג?

רכיב 8. CI/CD

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

אבל, כפי שכבר נאמר למעלה, אנחנו לא סוג של ברברים שרוצים לגלגל הכל ישר לייצור.
התצורה שנוצרה חייבת לעבור תחילה דרך Pipeline CI/CD.

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

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

למעט פקודות איתור באגים, כל השינויים ברשת חייבים לעבור דרך CI/CD Pipeline - זוהי הערובה שלנו לחיים שקטים וקריירה ארוכה ומאושרת.

רכיב 9. מערכת גיבוי וזיהוי חריגות

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

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

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

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

רכיב 10. מערכת ניטור

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

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

נחשוב על כך במאמר נפרד.

מסקנה

כבסיס, בחרתי באחד מעיצובי רשת מרכזי הנתונים המודרניים - L3 Clos Fabric עם BGP כפרוטוקול הניתוב.
הפעם נבנה את הרשת על Juniper, כי עכשיו ממשק JunOs הוא vanlove.

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

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

וכן, אני לא מבטיח לסיים בחן את המחזור הזה עם פתרון מוכן. 🙂

קישורים שימושיים

• לפני שמתעמקים בסדרה, כדאי לקרוא את ספרה של נטשה סמוילנקו פייתון למהנדסי רשת. ואולי לעבור קורס.
• זה גם יהיה שימושי לקריאה RFC על עיצוב מפעלי מרכז הנתונים מפייסבוק מאת פיטר לאפוכוב.
• תיעוד הארכיטקטורה ייתן לך מושג על אופן הפעולה של Overlay SDN. בד טונגסטן (לשעבר Open Contrail).

תודה

הערוץ הרומאי. להערות ועריכות.
ארטיום צ'רנוביי. עבור KDPV.

מקור: www.habr.com