מאמר
חידוש VMware לפני הפתח? צ׳ק־ליסט מעבר ל‑Proxmox
מאז רכישת VMware על ידי Broadcom, חידוש רישוי הפך מהחלטה טכנית שגרתית להחלטה אסטרטגית. זהו צ׳ק־ליסט מעשי ב‑8 שלבים: מה לבדוק, מה להחליט, ואיך מבצעים מעבר ל‑Proxmox VE כתהליך מבוקר ומדורג.
רכישת VMware על ידי Broadcom שינתה את המודל המסחרי: רישיונות קבועים (Perpetual) הופסקו לטובת מנויים, מוצרים עצמאיים אוחדו לחבילות, ותוכניות השותפים השתנו. ארגונים רבים בישראל מקבלים היום הצעת חידוש שנראית שונה מאוד מהקודמת — ולכן החידוש הבא הוא נקודת החלטה, לא פעולה אוטומטית.
זה לא אומר שכל ארגון חייב לעזוב את VMware. זה כן אומר שכדאי להגיע להחלטה עם תמונה מלאה: מה באמת רץ בסביבה, מה עלות החלופות, ואיך נראה מעבר מסודר ל‑Proxmox VE — פלטפורמת וירטואליזציה בקוד פתוח עם אשכולות, HA, הגירה חיה ומערך גיבוי ייעודי.
ב‑ILS Networks אנחנו מבצעים מעברים כאלה כתהליך שינוי תשתית מבוקר ומדורג — עם תכנית חזרה לכל שלב — כפי שעשינו בפרויקט של Ariston Group. הצ׳ק־ליסט הבא מסכם את השלבים שאנחנו עוברים עם כל ארגון ששוקל את ההחלטה.
-
להבין מה בעצם השתנה בחידוש
לפני שמשווים חלופות, חשוב להבין למה ההצעה החדשה נראית אחרת. השינויים של Broadcom הם הקשר השוק שבתוכו מתקבלת ההחלטה:
- רישיונות קבועים (Perpetual) הופסקו — הרישוי של VMware עבר למודל מנוי בלבד.
- מוצרים עצמאיים אוחדו לחבילות כמו VMware Cloud Foundation ו‑vSphere Foundation — ייתכן שההצעה כוללת יכולות שהארגון לא משתמש בהן.
- התמחור מבוסס ליבות (Per-Core), עם מינימום ליבות לכל מעבד.
- שינויים בתוכנית השותפים השפיעו על ערוצי הרכש והתמיכה של לקוחות רבים.
- סמנו את מועד החידוש ותכננו אחורה: הערכה רצינית ומעבר מסודר נמשכים חודשים, לא שבועות — כדאי להתחיל הרבה לפני שההצעה פוקעת.
-
מיפוי מלא של הסביבה הקיימת
אי אפשר לתכנן מעבר על סמך הנחות. השלב הראשון הוא תמונה מלאה של מה שרץ היום:
- רשימת כל המכונות הווירטואליות: מערכת הפעלה, vCPU, זיכרון, דיסקים, Snapshots ומצב VMware Tools.
- מיפוי השרתים והאשכולות: דורות מעבדים, זיכרון, אחסון מקומי מול אחסון משותף.
- תיעוד האחסון: Datastores, מערכי SAN/NAS, פרוטוקולים (iSCSI, NFS, FC) ודיסקים מסוג RDM.
- מיפוי הרשת: vSwitches ו‑Distributed Switches, רשתות VLAN, צימוד כרטיסי רשת ותלויות בחומת האש.
- רישוי שאינו VMware: רישיונות Windows Server, בסיסי נתונים ותוכנות שקשורות לחומרה, לכתובת MAC או ל‑UUID.
- תיעוד משימות הגיבוי והאינטגרציות שפונות ל‑vCenter (גיבוי, ניטור, אוטומציה).
- סיווג עומסים: קריטיים (עוברים אחרונים, עם הכי הרבה הכנה), רגישים (טיפול מיוחד — למשל רישוי תלוי חומרה), ומועמדים לגל ראשון (סיכון נמוך).
-
להחליט על ארכיטקטורת היעד
ל‑Proxmox VE יש כמה החלטות תכנון שצריך לסגור לפני שמזיזים מכונה אחת:
- תכנון האשכול: מספר שרתים, קוורום (מספר אי־זוגי של שרתים או QDevice) ותחומי כשל.
- אחסון: ZFS (שרת בודד או רפליקציה בין שרתים), Ceph (שלושה שרתים ומעלה, גדילה אופקית) או אחסון משותף iSCSI/NFS — לכל אפשרות מאפייני HA וביצועים שונים.
- רשת: גשרי Linux, רשתות VLAN ו‑Bonding, עם הפרדה בין תעבורת ניהול, אחסון ומכונות.
- הגדרת HA והגירה חיה: אילו עומסים דורשים התאוששות אוטומטית ואילו מספיק להם טיפול ידני.
- החלטה אילו עומסים, אם בכלל, נשארים על VMware — למשל מוצרי מדף שנתמכים רק על ESXi. מעבר חלקי הוא תוצאה לגיטימית.
-
לתכנן רישוי ועלות
ההשוואה הנכונה היא בין התמונות המלאות, לא בין שורות רישוי:
- לתמחר את חידוש VMware במלואו: מנוי לפי ליבות, רמת החבילה ותקופת ההתחייבות.
- Proxmox VE הוא קוד פתוח ללא רישוי לפי ליבות; מנוי Enterprise הוא אופציונלי, מתומחר לפי Socket, ומקנה גישה למאגר העדכונים היציב ולתמיכת היצרן.
- לתקצב את המעבר כפרויקט תשתית: תכנון, פיילוט, מעבר מדורג, שינויי חומרה או אחסון אם נדרשים, והכשרת הצוות.
- לא להסתמך על מספרי חיסכון כלליים מהאינטרנט — לבנות מודל עלות לפני/אחרי על הסביבה שלכם. התוצאה שונה מארגון לארגון.
- לסגור את שאלת התמיכה: מי עונה בשלוש בלילה — מנוי Proxmox, אינטגרטור ישראלי או צוות פנימי.
-
לתכנן מחדש גיבוי והתאוששות מאסון
מעבר פלטפורמה הוא הזדמנות (וחובה) לבחון מחדש את כל מערך הגנת המידע:
- Proxmox Backup Server: גיבוי אינקרמנטלי, דה־דופליקציה והצפנה, עם אימות תקינות מובנה לגיבויים.
- Veeam תומכת ב‑Proxmox VE החל מגרסה 12.2 — לקוחות Veeam קיימים יכולים להישאר על פלטפורמת הגיבוי המוכרת.
- רפליקציית ZFS בין שרתים לצורך התאוששות מקומית מהירה של מכונות נבחרות.
- עותק מחוץ לאתר: סנכרון מרוחק של PBS לאתר משני או לאתר DR.
- להגדיר RPO ו‑RTO לכל דרגת עומס, לגזור מהם לוחות זמנים ומדיניות שמירה — ולבדוק שחזורים בפועל, לא רק שהגיבוי "רץ".
-
פיילוט על עומסים לא קריטיים
לפני שנוגעים בייצור, מוכיחים את התהליך על סביבה שסובלת טעויות:
- לבחור קבוצה קטנה של מכונות בסיכון נמוך שמכסה את סוגי מערכות ההפעלה המרכזיים בארגון.
- לוודא את נתיב ההמרה: ייבוא דיסקים מ‑VMware, התקנת דרייברי VirtIO ב‑Windows ומיפוי הרשת מחדש.
- להשוות ביצועים לפני ואחרי תחת עומס אמיתי.
- להריץ מחזור גיבוי ושחזור מלא על מכונות הפיילוט עם מערך הגיבוי החדש.
- להגדיר תכנית חזרה לכל שלב: מה מפעיל חזרה לאחור וכמה זמן היא לוקחת.
- רק אחרי שהפיילוט עובר את כל הבדיקות — מתקדמים לסביבת הייצור.
-
מעבר מדורג בגלים
את הייצור לא מעבירים בבת אחת. עובדים בגלים, לפי סדר עדיפויות עסקי:
- לחלק את העומסים לגלים: סיכון נמוך קודם, מערכות קריטיות אחרונות.
- לתאם לכל גל חלון תחזוקה מוגדר מראש מול הגורמים העסקיים.
- לוודא כל גל — שירותים למעלה, אפליקציות נבדקו, גיבויים רצים — לפני שמתחילים את הגל הבא.
- לשמור את מכונות המקור כבויות אך שלמות עד שהגל מאומת במלואו.
- לעדכן את המשתמשים מראש על חלונות התחזוקה וההשפעה הצפויה.
-
אימות, תיעוד ותפעול שוטף
המעבר נגמר רק כשמישהו הוכיח שהכול עובד — ותיעד איך:
- בדיקות קבלה עם בעלי המערכות והמשתמשים, לא רק בדיקות תשתית.
- בדיקות שחזור שמוכיחות את יעדי ה‑RPO/RTO שהוגדרו: לשחזר מכונות וקבצים אמיתיים ולמדוד את הזמן.
- תיעוד מלא של הארכיטקטורה הסופית: אשכול, אחסון, רשת, לוחות גיבוי ונהלי תפעול.
- עדכון מערכי הניטור וההתראות לפלטפורמה החדשה.
- להבטיח מעטפת תפעול אחרי העלייה לאוויר — ILS Networks מעניקה תמיכה לסביבות שהיא מלווה.
מקורות
מקורות רשמיים לעובדות המרכזיות
הקישורים נבחרו ממקורות היצרנים ומתעדים את השינויים ברישוי, מודל המנוי ויכולות המעבר והגיבוי שהוזכרו במאמר.