VMXNET3 כנגד E1000

בקטגוריות: וירטואליזציה

18 מאי 2012

חלק מתהליך בניה של מכונה וירטואלית צריך להיות מוקדש לרכיבים הוירטואליים השונים. בבואנו ליצור מכונה, או להוסיף לה כרטיס רשת – נצטרך לבחור בסוג הכרטיס שיותקן במערכת ההפעלה. גרסת vSphere 4 ואילך מאפשרת לנו בחירה בין שלושה סוגים של כרטיסים -
E1000, VMXNET2, VMXNET3

add new hardware

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

סוגי הכרטיסים:

  • E1000 – מבוסס על צ'יפסט קיים (של אינטל). הוא מאוד נפוץ, ובמרבית מערכות ההפעלה לא ידרוש דרייבר נוסף. הוא כלול במערכות Windows XP 64-Bit ומעלה, וב-Linux 2.4.19 ומעלה.
  • VMXNET2 – הגרסה השניה של הדרייבר VMXNET, שנכתב במיוחד לשימוש בסביבה הוירטואלית, תוך דגש על תאימות לצורת העבודה היחודית בסביבה זו. השימוש בדרייבר זה יתאפשר בגרסאות ESX 3.5 ומעלה, הדרייבר כלול בחבילת VMware Tools.
  • VMXNET3 – הדור האחרון של הדרייבר VMXNET, למרות שאין קשר ישיר בניהם. הדרייבר נכתב מחדש כשיעודו לסביבה הוירטואלית בהתחשבות בביצועי רשת מקסימליים, ובשימוש מינימלי במעבד. אפשרי בגרסאות ESX 4 ומעלה, בגרסת חומרה 7 (Hardware version 7) לפחות, כלול בחבילת VMware Tools.
    מערכות הפעלה נתמכות כוללות את:
    גרסאות 32Bit / 64Bit של Microsoft Windows XP,7, 2003, 2003 R2, 2008, 2008 R2
    גרסאות 32Bit / 64Bit של Red Hat Enterprise Linux 5.0 ומעלה
    לגרסאות נוספות ניתן להיעזר במסמך KB של VMware לבחירת כרטיס רשת וירטואלי
    המשך קריאה »

VMware הכריזו לא מזמן על הגרסה החדשה בתשתית הוירטואליזציה שלהם, vSphere 5.0. כצפוי, גרסה זו מביאה מס' פיצ'רים חדשים, אך מה שנראה שמעורר הרבה רעש בקרב הלקוחות, היא שיטת הרישוי החדשה.
שיטת הרישוי הישנה (בגרסאות Standard ומעלה), התבססה על כמות המעבדים הפיזיים (Socket) תוך הגבלת מס' הליבות ל-12 בגרסאות הרישוי Advanced, Enterprise Plus והגבלה ל-6 ליבות בשאר הגרסאות. כמו כן, הייתה הגבלה על כמות הזיכרון (RAM) המקסימלית להוסט, שעמדה על 256GB, חוץ מגרסת Enterprise Plus שלא הייתה מוגבלת.

vSphere 4 Core / RAM limits

עם כניסת מגמת ריבוי הליבות בקרב יצרניות השבבים, רבים מהצרכנים נתקלו בתקרת הרישוי שלהם – 6 ליבות בלבד למעבד. מצב זה הפך את שדרוג התשתית הוירטואלית תוך שמירה על הרשיונות הקיימים, לבלתי אפשרי.
מצד שני, VMware לא קיבלה תשלום נוסף על שדרוגי תשתית הכוללים ליבות / RAM של בעלי רשיונות Enterprise Plus.

ב- vSphere 5.0 בוטלה לחלוטין מגבלת הליבות למעבד ומגבלת ה-RAM להוסט, לכלל הרשיונות המתומחרים לפי מעבד (Essentials, Essentials Plus מגיעים בקיט, בדומה לגרסה הקודמת). כמו שניתן לראות במסמך הרישוי הרשמי של vSphere 5.0 – בנוסף לתמחור לפי מעבד, נכנס חישוב נוסף לתמונה – vRAM, כמות הזיכרון שמוגדרת למכונה וירטואלית פעילה. החישוב יתבצע כך: לכל מעבד פיזי תוצמד זכאות שימוש בזיכרון, ע"פ רמת הרישוי השונה (ראו תמונה).

vSphere 5 Core / RAM limits

