קטגוריה: VMWARE

תכירו את 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 בעוד מס' שבועות.

קונסולידציה – השלב השני שלא מבצעים

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

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

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

ניקח דוגמא: לפנינו 4 ארונות 42U, הם עמוסים ב-40 שרתי 1U בכל ארון (כן, אני משער שבמציאות כמות השרתים פר ארון היא מופחתת הואיל וחלק מהשרתים הם 2U, בחלקם יושבים מדפים של סטורג', סוויצ'ים וכו'). אני מאמין שבכל שרת יש 2 מעבדים שכל אחד מהם הוא 4 או 6 ליבות.

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

  • כמות החשמל שמנוצלת פר ארון היא בערך 12 קילוואט שעה.
  • סביר להניח שפרוסים 40 רשיונות VMWARE Enterprise PLUS רק בארון הזה.

אז איך ניתן לפתור את בעיות הרשיונות או קיצוץ תקציב ה-Datacenter?

התשובה ל-2 בעיות אלו קשורה לפתרון קונסולידציה. קחו לדוגמא ארון עם 40 שרתים – את אותו ארון ניתן להעיף ממנו 34-36 שרתים החוצה וזאת מבלי שצריך לוותר על מכונות VM אחת! נכפיל ב-4 ארונות ונקבל שאנחנו יכולים להגיע למצב שבארון אחד נאחסן 24 שרתים ונקבל את אותם ביצועים וממצב של שימוש של כמעט 50 קוט"ש, נוכל לצמצם זאת ל-5 קוט"ש לערך, חסכון של 90% בחשמל!

גם מבחינת רשיונות VMWare נוכל לקצץ מ-160 רשיונות ל.. 24 רשיונות, יותר מ-75% חסכון מבלי לוותר על שום פונקציונאליות!.

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

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

[stextbox id='info' caption='גילוי נאות']פוסט זה מדבר על שרות בתשלום שניתן ללקוחות[/stextbox]

מה ההבדל האמיתי בין SSD רגיל ל-SSD ל-Enterprise?

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

הרשו לי להציג לכם את ה"יורש" של הסמסונג 850 PRO  שיצא שלשום – אחד מכונני ה-SSD שהצליח במשך 3 שנים להתעלות מעל רוב כונני ה-SSD הביתיים מבחינת ביצועים. זהו הסמסונג 860 PRO. מבחינת ביצועים הן מבדיקות והן "על הנייר" – זו חיה: 560 מגהבייט לשניה בקריאה ו-530 מגהבייט לשניה בכתיבה (זהו כונן בחיבור SATA). מבחינת IOPS יש לו בהחלט מה להתגאות: 100000 בקריאה, 90000 בכתיבה, ואורך החיים שלו – אתם יכולים לכתוב עליו ולמחוק – עד 4800 טרהבייט בכל משך ימי חייו. שום דיסק מכני לא נותן דבר כזה כמובן. מחיר: $238 לחצי טרהבייט.

והנה ה"אח הבכור" – ה-960 PRO בגירסת M.2 NVME. הביצועים? 3.5 ג'יגהבייט קריאה, 1.9 ג'יגהבייט כתיבה. IOPS? טוב ששאלתם: 440000 בקריאה, 360,000 בכתיבה. המחיר: $300 לחצי טרהבייט. אפשר לכתוב עליו באורך חייו כ-400 טרהבייט. (כן, ה-860 מחזיק הרבה יותר).

תכירו את ה-SSD החדש ביותר של אינטל (כתבתי עליו בעבר) – ה-900P. הוא יקר יותר ($628 לגירסה של 480 ג'יגהבייט), הוא יותר איטי בגישה לנתונים (2.5 ג'יגה בקריאה, 2 ג'יגה בכתיבה) אבל כשזה מגיע ל-IOPS, הוא בועט בכולם: 550,000 בקריאה, 500,000 בכתיבה.

אז מי מהם מתאים לחברות ומי לא מתאים לבית? ומדוע ההבדלים?

נתחיל ב-900P (הוא "האח הקטן" של ה-DC P4800X). נניח שאתה רוצה SSD מהיר לבית, אתה עורך וידאו נניח או מוכן לשפוך סכומים רציניים על המחשב למשחקים שלך. הכסף לא ממש משנה לך. האם כדאי לקנות אותו? התשובה היא לא. אם נעמיד את ה-900P במבחן מול ה-960 PRO או ה-860 PRO, שתיהם ינצחו אותו בקלות, כלומר אתה יכול לחסוך 300 דולר ולקבל SSD שיתאים לך לבית.

עכשיו נלך לחברה. נניח שאנחנו מקימים Storage משלנו, נניח שאנחנו מקימים שרת SQL כלשהו (לא חשוב אם זה מיקרוסופט, אורקל או PostgreSQL או MySQL) או שרת אפליקציה שאמור לתת שרות למחשבים רבים או משתמשים רבים. כאן דווקא ה-900P יתן ביצועים הרבה יותר גבוהים בהשוואה ל-2 ה-SSD של סמסונג, הם "יחנקו" מהר מאוד.

ה-SSD ל-Enterprise בעקרון בנוי לתת שרות לכמה שיותר משתמשים/מחשבים/תחנות, כמה שיותר Clients, בשעה שה-2 השניים בנויים לתת שרותים לכמה שפחות, כלומר למחשב אחד, לכמה אפליקציות שרצות במקביל במחשב הביתי/תחנת עבודה. במילים אחרות – אם לא מעמיסים על דיסק SSD ל-Enterprise אתם תקבלו ביצועים רחוקים מאוד ממה שמוצהר ע"י היצרן.

פרסמתי כאן בתחילת השנה פוסט על SSD ל-Enterprise והוא רלוונטי בדיוק לפוסט זה. בפוסט הקודם הזכרתי את ה-QD (ה-Queue Depth) שצריך אותו כדי לתת שרותים לכמה שיותר Clients וזה בדיוק מה ש-SSD ל-Enterprise מצטיין בו ו-SSD לבית גרוע בו. ניקח לדוגמא את ה-960 PRO, אם תסתכלו בסקירה זו תיראו שברגע שמתחילים להעמיס עליו, הביצועים צונחים דרמטית.

עכשיו נשארנו עם בעיה אחת: נניח ואנחנו רוצים ביצועים מאוד גבוהים לשרתים עם דיסקים מקומיים (כן, לאלו שמריצים vSphere עם דיסקים מקומיים לדוגמא) אבל המחיר מפחיד. ה-DC P4800X לדוגמא בגירסה צנועה של 375 ג'יגהבייט עולה $1700 (המחיר קצת יקר באמזון, המחיר הרשמי הוא $1520) וגירסת ה-750 ג'יגהבייט עולה מחיר "צנוע" של $3,653. במחיר כזה, גם חברות גדולות מתחילות לחשוב פעמיים אם לקנות במחיר כזה.

מה ניתן לעשות? ישנן מס' אפשרויות:

  • לקנות כמה קטנים. אפשר לדוגמא לרכוש 2 כרטיסי 900P (אגב, אם השרתים שלכם חדשים, אז ניתן לקנות את ה-900P בגירסת U.2 שנכנסת מקדימה) ולחבר אותם ב-RAID-0 ולהגדיר אותם כ-Cache. זה מתאים למצבים שאנחנו רוצים להריץ את השרת כשרת קבצים או כשרת NFS/SAMBA ואליו נחבר לדוגמא שרתי vSphere.
  • אם אנחנו רוצים להריץ שרת SQL או שרת אפליקציה כבד, נוסיף דיסק SSD כלשהו למערכת, עליו נתקין את מערכת ההפעלה והאפליקציות אך ה-DATA ישב ב-RAID-0 (מתוך הנחה שיש לכם גיבוי יומי!) כ"כונן" נפרד.
  • נבחר כונני Enterprise יותר זולים. לאינטל יש את ה-750 שישן קצת (מ-2015) אבל נותן ביצועים יותר טובים, יש את ה-P4600 ו-4700, שהם מעולים. חברות גדולות, כמובן, לא קונות כוננים ישירות מאינטל או סמסונג, ולכן מומלץ לחברות אלו לבדוק מיצרן השרת שלהם אלו דיסקים ניתן לקנות (לא מומלץ לקנות עם חיבור SAS, לכולן יש פאנל קדמי לחיבור דיסקים SSD בחיבור U.2 או SATA).

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