מתגי מרכז הנתונים של PicOS: EVPN ומדריך שדרוג

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

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

PicOS Switch vs PicOS NOS vs AmpCon-DC: What You Are Actually Choosing

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

• חומרת המתג- פלטפורמות רשת פתוחות ("תיבה לבנה" או "תיבה לבנה"), הבנויות בדרך כלל על סיליקון Broadcom. דוגמה נפוצה למרכז נתונים היא מתג 1U עלים או עמוד שדרה כגון N8550-32C, עם 32 x 100G QSFP28 יציאות ב- Broadcom Trident 3 ASIC. ה-ASIC, מהירויות היציאה והמאגר קובעים את הגבולות הקשים של מה שהקופסה יכולה לעשות.
• מערכת ההפעלה של רשת PicOS- הPicOS NOS מ-Pica8, בנוי על ליבת Debian Linux ללא שינוי. הוא מספק את מחסנית שכבה 2/שכבה 3, EVPN-VXLAN, MLAG, אבטחה וטלמטריה פתוחה (SNMP, sFlow ו-gNMI). ה-NOS, בתוספת הגרסה ושכבת הרישיונות שלו, קובעים אילו תכונות זמינות בפועל.
• AmpCon-DC- בקר הניהול והאוטומציה. הוא מטפל בהקצאה אפס-מגע (ZTP), תצורה מונעת-תבניות, גילוי טופולוגיה, טלמטריה, שדרוגים ואימות לאורך כל מחזור החיים, מתכנון יום 0 ועד פעולות יום 2+.

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

מדוע ארגונים מעריכים את PicOS עבור מרכזי נתונים

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

טיפול בתנועה מזרח-במערב עם עלה-עמוד השדרה

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

צמצום נעילת הספק-ב- וכיצד זה עובד בפועל

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

אוטומציה של יום 0 ליום 2+ עם AmpCon-DC

CLI ידני נסבל עבור קומץ מתגים ומסוכן בין עשרות או מאות. AmpCon-DC הוא המקום שבו PicOS מרוויח הרבה מהערך התפעולי שלו: ZTP onboarding, תבניות תצורה מבוססות Jinja-, ספרי משחק של Ansible וממשקי API של REST מפחיתים עבודה חוזרת וסחיפה של תצורה. המטרה היא לא אוטומציה לשמה - היא הפעלה חוזרת, שינוי שניתן לביקורת ושחזור מהיר יותר.

יכולות מפתח להערכה

מוכנות EVPN-VXLAN ו-IP Fabric

בדים מודרניים בדרך כלל מאריכים את שכבה 2 על פני שכבה 3 מנותבת תוך שימוש בשני סטנדרטים יחד:VXLAN, אנקפסולציית שכבת העל המוגדרת ב-RFC 7348, וEVPN, מטוס הבקרה המבוסס-BGP המתוקנן ב-RFC 7432. כאשר דגם המתג וגרסת PicOS תומכים בו, ניתן להעריך את PicOS עבור בדי עמוד השדרה-ניתנים להרחבה המשרתים סביבות מרובות-שדרות וירטואליות ובסגנון-ענן. התייחס לתמיכה ב-EVPN-VXLAN כגרסה- ודגם-ספציפית, ואשר אותה מול הפלטפורמה המדויקת שאתה מתכוון לקנות.

MLAG וזמינות גבוהה

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

תכנות וטלמטריה

מתג מרכז נתונים צריך להיות ידידותי לאוטומציה כברירת מחדל.- PicOS חושף ממשקים מבוססי Ansible, Python וסטנדרטים-, ומספקת נראות באמצעות טלמטריית זרימת SNMP, sFlow ו-gNMI. התמורה המעשית היא עקביות: תצורות תבניות, ניטור בסיסי וזיהוי סחיפה על פני כל המרקם.

ניהול מחזור חיים ונראות

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

PicOS לעומת NOS סגור לעומת NOS קהילתי

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

תרחישי ההתאמה-הטובים ביותר-המתאימים ביותר

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

