Open Virtualization Format וניהול סביבות וירטואליות הטרוגניות

10 באוגוסט 2008

אין תגובות

מכונות וירטואליות נעשות שכיחות יותר ויותר במרכזי המחשוב השונים, בהתאם לכך אנחנו עדים להתפתחות חזקה מאוד בתחום שרתי הוירטואליזציה, למעשה שרתי ה Hypervisor. סקירה קצרצרה של החבורה – VMware עם משפחת ה ESX, מיקרוסופט עם ה Hyper-V הדנדש, Citrix עם XenServer, אורקל, Sun, Parallels ועוד. פרט ל Citrix ומיקרוסופט אשר החליטו על אימוץ פורמט ה VHD של המכונות הוירטואליות במוצרים של שתי החברות – כהמשך ישיר של שיתוף הפעולה הרחב שלהן גם ככה – לא קיימת שום תאימות בין המוצרים השונים וככה מי שרוצה להטמיע מוצרי וירטואליזציה שונים בסביבה שלו נאלץ להשתמש בכלים צד שלישי בכדי לעשות את ההמרה בין הפורמטים השונים (זאת בהנחה כמובן שיש כלי להמרה בין הפורמטים הרלוונטיים וההמרה באמת גם עובדת בסופו של דבר).

כתגובה לדרישות הלקוחות – כן, אהה… – התאספו להן VMware, Xen Source, Dell, HP, IBM ומיקרוסופט כדי לחשוב מה אפשר לעשות בסוגיה, אחרי דיונים מרתוניים (ביל, שוב פעם הבאת בורקסים תפוח אדמה, כבר פעמיים אמרנו שאנחנו אוהבים גבינה) נולד לו ה OVF או Open Virtualization Format. אבל ניקח את הדברים בריצנות לשניה, סטנדרטיזציה של פורמט כזה היתה חייבת להיעשות בעיקר עקב הגדילה של ה Virtual Appliances.
Virtual Appliance הוא עוד תת תחום של הוירטואליזציה שהולך וגודל ויש הטוענים שהולך לשנות את איך שארגונים יעשו שימוש באפליקציות הארגוניות שלהן ואיך שספקי האפליקציות יספקו את אותן האפליקציות.
התצורה הוירטואלית של ה- Appliance שכולנו מכירים עכשיו – אותו רכיב חומרה המכיל אפליצקיה מסוימת אחת (או כמה) אשר רצה על מערכת הפעלה מותאמת במיוחד לאפליקציה (בד"כ היא בעיקר מופשטת מ features שאין בהם צורך) –  מאפשר לארגונים לא להתעסק יותר מדי בהטמעות מיוחדות לשם הפעלת האפליקציות וכמובן גם מאפשר לספקי האפליקציה להכין את הבסיס הטוב ביותר לאפליקציות שלהן.

קצת סדר בדברים, אותה ההחלטה של Citrix ומיקרוסופט על שימוש בפורמט ה VHD במוצרי הוירטואליצזיה של שתי החברות מתייחסת על פורמט הדיסקים הוירטואליים שנעשים בשימוש במוצרים, ממש כמו VMDK במוצרי VMware ו- VDI ב- Sun. ה OVF מתייחס לפורמט המכונה הוירטואלית כולה, או למעשה להגדרות השונות של המכונה, שדיסקים הוירטואליים הם רק אחד המאפיינים הכלולים בה.
הפורמט החדש מכיל את כל הגדרות החומרה של המכונה הוירטואלית. מעבד, זיכרון, רשת, התקני איחסון וכו'. כל ההגדרות האלה נשמרות בפורמט xml (קטע, ממש כמו במוצרים של Sun) אשר ייקרא על ידי אותם המוצרים אשר ייתמכו ב OVF ולאט לאט כל חברה מתחילה לתמוך בעניין.
לדוגמא Citrix הכריזה לא מזמן על פרוייקט קנשו (Project Kensho) אשר מיועד לנהל את אותן ה Virtual Appliances וכמובן יעבוד עם ה OVF, חלק מהיכולות שלו הן אופציה ל export של המכונות הוירטואליות מ- VMware, XenServer ו- Hyper-V ולעשות import ל XenServer ול- Hyper-V, והוא אפילו הולך להיות חינמי לגמרי.

ואם בתאימויות בין ה Hypervisors השונים עסקינן אז אין כמו לדבר על הניהול של כל הסביבה הוירטואלית, בייחוד כשמדובר על סביבות וירטואליות הטרוגניות, או בעצם סביבות בעלות יותר ממוצר Hypervisor אחד. והרי ברור שזה מה שהולך להיות בסופו של דבר, רוב הארגונים יבחרו לעבוד לפחות עם שני מוצרי וירטואליזציה שונים בסביבה שלהם. ואם ממשיכים בקו הזה – שיהיה צורך לנהל לפחות שני מוצרי וירטואליציה – הארגונים יידרשו מוצרי ניהול התומכים בכל אותן הסביבות – ד"א משהו לא כ"כ נפוץ עד עכשיו, עד כה כל חברה סיפקה מוצר ניהול לאפליקציות שלה וככה כל מנהל רשת ממוצע היה צריך להחזיק עשרות מוצרי ניהול לכל מוצר העובד אצלו בארגון – אז לפחות במוצרי הוירטואליזציה נעשה ניסיון לעשות שינוי, XenCenter של Citrix וגם SCVMM של מיקרוסופט תומכים גם ב Hyper-V גם ב XenServer וגם ב VMware ESX. מה שמעניין בכל הסיפור הזה שדווקא VMware לא מספקת שום מוצר ניהול שתומך במוצרים נוספים פרט ל ESX, לא מפתיע כ"כ, כולנו מכירים את היהירות המסויימת שלהם (מה שמפחיד קצת יותר שהיא נדבקת גם באלה המנסים לקדם אותם) והעמדה הרשמית שלהם היא שבנתיים הם לא רואים את הצורך הזה אצל הלקוחות שלהם. נו באמת, תעשו לי טובה.
אז כל עוד אין מענה לסוגיה מצד VMware הלקוחות שלה (כן, אלה בדיוק שאין להם את הצורך לפי VMware) הולכים לחפש את הפתרונות במקומות אחרים, אם זה SCVMM שנמצא בנתיים בבטא, אם זה XenCenter של Citrix ואם זה חברות קטנות יותר כדוגמת Hyper9 שנכון לעכשיו מספקים מוצר ניהול רק ל ESX אבל כבר עובדים על מוצר שיעבוד עם שלושת הגדולים.

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *