על אחסון, וירטואליזציה, ובעיות ביצועים

כמעט כל ארגון שמריץ פתרון וירטואליזציה (vSphere, Hyper-V, Xen, ואחרים) בדרך כלל משתמש בפתרון אחסון משותף לשרתים, בין אם מדובר בפתרון "הרכבה עצמית" (FreeNAS), פתרון קופסתי זול (Synology, Asustor, QNAP וכו') ובין אם מדובר במשהו קצת יותר גדול מצד חברות כמו HPE, IBM, Lenovo, Dell, NetApp, EMC וכו'. יש פתרון לכל תקציב.

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

אפשר לקטלג את סוגי התקלות ל-2 סוגים עיקריים. לסוג הראשון אני קורא "תקלות אבסולוטיות" ולסוג השני – "תקלות מעורפלות".

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

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

אני רוצה לתת דוגמא מה-LAB שלי. לפניכם צילום מסך מתוך מכונת VM ב-vSphere 6.7 שמריצה Windows 10 עם Crystal Diskmark 7. השרתים מחוברים לשרת ZFS עם 8 דיסקים מכניים ואין בו שום SSD, בחיבור 10 ג'יגהביט +SFP. על הנייר, כל מי שמבין באחסון, יאמר שהמספרים מעולים – 1.2 ג'יגהבייט קריאה/כתיבה על חיבור של 10 ג'יגהביט – זה המקסימום שאפשר לקבל.

הסיבה שהרצתי את אותה בדיקה בצילום מסך היתה קשורה לבעיה אחרת: כל מכונת VM שכיביתי או הפעלתי מחדש – עלתה בצורה מאוד איטית. זה לא היה קשור לשרתים כי לא היה עומס עליהם וגם כשביצעתי Migrate ל-VM לשרת אחרת והפעלתי מחדש, היתה אותה איטיות. בשרת ZFS לא היה שום עומס, וגם הסוויצ' לא דיווח של איטיות או הצפה כלשהי, ובכל זאת – אתם רואים את המספרים לעיל, לא רואים בעיה.

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

המקרים היותר מסובכים קשורים לכך שמריצים מכונות VM שונות שפותחות/יוצרות/קוראות אלפי קבצים בזמן קצר והאחסון לא ממש יודע לעמוד בכך (במיוחד כשמריצים RDS כ-VM עם אחסון מבוסס דיסקים מכניים) ואז כשמנסים להבין מדוע הדברים איטיים – כל גוף יפיל את זה על השני: ספק האחסון על ספק פתרון הוירטואליזציה, ספק פתרון הוירטואליזציה על מיקרוסופט ומיקרוסופט – על כולם. אז איך פותרים את זה?

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

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

  • הדבר הראשון שאני ממליץ, זה להשתמש בכלי בשם FIO. את הקוד של הכלי הזה אני ממליץ לקמפל באופן סטטי (בשימוש הפרמטר build-static– ), לפתוח תיקיה ב-Datastore כלשהו ולהעלות את הקובץ FIO הבינארי שקומפל לשם, ולוודא שיש לו הרשאות Executable. את הקובץ נריץ דרך SSH.
    הכלי (FIO) נותן לנו למדוד את מהירות הקריאה והכתיבה שיש לנו עם מדדים ופרמטרים שונים ובכך נוכל לדעת מהי מהירות הקריאה והכתיבה בין האחסון לשרת עצמו ישירות. כך נוכל לדעת אם הבעיה קשורה בתקשורת בין האחסון לשרת ולא בין האחסון למכונת VM כלשהי. חשוב: לבצע את הבדיקה עם כמה שפחות מכונות VM רצות על אותו שרת.
  • אנחנו יכולים להשתמש באותו כלי (ולחובבי Windows – יש את IOMeter שמבוסס על הקוד של FIO. את הכלי הזה, אגב, אפשר להריץ ישירות על Windows Server פיזי אם מדובר במכונה שנותנת שרותים דרך Hyper-V) כדי למדוד את אותם דברים שמדדנו קודם – אך הפעם אנחנו נמדוד בין מכונת ה-VM לאחסון, תוך שימוש ב-Datastore ובדיסק הקשיח הוירטואלי של אותו VM. שימו לב: התוצאות יכולות להיות שונות מהתוצאות שנקבל כתוצאה מבדיקה דרך הסעיף הקודם, הואיל והתרגום לדיסק הוירטואלי גובה מספר אחוזים בביצועים.
  • אם אתם מאלו שאוהבים כמה שיותר DATA כדי לאסוף כמה שיותר תובנות, בנו לעצמכם סקריפט שמשתמש ב-FIO כדי לבצע דגימות שונות ולאסוף את הנתונים לקובץ מסוים כדי לנתח אחר כך ולבדוק דגרגציה של פתרון האחסון ועוד.
  • אם הבעיה קיימת רק עם מכונות VM מסויימות, אז הבעיה אינה ממש קשורה לתקלות באחסון אלא יותר בכח של פתרון האחסון. הגיע הזמן להחליף למשהו יותר לכיוון ה-All Flash או לפחות עם פתרון Flash לכתיבה ו-Caching.
  • זה ישמע טריוואלי – אבל תפרידו תקשורת ברמה של פורטים ואם אפשר גם ברמה של סוויצ' – בין התקשורת מהאחסון לשרתים, לבין כל שאר הדברים. אני משער שחלק מהקוראים יאמרו "מה הבעיה עם VLAN?", אין בעיה – רק שבמקרים רבים אותם אלו שמגדירים נוטים לחתוך פינות ולפעמים ההגדרות לא יהיו נכונות ולא יסייעו. מצד שני – סוויצ' 10 ג'יגה כיום הוא דבר די זול.
  • דבר אחרון – כלים רגילים שמודדים ביצועים של דיסקים מכניים או SSD לא רלוונטיים במקרים של התקלות המדוברות בפוסט זה. זה נחמד להציג תמונות (או כדי למכור ללקוחות מצגת על פתרון) אבל התוצאות לא יהיו באמת נכונות (אתם באמת חושבים שמכונת ה-ZFS  הנ"ל בפועל יכולה לכתוב 1.2 ג'יגה בשניה בשעה שאין שום SSD? לא ממש, אבל ZFS יכול "לעבוד" על VMWare ובכך אפשר להציג את התוצאות הנ"ל, אם יש מספיק RAM בשרת, ובמקרה הזה – יש, 256 ג'יגה).

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

ברמת המאקרו: vSAN מול Nutanix

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

נתחיל מבחינת תכונות תמוהות: גם ב-vSAN וגם ב-Nutanix יש החלטות שאני לא יודע כמה אלכוהול שתה אותו מנהל לפני שהחליט להורות למפתחים שלו לכתוב/להשתמש בדברים מסויימים. אם ניקח לדוגמא ב-Nutanix את השימוש ב-Zookeeper כדי לשמור הגדרות בין Nodes שונים – האם הבחור התחלק על השכל? מה רע ב-etcd לאותו שימוש? וב-vSAN – קבוצות דיסקים מסוג All Flash כשהכתיבה נזרקת לדיסק יחיד כ-Write Buffer וגם הוא מוגבל ל-800 ג'יגה?? הרי לא מסובך ליצור מעין RAID-1 בין 2 SSD מסוג Mixed וכך אפשר למנוע נפילה של Disk Group רק בגלל נפילת SSD.

הרעיון של Nutanix לתמוך הן ב-Hypervisor של אחרים והן משלהם (AHV, עדיין בפיתוח וחסרים בו פונקציות רבות שכן קיימות ב-KVM, כמו שיתוף קבצים בין מכונות VM, דבר די חדש, מצגת על כך כאן) הוא רעיון לא רע, הרשיון שלהם הוא גם רשיון די "קל לעיכול" מבחינת תמחור ושימוש, והעניין שאין צורך ברשיון נוסף כדי להשתמש בדיסקים המקומיים כפתרון אחסון לפתרון וירטואליזציה, קונטיינרים ומכונות VM – הוא בהחלט יתרון ענק על פני vSAN. מצד שני – הדרך שבה vSAN מנצל דיסקים מהקצה הגבוה (NVME) והדרך שהוא כותב את המידע (חוץ מההערה שציינתי לעיל וההחלטה הבעייתית לגזול 25% מקום בשביל Slack מבלי לאפשר לשנות את הגודל, וההחלטה המאוד דבילית לגבי הגבלת שרותי יצוא ה-iSCSI) מאפשר להשיג כמות IOPS הרבה יותר גבוהה – אם מוכנים להשקיע בדיסקים עם כמות שרתים גדולה שתורמת לשרותי ה-vSAN. אפשר גם להגיע ל-7 ו-8 ספרות IOPS, רק צריך תשתית לכך.

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

ובשביל להחליט, צריך לראות קודם כל מה ההשקעה שיש לך בפתרון הקיים אצלך בארגון. אם אתה כבר מה שנקרא "מושקע כבד" על מוצרי VMware, אתה משתמש בכל השרותים של ה-vCenter, משתמש ב-VRA/VRO, כתבת סקריפטים שונים למערכת, אתה משתמש ב-NSX וכו' – אז הפתרון של Nutanix לא ממש יתן לך הרבה. הוא כן יתן לך כאב ראש כי תצטרך בעצם לנהל 2 מערכות שונות, ואם אתה הולך להריץ את הפתרון של Nutanix על VMWare, ואתה עדיין רוצה תמיכה מ-VMware, תצטרך לשלם בעצם כפול (אל תסמוך על הצהרות Nutanix שהם יעזרו לך במקרה ותהיה תקלה בתשתית של VMware) ואם תרצה לעבור לוירטואליזציה טבעית של Nutanix (ה-AHV) – תצטרך לקחת בחשבון שהיא חלקית ומאוד תלויה בגירסת מכונת ה-VM (לדוגמא: גירסה 15 עם כל ה-Secure Virtualization לא תרוץ על AHV).

מצד שני – אם כל מה שיש לך זה כמה עשרות מכונות וירטואליות, אתה משתמש ב-vSwitch וההשקעה שלך היא לא כזו גדולה בפתרון של VMware, אז הפתרון של Nutanix בהחלט יכול להיות פתרון טוב עבורך.

מצד שלישי – אם אתה חושב לנטוש את VMWare ולהקים את הכל מאפס עם Nutanix, הפתרון יכול אולי להתאים לך, אבל תצטרך לבדוק אם כל ה-ECO System המוצע לך ע"י Nutanix מספק את הצרכים שלך.

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

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

קצת על vSAN All Flash ועל דיסקים SSD NVME

בשבוע שעבר פרסמתי פוסט על vSAN וניסיתי לתת כמה שיותר פרטים מבחינת סוגי אחסון וכו'. הפעם אני רוצה להתרכז יותר במה ש-VMWare מגדירים "All Flash" ומה ההבדלים בעצם בין הדיסקים השונים בתוך קבוצת All Flash.

לפניכם צילום מסך מהגדרות vSAN על אחת המכונות שלי ב-LAB (לחצו להגדלה):

כפי שאתם יכולים לראות, במכונה זו אין שום דיסק מכני, הכל SSD, כאשר שישה מהדיסקים הם Samsung 860 Pro בחיבור SATA ויש SSD NVME מסוג Samsung 960 EVO שהוא SSD NVME. אני לא הגדרתי את סוג ה-Claim לדיסקים, המערכת ביצעה זאת באופן אוטומטי במקרה זה בכך שהיא בדקה מה החיבור של כל SSD למערכת: ברגע שמערכת vSAN מצאה כי יש במכונה SSD NVME, היא הגדירה אותו אוטומטית כ-Cache ואת כל שאר הדיסקים באותה מכונה כ-Capacity (במכונה זו יש סך הכל 7 דיסקים, כך שכמות ה-Disk Groups תהיה: אחת)

מבחינת VMware, ההמלצה הרשמית היא לכל Disk Group היא דיסק SSD מהיר והשאר יכולים להיות איטיים, בין אם בתצורת All Flash או Hybrid. אם לעומת זאת, אחליף את כל הדיסקים SATA SSD ב-NVME SSD, המערכת פשוט תבחר אחד מהם כ-Cache (הוא לא יהיה ממש Cache, הוא יהיה Write Buffer) והשאר יוגדרו כ-Capacity, אך למקרים כאלו ב-VMware מצפים שאם אתה הולך על הכל NVME, שהדיסק Cache לא יהיה NVME אלא משהו יותר מהיר כמו 3D Xpoint (של אינטל או מיקרון) או Z-SSD (של סמסונג).

אם תציצו כאן לדוגמא, זו אחת מהמערכות ש-VMware מציעה להרצת vSAN (יחד עם מכונות וירטואליות כמובן). מדובר בחבילה של שלושה שרתי Dell R740XD כאשר בכל שרת ישנם 3 דיסקים SSD 3D Xpoint לצרכי Cache ועוד 21 דיסקים SSD NVME בגודל 1 טרהבייט, כך שכל שרת יתרום ל-vSAN כ-3 קבוצות דיסקים. כמות אחסון הברוטו, אגב, תהיה 63 טרהבייט אבל ה"נטו" יטה יותר לכיוון ה-40 טרהבייט. מבחינת תמחור – כל שרת כזה בחו"ל עולה בערך כ-28,000 דולר (צריך לרכוש שלושה). ניקח את המחיר הנ"ל ונעגל אותו ל-100,000$.

נניח ומישהו פונה לעבדכם הנאמן ויש לו את התקציב הנ"ל, הוא רוצה vSAN עם ביצועי אחסון "הטופ שבטופ". האם הייתי ממליץ לו לרכוש מערכת כזו או בכלל לבנות מפרט שכולו דיסקים NVME ו-3D Xpoint?

התשובה שלי: אולי. אסביר מדוע.

לדיסקים SSD NVME אין חיבור לבקר דיסקים כלשהו. הם עובדים ישירות מול הליבות בשרת, וכאשר יש 24 דיסקים NVME שרוצים לקבל או להעביר מידע, הדבר יוצר עומס, במיוחד אם כמות הליבות היא מתחת ל-32 בשרת. נסו להקים (ללא קשר ל-vSAN) מערכת RAID-6 תוכנה עם 24 דיסקים NVME על מעבדי אינטל הנוכחיים, ותראו איך השרתים מגיעים מהר מאוד לתפוסה של 100% ניצול מעבד ובמקרים מסויימים המערכת פשוט תזרוק פקודות Reset לדיסקים.

אז איך VMware מוכרים פתרון כזה שלא נתקע? פשוט: הם מחלקים את כמות הדיסקים לעד 7 דיסקים בקבוצה (לא כולל דיסק ה-Cache) ואז השרת יכול לעמוד בכך בצורה טובה, מה שמוביל לבעיה השניה..

מערכת vSAN היא אחסון ב-Scale Out, כלומר אותו מידע נשמר בשרתים שונים ויש צורך לקרוא אותו (ברקע) משרת אחד ולהעתיק אותו לשרת אחר. אם נניח יש לנו רשת Infiniband במהירות של 56 ג'יגהביט, מספיק ש-2 דיסקים NVME ישלפו מידע במקביל להוצאה מהשרת, ואנחנו כבר חונקים את רשת התקשורת. אפשר כמובן לשדרג לרשת של 100 או 200 ג'יגהביט (ולהיות "חבר זהב" של אינטל או מלאנוקס) – אבל המחיר של תשתית כזו הוא סופר יקר. כל מה שאני כותב כרגע מדבר על דיסקים נוכחיים משנה שעברה. הדיסקים שיצאו במהלך החודשים הקרובים (כמו X100 של חברת מיקרון) מדברים על קצב העברת נתונים של 9 ג'יגהבייט קריאה, 5 ג'יגהבייט כתיבה. מי רוצה פקקי תקשורת היסטריים?

היכן זה כן יכול להתאים? במערכות וירטואליזציה שאינן "רועשות" – הכוונה שאין לנו סיטואציות ש-50 מכונות VM עולות במכה אחת, מתפזרות בין שרתים ועוברות תדיר בין השרתים הפיזיים. תמיד יהיו עומסים בהתחלה כשמעבירים מכונות VM בין אחסון קלאסי ל-vSAN, אולם לאחר מכן ברוב המקרים יעבור רק Delta של כל VM בהתאם ל-Policies שאנחנו קובעים ל-vSAN. עוד קהל שזה אולי יכול להתאים לו הם "ציידי הזדמנויות חומרה" – אותם ארגונים שיש בהם ליבראליות לרכוש דיסקים מצד ג' כשיש מחיר טוב. לדוגמא: Dell מוכרים בדוגמא לעיל כל SSD בגודל 1 טרהבייט מסוג P4510 של אינטל – ב-1100$. אותו דיסק נמכר ע"י חברת אינטל עצמה באמזון במחיר של … 1100 שקל, עם אחריות מלאה (אגב, גירסת 2 טרהבייט עולה כבר 3,000 שקלים בערך אחרי מסים וכו', ויש את DCT 983 של סמסונג – מעולה לצרכי Capacity בגודל 2 טרה ועולה בערך 2000 שקל, וגם מועמד לא רע בכלל לצרכי Cache). בשאר המקרים – אני ממליץ להסתכל על מערכת כמו אצלי ב-LAB (רק עם דיסקים SSD יותר גדולים ודיסק SSD NVME אחר, עדיף Mixed Intense, או אם יש כסף – לכו על P4800X, כל יצרני השרתים מוכרים זאת תחת שמות שונים).

אנצל הזדמנות זו כדי לענות לשאלה שנשאלתי כבר 4 פעמים מאנשים שונים: איך vSAN מול (הכניסו כאן שם מותג אחסון ודגם כלשהו)? והתשובה: אי אפשר להשוות. vSAN זה Scale Out בשעה שרוב מותגי האחסון הם Scale Up. פתרון vSAN יכול לזחול כשיש מעט שרתים תורמים, דיסקים מכניים ו-SSD זולים/ישנים עם רשת של 1 ג'יגה (VMware מבקשת 10 ג'יגה), ופתרון vSAN יכול לבעוט בכל פתרון אחסון Scale Up אם מכניסים SSD טובים וגדולים ל-Capacity ו-3D Xpoint כ-Cache, הרבה Disk Groups ומספר גדול של שרתים שתורמים ל-vSAN.

לסיכום: פתרון All Flash עם vSAN יכול לתת ביצועים מדהימים, אבל חשוב לדעת מה לבחור, תלוי מה מדיניות הארגון ברכישת ציוד כמו דיסקי(תעיפו מבט בלינקים), תלוי מה הרשת וכו'. חשוב לזכור – אי אפשר לעבור בין Hybrid ל-All Flash או ההיפך, וחשוב גם להסתכל על האופציה כמו בצילום מסך, רק עם דיסקים גדולים.

פתרון VDI לעסקים קטנים

למי שזוכר (ולמי שלא) – בשנה שעברה פרסמתי מספר מאמרים על VDI, ובחלק מהמאמרים התייחסתי לכך ששום פתרון מהחברות הגדולות (Microsoft, VMWare, Citrix, ,Nutanix) אינו מתאים לעסקים קטנים שיש להם בין כמות חד ספרתית של מכונות דסקטופ לבין כמות דו ספרתית בינונית (30-50, נניח) של מכונות דסקטופ. עלות פתרון VDI כולל תוכנות, רשיונות, ברזלים – היא מעל ומעבר לתקציב של אותם עסקים קטנים.

לכן, בסיוע חברת CRG שהשאילה לי ציוד (תודה, תומר!) ישבתי בחודשים האחרונים ובדקתי מספר פתרונות עם אפשרויות שונות והגדרות שונות על מנת להשיג מצב שמשתמש יוכל להשתמש במכונה וירטואלית עם אופיס, דפדפן ועוד כמה תוכנות שאינן דורשות משאבים גרפיים רציניים. במילים אחרות – חיפשתי פתרון VDI במובן המילולי – לקחת מכונת דסקטופ פיזית, לבצע לה P2V ולזה המשתמש יתחבר, רק בלי כל הפונקציות שהתוכנות הגדולות נותנות, ולכן אני כותב לטובת כל מיני מטרילים למיניהם: פתרון זה לא בא להתחרות בפתרונות הגדולים והמוכרים, אלא בא לתת משהו בסיסי עם כמה תוספות נחמדות.

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

אז איך VSAN בביצועים ובמחיר? (מאמר מעודכן 2/2020)

עריכה: יש עדכונים לפוסט – בסוף.

התבקשתי לאחרונה ע"י חברה גדולה להציע להם פתרון VDI ל-500 משתמשים. הפתרון אמור לכלול את כל מילות הבאז האחרונות: שיהיה Scale Out, שיהיה Hyper Converged, שלא יצטרכו סטורג' חיצוני, ובקיצור – שיכלול את הכל, אבל שלא יתפוס כמה ארונות.

אז הצעתי להם פתרון שכל הגודל שלו הוא 2U, של חברת Supermicro, דגם: A+ Server 2124BT-HNTR עם מפרט ארוך ומותאם לדרישות (את זה אני כבר לא יכול לפרט פה בבלוג). הפתרון הזה כולל הכל, עם פוטנציאל התקף לב מבחינת מחיר החומרה הדרושה ורשיונות. הייתי בטוח ב-99% שהלקוח זורק את ההצעה הזו לפח והולך עם איזה פתרון של Dell/HPE/Lenovo אבל במקום זה קיבלתי בקשה לשיחת סקייפ מאותה חברה. הם התרשמו מההצעה אך הם רצו לדעת קצת יותר לגבי החלק של ה-vSAN.

אז בסוף שבוע האחרון, בסיוע חברת Wiwynn (זו אחת מהחברות הגדולות שמייצרות ברזלים עבור ספקי ענן ציבורי הגדולים) וחיבורים מרחוק, התחלתי לבדוק את הנושא. VMWare לא ממש אוהבת את הרעיון לפרסם מספרים מבחינת Benchmarks (זה ב-EULA שלהם) אז אני אכתוב בכלליות וב..יצירתיות…

לטובת אלו שלא ממש מקימים/מתחזקים/משתמשים ב-vSAN, אתחיל בהסבר קצר לגבי מה-זה-vSAN: זהו הפתרון אחסון Scale Out של חברת VMWare. הפתרון מובנה בתוך ESXi אך לשם הפעלתו יש צורך ברשיונות נוספים פר כמות המעבדים בשרת.

הפתרון עובד בשיטה של Disk Groups: קבוצות דיסקים המכילות שני סוגי דיסקים: דיסק Flash מהיר (עדיף NVME) שנקרא "Cache" ודיסקים מכניים או SATA SSD שנקראים "Capacity". כל קבוצה כזו חייבת דיסק אחד Cache ו-2 או יותר דיסקים (עד 7) ל-Capacity. כל שרת יכול להכיל עד 4 Disk Groups. לאחר הגדרות הדברים הללו, יש להגדיר את ה-Policies השונים ל-vSAN וכמו כן להגדיר בכל שרת אלו חיבורים פיזיים ישמשו את ה-vSAN. לאחר כל הגדרות הסלט הללו, יהיה לנו Cluster אחד שלתוכו נשלב את כל השרתים המשתתפים ומקבלים את שרותי ה-vSAN.

מכאן, נצלול קצת יותר לעומק בעניין ה-Disk Groups:

באופן עקרוני, ישנם שני סוגים של Disk Groups, האחד נקרא All Flash והשני נקרא Hybrid, כאשר כפי שניתן להבין, ה-Hybrid מדבר על שילוב של דיסק SSD מהיר (NVME) ועוד דיסקים מכניים, והסוג השני (All Flash) מדבר על כך שכל הדיסקים בקבוצה הם SSD. ההבדל הטכני בין הסוגים הוא העבודה של ה-SSD שמשמש כ-Cache. במצב Hybrid אותו SSD מהיר מבצע בעצם 2 עבודות: הוא גם משמש כ-Read Cache של התוכן שנקרא לאחרונה משאר הדיסקים המכניים וגם כ-Write Buffer שמאחסן זמנית תוכן שיעבור ברקע אל הדיסקים המכניים. במצב All Flash לעומת זאת, ה-SSD המהיר משמש רק כ-Write Buffer ואילו כל הקריאה מתבצעת משאר הדיסקים SSD באותה קבוצה.