ה-vSphere vCenter יהיה אחראי על ריכוז וחלוקת זכאות הזיכרון הנרכש, גם אם מדובר במס' שרתי vCenter שעובדים ב-Linked Mode. מתוך מאגר כמות הזיכרון, תופחת כמות הזיכרון שהוקצתה למכונה פעילה – דולקת.
יש לשים לב שגרסאות Standard, Enterprise, Enterprise Plus לא ימנעו הדלקה של מכונה שהביאה לחריגה בכמות הזיכרון הכוללת שהוקצתה, אלא יקפיצו אזהרה בלבד. גרסאות Essentials, Essentials Plus לעומת זאת – לא יאפשרו הדלקה כאשר כמות הזיכרון שהוקצתה תחרוג מהמכסה.


(באדיבות thinkcloud.nl)

מס' לקוחות התלוננו אודות כמות הזיכרון הנמוכה עם חשיפת שיטת הרישוי החדשה. VMware ענתה בתגובה שכמות הזיכרון חושבה בהתאם לממוצע הנמצא בשימוש עם מערכת vSphere 4. לדבריהם, יחס הקונסולידציה הממוצע הוא 5:1, ז"א 5 מכונות וירטואליות מוקצות לכל מעבד פיזי. בנוסף, 3GB מוקצים בממוצע למכונה – לדבריהם. חישוב המערכת הממוצעת ע"פ VMware מביאה אותנו לצריכה של 15GB זיכרון. היות וכמות ה-vRAM המינימלית שמוקצית למעבד היא 24GB, יש מקום לשדרוג ולהתפתחות, לרוב הלקוחות.

עם השקת הגרסה החדשה vSphere 5.0, תספק VMware מחשבון ללקוחותיה המיועד לקבוע האם יהיה צורך ברשיונוות נוספים במערכות של vSphere 4 הנמצאות בשימוש. אם אתם רוצים לקבל אומדן אודות כמות הרשיונות, תוכלו להשתמש במחשבון רישוי vSphere 5.0, או בסקריפט PowerShell לחישוב צריכת vRAM נוכחית.

 

עדכון 03/08/2011:

VMware מודיעה בבלוג שלה כי לאור דרישת הלקוחות היא מבצעת שינויים במודל הרישוי, ובהקצאת כמות ה-vRAM.

הכמות תגדל ב-33% לרשיונות הבסיס, ותכפיל את עצמה (עד 96GB) ברשיונות Enterprise Plus. בנוסף, רשיון Free vSphere Hypervisor, יגיע עם הגבלה פיזית ל-32GB (פי-4 מההגבלה הקודמת).

בניגוד למערכות וירטואליזציה אחרות כגון Hyper-V ו-XenServer, לצורך בניית שרת ESXi נצטרך לרוב לקנות חומרה חדשה. זה יכול להסתכם בקניית כרטיס רשת נתמך לחומרה קיימת, אך על מנת לנצל את מלוא האפשרויות המוצעות ע"י המערכת הוירטואלית, נוכל גם להגיע לקנייה של שרת שלם. שרת ESXi מגיע עם תמיכה ודרייברים לחומרה המוגדרת מראש ע"י VMware. התמיכה בהתקנים אלו מצומצמת בגלל תכונות ההתקנים, והצורך של ESXi לספק בביצועים גבוהים למערכות ההפעלה המתארחות. ניתן להתקין דרייברים להוסט מסוג ESX, אך לעשות דבר דומה ל-ESXi יהיה יחסית מסורבל. כמו כן, הפעולה אינה נתמכת ע"י VMware.
לקבלת רשימת חומרה מומלצת ומאושרת ע"י VMware ניגש אל ה-Hardware Compatibility List (או: HCL), ונבצע חיפוש לרכיב החומרה / לשרת עליו נרצה להתקין את ה-Hypervisor. חומרה אשר אינה מופיעה ב-HCL, אינה מאושרת ע"י VMware, אך אין זה אומר שהיא לא תתפקד בצורה מלאה. ניתן לבצע חיפוש ממוקד לבדיקה האם רכיב מסויים נתמך, או להיעזר בקישורים שיובאו בפסקאות הרלוונטיות.

מדריך זה מיועד בעיקר לאנשי מחשבים המעוניינים לבחון את המערכת הוירטואלית ש-VMware מציעים, בהתקנת ESXi למטרות לימוד, בדיקת תאימות עם מערכות קיימות, או ריבוי שרתים בסביבת העבודה. במדריך נסקור את שוק החומרה הנוכחי והיישומים שלו בבניית מערכת ESXi 4.x, שלא תוך שימוש בשרתים מותגיים (IBM, Dell, HP), אלא בבחירת חומרה, והרכבת שרת מותאם אישית (Whitebox). לבסוף נענה על השאלה האם אפשר להתקין שרת ESXi על לפטופ?

