הגדרת libvirt/virsh לניהול מכונות וירטואליות KVM

הגדרת libvirt: נקודות כשל בניהול מכונות

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

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

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

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

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

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

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

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

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

אפשרויות הגדרת libvirt: השוואת גישות

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

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

שלוש אפשרויות עבודה

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

סדר היישום: מביקורת ועד מסירה

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

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

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

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

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

5. מסירה לתפעול. מוסרים נהלים, מפת פריסה והוראות לפעולות טיפוסיות — יצירת מכונה, העברה, יצירת גיבוי, תגובה לכשל.

מה נשאר אצל הלקוח: סכימות, מדיניות, נהלים

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

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

בנפרד עוברים עם המהנדסים של הלקוח על הנוהל: מסמך שאף אחד לא תרגל בפועל נשאר קובץ בלבד.

מקרה בוחן: איך גדלה צפיפות המכונות על צומת אחד

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

מה שינו

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

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

מדדים לפני ואחרי

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

במה ניהול מרכזי שונה מפקודות ידניות

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

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

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

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

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

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

ספקות טכניים: מפרקים צווארי בקבוק

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

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

מה יקרה בעת כשל צומת?

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

מה הדרישות לאתר ולצמתים?

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

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית.