קטגוריה: אחסון / Storage

הולכים לרכוש דיסקים קשיחים? שימו לב!

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

יצרניות הדיסקים הקשיחים מנסים כל הזמן להגדיל את כמות האחסון פר דיסק ואחת השיטות שכל יצרני הדיסקים הטמיעו נקראת SMR או Shingled Magnetic Recording. בשיטה זו, כשכותבים נתונים על הדיסק ובאותו אזור שבו הדיסק רוצה לכתוב, כבר קיימים נתונים – אז הבקר של הדיסק יורה למערכת לקרוא את הנתונים הקיימים בדיסק, לצרף אותם (בזכרון המכונה) לנתונים שצריכים להיכתב – ולכתוב את הכל מחדש. כל התהליך הזה לא קיים בדיסקים קשיחים רגילים שמשתמשים בשיטת קריאה/כתיבה שנקראת PMR ולפיכך דיסקים קשיחים שעובדים בשיטת SMR מתאימים יותר לצרכי גיבוי ארכיבאי, הווה אומר: אם אתה רוצה לגבות כמות גדולה של מידע בצורה חד פעמית ולהכניס לאחר מכן את הדיסק לארון או כספת או לשלוח את הדיסק Off Site – אז דיסקים כאלו מעולים לכך. בקיצור – אלו דיסקים שמתאימים כ-WORM.

מכאן נעבור לשוק ה-NAS, השוק בו אותן חברות בדרך כלל מוכרות ללקוחות וליצרני קופסאות NAS דיסקים קשיחים בגדלים של 2-8 טרהבייט. חברות כמו Western Digital גם מייצרת 2 משפחות דיסקים ל-NAS, האחת היא סידרת RED והשניה היא סידרת Red Pro, כאשר ה-Red Pro יותר מתאים ל-Enterprise הואיל והדיסקים שם מגיעים בחיבור SAS ולא SATA. יצרנים אחרים גם יעדו דגמים ומשפחות שונים של דיסקים לשוק ה-NAS. אחרי הכל זהו שוק שגודל וסקטור ה-SMB קונה המון ממנו מחברות כמו Synology או QNAP.

וכאן הגיע תחמון חדש מצד יצרני הדיסקים.

