הבלוג של חץ ביז

אחסון רגיל מול vSAN, Nutanix ופקטורים אחרים

לפני כמה ימים יצא לי לשוחח עם מישהו שפנה אליי מהבלוג לגבי פרויקט שהם מתכננים. מטבע הדברים אינני יכול לפרט, אבל משהו אחד שאני כן יכול לאמר (באישור שלו) – זה שהם מתכננים רשת ממש "אכזרית". כמה "אכזרית"? יש לא מעט ארגונים (בנק הפועלים לדוגמא, לפי פרסום שלהם) שמשתמשים ב-100 ג'יגהביט רשת ל-Backend, פה מדובר על 100 ג'יגהביט פר שרת. מכיוון שלא סגרנו חוזה ודיברנו על כרטיסים, הזכרתי בשיחה כרטיס מסוג CONNECTX-5 EN ADAP שיכול לעמוד יפה במשימה, אך המלצתי לו שבשביל השרידות, הוא יצטרך 2 כרטיסים כאלו וכאן הכל קשור ל-Fear Factor.

מה הכוונה? אם הלקוח רוצה לרכוש את הכרטיס הנ"ל ישירות מהיצרן, אז הוא ישלם 795$. לעומת זאת, אם הוא ירכוש זאת דרך יצרן השרתים שהוא משתמש (HPE) – הוא ישלם על אותו כרטיס בדיוק – 1600-2100$, וכאן בעצם נכנס ה-Fear Factor: ככל שחברה יותר גדולה, מפעילים יותר "ראש קטן" וקונים מיצרן השרתים בגלל Fear Factor וחשש שמא, אולי, יצרן השרתים לא יתן תמיכה, גם אם המחיר הוא פי 2-3. ככל שהחברה לעומת זאת יותר קטנה או שיש בה ראש צוות IT/מנמ"ר שמפעיל ראש יותר "גדול" – הוא ירכוש במחיר היותר נמוך, כל עוד הוא מקבל מסמך אחריות ותמיכה מיצרן הציוד.

מכאן נעבור לאחסון ונראה כיצד ה-Fear Factor יכול להשפיע.

"על הנייר" מבחינה טכנית נטו – אחסון בשיטת Scale out היה אמור לכבוש נתחים גדולים בשוק ולפגוע במכירות אחסון Scale Up מסיבות ידועות: אפשר להגדיל את כמות האחסון ללא השקעה כה מאסיבית מבחינה פיננסית, אפשר להגיע לכמות IOPS רצינית מאוד בכך שמשדכים עוד ועוד שרתים, והשרידות של פתרונות Scale Out מעולה. מבחינת שוק אחסון Scale Out, החלוקה די פשוטה: Nutanix בקצה הנמוך, vSAN בקצה הנמוך עד בינוני, Ceph בקצה הגבוה (כשאני מדבר על קצה גבוה – אני מדבר על החל מ-1-2 פטה ומעלה ועד כמות דו ספרתית של פטהבייטים).

אני רוצה לתת דוגמא של יעוץ שעבדכם הנאמן נותן כשזה מגיע לאחסון Scale Out שמגיע לפטהבייטים – אל תרכוש דיסקים מיצרן השרתים ותכניס לשרתים (למעט 2 דיסקים SSD בתצורת M.2 לאחסון מערכת הפעלה). רכוש שרתים בתצורת 1U, ו- JBOD גדול (12-24 דיסקים), ואז לחבר את ה-JBOD לשרתים ולסגור עיסקה עם מפיץ/יבואן של דיסקים כולל SLA. במקרים של הטמעות כאלו, מדובר על מאות או אלפי דיסקים, ושיטה כמו שאני מציע תחסוך משמעותית במחיר הפרויקט.

