3. עיצוב רשת ארגונית על מתגי אקסטרים

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

במאמר זה אנסה להיות תמציתי ככל האפשר:

• תאר גישה מודולרית לעיצוב רשתות ב-Etnterprise
• שקול את סוגי הבנייה של אחד המודולים החשובים ביותר של רשת הארגון - רשת השדרה (IP-campus)
• תאר את היתרונות והחסרונות של אפשרויות יתירות של צמתי רשת קריטיים
• שימוש בדוגמה מופשטת לתכנון/עדכון רשת ארגונית קטנה
• בחר מתגי Extreme כדי ליישם את הרשת המתוכננת
• עבודה עם סיבים וכתובות IP

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

בכל מקרה, מי שמעוניין מוזמן להמשיך לקרוא.

גישה מודולרית לתכנון רשת

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

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

כדוגמה, הבה ניקח בחשבון את הדברים הבאים:

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

• קירוב שני - כל אחת מהרמות הללו מפורטת במודולים נפרדים
  • רשת השדרה או הקמפוס מורכבת מ:
    • מודול בן 3 או 2 רמות המתאר את רשת הארגון ואת רמותיה - גישה, הפצה ו/או ליבה
    • מודול המתאר את מרכז עיבוד הנתונים (בעיקרו חלק השרת של התשתית)

  • רמת הגבול בתורה מורכבת מ:
    • מודול חיבור לאינטרנט
    • מודולי WAN ו-MAN, האחראים על חיבור אובייקטים ארגוניים המפוזרים גיאוגרפית
    • מודול לבניית מנהרות VPN וגישה מרחוק
    • לעתים קרובות, עסקים קטנים רבים משלבים כמה מהמודולים הללו, או אפילו את כולם, למודול אחד

  • רמת ספק:
    • רמה זו כוללת חיבורים "לעולם החיצון" - סיבים אופטיים כהים (השכרת סיבים ממפעילים), ערוצי תקשורת (Ethernet, G.703 וכו'), גישה לאינטרנט.

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

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

  • במקרים מורכבים יותר, ניתן לחלק את מרכז הנתונים ל:
    • חלק רשת דו-מפלסי או תלת-מפלסי
    • חלק השרת

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

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

  במאמר זה, אתמקד ברמת הארגון בקמפוס ואתאר אותה ביתר פירוט.

  סוגי רשתות IP-CAMPUS

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

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

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

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

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

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

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

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

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

  לפיכך, הרשת במוקדם או במאוחר גדלה למודל דו-שכבתי:

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

  מתגי גישה חייבים להיות חכמים יותר ובעלי יכולת לעמוד בדרישות ביצועי הרשת, האבטחה והגמישות, ועליהם:

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

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

  • הן מבחינת יציאות של downlink trunk לכיוון מתגי גישה, והן מבחינת ממשקי עמיתים של מתגי חלוקה שכנים (ובהמשך, ממשקי uplink אפשריים לכיוון הליבה)
  • בחלקים התפקודיים L2 ו-L3
  • מבחינת פונקציונליות אבטחה
  • מבחינת הבטחת סבילות לתקלות (יתירות, קיבוץ באשכולות ויתירות ספק כוח)
  • מבחינת הבטחת גמישות באיזון התנועה
  • בעלי (אם אפשר) פוטנציאל נוסף לצמיחה של פונקציונליות (טרנספורמציה לאורך זמן של התקן הצבירה לליבה)
  • במקרים מסוימים, ייתכן שיהיה מתאים להשתמש ביציאות PoE ו-PoE+ במתגי חלוקה.

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

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

  כתוצאה מכך, תנועת התנועה גדלה מהסיבות הבאות:

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

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

  בשלב זה, הארגון יכול לעבור למודל רשת בן 3 שכבות:

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

  • רוחב פס ממשק - 1GE, 2.5GE, 10GE, 40GE, 100GE
  • קיבולת מיתוג וביצועי העברה
  • סוגי ממשקים - 1000BASE-T, SFP, SFP+, QSFP, QSFP+
  • מספר ומערכת הממשקים
  • אפשרויות יתירות (הערמה, אשכולות, יתירות לוח בקרה (רלוונטי למתגים מודולריים), יתירות ספק כוח וכו')
  • פונקציונליות

  ברמה זו של הרשת, השינוי הטכני שלה בהחלט הכרחי:

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

  כמו גם מבחינה משפטית, המגדירה את מדיניות אבטחת הרשת של הארגון, אשר משלימה את מדיניות האבטחה הכללית מבחינת:

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

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

  למה אני כותב את כל האמיתות האלה? כי אני רוצה להזכיר כאן מונח כמו ROI - החזר השקעה (החזר/החזר השקעות) ולשקול את הצד הזה שקשור ישירות לבחירת ציוד הרשת.

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

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

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

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

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

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

  יתירות של צמתים קריטיים

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

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

  להלן טבלת סיכום כללית המשווה בין שתי השיטות:

  
  

  • ניהול — כפי שניתן לראות מהטבלה, בהקשר זה ל-stacking יש יתרון שכן מנקודת מבט ניהולית, stack של מספר מתגים מיוצג על ידי מתג אחד עם מספר רב של פורטים. במקום לנהל, למשל, 8 מתגים שונים במהלך clustering, ניתן לנהל רק מתג אחד במהלך stacking.
  • מרחק — כרגע, מבחינה מדויקת, היתרון של אשכולות אינו כה ברור, מכיוון שהופיעו טכנולוגיות של אחסון מתגים באמצעות פורטים מסוג stacking או פורטים דו-תכליתיים (לדוגמה, SummitStack-V עבור Extreme, VSS עבור Cisco וכו'), התלויות גם הן בסוגי המשדרים. כאן, היתרון ניתן לאשכולות המבוסס על העיקרון שכאשר מבצעים אחסון, ישנן אפשרויות הדורשות שימוש בפורטים מסוג stacking רגיל, המחוברים לעתים קרובות באמצעות כבלים מיוחדים באורך מוגבל - 0.5, 1, 1.5, 3 או 5 מטרים.
  • עדכון תוכנה — כאן אנו רואים של-clustering יש יתרון על פני stacking והנקודה היא הבאה — בעת עדכון גרסת תוכנת הציוד באמצעות stacking, מעדכנים את התוכנה במתג הראשי, אשר לאחר מכן לוקח על עצמו את התפקיד של הצבת התוכנה החדשה על המתגים החברים במחסנית. מצד אחד, זה מקל על העבודה, אך עדכון התוכנה דורש לעתים קרובות אתחול מחדש של החומרה של הציוד, מה שמוביל לאתחול מחדש של כל המחסנית וכך להפסקה בפעולתה ובכל השירותים הקשורים אליה למשך זמן = זמן אתחול מחדש. בדרך כלל, זה קריטי מאוד עבור הליבה ומרכז הנתונים. באמצעות אשכולות — יש לכם 2 מכשירים בלתי תלויים זה בזה, שבהם ניתן לעדכן את התוכנה ברצף אחד אחרי השני. במקרה זה, ניתן להימנע מהפרעות בשירותים.
  • הגדרות תצורה — כאן היתרון הוא כמובן של stacking, שכן במקרה של ניהול צריך לערוך רק את ההגדרות עבור מכשיר אחד וקובץ התצורה שלו. באשכולות, מספר קבצי התצורה יהיה שווה למספר צמתי האשכול.
  • סבילות לתקלות — כאן שתי הטכנולוגיות שוות בקירוב, אך עדיין יש יתרון קל לאשכולות. הסיבה לכך היא הבאה — אם ניקח בחשבון את המחסנית מנקודת מבט של תהליכים ופרוטוקולים רצים, נראה את הדברים הבאים:
    • יש מתג ראשי שעליו פועלים כל התהליכים והפרוטוקולים העיקריים (לדוגמה, פרוטוקול הניתוב הדינמי - OSPF)
    • ישנם מתגי עבדים אחרים שמפעילים את התהליכים העיקריים הנחוצים לעבודה במחסנית ולשירות התעבורה העוברת דרכם.
    • כאשר מתג האב נכשל, מתג העבד הבא בעל העדיפות הגבוהה ביותר מזהה את כשל המפסק הראשי.
    • הוא מתחיל את עצמו כמאסטר ומפעיל את כל התהליכים שפעלו על המאסטר (כולל פרוטוקול OSPF שאנו צופים בו)
    • לאחר זמן מה של התחלת התהליך (בדרך כלל קצר למדי), פרוטוקול OSPF עצמו מתחיל לפעול.
    • לכן, OSPF יעבוד מעט מהר יותר במקרה של כשל של אחד הצמתים במהלך אשכול מאשר במהלך ערימה (במשך הזמן הנדרש להפעלה ולאתחול תהליכים ופרוטוקולים במתג העבדים של הערימה). למרות שאני צריך לציין שפרוטוקולי ומתגים מודרניים של ערימה פועלים מהר מאוד, לעתים קרובות משך הפסקת התעבורה במהלך החלפת ערימה אורכת פחות משנייה אחת, אך עדיין באופן נומינלי אשכול מנצח בפרמטר זה.

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

  • גְמִישׁוּת — אני מחשיב את זה לאחד הפרמטרים העיקריים. באופן כללי, גמישות היא מאפיין מורכב, שמשמעותו התכונה של משהו להשתנות תחת השפעת עומס ולחזור לצורתו המקורית לאחר היעלמותו. באופן מוזר, עבור אשכולות זה יהיה גבוה יותר אפילו בהתחשב בציון של 4:3 במאפיינים לטובת סטקינג. הכל עניין של הגורם האנושי. כן, כן, אל תתפלאו — החוזק של פרמטרי סטקינג כמו בקרה מאוחדת, תצורת הגדרות ומורכבות פשוטה הוא המקום שבו טמונה החולשה של סטקינג כאשר הגורם האנושי נכנס לתמונה.

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

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

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

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

  כשאני אומר יתירות בתוך צומת רשת אני מתכוון:

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

  יתירות של חיבורים/קישורים מובנת בעיקר כנוכחות של נתיבי כבלים כפולים (או קישורי רדיו במקרה של שטחים פתוחים) עם:

  • מופץ דרך פירי כבלים ותעלות שונים בתוך הבניין
  • פיזור גיאוגרפי על פני השטח ברמה של 2 בניינים או יותר, עיר, אזור או מדינה (הטבעות הנפחיות הנקראות)

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

  • במקרה של שכפול של כרטיסי ממשק של מתג מודולרי, או בנוכחות מחסנית, יש צורך לחלק קישורים בין יחידות - כרטיסי ממשק במקרה של מתגים מודולריים ומתגים במקרה של מחסנית.
  • מומלץ להשתמש בפרוטוקולי צבירת קישורים (LACP, MLT, PAgP וכו') כדי לשלב קישורים לקבוצות ולאזן את העומס ביניהם.
  • להשתמש בנתבים התומכים בפרוטוקולי ECMP (Equal-Cost-Multi-Path) - כאשר, בעת מסירת מספר חבילות לאורך מסלול אחד, חבילות אלו אינן עוברות דרך נתיב (וממשק) אחד הטוב ביותר, אלא מחולקות על פני מספר נתיבים (ומספר ממשקים) הטובים ביותר, אשר נקבעים על ידי שוויון המדדים של פרוטוקול הניתוב, אשר בתורו אחראי על מילוי טבלת הניתוב הסופית.

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

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

  • הרשת נבנתה בצורה מורכבת למדי:
    • עם חבורה של פרוטוקולי ניתוב דינמיים ופרוטוקולים - OSPF, MP-BGP, MPLS, PIM, IGMP, IPv6 וכו'.
    • חבורה של שירותים - גישה לאינטרנט, VPN L2 ו-L3, VoIP, IPTV, קווים ייעודיים וכו'.

  • אבל היה צוואר בקבוק אחד ברשת - נתב הגבול, ששילב את הפונקציות של נתב גבול BGP וסיים כמה שירותי משתמש.
  • כן, זה עלה כמו כנף מטוס (כמה מיליוני רובלים)
  • כן, באותה תקופה זה היה אחד המכשירים המובילים בסדרה של ספק הרשתות המפורסם ביותר.
  • כן, זה היה חייב להיות אמין מאוד - עם דירוג MTBF מעולה
  • כן, היו לו 4 ספקי כוח, מורכבים לפי ערכת 2x2 ומחוברים מ-UEPS וכניסות שונות.

  אבל כל זה לא שינה את העובדה שהוא היה נקודת כשל יחידה ברשת.

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

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

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

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

  • חלקם של שירותי החברה, הקשורים או קשורים לגבול זה, היה כ-60-70%
  • כפי שחושב מאוחר יותר, הרווח היומי היה כ-900 אלף רובל (בקירוב) באותה תקופה.
  • כך, במהלך 3 ימי השבתה, תיאורטית, אבדו רווחים בסכום של מיליון 1 אלף רובל עד מיליון 620 אלף רובל.

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

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

  כתוצאה מכך, תוקנה מדיניות החברה:

  • סירב לחוזה ההחלפה בתנאי ה-NBD
  • עזב את חוזה השירות הרגיל
  • רכשתי נתב כפול בשווי של כ-1-1.3 מיליון רובל כדי לגבות 90% מהפונקציונליות של הנתב הראשי

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

  דוגמה לעיצוב רשת ארגונית

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

  • הכנה/הכנה — עליכם להחליט עם ההנהלה שלכם לגבי יעדי מודרניזציה של הרשת שאתם רוצים להשיג — להגביר את עמידות התקלות, ליישם שירותים או טכנולוגיות חדשות. אדלג כאן על הגדרת המגבלות — הטכניות והארגוניות, מכיוון שאני מניח שאתם עובדים בארגון ויש לכם עתודה גדולה של זמן להתגבר עליהן. אחזור לנושא התקציב בהמשך.
  • תכנון — כאן תצטרכו לבנות תיאור מלא של הרשת הנוכחית שלכם (אם אינכם יודעים אותו עדיין), כלומר לתאר את הרשת כפי שהיא כעת:
    • כמות וסוג הציוד
    • מספר וסוגי היציאות
    • נתיבי כבלים קיימים ותוכניות מיתוג בתוך ובין מבנים
    • תוכניות אספקת חשמל
    • כתובת L2 ו-L3
    • צור מפות רשת Wi-Fi עם נקודות גישה ובקרים
    • תאר את חוות השרתים שלך
    • מומלץ לתאר את כל השירותים שלכם ואת הקשרים ביניהם
    • אם כבר יישמתם מדיניות אבטחת רשת ומדיניות בקרת גישה לרשת בצורה כזו או אחרת, הקפידו לקחת זאת בחשבון בעת ​​תכנון
    • מיד אציין שהשלב השני, למעשה, הוא רשימה מלאה של הרשת, החל מתשתית הכבלים ותוכניות אספקת החשמל, וכלה בשירותים (יישומים ופורטים שלהם). שלב זה דורש עבודה רבה מאוד ולעיתים אף משעמם. אם אתה או קודמכם בתפקיד לא שמרתם תיעוד או אפילו מערכת ניטור בסיסית, הגיע הזמן לחשוב על זה. הרשת נוטה להשתנות עם הזמן בקצב כזה או אחר, ורק שמירה על תיעוד עדכני או מערכת ניטור יכולה לעזור לכם לעקוב אחר מצבה ולהקל על ניהולה. אבל זה כבר חל על שלב התפעול.

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

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

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

  • ישנו מיזם גדול למדי עם מספר משוער של מקומות עבודה, כ-700-800 עובדים (כאן אני מתכוון לעובדים הזקוקים לגישה לרשת הארגון)
  • ישנם מספר מבנים נפרדים בתוך שטח המיזם:
  • מבנים עיקריים:
    • מספר מבנים - 2 יחידות
    • מספר קומות בבניין - 7
    • מספר ארונות תקשורת לקומה בבניין אחד - 3 (סה"כ 21) יחידות.
    • מספר עובדים בבניין = ~ 250 איש

  • דיור נוסף:
    • מספר מבנים - 10 יחידות
    • מספר קומות בבניין/סדנה - 2 יחידות.
    • מספר ארונות תקשורת בבניין - 3 יחידות.
    • מספר עובדים בבניין = ~ 20 איש

  • הרמה הנוכחית של ליבת הרשת (אגב, סכמה נפוצה מאוד שנתקלתי בה יותר מפעם אחת בצורה כזו או אחרת ובהרכב הפורטים) מוצגת:
    • 2 מתגים L2:
      • 1 יציאות RJ-45 של 24 ג'יגה-בייט -
      • יציאות SFP של 1 ג'יגה-בייט - 4 יחידות
    • מתג L1 ראשון:
      • יציאות SFP של 1 ג'יגה-בייט - 24 יחידות
    • טופולוגיית ליבה - טבעת
    • קישורי עמית לעמית בין מתגים מופעלים באמצעות סיבים אופטיים
    • מתגים ממוקמים בחדרי שרתים קטנים עם ארונות
  • רמת חלוקה נוכחית:
    • בשילוב עם רמת ליבת הרשת מבחינת צבירת קישורים ממתגי גישה
    • כתובת L3 מועברת לנתב הגבול ו/או לחומת האש
  • רמת גישה נוכחית:
    • מתגי L2 עם 16 יציאות גישה RJ-100 של 45 מגה-בייט ו-2 יציאות RJ-45/SFP משולבות של ג'יגה-ביט
    • מתגים ממוקמים בארונות בקומות
    • טופולוגיית מתג גישה:
      • כוכב (רכזת וחישורים) עם מתג ליבה/חלוקה באמצע
      • קרן/חישור הוא ענף של מתגים בקומות - 3 יחידות בשרשרת
    • ישנם מתגי גישה לא מנוהלים
    • מתגים ב-9 מקרים נוספים מחוברים באמצעות ממירי מדיה (ממירי אות אופטי לאות חשמלי)
  • תשתית הכבלים הנוכחית:
    • מערכת כבלים בין בניינים:
      • יש כבל אופטי בין שני הבניינים הראשיים עם קיבולת של 2 סיבים
      • יש כבל אופטי אחד בין אחד הבניינים הנוספים (שם מותקן מתג הליבה) לכל אחד מהבניינים הראשיים עם קיבולת של 1 סיבים כל אחד.
      • יש כבל אופטי אחד בין מארזים נוספים למארזים עם מתגי ליבה מותקנים בקיבולת של 1 סיבים (הפיזור שלהם מוצג בתמונה למטה)
      • סוג הסיב בכל הכבלים הוא מצב יחיד/SMF
      • משתמשים במשדרי-מקלט SFP חד-מצביים בעלי 2 סיבים
      • חלק מהכבלים מסתיימים במסגרות חלוקה אופטיות (ODF) בחדרים נפרדים (חדרי שרתים/חדרי שרתים), וחלק מהכבלים מסתיימים בחדרי בקרה בגובה הרצפה.

    • מערכת כבלים בתוך מבנים:
      • יש מבנה כבלים מעורב בין חדרי השרתים לארונות הראשונים בקומות:
      • כבלי נחושת Cat5e - 10 יחידות (או 100 זוגות כבלים)
      • כבל סיב אופטי רב-מודדי/MMF עבור 4 או 8 סיבים - יחידה אחת.
      • כבל סיב אופטי רב-מודדי/MMF בעל 4 סיבים בין ארונות רצפה
      • כבלי נחושת Cat5e בין ארונות רצפה לשקעי גישה
    • מרכז נתונים נוכחי:
      • יש כמה שרתים, למשל 6 יחידות
      • כלל פורטים של 1 ג'יגה-בייט במתג הליבה בבניין הראשי הראשון
      • כל יישומי הארגון מועברים לשרתים
    • כתובת וניתוב L2, L3:
      • ישנם מספר רשתות VLAN ברשת - 2,3 לכל בניין
      • שרתים מוקצים לרשת נפרדת /24
      • לצרכים פנימיים, נעשה שימוש ברשתות אפורות מסוג B, הכלולות בטווח - 172.16.0.0/16
      • כתובות L3 מסתיימות בנתב הגבול ו/או בחומת האש
      • נעשה שימוש בניתוב סטטי
    • מידע נוסף:
      • טלפוניה:
        • טלפוניה מסורתית המשתמשת במרכזיות דיגיטליות בסגנון ישן (לא IP-PBX) נפרסה בבניינים ובכמה יחידות
        • יש צורך לספק טלפונים לבניינים חדשים, ללא עלויות הנחת קווי נחושת יקרים בקיבולת מסוימת ובניית SCS כפול לטלפוניה בתוך בניינים.
        • עם הזמן, מתוכנן להטמיע טלפוניית IP בכל רחבי הארגון, לשלב אותה עם מערכות CRM ולהעביר אליה את כל העובדים.
      • קיבולת הנמל:
        • יש צורך לנתח את הקיבולת הנוכחית של יציאות ראשיות ויציאות גישה, ולשריין לפחות 25-30% לצרכים עתידיים.
        • לנתח את יעילות התפוקה הנוכחית של פורטי גישה וקישורי רשת (trunk link)
        • לספק נוכחות של יציאות גישה PoE/PoE+ עבור התקנים ממערכות סמוכות - מעקב וידאו וטלפוניה
      • מעקב וידאו:
        • מתוכנן להשתמש ברשת הארגונית כאמצעי תחבורה עבור רשת מעקב הווידאו.
        • יש צורך לספק יציאות PoE עבור מצלמות CCTV
      • מערכות אלחוטיות:
        • בעתיד, מתוכנן ליישם תשתית אלחוטית לניידות עובדים.
        • יש צורך לספק יציאות PoE עבור נקודות גישה
      • תקציב, מועדים ודרישות ציוד:
        • נצל את הציוד הקיים שלך בצורה הטובה ביותר
        • בעת תכנון רשת, יש לקחת בחשבון את האפשרות להרחיב את קיבולת הרשת למשך N שנים קדימה.
        • בעת תכנון רשת, יש לקחת בחשבון תמיכה בכל פונקציות האבטחה האפשריות - הנה רשימה של פונקציונליות, החל מאבטחת פורטים וכלה באימות והרשאה של משתמשים דרך 802.1x.
        • במידה המרבית האפשרית, לשמור צמתים קריטיים ברשת בעלי חשיבות ראשונית - הליבה ומרכז הנתונים, ולאפשר לשמור צמתים בעלי חשיבות משנית - צמתים מפזרים.
        • תקציב הפרויקט צריך לאפשר מימון רציף במספר שלבים
        • סכום התקציב - כאן כל מיזם קובע לעצמו, בהנחיית האינדיקטורים הפיננסיים שלו
        • תנאים - במקרה האידיאלי ביותר, לא יהיו תנאים מפורשים, מכיוון שמדובר בפרויקט פנימי של החברה, המיושם על ידי עובדיה, או שהם יהיו יחסית בנוח - לדוגמה, שנה (או יותר). במקרה הגרוע ביותר - זה יכול להיות בין 1 חודשים לשישה חודשים.
      • פתרון בעיות רשת קיימות:
        • אובדן חבילות
        • בעיות DHCP במתגי גישה חכמים יותר או פחות הקשורות לשימוש במשפחת פרוטוקולי STP כדי להילחם בלולאות בפורטים של גישה.
        • להיפטר מנוכחותו של ממשק שרת DHCP בכל VLAN של עובד
        • הופעתן של לולאות מיתוג הקשורות להפעלה לא מורשית של מתגים מנוהלים/לא מנוהלים במשרדים ולחיבור כל מיני מכשירים אליהם.
        • הרשימה עוד ארוכה עוד ועוד...

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

      • לפחות לשרטט את הרשת הקיימת לצורך ניתוח נוסף
      • איסוף נתונים מציוד:
        • תנועה על יציאות תא מטען
        • שגיאות בפורטים
        • עומס על המעבד וצריכת זיכרון במתגים ובנתבים
        • תאר סכמות L2-L3 לפי VLAN וכתובות IP
      • העלה את תרשימי מסלול הכבלים:
        • דיאגרמות סיבים אופטיים ודיאגרמות חיווט של חיבור צולב אופטי
        • תוכניות חלוקת כבלי נחושת בין חדרי שרתים לקומות
        • תוכניות חלוקת כבלי נחושת בין קומות ומשרדים
        • בדיקת נוכחות של צלבים אופטיים ולוחות תיקון בחדרי שרתים וארונות
      • בדוק את מעגלי אספקת החשמל בשרת ובארונות הרצפה
      • בדיקת נוכחות של UPS וסוללות בצמתים קריטיים
      • לנתח את כל הנתונים

      בהתבסס על הנתונים משלב ההכנה, יצרתי תרשים לוגי גס:

      
      
      לאחר מכן, בהתאם לגישה המודולרית, יש צורך לזהות את הרמות והמודולים של הארגון:

      
      
      לא אגע ב-Edge במאמר זה, אך אזכור בקצרה את התזות הבסיסיות עבור כל אחד ממודולי הקמפוס:

      • גישה - ברמה זו יש להבטיח:
        • מספר הפורטים הנדרש למשתמשים כדי לגשת לרשת
        • יישום מדיניות אבטחה - סינון תעבורה ופרוטוקולים
        • דחיסת דומיין שידור ופילוח רשת באמצעות VLANs
        • יישום של רשתות VLAN נפרדות לתעבורת קול
        • תמיכה ב-QoS
        • תמיכה ביציאות גישה של PoE
        • תמיכה ב-IP multicast
        • סבילות לתקלות של uplinks בשילוב עם שכבת ההפצה (רצוי)
      • חלוקה - ברמה זו יש להבטיח את הדברים הבאים:
        • מספר הפורטים הנדרש לחיבור מתגי גישה
        • צבירה ויתירות של קישורי מתג גישה
        • ניתוב IP
        • סינון חבילות
        • תמיכה ב-QoS
        • סבילות לתקלות ברמת הקישור, החומרה וספק הכוח (רצוי מאוד)
      • הליבה חייבת לספק:
        • מיתוג וניתוב חבילות במהירות גבוהה
        • מספר היציאות הנדרש לחיבור מתגי חלוקה
        • תמיכה בניתוב IP ופרוטוקולי ניתוב דינמיים עם התכנסות רשת מהירה
        • תמיכה ב-QoS
        • פונקציונליות אבטחה להגנה על הגישה לציוד ולמישור הבקרה
        • עמידות בפני תקלות בחומרה ובספק כוח (חובה)
      • מרכז נתונים - שכבת הרשת של מודול זה חייבת לספק:
        • קישורי תקשורת במהירות גבוהה
        • מספר הפורטים הנדרש לחיבור שרתים
        • יתירות של קישורי תקשורת בין שרתים למתגי מרכז נתונים, ובין מתגי מרכז נתונים לליבה של הרשת (נדרש)
        • גיבוי ציוד ואספקת חשמל (נדרש)
        • תמיכה ב-QoS

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

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

      בשלב הבא, נחשב את הפורטים וקישורי התקשורת עבור הרמות הבאות:

      רמת הפצה

      רמת הליבה

      רמת מרכז הנתונים

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

      • רמת גישה — נדרשים מתגי גישה של 24 ו-48 פורטים, רצוי עם פורטי גישה של 1 ג'יגה-בייט ועם פורטי SFP אופטיים בעליית רשת עם תמיכה ב-PoE ופונקציונליות רחבה:
        • בסך הכל הם יספקו 504 פורטי גישה, אשר באופן עקרוני יכסו את דרישות הפורטים הפנויים אם יוחלט להשתמש ב-2 פורטים לכל תחנת עבודה - טלפון IP ופורט נתונים.
        • ניתן להשתמש במתג אחד בעל 48 פורטים ופונקציונליות PoE בכל קומה, המספק פורטי גישה לדרישות:
          • רזרבה - כ-102 יציאות רזרביות (22%) על המבנים הראשיים. עבור מבנים נוספים קצת יותר - 25%.
          • מעקב וידאו
          • רשת אלחוטית
      • רמת הפצה — נדרשים מתגים עם סט של פורטי SFP מ-12 עד 48 פורטים עם לפחות 2 פורטי SFP+, עם יכולת ערימה ופונקציונליות מורחבת, וכן נוכחות של ספקי כוח גיבוי.
      • רמת הליבה — נדרשים מתגים במהירות גבוהה עם 12 עד 24 פורטים SFP/SFP+ עם תמיכה הן ב-stacking והן באשכולות עם תמיכה ב-MC-LAG. יש לציין שניתן גם להשתמש בכלי ניתוב לאיזון תעבורה. הדורות האחרונים של מתגים ונתבים L3 תומכים ב-ECMP עם איזון תעבורה על פני 4 נתבים או יותר עם אותו מדד.
      • רמת מרכז הנתונים — נדרשים מתגים עם 8 עד 24 פורטים SFP/SFP+ עם תמיכה הן בערימה והן באשכולות עם תמיכה ב-MC-LAG.

      תוכנית הרשת היעד הושגה לבסוף כזה

      בחירת מתגים קיצוניים ליישום פרויקט

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

      רמה
      דגם
      יציאות
      תיאור

      ליבה
      x620-16x-בסיס*

      x670-G2-48x-4q-בסיס*
      16 x 10GE SFP+
       
       
       
      ‏48x10GE SFP+ ו-4x40GE QSFP+
      עבור צרכי הליבה של הגרעין:

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

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

      מרכז הנתונים

      x620-16x-בסיס*

      x590-24x-1q-2c*

      x670-G2-48x-4q-בסיס*

      16 x 10GE SFP+
       
       
       
      24x10GE SFP, 1xQSFP+, 2xQSFP28
       
       
      ‏48x10GE SFP+ ו-4x40GE QSFP+

      לצרכים הבסיסיים של מרכז הנתונים:

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

      המתג מסדרת x620 יעשה את העבודה עבור הדרישות המינימליות.
      במקרה של דרישות מורחבות למספר הפורטים ופונקציונליות רחבה יותר, כדאי לשקול את המתגים מסדרות x670-G2 ו-x590-24x-1q-2c.

      הפצה

      X460-G2-24x-10GE4-Base*

      X460-G2-48x-10GE4-Base*

      ‏24x1GE SFP, ‏8x1000 RJ-45, ‏4x10GE SFP+
       
       
       
      ‏48x1GE SFP, ‏4x10GE SFP+

      לצורכי הפצה בסיסיים:

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

      מתגי סדרת x460-G2 הם אידיאליים. נוכחותם של ספקי כוח יתירים עם היכולת להרחיב ולהוסיף יציאות 10G, CX (לערימה) ו-QSFP+ הופכת אותם למתגים אידיאליים עבור שכבת ההפצה עם יציאות של עד 1 ג'יגה-בייט.

      גישה

      X440-G2-24p-10GE4*

      X440-G2-24t-10GE4*

      X440-G2-48t-10GE4*

      X440-G2-48p-10GE4*

      24x1000BASE-T (4 x SFP משולב), 4x10GE SFP+ (תקציב PoE 380 וואט)
       
      24x1000BASE-T (4 x SFP משולב), 4x10GE SFP+
       
       
      24x1000BASE-T (4 x SFP משולב), 4x10GE SFP+ משולבים
       
      48x1000BASE-T (4 x SFP משולב), 4x10GE SFP+ משולבים (תקציב PoE 740 וואט)

      לצורכי גישה:

      • מספר נדרש של יציאות גישה
      • תמיכה ב-PoE/PoE+
      • פונקציונליות ויכולות הרחבת יציאות
      • בונוס נוסף בצורת תמיכה בהצבת פורטים של 10 ג'יגה-בייט "ישר מהקופסה"

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

      *ניתן למצוא את המפרט של המתגים שנבחרו במאמר הראשון בסדרה — סקירת מתגים קיצוניים

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

      • עבודה עם נתיבי כבלים - סיבים וקווי נחושת
      • כתובת IP

      עבודה עם סיבים

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

      מספר קישורי התקשורת

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

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

      אני אתן כמה פתרונות:

      • הצעד הברור הראשון הוא להשתמש בסיבים הרזרביים בכבל שבין בניין 1 לבניין 1 ובניין 1 לבניין 2 (כפי שניתן לראות מהטבלה, רק 2 מתוך 8 הסיבים בכל כבל נמצאים בשימוש). לשם כך, די להתקין חיבורי אופטיים בין החיבורים בבניין 1, ובמידת הצורך, להשתמש במודולי SFP עם תקציב אופטי עתודה.
      • השלב השני הוא שימוש בטכנולוגיית CWDM - ריבוב של אורכי גל נושאי גל בתוך סיב בודד. טכנולוגיה זו זולה בהרבה מ-DWMD ופשוטה למדי ליישום. הדרישות הן בעיקר לאיכות הסיבים האופטיים ומקלט-משדרים SFP/SFP+ באורך ובתקציב מסוימים. כפי שאמרתי במאמר הקודם - היכולת של מתגים לזהות מקלטי-משדרים של צד שלישי יכולה לפשט מאוד את חיינו ולהפחית את עלויות ההון לבניית כבלים אופטיים נוספים.
      • השלב השלישי הוא לשקול את האפשרות להגדיל את מספר הסיבים על ידי הנחת כבלים אופטיים נוספים.

      בשלב הבא נבחן את מספר הסיבים בין בניינים עם מתגי חלוקה מותקנים לבין בניינים נוספים 2-10. גם כאן, לא הכל כל כך ברור:

      • ראשית, אין מספיק סיבים כדי ליישם את תוכנית היעד שלנו - 2 סיבים לכל מתג (כפי שאנו זוכרים, יש לנו כבלים עם 4 OB לכל מקרה)
      • שנית, גם אם יש מספר מספיק של סיבים בין בניינים, סיבי MMF משמשים בתוך הבניינים, מה שלא יאפשר לנו לחבר בפשטות סיבי SMF ו-MMF (אני מדבר על מרחקים בין בניינים מעל 300-400 מטרים)

      במקרים כאלה, ניתן לשקול את האפשרויות הבאות:

      • אספקת סיבים לכל מתג SMF:
        • אם המרחק מאפשר, ניתן להאריך כבלי תיקון ארוכים נוספים בין המתגים. פעם השתמשנו בכבלי תיקון באורך של 30-50 מטר.
        • הנחת כבל SMF אופטי בעל קיבולת נמוכה וזול יחסית בין ארונות
        • כמוצא אחרון, השתמשו בממירי SMF-MMF שונים
      • כדי למזער את כמות הסיבים המשמשים בין בניינים, ניתן:
        • שימוש בפונקציונליות הערימה של מתגי גישה x440-G2 - תוך שימוש בסיב SMF אחד לכל מתג בקומה, מה שיאפשר שימוש ב-1 סיבים ופורטים בכל צד במקום 6 סיבים ופורטים
        • השתמשו בשני סיבים כדי לחבר את המתג הראשון בענף ואת האחרון. צברו קישורים על מתגי גישה לקצה והשתמשו בפרוטוקולי STP בטבעת שנוצרת.

      כתובת IP

      כאן אתן חישוב משוער של כתובת עבור התוכנית שלנו.

      כרגע יש לנו מספר רשתות מסוג B - 172.16.0.0/16. בעת חישוב מרחב כתובות ה-IP, אשתמש בשיקולים הבאים:

      • 4 הביטים של האוקטט השני ייצגו את הבניינים - 172.16.0.0/12.
      • אוקטט 3 יציין את מספר הקומה בבניין.
      • 3 אוקטטים = 255 יוקצו לקישורי נקודה לנקודה של ציוד ורשת בקרה.
      • VLAN ניהולי אחד לכל קומה לניהול מתגים.
      • VLAN של משתמש אחד לכל מתג (24 פורטים בממוצע).
      • VLAN קולי אחד לכל מתג (24 פורטים בממוצע).
      • VLAN אחד למערכת מעקב וידאו לכל קומה.
      • VLAN אחד עבור התקני Wi-Fi בכל קומה.

      קיבלתי טבלאות שנראות בערך כך:
      רשת 172.16.0.0/14
      רשת 172.20.0.0/14

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

      למעשה, בחירה ברשת האפורה 172.16.0.0/12 אינה האופטימלית ביותר, מכיוון שהיא מגבילה אותנו במספר הרשתות (מ-16 עד 31) עבור בניינים, וישנם גם משרדים מרוחקים שגם הם צריכים לחתוך בלוקים של רשת, אולי אפשרות אופטימלית יותר תהיה שימוש ברשתות 10.0.0.0/8, או שימוש משותף ברשתות 172.16.0.0/12 (לדוגמה, עבור צרכי שירות ושרתים) ו-10.0.0.0/8 (עבור רשתות משתמשים).

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

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

      למרות זאת, ראוי לציין בנוגע לשתי הנקודות הראשונות שהקיבולת של נתבים מודרניים גבוהה בהרבה מאלה שלפני 2-15 שנה ומאפשרת להם להכיל טבלאות ניתוב גדולות בזיכרון ה-RAM שלהם, והיחס בין המחיר לרוחב הפס של ערוצי התקשורת ירד בהשוואה למחירים של תקופות השימוש הנרחב בזרימות E20/T1 (G.1).

      מסקנה

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

      • ארגון גבולות הארגון (וזה סיפור נפרד עם מתגים, גבולות, חומת אש, מערכות IPS/IDS, DMZ, VPN ועוד)
      • ארגון רשת Wi-Fi
      • ארגון רשתות VoIP
      • ארגון מרכז הנתונים
      • אבטחה (וגם זה עולם נפרד, שמבחינת נפח ודרישות אינו נופל מתכנון של תשתית רשת נקייה, ולפעמים אף עולה עליו)
      • הנדסת חשמל
      • הרשימה עוד ארוכה

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

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

      זה רחוק מלהיות המאמר האחרון בנושא רשתות אקסטרים, אז הישארו מעודכנים (טלגרם, פייסבוק, VK, בלוג פתרונות TS)!

מקור: www.habr.com