כפי שציינתי לעיל, דיסק מבוסס SMR מתאים לצרכים של קריאה מרובה אך אינו מתאים לצרכים של כתיבה מרובה (גם לא כתיבה של 50% ומטה!) ולכן אם אתם רוצים לרכוש דיסקים לשרתים שלכם (מצד ג') או דיסקים ל-NAS שלכם, חשוב יהיה לוודא שהדיסקים עובדים בשיטה כמו PMR, CMR או שיטות מתקדמות אחרות (יש שיטות כאלו אולם עדיין לא יצאו לשוק המסחרי דיסקים המבוססים בשיטות החדשות) ולא SMR.

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

חמור מכך: חברות כמו Western Digital טענה כי רק הדיסקים בגודל 20 טרהבייט שלהם עובד ב-SMR, אבל כפי שתוכלו לראות כאן וכאן, הם לא בדיוק אומרים את האמת – וגרוע מכך, הם מסרבים לענות כששואלים אותם מהי שיטת הקריאה/כתיבה של דגם ספציפי. אם יש לכם דיסקים של WD, אז אם אותם דיסקים מסתיימים ב-EFRX אז אלו דיסקים שעובדים PMR/CMR ואין שום בעיה לעבוד איתם, הם מעולים. אם לעומת זאת הדגם שלהם מסתיים ב- EFAX – אז כדאי להחליף אותם.

מאז שהתפוצצה הפרשה הזו – גם Seagate וגם טושיבה הודו שגם הם משתמשים בטריק הזה. כאן אפשר לראות לגבי הדיסקים של Seagate וכאן אפשר לראות לגבי הדיסקים של טושיבה.

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

האם שווה לרכוש VxRail או Nutanix Appliance?

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

מהצד של VMWare חברת Dell מציעה מספר מערכות תחת שם המטריה VxRail. מהצד של Nutanix, כל היצרנים הגדולים מציעים קופסאות שעברו את כל מה שתיארתי לעיל והן מוכנות לקבלת הגדרות ראשוניות ולהתחלת עבודה. בשתי סוגי הפתרונות, מחכים לאיש ה-IT חיים קלים, מבטיחים היצרנים.

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

לפני שנוכל לענות על כך, ננסה להסתכל במבט על – על התשתית ב-DC המקומי של החברה. בכל ארגון גדול בדרך כלל תהיה תשתית Life cycle management כלשהי שנועדה בראש ובראשונה להציג לנו את מצב החומרה שיש ב-DC, בין אם מדובר במתגים, אחסון, שרתים, UPS וכו'. יצרניות השרתים לדוגמא כוללות גירסה פשוטה של ניהול השרת וגירסת Enterprise בתוספת תשלום. אותו ניהול יתריע בפנינו אם יש תקלת חומרה, אם יש צורך להחליף חומרה וכו'. בפתרונות אחסון יש משהו קרוב שמתריע שעלינו להחליף דיסק או להתייחס לבעיה אחרת, וכנ"ל במתגים, UPS וכו'. בדרך כלל אנחנו נחבר את כל המערכות הללו למערכת ניטור מרכזית אחת שתוציא לנו התראות לכל הדברים הנדרשים.

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

היתרון השני שעליו מדברים יצרני הקופסאות הוא ניהול הרבה יותר קל של אותן קופסאות. בקופסאות עם VxRail לדוגמא, יש את תוכנת VxRail Manager (הנה הדגמה) שנותנת לך לא רק לחבר שרת חדש ל-Cluster קיים, אלא גם להתקין תוכנות מה-Market, לתחזק את השרתים, לכבות, להדליק וכו'. אבל כפי שציינתי לעיל – חברות מעדיפות לנהל את הדברים במרוכז, כך שאם לחברה יש נניח מערכת iDrac Enterprise, עדיף לחבר את כל קופסאות ה-VxRail ל-iDrac Enterprise ולנהל משם, ולא דרך ה-VxRail Manager, ואותו דבר לגבי קופסאות שמריצות פתרון HCI של Nutanix.

אז למי בעצם כדאי לרכוש את הקופסאות הללו? אני חושב שקופסאות כאלו מתאימים ל-2 סיטואציות:

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

לעומת זאת, למי לא כדאי לרכוש את הקופסאות הללו:

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

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

הכנות לסיטואציית בידוד

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

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

  • רוחב פס: יש לכם 100 מגה או 1 ג'יגה או יותר – רוחב פס לחיבור לאינטרנט, ועליו אתם מחברים משתמשים דרך VPN. גם אם יש לכם 1 ג'יגה, זה לא אומר שיש לכם 1 ג'יגה נטו ל-VPN, רחוק מכך: כל VPN מממש הצפנה בדרך משלו (עם Ciphers שונים, תלוי במעבד שיש בקופסא או מה שהוגדר ב-Appliance הוירטואלי וכו') כך שעם חיבור 1 ג'יגה לדוגמא, יכול להיות שיש לכם אולי 500-600 מגהביט ברוטו. אם יש לכם כמה עשרות משתמשים שמתחברים לחיבור כזה (ונוסיף לכך את הגלישה באינטרנט שתעבור דרך החיבור הזה) אתם תמצאו את עצמכם מהר מאוד בבעיה של איטיות גלישה/התחברות/גישה לקבצים.
    אפשר לשם הניסוי לחבר מספר משתמשים סימולטנית ל-VPN שיש ברשותכם ולנסות לבצע חישוב מהירות כמה כל משתמש מקבל ולחלק את זה תיאורתית בהמשך, אבל תצטרכו בהמשך לקחת כאופציה את העניין שתצטרכו מהר מאוד לשכור רוחב פס הרבה יותר גדול ולבדוק שהתשתית VPN שלכם יכולה לעמוד בכמות גדולה של חיבורים.
  • ענן ציבורי ו-VPN משני: אפשרות נוספת לגבי חיבורי VPN של המשתמשים, אם הקמתם כבר תשתית בענן ציבורי כלשהו (אני מדבר על השלישיה, לא על "עננים" מקומיים ישראליים) – אפשר להקים VPN בתשתית הוירטואלית, לחבר את אותה תשתית וירטואלית ב-Site to site אל ה-VPN המקומי בארץ בארץ ולאפשר למשתמשים להתחבר דרך הענן אל התשתית המקומית שלכם. אתם תשלמו על התעבורה ועל שרות ה-VPN בענן, אבל אתם תשלמו רק על השימוש, לא תשלום חודשי/שנתי.
  • העברת חלק מהתשתית לענן ציבורי: תלוי בחברה ובתשתית, בחלק מהמקרים ניתן לשכפל מספר מערכות או פשוט להעביר מספר מערכות לתשתיות וירטואליות בענן הציבורי ואותן תשתיות יתנו שרות למשתמשים מבחוץ. חשוב לדאוג לסינכרוניזציה בשני הכיוונים (בין הענן לתשתית On Prem). לעניות דעתי, כדאי לחשוב על כך.
  • בדיקת תשתיות ניטור: במשרד רואים על מסכים גדולים את התקלות, מה רץ, מה לא. בבית – לא רואים כלום, ולכן חשוב לבדוק שאפליקציות הניטור שולחות התראות דרך תשתיות חיצוניות (מייל, SMS, וואצאפ וכו') ושיש מי שיטפל בתקלות (עבודה מהבית במקרים רבים אצל לא מעט אנשים היא סיבה מצויינת "להבריז" לטובת דברים אחרים).
  • צפו לתקלות תקשורת: אם בעתיד יוכרז במדינה "עוצר" (כפי שהוכרז אתמול באיטליה), תקלות תקשורת לא יהיו "אם" אלא "מתי" (פה בישראל, אל תאמינו לשום ספק תקשורת לגבי שרידות, ראינו את זה רק לפני שבועיים כמדומני, בתשתית של בזק/מטרו) ולכן כדאי לתת את הדעת על פעילות המערכת On Prem כשאין תקשורת ומה כדאי להוציא החוצה לענן הציבורי בחשבונכם וב-VPC שלכם שימשיך לעבוד.

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

בהצלחה.

על דיסקים ואחסון

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

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

אבל מה קורה אם יש צורך להזמין כמות גדולה של דיסקים? (ב"גדולה" אני מדבר על כמויות של 30 ומעלה – בתור התחלה). ניקח את זה יותר לכיוון המציאות: אתם רוצים להקים תשתית וירטואליזציה Scale Out עם vSAN או Nutanix. אתם לא רוצים עדיין לרוץ לכיוון All Flash ולכן אתם רוצים לשלב דיסקים מכניים גדולים יחד עם SSD שישמשו כ-Cache. ב-2 הפתרונות המתחרים, כמות ה"ברוטו" מבחינת הדיסקים שתכניסו – רחוקה מאוד מכמות ה"נטו" שתקבלו בפועל לשימוש, ולכן אם נרצה כמות תלת ספרתית של אחסון נטו פנוי, נצטרך לרכוש לא מעט דיסקים עבור מינימום 3 שרתים. נניח לשם הפוסט – שנצטרך 21 דיסקים מכניים ו-3 SSD (כלומר 7 מכניים ו-1 SSD פר שרת).

לפני שנעבור לחישובים שונים, בוא נשנה לרגע נושא ונדבר על שרידות: כיום בשוק, אצל רוב מוחלט של החברות, מצב השרידות שקיים הוא מצב שהמערכת יכולה להמשיך לעבוד, כל עוד דיסק אחד הוא תקול. במקרה והתקלקל דיסק, מפעילים את ה-SLA ותוך 4 שעות יגיע טכנאי ויתן לכם דיסק חלופי, תחליפו את הדיסק בשרת/מערך אחסון, הפעילו תהליך Rebuild. מה יקרה אם יתקלקל עוד דיסק עוד לפני שהקודם הוחלף ובוצע Rebuild? תקוו שהגדרתם דיסק אחד כ-Hot Spare – אחרת אתם בצרות.

נחזור לחישובים: כיום, בין אם מדובר בישראל או כמעט בכל מקום אחר בעולם, רכישת דיסק קשיח, בין אם מדובר ב-SSD או מדובר בדיסק מכני, תעלה אצל יצרן שרתים פי 2-3 בהשוואה לרכישה מיבואן רשמי בארץ. תרגום: אם דיסק כלשהו עולה $100 אצל יבואן רשמי, אצל יצרן שרתים, אותו דיסק יעלה 300-$200. את ההבדל הזה די קל לבלוע כשמדובר על רכישה של שרת אחד עם 4-5 דיסקים. ראש שקט, רכישה חד פעמית, תשלום חד פעמי, לא עושים מזה סיפור.

אבל אם נסתכל על הדוגמא לעיל עם ה-Scale Out בשביל ה-Nutanix/vSAN (או GlusterFS, או Ceph), אנחנו מדברים על 21 דיסקים, ואנחנו נשלם בפועל מחיר של 50-60 דיסקים. אתם לא צריכים להאמין לי, אתם יכולים ליצור קשר ישירות עם היבואנים בארץ:

  • דיסקים של חברת טושיבה – חברת CRG
  • דיסקים של חברות Seagate, Western Digital – חברת ח.י.

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

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

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

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

כמעט כל ארגון שמריץ פתרון וירטואליזציה (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 יכול כנראה להתאים.