את הדבר הזה לדוגמא, קשה "למכור" לארגונים בינוניים עד גדולים בגלל ה-Fear Factor שהזכרתי לעיל, שאולי, חס ושלום, יצרן השרתים לא ירצה לתת תמיכה (או במקרה של HPE, זה יעבוד אבל לא יתן חיווי טוב לגבי הדיסקים אם מכניסים דיסקים צד ג'), ולכן הם יעדיפו לשלם פי 2-3 פר דיסק, גם אם תראה להם שהם משלמים הרבה יותר מדי. זו בדיוק אחת הסיבות שחברות רבות העדיפו לרכוש אחסון Scale Up.

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

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

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

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

ברמת המאקרו: 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. לא ניתן לערבב.

הבעיות של מחשבי Thinkpad ו-Thunderbolt

ישנן חברות רבות שרוכשות ומשתמשות במחשבי Thinkpad ניידים עבור העובדים כמעט בכל הדרגות, ויש סיבה די טובה לכך: מחשבי ה-Thinkpad בדגמים היותר "רציניים" (T, X ואחרים, לא L, E) המחשבים רצים בצורה יציבה עם ביצועים קבועים לכל אורך הדרך.

יחד עם זאת, לפחות בשנה האחרונה, יש יותר ויותר תלונות של משתמשים על תקלות במחשבים הניידים הכוללים חיבורי Thunderbolt כ-USB-C, החל מבעיות של אי-טעינת המחשב, HDMI דרך Docking לא פעיל, ה-Thunderbolt לא מופיע ב-Device Manager ועוד שורה של תלונות.

הדבר הראשון שצריך להבין לגבי כל חיבורי ה-USB-C שיש באותם מחשבים, זה שהחיבורים, למרות שהם נראים מבחוץ זהים, הם שונים. יש חיבורי USB-C שהם בעצם Thunderbolt והם מסומנים באמצעות סימלון "ברק" ליד החיבור וחיבורים אלו מקושרים ישירות לשבבי Thunderbolt מסוג Alpine Ridge ו-Titan Ridge של אינטל, ואילו חיבורים אחרים הם חיבורי USB-C שמחוברים ישירות אל ה-Chipset שקשור למעבד במחשב ואין לו שום קשר ל-Thunderbolt. חיבורי USB-C רגילים יכולים לכלול החל מדברים מאוד בסיסיים כמו USB 2.0, הובלת חשמל (עד 100W), וחיבוריות ציוד מגוון מאוד. לעומת זאת, ה-Thunderbolt לוקח את מה שנתמך בסטנדרט USB-C רגיל ומוסיף לו שורת מצבים של Alternative Modes דרך ממשק PCIe תוך שימוש בשבבים שונים (ויקרים)שנמצאים בתוך המחבר (בדרך כלל הדבר יצוין עם סימלון ברק על המחבר).

לכן, בשלב הראשון יש צורך לבדוק מאיזו כניסה יש בעיה. לדוגמא – במחשבים כמו T480s ישנם שני חיבורים שנראים זהים, האחד עבור ה-Dock והאחד לחשמל. רק החיבור ל-Dock הוא חיבור Thunderbolt והשני הוא חיבור USB-C שמגיע מה-Chipset. (את החשמל, אגב, ניתן לחבר לכל אחד מהחיבורים, זה לא משנה, שניהם תומכים ב-Power Delivery).

לנובו טוענת שהבעיות שהוזכרו נבעו מקושחה (SPI-ROM) גרועה שהופצה ב-2018 עד אמצע 2019 וכי עדכוני קושחה שיצאו החל מאוגוסט 2019 (יצאו מאז לפחות 2 עדכונים קטנים נוספים) תיקנו את הבעיות הנ"ל, ולכן אם אחת מהבעיות שצוינו בקישור עדיין מופיעה לך, אתה צריך לפתוח קריאת שרות להחליף לוח אם ולהתקין את העדכונים האחרונים (כולל קושחה ודרייברים) ל-Thunderbolt. החלפה של לוח לא מתקנת את הבאג אבל כן כוללת בקר Thunderbolt שצריך את העדכון.

יחד עם זאת, ישנן עדיין בעיות שלא קשורות ל-Thunderbolt או ל-Dock וכן קשורות למערכת ההפעלה שאתה משתמש (במיוחד ב-Windows 10) הקשורות ל-Sleep. נניח שאתה לוקח את המחשב הנייד שלך לסבב ישיבות בחברה ואתה חוזר למשרדך, מחבר ל-Dock, לוחץ להפעלה לצאת ממצב שינה והופס – המחשב מתחיל תהליך Cold Boot, ותקווה שהמסמך שעבדת עליו – נשמר בהצלחה לפני שהמחשב החליט לעשות את השטות הזו. אישית, דיווחתי בעבר ללנובו על הבאג הזה פעמיים וקיבלתי תשובות שטותיות (כמו להסיר את התקנת האודיו של Realtek. ה"התקן" בסך הכל עושה Mixing, הוא לא מפעיל שבב נוסף כי אין שום שבב של Realtek במחשב הנ"ל). הבאג, אגב, אינו מתרחש עם מערכות הפעלה אחרות (אני עובד ברוב הזמן עם Fedora 31 על ה-Thinkpad שלי) כך שמדובר במשהו ספציפי ל-Windows שלנובו צריכים לתקן.

לסיכום: חלק מהבעיות אכן קשורות ל-Thunderbolt אך חלק מהבעיות קשורות ל-OS ודרייברים גרועים והגדרות שגויות של לנובו ללא קשר ל-Thunderbolt ב-Windows ובעיות כאלו קיימות גם במחשבים ניידים מתוצרת חברות אחרות (Dell, HP, ASUS, MSI ואחרים). הדור הבא של מחשבים ניידים מתוצרת כל החברות יכללו בחלקם את המעבדים החדשים של אינטל, הדור העשירי, שכוללים Thunderbolt בתוך המעבד, כך שיהיו דגמים רבים שכל חיבורי ה-USB-C שלהם יהיו חיבורי Thunderbolt עם תמיכה מלאה ובתקווה לכמות באגים אפסית.

דעה: כמה מילים על אחוזים

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

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

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

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

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

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

עכשיו אעבור לשכירים שעובדים דרך חברות "גולגלות", "כח אדם" וכו'. אותם שכירים יקרים מקבלים משכורת מאותן חברות כח-אדם/גולגלות בכל חודש, ללא קשר מתי הלקוח שהם עובדים אצלו – משלם לאותן חברות (במקרים רבים התשלום יגיע לאותן חברות בתנאים של שוטף+60,90,120 ויש גם כאלו שמשלמים שוטף+180), כלומר אותן חברות המעסיקות את השכירים ישירות סופגות את הסיכון לגבי תשלום מאוחר או אי תשלום. הדבר שאולי כדאי ששכיר ידע – מה המחיר שאותה חברה שהוא מגיע אליה יום יום, משלמת על שרותיו לאותה חברת כח-אדם ומה בעצם הוא לא מקבל. אם, לשם הדוגמא, כשכיר, אתה מקבל 80 שקלים לשעה (החישוב הגס הוא: חלוקת משכורת הברוטו שלך ב-200 שעות לחודש) ואתה מצליח להבין שהחברה שאתה נמצא משלמת עליך כ-160 שקלים לשעה, אז אתה בעצם מפסיד 50% (ברוטו, ברוטו, אנחנו בישראל) משכורת. איך ההרגשה לא לקבל עוד 50% (ברוטו) כל חודש?

לכן, לשכירים, אני ממליץ מספר דברים:

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

ולעצמאים:

חישוב צריך להתבצע לפי מחיר פר-שעה, בניכוי כל המיסים (ביטוח לאומי, מס הכנסה, מע"מ, עכשיו הוסיפו גם צורך לשלם פנסיה בתנאים סופר גרועים).כמה העצמאי או החברה המפנה גוזרים, ומה הסכום שאתה מקבל בפועל. אם הם גוזרים סכום סביר (נניח 10%, אולי יותר, תלוי מה אתה מחשיב "סביר") ומדובר על עבודה ארוכה או עבודה שדורשת כמות שעות כל חודש, אז עבודה כזו יכולה להיות הכנסה מעולה לכסות מספר הוצאות שחוזרות כל חודש (שכר דירה/משכנתא, מיסי רשויות), וכדאי לסגור דיל. מצב נוסף שכדאי לקחת בחשבון – חברה מפורסמת עם פוטנציאל לעבודות עתידיות שם.
… אבל מצד שני, אם אחרי כל הקיזוזים שהם חובה ("שותפים טבעיים") ובקיזוז מה שהמפנה גוזר מביא אותך לרף התחתון של המחירון שלך ומטה, או שהוא אומר את המילים "Back to Back", אני ממליץ לך לשקול היטב אם בכלל לקחת את העבודה הזו.

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

בקרוב: Azure בישראל – עם קצת יותר פרטים

מיקרוסופט הכריזה היום על כך שהם מקימים בארץ … Data Center, אם להאמין למאמרים שהתפרסמו ב-Geek Time. ב-The Marker כתבו נכונה שמיקרוסופט הולכים להקים בעצם Region, אבל גם הם נפלו בהסברה וכתבו "..חוות שרתים מקומית שתשמש את תשתית הענן שלה". אני יכול להמשיך, אבל אני חושב שהפואנטה ברורה…

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

אז כן, מיקרוסופט אכן מקימה Region. מה קרה שמיקרוסופט מכריזה עכשיו ולא לוקחת את הזמן ומודיעה בעתיד? חכו עוד קצת ותראו….

ה-Region שיוקם בישראל אינו מורכב מחוות שרתים אחת. ולמיטב ידיעתי, מיקרוסופט לא הולכת לזרוק כמה מאות/אלפי שרתים אצל בזק או סלקום ולהכריז "Region חדש!". בעסה לכל מיני ספקים בארץ, אז לא..

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

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

מכאן נעבור לחלק שמיקרוסופט לא תסכים לעולם לאשר או להכחיש (והאמת – לא דיברתי איתם על כך ישירות). מיקרוסופט יהיו בין הספקים הראשונים שיכניסו כאן את הדורות החדשים מבחינת תשתית מבוססת OCP מהדור האחרון, שימוש במעבדים של AMD EPYC (בדגמים שאי אפשר לרכוש, כמו 7H12), שימוש ב-CXL, טכנולוגיות מיתוג חדש בין ציוד למעבדים ועוד ועוד – בקיצור, אם השמועות שקיבלתי נכונות, הטכנולוגיה שתנחת כאן בארץ תהיה מה"מילה האחרונה".

בכל הקשור Azure 365 (כלומר Azure עם אינטרגציה ל-Office 365) – זה יגיע אחר כך. מתי? שאלה טובה.

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

ועוד נקודה קטנה: זוכרים ש-Med1 הכריזו שיש להם Azure ושפרסמתי שזה לא ממש Azure ושזה בסך הכל Azure Stack שממש לא שווה לרכוש כספית? אז בקרוב יהיה פה ה-"Real Deal" וספקי ההוסטינג/VPS/COLO המקומיים מוזמנים להתחיל להיכנס לפאניקה. נשארה עוד שנה-שנה וחצי.

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

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