כיצד תכננו והטמענו רשת חדשה ב-Huawei במשרד במוסקבה, חלק 1

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

בחירת פתרון טכני: מקלט מוטנטים

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

למה?

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

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

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

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

עיצוב כביש מהיר: אנחנו המפעיל (הפתעה)

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

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

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

מכיוון שיש לנו רשת בדרגת ספק, אתה יכול להתחבר אליה רק ​​בהתאם לכללים. יחידות השירות קובעות מדיניות ומספקות שירותים. הם אפילו לא צריכים מידע על החיבורים של שרתים, מכונות וירטואליות ותחנות עבודה ספציפיות. אבל יחד עם זאת, יש צורך במנגנוני הגנה, כי אף חיבור אחד לא אמור להשבית את הרשת. אם לולאה נוצרת בטעות, משתמשים אחרים לא צריכים לשים לב לכך, כלומר, יש צורך בתגובה נאותה מהרשת. כל מפעיל טלקום פותר כל הזמן בעיות דומות שנראות מורכבות לכאורה בתוך רשת הליבה שלו. הוא מספק שירות ללקוחות רבים עם צרכים ותנועה שונים. יחד עם זאת, מנויים שונים לא צריכים לחוות אי נוחות מהתנועה של אחרים.
בבית פתרנו את הבעיה בצורה הבאה: בנינו רשת L3 עם יתירות מלאה, תוך שימוש בפרוטוקול IS-IS. רשת שכבת-על נבנתה על גבי הליבה המבוססת על טכנולוגיה EVPN/VXLAN, באמצעות פרוטוקול ניתוב MP-BGP. כדי להאיץ את ההתכנסות של פרוטוקולי ניתוב, נעשה שימוש בטכנולוגיית BFD.

מבנה רשת

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

שכבת תחתית - ניתוב

שכבת על - ניתוב

מתגי Huawei CE6870 עם רישיונות VXLAN שימשו כמתגי הפצה. למכשיר זה יחס מחיר/איכות אופטימלי, המאפשר לחבר מנויים במהירות של 10 ג'יגה-ביט לשנייה, ולהתחבר לעמוד השדרה במהירויות של 40-100 ג'יגה-ביט לשנייה, בהתאם למקלטי המשדר בשימוש.

מתגי Huawei CE6870

מתגי Huawei CE8850 שימשו כמתגי ליבה. המטרה היא להעביר תנועה במהירות ובאמינות. לא מחוברים אליהם מכשירים מלבד מתגי הפצה, הם לא יודעים כלום על VXLAN, ולכן נבחר דגם עם 32 יציאות 40/100 Gbps, עם רישיון בסיסי המספק ניתוב L3 ותמיכה ב-IS-IS ו-MP-BGP פרוטוקולים .

התחתון הוא מתג הליבה של Huawei CE8850

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

• איחוד של מתגי הפצה למחסנית עמידה לתקלות בכל חדר חיבור צולב. יתרונות: פשטות וקלות התקנה. חסרונות: יש סבירות גבוהה יותר לכשל של כל הערימה כאשר מתרחשות שגיאות בקושחה של התקני רשת ("דליפות זיכרון" וכדומה).
• החל טכנולוגיות M-LAG ו-Anycast gateway כדי לחבר התקנים למתגי הפצה.

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

לַחֲצוֹת

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

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

עכשיו בואו נסתכל על חיבור מתגי הפצה לקרנל:
סובלנות תקלות מסופקת ברמת הרשת באמצעות פרוטוקול IS-IS. שימו לב שקו תקשורת נפרד L3 מסופק בין המתגים, במהירות של 100G. מבחינה פיזית, קו תקשורת זה הוא כבל גישה ישירה אותו ניתן לראות מימין בתמונה של מתגי Huawei CE6870.

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

צריך לומר כמה מילים על האופן שבו טכנולוגיות שער VXLAN ו-Anycast פועלות יחד. VXLAN, מבלי להיכנס לפרטים, היא מנהרה להעברת מסגרות Ethernet בתוך מנות UDP. ממשקי הלולאה של מתגי הפצה משמשים ככתובת ה-IP היעד של מנהרת VXLAN. לכל חיבור צולב יש שני מתגים עם אותן כתובות ממשק loopback, כך שניתן להגיע לכל אחד מהם חבילה, וניתן לחלץ ממנה מסגרת Ethernet.

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

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

במקום מסקנה

כפי שצוין לעיל, במהלך הבדיקה והתפעול הרשת הפגינה אמינות גבוהה (זמן השחזור לתקלות אופייניות הוא לא יותר ממאות אלפיות שניות) וביצועים טובים - כל חיבור צולב מחובר לליבה בשני ערוצי 40 Gbit/s. מתגי גישה ברשת שלנו מוערמים ומחוברים למתגי הפצה באמצעות LACP/M-LAG עם שני ערוצי 10 Gbit/s. מחסנית מכילה בדרך כלל 5 מתגים עם 48 יציאות כל אחת, ועד 10 ערימות גישה מחוברות להפצה בכל חיבור צולב. כך, עמוד השדרה מספק כ-30 Mbit/s למשתמש גם בעומס התיאורטי המקסימלי, שמספיק בזמן כתיבת שורות אלו לכל היישומים המעשיים שלנו.

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

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

מקסים קלוצ'קוב
יועץ בכיר בקבוצת ביקורת רשת ופרויקטים מורכבים
מרכז פתרונות רשת
"מערכות מידע סילון"

מקור: www.habr.com