אוטומציה של רשת. מקרה מהחיים של האדם

היי הבר!

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

כתב ויתור

הכלים העיקריים שלנו לאוטומציה הם Ansible (ככלי אוטומציה) ו-Git (כמאגר עבור ספרי משחק של Ansible). אני רוצה להסתייג מיד שזה לא מאמר מבוא, שבו מדברים על ההיגיון של Ansible או Git, ומסבירים דברים בסיסיים (למשל, מה הם roletaskimodules, קבצי מלאי, משתנים ב-Ansible, או מה קורה כאשר אתה מזין את הפקודות git push או git commit). הסיפור הזה לא עוסק איך אתה יכול לתרגל את Ansible ולהגדיר NTP או SMTP בציוד שלך. זהו סיפור על איך אתה יכול לפתור במהירות ורצוי בעיה ברשת ללא שגיאות. כמו כן, מומלץ להבין היטב כיצד פועלת הרשת, בפרט מהי ערימת פרוטוקול TCP/IP, OSPF, BGP. אנחנו גם נוציא מהמשוואה את הבחירה של Ansible ו-Git. אם אתה עדיין צריך לבחור פתרון ספציפי, אנו ממליצים בחום לקרוא את הספר "תכנות רשת ואוטומציה. מיומנויות למהנדס הרשתות של הדור הבא" מאת ג'ייסון אדלמן, סקוט ס. לו ומאט אוסוולט.

עכשיו לעסקים.

הצהרת הבעיה

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

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

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

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

ג'קי צ'אן יכול לתאר היטב את המצב.

תודה לך, ג'קי.

מצב לא נעים במיוחד, נכון?

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

בואו נדון כיצד יתפתחו אירועים נוספים.

אנו מציעים את סדר הצגת החומר הבא

1. בואו נסתכל על דיאגרמת הרשת ונראה איך זה עובד;
2. נתאר כיצד אנו מעבירים הגדרות מנתב אחד לאחר באמצעות Ansible;
3. בואו נדבר על אוטומציה של תשתית ה-IT בכללותה.

דיאגרמת רשת ותיאור

ערכתי

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

יש לנו שתי משימות עיקריות להעברת תנועה:

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

נתחיל עם האלמנטים הבסיסיים:

1. שני נתבי גבול (BRD-01, BRD-02);
2. אשכול חומת אש (FW-CLUSTER);
3. מתג ליבה (L3-CORE);
4. נתב שיהפוך לחבל הצלה (כשנפתור את הבעיה נעביר את הגדרות הרשת מ-FW-CLUSTER ל-EMERGENCY) (EMERGENCY);
5. מתגים לניהול תשתית רשת (L2-MGMT);
6. מכונה וירטואלית עם Git ו-Ansible (VM-AUTOMATION);
7. מחשב נייד עליו מתבצעת בדיקה ופיתוח של ספרי משחק עבור Ansible (Laptop-Automation).

הרשת מוגדרת עם פרוטוקול ניתוב דינמי OSPF עם האזורים הבאים:

• אזור 0 – אזור הכולל נתבים האחראים על העברת התנועה באזור EXCHANGE;
• אזור 1 – אזור הכולל נתבים האחראים על תפעול שירותי החברה;
• אזור 2 – אזור הכולל נתבים האחראים על ניתוב תעבורת ניהול;
• אזור N – אזורי רשתות סניפים.

בנתבי גבול נוצר נתב וירטואלי (VRF-INTERNET), שעליו מותקן eBGP תצוגה מלאה עם ה-AS המוקצה המקביל. iBGP מוגדר בין VRFs. לחברה מאגר כתובות לבנות המתפרסמות ב-VRF-INTERNET הללו. חלק מהכתובות הלבנות מנותבות ישירות ל-FW-CLUSTER (כתובות בהן פועלים שירותי החברה), חלקן מנותבות דרך אזור EXCHANGE (שירותי חברה פנימיים הדורשים כתובות IP חיצוניות, וכתובות NAT חיצוניות למשרדים). לאחר מכן, התעבורה עוברת לנתבים וירטואליים שנוצרו ב-L3-CORE עם כתובות לבנות ואפורות (אזורי אבטחה).

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

אוטומציה ותיאורה

הבנו איך הרשת עובדת. עכשיו בואו נסקור צעד אחר צעד מה נעשה כדי להעביר תנועה מ-FW-CLUSTER ל-EMERGENCY:

1. אנו משביתים את הממשקים במתג הליבה (L3-CORE) שמחברים אותו ל-FW-CLUSTER;
2. אנו משביתים את הממשקים במתג ליבת L2-MGMT שמחברים אותו ל-FW-CLUSTER;
3. אנו מגדירים את נתב החירום (כברירת מחדל, כל הממשקים מושבתים בו, מלבד אלה המשויכים ל-L2-MGMT):

• אנו מאפשרים ממשקים ב-EMERGENCY;
• אנו מגדירים את כתובת ה-IP החיצונית (עבור NAT) שהייתה ב-FW-Cluster;
• אנו יוצרים בקשות gARP כך שכתובות הפרג בטבלאות L3-CORE arp ישתנו מ-FW-Cluster ל-EMERGENCY;
• אנו רושמים את מסלול ברירת המחדל כסטטי ל-BRD-01, BRD-02;
• צור כללי NAT;
• הרם לאזור חירום OSPF 1;
• הרם לאזור חירום OSPF 2;
• אנו משנים את עלות המסלולים באזור 1 ל-10;
• אנו משנים את עלות מסלול ברירת המחדל באזור 1 ל-10;
• אנו משנים את כתובות ה-IP המשויכות ל-L2-MGMT (לאלו שהיו ב-FW-CLUSTER);
• אנו יוצרים בקשות gARP כך שכתובות הפרג בטבלאות L2-MGMT arp ישתנו מ-FW-CLUSTER ל-EMERGENCY.

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

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


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

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

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

לאחר מכן, קראנו את התוצאה של הפעולות שבוצעו בספר המשחקים של Ansible (כתובות ה-IP הוחלפו למטרות סודיות):

[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml 

PLAY [------->Emergency on VCF] ********************************************************

TASK [vcf_junos_emergency_on : Disable PROD interfaces to FW-CLUSTER] *********************
changed: [vcf]

PLAY [------->Emergency on MGMT-CORE] ************************************************

TASK [mgmt_junos_emergency_on : Disable MGMT interfaces to FW-CLUSTER] ******************
changed: [m9-03-sw-03-mgmt-core]

PLAY [------->Emergency on] ****************************************************

TASK [mk_routeros_emergency_on : Enable EXT-INTERNET interface] **************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Generate gARP for EXT-INTERNET interface] ****************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Enable static default route to EXT-INTERNET] ****************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change NAT rule to EXT-INTERNET interface] ****************
changed: [m9-04-r-04] => (item=12)
changed: [m9-04-r-04] => (item=14)
changed: [m9-04-r-04] => (item=15)
changed: [m9-04-r-04] => (item=16)
changed: [m9-04-r-04] => (item=17)

TASK [mk_routeros_emergency_on : Enable OSPF Area 1 PROD] ******************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Enable OSPF Area 2 MGMT] *****************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change OSPF Area 1 interfaces costs to 10] *****************
changed: [m9-04-r-04] => (item=VLAN-1001)
changed: [m9-04-r-04] => (item=VLAN-1002)
changed: [m9-04-r-04] => (item=VLAN-1003)
changed: [m9-04-r-04] => (item=VLAN-1004)
changed: [m9-04-r-04] => (item=VLAN-1005)
changed: [m9-04-r-04] => (item=VLAN-1006)
changed: [m9-04-r-04] => (item=VLAN-1007)
changed: [m9-04-r-04] => (item=VLAN-1008)
changed: [m9-04-r-04] => (item=VLAN-1009)
changed: [m9-04-r-04] => (item=VLAN-1010)
changed: [m9-04-r-04] => (item=VLAN-1011)
changed: [m9-04-r-04] => (item=VLAN-1012)
changed: [m9-04-r-04] => (item=VLAN-1013)
changed: [m9-04-r-04] => (item=VLAN-1100)

TASK [mk_routeros_emergency_on : Change OSPF area1 default cost for to 10] ******************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change MGMT interfaces ip addresses] ********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

TASK [mk_routeros_emergency_on : Generate gARPs for MGMT interfaces] *********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

PLAY RECAP ************************************************************************

בוצע!

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

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

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

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

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

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

ממצאים

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

• הקצאת מכשיר;
• איסוף נתונים;
• דיווח;
• פתרון תקלות;
• ציות.

אם יש עניין, נוכל להמשיך את הדיון באחד מהנושאים הנתונים.

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

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

ולמה הנקודות הללו אמורות להוביל:

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

מחברי המאמר: אלכסנדר צ'לובקוב (CCIE RS, CCIE SP) ופבל קירילוב. אנו מעוניינים לדון ולהציע פתרונות בנושא אוטומציה של תשתיות IT.


מקור: www.habr.com