רכיבי המערכת:

* מעבד - לרוב, זה יהיה הרכיב הראשון שנבחר. מלבד התמיכה ההכרחית בארכיטקטורת 64Bit, נחפש מעבד עם תמיכה חומרתית בוירטואליזציה, שתיתן לנו להגיע לביצועים אופטימליים. טכנולוגיה זו נקראת Intel VT-x / AMD-V, אצל 2 יצרניות המעבדים הגדולות. מכיוון שעיבוד מקבילי הוא הכרחי כאשר מס' מערכות הפעלה עובדות זו לצד זו, נשאף לבחור במעבד עם מס' ליבות / נימים (HT) גבוה ככל שיאפשר לנו התקציב. מומלץ לבחור מעבד מרובע (בעל 4) ליבות ומעלה, מאחר ועלותם בימינו אינה גבוהה. אם נבחר במעבד מסדרות השרתים, הרי שהאופציה (המבורכת) לריבוי תושבות מעבדים נכנסת לפרק.
עלות ורמת ביצועים גבוהה: מעבדים מסדרות השרתים – Opteron של AMD או Xeon (ובעברית, בבקשה: זיאון) של Intel המגיעים עם תמיכה בריבוי מעבדים, ובזכרונות עם תכונות ECC.
עלות ורמת ביצועים ממוצעת: מעבדים מרובעי ליבה – החל ממעבדי Q6600 החלוציים, ועד i5/i7/X4 של ימינו.

המשך קריאה »

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


 

 

תפקידים מרכזיים:

* VMware Tools מכילה דרייברים חיוניים לחומרה הוירטואלית - בהם הדרייברים של מתאם הרשת, כרטיס המסך, התקני האכסון, והעכבר. בניגוד לשאר ההתקנים, התקנים ספציפיים אלו משתמשים בדרייברים יחודיים המאפשרים ביצועים גבוהים יותר, ובינהם: VMXNET3, LSI Logic SAS, VMware SVGA 3D. מטרה נוספת של הדרייברים היא לאפשר לנו עבודה יותר נעימה אל מול ה-Console – העכבר יגיב בצורה טובה, ולא נצטרך להשתמש בשילוב Ctrl+Alt על מנת להוריד את הפוקוס מחלון ה-Console.

* סנכרון שעון – ביכולת VMware Tools לגשת אל ההוסט, ולבצע סנכרון שעון דרכו (כשהוא מסתכרן מול NTP). אם מעוניינים ברמת דיוק גבוהה, יש להגדיר סנכרון ישירות מול שרת NTP למערכת ההפעלה הוירטואלית, אך אין זה מומלץ להשתמש בשניהם.

* High Availability Monitoring - תפקיד חשוב מאוד, אך לעיתים נסתר מן העין הוא שליחת הודעות Heartbeat אל שרת ה-vCenter. כאשר יכולות ה-HA מופעלות, שרת ה-vCenter משתמש בהודעות אלו כאינדיקציה לפעילות תקינה של מערכת ההפעלה הוירטואלית. כאשר לא מתקבלות הודעות אלו – יוגדר מצב "כשל" למכונה הוירטואלית, והיא תאותחל. דגש חשוב: ההודעות אל שרת ה-vCenter אינן נשלחות דרך כרטיס הרשת, אלא מועברות ישירות דרך ההוסט. משום כך לא ניתן לנטר כשלים ברמת התקשורת דרך הודעות ה-Heartbeat, ואין לבצע בדיקה של תשתית ה-HA ע"י ניתוק כבל הרשת, מכיוון שזה פשוט לא יעבוד (רוצים לגרום למסך כחול BSOD למטרת בדיקה?).

* ניהול זיכרון – ישנן מספר טכניקות בהן משתמש ה-Hypervisor לניהול מתקדם של זיכרון. אחת מהטכניקות מצריכה קיום של VMware Tools, ודרייבר vmmemctl מותקן על המערכת. טכניקה זו נקראת Memory Ballooning. מאחר ומערכת ההפעלה לא תמיד מפנה זיכרון שלא נמצא בשימוש, יכול להיווצר מצב שבו כמות הזיכרון הזמינה לשימוש ההוסט, ולחלוקה למכונות הוירטואליות – נמוכה. כאשר ההוסט מגיע למצב זה, הוא נותן הוראה "לנפח" את הרכיב שיושב בזיכרון המכונה הוירטואלית, ולגרום ל-Clean Up עצמי של מערכת ההפעלה, ולפינוי זיכרון שאיננו בשימוש.

