קטגוריה: שרתים

גישות SaaS/PaaS והגישה ההיברידית

כמעט בכל חברה יתקיים מצב בו החברה תחפש תוכנה שתבצע שרות X או שתתן שרותי פלטפורמה Y במקום "להמציא את הגלגל" מחדש בכל פעם. אם לדוגמא העסק מעוניין לשלוח איחולי חג שמח לכל הלקוחות, ניתן יכול לשכור שרותי Saas של חברה כמו Mailchimp לדוגמא ובתמורה תקבלו ממשק קל לשימוש וסיכוי מאוד גדול שכל לקוחות העסק יקבלו את המייל. מצד שני אפשר בעזרת מעט סקריפטולוגיה ושימוש באמזון SES לבצע את אותו דבר אך במחיר זול בהרבה (יכול לחסוך לא מעט אם לחברה יש מאות אלפי או מיליוני לקוחות לדוגמא). אפשר כמובן לקחת גם את האופציה החינמית ולהקים שרת מייל או להשתמש בשרת מייל מקומי כדי לשלוח את הררי האימיילים, אבל במקרים כאלו הסיכוי שהמייל יתקבל אצל כל הלקוחות הוא די קלוש – אם לא משקיעים בכל עניין של Whitelist, RBL, דבר שלוקח לא מעט זמן ומשאבים.

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

  1. עלויות תמיכה – ככל שתוכנה נמכרת כ-Stand Alone, עלות התמיכה ליצרן התוכנה תהיה גבוהה, מכיוון שיש לא מעט סיכוי שהתוכנה לא תעבוד בסביבות או מכונות שונות, הרשאות שגויות, חוסר ידע טכני של הלקוח ועוד. ככל שהתומכים הטכניים יהיו עסוקים יותר ויותר שעות בפתרון בעיות של לקוח ספציפי זה או אחר, הרווח של יצרן התוכנה ירד. אחרי הכל, אף אחד לא משלם ליצרן התוכנה אם מחלקת התמיכה השקיעה 10 שעות בפתרון בעיה אצל לקוח יחיד לדוגמא.
  2. פיראטיות – בהרבה מאוד חברות הצוות מוריד אפליקציה או פלטפורמות מסויימות למטרת Trial ומיד לאחר מכן הם מחפשים כל מיני כלים ודרכים כדי לפרוץ את ה-Trial. הרווח של יצרן התוכנה ממקרים כאלו – אפס.

מהרגע שיצרן התוכנה מציע את מוצריו כ-PaaS או SaaS, הדברים נהיים יותר קלים עבורו:

  1. אין פיראטיות
  2. עלויות התמיכה מצטמצמות משמעותית הואיל והכל רץ בתשתית וירטואלית של יצרן התוכנה בעננים שונים ומקרי התמיכה נהיים יותר ויותר פשוטים כי ניתן לשחזר את התקלות במחלקת התמיכה של יצרן התוכנה.
  3. תזרים הכנסות חודשי/שנתי רציף מהלקוחות.
  4. קצב הפיתוח מואץ יותר, באגים ופונקציונאליות חדשה נכנסת ל-Life Cycle של השרות במהירות גבוהה יותר ובכך דרישות לדברים חדשים שלקוחות מבקשים – נענים במהירות גבוהה יותר.
  5. אין צורך בתמיכת Legacy הואיל וכולם עובדים על גירסה אחת או שתי גרסאות.

אך יש גם חסרונות:

  1. עלויות תשתית הרבה יותר גבוהות בענן ציבורי. בניגוד למכירת תוכנת Stand Alone שלא מתחברת החוצה, כאן פתרון ה-Saas/PaaS יצטרך חיבור קבוע למשאבים שונים של יצרן התוכנה.
  2. אבטחת המידע צריכה להיות הרבה יותר רצינית בהשוואה למקרים של תשתית סגורה החוצה. מהרגע שמתגלה אצל יצרן כזה דליפת מידע, יש סיכוי לא רע שחלק מהלקוחות יעדיפו לנטוש ולחפש פתרון מתחרה.

אלו, פחות או יותר הסיבות שבגללן חברות תוכנה יעדיפו להציע שרותי PaaS/SaaS.

