חישוב דפוסי טעינה
- 13 דקות
אם תעבורה למשאב ענן כגון VM (או קבוצה של מחשבים וירטואליים) או יישום אינטרנט היו קבועים וביטול שינוי, לא היה צורך לשנות את קנה המידה. מנהל ענן יכול פשוט להקצות את מספר המופעים הדרושים כדי לטפל בטעינה ולבצע אותה. אך דפוסי אינם לאורך זמן - לעתים צפויה, ולפעמים לא. בעולם האמיתי, מנהל מערכת חייב לאבחן את העומס על המשאבים שהיא מנהלת ולהשתמש בקנה מידה כדי להבטיח שהמערכת תוכל לעקוב אחר הביקוש.
לפני שנדון באופן קנה המידה, על את קנה המידה שלנו על-ידי שבירת כמה מתבניות הטעינה הנפוצות שמחשבים וירטואליים ומשאבי ענן אחרים חווים.
צמיחה עקבית
אחד מניעי הפעילויות הנפוצים ביותר לצורך בקנה מידה גדול הוא צמיחה עקבית לפי דרישה. איור 1 מציג את התעבורה לאתר האינטרנט של חברה לאורך תקופה של 24 חודשים. החברה גדלה במהירות, והתעבורה לאתר האינטרנט שלה משקפת זאת. אם נניח כי שרת אינטרנט אחד יכול לטפל ב- 5,000 בקשות ליחידת זמן, החברה מתחילה בשלושה או ארבעה שרתי אינטרנט, אך צריכה כ- 20 שנתיים מאוחר יותר כדי להתעדכן בביקוש הולך וגדל ולהמשיך לספק ללקוחותיה שירות טוב.
איור 1: צמיחה עקבית.
צמיחה עקבית היא בין דפוסי העומס הקלים ביותר כדי לפצות על מכיוון ששינוי הוא יציב והדרגתי. סביר להניח שנוכל לשנות את קנה המידה באמצעות שרתים פיזיים מאחר שנוכל לצפות מתי יהיה צורך בשרת הבא (או קבוצת שרתים) ויש לנו שבועות אם לא חודשים להתכונן, אך מיחשוב ענן מאפשר לנו להעביר שרתים וירטואליים חדשים למצב מקוון תוך דקות ספורות. בעוד שמגמה של 24 חודשים מציגה צמיחה יציבה וצפויה, העומס עשוי לרהות באופן משמעותי במהלך תקופות זמן קצרות יותר. מיחשוב ענן מסתגל הרבה יותר למיקרו-מגמות מאשר שינוי קנה מידה עם שרתים פיזיים.
עומסים מתנודות ללא הרף
הגמישות המהירה המוצעת על-ידי מיחשוב ענן חיונית כאשר הטעינה תנודות באופן בלתי צפוי לאורך פרקי זמן קצרים יחסית. איור 2 מציג את העומס באתר אינטרנט לאורך תקופה של 24 שעות. פעם נוספת, בהנחה שהשרת אחד יכול לטפל ב- 5,000 בקשות ליחידת זמן, מספר השרתים הדרושים משתנה משניים עד 16 לאורך היום. נוכל להכיל תעבורה זו על-ידי שמירת 16 שרתי אינטרנט וירטואליים במצב מקוון בכל עת, אך זכור כי ספקי שירותי הענן מחייבים עבור מחשבים וירטואליים גם כאשר הם לא פעילים. הקיבולת העודף לא רק מבזבזת אנרגיה, אלא גם מכפילה בערך את העלות.
איור 2: עומס מתנוון ללא הרף.
עומסים מחזוריים
איור 3 מציג עומס שגדל ופחת בתבנית רגילה וצפויה במידת מה - לדוגמה, הביקוש עולה במהלך שעות העבודה והוא חוזר בשעות הערב ובלילה. שיאו, עומס זה דורש כ- 20 שרתים לטפל בביקוש, בהנחה נוספת 5,000 בקשות ליחידת זמן לשרת. לא הגיוני לסובב שרתים פיזיים בתוך ויציאה של 24 שעות ביום, אך ניתן להקצות ולבטל בקלות הקצאה של שרתים וירטואליים בלוח זמנים כדי לוודא שקיבולת השרת שווה לביקוש. שרתים פיזיים היושבים במצב לא פעיל או מנוצלים 12 שעות ביום מייצגים CapEx בלתי רצוי וצריכת אנרגיה מיותרת. שרתים וירטואליים מגיעים גם הם בעלות, אך ניתן לבטל את הקצאתם כאשר הם אינם נדרשים וניווצרו שוב במהירות כאשר הביקוש דורש זאת.
איור 3: עומס מחזורי החוזר כל 24 שעות.
רצף בלתי צפוי
אחת התבניות הקשות ביותר להתמודד איתם מתוך נקודת המתנה של עלות ותחזוקה היא תבנית שגורמת להתפרצויות בלתי צפויות (איור 4). אם פסגות הן צפויות - לדוגמה, אם אתר האינטרנט מגיש שירות משלוח פיצה שנוהג בטעינה גבוהה יותר בסופי שבוע ובחגים - ניתן לתכן קיבולת נוספת. אבל אם הם לא ניתנים לחיזוי, עלינו להיות מוכנים לטפל בהם בכל עת.
איור 4: רצף בלתי צפוי.
אנו עשויים לחזות עלות עודפת (העלות של שרתים שהוקצו לטיפול בעומס שיא, אך הם לא פעילים יחסית בזמנים של תעבורה נמוכה יותר) כאזור שבין החלק העליון של העקומה לבין קו אופקי שצויר דרך הנקודה הגבוהה ביותר. במקרה זה, העלות של אספקת קיבולת של 100,000 בקשות ליחידת זמן עבור העומס באיור 4 גבוהה באופן משמעותי מהעלות של אספקת קיבולת שווה ערך באיור 3.
אם נוכל לצפות את סדר הביקוש המרבי (לא בהכרח את התזמון שלו) ולא אכפת לנו מהעלויות, נוכל לספק קיבולת נאותה בכל עת על-ידי הקצאת מספיק שרתים כדי לטפל בטעינה הגבוהה ביותר. מיחשוב ענן מאפשר לנו להעביר משאבים למצב מקוון כאשר הם נדרשים ולהוביל אותם למצב לא מקוון (ולהפסק את קבלת החיובים עבורם) כאשר הם אינם נדרשים. גמישות מופעלת על-ידי שינוי קנה הענן. בואו נבחן את המושג של שינוי קנה מידה מקרוב, ובדוק מדוע הוא גורם מרכזי בכלכלה של מיחשוב ענן.
בדוק את הידע שלך
משוב
האם עמוד זה היה מועיל?
לא
זקוק לעזרה בנושא זה?
רוצה לנסות להשתמש ב'שאל את Learn' כדי להבהיר או להדריך אותך בנושא זה?