כמה מילים על ZFS (לשנת 2018)

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

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

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

להלן צילום מסך מ-vSphere client בגירסה 5.5, כאשר מגדירים LUN חדש ובוחרים את ה-Block Size (לחצו להגדלה):

טעות מאוד נפוצה של עובדי IT היא להגדיר את גודל הבלוקים בגודל 8 מגהבייט מבלי להתייחס לתוכן שישב באותו Datastore. אם לדוגמא ישבו בו קבצים רבים קטנים (בגדלים של מאות קילובייט או מגהבייטים בודדים) אז מדובר בכך שהגישה לקבצים תהיה יותר איטית בהשוואה לדוגמא בבחירה בגודל של 1 או 2 מגהבייט והאיטיות תורגש במיוחד כה-Datastore גדול מאוד בעת כתיבה וכמובן שמדובר בבזבוז מקום.

במקרה לעיל, לא חשוב איזה Storage יש לך, מהרגע שהגדרת iSCSI LUN בסטורג', לסטורג' אין מושג ירוק מה אתה הולך לעשות איתו. מבחינתו זה Block ולך תשבור את הראש מה לעשות ואיך להגדיר ואיך לעשות אופטימיזציה לו ב-Initiator שלך.

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

אבל מה קורה אם אנחנו רוצים לבנות פתרון סטורג' משלנו ואנחנו מעוניינים לעשות לו אופטימיזציה ולא להיות "שבויים" באיזה פתרון שלא מאפשר לנו להגדיר דברים לעומק? אם אנחנו בונים עם לינוקס מערכת כזו עם File System כמו XFS או EXT4, מאותו הרגע שחילקנו את הדיסק עם או בלי LVM, ואנחנו מפרמטים את כל מערך ה-RAID בזמן ההתקנה, אז כבר אי אפשר לשנות את גודל הבלוקים. ב-XFS לדוגמא, ברירת המחדל היא להגדיר בלוקים בגודל 4K כל בלוק, אבל אם אנחנו הולכים לאחסן רק קבצים שרובם בגודל מס' ג'יגהבייטים, אנחנו נפסיד מהירות.

לעומת זאת ב-ZFS, גם אחרי ששייכנו את כל הדיסקים ל-Pool מסויים, אנחנו תמיד יכולים להגדיר את גודל הבלוקים (ב-ZFS זה נקרא record size) גם אחרי יצירת ה-Pool ויצירת Dataset (חשוב כמובן לשים לב שאם יצרנו Dataset ואנחנו מגדירים לו record size חדש, רק הקבצים החדשים יקבלו את גודל ה-record size החדש, לא הקבצים הישנים) כפי שניתן לראות לדוגמא כאן. (אגב, זה דבר שמאוד עוזר עם MySQL לדוגמא, אתם מוזמנים להציץ כאן)

נקודה נוספת וחשובה היא כמובן הדיסקים. ישנם עדיין מקרים רבים שיש שרתים פיזיים שמריצים אפליקציות מסויימות על דיסקים מקומיים עם כרטיס RAID הכולל זכרון Cache וסוללה, אך עם הדיסקים החדשים שיש כיום שמחירם יורד כל הזמן, יהיו לא מעט חברות שישמחו לקנות דיסקים בגודל 6,8,10,12 או אפילו 14 טרה בייט ויחברו אותם לבקר ה-RAID וכך הם יקבלו כמות אחסון מכובדת, אך יש בעיה מרכזית אחת: כל דיסק מעל גודל 4 או 6 טרהבייט שנדפק ומוחלף, יאיט אוטומטית את הביצועים של כל מערך הדיסקים לזמן רב (זה יכול לקחת ימים או במקרים של דיסקים גדולים כמו 10,12,14 טרהבייט – אפילו שבועות!) מהסיבה הפשוטה שבקר דיסקים הוא דבר די טיפש, הוא יודע לקרוא בלוקים, אבל הוא לא יודע מה יש בבלוקים, כך שבקר ה-RAID מבצע rebuild, הוא יעתיק את כל הבלוקים, גם אם 60% מהדיסק הוא בכלל ריק! לעומת זאת ב-ZFS אם נדפק דיסק והחלפנו אותו, מערכת ה-ZFS תשחזר (מה שנקרא: resilver) רק את הקטעים שלא קיימים בדיסק החדש, כך שה-rebuild יהיה הרבה יותר קצר והמערכת תשוב לאיתנה במהירות הרבה יותר גבוהה מאשר בתהליך rebuild של כרטיס RAID.

