בפוסט הקודם דנתי במכולות / אזורי Solaris ולמה הם רעיון טוב. לסולאריס יש שכבת וירטואליזציה נוספת הנקראת Logical Domains או LDOMS. אורקל מיתגה אותו מחדש ל- 'Oracle VM Server for SPARC' אך ברוב הגורמים קל יותר לקרוא להם LDOM. מספיק עם המינוח. מה בדיוק אלו ומדוע תזדקק לשכבת וירטואליזציה נוספת?
LDaris של Solaris דומים יותר לווירטואליזציה באופן שבו VMware מספקת אותה. יש לך מכולות ייחודיות ומפולחות לחלוטין. אלה יכולים להריץ מערכות הפעלה שונות או גרסאות של Solaris. אם אתה זוכר ממאמר Solaris Zones, Non Global Zones (NGZ) חולקים את אותו גרעין של ה- Global Zone (GZ) המארח אותו. אתה יכול להריץ גרסה ישנה יותר של NGZ ב- GZ, אך זה נעשה באמצעות ספריית תאימות המדמה אותה. ה- LDOM מאפשר לך לקבל מופע ייחודי.
LDOM אכן דורש שהמעבד יתמוך בווירטואליזציה. עבור SPARC, מדובר בעיקר במעבדים המבוססים על ארכיטקטורת sunv4. קל יותר לזכור / לזהות, מעבדי Sparc T, בין אם הם T1-T7 אם כי ישנם מעבדים אחרים התומכים בכך. עבור x86 / x64. Solaris החלה, בגרסאות האחרונות, לתמוך בטכנולוגיה זו גם עבור x86 / x64 אך אנו נתמקד במעבדי SPARC עבור מאמר זה.
בשלב זה, אתם בטח שואלים את עצמכם, זה נהדר אבל למה אנחנו צריכים מספר רב של שכבות וירטואליזציה? LDOMs נהדרים אם אתה זקוק לסביבה מבודדת באמת. אולי יש לך גרסאות ספציפיות של Solaris שאתה צריך למטרות ספציפיות? לדוגמה, אם יש לך ערימת ייצור הדורשת Solaris 11.1 עבור מסד הנתונים ו- Solaris 10 עבור האפליקציה, תוכל להגדיר בקלות דומיין אורח LDOM לכל אחד מהם כדי שתוכל להריץ גרסאות ספציפיות אלה. אולי האפליקציה שלך כוללת 5-6 יישומים שונים שזקוקים לשכבת פילוח כלשהי מכיוון שהם אינם יכולים להתקיים באותו מופע מערכת הפעלה. אתה יכול להקים כל אחד באזור נפרד כדי להשיג זאת.
כפי שתואר לעיל, מקרה שימוש אחר מיועד להעברות. כאשר הגיע הזמן לשלול חומרה מדור קודם אך אתה עדיין זקוק לגרסאות ה- Solaris הישנות יותר מכיוון שהאפליקציה שלך פשוט לא תפעל בגרסה חדשה יותר, או אולי היא לא תומכת / לא מאושרת בגרסה החדשה יותר ואינך רוצה להתמודד עם תרחיש זה. סיבוב LDOMs ואזורים הם דרך קלה וקלה להשיג זאת מכיוון שכוח העיבוד וה- RAM הם בדרך כלל עודפים.
כדי להשיג זאת, ישנם 5 תפקידים עיקריים ל- LDOM. תחום שליטה, תחום שירות, תחום קלט / פלט, תחום שורש ודומיין אורח. תחום הבקרה אחראי על ניהול ה- LDOM המתארחים בשרת הפיזי. זה בדרך כלל משולב עם תחום השירות האחראי על הצגת משאבים מסוימים לדומיין האורח כגון דיסקים. תחום האורח הוא מערכת ההפעלה האורחת של השרת הווירטואלי בפועל. זה עוזב את תחום השורש ואת תחום הקלט / פלט. שני אלה משולבים בדרך כלל גם לתחום הבקרה. הם אחראים על מתן גישה לאוטובוסי PCI / PCIe. חשוב לציין כי דומיין האורח הוא בדרך כלל המקום היחיד שברצונך להתקין בו את היישומים העסקיים שלך כדי לפלח כראוי את הסביבה.
בדומה ל- Hypervisors אחרים, ניתן לעבור מ- LDOM בשידור חי משרת פיזי אחד למשנהו כל עוד יש להם אחסון משותף וכל שרת יכול לראות את אותם התקני אחסון. זה יכול להיות מועיל ביותר אם יש לך LDOM שעוסק במשאבים ואתה צריך לאזן. כאשר אתה מגדיר את ה- LDOMs אתה מגדיר גם את כל המגבלות שאתה רוצה לכל אחד מהם מבחינת זיכרון RAM, מעבד וכו '.
חלק מהמנהגים העיקריים לשימוש בשתי שכבות הוירטואליזציה הללו מגיעים לכוח העיבוד ולקיבולת ה- RAM העולים על צרכי היישום בפועל. לדוגמא, הייתי מעורב בהעברה מקיפה של Solaris Datacenter, שם הצליחו להחליף 30 מתלים של שרתי SPARC, SAN ומתגי רשת עד 6 מדפי ציוד ו- 5 שרתי SPARC בסך הכל. עם 5 שרתי SPARC אלה, כמה מאות אזורים מתארחים באמצעות תריסר LDOMs. הניהול פשוט הרבה יותר מכיוון שיש רק 5 שרתים פיזיים לניהול. אם צריך להקפיץ אזור או LDOM, פקודות zoneadm או ldm הן בהישג יד מבלי לשלוח מישהו לקומת מרכז הנתונים או לזכור את פרטי הקישוריות של ILOM.
ניהול קשרי LDOM יכול להיות משויך לבקרת גישה מבוססת תפקידים (RBAC). אולי אתה רוצה לתת למנהלי מערכת מסוימים גישה לשינוי LDOM אך למנהלי דרגות נמוכות יותר לדומיינים / אזורים אורחים. נעשה וחשוב בקלות כך שתוכל להגביל למי יש גישה לגרום לשינויים בתצורה נרחבים.
3 דקות קריאה
