הגדרת VMware vSphere/ESXi: אשכול עמיד בפני תקלות מקצה לקצה

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

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

הגדרת VMware vSphere: היכן הקלאסטר נשבר

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

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

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

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

מה משתנה לאחר ההטמעה: השבתה, שחזור, כשלים

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

זמן שחזור השירותים: דקות במקום שעות

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

מחלקת כשלי חומרה שנמנעה

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

מעבר אוטומטי ללא פעולות ידניות

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

זמינות השירותים והעומס על התורן

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

מצבי עמידות לתקלות ב-vSphere: מה לבחור

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

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

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

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

סדר ההטמעה: מביקורת ועד מסירה לתפעול

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

  1. ביקורת תשתית. עורכים מלאי של מארחים, מקטעי רשת, מערכים ומכונות וירטואליות קיימות, ומפיקים מפת תלויות בין שירותים. בפלט — רשימת צווארי בקבוק: אחסון עמוס יתר על המידה, נתיבים בודדים למערך האחסון, היעדר יתירות במתגים.
  2. תרשים מיקום הצמתים. מפזרים את המארחים בין ארונות, אזורי חשמל וזוגות רשת כך שכשל של אלמנט בודד לא יפיל את הקלאסטר. מחשבים עתודת משאבים לפי כלל N+1 וכללי איזון.
  3. הכנת הפלטפורמה. מסמנים רשתות: תעבורת שירות, הגירות, גישה לאחסון דרך iSCSI או NFS, VLAN נפרדים, גודל מסגרת מוסכם. מגדירים פרופילי אחסון ומדיניות עמידות לתקלות.
  4. הגדרת הקלאסטר. מפעילים זמינות גבוהה עם בקרת עתודה, מגדירים heartbeat לאחסון, סדרי עדיפויות וסדר אתחול של מכונות וירטואליות, בידוד צומת בעת אובדן קשר.
  5. בדיקה בסביבת ניסוי. מריצים עומסי בדיקה, הגירות מתוכננות והידרדרות אחסון, מודדים זמן תגובה בשיא. תיקונים מבוצעים לפני העברה לסביבת ייצור.
  6. תרגילי כשל. מכבים בתורו מארח, חשמל של ארון, מנתקים קישור עולה ומדמים אי-זמינות של מערך. מתעדים את זמן האתחול בפועל של השירותים ואובדן נתונים.
  7. מסירה לתפעול. מוסרים נהלי תחזוקה, מפות שחזור, ניטור מוגדר וספי התראות, מעבירים הדרכה למשמרת התורנית ומתאמים חלונות עבודה.

תיעוד, תרשימים ומדיניות גישה

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

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

מקרה בוחן: הקלאסטר עמד בכשל צומת ביום עבודה

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

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

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

כשל באמצע יום העבודה

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

מדדים לפני ואחרי: השבתה של שירותים קריטיים — 40 דקות מול 2, שחזור מלא — שעה וחצי מול 4 דקות, שיעור הכשלים שהקלאסטר טיפל בהם ללא מהנדס — 100%. עבודות מתוכננות מתבצעות כעת ללא חלון תחזוקה: מוציאים צומת מהקלאסטר, מעדכנים ומחזירים, והעומס עובר על האחרים.

במה שונה קלאסטר עמיד לתקלות מגיבוי?

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

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

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

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

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

שאלות טכניות שנשאלות לפני תחילת העבודות

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

האם הציוד שכבר מותקן בארון מתאים?

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

האם ניתן להרכיב עמידות לתקלות ללא מערכת אחסון חיצונית?

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

כיצד מתבצעת תחזוקה מתוכננת ללא השבתה?

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

כיצד לוודא שהמעבר אכן עובד?

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

נדון במשימה: מה נדרש להערכה

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

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

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