חסרונות נוסף שקיימים ל-XFS ול-EXT4 הם לדוגמא:

  • אין בדיקת קבצים מתמשכת. ב-ZFS לכל קובץ יש checksum כך ש-ZFS יודע בדיוק אם מה שהוא קרא תקין או לא ואם לא הוא יטפל בבעיה אוטומטית בכך שהוא יעביר את הנתונים למקום אחר (בערך כמו שבקר SSD טוב עושה) ול-ZFS ישנו גם תהליך scrubbing שעובר אחת לכמה ימים על כל הקבצים בדיסקים לבדוק זאת ולטפל בתקלות באופן אוטומטי. ב-XFS וב-EXT4 יש לך Journal שיכול לעזור בקריסת המכונה, אך זהו פתרון שאינו מספק על מנת לשמור על הנתונים.
  • ב-EXT4 וב-XFS אין מנגנונים לניצול משאבי המכונה מבחינת זכרון. כן, ללינוקס יש שימוש מתוחכם בזכרון החופשי לשם Cache מסוגים שונים, אבל ב-ZFS יש את ARC שלוקח כברירת מחדל מחצית מהזכרון של המערכת להאצת ביצועי דיסק בכך שהוא משתמש באותו זכרון שהוא "גזר" בהתחלה, וכידוע – זכרון RAM הוא הדבר הכי מהיר שיש, יותר מכל SSD שקיים בשוק.
  • שימוש מושכל ב-SSD וב-NVME: עם מערכת כמו bcache או fastcache (לאלו שאוהבים לחיות על הקצה) יכול להיות פתרון די טוב על מנת להאיץ ביצועים של דיסקים מכניים, אך ב-ZFS יש לך 3 מנגנונים שמטפלים בכך:
    • מנגנון ה-ARC (שמשתמש כברירת במחצית הזכרון של המכונה לשם CACHE מהיר)
    • מנגנון ה-ZIL (להאצת ביצועים וטרנזאקציות של קבצים קטנים ורישומי הפניות להיכן קבצים נכתבים, אפשר לקרוא על כך כאן)
    • מנגנון ה-L2ARC – כאן בד"כ יהיה SSD מהיר ששומר עותקים של קבצים שניגשים אליהם בתכיפות גבוהה.
  • מערכת ZDB – לכל File system יש כלים משלו (tune2fs ל-EXT3/EXT4 לדוגמא או ערימת הכלים הזו ל-XFS), אבל ZDB לוקח את זה כמה צעדים קדימה – לבדיקה האם יש Cache אופטימלי, לבדיקה של ביצועים פר דיסק, בדיקות והגדרות ל-B-TREE (כן, ZFS שומר את הקבצים ב-B-Tree) ועוד המון דברים. ZDB הוא ה"אולר השוויצרי" ל-ZFS ועבודה איתו יכולה לתת ביצועים שעוקפים מרחוק כל File System לינוקסי.

יחד עם זאת ל-ZFS יש עדיין חסרונות (שיטופלו בשנה הקרובה):

  • הוספת דיסקים: לא, אתה לא יכול להוסיף עוד דיסק אחד אלא 2 ומעלה. גם החלפת דיסקים קיימים בדיסקים יותר גדולים היא לא בדיוק פיקניק כרגע (אבל זה אפשרי). במהלך 2019 יתווסף קוד להוספה דיסקים – אפילו דיסק בודד כמעט מבלי שנצטרך להתמודד עם איטיות של פריסת DATA מחדש (יועתקו מספר בלוקים בודדים וזהו).
  • עבודה עם SSD – אחד החלקים היותר נחמדים ב-SSD זו פקודת trimfs שאומרת ל-SSD לבצע פקודת TRIM ב-SSD. ב-ZFS יש תמיכה ל-Trim אך היא אינה אוטומטית בגירסת ZFS ללינוקס. יש Pull request שיכול לעבוד ברוב המקרים בגירסה הנוכחית היציבה של ZFS ללינוקס, ובגירסת ה-Master זה עובד בצורה טובה. אני מאמין שבחודשים הקרובים זה יוכנס פנימה.

לסיכום: אפשר להקים שרת ZFS תוך דקות ספורות על מכונה חדשה. יוצרים pool עם תצורת RAIDZ רצויה, מחלקים דיסק SSD ל-2 פרטישנים (אחד log ואחד cache, ככלל עדיף 2 SSD שיעבדו כ-Mirror), מצמידים אותם ל-pool ויאללה – יש מערכת ZFS עובדת. העניין הוא שאם אתה רוצה ביצועים מעולים, תצטרך להשקיע זמן בהגדרות דברים לפי מה שרוצים להריץ ומה ה-ZFS צריך לשרת (ואני ממליץ את הספר הזה ל-ZFS על לינוקס, או את הספרון הזה). האם ZFS הוא פתרון חלופי לסטורג' סגור – במקרים מסויימים כן ובמקרים מסויימים לא (תלוי בדרישות ובצרכים), אבל הוא מאוד מתאים אם חברה מחליטה להקים סטורג' קטן והיא מוכנה להשקיע את שעות העבודה כדי לבצע אופטימיזציה וזה לוקח זמן (לפי הידע של מי שמבצע זאת), זה לא משהו שנעשה בחצי יום, וצריך לעיתים להקים מערכת שלמה כדי להגדיר לבדוק את הביצועים.

קצת על Windows ואוטומציה

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

בלינוקס, קיימים מספר פתרונות האוטומציה מבוססי קוד פתוח כמו:

  • Chef
  • Puppet
  • Ansible
  • SALT

לכל אחד יתרונות וחסרונות, אך מבחינת פלח שוק, Ansible מוביל בפער ענק על פני האחרים כולל פתרונות מסחריים סגורים, הנה גרף שיציג זאת (מקור: Datanyze) (לחצו להגדלה):

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

אחד היתרונות הגדולים בגירסה האחרונה (2.5) של Ansible היא פתרון מלא ל-Windows. צריכים לעדכן שרתים? צריכים להוסיף אתר ל-IIS? צריכים להעביר קבצים? מעתה כל מה שצריך זה ליצור קבצי Playbooks פשוטים (לא, לא צריך לדעת לתכנת בשביל לכתוב Playbooks) ופשוט להריץ אותם. Ansible ירוץ במקביל לכל המכונות שהגדרתם ויבצע את העבודה. בתוך Ansible יש חלקים שנקראים מודולים שהם בעצם הקוד שירוץ על השרתים (דרך WinRM) והם כתובים ב-Python ולכן חלוקת העבודה יכולה להיות שמי שמבין בפייתון יכתוב מודולים והשאר יכתבו Playbooks בהתאם לצורך. אגב, יש תמיכה במערכות הפעלה אחרות, וירטואליזציה וגם חומרה.

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

תכירו את Redfish

