תשתית מקומית וענן: חסכון – צו השעה

Print Friendly, PDF & Email

כמעט בכל חברה מגיע מצב שאחת הסיטואציות הבאות מתרחשות:

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

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

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

אז איך בעצם ניתן לחסוך?

בכל הקשור לתשתית מקומית, ההמלצה שלי במקרים רבים היא לפני שאצים רצים לרכוש שרתים חדשים לדוגמא, לשדרג את הקיימים. תחליפו מעבדים לכאלו עם יותר ליבות, תוסיפו זכרון, אם אתם עובדים עם דיסקים מקומיים – תחליפו אותם ל-SSD טובים וכו'. אם לדוגמא רכשתם (בחוכמה) שרתים כמו של חברת SuperMicro, אז אתם בכלל יכולים לעבור קדימה דור של מעבדים (לדוגמא: V3 ל-V4 או Xeon SP דור ראשון לדור שני) – כלומר בלא מעט מקרים ניתן לשדרג תשתית קיימת של שרתים ולהרוויח ביצועים יותר גבוהים, וזאת במחיר קטן בהרבה מרכישת שרת חדש (מה גם שהשדרוג נתמך לחלוטין על ידי היצרן והמפיץ)

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

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

  • להפסיק לחשוב על הענן הציבורי כ-DC פרטי שלנו. ב-VMware, כשמקימים מכונה מקומית וכשאתה מגדיר VM עם 16 ליבות או חצי טרה אחסון (ב-Thin Provisioning) – אז המערכת תהיה מספיק חכמה לתת לך משאבים, אבל לא לחסום את המשאבים הללו משימוש מכונות VM אחרות. בענן ציבורי – אתה משלם על כך, גם אם השתמש באחסון ב-2% ובמעבד ב-4%, אתה תשלם כאילו ניצלת את הכל, אז במקרים כאלו, כדאי לשנות Instance או לבנות אותה מחדש עם משאבים יותר מצומצמים.
  • לנטר ולצמצם – כלים כמו Terraform יודעים היטב לתמוך בכל ספקי הענן הציבורי. נכון, זה לא בדיוק "קליק קליק קליק" אבל בהחלט שווה להשקיע וללמוד ואז להתחיל להריץ את זה על החשבון שלכם ולמצוא מה המשאבים שאינם מנוצלים, דברים שהוגדרו בפראות אבל לא ממש משומשים וכו' – ומשם להחליט מה לעשות עם זה. החסכון בשיטה הזו – גדול מאוד.
  • להפסיק להתעצל! אתה צריך SQL שכל מה שמתחבר אליו זה client ורבע? תקים קונטיינר או Instance כזה בעצמך במקום להשתמש בשרות מנוהל. זה יותר זול. נכון, צריך להשקיע קצת יותר בהקמה והגדרה, אבל זה חוסך בטווח הארוך.
  • לעבור לקונטיינרים במקום מכונות וירטואליות – קונטיינר תופס פחות משאבים, ניתן לרפלק, ויש לו Scaling מעולה. אה, ובחישוב סופי, זה יוצא יותר זול.
  • לבחור תוכנות אחרות שהן יותר "Native" לענן – תוכנות שיודעות לאחסן ב-Object Storage לדוגמא, שהוא הרבה יותר זול מאחסון שמחובר ל-Instance, וזו רק דוגמא אחת.
  • לכבות מכונות – מכונה כבויה עולה הרבה פחות ממכונה פעילה (אתה עדיין צריך לשלם על האחסון שהיא תופסת), אז אולי הגיע הזמן לאיזה סקריפט קטן שרץ על כל המכונות ומכבה כאלו שלא עושות כלום, ואגב, עדיף להגדיר עם Terraform שמכונות מסויימות יכובו אוטומטית (או ימחקו) לאחר זמן מה, כמו מכונות טסטים שהוקמו זמנית ושכחו מהן.

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

Comments

comments

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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