* כיבוי והפעלה מחדש – התקנת VMware Tools תוסיף לנו את האפשרות לכבות את מערכת ההפעלה האורחת בצורה מסודרת, ע"י פקודת Shutdown / Restart.

המשך קריאה »

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

לפני שלושה חודשים, 2/2011, הכונן ננעל סופית, ולא הייתה לי גישה לנתונים כלל – בחיבור ללוח האם, למחשב אחר, או בחיבור חיצוני ל-USB. בדיקה שביצעתי באתר Seagate באמצעות המס' הסריאלי של הדיסק הקשיח הבהירה לי שהכונן עדיין באחריות. נשמתי לרווחה. מכיוון שלא זכרתי מאיזו חנות קניתי את הדיסק הקשיח, יצרתי קשר עם נציגות סיגייט בארץ, והיבואן הרשמי של ההארדיסק שהיה ברשותי, CRG Electronics. שוחחתי עם אחד מאנשי השירות שלהם, והסברתי לו את הבעיה. הוא אמר כי "הוא לא מכיר בשום בעיה בסדרת קשיחים אלו"*, וכי CRG לא תוכל לעזור לי במקרה זה. הוא אף אמר שהיחידים שיכולים לסייע לי בשחזור המידע הם מעבדה לשחזור מידע.
מכיוון שלא הייתי מעוניין להשקיע מאות שקלים בשחזור המידע, החלטתי לוותר על החומר, אך עדיין הייתי מעוניין להחליף את הדיסק במסגרת האחריות. גם כאן ידיה של CRG היו קצרות מלסייע, והפנו אותי לקישור מימוש אחריות. התהליך פשוט -

  1. הרשמה ומילוי פרטים באתר Seagate.com הכוללים – פרטים אישיים, כתובת, פרטי דיסק קשיח ותקלה.
  2. משלוח הדיסק הקשיח התקול לכתובת בארץ, והעברתה על ידם למרכז השירות באירופה.
  3. קבלת דיסק קשיח בחזרה אל הכתובת שצויינה, לאחר בחינת הדיסק שהתקבל במרכז השירות.

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


שבוע וחצי לאחר מכן, הודיע לי שליח DHL אודות חבילה שמחכה לי, ושקבלתה מותנית בתשלום של 101 ש"ח. זה היה נשמע לי קצת תמוה, אבל ביקשתי לקבל את פירוט התשלום, על מנת להסביר ל-DHL / מכס שזהו כונן שהתקבל במס' האחריות, ולשחרר את החבילה ללא תשלום. החשבונית נראתה כך:

המשך קריאה »

ביולי 2010, עם השקת vSphere 4.1, הודיעה VMware כי מהגרסה הבאה תופץ המערכת עם ESXi בלבד. גרסאות חדשות ל-ESX יצאו לאורך הפצת vSphere 4.1 בלבד. באותה הכרזה ביולי, המליצה VMware לחברות להיערך לקראת המעבר, על כל הכרוך בו – להתקין ESXi להוסטים חדשים, ולתכנן הגירה ומשמעויות להוסטים קיימים מבוססים ESX.

החודש, 05/2011 הוסר הקישור להורדת VMware ESX 4.1 מעמוד ההורדות הראשי של מערכת vSphere. בכך אותתו VMware לציבור הלקוחות שלהם על השינוי המתוכנן, והמעבר ל-Hypervisor אחיד. מי שיחפש היטב ימצא קישור לעמוד צדדי להורדת ESX, אך לא נדרש יותר מזה כדי להבהיר את רצינות המהלך. לאחר מס' ימים של סערה קטנה בקרב קהילת VMware, הוחזר הקישור לעמוד ההורדות הראשי, והוא כרגע נמצא בתחתית העמוד.

עם המעבר של VMware לאסטרטגיה שנותנת את מירב אפשרויות הניהול למרכז השליטה (vCenter, vCloud Director), הבינו ב-VMware כי ESX, עם ההגדרות שלו, ה-Agents השונים, והדרייברים המותאמים אישית כבר לא תואם את ראייתם העתידית, ולא ישתלב היטב במערך החדש. ארגונים שמסתמכים על ESX והאפשרויות השונות הייחודיות לו, צריכים ללא ספק להתחיל לשקול את אפשרויות ההגירה שלהם, עם המעבר ל-ESXi קל המשקל.