אני רוצה להכיר לכם את Redfish. בעקרון, Redfish זה API סטנדרטי לנהל כמעט כל דבר בתחום ה-IT, החל מ-SDDC (כלומר Software Defined Data Center) וכלה בשרתים, שרותים, מתגים ובקיצור כמעט כל דבר שניתן להתחבר אליו. Redfish משתמש בסטנדרטים קיימים (REST API, web services ופלט כ-JSON) על מנת לעשות את החיים הרבה יותר קלים למחלקת ה-IT בחברה.

אחד הדברים שצריך לדעת על Redfish שזה משהו ענק שמשתתפים בו כל המי ומי בתחומי הברזלים לדוגמא. לפוסט הזה, אני מעוניין להתרכז בתחום ה-OOB (שזה אומר כל ה-iDRAC/IMM/ILO/IMC למיניהם).

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

ועכשיו אשאל שאלה: כמה זמן יקח מהרגע שהשרתים יורדים מהמשאית עד שהם פועלים עם ה-OS/וירטואליזציה שבחרתם? אני מאמין שזה לא עניין של שעות, זה יהיה מינימום עניין של ימים עד שבועות. אחרי הכל, במקרים רבים יש צורך להכניס כרטיסים שונים לשרת, אולי לשנות את תצורת הזכרון, להתקין OS, להגדיר את ה-UEFI/BIOS, לחבר למתגים, להגדיר כתובות IP, VLAN וכו', , להגדיר RAID, לפרמט דיסקים, ועוד כמה וכמה דברים.

כשמדובר על כמות של 1-3 שרתים, זה לא כזה ביג דיל, אבל אם מדובר על פרויקט חדש והגיעו 20 שרתים.. אתם יכולים לדמיין את הכאב ראש.

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

איך? עם ה-API של Redfish. כאן לדוגמא תוכלו למצוא עבור שרתי Dell סקריפטים הן ב-Python או ב-PowerShell על מנת להשתמש עם ה-Redfish בחיבור ל-iDRAC לעשות כמעט הכל, החל מהגדרת UEFI/BIOS, שדרוגי קושחה, הגדרות iDRAC, הגדרות RAID ושלל ירקות נוספים.

הכל טוב, רק שיש בעיה אחת קטנה: יש לי 20 שרתים להקים, להתחיל לשנות כל פעם סקריפטים? לכתוב סקריפט wrapper שמריץ את הסקריפטים שניתנים באותו אתר? זה חתיכת כאב ראש.

נכון. בשביל זה יש דרך אחרת, אוטומציה מקבילית, ואני מדבר כמובן על Ansible.

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

לסיכום: Redfish נותן סוף סוף דרך "לדבר" בצורה מאובטחת עם הציודים שלכם דרך סקריפטים שונים שניתנים לשימוש באוטומציה. אפשר גם להגדיר כך הגדרות שונות וגם לקרוא לדוגמא מה-OOB את התקלות האחרונות מה-Log. אם נחכים להשתמש גם ב-PXE (אני דווקא ממליץ על IPXE במקום PXE, הוא הרבה יותר מהיר כי הוא עובד ב-HTTP ולא TFTP כך שניתן לעבוד מהר ובמקביל) נוכל גם להתקין בצורה אוטומטית תוך שימוש בכלים כמו kickstart או preseed להתקין מערכות הפעלה שונות בתצורה מינימלית ואת השאר לעשות עם Ansible (כן, כולל Windows, אסביר בפוסט הבא) ובכך לחתוך את הזמן להקמת השרתים בעשרות אחוזים וגם התחזוקה תהיה הרבה יותר מהירה ואוטומטית.

להלן וידאו הדגמה של Dell מכנס Red Hat Summit האחרון שנערך לפני ימים ספורים:

על לינוקס, VMWare וטעות הקשורה לחיישנים

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

עד לגירסה 5 (גם 5.5) ב-VMware השתמשו בד"כ בדרייברים מבוססי לינוקס כדי להפעיל ציודים, בין אם מדובר בציוד זול או בבקרים יקרים מאוד. בגירסה 6 החליטו ב-VMWare לעבור לדרייברים שהם כותבים (או שהיצרן כותב) עם שינויים מהותיים בקוד כך שלא כל כך קל לקחת דרייבר של לינוקס ולזרוק אותו לגירסה 6 (ולפי השמועות, זה הולך להשתנות שוב בגירסה 7, אבל בינתיים אלו רק שמועות).

אם יש לכם שרתים שמריצים VMWare, אחד הדברים החשובים שתרצו לדעת הוא מה מצב החיישנים במערכת. מה הטמפרטורה של המעבד, דיסקים, ספק כח, חום פנימי בשרת, מצב תקלות זכרון ודברים כאלו ואכן, עד גירסה 6 של vCenter קיבלתם את המידע כולו בתצורת עץ. המידע הזה חשוב (וגם ניתן לקריאה על ידי תוכנת הניטור שלכם דרך SNMP). עד גירסה 6 ה-vCenter עשה משהו פשוט מאוד: הוא פנה לכל שרת ESXi שרשום ב-vCenter וקרא ממנו את הערכים. איך ESXi קורא את הערכים? בעזרת חבילה שכלולה בכל הפצת לינוקס שנקראת lm-sesors והיא קיימת בכל התקנה של שרת ESXi. החבילה הזו מעודכנת כל הזמן וכל עוד הקרנל בלינוקס מעודכן, תוכל לקרוא את כל החיישנים במערכת, וזה רץ על כל מערכת, בין אם מדובר במחשב נייד, בדסקטופ, תחנת עבודה או שרת מפלצתי.