אחד הדברים השונים ב-vSAN בהשוואה לרכישת אחסון רגיל (Scale Up) הוא שבאחסון רגיל מבקשים מאיש המכירות כמות טרהבייט שנרצה (ברוטו/נטו) וכיום יותר ויותר מבקשים שאותו אחסון יעמוד בכמות IOPS מסויימת גם בעומסים.

ב-vSAN לעומת זאת, החישובים הם שונים לחלוטין. עצם העובדה שהכנסנו נניח דיסקים בכמות כוללת, נניח, של 100 טרהבייט, לא אומר שישארו לנו נניח לאחר RAID-5 תוכנה כ-80 טרהבייט באיזה Datastore לשימושנו החופשי.

הנה דוגמא ל-vSAN על 4 שרתים שיבנה כ-RAID-5 (תוכנה) עם הפרמטרים הבאים:

  • כמות שרתים המשתתפת ב-vSAN (שרתים שמכילים דיסקים): 4
  • כמות Disks Group פר שרת: 3
  • כמות דיסקים המשמשים כ-Capacity פר קבוצת דיסקים: 5
  • כמות מקום פנוי לצרכי Slack Space (זהו מקום לאחסון Snapshots, Rebalancing ועוד): 30%
  • כמות מקום לצרכי Checksums (אם אתם רוצים לבצע דחיסה ו-Dedup – תצטרכו את זה): 5%
  • "יעילות מקום פנוי" (כלומר: Dedup) תהיה: 1.7
  • סוג וגודל הדיסקים שנשתמש: SSD בגודל 1.92 טרהבייט.
  • סה"כ כמות דיסקים SSD שנשתמש: 72, כאשר מתוכם 12 דיסקים יהיו NVME SSD (עדיף Mixed Intense/Mixed Use).

כל זה יתן לנו את הדברים הבאים:

  • אחסון "ברוטו" – 117 טרהבייט
  • אחסון "לשימוש" (לפני שנחתכים ממנו חלקים שונים): 100 טרהבייט, כך שזה מתחלק ל-:
    • אחסון Workload (כאן מתאחסן בעצם ה-Datastore שלכם): 91 טרהבייט
    • אחסון לצרכי Checksum דחיסה, dedup וכו' – 5.3 טרהבייט
    • אחסון לצרכי Replica או Parity – כ-30 טרהבייט
    • אחסון לצרכי File System – כ-1.17 טרהבייט
    • אחסון לצרכי HA ומצב Maintenance (כך כשהשרת במצב Maintenance הוא יוכל להמשיך לתת שרותי אחסון): 35 טרהבייט.

(אל תנסו לחשב סעיף+סעיף, יש פה הכללה צנועה של Dedup ביחס של 1:1.7)

הערה: למי שמעוניין, כאן יש את המחשבון שבו השתמשתי. ל-VMWare יש גם משהו, אבל הרבה יותר מורכב.

מכאן נעבור לביצועים: הביצועים עצמם תלויים בכמה דברים:

  • סוג הדיסקים שנשתמש בהם ל-Capacity. דיסק SSD SATA רגיל הוא מהיר בקריאה, אבל איטי בכתיבה רנדומלית או רציפה, במיוחד כשמדובר בהעתקה של מעט מספר ג'יגהבייטים. כמו כן, ב-SATA יש רק ערוץ אחד, הווה אומר שהדיסק יכול לקרוא או לכתוב בכל פעם, אך לא את שתיהם. בדיסק SSD NVME לעומת זאת אין את המגבלה הזו וגם מהירות הכתיבה בדיסק NVME אפילו Read Intense היא לא כזו רעה (בין כמה מאות ל-1-1.5 ג'יגהבייט בממוצע, תלוי בכמות הנתונים). ה-Disk Group שיתן את הביצועים הכי גבוהים הוא קבוצה שכולה תורכב מ-NVME SSD כ-Mixed Use/Mixed Intense.
  • רשת – אם כל הדיסקים הם SATA, אז תקשורת במהירות 10 ג'יגהבייט היא צורך בסיסי, אולם אם הכל NVME, תצטרכו רשת לפחות במהירות של 40 ג'יגהביט. חשוב לזכור: דיסקים SATA SSD יכולים להוות צוואר בקבוק.
  • זכרון – כל שרת יצטרך להיות עם לפחות 128 ג'יגהבייט זכרון וכמות ליבות נדיבה פר מעבד.
  • כמות השרתים עם דיסקים המשתתפים ב-vSAN – כמה שיותר, הביצועים עולים, אם כי לא בצורה ליניארית.

ולשאלה שאני נשאל לא מעט עליה – מי יותר מהיר, vSAN או הפתרון של Nutanix? התשובה: vSAN. הפתרון של Nutanix מבוסס על פתרון לינוקס שלא ממש יודע לנצל טוב דיסקים NVME, לפחות ממה שבדקתי.

