אז מה ההבדל בין המתגים הוירטואליים השונים בסביבת vmware?

בגרסא הבסיסת של כל ESX קיים מתג vSwitch הנקרא Virtual Standard Switch או בקצרה vSS.
היתרון של ה vSS הוא שכל מתג עצמאי לחלוטין בהיבט ההגדרות וכאן גם החסרון הגדול שלו - כל הגדרה צריך לבצע ידנית במתג שבכל שרת ובכך מעלים את הסבירות לטעות אנוש.

על מנת להתמודד עם בעיה זו ובעיות נוספות, vmware פיתחה מתג וירטואלי נוסף הנקרא Virtual Distributed Switch או בקצרה vDS.
היתרון המשמעותי של המתג הוא ביכולת הניהול המרכזי של כלל המתגים בסביבה באמצעות ה vCenter. שים לב ש vCenter מהווה Configuration Plane בלבד ולא Control Plane. זהו הבדל חשוב שנעמוד עליו ועל ההשלכות שלו כשנפרט לגבי Nexus 1000v.

בנוסף, למתג ה vDS ישנן תכונות נוספות המבדלות אותו מ vSS (פרט למחיר... מחייב רשיון Enterprise plus):

• ניהול מרכזי
• יכולות QoS מתקדמות כגון Shaping בכניסה וביציאה של כל פורט
• יכולת Security מתקדמות כגון Private VLAN
• מאפשר להתקין Nexus 1000v שמאפשר יכולות נוספות כגון NetFlow, ACL וכו'

מצד שני, ישנם גם חסרונות.

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

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

האופציה השלישית והאחרונה היא מתג Nexus 1000v עליו נפרט בפוסט נפרד.

להרחבת הנושא, מוזמנים לקרוא את מסמך ה VMware.

miercom

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

VDI products

השוואה בין מוצרי VDI על פי חברת הבדיקות miercom. הבדיקה מומנה על ידי citrix.

רוחב פס - בעבודה משרדית סטנדרטית (מיילים, מסמכים וכו׳) citrix מנצל 370kbps ואילו vmware מנצל 1.09mbps. בעבודה עם flash (סרטון ב youtube) היה הבדל גדול יותר - citrix ניצל 3mbps לעומת 29mbps של vmware.
תצוגת וידאו - בהשוואת vidMOS יש יתרון ל citrix עם ציון מקסימאלי 5 לעומת vmware עם ציון 3.

VSX vSwitch/vRouter Limitations

בארכיטקטורת VSX, ה vSwitch ו vRouter הינם מקומיים לשרת בו הם מוגדרים ואינם פרוסים על כל ה cluster. לכן, כאשר מעוניינים לבצע HA עבור VS בודד, ישנה מגבלה שלא ניתן לעשות זאת באחד המקרים הבאים:
1. אם ה VS מקושר ל vRouter
2. אם ה VS מקושר ל vSwitch שאין לו uplinks לרשת החוצה.

שילוב OSPF בארכיטקטורת VRF-Lite

כאשר מגדירים בנתב מספר VRF-ים בתצורת VRF-Lite עם OSPF, ממשק השייך ל VRF לא יקבל ניתובים מסוג LSA Type 3 או LSA Type 5 מבלי להפעיל את הפקודה capability vrf-lite תחת הגדרות ה OSPF.
פקודה זו משמשת לביטול תהליך בדיקות של נתבי PE בתצורת MPLS. הבדיקות המבוטלות הן:
1. לא בודקים down bit
2. לא בודקים זהות של domain-id

מומלץ להפעיל את הפקודה בכל מימוש של VRF-Lite בשילוב OSPF.

Service card conectivity issues in 6500

ישנה בעיה בתקשורת של service modules ב 6500 כאשר משתמשים ב etherchannel שיוצא משני כרטיסים שונים. הפתרון הוא להגדיר כתובת gw של נתב שאינו ה 6500 בו מותקן ה service module.

להלן קישור ל bug ב cisco.

Microsoft NLB

מנגנון cluster load balancing של microsoft.
הרעיון הוא שכל חבילה המיועדת ל cluster תגיע בו זמנית לכל השרתים. המטרה היא לאפשר שיקום מיידי במתאר כשל של שרת או של הרשת.

שני מצבי עבודה:

unicast mode- לכל שרת יש כתובת mac ייחודית משלו שאיתה הוא יוצא אל הרשת. כאשר ה cluster מקבל בקשת arp התשובה היא כתובת mac שאינה שייכת לאף אחד מהשרתים. המשמעות היא שהמתג יבצע flooding לתעבורה המיועדת ל cluster ולכן גם במקרה של כשל השיקום לשרת חלופי נעשה מיידית.

multicast mode - תשובה לבקשות arp הינה כתובת ethernet multicast. כל שרת מבצע igmp join לאותה כתובת כדי לאותת למנגנון ה igmp snooping במתג שהוא מעונין במידע. כתובת ה mac הפיזית של השרתים אינה כתובת ה ethernet multicast ולכן המתג לא לומד את כתובת ה mac דרך הפורטים של השרתים. בנוסף, גם אם השרתים היו עושים שימוש בכתובת mac זו, המתג היה מבצע mac flapping כי רואה את אותו ה mac במסר פורטים. הפתרון הוא להגדיר רשומות mac סטטיות במתג. ב 6500 נדרש גם לבטל snooping על הפורטים שאליהם מקושרים השרתים ב cluster.
בעיה נוספת היא שהנתב הסמוך ל cluster לא יחזיק רשומת arp תקינה כיוון שנתב cisco לא מסכים להחזיק רשומת arp דינאמית שכתובת ה mac הינה multicast. הפתרון הוא להגדיר רשומת arp סטטית.

vmware ממליצים על multicast mode.

 קישור למסמך של cisco בנושא.

FCoE in software

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

TOS to EXP mapping

שדה tos הנכנס לרשת mpls מועתק לשדה ה exp אוטומטית.
ביציאה מרשת ה mpls שדה ה exp אינו מועתק בחזרה לשדה ה tos.
ראה קישור.

link state tracking

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

הגדרות:

Switch(config)#link state track 1

interface GigabitEthernet1/0/1

link state group 1 upstream

interface GigabitEthernet1/0/2

link state group 1 downstream

well known networking timers

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