ארגון קונה שרת אחד גדול, מריץ עליו ארבע מכונות וירטואליות, ותוך חצי שנה מגלה שהזיכרון נגמר לפני שהמעבד בכלל התחמם. זו הטעות הנפוצה ביותר בוירטואליזציה לעסקים: קונים לפי תחושה, לא לפי חישוב. שרת שקנוי במידה נכונה חוסך אלפי שקלים ומונע את הרגע הלא נעים שבו צריך להשבית את כל המערכת כדי להוסיף רכיב שהיה אמור להיות שם מלכתחילה.
המדריך הזה הוא כלי, לא רשימת מפרטים. הוא לוקח אתכם דרך התהליך שמנהל רכש או מנהל IT צריך לרוץ עליו לפני שהוא מבקש הצעת מחיר: מה זו וירטואליזציה בפועל, אילו משאבים באמת קובעים כמה מכונות ירוצו, איך אומדים את המספר, וכמה מרווח ביטחון להשאיר. בסוף תדעו לתרגם "אני צריך להריץ בערך עשר מכונות וירטואליות" למפרט שרת קונקרטי — טאואר או ראק — של Lenovo ThinkSystem.
קודם כול — מה קורה בפועל כשמריצים וירטואליזציה
וירטואליזציה היא הרעיון שמפריד בין השרת הפיזי לבין מערכות ההפעלה שרצות עליו. במקום מחשב אחד עם Windows אחד, יש שכבת תוכנה דקה שנקראת היפרוויזור, והיא מחלקת את המשאבים הפיזיים — ליבות מעבד, זיכרון, אחסון, כרטיסי רשת — בין כמה מערכות הפעלה נפרדות שרצות במקביל. כל אחת מהן היא מכונה וירטואלית (VM), והיא "חושבת" שיש לה מחשב משלה.
המשמעות העסקית פשוטה. שרת פיזי בודד יכול להחליף חמישה, עשרה או עשרים שרתים ישנים שכל אחד מהם עמד בפינה וניצל עשרה אחוזים מהכוח שלו. במקום להחזיק שרת קובץ, שרת דומיין, שרת אפליקציה ושרת גיבוי כארבע קופסאות ברזל נפרדות — כולם רצים כארבע מכונות וירטואליות על אותה קופסה אחת. זה חוסך חשמל, מקום, ורישוי, ומאפשר לגבות מכונה שלמה כקובץ בודד ולשחזר אותה על חומרה אחרת תוך דקות.
[מיקום מומלץ לתמונה]
נושא התמונה: תרשים סכמטי של שרת פיזי אחד עם היפרוויזור המריץ מספר מכונות וירטואליות.
תיאור התמונה: איור המראה שרת פיזי בתחתית, שכבת היפרוויזור מעליו, ומעליה ארבע-חמש מכונות וירטואליות נפרדות, כל אחת עם אייקון מערכת הפעלה משלה.
טקסט ALT מוצע: תרשים וירטואליזציה לעסקים – שרת פיזי אחד המריץ כמה מכונות וירטואליות דרך היפרוויזור.
שלב 1 — זיהוי המשאב שיגמר לכם ראשון
לשרת יש ארבעה משאבים שמכונות וירטואליות מתחלקות עליהם, ולכל אחד תפקיד אחר. הטעות היא להתמקד בזה שהכי קל לספור (מספר הליבות) ולהזניח את זה שבאמת נגמר קודם (הזיכרון). נעבור עליהם לפי סדר החשיבות בפועל.
זיכרון (RAM) — צוואר הבקבוק כמעט תמיד. זה המשאב שנגמר ראשון ברוב הפריסות. כל מכונה וירטואלית צורכת זיכרון פיזי אמיתי לפי מה שהוקצה לה: אם הקצתם ל-VM שמונה ג'יגה-בייט, השרת מפריש עבורה שמונה ג'יגה מהזיכרון הפיזי, בין אם היא עסוקה ובין אם לא. את המעבד אפשר לחלק בזמן — שתי מכונות יכולות "להתחלף" על אותה ליבה — אבל את הזיכרון קשה הרבה יותר לחלוק. לכן ברגע שסוכמים את הקצאות הזיכרון של כל המכונות, מגיעים לתקרה מהר. שרתי ThinkSystem דו-מעבדיים מודרניים בונים על זה: ה-SR650 V3, למשל, כולל 32 חריצי זיכרון ותומך עד 8 טרה-בייט זיכרון TruDDR5 כשמאכלסים אותם ב-DIMM בנפח 256 ג'יגה — קיבולת שנועדה בדיוק לפריסות וירטואליזציה צפופות.
מעבד — ליבות ו-threads. כאן חשוב להבין את ההבדל בין ליבה פיזית ל-vCPU. מעבד שרת מודרני מציג לכל ליבה שני מסלולי ביצוע (threads, בטכנולוגיית Hyper-Threading של אינטל), וההיפרוויזור מקצה למכונות הווירטואליות vCPU — מעבדים וירטואליים. אפשר להקצות יותר vCPU מסך הליבות הפיזיות, כי לא כל המכונות עמוסות באותו רגע; יחס הקצאה נפוץ לעומסים משרדיים רגילים נע בין 3:1 ל-8:1 vCPU לכל ליבה פיזית. לעומס כבד וקבוע — בסיס נתונים תובעני, שרת טרמינל עם עשרות משתמשים — היחס יורד וקרוב יותר ל-1:1. מעבדי הדור החמישי של Intel Xeon Scalable מגיעים עד 64 ליבות למעבד, כך ששרת דו-מעבדי כמו ה-SR650 V3 מגיע עד 128 ליבות פיזיות בקופסה אחת.
אחסון — מהירות, לא רק נפח. כאן טועים הרבה. כשעשר מכונות ניגשות לאותם דיסקים בו-זמנית, דפוס הגישה הופך אקראי לחלוטין — מה שמכונה בעגה I/O blender. דיסקים מכניים מסורתיים קורסים תחת עומס כזה, ולכן וירטואליזציה רצינית נבנית על כונני SSD, ורצוי NVMe שמתחברים ישירות לאפיק PCIe. ה-SR650 V3 תומך עד 40 כונני 2.5 אינץ' ועד 36 כונני NVMe, כך שאפשר לבנות מערך מהיר שיעמוד בעומס מקבילי בלי שהאחסון יהפוך לצוואר הבקבוק.
רשת (NICs) — כרטיסי רשת. כל התעבורה של כל המכונות הווירטואליות עוברת דרך כרטיסי הרשת הפיזיים של השרת. בפריסה עסקית רוצים לפחות שני חיבורים — אחד ליתירות ואחד להפרדת תעבורת ניהול, גיבוי או אחסון מרשת המשתמשים. אם האחסון עצמו יושב על רשת (iSCSI לעבר NAS או SAN), החיבור הזה חייב להיות מהיר ומופרד, אחרת הגיבוי בלילה יחנוק את שאר התעבורה.
[מיקום מומלץ לתמונה]
נושא התמונה: ארבעת משאבי השרת בווירטואליזציה — מעבד, זיכרון, אחסון ורשת.
תיאור התמונה: אינפוגרפיקה עם ארבעה אייקונים המסמנים CPU, RAM, אחסון SSD ו-NIC, כשליד הזיכרון מסומן דגל "צוואר הבקבוק הנפוץ".
טקסט ALT מוצע: ארבעת המשאבים שקובעים כמה מכונות וירטואליות שרת יכול להריץ.
שלב 2 — אמידת מספר המכונות שהשרת יריץ
אין נוסחה קסומה שאומרת "שרת X מריץ בדיוק 20 מכונות". המספר תלוי כולו במה שרץ בתוך המכונות, ולכן האומדן נבנה מלמטה למעלה. הנה הסדר.
ראשית, פרטו כל מכונה מתוכננת בשורה משלה, עם שלושה נתונים: כמה vCPU היא צריכה, כמה זיכרון, וכמה אחסון. שרת דומיין קטן יסתפק ב-2 vCPU ו-4 ג'יגה זיכרון; שרת קבצים ל-30 עובדים ידרוש אולי 4 vCPU ו-8–16 ג'יגה; בסיס נתונים תובעני עשוי לבקש 8 vCPU ו-32 ג'יגה ומעלה. אל תנחשו במעורפל — עדיף אומדן זהיר לכל מכונה בנפרד.
שנית, סכמו. חברו את כל הזיכרון שהקצתם — זה המספר שקובע את תקרת השרת, כי כאמור זיכרון לא נדחס. הוסיפו עליו כ-10 עד 20 אחוז לתקורת ההיפרוויזור עצמו, שגם הוא צורך זיכרון לניהול. אם סכום הזיכרון של המכונות הוא 96 ג'יגה, כוונו לשרת עם 128 ג'יגה לפחות — ולא בגלל היום, אלא בגלל השנה הבאה.
שלישית, בדקו את המעבד מול היחס. חברו את כל ה-vCPU, החילו יחס הקצאה שמרני שמתאים לעומס שלכם, וכך תגיעו למספר הליבות הפיזיות הנדרש. דוגמה קונקרטית: עשר מכונות משרדיות טיפוסיות עם ממוצע 2 vCPU כל אחת הן 20 vCPU; ביחס שמרני של 4:1 זה חמש ליבות פיזיות בלבד — כלומר המעבד כמעט אף פעם לא הבעיה בפריסה קטנה. הזיכרון של אותן עשר מכונות, לעומת זאת, עשוי בקלות לגעת ב-64–80 ג'יגה. זו בדיוק הסיבה שקונים לפי זיכרון.
שלב 3 — מרווח ביטחון: תכנון לכשל, לא רק לשגרה
שרת שממולא עד 95 אחוז מנוצל הוא שרת שאין לו לאן לגדול, ומסוכן עוד יותר — אין לו לאן ליפול. שני סוגי מרווח צריך לתכנן מראש.
מרווח לצמיחה. כלל אצבע מעשי: תכננו את השרת כך שאחרי שכל המכונות המתוכננות רצות, עדיין נותרו כ-25–30 אחוז מהזיכרון ומהמעבד פנויים. עסק שגדל מוסיף מכונה חדשה כמעט בלי לתכנן — אפליקציה חדשה, סביבת בדיקות, שרת נוסף — והמרווח הזה הוא ההבדל בין "מוסיפים VM בחמש דקות" ל"צריך לקנות שרת".
מרווח לכשל (יתירות ו-HA). כאן נמצא ההבדל הגדול בין תחביב לתשתית עסקית. אם כל המכונות רצות על שרת פיזי אחד, השרת הזה הוא נקודת כשל בודדת — הוא נופל, והכול נופל איתו. עסק שתלוי בשרת מריץ לכן שני מארחים (או יותר), עם היפרוויזור שיודע לבצע High Availability: אם מארח אחד קורס, המכונות שלו מופעלות מחדש אוטומטית על המארח השני. הקריטי להבנה: במצב כזה כל מארח חייב לרוץ בשגרה על חצי כוח בלבד, כי בזמן כשל הוא צריך לשאת גם את העומס של חברו. שני שרתים שכל אחד מנוצל 50 אחוז זו לא בזבזנות — זו בדיוק המשמעות של יתירות.
[מיקום מומלץ לתמונה]
נושא התמונה: מעבר של מכונות וירטואליות ממארח שקרס למארח תקין בזכות HA.
תיאור התמונה: שני שרתים זה לצד זה; חץ מראה מכונות וירטואליות עוברות מהשרת השמאלי (מסומן בכשל) לשרת הימני שממשיך לפעול.
טקסט ALT מוצע: יתירות שרתים – העברת מכונות וירטואליות בין מארחים בזמן כשל בזכות High Availability.
שלב 4 — בחירת ההיפרוויזור
ההיפרוויזור הוא שכבת התוכנה, לא החומרה, אבל הוא משפיע על הבחירה כי הוא קובע את הרישוי ואת יכולות ה-HA. שלוש המשפחות הנפוצות: VMware vSphere/ESXi — הבשל והנפוץ ביותר בארגונים, עם יכולות ניהול ו-HA עשירות ורישוי בתשלום; Microsoft Hyper-V — משתלב מצוין בסביבות Windows Server וכלול ברישוי המערכת; ו-Proxmox VE — פתרון קוד פתוח שצובר פופולריות בעסקים קטנים ובינוניים בזכות עלות נמוכה. לכל אחד יתרונות בהקשר אחר, והבחירה נגזרת מהסביבה הקיימת ומהתקציב יותר מאשר מהשרת עצמו. שרתי ThinkSystem נבדקים ומאושרים לעבודה עם ההיפרוויזורים המרכזיים, כך שהחומרה לא מגבילה את הבחירה.
שלב 5 — טאואר או ראק: תרגום המספר לקופסה
אחרי שיש בידכם מספר — כך וכך זיכרון, כך וכך ליבות, כזה וכזה מרווח — נשארת שאלת הצורה. ההבדל בין טאואר לראק הוא לא רק פיזי; הוא משקף כמה אתם מתכוונים לגדול.
טאואר הוא שרת בצורת מגדל שיושב על הרצפה או על שולחן, בלי צורך בארון תקשורת ייעודי. הוא שקט יחסית, מתאים למשרד בלי חדר שרתים, והוא הבחירה הטבעית לעסק קטן שמריץ מספר מצומצם של מכונות. בקצה הכניסה, ThinkSystem ST250 V3 הוא שרת חד-מעבדי המבוסס על Intel Xeon 6300-series או E-2400, עם עד 8 ליבות, ארבעה חריצי זיכרון ותקרה של 128 ג'יגה זיכרון. זה מספיק בהחלט לכמה מכונות וירטואליות קלות — שרת דומיין, שרת קבצים, אולי אפליקציה קטנה — אבל התקרה של 128 ג'יגה מזכירה שוב שהזיכרון הוא הגבול, ושמדובר בפתרון כניסה ולא בפלטפורמת צמיחה.
ראק הוא שרת שטוח שמותקן בארון תקשורת סטנדרטי ברוחב 19 אינץ', ונמדד ביחידות גובה (U). הוא צפוף, קל לתחזוקה מסודרת של כמה שרתים יחד, ובנוי לצמיחה. ThinkSystem SR650 V3, למשל, הוא שרת דו-מעבדי בגובה 2U שתומך עד 64 ליבות למעבד (עד 128 ליבות בשרת), 32 חריצי זיכרון עד 8 טרה-בייט, ועד 40 כונני 2.5 אינץ'. זו פלטפורמה שנועדה לרכז עשרות מכונות וירטואליות, ולעבוד בזוג עם שרת נוסף לצורך HA. אם אתם מתכננים לגדול, לפרוס שני מארחים ליתירות, או להריץ עומסים כבדים — הכיוון הוא ראק, גם אם היום נדמה שטאואר מספיק.
[מיקום מומלץ לתמונה]
נושא התמונה: השוואה ויזואלית בין שרת טאואר ThinkSystem לשרת ראק ThinkSystem.
תיאור התמונה: שני שרתי Lenovo ThinkSystem זה לצד זה — טאואר עומד משמאל, שרת ראק 2U מותקן בארון תקשורת מימין.
טקסט ALT מוצע: שרת Lenovo ThinkSystem טאואר מול ראק לווירטואליזציה בעסק.
דוגמה מרוכזת: עסק עם עשר מכונות וירטואליות
נריץ את התהליך על מקרה אחד. עסק בינוני רוצה לרכז עשר מכונות: שני שרתי דומיין, שרת קבצים, שרת אפליקציה, בסיס נתונים, שרת דואר פנימי, שני שרתי בדיקות ועוד שניים קלים. סכום הזיכרון המבוקש יוצא כ-80 ג'יגה. מוסיפים תקורת היפרוויזור ומרווח צמיחה — מגיעים ליעד של כ-128 ג'יגה למארח. סכום ה-vCPU הוא כ-28; ביחס שמרני זה מתחת ל-16 ליבות פיזיות בקלות. עד כאן, שרת בודד בינוני מספיק בשגרה.
אבל אם העסק לא יכול להרשות לעצמו שהכול ייפול יחד — והוא לרוב לא יכול — התכנון האמיתי הוא שני מארחי ראק, כל אחד עם 128 ג'יגה, שרצים בשגרה בחצי עומס ומוגדרים ל-HA. זה כבר לא "כמה מכונות נכנסות בשרת", אלא "כמה מכונות נכנסות בשרת אחד כשהשני מת" — וזו השאלה שמפרידה תכנון תשתית מרכישה אימפולסיבית.
רוצים לתרגם את מספר המכונות שלכם למפרט מדויק?
הפער בין "צריך בערך עשר מכונות" למפרט שרת נכון הוא בדיוק המקום שבו כדאי לדבר עם מי שעושה את זה שנים. אנחנו ב-MDS מלווים עסקים בצפון ובכל הארץ בבחירת שרתי Lenovo ThinkSystem לפי עומס אמיתי — סופרים איתכם את הזיכרון והליבות, מתכננים יתירות ומרווח צמיחה, ומתאימים טאואר או ראק למה שבאמת תריצו, לא למה שנשמע מרשים בקטלוג. כאמצע שירות מוסמך של Lenovo, אנחנו גם עומדים מאחורי החומרה לאורך חייה. חייגו 04-8211416, כתבו ל-mds@mds.co.il, או קפצו אלינו לדרך השלום 9, נשר — ונבנה יחד מפרט שיחזיק גם את הצמיחה הבאה שלכם.
שאלות ותשובות
איזה משאב הכי חשוב בשרת לווירטואליזציה?
ברוב הפריסות העסקיות הזיכרון (RAM) נגמר ראשון, כי כל מכונה תופסת זיכרון פיזי קבוע שקשה לחלוק בין מכונות. לכן מומלץ לגזור את גודל השרת לפי סכום הזיכרון של כל המכונות הווירטואליות, בתוספת תקורת היפרוויזור ומרווח צמיחה.
כמה מכונות וירטואליות אפשר להריץ על שרת אחד?
אין מספר קבוע — זה תלוי כולו במה שרץ בתוכן. מכונות משרדיות קלות דורשות מעט, בסיסי נתונים ושרתי טרמינל דורשים הרבה. האומדן נבנה מלמטה: סוכמים זיכרון ו-vCPU של כל המכונות ובודקים מול קיבולת השרת ומרווח הביטחון.
האם שרת טאואר מתאים לווירטואליזציה?
כן, לעסק קטן עם מספר מצומצם של מכונות. שרת טאואר חד-מעבדי כמו ThinkSystem ST250 V3 מריץ בנוחות כמה מכונות קלות. לצמיחה, לעומסים כבדים או ליתירות בין שני מארחים — עדיף לעבור לשרת ראק דו-מעבדי.
למה כדאי שני שרתים ולא אחד גדול?
שרת בודד הוא נקודת כשל בודדת: אם הוא נופל, כל המכונות נופלות איתו. שני מארחים עם High Availability מריצים מחדש אוטומטית את המכונות של מארח שקרס על המארח השני — ולכן כל מארח רץ בשגרה בכ-50 אחוז ניצול, כדי שיהיה לו כוח לשאת גם את העומס של חברו בעת כשל.
