מדוע vMotion נכשל תחת עומס חי
מיגרציה חיה של מכונות וירטואליות נראית כמו פקודה אחת, אבל מתחתיה יש כמה תהליכים מקבילים: העתקת מצב הזיכרון, העברת דיסקים, הגדרה מחדש של הרשת ומעבר למארח היעד. כל עוד הם נכנסים לחלון שהוקצה, המעבר עובר בלי שמים לב. כשל בהעברת מכונה וירטואלית מתחיל כשתהליך אחד לפחות לא מדביק את העומס.
הסיבה הראשונה — חוסר סנכרון בנתונים. הזיכרון מועבר לפי דפים, ולאחר תחילת הסנכרון הדפים שהשתנו מועתקים שוב, ואז עוד פעם.
אם היישום כותב מהר יותר מהערוץ מספיק להעביר, הסבב לא נסגר: ההיפרוויזור מפעיל מחדש את הסנכרון עד הקצה, ואחר כך מחזיר את ההעברה לאחור — המכונה נשארת במארח המקור, וחלון התחזוקה כבר זז.
השנייה — צוואר בקבוק באחסון. כרכים שונים, סוגי מחיצות, גודל בלוק ומטמון נותנים מהירות בלתי צפויה: ב-Storage vMotion הנתונים מועברים לאט מהמתוכנן, ואילו דיסקים בחיבור ישיר אי אפשר להעביר בכלל. ערוץ עמוס בין אתרים מוסיף משלו — תעבורת המיגרציה חולקת רוחב פס עם שכפול וגיבוי, וזמן החישוב מוכפל.
השלישית — היעדר מרווח במשאבים, בגללו הסיכון הופך להשבתת שירות במעבר: בלי רזרבה של מעבד וזיכרון במארח היעד, מיתוג מאומת ותוכנית נסיגה, כל עיכוב נמתח לשעות. נסביר איך זה נסגר — מפרופיל העומס ועד הרצת מיגרציה על עותק.
מה נותן מעבר בלי השבתת שירות
המהות של מעבר בלי השבתת שירות היא שמכונה פעילה עוברת בין מארחים בלי לכבות אותה: הזיכרון מועתק למארח היעד, הדפים שהשתנו מדביקים במעברים חוזרים, והמעבר אורך שברירי שנייה. חיבורים שנקלעו להשהיה הזו מתחברים מחדש לפי טיים-אאוט, ולא נשברים בשגיאה. סוג המשימות «לכבות, להעביר, להדליק» יוצא מתוכנית התחזוקה.
מכאן האפקט המרכזי — קיצור חלון התחזוקה. עדכון היפרוויזור, החלפת חומרה, איזון מחדש של עומס והעברת דיסקים בין אחסונים מתבצעים על מערכות פעילות: הצומת מועבר למצב תחזוקה, המכונות מתפזרות על פני האשכול, והעבודות כבר לא דורשות השבתות לילה. Storage vMotion עושה את אותו הדבר עם דיסקים — הכרך מוחלף תחת מערכת פעילה, בלי כיבוי ורישום מחדש.
כמו כן יורד סוג הכשלים שקשורים למעבר ידני. כשההעברה נעשית ביד — עצירת שירות, ניתוק כרכים, סריקה חוזרת, רישום במארח חדש, הפעלה, תיקון רשומות מאזן העומס — כל טעות הופכת חלון מתוכנן לתקלה.
במיגרציה חיה אין מקום לטעות: אם ההעברה לא מתכנסת, המכונה נשארת במארח המקור וממשיכה לשרת בקשות. ההשהיה בפועל — שברירי שנייה במקום עשרות דקות, ואין יותר צורך לתאם עבודות לילה עם העסק.
רציפות השירות נבדקת בקבוצת פיילוט: מודדים אי-זמינות אמיתית, בוחנים התנהגות תחת עומס, ורק אחר כך מעבירים את השאר.
השוואת מצבים: vMotion ו-Storage vMotion
מצב המיגרציה החיה נבחר לפי מה בדיוק עובר: צומת מחשוב, אחסון או שני הרכיבים יחד. ב-VMware vMotion מכונה פעילה מחליפה מארח, והדיסקים שלה נשארים באחסון משותף — זמן ההשבתה נמדד בשניות, והמשך תלוי בקישוריות בין הצמתים, לא בנפח הדיסק.
Storage vMotion פותר את המשימה ההפוכה: קבצי המכונה הווירטואלית עוברים לאחסון אחר, והמכונה עצמה נשארת במארח הנוכחי. זמן ההעברה כאן פרופורציונלי לנפח הנתונים ולרוחב הפס בין המערכים.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| vMotion | צריך להסיר עומס מצומת, לפנות אותו לתחזוקה או לאזן את האיזון באשכול, והאחסון נשאר כשהיה | נדרש אחסון משותף שזמין לשני המארחים, וערכות פקודות מעבד תואמות בגבולות האשכול |
| Storage vMotion | העברת אחסון של מכונות וירטואליות: החלפת מערך, הוצאת ציוד ישן, העברת דיסקים לרמה אחרת | נדרשים מקום פנוי באחסון היעד ומרווח רוחב פס; תמונות מצב גדולות ודיסקים במצב העברה ישירה מאריכים את הפעולה |
| שני המצבים ברצף | מעבר לצומת אחר ולאחסון אחר בו-זמנית, כולל לאתר אחר או לאשכול אחר | הפעולה הארוכה ביותר: דרישות רשת, תאימות ומקום פנוי מצטברות, ונדרש מרווח בעומס |
לפני בחירת המצב אנחנו בודקים את מה שבדרך כלל שובר את ההעברה: תמונות מצב של דיסקים, מצב החיבור שלהם, סוגי האחסון בשני הקצוות ותאימות המעבדים. זה מאפשר להפריד מראש בין מכונות שיעברו בלי השבתה לבין אלה שיהיה צריך להעביר בנפרד.
שלבי ההעברה: מביקורת ועד מסירה
סדר העבודות קבוע: קודם עובדות, אחר כך מעבר. שלבי מיגרציית התשתית בנויים כך שכל צעד נותן תוצאה ניתנת לבדיקה, והמצב הביניים נשאר הפיך — בזה נבדלת העברה מתוכננת מהעברת חירום.
- ביקורת לפני ההעברה. מיפוי מלאי של מכונות, מערכות הפעלה אורחות, דיסקים, רשתות ותלויות בין שירותים. בנפרד — תאימות לאשכול היעד ופרופיל עומס על האחסון בשעות שיא: הוא קובע את חלון העבודה המותר.
- תוכנית העברת מכונות וירטואליות. מסמנים מה עובר במיגרציה חיה עם vMotion בלי השבתת שירות, ומה דורש השבתה קצרה — החלפת פורמט דיסק, דרייברים או בקר. מתעדים התאמות רשת וסדר קבוצות.
- הכנת האתר. אחסון, מאגרים, מדיניות מיקום, הרשאות, לוחות זמנים לשכפול, גיבויים. בודקים אם רוחב הפס של הערוצים מספיק להעברת דיסקים, ולא רק למעבר עצמו.
- הרצת ניסיון. מעבירים שניים-שלושה עותקים מקבוצות שונות ומבצעים מדידות ביקורת: זמן מעבר, השהיות קלט-פלט, עומס אחסון. לפי המדידות מעדכנים את התוכנית ואת אורך החלון.
- הגל המרכזי. הקבוצות עוברות לפי הסדר שנקבע, אחרי כל אחת — בדיקת זמינות שירותים, יומנים וגיבויים.
- בדיקה אחרי המיגרציה. משווים את המדידות לבסיס, את המקורות משאירים כבויים אך מוכנים להפעלה: זו תוכנית הנסיגה.
- מסירה. גישות, תרשימים, נוהל תחזוקה והוראות חזרה למשמרת תורנות.
מסמכים ותרשימים שנשארים אצלכם
המיגרציה לא מסתיימת ברגע המעבר למארח אחר, אלא בחבילת תיעוד של התשתית, שלפיה אפשר להפעיל אותה ולפתח אותה בלי מחבר השינויים. להלן מה שאנחנו מוסרים יחד עם הגישות: הרשימה מכסה גם עבודה יומיומית, גם מיגרציה הבאה, וגם ניתוח תקלה.
- מפת תלויות שירותים. מה קשור למה: פניות למסדי נתונים, מתווכי הודעות, אחסון קבצים, מערכות חיצוניות. אוספים מתוך קונפיגורציות ויומני רשת, ולא מהזיכרון של המנהל — במעבר רואים מיד מה אסור לכבות בו-זמנית.
- תרשים התשתית הווירטואלית. אשכולות, מארחים, אחסון, פלחי רשת, נקודות כשל, מרווח במעבדים, בזיכרון ובדיסקים. לפיו מהנדס חדש מבין את הטופולוגיה בשעה, ולא בשבוע של שאלות.
- נוהל העברה. סדר המיגרציה בשלבים: מה בודקים לפני המעבר, אילו מדדים נחשבים סימן להצלחה, באילו תנאים חוזרים למארח המקור וכמה זה אורך.
- נוהל שחזור. זמן שחזור יעד ונקודת שחזור לכל שירות, סדר עלייה, אחראים, קריטריון לסגירת תקרית.
- מדיניות גישה. תפקידים, חשבונות שירות, הרשאות ברמת האשכול, האחסון ומערכות אורחות, כללי סבב סודות וסדר הענקת גישות לעובדים חדשים.
- מיפוי מלאי וגיבוי. משאבים של כל מכונה, לוח זמנים לגיבויים, מקומות אחסון, תאריך בדיקת השחזור האחרונה מגיבוי.
כשקבלן חדש או המהנדס שלכם פותח את הקבצים האלה, מסירת התשתית לא הופכת להתכתבות עם שאלות. את המסמכים אנחנו כותבים בהתאם לסביבה שלכם — עם שמות אמיתיים של מארחים, אחסון וקבוצות גישה, ולפני המסירה עוברים על הרשימה יחד עם הצוות ומתקנים את מה שנשאר לא ברור.
מקרה בוחן: מעבר אשכול בלי השבתת שירות
אשכול של כמה עשרות מכונות וירטואליות תוחזק ידנית. העברות מתוכננות בוצעו רק בחלונות לילה: כל אחת — עם השבתת שירות של ארבעים עד שישים דקות ומהנדס תורן מול המסך.
בחודש הצטברו שישה עד שמונה חלונות כאלה, וטעות בסדר ההעברה הסתיימה בכך שחלק מהמכונות עלו עם הגדרות רשת שגויות והיה צריך לתקן אותן כבר בבוקר, על משתמשים פעילים.
מה שינו
את התחזוקה העברנו לאמצעים המובנים של VMware: מכונות פעילות מועברות בין מארחים תוך כדי עבודה דרך vMotion, כרכי דיסקים מועברים בנפרד מהמחשוב — המעבר הפסיק להיות אירוע עם השבתה.
את סדר הפעולות עיגנו בנוהל: קודם בדיקת תאימות ברמת ערכות פקודות מעבד ודרייברים, אחר כך העברת מחשוב, אחר כך אחסון, ורק לאחר מכן — הוצאת המארחים שהתפנו לתחזוקה. בנפרד הגדרנו כללי חלוקת משאבים, כדי שאחרי ההעברה העומס לא ייפול על מארח אחד.
מה השתנה
חלונות לילה כתהליך נפרד נעלמו: עבודות שגרה מתבצעות בשעות העבודה, מספר ההשבתות המתוכננות הצטמצם משישה-שמונה בחודש לאפס, והזמן שהתפנה לתורנים עבר לפיתוח התשתית.
זמן החזרה לעבודה אחרי כשל במארח הצטמצם מכמה שעות של ניתוח ידני לעשרות דקות — המכונות עולות על צומת גיבוי לפי תרחיש שנכתב מראש. מיגרציית האשכול עכשיו אורכת יום עבודה אחד במקום שרשרת של משמרות לילה, והשירות לא כובה אף פעם.
מה לעשות אם vMotion לא עובר באחסון הנוכחי
לרוב המיגרציה החיה נופלת לא בגלל כשל בהיפרוויזור, אלא בגלל היעדר נקודת עיגון משותפת בין הצדדים. בודקים ארבעה דברים: האם אחסון אחד רואה את שני האשכולות, האם סוגי הכרכים תואמים, האם יכולות המעבדים מצומצמות לערכה משותפת, והאם אין תמונות מצב פתוחות והתקני העברה ישירה. כל פרט כזה חוסם את ההעברה עוד לפני ההתחלה, והשגיאה מציגה רק את התוצאה.
אם המארחים באותו אשכול, וצריך להחליף אמצעי אחסון ולא צומת מחשוב, זו משימה של Storage vMotion: הדיסקים עוברים בין אחסונים תוך כדי עבודה, בלי לעצור את מערכת האורח. מגבלה אחת — רוחב הפס של הערוץ בין המערכים: כשהמערך חלש, ההעברות נכנסות לתור ונקטעות בגלל טיים-אאוט.
כשאין נקודה משותפת בכלל — אשכולות שונים, אתרים שונים, היעדר כרך משותף — מסתדרים בלי לבנות מחדש את התשתית. אחסון «גשר» שזמין לשני הצדדים מאפשר להעביר כרכים בחלקים: קודם בסיס, בתמונת מצב שנלקחה, אחר כך דלתא, ואת השרשרת מרכיבים כבר ביעד. מספר ההעברות במקביל מוגבל ידנית, אחרת ערוץ השכפול נסתם.
אם גם זה לא עובר, עובדת רמת האורח: שכפול באמצעים של המערכת עצמה או העברה קרה — מכבים את המכונה, מעתיקים כרכים, מעלים במקום חדש. המסלול הקר צפוי ובשעות שיא מתברר כמהיר יותר מאשר מאבק בטיים-אאוטים.
על VMware ופלטפורמות תואמות אנחנו קודם אוספים מפת תאימות: למי אילו כרכים נראים, אילו ערכות פקודות תואמות, והיכן צוואר הבקבוק של הערוץ. כך ההעברה נכנסת לחלון התחזוקה בלי לבנות מחדש את כל האחסון.
ספקות נפוצים לפני מיגרציה חיה
לפני מיגרציה חיה עם vMotion עולה אותו סט ספקות: מה יקרה לשירות בניתוק ההעברה, האם יהיה צריך לכבות מכונות, ואיך יתנהגו מסדי נתונים תחת עומס. להלן ניתוח ההתנגדויות שאיתן באים אלינו לרוב, כולל אשכולות עם אחסון משותף ומערכות שלא עודכנו מזמן.
מה יקרה אם ההעברה תיקטע באמצע?
המכונה נשארת במארח המקור: עד סיום ההעברה המצב נקלט בנקודת חזרה, ובמקרה של ניתוק הקשר מערכות אורחות ממשיכות לעבוד במקום שבו עבדו. את החזרה בודקים על קבוצת בדיקה לפני הוצאת האחרות.
האם חובה לכבות מכונות וירטואליות?
לא. במיגרציה חיה הזיכרון ומצב המעבד מועברים תוך כדי תנועה, ואי-זמינות קצרה אפשרית רק ברגע המעבר. את משך הזמן אנחנו מודדים מראש, ולא מבטיחים במילים.
איך מעבירים מסדי נתונים ואשכולות?
צמתים מעבירים אחד-אחד, תוך מעקב אחר קוורום ושכפול: האשכול חייב לשמור על רוב קולות בכל צעד. מסדי נתונים עם כתיבה אינטנסיבית מועברים למצב סנכרון עדין ומועברים אחרונים.
מה לעשות עם פלטפורמות מיושנות?
מערכות אורחות על גרסאות ישנות לרוב לא תומכות בהעברה חיה — מעדכנים או בונים אותן מחדש מראש. זה מאריך את ההכנה, אבל מסיר סוג כשלים שאחרת היה עולה במהלך העבודות.
בואו נדון בתרחיש ההעברה שלכם
כדי להזמין העברת מכונות וירטואליות לא צריך מסמך רשמי — מספיק מה שכבר יש למנהלים: ייצוא מהמלאי, תרשימי רשת, התכתבויות על חלונות תחזוקה. לפי הסט הזה אנחנו בונים תוכנית גלים ואומרים היכן המעבר יעבור בלי השבתת שירות והיכן יידרש חלון.
- הרכב הצי: מספר מכונות, מערכות הפעלה, נפח וסוג דיסקים, תמונות מצב, תבניות, מכונות עם דיסקים משותפים של האשכול.
- מפת אתרים: מיעון, פילוח רשתות, כללי ניתוב בין סביבות, זמינות אחסון משני הצדדים.
- דרישות זמינות לכל שירות: משך השבתה מותר, שעות שבהן המעבר אסור, תקופות עומס שיא.
- שירותים קריטיים וקשרים בין מכונות: מה עולה ראשון, מה מחזיק נעילות וכרכים משותפים, והיכן סדר ההפעלה נוקשה.
- הגדרות נוכחיות של האשכול והאחסון: סוגי אחסון, מדיניות מיקום, מגבלות על מספר משימות במקביל.
- תנאי נסיגה: עד מתי אפשר לחזור לאתר המקור והאם יהיו שם מספיק משאבים בזמן שמיגרציית האשכול נמשכת.
ייתכן שחלק מהרשימה חסר — זה בסדר, חלק מהנתונים אנחנו אוספים בעצמנו בסקירה. תארו את המשימה ושלחו את מה שיש: נחזור עם הערכה, חלוקה לגלים, נקודות בדיקה אחרי כל אחד ותרחישי נסיגה. כך העברת תשתית מקצה לקצה מקבלת קריטריוני קבלה מדידים, ולא הבטחה «נעשה בזהירות». נדון במיגרציה על מספרים קונקרטיים של הצי שלכם.