התאמה חזקה כאשר:

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

פחות מתאים כאשר:

• לצוות אין יכולת אוטומציה ואין תוכנית לבנות אותו.
• אתה תלוי מאוד ב-TAC של ספק יחיד עבור הפעולות היומיומיות-ל-היום.
• אין יכולת -לאמת את הבד לפני הייצור.
• החומרה המועדפת או ערכת התכונות הנדרשות אינן במטריצה ​​הנתמכת.

מקרי שימוש נפוצים

שדרוגים של 10G/25G עד 100G

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

עלים-בדי מרכז הנתונים של עמוד השדרה

מתגי עלה מחברים שרתים ואחסון; מתגי עמוד השדרה מספקים את הבד המהיר- בין העלים. PicOS מתאים לתפקידים אלה כאשר המהירויות, ספירת היציאות ותכונות הניתוב תואמות את העיצוב. כבלים מובנים הופכים את התכנון ל- הרבה יותר נקיתא מטען MPO/MTP וכבלים לפריצהמלפנים שומר על חיבורי-עלים-ל-גבוהים-ניתנים לניהול ככל שהבד גדל.

Data Center Gateway ו-Interconnect

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

AI, HPC, ו-Lossless Ethernet

בדי AI ו-HPC הם לא רק רוחב פס גולמי. תעבורת RDMA (RoCEv2) זקוקה למארג Ethernet נטול אובדן או כמעט -ללא הפסדים, התלוי בבקרת זרימה כגון PFC ואיתות גודש כגון ECN, בתוספת מאגרי מתג נאותים וטלמטריה נקייה. מתגי מרכז הנתונים של PicOS תומכים בהובלה ללא הפסדים מבוססי PFC/ECN-על פלטפורמות תואמות, ועיצובים ברוחב פס גבוה- משתמשים יותר ויותר בממשקי 400G - בעת תכנון קישורי עמוד שדרה או GPU-על בד, אשר את האופטיקה וגורם הצורה, כולל400G QSFP-DD. אמת את התנהגות הגודש, גודל המאגר ותאימות NIC מול עומס העבודה הספציפי שלך לפני התחייבות.

כיצד לתכנן פריסת PicOS

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

שני פריטים ברשימה זו גורמים לעיכובים הנמנעים ביותר. ראשית, החליטו על הגישה לשרת בינוני מוקדם: האם לבצע סטנדרטיזציהאופטיקה של 10GBASE-T או SFP+משנה את הנחות הכבלים, הכוח והטווח בכל מתלה. שנית, תכנן בכוונה את הכבלים לפריצת כבלים - למשל, פריצת יציאת 100G יחידה ל-4 x 25G קישורי שרת - באמצעות הימיןכבלים פריצת MPOכך שמפת הנמל והקצאות הסיבים מסתדרות לפני יום ההתקנה.

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

טעויות נפוצות שיש להימנע מהן

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

התעלמות מדרישות תכונה ורישיון NOS.מערכת ההפעלה, הגרסה שלה והרישיון שלה קובעים מה הרשת יכולה לעשות בפועל. אשר L2/L3, EVPN-VXLAN, MLAG, טלמטריה ואבטחה מול הפלטפורמה המדויקת לפני הקנייה.

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

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

האם PicOS מתאים למרכז הנתונים שלך?

מתגי מרכז הנתונים של PicOS מתאימים לארגונים שרוצים מארג ניתן להרחבה, אוטומציה-תפעול מוכן, מקורות חומרה פתוחים ומחזור חיים מובנה - במיוחד צוותים שמתכננים עיצובי עלים-שדרה, שדרוגים של 10G/25G ל-100G, EVPN-VXLAN מחליפים רקמות ידניות{8}או{7} אינו בר קיימא יותר. הם בהתאמה חלשה יותר כאשר אין יכולת אוטומציה, תלות קשה בתמיכה של{10} ספק יחיד, אין מעבדה לאימות מולה או חומרה מחוץ למטריצה ​​הנתמכת.

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