אחת הנקודות שבמקרים רבים אינני רואה התייחסות מצד אותן חברות – היא למקרים שהלקוח אינו מוכן "לעבור All In", כלומר הלקוח לא מוכן שכל ה-DATA שלו ישב בתשתית של יצרנית תוכנה ולו (ללקוח) לא תהיה שליטה על הנתונים מבחינת אבטחת מידע או בכלל מהבחינה העקרונית שזה ישב בתשתית של חברה אחרת שאין לו מושג ירוק לגביה. זו לדוגמא אחת הסיבות שחברות יעדיפו לוותר על פתרון SaaS/PaaS שמוצע רק על ענן ובמקומו הם יעדיפו פתרון שרץ מההתחלה ועד הסוף על תשתית מקומית (On Prem).

מה שלעניות דעתי אותן יצרניות תוכנה PaaS/SaaS צריכות להציע – הן את האפשרויות הבאות (אחת או יותר), משהו שהוא יותר מעין "Hybrid":

  1. ה-DATA של הלקוח יכול להיות מאוחסן On Prem עם Agent שמתחבר לענן. לשרות תהיה גישה עם הרשאות מאוד מוגבלות
  2. אם ללקוח יש חשבון בענן ציבורי כלשהו, הלקוח יוכל להגדיר אחסון אובייקטים כלשהו (S3 לדוגמא) עם הרשאות מוגבלות שינתנו בעת הפעלה ראשונית של שרות ה-SaaS/PaaS והרשאות אלו יהיו תחומים למשאבים מסויימים בלבד (נניח Bucket כלשהו)
  3. הלקוח יצטרך לבחור כבר בהתחלת שימוש ה-PaaS/SaaS את ה-Passphrase שלו (ובלבד שיהיה מורכב) ועם אותו Passphrase (ואולי יחד עם עוד מספר נתונים) יוצפן ה-DATA של הלקוח כך שגם ליצרן התוכנה לא תהיה גישה לנתונים. (אפשר כמובן במקום Passphrase יהיה אפשר להשתמש במפתחות פרטי/ציבורי יחד עם Passphrase)

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

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

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

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

הוירוס, עבודה מרחוק – והלאפטופ

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

מהרגע שעניין הוירוס קיבל דחיפות יותר ויותר גדולה בארץ, חברות עטו על יבואני מחשבים לרכוש לאפטופים לעובדים, בין אם מדובר ברכישה קטנה של בודדים או מאות. כל לאפטופ קיבל טיפול פירמוט והתקנת Image עם כל האפליקציות של החברה, חיבור VPN, חיבור לשיחות וידאו ועוד מספר דברים – וכך כיום רוב החברות עובדות: מרחוק, עם VPN, עם Zoom/teams/WebEx/Skype לצורך פגישות ושיחות וכו'.

וכאן גם מתחילה הבעיה הגדולה, בכל מה שקשור לאבטחת מידע: ככל שיש יותר לאפטופים מבוססי Windows/Mac שמתחברים לרשת הארגונית דרך ה-VPN, הסיכוי לפריצה – גדול עד גדול מאוד. אף קבוצה שפורצת לא מחפשת לפרוץ ישירות את התשתית הארגונית בכך שינסו לתקוף את ה-Firewall/IPS/IDS, הכל עושים "מסביב", דרך קבלני משנה, דרך לאפטופים של עובדים שלא מבינים כלום באבטחת מידע. כל מה שצריך בסופו של יום זה פשוט לפרוץ ללאפטופ שנמצא בבית במגוון שיטות, וברגע שאותו לאפטופ יהיה מחובר דרך ה-VPN, הפורץ יוכל להריץ ברקע מגוון סקריפטים כדי לסרוק/לגנוב מידע ועוד. לא מאמינים? תכירו את חברת Visser, קבלן משנה של NASA, SpaceX, Tesla ועוד מספר חברות – דרכה פרצו לאותן חברות וגנבו מידע ומאוחר יותר פרסמו אותו.

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

