עריכת תכני מולטימדיה – תחנות עבודה מול עבודה מרחוק

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

לשיטה כזו יש כמובן יתרונות כמו "שקט" ללקוח הרוכש, אולם יש לה גם בעיות:

  • חוק מרפי אומר שאם ידפק הדיסק הקשיח של תחנת העבודה, שחזור דרך ה-Image לעולם לא יספיק ותמיד יאבדו קבצים חשובים ספציפית לאותו עורך או קבצים חשובים אחרים שנשמרו בתחנה אך מעולם לא גובו בגיבוי המרכזי.
  • Overpowered או Underpowered – בלא מעט מקרים שיצא לי לראות, הלקוח רכש מכונה שהיא או חזקה מדי לאותו סוג עבודות, או שהיא חלשה מדי. מה לעשות, לא כולם לוקחים בחשבון חישובי Single threaded Performance לתוכנות "סוררות" כמו פוטושופ, אפטר אפקט ועוד.
  • למכונה אין גיבוי בפתרון הגיבוי המרכזי, כך שאם מישהו החליט שעכשיו זה רעיון טוב לשדרג לדוגמא את פרמייר ופתאום פרמייר כלל לא מוכן לעבוד, גם לאחד הסרת הגירסה החדשה – יהיה לנו עובד ותחנה מושבתים, וכמה שעות של עבודה כדי להחזיר את התחנה לעבודה רגילה. כנ"ל גם במקרים שיש תקלות פתאומיות (כי מישהו לחץ על OK להתקין עדכוני Windows ש..אופס, דפקו את התחנה)

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

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

  • התאמה מדויקת של מכונה וירטואלית לאותו עובד. בתחנות עבודה יש צורך לקבוע מראש כמות ליבות/זכרון/סוג GPU. במכונה וירטואלית אפשר לעומת זאת "לחתוך" כמות מדוייקת ובכך למנוע בזבוז משאבים. מעבד עם 20 ליבות לדוגמא, הוא דבר מיותר לחלוטין לפוטושופ או לאפטר אפקט.
  • אפשרות שדרוג מיידית כשצריך יותר משאבים: רבים אולי לא מודעים לכך, אבל כשעורכים סרט/וידאו, עריכה "רגילה" (חיתוך, Transitions, דברים די בסיסיים) אינה מצריכה כמו זכרון VRAM גדולה. לעומת זאת, קולוריסטים שמשתמשים ב-דה-וינצ'י ויוצרי אפקטים (באותה תוכנה) יצטרכו כמות VRAM הרבה יותר גדולה, ואת זה אפשר לקבוע פר VM.
  • מכונות ה-VM הנ"ל יגובו כל יום במסגרת גיבוי מרכזי באולפן וכך, גם במקרה של תקלת "הצילו" יהיה אפשר לחזור יום אחורה בלי בעיה תוך דקות ספורות.
  • התכנים ישבו בתוך פתרון אחסון (אין צורך במשהו סופר יקר) שגם הוא יגובה, כך שגם כאן – שום תוכן לא הולך לאיבוד ולא מסתמכים יותר על פתרונות NAS שעולים 800 שקל ב-IVORY.
  • אפשר לעבוד מכל מקום – מהלאפטופ, בגינה בחוץ, אפשר להדגים בחדרי ישיבות את העבודה ועוד ועוד.
  • קל להוסיף משאבים לשרתים: GPU? זכרונות? מעבירים את מכונות ה-VM למכונה אחרת, מוסיפים, מפעילים, יוצאים ממצב Maintenance, ואפשר לפזר את המשאבים החדשים למי שצריך.

הפתרון שאני מדבר עליו קשור ל-VMware (למען האמת, גם פתרונות מתחרים כמו Nutanix, Xen יתנו את אותו פתרון) ללא שימוש ב-VDI. החיבור עצמו יכול להתבצע דרך RDP שקיים בתוך ה-VM או דרך פתרון צד ג' כמו Parsec או Teradici. מבחינת Latency, מנסיונות שביצעתי לאחרונה, הוא נמוך מאוד.