בגירסה 6.5 ל-VMware "קפץ הפיוז" והם החליטו שה-vCenter (בין בגירסת Windows או VCSA) לא יקרא יותר את החיישנים מה-ESXi (שכבר יש לו את הנתונים שמתעדכנים כל 90 שניות), אלא יפנה אל ה-IPMI. למי שלא מכיר – בכל לוח אם של שרת יש רכיבים שנותנים ניהול מרחוק, אתם אולי מכירים את זה בשמות כמו ILO, IMM, iDRAC – וכולם בעצם מממשים פחות או יותר את סטנדרט IPMI לשליטה מרחוק על המכונה. הבעיה, כמו תמיד, שיש לא מעט מקרים שהמימושים הם לא ממש משהו או שהיצרן החליט להתעלם מחלק מסטנדרט ה-IPMI. אחרי הכל, למשתמש יש גישת CLI או גישת Web לניהול מרחוק, אז אפשר להחביא את המימוש העקום מתחת לשטיח.

וזה משהו שב-VMWare לא ממש התעמקו כנראה. מבחינתם, החל מגירסה 6.5, יש שרות שנקרא wbem ויש API לפונקציה שנקראת HostConfigManager.healthStatusSystem והיצרן צריך לכלול (או לשחרר) VIB שכולל את הגישה לניהול מרחוק של השרת, כך שבתאוריה המנהל יצטרך רק להכניס פרטי התחברות ל-IMM/IDRAC/ILO והמערכת תתחיל לקרוא את החיישנים ישירות מהניהול הרחוק.

במציאות .. זה לא ממש עובד. כך לדוגמא אחד השרתים שלי (גם אחרי התקנת ה-VIB) מראה תצוגה של החיישנים בכל שרת (לחצו להגדלה):

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

אז מה קורה פה? מי שיקרא את המאמר הזה יבין שגם אם הוא יתאמץ וינדנד ליצרן לקבל VIB מתאים, יגלה שזה לא יעזור. יש באג, ועד כה (יצא כבר 6.7) זה לא תוקן. המסקנה: רוצה לנטר את המכונות ושדרגת ל-vCenter 6.5 ומעלה? תתחיל לנטר את המכונות עצמם. איך? קרא כאן.

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

על בעיה X ופתרון Y

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

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

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

  • מה הפונקציונאליות שהוא מחפש
  • מה הפונקציונאליות שמאוד חשובה לו, ומה הפונקציונאליות שבשבילו זה יהיה "נחמד" אם קיים אך אותה פונקציונאליות אינה קריטית.
  • האם הוא מחפש פתרון Scale Up או Scale Out
  • האם הוא מחפש פתרון שישולב כ-Hyper Converge או שהוא מחפש פתרון של ברזלים נפרדים
  • ויש עוד לא מעט שאלות…

ההבדלים ביני (וכמובן אחרים), כיועץ ואינטגרטור בלתי תלוי (כלומר אחד שהוא אינו בעצם Reseller של ברזלים ממותגים) הם דברים חשובים כגון:

  • אינטגריטי – אם מישהו יבוא אליי ויבקש לדוגמא פתרון סטורג' Scale Out והדבר הכי חשוב לו זה iSCSI לדוגמא, אז אני אומר לו בפשטות שכרגע אין פתרון Scale Out בקוד פתוח (גם כמוצר מסחרי) שיש לו פתרון iSCSI ל-Scale Out בצורה טובה והוא יצטרך פתרון קנייני.
  • על מה הפתרון אמור לענות? לקוח רוצה X על מנת לפתור את בעיית Y. נעזוב לרגע את X, ונשמע מהלקוח מהו אותו Y. אין ספק, דרישותיו של הלקוח הן חשובות, אולם ברגע שמספרים לי מהו אותו Y, אז ניתן להעלות מספר פתרונות שיכולים לענות על Y וגם להתחשב בצרכי הלקוח.
    לדוגמא: ללקוח יש 20 מכונות VM שמשמשות לפיתוח והלקוח רוצה פתרון סטורג' עבורם Scale Up. במקרה כזה אני יכול להציע לדוגמא פתרונות מבוססים ZFS, בין אם כקוד פתוח נטו או מוצרים מסחריים ובהצעה שאגיש לו יוסבר מדוע הפתרון הזה טוב ויוצעו ללקוח מספר פתרונות מבוססים ZFS, כך שבסופו של דבר ה-Y הם אותם 20 מכונות VM וה-X יהיה פתרון מבוסס ZFS.

וכאן בעצם מגיעה השאלה המרכזית שלי…

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

שלח לחמך על פני המים

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

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

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

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

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

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

תודה,
חץ בן חמו
[email protected]

על עלויות תמיכה של מוצרי קוד פתוח

עולם הקוד פתוח כיום נותן מגוון מוצרים הקשורים לתשתיות שונות, Software Defined, וירטואליזציה ועוד, ובמקרים רבים חברות רבות מעוניינות באותם מוצרי פרויקטים בקוד פתוח, ומדוע לא? לבצע Download, להתקין ולעבוד עם זה, בלי עלויות של רשיונות פר שנה, פר שרת, פר חיבור ופר השד-יודע-מה…

להלן מס' דוגמאות של מוצרים:

  • GlusterFS
  • Ceph
  • oVirt
  • OpenStack
  • ManageIQ
  • Kubernetes
  • OpenShift Origin

2 המוצרים הראשונים הם Software Defined Storage, השלישי והרביעי הם מוצרי וירטואליזציה, והמוצר החמישי הוא מוצר לניהול מקיף של תשתיות וירטואליזציה ועוד – מקומית ובענן ו-2 האחרונים הם לניהול קונטיינרים לכל המוצרים הללו נלווית עלות של 0 שקלים כלומר אתה יכול להיכנס לאתרים, להוריד ולהשתמש.

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

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

לכן, בדרך כלל כשמעוניינים באחד המוצרים הנ"ל לדוגמא, יש לקחת בחשבון שאם אין בחברה ידע מעמיק על המוצר או על מערכת ההפעלה (כמו במקרים שיש רק Windows ב-90% מהתשתית ואין שם אף אחד שמבין לעומק בלינוקס) – יהיה צורך ברכישת בנק שעות תמיכה שנתי על המוצר או על הפתרון ובד"כ מדובר על כמה עשרות אלפי שקלים (בין 15K ל-40K, תלוי במוצר, תלוי אם מדובר רק בתחזוקה או בהקמה, תלוי בכמות שעות ותלוי ממי רוכשים והאם יש באמת ידע לעסק שמציע פתרון או שמדובר בעסק שחותך מחירים ולוקח מישהו מהודו כך שרוב הרווח עובר אליו ולא להודי) כך שאם אין בחברה ידע – המוצר כבר לא ממש "חינם".

מצד שני, לאלו שכן רוצים לרכוש את המוצר המסחרי ומוכנים לשלם את המחיר, מומלץ לחלק את העבודה ל-2 ואת ההקמה/הטמעה להוציא למישהו חיצוני (ולא ליצרן, כמו במקרים של רד-האט, אלא אם בא לכם לשלם כמה מאות דולרים לשעה!) ואת התמיכה אתם תקבלו במסגרת רכישת התוכנה.

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

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

ההבדל בין קוד פתוח למוצר מסחרי מבוסס קוד פתוח

לפני מספר חודשים פרסמתי בכמה מקומות סקירה מקוצרת על פרויקט של Red Hat שנקרא oVirt. הפרויקט הזה הוא בעצם ה"תשובה" של Red Hat לכל אלו שמחפשים מוצר וירטואליזציה כ-Hyper Converge. המערכת כוללת בפנים פתרון סטורג', רשת וכמובן Compute ויש בה עוד חלקים שלמוצרים מתחרים יש תשובות חלקיות.

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

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

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

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

הנקודה השניה החשובה היא כמאמר הפתגם "יותר משהעגל רוצה לינוק, הפרה רוצה להניק". כל יצרני השרתים מוכרים את המוצרים המסחריים מבוססי הקוד הפתוח כולל תמיכה מלאה 24/7, כלומר אם מחר תרצה לרכוש שרתים מ-HPE או DELL או LENOVO ותרצה לרכוש פתרון אחסון SDS, פתרון קונטיינרים כמו OpenShift המסחרי, פתרון סטורג' Scale Out כמו Ceph או Gluster או מוצר ענק כמו SAP HANA – הם ימכרו ויתמכו בך כולל SLA מלא ואז אינך תלוי באם חץ בן חמו זמין או אם יש מישהו אחר שיתן לך תמיכה. אתה מקבל תמיכה מלאה בדיוק כמו שאתה מקבל תמיכה לברזלים שלך. ליצרן יש תמיכת "גב אל גב" עם יצרן התוכנה. דוגמא פשוטה לחובבי מיקרוסופט ו-Azure – אם יש לך הפצת לינוקס מותקנת על VM ב-Azure ויש לך בעיה, אתה פונה לתמיכת Azure והם מנסים לפתור. לא מצליחים? יש להם קו ישיר ליצרן ההפצה שיעזור להם ולך לפתור את הבעיה.

לסיכום: כמו שאתה קונה מתגי תקשורת של Cisco, כמו שאתה קונה מערכת מורכבת כמו JIRA, כך גם עם מוצרים מסחריים מבוססי קוד פתוח. החברה שמוכרת לך את זה, בין אם יצרן התוכנה או יצרן הברזלים – אתה מקבל שרות מלא הכולל התקנה, הטמעה, תמיכה וכו' לפי SLA שנקבע בין הצדדים. זה ש-HP מעדיפים למכור סטורג' 3PAR שלהם או DELL מוכרים סטורג' כמו UNITY, לא אומר שזה הדבר היחיד שהם מוכרים. יש להם עוד מוצרים, אתה פשוט צריך לבקש את זה במסגרת ההזמנה ואין שום הבדל בתמיכה/התקנה/הטמעה בין אם קנית לדוגמא סטורג' קנייני או פתרון סטורג' SDS, בין אם קנית פתרון מבוסס קוד פתוח או פתרון סגור לחלוטין. יש כמובן את הפרויקטים בקוד פתוח שהם אינם מוצר מסחרי ואתה חוסך את הקניה איתם, אבל שם המסלול הוא שונה והוא יותר קשור בחברות ועצמאים פה בארץ שיכולים לתת לך שרות על כך, ולכן כדאי להבדיל בין הדברים.

קצת על עולם ה-NVMEoF וסטורג' חזקים

אם נסתכל היום בכל חברה בינונית וגדולה שיש לה כמה עשרות שרתים פיזיים ומעלה – בד"כ נמצא סטורג' קנייני כלשהו, בין אם זה NetApp, HPE, Dell/EMC, IBM. Hitachi ואחרים. הסיבה לכך היא די פשוטה: הפתרונות הללו נותנים ביצועים גבוהים וגם נותנים פתרונות לצרכים השונים, החל ב-LUN ש"מפורמט" ל-iSCSI (כשצריך),iSCSI, NFS, CIFS, Snapshots ועוד ועוד. הפתרונות הללו במקרים רבים היו יותר טובים מפתרונות Software defined storage בעבר בגלל מה שהיה מבחינת חומרה בתוך הסטורג' הקנייני, בין אם זה שימוש ב-NVRAM, בכרטיסי האצה, ב-SSD (שלא חושבו כחלק מכמות המקום הפנויה בסטורג', מה שנקרא גם Vault) – ובקיצור, שורת טכנולוגיות שמובנים בתוך הסטורג' שנותנים ביצועים נאותים שמתאימים לאותן חברות.