כמו לכל דבר, יש יתרונות ויש חסרונות, גם ל-vSAN וחשוב לקחת אותם בחשבון:

  • שרות ה-iSCSI ש-vSAN נותן לא מאפשר חיבור שרתי ESXi אחרים דרך ה-iSCSI Initiator.
  • אין ל-vSAN תמיכה ב-DPM, Storage Profiles, Sparse Disks, RDM וכו'.
  • כל השרתים שיקבלו שרותים מ-vSAN צריכים להיות תחת אותו Cluster. צעד הזוי מצידם, אבל זה מה שיש.
  • המחיר די גבוה: יש ארבעה סוגי רשיונות ל-vSAN. הרשיון הכי פופולרי (Advanced) עולה בסביבות ה-4000$ (זה "על הנייר", תפעילו כישורי מו"מ!) והוא הכי מומלץ מבחינת פונקציונאליות ושרידות.
  • יש לרכוש רשיונות פר מעבדים בשרת, כלומר אם יש 10 שרתים כשבכל שרת 2 מעבדים, יש לרכוש 20 רשיונות, גם אם 4 שרתים מתוכם משתתפים במתן שרותי vSAN וכל השאר מקבלים שרותים. במילים אחרות: כל מה שמתחבר ל-vSAN, צריך רשיון פר מעבד.
  • עדיין חסרה תמיכה במסגרת Disk groups ביותר מדיסק Cache יחיד, כמו כן יש בעיות עדיין בתמיכה ל-Optane PMEM ב-vSAN עצמו.
  • כפתרון אחסון ל-VDI, המחיר מטורף (כמדומני 50$ פר VM).
  • אם אתם רוכשים דיסקים רק מיצרן השרתים – המחיר לכל הפתרון יהיה מאוד גבוה, במיוחד בדיסקים NVME (לדוגמא: דיסק 1.92 טרהבייט NVME Read Intense יעלה לכם בסביבות ה-$2500, ואילו NVME Mixed Use באותו גודל יכול להגיע למחיר של $4000). לכן, אם רוצים, אפשר ללכת על פתרון כרטיס הרחבה של HPE ל-4 כרטיסי M.2 ולרכוש 4 דיסקים NVME Mixed Use מצד ג' שנותן ביצועים טובים (הואיל ומדובר בפתרון Cache, השרידות אינה חשובה, ה-DATA נשמר ב-Capacity).

לסיכום: vSAN זה פתרון Scale Out טוב כשרוצים להשתמש רק בשרותי וירטואליציה של VMWare. מבדיקות שערכתי, המערכת יכולה בהחלט להנפיק ביצועים גבוהים, אולם יהיה צורך בהשקעה כספית רצינית בדיסקים ובכמות השרתים שיריצו את ה-vSAN. מבחינת תמחור – מדובר במחיר גבוה "על הנייר" אולם אם מחפשים מערכת שגם תיתן ביצועים גבוהים וגם ניתן יהיה להגדיל אותה במרוצת הזמן ולקבל יותר ביצועים – כדאי לבחון אותה ולהתייחס גם לחסרונות שלה.

עדכון: תודה לגלעד בראון שציין בפניי כי ישנה חבילה שנקראת "Horizon 7 Enterprise" שכוללת את כל הרשיונות והפונקציונאליות הנחוצה ללא צורך ברשיונות vSAN נוספים והרישוי הוא לפי כמות המשתמשים (כלומר חבילות).

עדכון 2: עוד נקודה שגלעד ציין –  ה-Cluster vSAN יכול להיות או Hybrid או All Flash. לא ניתן לערבב.

VMWare על AWS – האם שווה להשכיר?

(אני רוצה להתחיל בהערה קטנה. אחרי שכתבתי את הפוסט על PKS קיבלתי מאנשים הערות שאני "אנטי VMware". אני לא. למען האמת, אני בשלבים של מעבר כל המכונות שלי ל-vSphere 6.7 ואני חושב שפתרון הוירטואליזציה של VMWare הוא מהטובים בשוק. יחד עם זאת, יש לי השגות לגבי חלק ממוצרי החברה ואת אותן השגות אני משתף, לא יותר מזה). נקודה נוספת: בעבר כתבתי על VMWare on AWS אבל הכל היה מבוסס על שמועות. הפעם ביקשתי מחבר שבעבודתו משתמשים במוצר להקדיש לי שעתיים ולהראות לי את התכונות ובדקתי גם את ההדגמות והקליפים הרשמיים טרם כתיבת פוסט זה.

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

לתוך הנישה הזו VMWare מוציאה "מוצר חדש" שנקרא VMWare on AWS ופתרון זה יוצר מעין "המשכיות בענן", אתה יכול להשתמש ב-SDDC Manager לנהל את הפתרון של VMware בענן יחד עם הפתרון שרץ אצלך מקומית (On Prem). אתה לא צריך לשנות מכונות וירטואליות לעבר הפתרון שלהם שרץ בענן של ה-סע"צ שבחרת, אתה פשוט מבצע Migrate של אותן מכונות וירטואליות לאותו DC מרוחק, ל-Cluster המרוחק ול-Datastore המרוחק, בוחר את הסוויצ', מאשר, וזהו – המכונות הוירטואליות בדרך לענן הציבורי. נשמע קל ופשוט, בלי הרבה כאבי ראש.. לא?

אז זהו, שזה "טיפה" יותר מורכב. מבחינה טכנית, מה שציינתי לעיל הוא נכון ואנשי השיווק והאנשים הטכניים של VMWare יאשרו זאת, אבל יש כאן כמה דברים שכדאי לפני כן לקחת בחשבון:

  • הפתרון VMWare on AWS הוא בעצם פתרון vSAN המוכר. אתם לא משלמים פר VM, אתם משלמים פר שרת פיזי ויש צורך במינימום 3 שרתים.
  • התמחור יכול להיות דינמי (פר שעה) או פר שנה או פר 3 שנים והמחיר עצמו טיפ טיפה גבוה .. אם לדוגמא אתם רוצים להקים זאת בארה"ב, בוירג'יניה, שם המחיר יהיה הכי "זול". כמה? ובכן, על 3 מכונות בסיס (נקראת i3) תשלמו 155,961 דולר לשנה. רוצים להריץ את זה בפרנקפורט, גרמניה? המחיר מטפס ל-185,952 דולר לשנה. המחיר כולל את הרשיונות ל-vSphere ו-vSAN אך אינו כולל VMWare Site recovery, ובשביל לכלול זאת יש לשלם $22,600 פלוס 347$ פר VM.
  • ישנן שתי סוגי מכונות: i3 metal, r5 metal. ה-i3 כוללת דיסקים NVME מקומיים (אחסון כולל Cache בסביבות ה-16 טרה), ואילו מכונת ה-i5 משתמשת באחסון של AWS (ה-EBS) כ-"דיסקים מקומיים", אחסון EBS אינו נכלל בסכומים שציינתי לעיל והתשלום הוא חודשי. פונקציה נוספת – Elastic vSAN (מאפשר להשתמש באחסון שבשרת גם אם אותו שרת הוא במצב תחזוקה) עולה $2.28 לשעה פר מכונה. אלו מחירים ל-3 שרתים בשרת ה"נמוך" (18 ליבות, i3-metal). אם אתם רוצים להשתמש באחסון של אמזון (EBS) ולקחת שרתים יותר רציניים (r5 metal, עם 48 ליבות) אז בוירג'יניה תצטרכו לשלם 174,411 דולר לשנה, ובפרנקפורט המחיר מטפס ל-210,396 דולר לשנה.
  • רוצים הנחות על המחיר? בשמחה, רק אם אתם משלמים מראש. אם אתם שוכרים את הברזלים ל-3 שנים מראש, יש לכם 50% הנחה. אם לשנה – 30% הנחה (לפי המסמך הזה).

חברות שונות יסתכלו על המחירים הללו בצורה שונה. רוב החברות הישראליות יסתכלו וסביר להניח שיאמרו NO DEAL, ולעומת זאת חברות בינלאומיות גדולות ינסו להוריד קצת את המחיר – וישכרו.

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

אם נרכוש שלושה שרתים, בכל אחד מהם מעבד אחד AMD EPYC עם 32 ליבות (כך נחסוך במחצית את העלויות של vSphere ו-vSAN וכל מוצר אחר שמחושב Per Socket), עם חצי טרהבייט זכרון, עם 6 דיסקים NVME SSD ו-2 דיסקים NVME SSD Mixed Intense, עם כרטיס רשת של 10 ג'יגהביט, כל הרשיונות (ל-3 שנים) שצריך ולקינוח גם סוויצ' נחמד. צריכים את המערכת בגרמניה, או ארה"ב או אפילו מחוץ למשרדכם פה בארץ? חפשו ספק שמוכר שרותי COLO (כלומר Co Location) לאחסן 4U או 7U (שזה 3 שרתים, תלוי בגודלם הפיזי – פלוס סוויצ') עם רוחב פס נאה, ואתם תשלמו לו בערך 2000-4000$ לחודש.

ניקח את כל הערימה הזו ונחשב אותה – ותראו שלא תגיעו ל-$160,000 שתצטרכו לשלם בממוצע לשנה על VMWare on AWS, ובנוסף – הציוד והרשיונות הם שלכם, וזה כולל SLA לברזלים ולציוד עצמו.

אחד הדברים שחשוב להבין לגבי VMWare on AWS היא למרות שהשיווק יזכיר בכל שניה וחצי את המילה "ענן" – חוץ מהעובדה שזה יושב ב-DC של ספק ענן ציבורי, אין לפתרון הנ"ל כמעט כלום עם מה ש-סע"צ בעצם מייצג. (ה"כמעט" קשור למכונה r5 metal שמשתמשת באחסון של ספק הענן אבל זה בעצם לא ממש משנה כלום. EBS מאפשר גדילה דינמית, אבל vSAN לא יודע "לאכול" דיסק "פיזי" שגודלו השתנה). כל השירותי ענן שתשתמש בהם מתוך ה-VMware on AWS יהיו בדיוק כמו שתיקח את השרותים מבחוץ או ממכונות וירטואליות שה-סע"צ משכיר מהשרותים שלו.

הבה נסתכל על ההצעות של ה-סע"צ. רבים נוטים להתעצל ולבחור נניח מהעשיריה הראשונה של ההצעות ל-VM כדי לא להסתבך, אבל המציאות היא שכל סע"צ מציע מספר "דורות" של מכונות וירטואליות, חלק לא קטן מההצעות די זולות ויכולות להתאים למשימות שונות (הנה לדוגמא ההצעות של AWS. מיקרוסופט, לפחות ממה שבדקתי, לא מציעה טבלה כזו אז חברת Nakivo מציעה טבלה כזו עם הסברים, ובגוגל יש דף פשוט שמסביר את הסוגים. אז אם לדוגמא אתם צריכים להריץ אפליקציה שדורשת המון זכרון אך כמעט ולא עושה כלום עם המעבד, אתם יכולים לשכור Instance מדור ישן יותר ובכך לחסוך. צריכים מכונות VM שאליהן מחוברים דיסקים SSD פיזיים לוקאלית? יש. ב-VMWare on AWS אין חיה כזו – יש סוג אחד של מעבד (ישן, מלפני שלוש דורות – Xeon V4) ואין לך אפשרות לחבר SSD פיזי לוקאלית ל-VM (על VMware on AWS – כי זה מנוהל על ידי VMware).

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

קונטיינרים ו-Windows – מאמר עדכון (2020)

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

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

וזה חתיכת כאב ראש..

באותו זמן מיקרוסופט החלה להציע דרכים להכין ולהריץ קונטיינרים, אבל רק ב-Windows Server 2019 (ובגרסאות Windows 10 היותר מתקדמות) הם הציעו באופן רשמי דרכים להריץ קונטיינרים ל-Windows (הכוונה שהקונטיינר מכיל IMAGE עם קבצים בינאריים ל-Windows). בהתחלה עם Hyper-V בצורה מבודדת (דרך מצויינת לבזבז זכרון) ואחר כך כ-Process מבודד.

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

בחודשים האחרונים החלו יצרני "הפצות" K8S כמו PKS של VMWare להציע גירסת בטא לתמיכת Windows Containers וגירסת Openshift הבאה תציע זאת גם. אם אתם מתכוננים להיפגש עם נציג של VMWare לגבי PKS, הוא בוודאי יציג לכם מצגת עם שקופית שמזכירה לכם ש-Windows 2008/2008R2 מסיים לקבל תמיכה רשמית השנה ולכן כדאי לנצל את העניין לעבור לקונטיינרים (אכן התמיכה מסתיימת אבל יש שמירה לאחור די רצינית בכל הקשור לתאימות בינארית, כך שאפשר להריץ את אותן אפליקציות ב-Windows 2012/2016/2019, המקסימום – תצטרכו לקמפל מול ספריות סטנדרטיות, כך שהטענה שגירסת OS הסתיימה ולכן עכשיו עכשיו חשוב לעבור לקונטיינרים – לא ממש "מחזיקה מים").

אז מה המצב כיום?

טכנית, אין בעיה להריץ K8S תחת Windows, אך כרגע Windows נתמך כ-Workers Node באופן רשמי ולכן עדיין תצטרכו מכונת לינוקס שתשמש כ-Master. אם אתם רוצים להריץ K8S מהקוד הקיים הפתוח, אתם צריכים לעבור תהליך התקנה די ארוך ומורכב שאפשר לקרוא עליו כאן (יש עוד 2 חלקים בצד שמאל, אל תדלגו עליהם). אם אתם חושבים להשתמש ב-Rancher, גירסה 2.3 תומכת ב-Windows Containers, לגבי השאר – ציינתי לעיל.

אם אתם מתכננים לממש ולהריץ קונטיינרים ל-WIndows בעננים ציבוריים, אז כל הספקים המספקים שרות הרצת קונטיינרים מנוהל כבר תומכים בכך.

הדברים החשובים לזכור ולבדוק (אם אתם מריצים K8S ב-On prem):

  • לא לשדרג את ה-Windows אוטומטית. אם מיקרוסופט מוציאה מחר Service Pack או עדכון שמעלה את גירסת ה-Windows (דוגמא: 1709 ל-1903) יכול לשבור דברים בקלות, ויכול להיות מצב שלא תוכלו להריץ קונטיינרים.
  • תמיכת Plugins – ל-K8S יש מאות Plugins שונים בתחומים שונים. ב-Windows רק חלק קטן נתמך ורץ (הם מופיעים בקישור שנתתי בפיסקת תהליך ההתקנה לעיל). כך לדוגמא, חלק מיצרני הסטורג'ים שחררו Plugins ל-K8S בכל הקשור ל-Volumes, צרו איתם קשר לראות אם הם שחררו את ה-Plugins שלהם ל-Windows. כמו כן, תמיכת CSI (כלומר: Containers Storage Interface) היא עדיין ברמת אלפא/בטא.
  • יכול להיות שה-IPS/IDS שלכם לא יאהבו את K8S ל-Windows, הואיל ובחלק מהמקרים נעשים שינויים לפאקטות. כמו כן התמיכה ב-NAT היא קצת בעייתית (תסתכלו בחלק של ה-Networking באותו קישור) – קחו את זה בחשבון לטיפול.
  • קונטיינרים ברמת privileged (אלו בדרך כלל קונטיינרים שמשפיעים על כל ה-K8S) לא יכולים כרגע לרוץ תחת Windows.
  • ניהול זכרון: בלינוקס יש תהליך (שנוא אבל הכרחי) שנקרא OOMKiller שהורג תהליכים בעת מצבים שמסתיים הזכרון. ב-Windows זה אחרת, וברגע שמסתיים הזכרון, המערכת משתמשת ב-pagefile כך שאין משהו שיהרוג תהליכים אם הזכרון מסתיים ולכן יכול להיות מצב שה-Node "יזחל" רק בגלל שאין זכרון. התיעוד מציע מספר אפשרויות, אבל כדאי לעקוב היטב במערכת הניטור לגבי זכרון במכונות Windows המריצות PKS.
  • אם אתם משתמשים ב-Flannel פלאגין לרשת K8S, כדאי לזכור שאין אפשרות לתקשורת בין Node ל-POD.
  • אבטחה – בכל מה שקשור ל-Secrets – דברים נכתבים כ-clear text ב-Node Volume. יש שתי המלצות בתיעוד – או ACL או Bitlocker, שתי פתרונות שלדעתי די עקומים אבל זה מה שיש. בנוסף – האבטחה ל-POD שהפצות K8S שונות מאפשרות תחת לינוקס (SELinux, AppArmor וכו') – לא נתמכות ב-Windows בכלל ויכול להיות שבעתיד יפותח משהו.

כל הנקודות לעיל נלקחו מהמסמך בקישור לעיל והם רלוונטיים לגירסה האחרונה (שברוב המקרים לא כלולה בהפצות K8S השונות), ולכן אני עדיין טוען: התמיכה ב-Windows היא עדיין Work In progress, זה יכול להספיק להריץ דברים פנימית שאינם פתוחים/חשופים לאינטרנט, בסביבות Testing, Staging ואפילו PROD מצומצם, אבל מומלץ לעבור עם מחלקת אבטחת מידע על כל המגבלות במסמך המקורי ולהחליט אלו קונטיינרים ל-Windows להקים ולהריץ ב-K8S, מה ממירים להרצה על לינוקס (כדאי לזכור: בתוך POD אי אפשר להריץ קונטיינרים גם מ-Windows וגם מלינוקס), ועל מה כרגע מדלגים.

לסיכום: K8S ל-Windows, למרות יצרני הפצות K8S שונות, הוא עדיין Work In Progress. יש את כל החלקים הבסיסיים, אבל חסרים לא מעט דברים חיצוניים ויש לא מעט אורות אדומים בכל מה שקשור לאבטחת מידע, ניהול זכרון, Plugins וכו' וכו'. אין שום בעיה ואפילו מומלץ – להקים מערכת K8S ולצוות אליה מכונות Windows לשרת Linux שישמש כ-Master ולהתחיל תהליכי המרה, טסטים והרצות שונות, אבל כשזה מגיע לפרודקשן, ממליץ "לעשות חושבים", גם אם מדובר בהרצת קונטיינרים לפרודקשן במערכות קונטיינרים מנוהלות ע"י ספקי ענן ציבורי.

אחסון: Scale Up מול Scale out (מאמר עדכון)

יצא לי לאחרונה לשבת אצל מספר לקוחות שהזמינו שרות יעוץ לגבי אחסון ולשמוע את הדרישות, ובלא מעט מקרים, הצרכים של אותם לקוחות הצריך פתרון הפוך ממה שהם חשבו. יש כאלו שחשבו על פתרון Scale Out בשעה שהם צריכים פתרון Scale up – וההיפך.

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

נתחיל בפתרון הפופולרי שיותר ויותר רוצים: פתרון Scale Out ובמקרה של VMWare מדובר כמובן ב-vSAN (עם Nutanix, Simplivity, Hyperflex הדברים מעט שונים). הדבר הראשון שצריך לקחת בחשבון זה עלות שדרוג רשיון ל-vSAN. בכל שרת שיש בו שני מעבדים, צריך לשלם כמדומני $5000 וזה רק על הרשיון, כלומר אם יש נניח 10 שרתים, אנחנו מדברים על $50K לפני שבכלל דיברנו על חומרה. אחרי שדיברנו על רשיונות, נדבר על דיסקים וסוג האחסון: Hybrid או All Flash, רובם כשהם מקבלים הצעות ל-All Flash ב-vSAN נרתעים מהמחיר אז נעבור ל-Hybrid. הדיסקים מקובצים כ-Disk Group. מבחינה טכנית, כל Disk Group יכול להכיל עד 7 דיסקים מכניים ודיסק SSD, המכניים הם ה-Capacity וה-SSD נקרא Cache. חישוב הדיסקים צריך להיות לפי רמת ה-RAID שאתם בוחרים, לפי כמות ה-Fault Domains, ה-Erasure Coding ועוד. לא מומלץ לנסות לחשב לפי Dedup מכיוון שיחס ה-Dedup הוא משתנה נעלם שמשתנה בהתאם לתוכן המאוחסן, כמות פעמים שאותם בלוקים מאוחסנים ועוד, למעוניינים – ניתן לקרוא יותר פרטים על כך כאן וכאן. נקודה חשובה לציון: VMWare גם נוטים להמליץ על דברים שייקרו את המערכת, כמו בקר RAID לכל קבוצת דיסקים (כי זה עוזר ב-Rebuild), תלוי במצב הקונפיגורציה שלכם, לא חייבים להקשיב ולרכוש. מה שכן, ותלוי בתקציב, מומלץ לרכוש SSD Mixed Intense ל-Cache (היחס קריאה כתיבה לדיסקים SSD שהם Read Intense הוא 80/20 או 75/25, ו-VMWare מבקשת 70/30 – לשיקולכם).

מכאן נעזוב את פתרונות ה-HCI ונעבור לאחסון כללי.

אין שום בעיה לאחסן 2-3 פטהבייט באחסון Scale Up. הנה לדוגמא JBOD של Western Digital שיכול לקבל עד 102 דיסקים מכניים של 12 טרהבייט ולתת כמות אחסון ברוטו של 1.2 פטהבייט. אפשר לשרשר קופסא כזו לעוד שלושה קופסאות נוספות כך שתיאורתית ניתן לאחסן ברוטו 3.6 פטהבייט. את הקופסאות האלו ניתן לחבר לשרת שמריץ את תוכנת האחסון (למען האמת, ניתן לחבר את זה כמעט לכל סטורג' חדש כיום, רק שיצרן הסטורג' לא יתמוך בכך מבחינת תמיכה ואחריות, אם כי יכול להיות שגם הוא מוכר משהו דומה) ואם רוצים – אפשר לחבר שתי קופסאות סטורג' ("ראשים") בתצורת High Availability ולקבל פתרון אחסון מעולה…

.. עד שמגיעים לבעיה המרכזית באחסוני Scale Up כאלו: אם בקר ה-SAS באחת מקופסאות ה-JBOD יתקלקל, פתרון האחסון יושבת (וכמובן השרתים המקושרים לו) ואנחנו מדברים על השבתה של מינימום 4 שעות במקרה הטוב, יום עסקים במקרה הפחות טוב, וכמה ימים במקרה הרע (מה לעשות, לא לכל יבואן יש כמה כאלו שהוא שומר בסטוק למקרה חרום, וכבר ראיתי מקרה כזה).

לכן חשוב להבין, מבחינת Scale Up, תיאורתית אפשר לאחסן בו המון, אך ככל שמכניסים יותר ויותר חלקים לפתרון (עוד בקרי RAID, עוד קופסאות JBOD וכו') הסיכוי להשבתה הוא יותר גדול, הזמן לבצע Rebuild לדיסק עם מספר דו ספרתי של טרהבייט – גודל בצורה משמעותית, ולכן מעשית – זה לא מומלץ

ב-Scale Out לעומת זאת, אפשר לשלב מספר קופסאות כמו הנ"ל בכך שנצוות קופסא מול שרת, מינימום שלושה שרתים (הכמות עולה במספר אי זוגי – 3,5,7 וכו' וכו') ואז גם אם יתקלקל JBOD, יתקלקל שרת אחסון Scale Out או שניהם ביחד – המערכת תמשיך לתת שרות. החסרון כמובן קשור לעלויות – צריך יותר שרתים יעודיים, צריך Backbone של 40 ג'יגהביט לפחות, סביר להניח שנצטרך שרת עם דיסקים SSD לצרכי Cache וכו', ולכן פתרונות כאלו מתאימים לפרויקטים גדולים כמו HPC, או Big Data ועוד, וכאן שימוש בפתרונות Scale Up לא יתן פתרון אחסון מהיר ויעיל. אותו דבר לגבי כמות אחסון – אם כל מה שאתה צריך לאחסן זה כמה עשרות או מאות בודדים (100-200) של טרהבייט, לך על Scale Up.

לסיכום: יהיה האתגר אשר יהיה, לא מומלץ "לרוץ" ולרכוש פתרון שהחברים ממול רכשו, גם אם הם מריצים את אותה תשתית בערך. האם פתרון Scale Up מתאים? אולי Scale Out?  על מנת לעלות כך, צריך לקחת בחשבון הרבה פרמטרים, שאלות ובעיות שרק בחישוב הכולל שלהם אפשר להחליט אם ללכת לכאן או לכאן, ומכאן אפשר להמשיך לשלב של בחירת מערכת, SDS, עלויות מול תקציב ועוד.

על דיסקים SSD – אחריות, ביצועים, יד שניה ועוד

לקראת השנה האזרחית החדשה החלטתי לכתוב פוסט חדש המבוסס על דוח"ות שכתבתי עבור לקוחות שונים והחלטתי לקחת חלקים מהם (ברשות) ולאחד אותם לפוסט אחד. כל מה שאני כותב בפוסט זה מבוסס הן על תיעוד של היצרניות והן על בדיקות Stress testing שביצעתי עבור לקוחות. שמתי לב שרבים מאנשי ה-IT (וחלק קטן מאנשי השיווק) מביאים/מציגים פרטים ישנים או רלוונטיים ולכן בפוסט זה אתייחס לסוגים שונים של דיסקים. הן ללקוחות קצה ביתיים/סמי-מקצועיים והן ל-Enterprise. הטכנולוגיה והמושגים רלוונטיים בערך לשנתיים האחרונות.

אתחיל בנושא אחריות ו"טחינת דיסקים", מושג שמתאים לדיסקים מכניים ולא ל-SSD ואסביר מדוע.

אחריות על דיסקים נמדדת ב-2 מושגים שונים, תלוי בשוק. בשוק הביתי/סמי-פרו, היא נמדדת ב-TBW – שזה Terabyte Written, כאשר מדובר על הכמות הכוללת של מידע הנכתב על הדיסק מרגע יציאתו מפס היצור. פירמוט, חלוקה לפרטישנים, כתיבה מחדש, פירמוט מחדש, חלוקה מחדש – אינה "מאפסת" את כמות הנתונים הנכתבים על הדיסק וניתן לראות את כמות הקריאה וכתיבה על דיסק באמצעות כלים שיודעים לקרוא את ה-S.M.A.R.T בדיסק (לא חשוב אם מדובר ב-SATA, SAS, NVME). היצרן מציין כמות מסויימת ולאחריה נדלק "דגל" של WEAR out ב-S.M.A.R.T ומאותו רגע – פגה האחריות. היצרן גם מציין כמות שנות אחריות למקרה ולא מגיעים לכמות הכתיבה/שכתוב המותרת, בדרך כלל זה 3 או 5 שנים (רק בחלק קטן של הדיסקים יש אחריות ל-10 שנים, כמו לסמסונג 850 PRO)

בדיסקים ל-Enterprise המדידה היא שונה והולכת לפי DWPD, כלומר Drive Write Per Day, ובמילים פשוטות: כמה פעמים אתה יכול לכתוב על הדיסק מאפס כל יום ולמלא אותו (אף פעם לא מומלץ למלא SSD עד הסוף, תמיד מומלץ להשאיר 5-10% מחוץ לפרטישן שכותבים עליו, וזאת כדי לאפשר לבקר להזיז נתונים שנכתבים על תאים בעייתיים ובכך לתת לדיסק להמשיך לפעול כמצופה) וגם כאן יש כמות שנים לאחריות (3-5). על הנייר, במידה ותעבור את כמות ה-DWPD, דגל ה-Wear Out ב-S.M.A.R.T ידלק והאחריות תפוג.

כל מה שהזכרתי כאן – הוא "על הנייר", אבל המציאות שונה לחלוטין.

בניגוד לדיסקים מכניים, דיסקים SSD (שוב, אין זה משנה איזה חיבור, ולמעט דיסקים Optane מהקצה הגבוה – שהם אינם מבוססי NAND Flash) צריכים טמפרטורה מסויימת כדי לכתוב. בדרך כלל SSD במצב אידיאלי שלא מבצע עבודה יהיה בטמפרטורות הנעות בין 30-40 מעלות וכשמתחילים לכתוב נתונים, החום עולה, וככל שכותבים עוד ועוד נתונים (עשרות עד מאות ג'יגהבייט) החום עולה ברציפות וכשהוא מגיע בערך ל-78 מעלות ומעלה, מהירות הכתיבה יורדת משמעותית (אגב, זה קורה גם ב-Mixed Intense SSD אם כי בצורה פחות דרסטית) לעשרות מגהבייט עד קצת מעל 100 מגהבייט לשניה כשכותבים מעל 30-50 ג'יגהבייט באופן רצוף. בכתיבה אקראית/מזדמנת קצרה (עד 5-10 ג'יגהבייט, תלוי ב-SSD), ה-SSD יפעיל אלגוריתמים שונים שכל מטרתם היא לחסוך בכתיבה, כך שגם בעבודות כבדות מאוד, ב-99.99% מהמקרים לא תגיעו לכמות הכתיבה המותרת ביום (כמות הקריאה ביום אינה מוגבלת מבחינת אחריות בשום SSD), ולכן – אין זה משנה אם המערכת שלכם כותבת ביום 2 ג'יגהבייט או 300 ג'יגהבייט ביום על SSD – זה לא "טוחן" אותו (ולא תשמעו ממנו קולות כמו בדיסקים מכניים ישנים).

הדברים שכן יאיטו SSD הם:

  1. ניצול 100% מהדיסק כך שלא נשאר למערכת מקום להעברת מידע שמאוחסן בתאים דפוקים (ראו המלצה לעיל בנוגע ל-Provision).
  2. דיסקים SSD ביתיים זולים (Corsair MX300, MX500, סאנדיסק ביתיים ישנים)
  3. דיסקים SSD לא DRAM או SLC Cache שמשמש כחוצץ ל-NAND.

נקודה חשובה לגבי אחריות דיסקים (SSD או מכניים): היצרן מעניק אחריות לדיסק למשך מספר שנים המצוין (או לפי כמות כתיבות או לפני DWPD). בחברות שקונות את הדיסק מיצרן השרתים – התהליך קל ופשוט – נותנים אחד, מקבלים אחד. במקרים של קניה מאמזון – אפשר לפנות ישירות ליצרן, תצטרכו להציג חשבונית על מנת להתחיל תהליך החלפה. אצל חלק מהמוכרים בארץ של דיסקים דגמים ישנים לציוד ישן – האחריות היא מול המשווק בלבד (אולטרייד לדוגמא). בכל המקרים של החלפה מול היצרן, האחריות שתהיה על הדיסק המוחלף אינה אחריות מלאה ל-3-5 שנים אלא רק ליתרה של האחריות. לדוגמא: אם יש לנו מערכת בת 4 שנים (שקנינו אותה יחד עם הדיסקים שיש להם אחריות ל-5 שנים) ואנחנו מחליפים דיסק תקול, היצרן יתן אחריות למשך שנה בלבד (או 90 יום אם האחריות נגמרת עוד חודש נניח), ולכן במקרים כאלו אולי כדאי לשקול לקנות דיסקים חדשים.

נעבור מכאן לדיסקים SSD יד שניה: ישנם מדי פעם באתרי מכירה שונים (איביי, אמזון וכו') דיסקים משומשים של Enterprise במחיר זול ומפתה. אלו דיסקים שלא ממש יתאימו לחברות מכיוון שהיצרן לא יתן לכם כרוכשים אחריות כלשהי. מה שכן, הם יכולים להתאים למקומות ואנשים שלא אכפת להם לרכוש בזול תוך נטילת סיכון שלא תהיה אחריות. מבחינת ביצועים – לא אמורה להיות בעיה איתם. חשוב, אם אפשר, לבקש מהמוכר לראות תמונת סטטוס של ה-S.M.A.R.T לפני רכישה (בלינוקס אפשר לבדוק זאת עם smartctl, ב-Windows יש S.M.A.R.T. Monitoring Tools) ולבדוק מה הגבולות כתיבה שהיצרן ציין לגבי אותו SSD.

נקודה נוספת שחשובה הן בדיסקים NVME חדשים או יד שניה: אם אתם מחברים מספר דיסקים כ-RAID כלשהו (לא RAID-5!) ואתם מצפים לראות ב-OS מהירות כתיבה/קריאה כפול מה שכתוב על המדבקה/במפרט – תתכוננו להפתעות. Windows Server 2019 במערכת עם 12 דיסקים ב-RAID-6 לדוגמא נתנה ביצועים של … 10 ג'יגהבייט לשניה בקריאה, גם אחרי כיוונון כל הגדרה אפשרית, ובלינוקס עם ZFS יש תוצאות הרבה יותר טובות אך שאינן מגיעות למהירות המדבקה (אז אל תסמכו על JMeter).

דיסקים שכדאי לצפות לקראתם בשנה הבאה (לפי השמועות וההדלפות) – לכל אלו שצריכים דיסקים SSD NVME לעבודות כבדות (Cache, SQL) ואחרים:

  • סמסונג ZET דור שני וביצועים מאוד מרשימים בקריאה, ו-Latency שמאוד קרוב ל-DRAM
  • Optane דור שני – דיסקים יותר גדולים, פתרון יותר טוב לקירור, ביצועים בערך כמו הדור הנוכחי.
  • דיסקים SSD ל-Enterprise מבוססי QLC (כל היצרנים) זולים. עדיף לוותר, ביצועי כתיבה מחרידים!
  • שרתים עם דיסקים SSD בחיבור U.3 או מסוג Ruler. תהיו קונסרבטיביים ואל תרכשו – החברות (סמסונג, אינטל ועוד כמה) עדיין במריבות לגבי הסטנדרט. רוצים NVME? רק עם חיבור U.2 או כרטיסי PCIe.

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

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

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

בסיטואציה הראשונה, בדרך כלל התגובה הראשונית תהיה "תסתדר עם מה שיש", ואם באמת יש צורך בברזלים חדשים, יהיה צורך במספר ישיבות על מנת לשכנע את ההנהלה להתחיל תהליך לבנות מפרט, לבקש הצעות ממפיצים שונים, להחליט מה לרכוש, לרכוש, ואז להטמיע את זה ב-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 שונים כדי להעיף דברים שאינם בשימוש או צמצום דברים שאינכם משתמשים בהם כפי שחשבתם מלכתחילה.