האם ניתן לעשות משהו בנידון? כן.

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

  1. ממבוזר – למרוכז. אחד הדברים הראשונים שצריך לעשות, הוא, מה לעשות, לעבור לפתרון VDI. עם תשתית VDI (ואני מדבר על תשתית VDI שרצה על מכונות VM, פחות על פתרונות של VDI לאפליקציות ספציפיות) אפשר להנות ממספר יתרונות:
    1. אין צורך בדרייברים שמגיעים מיצרני לאפטופים ומחשבים. בפתרון VDI מבוסס VMware לדוגמא, יש צורך בהתקנה של ה-VMware Tools וזה כבר יתקין את הדרייברים הנחוצים ותו לא. כך נחסוך בעיות של חורי אבטחה בדרייברים.
    2. הרבה יותר קל לנהל צי של מכונות וירטואליות מבחינת הקמה/כיבוי/הגדרות וכל ה-Life Cycle בהשווה לטיפול במכונה פיזית.
    3. אין צורך להתקין ערימת אפליקציות על Image. יש כלים כמו ThinApp או Enigma Virtual Box (לא להתבלבל בין זה לבין וירטואליזציית VirtualBox – אלו 2 דברים שונים) שנותנים אפשרות להריץ אפליקציות שהמשתמש צריך ללא צורך בהתקנה מראש, כך שהמשתמש יכול לקבל Image עם המינימום שבמינימום ולינקים לדברים נוספים בהתאם להרשאות ולצורך. כך אפשר להוריד את וקטור התקיפה – אין צורך בקורא PDF ישן או אפליקציות אחרות שהמשתמש לא צריך אותם.
  2. מעבר לשימוש ב-Thin Client. כן, כל לאפטופ יכול להתחבר ל-VPN בקלות, אבל אותו לאפטופ הוא מטרה מעולה וקלה מאוד לפריצה. לעומת זאת, מכשירי Thin Client טובים (Dell, HPE, Lenovo – כולם מוכרים כאלו) הם קשים יותר לפריצה הואיל והמערכת הפעלה הלינוקסאית שבתוכם מגיעה מראש כ-Read Only, וקשה יותר לפרוץ אליה מאשר ללאפטופ או לדסקטופ. אפשר לקחת את זה צעד קדימה ופשוט להשתמש במערכות כמו Stratodesk עם דיסק און קי שנחסום אותו לכתיבה – שממנו נבצע Boot, את זה הרבה יותר קשה לפרוץ.
  3. מניעת שימוש במשאבי אחסון מקומיים. מניעת אפשרות גישה לכונן C בלאפטופ המקומי יכולה לעזור בכך שגם לפורץ לא תהיה אפשרות העלאת סקריפטים וקבצים אחרים למכונת VM שהמשתמש יתחבר אליה. אפשר תמיד להקים File Server בתשתית המקומית ולמפות לכל משתמש כמה עשרות ג'יגהבייט כדיסק רשת לאחסון דברים.

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

  • אין צורך ברכישת אחסון סופר-יקר AFA עבור VDI. אפשר להשתמש עם דיסקים מקומיים ו-vSAN. הכי חשוב שהדיסק SSD המשמש לצרכי Caching יהיה SSD טוב, כמו Optane, הואיל ורוב העבודה של VDI עולה מה-Cache וכמעט שלא מהדיסקים האחרים.
  • אין צורך לרכוש כרטיסי GPU יקרים כולל מנוי חודשי ל-nVidia, כל עוד המשתמשים מבצעים עבודות בסיסיות ולא עבודות וידאו/תלת-מימד או עבודות הכרחיות.
  • מומלץ לרכוש מעבדים עם Cache גדול (מכיוון שהמעבד, בהיעדר GPU, מרנדר את התצוגה, ה-L3 Cache שלו חשוב, כמה שיותר גדול, יותר טוב). כיום מעבדי AMD EPYC כמו 7F72, 7F52, 7F32 הם מעבדים מעולים לכך (שימו לב, אלו מעבדים שהוכרזו רק שלשום, נכון לכתיבת שורות אלו, והם יוצעו למכירה ללקוחות בתחילת החודש הקרוב).
  • מומלץ לשנות/לשדרג/להחליף לרשיון "כרוך" (Bundle) ולא לרכוש עצמאית תוספת רשיון. דברו עם נציג שיווק פתרון הוירוטואליזציה שלכם.
  • אין צורך לרכוש במאות דולרים Thin Client. אפשר את הפתרון של Stratodesk (לינק למעלה) יחד עם Raspberry Pi 3/4 ובכך לחסוך יותר מ-50% מהמחיר פר חתיכה.

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

האם שווה לרכוש 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, זו תהיה זריקת כספים לפח.

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

אחת הטכנולוגיות שתמיד נצטרך בכל 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. לא ניתן לערבב.