בשנים האחרונות ישנם פתרונות אחרים המבוססים על Software Defined Storage (בקיצור: SDS) המוטמעים כחלק מפתרון וירטואליזציה, פתרונות כמו VSAN של VMware, או Nutanix או Simplivity ואחרים. בפתרונות כאלו בכל שרת יש דיסקים שמשמשים לאותן מכונות VM שרצים בשרת והדיסקים גם משמשים לאחסון ושרידות של VM אחרים, כך שאם שרת פיזי נופל, ה-VM יופעל מחדש במכונה פיזית אחרת (מה שנקרא: HA) או שה-VM ממשיך לפעול מהעתק רצוף שרץ על מכונה אחרת (מה שנקרא Fault Tolerance או FT בקיצור). במקרים כמו של VSAN ניתן כמובן להגדיל את האחסון בכך שמוסיפים עוד שלישיית דיסקים (2 איטיים ואחד SSD מהיר) בכל פעם שמגדילים את האחסון, אם כי ההמלצה "בין השורות" היא שעדיף להוסיף שרת פיזי נוסף ולפזר את המכונות VM ביניהם כדי לקבל יותר IOPS. השיטה הזו טובה (וב-VMware ישראל נותנים לדוגמא את ערוץ 10 שעבר לעבוד כך), אך החסרון המשמעותי של השיטה הזו היא שזה לא תמיד עובד טוב. כך לדוגמא, אם מכונות VM צריכים SSD שהוא Mixed Intense, ה-VSAN לא תמיד ידע להעביר אותו למכונה אחרת שגם שם יש SSD שהוא Mixed Intense ובכך אנחנו עלולים לקבל ביצועים מופחתים, רק בגלל שה-DRS החליט להעביר את ה-VM בגלל עומסים (אני מכיר את זה אישית מה-LAB שלי).

