תחזוקה ועדכונים של ענן פרטי

סביבות ענן פרטיות מתוכננות כך שלא יהיה בהן נקודת כשל יחידה:

• אשכולות ESXi מוגדרים עם זמינות גבוהה (HA) של vSphere. גודל האשכולות נקבע כך שיהיה בהם לפחות צומת חלופי אחד לצורך עמידות.
• ‫vSAN מספק אחסון ראשי עם יתירות, ונדרשים לפחות שלושה צמתים כדי לספק הגנה מפני כשל יחיד. במקרים של אשכולות גדולים יותר, אפשר להגדיר את vSAN כך שיספק עמידות גבוהה יותר.
• מכונות וירטואליות (VM) של vCenter,‏ PSC ו-NSX Manager מוגדרות עם אחסון RAID-10 כדי להגן מפני כשל באחסון. בנוסף, מכונות ה-VM מוגנות מפני כשלים בצמתים וברשת באמצעות vSphere HA.
• למארחי ESXi יש מאווררים וכרטיסי רשת (NIC) מיותרים.
• מתגי TOR ומתגי spine מוגדרים בצמדי HA כדי לספק עמידות.

‫VMware Engine עוקב באופן רציף אחרי זמני הפעילות, עוקב אחרי הזמינות ומספק הסכמי רמת שירות (SLA) של זמינות לסוגים הבאים של מכונות וירטואליות:

• מארחי ESXi
• vCenter
• PSC
• NSX Manager

ב-VMware Engine מתבצע ניטור רציף של הרכיבים הבאים כדי לאתר כשלים:

• דיסקים קשיחים
• יציאות פיזיות של כרטיס NIC
• שרתים
• מעריצים
• הספק
• מתגים
• החלפת יציאות

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

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

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

• ESXi
• בקר שירותי הפלטפורמה של vCenter
• vSAN
• NSX

גיבוי ושחזור

הגיבויים כוללים את הפריטים הבאים:

• גיבויים מצטברים מדי לילה של vCenter,‏ PSC וכללי DVS.
• ממשקי API מובנים של vCenter לגיבוי רכיבים בשכבת האפליקציה.
• גיבוי אוטומטי לפני עדכון או שדרוג של תוכנת הניהול של VMware.

תחזוקה

התחזוקה המתוכננת כוללת את הסוגים הבאים.

תחזוקה של הקצה העורפי ותחזוקה פנימית

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

תחזוקת הפורטל

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

• מישור הניהול ואפליקציות של VMware
• גישה ל-vCenter
• כל הרשתות והאחסון

תחזוקת תשתית VMware

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

• מישור הניהול ואפליקציות של VMware
• גישה ל-vCenter
• כל הרשתות והאחסון

עדכונים ושדרוגים

‫VMware Engine אחראי לניהול מחזור החיים של תוכנת VMware ‏ (ESXi,‏ vCenter,‏ PSC ו-NSX) בעננים פרטיים.

עדכוני התוכנה כוללים את הדברים הבאים:

• תיקונים: תיקוני אבטחה או תיקוני באגים שפורסמו על ידי VMware
• עדכונים: שינוי בגרסה משנית של רכיב במערך VMware
• שדרוגים: שינוי בגרסה הראשית של רכיב בסטאק VMware

ב-VMware Engine נבדקים תיקוני אבטחה קריטיים ברגע שהם זמינים מ-VMware. ‫Google תשאף להתחיל בהפצה של תיקונים קריטיים רלוונטיים לסביבות ענן פרטי תוך שבוע ממועד הזמינות שלהם. ציר הזמן בפועל להשלמת התיקון ישתנה בהתאם לזמינות של התזמון ולצורך לתזמן את התיקון כדי להימנע מהשבתה של עומסי העבודה של הלקוחות.

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

VMware Engine גם עובד עם ספקי מפתח בתעשייה כדי לוודא שהם תומכים בגרסת התוכנה העדכנית של VMware לפני השקת שדרוג גרסה משמעותי. כדי לקבל מידע על תמיכה בספקים ספציפיים, אפשר לפנות אל Cloud Customer Care.

אחריות לעדכון האישור

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

הכנה

‫Google ממליצה לבצע את ההכנות הבאות לפני שמתחילים בעדכון או בשדרוג:

• בדיקת נפח האחסון: כדי לעמוד בתנאי הסכם רמת השירות, צריך לוודא ששימוש בנפח האחסון של אשכול vSphere נמוך מ-80%. אם רמת הניצול גבוהה מ-80%, יכול להיות שהשדרוגים יימשכו זמן רב מהרגיל או ייכשלו לחלוטין. אם השימוש בנפח האחסון גבוה מ-70%, כדאי להוסיף צומת כדי להרחיב את האשכול ולמנוע השבתה פוטנציאלית במהלך השדרוגים.
• שינוי מדיניות האחסון ב-vSAN עם FTT של 0: שינוי מכונות וירטואליות שהוגדרו עם מדיניות אחסון ב-vSAN עם FTT של 0 ל-Failures to Tolerate (FTT) למדיניות אחסון ב-vSAN עם FTT של 1 כדי לשמור על ה-SLA.
• הסרת חיבורים של תקליטורים למכונות וירטואליות: מסירים תקליטורים שמחוברים למכונות וירטואליות של עומס העבודה שלא תואמים ל-vMotion.
• משלימים את ההתקנות של כלי VMware: משלימים את כל ההתקנות או השדרוגים של כלי VMware לפני שהשדרוג המתוזמן מתחיל.
• הסרת שיתוף של אוטובוס SCSI במכונות וירטואליות: מסירים את השיתוף של אוטובוס SCSI במכונות וירטואליות אם לא רוצים שהמכונות הוירטואליות יכובו.
• הסרה של מכונות וירטואליות ומאגרי נתונים שלא ניתן לגשת אליהם: הסרה של מכונות וירטואליות שלא בשימוש ושלא ניתן לגשת אליהן ממלאי vCenter. מסירים מאגרי נתונים חיצוניים שלא ניתן לגשת אליהם.
• השבתה של כללי Distributed Resource Scheduler (DRS): כללי DRS שמוצמדים למכונה וירטואלית למארח מונעים מצומת להיכנס למצב תחזוקה. אפשר להשבית את כללי ה-DRS לפני השדרוג ולהפעיל אותם אחרי שהשדרוג יסתיים.
• עדכון של תוספים של VMware ופתרונות של צד שלישי: צריך לוודא שהתוספים של VMware והפתרונות של צד שלישי שפרסתם ב-vCenter של הענן הפרטי תואמים לגרסאות שאחרי השדרוג שצוינו קודם. דוגמאות לכלים: כלים לגיבוי, לניטור, לתיאום של התאוששות מאסון ופונקציות דומות אחרות. כדי לוודא תאימות אחרי השדרוג, כדאי לפנות לספק הפתרון ולעדכן מראש את הפתרון אם צריך.

משך השדרוג ותהליכים ברקע

הגורמים הבאים יכולים להשפיע על משך השדרוג:

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

הגדרות שעשויות להשפיע על תהליכי התחזוקה

‫VMware Engine משתמש במצב תחזוקה של VMware כדי לבצע שדרוגים, עדכונים ותחזוקה של צמתים. כך תוכלו להבטיח שעומסי העבודה ב-Private Cloud ימשיכו לפעול. עם זאת, יכול להיות שיהיה צורך לבצע שלבים נוספים כדי שהצומת יעבור למצב תחזוקה, בהתאם להגדרות הבאות:

• כללי DRS: כללי חובה שמכריחים מכונות וירטואליות להישאר בצומת ספציפי.
• שיתוף של אוטובוס SCSI: מכונות וירטואליות שהוגדרו לשתף אוטובוסים של SCSI.
• חיבורי CD-ROM: מכונות וירטואליות עם CD-ROM מצורפים, במיוחד אם אי אפשר להעביר את ה-CD-ROM האלה לצומת אחר באמצעות vMotion.
• חיבורים ליציאה טורית: מכונות וירטואליות שמשתמשות בחיבורים ליציאה טורית, שמונעים את ההעברה שלהן לצומת אחר באמצעות vMotion.
• מיפויים של מכשירים גולמיים (RDM): מכונות וירטואליות עם גישה ישירה למכשירי אחסון פיזיים.

חשוב: ניהול יזום של ההגדרות האלה יכול לעזור לייעל את תהליכי התחזוקה העתידיים של VMware Engine.

אם נדרשת פעולה

אם אחת מהתצורות האלה קיימת בצומת, צוות Cloud Customer Care יודיע לכם על כך לפחות 24 שעות לפני שינקוט את פעולות התיקון הנדרשות כדי לשמור על הזמינות של הענן הפרטי שלכם. במקרים מסוימים, פעולות כמו כיבוי של מכונה וירטואלית והעברה שלה באמצעות vMotion ואז הפעלה שלה, או הסרה של תקליטורי CD-ROM, עלולות לשבש את עומס העבודה לזמן קצר.

המאמרים הבאים

• מידע נוסף על האבטחה ב-VMware Engine