קטגוריה: יעוץ וירטואליזציה

כשמעוניינים בהקמת מערכת ניטור לארגון

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

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

  • מחיר: יכול להיות שהמערכת הוטמעה בגלל מחיר נמוך (או אפסי) כשהתשתית ב-IT היתה די קטנה אולם עתה שצריך להוסיף כך וכך בדיקות, יש צורך לשלם כמה אלפי דולרים לרשיונות (ובמקרים רבים הרשיונות הם לתקופות ולא תשלום חד פעמי לתמיד). במקרים אחרים החברה אימצה שימוש במערכת ניטור מבוססת SAAS שצריך לשלם עליה כל חודש ועתה החליטו שעדיף להקים משהו פנימי שלא צריך לשלם הרבה.
  • אי גדילה – במקרים רבים החברה מעוניינת במערכת שלא רק יודעת לנטר דיסק/רשת/מעבד לשרתים אלא לתת הרבה יותר מידע פר ציוד ובהתאם לסוג הציוד (לדוגמא: IPMI מפורט לשרתים, גרף תעבורה עם התראות פר פורט ב-Switch וכו') והמערכת הנוכחית לא נותנת זאת.
  • החלטות הנהלה: החברה לא מעוניינת במערכת הנוכחית ורוצה משהו אחר וזו ההחלטה הסופית.

וכשרוצים להחליף מערכת, ישנן מאות ואלפי פתרונות והצעות שונות ואת אותן פתרונות ניתן לחלק לחלוקה הבאה:

  • פתרון SAAS – אתה נרשם לחברה המציעה את השרות, מתקין Agents בשרתים שלך ובד"כ בתוך יום יומיים המערכת שלך מנוטרת מבפנים החוצה (ה-Agents שולחים מידע החוצה), יש לך תמיכה, והתשלום הוא פר חבילות סנסורים ("חיישבנים"), SLA של תמיכה וכו'.
  • פתרון קנייני – אתה מתקין שרת כ-VM, מתקין Agents וגם כאן תוך יום יומיים המערכת פחות או יותר חיה, רצה ומציגה את הגרפים וההתראות שאתה צריך. גם כאן התשלום הוא פר חבילות סנסורים, סוג SLA וכו'. הפתרון הוא פתרון קוד סגור.
  • פתרון קוד פתוח – אתה מקים VM עם SQL כלשהו (MySQL) ואפליקציית הניטור, מתקין Agents ותוך יום יומיים של הגדרות וכו' – תקבל התראות. התשלום הוא אפסי למעט אם מישהו מבחוץ מקים לך את המערכת (ואז התשלום הוא על העבודת הקמה), או שאם אתה מעוניין – רוב החברות שמציעות פתרון קוד פתוח מציעות או פתרון משלים כקוד סגור עם תמיכה או פתרון תמיכה SLA למוצר הקוד פתוח.

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

  • פתרון SAAS. נשמע מעולה, השאלה האם אתה מעוניין לתת לגורם כלשהו לדעת כל דבר מה שעובר אצלך במערכת? (כמות מכונות, מצב מכונות, לאן נכנס ויוצא טראפיק וכו'). הבעיה השניה עם SAAS זה שאתה לא יודע מה הם נוהלי האבטחה (אם יש, מעבר להודעת ה-PR שמופיעה באתר), מה קורה אם פורצים אל תשתית ה-SAAS של אותה חברה שמציעה את השרות, או מה קורה אם שרות ה-SAAS נופל כי התכנון היה גרוע.
    חסרון נוסף: האנשים הנוכחיים שלך אולי יכירו איך לכתוב לזה סקריפטים כדי להוסיף תמיכה בדברים, אבל ברוב המקרים לא תמצא אנשים שכירים חדשים שמכירים את הפתרונות הללו.
  • פתרון קנייני – קצת פחות חמור מ-SAAS, אולם רוב החברות דווקא מעדיפות שלא לרכוש פתרון קנייני בקוד סגור. גם כאן, עקומת הלמידה תחזור בכל פעם שיש לך מישהו חדש מכיוון שרוב האנשים לא מכירים כתיבות סקריפטים וכו' לתוכנות קנייניות.
  • פתרון קוד פתוח הוא דבר מעולה בכך שיש לך את הקוד ואתה יכול לעשות עם הדברים כרצונך. בנוסף, בתוכנות כמו Zabbix, Cacti, Icinga וכו' תוכל למצוא פורומים וגם פרילאנסרים בארץ שנותנים שרות על כלים אלו.
    יחד עם זאת – חשוב לשים לב לאותיות הקטנות. תוכנות ניטור כמו OpenNMS זמינות כקוד פתוח, אולם הגירסה הפתוחה אינה יציבה ואין לה תמיכה מסחרית והגירסה המסחרים שבקוד פתוח כן זמינה עם תמיכה, אך המחיר הוא שנתי כפי שניתן לראות בלינק לעיל.

מתוך האפשרויות לעיל, אני ממליץ ללכת על פתרון מבוסס קוד פתוח. כאן, וכאן תוכלו למצוא מספר תוכנות בקוד פתוח. תוכנה כמו Cacti טובה לגרפים, אבל פחות טובה להתראות. תוכנה כמו Zabbix טובה לגרפים והתראות ויש לה תמיכה מעולה ב-Windows. תוכנה כמו Icinga (שהיא בעצם Fork של Nagios) היא תוכנה מעולה אך מורכבת מאוד ומתאימה לאלו שנטשו את Nagios אבל רוצים עדיין משהו מוכר. לאלו שמחפשים לעומת זאת מערכת ניטור אבל שנותנת הרבה הרבה יותר מידע מאחרים ולהשקיע המון במערכת (ובתמורה תקבל אפשרויות שאילתות מאוד עמוקות עם התממשקות לכל ממשק קיים כמעט) – אז Prometheus של חברת Sound Cloud יכולה להיות הכלי בשבילכם (אם כי אני לא רואה לזה חבילה מסחרית).

יהיה הפתרון אשר יהיה, אני ממליץ לחלק את העבודה ל-3 חלקים (זאת כמובן לאחר שבחרתם תוכנת ניטור):

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

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

בהצלחה

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

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

מוציאים מכרז לרכישת ברזלים? זוג עיניים נוספות יכול לסייע

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

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

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

נעבור חלק חלק, נתחיל בסטורג':

  • במכרז מבקשים הצעת מחיר ל-Unity של Dell/EMC, עם שילוב של דיסקים מכניים (16), דיסקים SSD בגודל 400 ג'יגה (10), ו-3 דיסקים (Fast Cache) ושאר הציודים שצריך. זה טוב ויפה אולם יש כאן לעניות דעתי מספר נקודות שכדאי לחשוב עליהן:
    • פתרון כזה אינו עונה לצרכי מכונות VM שמייצרים כתיבה מרובה. נכון, הסטורג' "יחביא" את האיטיות בעזרת ה-Fast Cache (פלוס עוד כמה טריקים) אבל בשלב מסוים האיטיות תחל לצוץ.
    • הדיסקים SSD  הם איטיים (ולא חשוב אם בפנים הם MLC או eMLC) ובמקרים של Enterprise, דווקא ה-SATA SSD מבצעים עבודה הרבה יותר טובה (תסתכלו בהצעות של כל היצרני SSD, תראו שבד"כ מציעים SATA או U.2/PCIe/NVME, בקושי SAS) ולכן חשוב לזכור – זה לא משנה אם הדיסקים נמצאים בתוך סטורג' קנייני או בשרת: SSD קטנים יותר איטיים מהגדולים ולפעמים בפערים מאוד משמעותיים. לדוגמא: אם רוצים לרכוש 4 דיסקים של 400 ג'יגה, עדיף 2 דיסקים של 800 ג'יגה.
    • במקום להיצמד למותג קנייני, מוציא המכרז יכול לבקש פתרון חומרה ותוכנה שהם Software Defined Storage עם כל הפונקציות שהוא מצפה לקבל בסטורג' קנייני וגם להכתיב כמות מינימום ומקסימום IOPS שפתרון ה-SDS יצטרך לעמוד בו. חשוב לזכור: אם לשם הדוגמא אתה מוציא מכרז ואני זה שצריך לעמוד בו, ואני הסכמתי למפרט שלך, אני צריך לעמוד בביצועים במפרט, ואם זה עולה לי יותר, אותך זה לא מעניין, אני צריך לתת את מה שמובטח וזהו, ולכן במכרזים כאלו כדאי לנצל את הסיטואציה ולקחת SDS, מה עוד שתמיד ניתן להשתמש ב-SDS בעתיד לצרכי פתרונות אחרים בתחום הסטורג', כך שההשקעה משתלמת יותר מאשר סטורג' קנייני (אם לדוגמא עברתם לסטורג' אחר, אתה לא יכול להעביר את הדיסקים הישנים יותר).

מכאן נמשיך לשרתים:

מוציא המכרז מבקש 2 שרתי Dell R730:

  • ראשית, כדאי לבקש את דגם ה-XD, ההבדל במחיר הוא קטן (100-200 דולר, תלוי אצל מי קונים), ודגם ה-XD ניתן בהמשך להרחבות שונות שלא כל כך קיימים ב-R730 הרגיל.
  • לא מומלץ לקחת 32 ג'יגהבייט זכרון במקלות של 2 ג'יגהבייט (כלומר 16 מקלות) הואיל וכל נסיון הרחבת זכרון בעתיד מחייבת החלפת כל מקלות הזכרון ובמקרים רבים הזכרונות הללו ישארו "מיותמים", לכן מומלץ לרכוש את הזכרון עם מקלות של 4 או 8 ג'יגהבייט, בהתאם לגודל הסופי שרוצים.
  • 2 דיסקים של 300 ג'יגהבייט – חבל אפילו לרכוש אותם. אם (כפי שבמקרה זה) רוצים להריץ VMWare, עדיף לרכוש 2 מיקרו SD עם ה-Image מוטמע בהם ולהכניסם לתוך השרת, הואיל ו-ESXI כותב אליהם מעט מאוד והמודול מיקרו SD כולל שרידות (RAID-1). במקום ה-300 ג'יגה, אפשר לרכוש 2 דיסקים SSD בגודל של 500 ג'יגהבייט (מספיק Read Intense רגיל, לא צריך Mixed Intense) ואז להשתמש בהם כ-Read Cache בתוך vSphere, כך תוכנות רבות שרצות שוב ושוב ישתמשו ב-SSD המקומי כ-Cache לקריאה והדברים ירוצו החל מהפעם השניה יותר מהר מבלי להשקיע תקציב רציני.
  • כרטיסי רשתות: במקום לרכוש כרטיס Qlogic 57800 שנותן 2 כניסות 10 ג'יגהביט ו-2 כניסות 1 ג'יגהביט, כדאי לרכוש כרטיס אחד נוסף Intel X710 Quad Port – יוצא יותר זול עם אותה כמות פורטים (4 של 10, 4 של 1).

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

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

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

על מעבר לעננים, אירוח אתרים ועוד כמה דברים

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

נתחיל בתחום האירוח אתרים. עד היום חברות שונות בארץ ששוכרות מקומית מכונות וירטואליות/שרתים לשם אירוח האתרים מהסיבה הפשוטה של Latency ו-SEO (לנקודת ה-SEO לדעתי אין שום אחיזה בכל מה שנוגע ל-Latency ואני יכול להעיד שיש לי כמה מילות מפתח במקום ראשון בגוגל והשרת הוירטואלי שלי נמצא בכלל ב-Amazon Lightsail בוירג'יניה!). עד היום היה ניתן לארח את האתר שלכם בחו"ל ולהשתמש בשרות CDN כמו של Incapsula שלהם יש שרתי EDGE פה בישראל. החל מעתה, גם למתחרה הגדול שלהם (Cloudflare) יש נקודת EDGE פה בישראל כך שאפשר בהחלט להשיג Latency מאוד נמוך גם מבלי לשכור מכונות בארץ ובכך ניתן לחסוך בעלויות השכרה.

מכאן נעבור לעננים ציבוריים ולחברות בינוניות עד גדולות (במובן האמריקאי/אירופאי, פחות במובן הישראלי). בשנים האחרונות, עם כניסת העננים הציבוריים יותר ויותר לקידמת הבמה, חברות בסדר הגודל שהזכרתי לעיל "השתעשעו" (במובן של PoC, העברת מספר מכונות לענן ציבורי כלשהו לצרכי טסטים ו"טבילת אצבעות" וכו'). חברות רבות קיבלו קרדיטים מספקי הענן הציבורי (בסכומים הנעים מעשרות עד מאות אלפי דולרים). חברות רבות השתמשו באותם קרדיטים כדי להעביר תשתיות כלשהן לענן ובאותו זמן לפי כל החברות המודדות מכירות שרתים, מתגים, סטורג' וכו' (חברות כמו IDC, מורגן סטנלי, גרטנר ואחרים) הוציאו דוחות שכמות הציודים ל-DC/שרתים שנמכרת מאותם יצרנים הולכת וקטנה והטרנד הזה נמשך כבר יותר מ-5 שנים, אולם לקראת סוף 2016 האחוזים עלו במעט ואילו ב-2017 האחוזים עלו בצורה יפה (7% בהשוואה ל-2016) לפי הדו"ח של חברת Canalys שהופיע ב-The Register כאשר Cisco מכרה יותר מאשר Dell/EMC (ו-Dell/EMC מכרה יותר מ-HPE). דו"ח של חברת Morgan Stanley ציין פחות או יותר את אותם דברים בחודש שעבר.

אבל (וזה "אבל" גדול) – יש כאן גם טוויסט…

חברת ששמעו, התעניינו או הקימו PoC (או אולי עברו) לפתרונות HC (כלומר Hyperconverge) ראו שפתאום הם לא חייבים לרכוש את הסטורג'ים היקרים (מאוד) או סוויצ'ים סופר יקרים שעושים המון דברים. פתרונות Hyperconverge כמו ה-VSAN של VMWare, או Nutanix או SimpliVity או OpenStack (או RHV של רד-האט) נותנים גם ביצועים יפה וגם שרידות מרשימה – והכל רץ על שרתים סטנדרטיים כשהכל בעצם רץ כ-(Software defined (storage/network. ולפי 2 הדוחות, חברות מגלות יותר ויותר עניין בפתרונות כאלו מאשר הפתרונות הקאלסיים של ברזלים קניינים ויעודיים.

משהו נוסף שמוזכר בדוחות אחרים (לצערי אין לי כאן קישורים כי רובם בתשלום) זו מצד אחד הפתיחות שהיום הרבה יותר גדולה כלפי PAAS ו-SAAS, אך מצד שני, יש נסיגה כלשהי מ-IAAS. אני מכיר חברות שפרסמו מאמרים כמה IAAS יהיה יותר זול אצל ספקי ענן ציבורי אבל בסופו של יום אם נסתכל על הטרנד של השנתיים האחרונות, יותר ויותר חברות מעדיפות את ה-Infrastructure להשאיר אצלם למעט דברים מסויימים שעדיף שיהיו בענן (אתרי אינטרנט, שרותים מסויימים שעדיף לתת דרך הענן וכו') אבל השאר (שאינו SAAS/PAAS צד ג') – מקומית ב-DC שלהם.

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

ישנן 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]

על קונטיינרים וחומרה

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

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

עולם הקונטיינרים משנה מספר דברים חשובים:

  • אפשר להקים הרבה פחות מכונות VM כדי לתת את אותו שרות.
  • קונטיינרים צריכים 30-70% פחות משאבים בהשוואה להרצת אותה אפליקציה שרצה ב-VM
  • מבחינת Scalability – קונטיינרים עושים את העבודה בצורה יותר טובה בהשוואה ל-Scaling של מכונות VM, והגדילה הרבה הרבה יותר מהירה בהתאם לעומסים.

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

אם נסתכל על חברות ענקיות כמו פייסבוק וגוגל, נראה שבהתחלה השרתים שלהם היו שרתים מאוד צנועים, והם פשוט הכניסו המון שרתים על מנת לבצע Scale Out עם מעבדי Xeon. לאחרונה, אותן חברות החלו לעבור לארכיטקטורות מתחרות, בגוגל לדוגמא עברו למעבדי Power של IBM ומעבדי ARM חדשים ו-Facebook גם מכניסים מעבדי ARM. זה לא ללקוחות שלהם, זה בשביל להריץ את הקונטיינרים שלהם.

לכל אחד מהארכיקטורות האחרות יש יתרונות על פני מעבדי ה-Xeon (גם החדשים) של אינטל:

  • למעבדי ARM יש את היתרון הגדול של כמות ליבות גדולה וצריכת חשמל נמוכה, מצב אידיאלי כאשר כל קונטיינר אינו צריך עוצמת מעבד רצינית ולפיכך ניתן להריץ יותר קונטיינרים פר מכונה פיזית מבלי לצרוך כמות חשמל כה גדולה. כך לדוגמא מערכת Apollo 10 של HPE תוכל בקרוב לקבל מעבדי ARM בגירסה יעודית. חברת Qualcomm לדוגמא יצרה מעבד שנקרא Centriq ויצרני שרתים מובילים שמחים לאמץ ולמכור שרתים עם פתרון זה.
  • למעבדי Power יש הרבה יותר כח מכל מעבד Xeon שיש לאינטל. אלו המעבדים שמפעילים את ה-MainFrame למיניהם ו-IBM מוכרת לדוגמא שורת מכונות שמריצות לינוקס בצורה טבעית עם אחריות ושרות מלאים (עם Red Hat 7.4) וכל מכונה יכולה להריץ הרבה יותר קונטיינרים בהשוואה למכונה מבוססת Xeon (תלוי כמובן במפרט).
    יתרון נוסף של מעבדי Power9 של IBM – זה שניתן להריץ קונטיינרים באופן טבעי ישירות על ה-Main Frame, ולקבל לא רק ביצועים טובים, אלא את השרידות הכי גבוהה שיש (זו המערכת היחידה שאתה יכול להוסיף זכרון, מעבדים כשהמערכת רצה).

נשאלת כמובן השאלה: מה עם תאימות בינארית? התשובה לכך היא די פשוטה: המערכת הפעלה שתרוץ בקונטיינרים כבר קיימת לקונטיינרים. מה שנשאר הוא לקמפל ספריות וקוד פנימי של החברה ובכך בעצם ליצור קבצים בינאריים לפלטפורמה שנבחרה וכך נוכל לבנות Images שהם אופטימליים (ללא שום המרות או אמולציות) לפלפורמה שנבחרה. לדוגמא – אם האפליקציות שהחברה כותבת הם ב-JAVA ורצים על Tomcat, אז ה-JDK קיים באתר של IBM ויש קונטיינר מוכן עם Tomcat ל-Power9. אותו הדבר קיים גם ל-ARM.

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

דעה: על רכישת CoreOS ע"י רד-האט

[stextbox id='info' caption='הערה']הדברים הנכתבים כאן הינם דעתי האישית, אינני כותב מטעם Red Hat[/stextbox]

בימים האחרונים פורסמו באתרי טכנולוגיה שונים החדשות כי חברת רד-האט רכשה את חברת CoreOS. חברת CoreOS היתה מתחרה של רד-האט בכל הקשור למערכת לניהול Kubernetes (בשם Tectonic), ניהול Registry לקונטיינרים (Quay), וכמו כן את Container Linux (מערכת הפעלה מצומצמת להפעלת קונטיינרים) וכמובן את etcd שהוצאה כקוד פתוח ורבים (כולל רד-האט) משתמשים בו.

רד-האט (Red Hat) כידוע, היא החברה הכי גדולה בהפצת לינוקס ובמערכות מבוססות קוד פתוח ומטבע הדברים, כשהיא רוכשת חברות קטנות אחרות, יהיו כאלו שידאגו מה יהיה עם המוצרים שהם רכשו, מה עם תחרות וכו' וכו'. בפוסט זה אנסה להסביר מה הולך לקרות לדעתי בהתבסס על רכישות קודמות של רד-האט (כמו Qumranet, InkTank, Gluster ואחרים).

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

אז לעניות דעתי הדברים הבאים הולכים להתרחש. כל השינויים לא הולכים לקרות מחר, אלא סביר להניח שלקראת סוף השנה או החל משנה הבאה:

  • אחד הדברים הראשונים שלדעתי הולכים להשתנות הוא דווקא בצד של רד-האט והוא מוצר ה-Atomic Host. אינני חושב ש-Atomic Host ימחק, אבל יכול להיות שיהיו שינויים שיגיעו מ-Container Linux של CoreOS.
  • בכל מה שקשור ל-Registry, אני בספק אם יהיו שינויים רציניים אם בכלל במוצרים של רד-האט. ה-Registry הנוכחי שקיים ב-OpenShift לא ממש שונה למיטב זכרוני ממה שקיים ב-Quay, אבל יכול להיות שיהיו שינויים מעטים.
  • לגבי Tectonic – כאן זו שאלת המיליון דולר. רד-האט מייעדת את OpenShift ללקוחות גדולים, אלו שמוכנים לשלם כמה עשרות אלפי דולרים על מערכת OpenShift Enterprise (ועוד 2000-3000$ פר Node, ויש עוד כמה תשלומים על כל מיני חלקים) ורד-האט כבר הפיקה לקחים מהעבר לא לעצבן את הלקוחות הגדולים בשבירת תאימות אחורה. אני מאמין שבשנה שנתיים הקרובות יהיו 2 מוצרים: יהיה Tectonic שכולל שינויים (והמרה/תמיכה בפורמט קודם) להיות תואם לפורמט של OpenShift והוא ייועד לתחום ה-SMB (כלומר Small/Medium Business) ותהיה מערכת ה-OpenShift Enterprise שתוכל להמיר מערכת Tectonic ל-OpenShift – לאלו שגודלים ורוצים לעבור ל-OpenShift Enterprise.
  • לגבי etcd – השינויים שיהיו הם מול ה-Upstream, כלומר מה ש-CoreOS קובעים (פחות או יותר) יכנס ל-OpenShift.
  • לגבי RKT – יכול להיות שיקחו חלקים ממנו לצרכי שיפור Docker Container Engine (אני בספק) אבל אישית אני לא רואה את זה ממשיך כמוצר מסחרי.
  • לגבי השאר – כל פרויקט יעבור בחינה אם הוא מתאים לשילוב בדברים קיימים או שהוא ישאר ב-github.

רבים ישאלו: מדוע בעצם רד-האט רכשה את CoreOS? הרי יש להם מוצר כמו OpenShift הן בגירסת Online (שכל אחד יכול להיות מנוי ולהקים קונטיינרים מבלי להרים מקומית מאומה) והן גירסת Enterprise, אז מה להם ול-CoreOS? התשובה היא פשוטה: גודל שוק ולקוחות. השוק יותר ויותר מתרכז סביב פתרונות גדולים, בין אם מדובר בפתרונות ענן של ספקי הענן הציבורי, פתרון Kubernetes ישיר (גירסת הקוד הפתוח) או פתרון ניהול קונטיינרים מבוסס Kubernetes עם "פנים" ל-Enterprise. תמיד יהיו פתרונות כמו DC/OS, Rancher ואחרים שיכולים להתאים לכל מיני סקטורים, אבל ה-Enterprise דורש דברים אחרים ש-Kubernetes עצמו לא נותן לא מבחינת אבטחה, לא מבחינת רגולציה, עמידה בסטנדרטים משפטיים ועוד, והדבר הכי קרוב שיש עבור Enterprise כולל הדרישות הגבוהות שלהם (ולאלו שמוכנים לשלם) זה OpenShift.

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

נקודות למחשבה בעת קניית סטורג' קנייני (סגור)

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

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

פתרונות סגורים לעומת זאת – הם הרוב המוחץ כרגע בישראל, החל מפתרונות NAS פשוטים לעסק הקטן, המשך בפתרונות SAN עם חיבורי FC (כלומר Fiber Channel) וכלה בפתרונות המכילים לא רק את שכבת הדיסקים/LUN וכו' אלא גם פתרונות לפרוטוקולים כמו NFS/CIFS ולאחרונה פה ושם ישנם פתרונות שמציעים בנוסף גם Object Storage. מכיוון שכל יצרן נותן לזה שם מפוצץ אחר, נקרא להם בפוסט זה "פתרון משולב".

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

צריך NFS/CIFS?
אם נקנה מחר פתרון SAN שכל מה שהוא נותן לנו זה iSCSI, אנחנו לא נקבל שרותים כמו CIFS/NFS. זה נראה חסרון קריטי במבט ראשון, אך מצד שני לא חסרים Appliance וירטואליים (שרצים כמכונות VM) שיתנו את אותן פונקציונאליות, בין בפתרון מבוסס קוד פתוח, או פתרון סגור לחלוטין. אותם Appliance עולים כסף (למעט אם הקמת מכונת לינוקס ובחברה יגדירו את הדברים) אך במקרים רבים אותם Appliances יעלו פחות מרשיון CIFS או NFS ופחות מפתרון משולב וישנם גם Appliances שעובדים כצוותא בצורה מעולה כ-Cluster (אקטיבי/אקטיבי או אקטיבי/פאסיבי). אפשר כמובן גם להשתמש ב-Windows עצמו כשרת קבצים לדוגמא (אם כי אינני בטוח שזהו פתרון טוב לאלפי חיבורים סימולטנית). חשוב לזכור: לא חשוב כמה הסטורג' יהיה יקר, מימוש דברים כמו NFS/CIFS מבוצע בתוכנה בלבד והכל עניין של מימוש. יש מימושים טובים יותר ויש מימושים טובים פחות הן ב-Appliances והן בסטורג'.

פתרון  Cluster?
פתרון Cluster הוא פתרון מעולה לשרידות, הכל נכתב כפול ואם אחד נופל, השני ממשיך לתת שרות וכשאותו אחד שנפל הוקם, יש סינכרון ביניהם מבחינת קבצים. הבעיה בד"כ? המחיר. אם נניח פתרון סטורג' יחיד עולה 40,000$ (סתם זורק מספר), פתרון Cluster יעלה הרבה יותר מ-80,000$ בגלל הרשיון. על זה אפשר להתגבר כמובן, אך הבעיה המרכזית שבגינה חברות מחליטות לעבור לפתרון סטורג' אחר – הינם מחירי ההרחבות. אם נרצה להוסיף מגש, נצטרך כפול (וכמובן כפול דיסקים). מגש האצה? אותו דבר. אם תסתכלו באינטרנט על מחירי דיסקים ל-Enterprise (ולא משנה אם מדובר בדיסק מכני או SSD) – אתם תוכלו למצוא בכל מיני אתרים גרפים שמראים על ירידות מחירים, בשעה שאצל יצרני סטורג' אין כמעט דבר כזה. דיסק עולה 700$ היום והוא יעלה 700$ (אם לא יותר) גם עוד חודש. בלא מעט מקרים, כשלסטורג' יש כבר מעל שנתיים או שלוש "ותק" – תראו יותר ויותר חברות שכבר מוכנים לקחת סיכון ולקנות דיסקים ממקור חיצוני אחר ולא ספציפית מהיצרן (חשוב לשים לב שפורמט הסקטורים יכול להיות שונה, כמו במקרים של NetApp אם כי יש כלים בלינוקס שיכולים לשנות את פורמט הסקטורים למה שתרצו ובכך להשמיש דיסק "זר" לסטורג').

מעבר לפתרון Scale Out
מדי פעם אני נשאל "מתי לדעתך כדאי לחשוב על מעבר לפתרון Scale Out?" ותשובתי היא פשוטה: כמה טרהבייט של מידע יש לך? ככל שכמות המידע שלך גודלת ועוברת נפחים של עשרות טרהבייטים (נניח 80-100) – יהיה כדאי לחשוב על פתרון Scale Out.
בפתרונות Scale Out דברים רבים "נזרקים" החוצה בהשוואה לעולם הסטורג' עם ראש אחד או כפול. כך לדוגמא, כל האחסון מבוצע על שרתים (אם כי תמיד אפשר לחבר להם JBOD). ליצרן התוכנה לא משנה ממש איזה שרתים יש לך (כל עוד הם עומדים בפרמטרים מסויימים) וגם את הדיסקים אתה יכול לרכוש בעצמך מאיזה גורם שתרצה. ב-Scale Out עובדים יותר דרך Ethernet (או Infiniband – תלוי בכם) בחיבור Copper או סיבי (החלטה שלכם) כאשר הרשת בין השרתים צריכה להיות מינימום 10 ג'יגהביט (מומלץ יותר 40 או 50 ג'יגהביט). לא חייבים שהכל יהיה Flash אבל צריך כמה וכמה דיסקים SSD ומה שהכי חשוב – הכל מבוסס תוכנה וכאן מגיע שלב מעניין: רוב מוחלט של המשתמשים ב-Scale Out אינו פוסל פתרון מבוסס קוד פתוח (כמו CEPH) ומבחינת פונקציונאליות – מה יש לקוד הסגור, יש גם לקוד הפתוח. כמובן שאינני ממליץ להוריד מהאינטרנט ולהתקין אלא לרכוש את התוכנה (תצטרכו תמיכה, האמינו לי) כך שבסופו של דבר השיקול העיקרי כאן הוא המחיר רשיון ופחות מחיר שרתים (אין שום בעיה להשתמש בשרתים מדור קודם או לפניו).
עוד נקודה שחשוב לזכור בכל הנוגע ל-Scale Out: אם צריך יותר ביצועים, לא מרחיבים יותר זכרונות / מחליפים למעבדים מהירים יותר – אלא מוסיפים כל פעם שרתים נוספים שיריצו את התוכנה, וכך גם כמות המקום הפנויה גודלת והביצועים גדלים.

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

על Spectre/Meltdown ועל יצרניות סטורג'

הערה: הפוסט הבא נכתב כטור דעה אישית בלבד ואינו בא "לתקוף מתחרים"

כולנו שמענו על הצרות עם Meltdown ו-Spectre. בחברות מסויימות מיהרו להטמיע עדכוני BIOS/UEFI רק כדי לראות מערכות שבאופן רנדומלי מבצעות Cold Reboot ללא השארת עקבות והצהרות מצד היצרנים לא להתקין את העדכונים האחרונים ואם הם הותקנו – יש לבצע Rollback.

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

תסלחו לי, אבל מדובר לדעתי האישית בחתיכת בולש*ט!

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

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

כיום, מה שבד"כ רואים בפריצות למערכות, זה שמנסים לפרוץ אל השרתים ומכיוון שלשרתים אין גישה לכל מה שנמצא על ה-Storage, אפשר לגשת דרך השרת רק לחלק מהמידע. עכשיו תנסו לחשוב על פורצים מתוחכמים וממומנים. תחשבו על חברות מתחרות שיש ברשותן מאות מילונים/מיליארדי דולרים, תחשבו על מדינות כמו סין ורוסיה שמחזיקות צבא של פורצים ושהן מעוניינות במידע שלך. גם באותם גופים קוראים חדשות והם קוראים שיצרניות ה-Storage מתחמקות והן לא הולכות לבצע עדכוני Meltdown/Spectre. עכשיו אותם פורצים פשוט צריכים לשנות אסטרטגיה: עכשיו הם צריכים בעצם לפרוץ לתחנת עבודה שמריצה Windows או מק או לינוקס ומשם לפרוץ לממשק ווב או לקונסולה (CLI) של ה-Storage, להעלות משהו כמו busybox ואז להשתמש ב-חורים Spectre/Meltdown כדי לקבל מידע סודי/פנימי/חסוי. (הנה משהו שאולי יכול לעזור לכם: בדקו אם יש לכם ACL שנותן גישה לממשק רק למכונות מסויימות בחברה).

מדוע החברות Storage עושות זאת? אני יכול רק לנחש: אם הם יתקינו את הטלאים נגד Spectre/Meltdown – תהיה ללקוחות הנחתה רצינית מאוד בביצועים. כמה? אני יכול להמר בסביבות ה-5-40% תלוי כמובן כמה ה-Storage חדש או ישן. את הלקוחות לא יעניין שהחור קשור למעבדים של אינטל, הם יפנו אצבע מאשימה ליצרני ה-Storage ויצרניות ה-Storage יצטרכו להחליף לוח עם כמעט כל החומרה (למעט כרטיסים וספקי כח..) והמחיר לדבר כזה הוא אסטרונומי מבחינתם.

לסיכום: האם הטיעון של יצרני ה-Storage יחזיק משהו? אני בספק. לחברה הראשונה שיפרצו ותהיה הוכחה שהפורצים חדרו דרך הממשקים והשתמשו ב-Spectre/Meltdown, תהיה לדעתי גל תביעות נגד היצרנים. תזכרו: כלקוחות, ממש לא מעניין אתכם איזה מעבדים ואיזה ציוד נמצא על לוח האם של ה-Storage, אתם רוצים ביצועים נטו, וגם אם יהיה שם מעבדים של ARM זה לא ממש יעניין אתכם.

Exit mobile version