כיום פתרונות ה-SDS תופסים יותר ויותר מקום של כבוד (לפחות בחו"ל), כאשר הלקוח בעצם צריך לרכוש את התוכנת SDS והוא מריץ את התוכנה על הברזלים שיש לו, כאשר אותם ברזלים הם שרתים מהיצרנים המובילים (Dell, Lenovo, HPE, SuperMicro, Cisco) ואותו הלקוח מקבל בעצם בחבילה את כל הפונקציות שהוא רגיל לקבל מיצרן סטורג' קנייני, כולל כל החיבורים שהוא צריך (FC, FCOE, Ethernet, Infiniband) ויש ל-SDS תמיכה והתממשקות לכל הפלטפורמות המובילות וגם לתוכנות גיבוי המובילות.

גם בפתרונות SDS וגם בפתרונות קנייניים, בד"כ הפתרונות מבוססים על דיסקים SSD בחיבורי SAS/SAS2/SATA או על דיסקים מכניים או שילוב שלהם (כאשר פתרון האחסון יודע להעביר נתונים שאינם נקראים תדיר לדיסקים המכניים ונתונים שנקראים/נכתבים תדיר ל-SSD, או במקרים אחרים שהמערכת מאפשרת ללקוח לבנות LUN או Share מ-SSD או מכני לפי צרכי הלקוח). אלו פתרונות טובים כאשר יש לנו עשרות שרתים עד מאות בודדות של שרתים פיזיים, כשהדרישה מבחינת ביצועי דיסק/סטורג' אינה כה גבוהה (כלומר שאפשר להסתדר עם IOPS של 5 ספרות נניח).

אבל מה קורה אם יש לנו מאות (ואולי יותר) של שרתים ואנחנו רוצים ביצועי דיסק מאוד גבוהים, בדיוק כמו ביצועים של דיסקים מקומיים? נסו לחשוב על בנקים ומוסדות פיננסיים גדולים שבשבילם כל מילישניה זה רווח או הפסד כספי? כאן נצטרך דברים הרבה יותר חזקים. יש כמובן פתרונות AFA (שזה All Flash Array) אבל הפתרונות האלו ו-Scale Out הם לצערי .. לא משהו.

בואו ננסה לדמיין משהו. דמיינו שצריך להקים פתרון מבוסס Flash בגודל 1 פטהבייט. סביר להניח שאתם מדמיינים ארון מלא בדיסקים, עם סוויצ' רציני מלמעלה (TOR או Top Of Rack).

מהדמיון נעבור למציאות, הביטו בתמונה הבאה (לחצו להגדלה):

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

בשרת ה-1U יש 36 מקומות למלבנים הללו, כך שבשרת 1U צנוע ניתן להכניס 576 טרהבייט, ובשרת 2U – כ-1152 טרהבייט, כלומר יותר מפטהבייט על שרת פיזי אחד!. הפתרון הזה שאתם רואים לעיל הוא הפתרון של סמסונג, לאינטל יש פתרון דומה (אם כי הקוביות קצת יותר מוארכות והם נקראים "סרגלים" – בתמונה משמאל ואינטל קוראת להם NGSFF). בפתרונות הללו אין שום בקרי RAID כלשהם (הכל מחובר דרך PCIe ומתגי PLX ישירות למעבד, כך שהביצועים מאוד גבוהים, בסביבות ה-3-4 ג'יגהבייט קריאה וכמעט 2 ג'יגהבייט כתיבה לשניה פר מקל).

וכאן אנחנו מתחילים להכיר את פתרון עם השם המפוצץ NVMEoF (ר"ת של NVME over Fiber, אם כי לא מדובר על Fiber Channel רגיל).

בוא נחשוב על חיבורים לשרת כזה. חיבור של 1 ג'יגהביט לא בא בחשבון וחיבור 10 ג'יגהביט "יחנק" עוד בפעילות של מקל יחיד! אנחנו צריכים פעילות של מס' מקלות NVME כדי לתת ביצועים סופר חזקים וסופר מהירים כדי שהמכונות שיחוברו לשרת כזה ירגישו כאילו הדיסק שהם מקבלים – הוא ממש מקומי, כלומר אנחנו צריכים חיבורים של 25,50,56 או 100 ג'יגהביט, כלומר או Ethernet או Infiniband.

מבחינת תעבורה מהירה, אנחנו צריכים לוותר על TCP/IP במהלך העברה של הנתונים (אך לא בזמן ה-Handshake הראשוני, בשביל זה עדיין אנחנו צריכים IPv4 או IPv6 ב-TCP/IP) ואז אנחנו עוברים לשימוש בטכנולוגיה שרבים מאיתנו מכירים… RDMA, זוכרים? היתרון הגדול עם RDMA הוא שהמעבד באותו שרת "מקור" לא צריך כמעט לעשות כלום, ומכיוון שאנחנו מעבירים בעצם "בלוקים", אז אנחנו מוותרים בדרך גם על שכבת ה-File System. מישהו שהסברתי לו על הנושא אמר לי "אה, זה בעצם מעין iSCSI על סטרואידים".. אפשר לאמר 🙂

ל-NVMEoF יש מספר יתרונות גדולים:

  • אפשר להכניס איזה גדלים שרוצים וכמה שרוצים. אפשר להתחיל ב-2 מלבנים של 8 טרה ואחר כך להוסיף עוד 4 של 16 ואחר כך עוד 4 של 8 טרהבייט. למערכת זה לא ישנה כלום. מבחינתה – יש עוד מקום לאחסן.
  • אין צורך לבנות מערכי RAID (כי .. אין RAID). במערכת שתרוץ על השרת נוכל לקבוע איך הנתונים ישמרו, מה הדחיסה שתהיה והיכן ישמר עותק נוסף של הנתונים.
  • ההשקעה למוסדות גדולים אינה כה גבוהה (לא ניכנס לחישובי ה-ROI, אפשר לכתוב ספר שלם על זה!). כן, יהיה צורך בהחלפת מתגים וכרטיסים בשרתים, והמוסדות יצטרכו להחליט עם מה הם עובדים – Infiniband או Ethernet (כבלי CAT 7 עם תיוג Class F יכולים להעביר 100 ג'יגה עד 15 מטר אורך, CAT 8 יתן עד 100 מטר 100 ג'יגהביט אך הוא עדיין לא אושר רשמית. כאן יש עוד פרטים לגבי 100 ג'יגה)
  • ישנן תוכנות שונות שנותנות את שרות ה-NVMEoF, חלקן כחול לבן כמו Kaminario, E8, Pure וכו'. כמו שכתבתי לעיל, אני ממליץ לרכוש תוכנה ולא פתרון חומרתי סגור מכיוון שעם תוכנה אפשר לעבור לפתרונות מתקדמים יותר בעתיד תוך שימור ההשקעה בברזלים, לא צריך לרכוש פתרון חומרתי סגור אחר ולהיפתר מהקודם.
  • מבחינת תמיכת חומרה – גם כאן, החבר'ה מיוקנעם ישמחו לסייע לכם (Mellanox), סמסונג, אינטל, Chelsio, Qlogic ואחרים, וכל יצרני המתגים המוכרים כבר תומכים בפתרונות NVMEoF.
  • מה עם פתרונות קוד פתוח? גירסת RHEL 8 שתצא (כנראה, כנראה..) עד סוף השנה תתן פתרון NVMEoF עד סוף השנה, וכל מערכות ההפעלה והוירטואליזציה יתמכו בפתרון.
  • כל הפתרונות (שאני מכיר) תומכים ב-Scale Out.

לסיכום: NVMEoF הוא בהחלט פתרון מעולה לעתיד. לפני שבועיים הרצתי אותו בבית (כפתרון וירטואלי, אין לי ממש כספים לדיסקים NVME ל-Enterprise) על Fedora 27. ובהחלט ה-Latency נמוך מאוד והביצועים מרשימים. אני תיארתי את הפתרון לעסקים גדולים כמו בנקים וכו' אולם כל חברה בינונית ומעלה יכולה להתחיל ב-PoC על מנת לבדוק בהמשך מימוש פרודקשן של פתרון כזה. לא צריך השקעה של מאות אלפי שקלים – מספיק 2-4 דיסקים NVME, כמה כרטיסי רשת במהירות של 25 ג'יגה ומעלה (ללא סוויצ') ושרת שיכול לקבל דיסקים כאלו, מערכת לינוקס עדכנית ואפשר לנסות ולשחק עם זה.
אפשר לאמר שאנחנו "חוזרים לאחור" הן מבחינת שיטת העברת הנתונים (RDMA) והן מבחינת מקום אחסון הנתונים (מחוץ לשרתי הוירטואליזציה/קונטיינרים) ובכך יש מעין "מלחמה" בין השיטות, רק שהפעם השיטה ה"ישנה" קיבלה זריקת חיזוק רצינית בכך ש-NVMEoF נותנת לנו ביצועים הרבה יותר גבוהים מבחינת דיסק בהשוואה לכל פתרון Hyper Converge.

למעוניינים, להלן וידאו של רד-האט יחד עם סמסונג ומלאנוקס שמסביר יותר על הדברים:

תכירו: Windows Server 2019

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

מיקרוסופט הכריזה רשמית היום על גירסת Preview ל-Windows Server 2019. הגירסה זמינה להורדה (המפתחות כבר בתוך ה-ISO או VHDX) אבל כדאי לשים לב: זוהי גירסת CLI, תצטרכו להתקין כלים כדי להיכנס עם ממשק גרפי.

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

  • Cluster Set: כפי הנראה גם מיקרוסופט מבינה ש-Hyper Converge זה העתיד ומעתה ניתן להגדיל קלאסטרים וליצור Cluster ל-Compute, ל-Storage (הכוונה ל-Cluster של Storage Spaces Direct, כן, גם במיקרוסופט מבינים ש- Software Define Storage יותר עדיף מברזלים קנייניים), ומכונות ה-VM שלכם יכולים "לשוט" להם בתוך ה-Cluster Set לפי ביצועים או שרידות שתגדירו. נחמד.
  • Windows Defender מקבל חיזוק משמעותי בדמות ATP (כלומר Advanced Thread Protection) עם ערימת חיישנים וירטואליים לניטור זכרון, פסיקות (Interrupts) וכו'. אני ממליץ להיכנס ללינק שפרסמתי לעיל לקרוא את הדברים (ויש לא מעט). קצת מזכיר מעולם הסולאריס את DTrace רק שזה לשם הגנת המערכת.
  • מערכת WSL – מיקרוסופט מעתה משלבת את Windows System for Linux בתוך Windows Server 2019 כך שתוכלו להריץ את הפצת הלינוקס החביבה עליכם בתוך שרת Windows 2019. בנוסף מיקרוסופט מחזירה לחיים חלק ממה שהיה בעבר SFU (כלומר Services for Unix) עם SSH, TAR, CURL כך שיהיה אפשר לשלב את הדברים בתוך סקריפטים שלכם.
  • קונטיינרים – כן, מיקרוסופט עושה מאמצים כדי לשלב קונטיינרים ברמה הרבה יותר "טבעית", כך לדוגמא כל IMAGE לא ישקול 5 ג'יגהבייט והוא יקבל "דיאטה" ל-2 ג'יגה (הלו מיקרוסופט, בלינוקס זה בד"כ בין 100-200 מגה בשכבה הראשונה, דרושה עוד דיאטה), כך שתוכלו להריץ גם קונטיינרים של לינוקס ישירות בשרת Windows Server 2019. אוסיף כאן הערה אישית: כרגע ה-WSL נותן ביצועים מחרידים בכל הקשור ל-I/O של קבצים גם ב-2016 וגם ב-Windows 10, כך שבשלב זה הייתי ממליץ לאלו שרוצים להריץ קונטיינרים מבוססי לינוקס – תריצו את זה על מכונת לינוקס.
  • עוד על קונטיינרים – מיקרוסופט "מיישרת קו" עם השוק והיא תשלב את Kubernetes בתוך ה-Windows Server 2019 (כך שאם הלכתם על משהו שאינו תואם ל-Kubernetes – מומלץ לחשוב על "אחורה פנה")
  • פרויקט "הונולולו" – הממשק הגרפי החדש של מיקרוסופט ל-2019 שנותן לכם לא רק לנהל את השרת החדש, אלא גם להתממשק ל-Azure וליצור Hybrid Cloud.

עתה, הרשו לי לשתף אתכם במחשבותיי לגבי המערכת החדשה.

הקמתי את המערכת הזו ושיחקתי איתה פה אצלי ב-LAB הביתי שלי ואני חייב לציין שהתחושה שלי ש-Windows 2019 החדש יותר מזכיר משהו כמו WIndows Server 2016.1. יש שיפורים – אך הם אינם כאלו גדולים. מיקרוסופט כמובן תתנגד למה שציינתי ולראייה המחיר – Windows Server 2019 יהיה יותר יקר (במובן של CAL) מ-WIndows Server 2016 והסיבה לכך פשוטה: מיקרוסופט רוצים שפחות תתקינו את זה על הברזלים אצלכם ויותר תשתמשו בשרותי ה-Azure שלכם.

וכאן בגירסה זו של Windows Server, שרותי ה-Azure מודבקים על ימין ועל שמאל. רוצה DR? עם אז'ור. קלאסטרים, מיגרציה וכו'? עם Azure. זו כמובן זכותה של מיקרוסופט אבל זה די מאכזב לראות שמיקרוסופט שוב נוקטת בשיטות הישנות של כריכת שרות בשרות. אולי כדאי להזכיר למחלקה המשפטית של מיקרוסופט את השם "נילי קרוס"? (מי שהיתה נציבת ההגבלים העסקיים באיחוד האירופאי וקנסה את מיקרוסופט במיליארדי דולרים!). מן הראוי היה שמיקרוסופט תפתח איזה API לאפשר לשאר יצרני העננים הציבוריים (גוגל, אמזון) להתממשק ולאפשר לתחרות לעבוד.

לסיכום: Windows Server 2019 הוא בהחלט מוצר שמראה שמיקרוסופט דוחפת בכל הכח גם לעבודה של Multi Platform (לינוקס, Windows, קונטיינרים "טבעיים" וכו'), את עניין ה-Hyper Converge ואני מאמין שגם תהיה התממשקות מאוד הדוקה ל-Azure Stack לטובת חברות שמעוניינות להריץ את הכל פנימית על הברזלים המקומיים (עקב מגבלות חוקיות ורגולטריות). אלו בהחלט דברים מעולים, אך לעניות דעתי חוסר הפתיחות כלפי ספקי עננים מתחרים קצת פוגם בדברים.
גירסת ה-ISO זמינה במסגרת תוכנית Windows Insider וה-ISO יפעל עד חודש יולי. למנויים ל-LTSC תהיה גירסה של Windows Server 2019 בעוד מס' שבועות.