תוכן עניינים:
אז אתם והחברה שלכם תכננתם את המסע שלכם לענן, וצעד מרכזי כרוך בווירטואליזציה של השרתים שלכם בכדי להיפטר מכל אותה חומרה מגושמת באתר. אבל אולי אינך בטוח איפה להתחיל, או שאתה זקוק לעזרה בזיהוי שיטות העבודה המומלצות בכל הקשור להגדרת ה- VMs החדשים שלך. ריכזתי את שלושת הטיפים המובילים שלי להפיכת וירטואליזציית השרת לאפקטיבית וללא כאבים ככל האפשר. עצות אלה יסייעו לכם להימנע ממני להימנע מאבני נגף פוטנציאליות, כך שתוכלו להקדיש פחות זמן להקמה ויותר זמן להתמקד בשרת העסק.
טיפ מספר 1: גודל בחוכמה
זה נשמע הגיוני להשיג את ה- VMs הקיבולת הגדולה ביותר האפשרית שתתאים לעומס עבודה בכל גודל, נכון? לא כל כך מהר. אספקת יתר של מעבדים על גבי VM יכולה למעשה להחמיר את הביצועים, לא להיות טובים יותר. באופן כללי, הקצאות ה- CPU שלך צריכות להתאים לניצול. אם השרת אינו צורך משאבים במלואו, הוא מספק יותר מדי יתר עלול להשפיע על הביצועים. אם אתה זקוק למשאבים נוספים מאוחר יותר, אתה תמיד יכול להרחיב ולהוסיף משאבי שרת נוספים. בצד השני של המטבע, וודא שאתה לא מגזים במארחים שלך - מדדים כמו בלוני זיכרון ומוכנים ל- CPU הם אינדיקטורים מוקדמים לכך שהמארח מגיע לגבול שלו. (למידע נוסף על יעילות VM, ראה 5 דברים שיכולים לגרום למצב של תשתית וירטואלית.)
טיפ מס '2: הישאר N + 1 מיותר
הכלל "שניים הוא אחד ואחד אינו" בהחלט חל כאן. יתירות N + 1 היא הכרחית כדי להבטיח השבתה מינימלית אם אחד המארחים שלכם יעלה בבטן. קיימת כאן תפיסה שגויה ש- VMs אינם רגישים לבעיות דומות בהן אתה עלול להיתקל בשרת פיזי. למעשה, יתירות חשובה עוד יותר אם כל אחד מהמארחים שלך מריץ מספר VMs. בנוסף לשמירה על חלפים חמים וחמים, חילוף קר מאפשר לך להחזיר את הגנת ה- N + 1 שלך מייד אם וכאשר מתרחש מארח לקוי וזקוק לתיקון. אמנם ביצוע המעבר משרתים פיזיים עשוי לחסוך לך כאבי ראש רבים בכל הקשור לניהול אירועים ופתרונותיהם, אך עדיין תרצה שיהיה מארח גיבוי, ועוד אחד, "גיבוי לגיבוי" כביכול.
