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

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

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

הדרך לאימוץ טכנולוגיות חדשות

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

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

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

אז איך בעצם מתקדמים, למה כדאי להקשיב, מה כדאי לעשות או ללמוד?

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

הדבר השני – למפות את הצרכים שלכם במסמך מפורט, דברים כמו:

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

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

  • עניין ה-"הם רכשו" – בנק מסוים רכש, חברות X,Y,Z הגדולות והידועות קנו את המוצר, ואם הם קנו, אז אתם יכולים להיות רגועים ולהבין מכך שהמוצר הוא מ-ע-ו-ל-ה ובהחלט מתאים לכם.
    • את המידע הזה כדאי להכניס לראש בקטגוריית "נחמד לדעת" אבל לא לתת לזה להשפיע עליכם מסיבה פשוטה: אינכם יודעים מה גודל הפתרון שניקנה, האם הוא נקנה רק כי אותו לקוח קיבל הנחה ענקית, והאם אותו לקוח משתמש בזה רק באחוז קטן מאוד מהתשתית שלו. אתם לא מצפים שבנק מסוים, אם תתקשרו אליו, יתחיל לפרט לכם מה התשתיות שלו, נכון?
    • תשתיות שונות – נציגי השיווק מציינים בגאווה שהמוצר רץ בחברה גדולה X. למעט פתרונות חומרה, קשה מאוד לדעת על איזו חומרה ועל איזה ציוד הפתרון רץ, כך שיכול להיות שאצל אותו לקוח הפתרון יטוס, אולם עקב תקציב מינימלי שיש לכם, הפתרון ירוץ אצלכם בצורה איטית.
  • שאלות ותשובות – חשוב לזכור: נציגי הפתרון רוצים למכור לכם את הפתרון ולכן כל פתרון מתחרה הוא זבל ומי שתומך/ממליץ על המוצר המתחרה – בכלל לא מבין בתחום. לא תשמעו דברים טובים על הפתרונות המתחרים ולשאלות טכניות במקרים רבים תקבלו תשובות סובייקטיביות.
  • נקודה חשובה מאוד: במהלך הישיבה יובטחו לכם דברים שונים (מבחינת ביצועים, עלויות וכו') – שום הבטחה לא שווה אלא אם היא כתובה בלשון ברורה על הנייר וחתומה. ראיתי מספיק מקרים שבו נמכרו ללקוחות פתרונות אחסון עם הבטחה לכמות IOPS מסוימת, ואחרי שנתיים כשלהקוח הפסיק לקבל את אותם IOPS וכשהוא פנה אליי, הסתבר שנציגי המכירות לא ממש טרחו להסביר לו את עניין ה-Wear Leveling.

ככל שתפגשו עם יותר נציגים שמוכרים פתרונות שונים, תקבלו יותר ויותר מידע מוטעה. הנציג הקודם עם המוצר המתחרה הבטיח X מבחינת ביצועים? אפשר לקבל את X במוצר המתחרה – אם תשקיעו עוד 100,000$ בחומרה לדוגמא. בקיצור – תתכוננו להטעיות (עם/בלי כוונה).

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

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

קיבלתם יעוץ ובחרתם פתרון? ברכותיי. עכשיו הגיע השלב להטמיע את הפתרון.

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

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

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

בהצלחה.

אחסון רגיל מול 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% (ברוטו) כל חודש?

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

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

ולעצמאים:

  1. חישוב צריך להתבצע לפי מחיר פר-שעה, בניכוי כל המיסים (ביטוח לאומי, מס הכנסה, מע"מ, עכשיו הוסיפו גם צורך לשלם פנסיה בתנאים סופר גרועים).כמה העצמאי או החברה המפנה גוזרים, ומה הסכום שאתה מקבל בפועל. אם הם גוזרים סכום סביר (נניח 10%, אולי יותר, תלוי מה אתה מחשיב "סביר") ומדובר על עבודה ארוכה או עבודה שדורשת כמות שעות כל חודש, אז עבודה כזו יכולה להיות הכנסה מעולה לכסות מספר הוצאות שחוזרות כל חודש (שכר דירה/משכנתא, מיסי רשויות), וכדאי לסגור דיל. מצב נוסף שכדאי לקחת בחשבון – חברה מפורסמת עם פוטנציאל לעבודות עתידיות שם.
  2. … אבל מצד שני, אם אחרי כל הקיזוזים שהם חובה ("שותפים טבעיים") ובקיזוז מה שהמפנה גוזר מביא אותך לרף התחתון של המחירון שלך ומטה, או שהוא אומר את המילים "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 אחר.