ברוב המקרים, החשש מ-ESXi נובע מחוסר ידע. מכיוון שב-VMware ידעו שהוא גורם לבלבול לעיתים עם המוצר ESXi Free (שניתן עם פיצ'רים מוגבלים), שונה שמו של ESXi Free ל-VMware Hypervisor. מי שמעוניין לקרוא מה יש ל-VMware להגיד על ההבדלים האמיתיים בין ESX ל-ESXi, מוזמן לקרוא. מי שמעוניין בתקציר, הנה הוא מובא לפניכם: מעבר להסרת ה-Service Console, אין שוני ממשי בין גרסאות ESX/i. הגרסה ברשיון תקבל את כל האפשרויות המתקדמות, תיתן ביצועים כמעט זהים, ותהיה בעלת חתימת אבטחה קטנה יותר שתדרוש פחות עדכונים (95% מהעדכונים שיצאו ל-ESX היו קשורים לאבטחת ה-SC).

המשך קריאה »

מיקרוסופט, שבתחילה (Windows Hyper-V Server 2008) הציגה מוצר וירטואליזציה שלא היה מתאים ללחברות גדולות בגלל חוסר ב-Clustering, Live Migration, HA – הגיעה לרמת Enterprise לאחרונה, עם השקת Windows Hyper-V Server 2008 R2, ולאחריו SP1. ההתפתחות הרבה במוצר הוירטואליזיצה של מיקרוסופט – Hyper-V, מחייבת מאנשי ה-IT בכלל, וממומחי הוירטואליזציה וה VMware בפרט, להכיר את המוצר הזה. בפוסט זה אנסה לעזור לאנשי ה-VMware לעשות את המעבר הנחוץ הזה, לסביבת Hyper-V.

Hyper-V של מיקרוסופט מגיע בשתי תצורות – האחת, במוצר עצמאי בשם Microsoft Hyper-V Server 2008 /R2 המופץ בחינם. ממשק העבודה במערכת זו הוא בעיקר באמצעות CLI, ולא ניתן להוסיף Features / Roles למערכת זו. השליטה על המכונות הוירטואליות מתבצעת ממחשב נפרד, באמצעות הרחבת MMC עם Hyper-V Manager במערכות הפעלה Windows 2008 / 7 או ע"י SCVM.
התצורה השנייה היא כ-Role במערכת ההפעלה Windows Server 2008 /R2 המאפשרת שימושים נוספים במערכת הפעלה המארחת. השליטה במכונות הוירטואליות תתבצע דרך מערכת ההפעלה המארחת, או ע"י MMC / SCVM.

המשך קריאה »

Backup Exec הוא מוצר גיבוי שעבר לא מעט חברות וגרסאות, עד אשר הגיע לגרסה המודרנית שלו. בין השנים 1999-2005 המוצר היה ברשות חברת Veritas. גרסאותיו האחרונות, משנת 2005 ואילך – הן של חברת Symantec שרכשה את Veritas. בשנת 2005 יצאה גרסת Symantec Backup Exec 10d ומאז, סימנטק הוא בית התוכנה האחראי על המוצר.

התוכנה מיועדת לביצוע גיבוי למחשבים בסביבת Windows / Linux, בשוק העסקים בגודל בינוני הכולל מס' רב של שרתים ועמדות קצה.

בתוכנה Backup Exec, מערכת הגיבוי מורכבת ממס' חלקים מרכזיים:

  • Media Server – לב המערכת. שרת מבוסס ווינדוס, השולט על כלל משימות הגיבוי, ומנהל את בסיס הנתונים.
  • Storage Devices – החלק/ים המשמש/ים לאכסון הגיבויים – HDD, SAN, Tape.
  • Workstation / Server Agent – רכיב המותקן בכל מערכת הפעלה המשתתפת בגיבוי.
  • Administration Console – עמדת השליטה על ה Media Server, קובעת פעולות ברירת מחדל, מנהלת את ההתקנים, מריצה אשפים. ניתן להריץ אותה ממחשב אחר, או מהשרת עצמו.

המשך קריאה »

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

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

השוואה בין קוראי ספרים אלקטרוניים

אודות חי בעולם וירטואלי

מכירים את זה שאתם חייבים לשתף מישהו בדברים שמעניינים אתכם? זאת כל המטרה כאן.