Proxmox VE: הגדרת וירטואליזציה וקונטיינריזציה מפתח-על-מפתח

הגדרת Proxmox: היכן התשתית מאבדת שליטה

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

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

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

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

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

מה נותנת וירטואליזציה מנוהלת: אפקט במדדים מדידים

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

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

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

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

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

אפשרויות הגדרה של Proxmox למשימות שונות

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

תרשימי הצבה והמגבלות שלהם

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

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

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

1. אודיט תשתית — ספירת מלאי של שרתים, דיסקים, רשת ומכונות פעילות: מה מעבירים, מה מוציאים משימוש, איפה צווארי בקבוק במעבד, בזיכרון ובפעולות דיסק.
2. תכנון התרשים — פריסת מכונות וקונטיינרים בין הצמתים, קוורום, תפקידים, תוכנית כתובות ורזרבת כוח לגידול.
3. פריסה — התקנת צמתים, הרכבת אשכול Proxmox VE, חשבונות והרשאות אחידים, חיבור לניטור.
4. הגדרת אחסון — דיסקים מקומיים או כרך משותף, רפליקציה בין הצמתים, לוח זמנים לגיבוי ועומק שמירת הגיבויים.
5. הגדרת רשת — גשרים, פילוח תעבורה, בידוד קבוצות מכונות, גישה נפרדת לפאנל הניהול.
6. בדיקת עמידות לתקלות — כיבוי צומת תחת עומס, הדמיית כשל דיסק, שחזור מגיבוי: מתעדים את זמן המעבר והשחזור.
7. מסירה לתפעול — נוהלי עדכונים, הרשאות גישה, תיעוד, הדרכת הצוות שלכם וליווי לאחר ההעלאה.

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

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

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

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

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

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

מה היה לפני

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

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

מה שינינו

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

• שרתים לא מנוצלים: תשעה מתוך ארבעה-עשר → שניים, שנשארו למשימות עם גישה ישירה לחומרה;
• תחזוקה מתוכננת של צומת: חלון לילה של 3–4 שעות → 20–30 דקות בשעות העבודה בלי עצירת שירותים;
• שיעור הפעולות הידניות בהוצאת צומת: כ-שמונים אחוזים → בדיקות בודדות לפי צ'קליסט קצר;
• נפילת צומת: השירותים שכבו עד הגעת המהנדס → העומס מתחלק אוטומטית בין הצמתים החיים.

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

במה קונטיינרים שונים ממכונות וירטואליות בפועל

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

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

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

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

התלבטויות לפני ההתחלה: מגבלות ושאלות נפוצות

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

האם החומרה הנוכחית שלנו תתאים?

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

האם נוכל אחר כך לתחזק את המערכת בכוחות עצמנו?

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

מה יקרה בנפילת צומת או דיסק?

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

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

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

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

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

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