מה לגבי עבודה מרחוק, מהבית? ובכן, בישראל, לצערי ספקי אינטרנט אוהבים "לשחק" עם רוחבי הפס (הן מצד החוות שרתים והן מצד ה-DSL/כבלים). פרמייר/דה-וינצ'י/AVID ותוכנות אחרות בעבודה מרחוק דורשים רוחבי פס די משמעותיים (20-50 מגהביט), במיוחד עם פתרונות תקשורת כמו Teradici אם מעוניינים לקבל צבעים מדוייקים לקולוריסטים – ולפחות ממה שידוע לי, לפעמים אפשר לקבל תקשורת מהירה כזו ולפעמים .. לא (מהצד של ה-DSL). את זה בכל מקרה אני חושב לבדוק בקרוב.

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

בעקבות אירועי אבטחה וקורונה: כדאי VDI?

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

  1. לא חשוב מה הפתרון – חברות רוצות לראות שאחרים (לפחות בגודל של אותו לקוח, עדיף יותר גדול) משתמשים בפתרון
  2. שהפתרון לא יהיה Bleeding Edge
  3. הלקוח ירצה לנהל את הפתרון In House עם כמה שפחות תלות מבחוץ.

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

וזו היתה טעות רצינית. לעניות דעתי.

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

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

בעולם ה-VDI הדברים שונים. לחלוטין.

הרעיון המרכזי ב-VDI הוא שאתה יכול להתחבר אל הדסקטופ הוירטואלי עם כל סוג של ציוד, כל עוד אותו ציוד מכיל אפליקציה שיודעת "לדבר" בשפת התקשורת להתחברות ל-VDI (הדוגמא הכי נפוצה: RDP), כלומר אותו ציוד שתתחבר איתו, יכול להיות בעל מערכת הפעלה אחרת (לינוקס לדוגמא), מעבד שאינו X86 (כמו ARM), או Form Factor שאינו כולל מסך נייח (סמארטפון, טאבלט). פתרון החיבור מעביר בסופו של דבר כברירת מחדל את הקשות המקלדת, תנועות עכבר ותצוגה – דרך תקשורת מוצפנת. בברירת המחדל, אין גישה לשום ציוד מקומי כמו מדפסת, דיסקים קשיחים, חיבורי USB (שאינם מקלדת ועכבר) וכו' ובדרך כלל תהיה גם הפרדה ברמת הרשת בין גישת ה-RDP לבין התקשורת שהדסקטופ הוירטואלי עצמו משתמש – לצורך גלישה באינטרנט/אינטרה-נט לדוגמא, כך שגם אם מחשב פרוץ מתחבר, אין לו גישה ישירה אל הקבצים והתיקיות בדיסק הקשיח הוירטואלי או דרך להריץ סקריטפים מהמחשב הנייד הנגוע למכונת הדסקטופ הוירטואלית. שכבה נוספת של הגנה שקיימת בפתרונות כמו Horizon של VMware היא שימוש חד פעמי בדסקטופ וירטואלי, כך שאם המשתמש התנתק/ביצע Log out – אותו VM פשוט ימחק ויבנה מחדש, כך שגם אם מישהו הצליח לפרוץ, אותו VM "יחיה" רק בזמן סשן החיבור של המשתמש, ולאחריו – (לפי ה-Policy שנקבע) המכונה תימחק.

כל מה שתיארתי הוא די בסיסי מבחינת אבטחת מידע. אפשר מכאן והלאה לקחת את זה לרמות יותר גבוהות הכוללות בדיקת Integrity של הציוד שיתחבר (לדוגמא באנדרואיד יש SafetyNet, ב-iOS יש מספר דרכים לבדוק אם המכשיר עבור Jailbreak, וב-Windows מיקרוסופט עובדת על פתרון "שרשרת" שעובר מה-BIOS והלאה כדי לבדוק שדברים לא שונו. בלינוקס יש מספר דרכים, כאשר הדרך הפופולרית ביותר היא לחתום עם TPM על ה-Image, לבצע mount כ-read only ועוד מספר דברים על מנת למנוע tampering ב-thin client) – ובכך למנוע כמה שיותר נסיונות פריצה לרשת הפנימית של הארגון.

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

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

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

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