קטגוריה: פרילאנס

על בנייה ואבטחת מערכות משובצות

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

עם כניסת ה-Raspberry Pi ושלל החיקויים שלו, יותר ויותר אנשים החלו לגלות את עולם ה-SBC (כלומר Single Board Computer – לוח אחד שעליו נמצא הכל, כולל מעבד, זכרון, אחסון ושלל חיבורים לעולם החיצון) ושוק המערכות המשובצות החל לקבל "ניעור" רציני. חברות המייצרות פתרונות הכוללות מערכות משובצות ראו שניתן לרכוש בכמה עשרות דולרים מערכות SBC ל-Embedded, מה שגרם למתחרים הותיקים להוריד מחירים. למי שאינו מכיר – הכרטיסון בתמונה הוא מחשב Raspberry Pi Zero שכולל כל מה שצריך (למעט חיבור רשת קווית שאפשר להוסיף במספר דרכים). העלות? 5 דולר, וזו סתם דוגמא ל-SBC זול שיכול לבצע פרויקטים שונים.

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

  • עצמאית או C/S? אחד הדברים הראשונים החשובים הוא להחליט איך המערכת תרוץ בעצם. האם מדובר במערכת עצמאית שאין לה תקשורת לשום שרת (עצמאית) או C/S (כלומר Client Server)? אם מדובר במערכת עצמאית, אז נצטרך להתקין עליה את כל האפליקציות (תיכף ארחיב על כך), ולדאוג לכך שהיא תפעל כמעט בכל מצב אפשרי, כולל מצב חרום שבו היא יכולה להציג למפעיל אם יש תקלה, מה התקלה ומה קוד התקלה כדי שיצרן הפתרון יוכל לטפל בכך.
    אם מדובר ב-C/S לעומת זאת, אז יהיה כדאי לבנות מערכת כמה שיותר רזה (לא להתקין הפצת לינוקס על המערכת אלא להשתמש ב-Yocto לדוגמא) וכל אפליקציה נחוצה תרוץ על השרת וביניהם התקשורת תעבור ב-TCP/IP, שימוש ב-Web Sockets וכו'.
    אם מדובר במערכת שיש לה תקשורת לשרת אך התקשורת אינה קבועה (אחת לשעה, אחת ליום וכו') אז כדאי יהיה לבנות אותה למצב אחסון זמני כך שברגע שהתקשורת מבוצעת, כל הנתונים מועברים לשרת, מתבצעת בדיקה שהנתונים נשמרו על השרת באופן תקני (אפשר להשתמש במגוון שיטות checksum) ולאחר מכן הנתונים ימחקו מהמערכת המשובצת. מבחינת אפליקציות להתקנה, נצטרך למצוא מה ניתן עדיין להריץ על השרת הרחוק ומה צריך לרוץ מקומית.
  • לא לדסקטופ: יש לא מעט מפתחי מערכות משובצות, שברגע שהם מקבלים מערכת משובצת עם 4 ליבות, 1-4 ג'יגהבייט זכרון ו-64 ג'יגה אחסון eMMC – בונים מערכת כאילו זה לינוקס דסקטופ. זה לא רעיון טוב הואיל וכל מעבד PC פשוט עוקף בסיבוב כל מעבד של מערכת משובצת. בנוסף, מערכות משובצות בקושי מקבלות עדכונים אם בכלל כך שיש סיכוי לא קטן שמערכת כזו בסופו של דבר תיפרץ ומכיוון שמערכות כאלו לא מעודכנות כמעט, הפורץ יכול להיכנס ולהשתמש ברשת הפנימית ובמערכת המשובצת כפי שירצה.
  • דיאטה: מערכת צריכה להיות כמה שיותר קטנה על מנת להקטין את וקטור התקיפה ולאפשר תחזוקה (אם צריך) קלה, ולכן לא מומלץ להתקין עליה מערכות אפליקציות שרת רגילות. צריכים לדוגמא SQL? תכירו את SQLite. צריכים שרת HTTP? יש מספר אפשרויות שמתאימות למערכות משובצות או httpd שמגיע כחלק מ-BusyBox או שימוש בשרת Web מובנה שקיים בפייתון/GO.
  • שפות כתיבת קוד: אם הפתרון הולך לרוץ כ-C/S, אז אתם יכולים לכתוב באיזו שפה שבא לכם ולהריץ את הקוד על השרת. אם זו מערכת עצמאית, אז אני ממליץ לכתוב בפייתון, Go או PERL (לוותיקים שביניכם) וסקריפטים ניתן ב-Bash או Python. יהיו כמובן חברות שירצו לכתוב קוד ב-JAVA או DOT NET (אפשר להריץ Dot Net Core על לינוקס), אבל חשוב לזכור שאם המערכת מבוססת על ARM ותרוץ עצמאית, אפליקציות כמו Wildfly או runtime של Dot Net Core לוקחות לא מעט משאבים ובלא מעט מקרים גורמות למערכת להגיב בצורה איטית.
    חשוב: לא לכתוב קוד אסמבלר יעודי למעבד. נכון, קוד אסמבלר זה נחמד ונותן מהירות (היום זה פחות רלוונטי, GCC מוציא קוד אסמבלי מעולה!) אבל פעם הבאה שהחברה תחליט להחליף מעבד, מישהו יצטרך לשכתב המון קוד אסמבלר מחדש ולכן אני ממליץ לא להיכנס לביצה הזו.
  • רדו מ-Windows: אתם בוודאי נתקלתם בזה בעבר – כספומטים שמגיבים באיטיות, מערכות מידע שלא מגיבות או שפשוט תקועות, קופות רושמות שנתקעות באמצע העברת מוצרים אצל הקופאית ועוד ועוד. מדוע ישנם הרבה פתרונות מבוססי Windows? כי מיקרוסופט מספרת כמה ה-Windows (כולל גירסת ה-Embedded) "יציבה", חברות גדולות עד לפני מס' שנים כתבו קוד שרץ רק על Windows, בנו "פתרון" שמורכב על PC פשוט והרי לכם מערכת שגם עם מיטב המומחים עדיין מצליחה להיות בלתי יציבה ואיטית פתאום.
    כיום ניתן לבנות מערכת משובצת מבוססת לינוקס שלא תתפוס יותר מ-80 מגהבייט אחסון (בערך) ותרוץ יפה על 1 ג'יגהבייט זכרון והמערכת תכלול דפדפן ותמיכה במסך מגע וכל המערכת תעלה מרגע החיבור לחשמל תוך 8-12 שניות עם הצגת לוגו לקוח בשניה הראשונה ולאחר 10-12 שניות הלקוח האנושי יכול להשתמש במערכת בתוך דפדפן סגור (כך שניתן להציג גרפיקה, OpenGL, אנימציה וכו' וגם לחבר את המערכת לציודים אחרים אם צריך).
    מדוע לא עוברים למערכת כזו? בחלק מהמקרים יהיה צורך לכתוב קוד חדש (במקרים כמו קופות), בחלק מהמקרים מדובר בחששות לא מבוססים, ובחלק מהמקרים עקב אי ידיעה או אי הכרת הדברים. אני מקווה בקרוב לקבל כמה מערכות משובצות, לבנות כמה מערכות דמה ולהוציא קליפים להדגמה ביוטיוב..
  • אבטחת מידע: זוכרים שאמרתי שלא כדאי להתקין הפצת לינוקס על מערכת משובצת? זה אחד הדברים הראשונים שפורץ ינסה להשתמש לטובתו, ולכן מומלץ לעבוד עם Busy Box סופר מצומצם במכונה שיכלול אך ורק פקודות הכרחיות, לצמצם הרשאות, לא להריץ הכל כ-root, ואם אפשר – לעבוד עם מפתחות והצפנה, בשביל זה כמעט כל מערכת משובצת מכילה רכיב TPM (לחובבי Raspberry Pi – יש חלק שניתן לרכוש, להרכיב ולהשתמש מבלי להלחים חוטים). אם המכשיר הולך להיבנות בסין, קחו בחשבון שינסו לגנוב לכם את הקוד ולכן הצפנה היא מאוד חשובה.
  • פשוט זה חכם: תכירו את אחד החתולים הביתיים שלי – זהו נימי. מדוע אני מציג אותו? כי רמת המשכל של נימי שווה בערך לרמת המשכל של חלק מהאנשים בסין שיבנו ויקימו את המערכת ללקוח ובחלק מהמקרים – זו גם תהיה רמת המשכל של אלו שישתמשו במערכת (כבר ראיתי מישהו שמנסה להכניס בכח את כרטיס האשראי שלו לחור ממנו יוצאת הפתקית בכספומט!).
    לכן – אם המערכת שלכם כוללת אחסון (eMMC, SSD, לא מומלץ דיסק קשיח מכני, SSD הרבה יותר אמין) ואתם צריכים להקים Installer שירוץ על PC ויתקין את המערכת שלכם על הלוח SBC, תשתמשו בכמה שיותר אוטומציה ותנסו לצפות ולפתור כל תקלה אפשרית. אם המערכת נמסרה וישנה תקלה במערכת, תעלו אותה מחדש אוטומטית כך שברגע שהמשתמש יכנס דרך הדפדפן, התקלה תוצג והלקוח יוכל לשלוח לכם צילום מסך שלה.
    חשוב לנסות (אם התקציב מאפשר) לבנות מערכת Dual Boot (מערכת u-boot תומכת בכך) כך שניתן יהיה לשדרג מרחוק את המערכת עם Image תקין, ואפשר להשתמש בגירסת SystemD האחרונה כדי לעלות למערכת חרום אם המערכת הנוכחית לא עולה (אפשר לקרוא על כך כאן).
  • דלת אחורית/כניסה מרחוק: לא תמיד אתם יודעים היכן המערכת תרוץ ואתם לא יודעים מתי ומאיפה תקבלו בקשת תמיכה, ולכן חשוב לבנות זאת כחלק מהמערכת. אל תצפו ממשתמש קצה להקיש פקודות או שתקבלו בלא מעט מקרים – תוצאות מביכות.

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

כמה מילים על המרה מערכת לניהול גרסאות קוד

בשנה האחרונה ביצעתי מספר פרויקטים הקשורים להמרת מערכת לניהול גרסאות קוד, ממערכות שונות למערכות מבוססות GIT (כמו GitLab, או Bit Bucket ואחרים), ורציתי לשתף עם הקוראים כמה תובנות בנושא.

אם יש סוג מסויים של עסקים בהם אין עבודה כזו, אלו הם הסטארטאפים. אני לא מכיר ולא שמעתי אפילו על סטארטאפ אחד שלא משתמש בפתרון מבוסס GIT (בין בשימוש שרת GIT, שימוש בשרותי GIT של ספקי הענן וכו'). בדרך כלל עניין ההמרה מתרחש אצל חברות ותיקות, ושם אצל אותן חברות ותיקות יש כל מיני פתרונות לניהול קוד, בין אם מדובר ב-TFS (או VSS), ב-Subversion או Mercurial, וכן .. יש גם חברות שמשתמשות ב-CVS. כמעט בכל חברה, מעבר למערכת ניהול קוד אחרת זה תהליך לא קל (בירוקרטית וניהולית, טכנית ניתן להמיר את הדברים ביום או יומיים, תלוי בכל מיני פרמטרים).

ככל שעובר הזמן, עניין המעבר ל-GIT נהיה פחות "אופציה" ויותר "צורך". חברות שחושבות לעבור להשתמש במערכות מבוססות קונטיינרים (בין אם זה Kubernetes, OpenShift, CaaS, Rancher, Mesos ועוד) יצטרכו להבין עוד בהתחלה שמבחינה טכנית ניתן איכשהו לעבור עם מערכת ניהול קוד הנוכחית שיש להן, אבל אם מכניסים מערכת קונטיינרים ל-Enterprise, הצורך לעבור ל-GIT יהיה יותר דחוף.

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

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

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

  • אם אתם חברה גדולה ומסודרת, ואני אוריד את מערכת הקוד הנוכחית ואמחק אותה, והמחלקה המשפטית שלכם תשמע את זה, הם ירדפו אחריי עם נבוטים. קוד ישן ומערכות ישנות צריכות להיות זמינות במקרה שהחברה נתבעת על העתקת קוד או הפרת פטנטים. ישנה חשיבות קריטית לזמנים (תאריכים, כולל שעה מדוייקת) של הכנסת קוד והדברים האלו יוצגו בבית משפט/דיונים מול התובעת כדי להראות סתירות בתביעה. לכן, מה שעושים לגבי מערכות ניהול קוד קיימות (לאחר מעבר לעבודה עם GIT) – הוא שמירת גיבוי, כיבוי המכונה אך לא למחוק אותן.
  • העברת היסטוריה מלאה של קוד קיים ממערכות ניהול קוד אחרות ל-GIT: זה אפשרי בחלק מהמקרים (לדוגמא: mercurial או TFS) אך בעייתי במקרים כמו CVS או Subversion, ולכן בדרך כלל ההמלצה היא להעביר קוד נוכחי ולשמור קוד/Branches ישנים במערכת הקודמת. מיקרוסופט בעבר הבטיחו ללקוחות כי הם יעבירו בקלות קוד מ-SVN ל-GIT כולל היסטוריה מלאה, ורק אחרי שהם התחילו את הפרויקט, הם ראו כמה זה לא ממש ריאלי (במיוחד אם יש קוד ענק של מספר שנים) ומאז הם ירדו מכך.
  • האם להשתמש בשרותי Code Repository של ספק הענן שאיתו אתם עובדים או להרים VM עם אפליקציית שרת GIT (כמו GitLab, BitBucket, GitHub Enterprise)? זה תלוי בכם. אם חתמתם עם ספק הענן על חבילת תמיכה רצינית, אז אולי כדאי להשתמש בשרות (שימו לב, שתצטרכו לשלם תשלום חודשי על כך. באמזון AWS ה-5 משתמשים ראשונים הם בחינם). לעומת זאת, אפשר להקים Instance ולהקים מערכת GIT כמו אלו שציינתי במחירים נוחים:
    • מערכת GitLab היא חינמית כל עוד אינכם צריכים תמיכה מסחרית מהחברה.
    • מערכת BitBucket היא חינמית ל-5 משתמשים ראשונים, 2$ לאחר מכן (מינימום 10 משתמשים) ואתם מקבלים גם אינטגרציה עם Jira.
      שימו לב: ב-2 המקרים אתם מקבלים גם תמיכת Pipelines כדי לבצע אוטומציה לקימפולים, קונטיינרים וכו'.
  • עבודה עם מערכת ניהול קוד נוכחית יחד עם GIT: אם יש לכם מערכת ניהול קוד ישן מבוססת Subversion, ניתן להקים מערכת (היא בתשלום אם יש יותר מ-10 משתמשים) המאפשרת לעבוד מול ה-Subversion והמערכת המסחרית תמיר מיידית את הקוד למערכת ה-GIT שלכם ולהיפך, כך שניתן להמיר את המפתחים לעבודה ב-GIT ואת האוטומציה (Jenkins, Team City וכו') בהדרגה ולא במכה אחת.
  • תמיכה והדרכה – חשוב לסגור את העניין במסגרת חוזה הפרויקט. קל מאוד לעשות שטויות מצד אחד ובמקרים רבים גם לא מנצלים את היתרון של מערכות מבוססות GIT מצד שני – וחבל.

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

התקציב השנתי ורכישת ציוד

יש חברות שכבר הספיקו לתכנן את תקציב ה-IT לשנה הקרובה, יש כאלו שעדיין יושבים על המספרים. כמובן שאצל כל חברה הדברים שונים, יהיו כאלו שירצו בשנה הקרובה להחליף שרתים, להחליף סטורג', אולי לרכוש PC חדשים, לשדרג ל-SSD, לעבור לתקשורת פנימית יותר מהירה (10/40/50/100 ג'יגהביט), וכמובן שיש את כל עניין הפלטפורמות: לעבור לקונטיינרים, הטמעת CI/CD, להתחיל לעבוד בתצורת AGILE, לשכור אנשים/חברות ללמד את העובדים טכנולוגיות חדשות וכו'.

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

נתחיל בסטורג' SDS.

את עולם הסטורג' לקצה התחתון עד הבינוני ניתן לחלק ל-2: סטורג' קנייני (כזה שמגיע עם "ראש", מדפים), וסטורג' מבוסס תוכנה (SDS – כלומר Software Defined Storage). אם תשאלו את אנשי השיווק של הסטורג' הקנייני, תקבלו הילולים מכאן עד הודעה חדשה כמה הוא יציב, וכמה "לא כדאי" לרכוש SDS. המצב במציאות – די הפוך. בואו נאמר שאתם הולכים להוציא $50,000 על פתרון סטורג' ואתם מבקשים מכל העולם והחתול שלו הצעות מחיר לסטורג'. רוב ההצעות שתקבלו – הם SDS, גם אם הם לא יקראו כך בכותרת.

באופן עקרוני, סטורג' SDS מבוסס בעצם על חלקים COTS (כלומר Common Off The Shelf), כלומר שרת SDS אינו שונה מהותית מכל שרת שיש לכם בחדר/חוות שרתים שלכם. יש בו זכרון, מעבדים, בקר דיסקים, דיסקים קשיחים, וכרטיסי רשת. 2 הדברים ששונים בין סטורג' SDS לשרת רגיל הם בקר דיסקים (בחלק מהמקרים יש SAS Expander ו/או בקר RAID יותר יוקרתי הכולל תמיכה ל-SSD Caching) וכרטיסי רשת לחיבור מהיר (10/40/50 ג'יגה). הדבר העיקרי שהופך את השרת ל-סטורג', זו בעצם התוכנה שרצה עליו.

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

מבחינת ביצועים – אחת השאלות שאני תמיד מקבל מצד כל מיני חברות שמתעניינות בסטורג' זה משהו בסגנון "אני צריך פתרון סטורג' עם X טרהבייט ועם כמות Y של IOPS רציפים". עם SDS אין בכלל את העניין הזה. רוצה X טרהבייט? תכניס כך וכך דיסקים ואם נגמר המקום, חבר JBOD בחיבור SAS-HD2. רוצה IOPS? תגדיל כמות זכרון ותוודא שיש לך SSD מהירים כמו P4800X או 905P של אינטל או Z-SSD של סמסונג (זה במקרה הקיצוני שצריכים IOPS גבוה בכל מחיר) או כל SSD שהוא Mixed והוא נמכר לך ע"י יצרן השרתים שלך. סמסונג, אינטל, מיקרון, טושיבה – כולם מייצרים כאלו.

שרידות – אחת הבעיות הקשורות במחיר – היא שרידות High Availability בסטורג' קנייני, כלומר כשצריכים "2 ראשים" לקבל שרידות. המחיר של ראש שני – יקר מאוד! לעומת זאת, בסטורג' SDS, מדובר בעצם על עוד שרת, רכישת JBOD לדיסקים וחיבור ה-JBOD ל-2 השרתים והפעלת פונקציית HA בתוכנת הסטורג'.

מה עם ביצועי רשת ב-SDS? שרת חזק יחיד עם כרטיסי רשת במהירות גבוהה, יתן ביצועים גבוהים ומענה לחיבור כל התשתית שצריך. מנסיון אישי על שרתים שהקמתי, הגעתי ל-250 ג'יגהביט תוך חיבור 150 שרתים, חלקם ב-NFS, חלקם ב-iSCSI וחלקם ב-CIFS (הייתי יכול להגיע ליותר אם היתה לי מכונה יותר חזקה ויותר כרטיסי רשת), כך שפתרון SDS יכול לעמוד בעומסים בלי שום בעיה.

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

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

עוד על SDS כתבתי כאן וכאן.

חושבים להקים HPC?

עם כניסת העננים הציבוריים לחיינו ול"חיים" של חברות, תחום ה-HPC (כלומר High Performance Computing – כשמקימים פרויקט ובו תשתית עם כמות שרתים גדולה כדי להריץ דברים שונים כמו חישובים בצורה מרוכזת) ירד מעט מסולם הפופולריות. אחרי הכל, אם אני יכול לשכור 50 שרתים (פיזיים/וירטואליים) מאמזון בכמה קליקים, אז בשביל מה לרכוש ברזלים?

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

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

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

הדבר הראשון החשוב ביותר בכל מערכת ה-HPC הוא כח החישוב (בגלל זה צריך את השרתים) ולכן יש צורך בתצורה מסויימת. התצורה המומלצת היא שרתים עם 2 מעבדים או מעבד אחד מרובה ליבות. בד"כ זה יהיה שרת 1U או 2U.

מבחינת מעבדים – אני ממליץ על AMD EPYC ולא על Xeon מהסיבה הפשוטה שעל כל כמות X ליבות שאתם קונים במעבד Xeon, אתם מקבלים כפול עם EPYC וכבונוס אתם מקבלים גם יותר נתיבי PCIe (אם צריך להכניס יותר GPU או כרטיסים נוספים) ויותר L3 Cache במעבד ובנוסף חסכון של אלפי דולרים פר מכונה. אם הולכים על מעבדי EPYC, אז השרתים שאני ממליץ:

  • Dell – שרת 1U R6415 (עם מעבד 1 עד 32 ליבות) או שרת R7425 עם 2 מעבדים (עד 64 ליבות)
  • HPE (דור 10): שרת DL325 (מעבד 1, עד 32 ליבות), DL385 (כ-2 מעבדים, עד 64 ליבות). אם אתם חושבים על הקמת HPC בסוף השנה/התחלת שנה הבאה, אולי תתעניינו גם בשרת ה-CL3150 של HPE.

חברות כמו Cisco מציעות פתרונות מבוססי Nodes שבהם ניתן להכניס 4 שרתים בתצורת 2U. זה נראה כך:

זה נחמד, אבל לא כל כך מתאים ל-HPC בגלל המחיר היקר, מה גם שקשה מאוד להוסיף דברים למכונה כזו, ולכן אני לא ממליץ על תצורה של מכונה כזו או Blade.

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

מבחינת סטורג': ברוב המקומות שתראו HPC, לא תראו סטורג' מרכזי כמו NetApp או EMC. הפתרון לסטורג' בדרך כלל הוא פתרון Scale Out מבוסס קוד פתוח, כמו Ceph או Gluster, ואם אתם רוצים את הפתרון קוד פתוח בגירסה מסחרית, אתם יכולים לרכוש מ-SuSE ישראל או מ-Red Hat בארץ.

מכיוון שסטורג' Scale Out נסמך על דיסקים, תצטרכו דיסקים מקומיים על כל מכונה. כאן אני ממליץ להשקיע ב-SSD NVME בתצורת Mixed Intense. ישנם כאלו שמעדיפים להשתמש ב-SSD ובדיסקים מכניים, אבל כפי שניתן לקרוא בפתרונות Storage כמו Ceph – זה לא מומלץ.

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

תקשורת – 10/25/40/50 ג'יגה – זו צריכה להיות החלטה שלכם. יש מספר יצרנים שמוכרים סוויצ'ים – HPE, DELL, JUNIPER, CISCO – מה שחשוב הוא חיבור מהיר (לא 1 ג'יגה ולא 1 ג'יגה ב-Bond) ולפחות חיבור כפול ומתגים כפולים על מנת לקבל שרידות גבוהה. אפשר לחבר את השרתים למתגים בחיבור אופטי או DAC/TwinAx נחושת, החלטה שלכם, אין ממש הבדלים בין השתיים.

אוטומציה: קניתם עשרות שרתים לפרויקט HPC, אתם צריכים אוטומציה, אין דרך להתחמק מכך. בד"כ ההמלצה שלי היא על Ansible, אבל יש כמובן גם SALT, Puppet, Chef. צוות הלינוקס בחברה יכול לאמר מה העדפותיו.

הפצת לינוקס: נדיר מאוד שתמצאו HPC שמריץ Windows, כי כולם מריצים לינוקס, ולכן יש צורך בהפצת לינוקס שתהיה על כולם. בהתאם למדיניות בחברה זה יכול להיות RHEL של רד האט או CentOS 7 החינמי, או SLE של SuSE (ואם אתם מתעקשים על אובונטו, רק גירסת שרת LTS). כפי שציינתי לעיל – גם לרד-האט וגם ל-SuSE יש נציגות בארץ.

שימוש ב-GPU בכל שרת: כאן זה מאוד תלוי מה אתם הולכים להריץ. מכיוון שאין וירטואליזציה בשרתים, אפשר להשתמש בכל GPU (הערה: רשמית, nVidia אוסרת שימוש בכרטיסי GTX בשרתים, אחרת נו נו נו לכם), אך מצד שני, כרטיסי Tesla לאו דווקא יתנו ביצועים יותר גבוהים, אלא אם אתם צריכים הרבה יותר VRAM בכרטיס ה-GPU.

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

תאימות קדימה: במקום לזרוק את המכונות בעוד 3-4 שנים, אפשר לשדרג אותם מבחינת מעבדים, אבל חשוב לשים לב עם אלו מעבדים רוכשים: שרתים מבוססי EPYC של AMD – מובטחת תאימות קדימה לדור מעבד הבא ואחריו, כנ"ל לגבי מעבדי Xeon SP של אינטל אך זה לא קיים במעבדי Xeon V4, שם אתם יכולים אולי לשדרג למעבד מאותה משפחה, אבל סביר להניח שתצטרכו גם להחליף ספקי כח ולא תקבלו ביצועי RAM יותר גבוהים.

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

נקודות למחשבה כשרוצים לרכוש סטורג' חדש

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

לא מעט חברות בארץ משווקים (או Reseller) של מוצרי סטורג'. חלק מהמוצרים הם סטורג' "אמיתי" וחלק מהמוצרים הם לא יותר מאשר שרת סטנדרטי שהוכנסו לתוכו דיסקים, מערכת הפעלה קניינית הכוללת פתרון סטורג' בתוכנה – והרי לכם סטורג' מבוסס תוכנה. כמעט אף אחד, אגב, לא יאמר לכם שזה SDS (כלומר Software Defined Storage) למרות שרוב הסטורג'ים שמוכרים בקצה התחתון עד בינוני הם SDS לכל דבר ועניין, רק שאתם תשלמו מחיר הרבה יותר גבוה ממחיר שרת רגיל שיש בו דיסקים ואיזו תוכנה. מדוע? וולקאם טו איזראל!

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

  • 22 דיסקים של סמסונג מסוג PM883 בגודל 1 טרהבייט מסוג Mixed Intensive
  • 2 דיסקים של אינטל 900P (לצרכי Cache, ZIL, Logs) בגודל 280 ג'יגהבייט
  • 256 ג'יגהבייט זכרון DDR4 ECC במהירות 2666 מגהרץ
  • מעבד יחיד Xeon V4 עם 4 ליבות
  • מערכת הפעלה: Fedora 28 עם ZFS
  • חיבורי רשת של 25 ג'יגהביט

המערכת הזו עבדה במשך חודשיים תוך כדי שהיא מחוברת ל-15 שרתי ESXi ונתנה הן שרותי iSCSI והן שרותי NFS (נפרדים, ישירות ל-VM). מבחינת IOPS – זה נע בין חצי מיליון ל-מיליון.

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

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

  • ה-256 ג'יגהבייט זכרון – זה ה-RAM של המערכת, זה הדבר הכי מהיר שיש
  • 2 הדיסקים 900P של אינטל – יש להם Latency יותר גבוה מ-RAM אבל יותר נמוך מכל דיסק אחר
  • דיסקים SSD

בסטורג' קנייני לעומת זאת (StorWiz של IBM, או VNX של EMC לדוגמא) ה-Tiering מעט שונה:

  • שכבת ה-RAM
  • שכבת NVRAM – זהו זכרון מסוג מיוחד שאינו נמחק ברגע שאין חשמל
  • שכבת ה-SSD
  • שכבת הדיסקים המכניים / SSD שליפים (במדפים)

בשרתי סטורג' שהם SDS אין שכבת NVRAM ובמקרים רבים גם אין בקרי RAID כפולים, כך שה-Tiering הוא כמו זכרון, SSD, ודיסקים. כאן, חשוב לדרוש שיהיו SSD שלא מותקנת עליהם מערכת ההפעלה, ה-Cache אמור לשבת ב-SSD נפרדים ושיהיו Mixed Intensive. ברוב ההצעות מחיר שתקבלו, ה-SSD יהיו Read Intensive ויש הבדל ניכר במחיר.

דבר נוסף שחשוב הוא עניין החיבוריות: כמעט כל מי שמוכר פתרון סטורג', מוכר אותו עם פתרון FC (כלומר Fiber Channel) במהירות 16 ג'יגהביט. זהו פתרון טוב לדיסקים בחיבור SAS ו-SAS2 או SATA למדפים/JBOD או בדיסקים שיושבים בשרת, אבל אם אתם חושבים על NVME – פתרון ה-FC יהווה צוואר בקבוק – חיבור 16 ג'יגהביט מאפשר ברוטו 2 ג'יגהבייט לשניה, ו-NVME מעביר בין 1.5 ל-2.5 ג'יגהבייט לשניה ואני מדבר על דיסק יחיד, ומכיוון שלעולם לא תכניסו SSD NVME יחיד, החיבור יחנק, ולכן אולי כדאי לחשוב על פתרונות Infiniband או Ethernet מהירים במהירות 25 ג'יגהביט ומעלה (ובקשר ל-Latency – ישנם מס' פתרונות עם Latency נמוך, כולל RDMA וחבריו).

אם כבר דיברנו על FC, לא מומלץ לסמוך על 4 חיבורי ה-FC שקיימים ותמיד מומלץ לקנות מתג לחיבור המהיר, במיוחד אם יש לכם רק 3 שרתים ואתם חושבים לגדול בהמשך. יש תחרות, נצלו אותה לשם מו"מ כדי להשיג מחירים טובים.

נקודה נוספת שחשוב לקחת בחשבון היא גיבוי הסטורג' עצמו. כן, יש Veeam שמגבה מכונות וירטואליות (והוא מגבה ל.. סטורג') אך תקלה רצינית בסטורג' (ותקלות תמיד קורות, תשאלו את מרפי) לא תאפשר לכם לא לשחזר מכונות VM או דברים אחרים, ולכן כדאי לגבות את הסטורג' לקלטות גיבוי או למכונת NAS זולה אחרת (במכונות שהן אינן G8/G9/G10 של HPE שהן אינן ביצור/פרודקשן אפשר גם להכניס SATA "ביתיים" גדולים זולים, רק חשוב להוסיף SSD לשם Cache). כאן, אגב, אני רוצה להזהיר בהזדמנות שדיסקים SSD של אינטל ש-HPE משווקת, במקרים רבים הקושחה כזו גרועה, שדיסקים נופלים גם בצוותים!

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

ומה לגבי כל ההתלהבות לגבי HCI עם vSAN/Nutanix/Simplivity במקום סטורג' יעודי? הם טובים, אבל הבעיה האמיתית שלא תמיד שמים לב אליה היא עניין גדילת כמות הסטורג': במקרים כמו vSAN לדוגמא תצטרכו להוסיף 3 דיסקים (2 מכניים או SSD Read פלוס SSD מהיר) פר שרת שמשתתף ב-HCI, ומהירות IOPS גבוהה מקבלים רק כשכמות השרתים המשתתפים ב-HCI היא גדולה (ארון פלוס). נוסיף לכך שבניגוד לדיסקים ביתיים, דיסקים ל-Enterprise יקרים והמחירים בקושי יורדים (וחברה כמו HPE לוקחת עשרות אחוזים יותר בגלל … מדבקה ושינוי כמה ביטים בקושחה) – זה יכול להוות בעיה בטווח הארוך.

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

על גריטת שרתים ישנים ומה ניתן לעשות

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

כשאני מקבל פניות מחברות (לא מסוחרים שמוכרים יד שניה) שרוצות לגרוט/למכור את השרתים היותר ישנים שלהם, אני מקבל פניות שאני יכול להגדיר אותם ל-2 סוגים:

  • מחירים בשמיים – כשחברה רוצה מחירים מאוד גבוהים פר שרת (מעל 1000-1500 שקל נניח) על השרתים שלהם ומחירים בנפרד על ציודים. אלו בד"כ יצטרכו ללמוד על בשרם שאף סוחר/גורט לא יקנה מהם.
  • מחירים מתחת לרצפה – חברות שמקבלות הצעות לקבל "שווה ערך" על שרתים, למרות שבפועל הם מקבלים הרבה פחות ממה שהם שווים (בד"כ השווה ערך מגיע בצורת זיכוי על שעות טכנאי, הנחה ברכישת שרתים או שרותים. סוחרים יד שניה בד"כ ישלמו כסף אם הם לא מוכרים לאותו לקוח ציוד או שרותים).

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

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

  • HP G9 לסוגיו
  • DELL X30 (ה-X מוחלף ב-400, 600, 700 וכו'. האות שבשם לא ממש משנה)

הדבר הראשון שצריך לבדוק הוא אלו מעבדים יש לכם (אפשר להסתכל ב-BIOS/UEFI). אם יש לכם Xeon V3 אז אתם יכולים לפנות ליצרן ולרכוש Kit שדרוג למעבדים, אפשר להכניס מעבדי Xeon V4 לשרת (יש צורך לעדכן את ה-BIOS/UEFI לפני כן, אם לא שדרגתם לאחרונה). הביצועים לא יהיו כמו שרת דור קדימה (G10, X50), אבל אתם תקבלו ביצועים שגבוהים בין 30-60% (ההפרש בביצועים הוא בגלל הזכרון, בשרתים כמו G10,X50 הזכרון הוא DDR4 במהירות יותר גבוהה ממה שיש לכם עם ה-DDR3).

הבעיה בעניין השדרוג קשורה לדרך שאתם רוצים לשדרג. אם אתם לדוגמא חושבים לפנות ליצרן, המחיר שיגבה מכם לא ממש זול. אם לדוגמא יש לכם שרתי X30 של DELL (שוב, ה-X מוחלף במספר 430,630,730 וכו'), תצטרכו לשלם בסביבות ה-800-6000 דולר (תלוי במעבד) כפי שאתם יכולים לראות כאן. אם לעומת זאת אתם קונים מסוחר יד שניה שמביא טכנאי שעושה לכם זאת, המחיר זול יותר. כך אתם מאריכים את חיי השרתים הללו בעוד כמה שנים.

מצד שני, חברות המוכרות שרתים חדשים מעוניינים כיום להיפטר מהמלאי עם מעבדי Xeon V4, אז יכול להיות מצב שרכישת שרת חדש תהיה זולה יותר (מה גם שהמדינה מכירה בשרתים החדשים כמלאי שיש לו פחת ל-3 שנים, כך שאתם מרוויחים בסופו של דבר יותר על רכישת שרת חדש).

שרתים ישנים יותר כמו:

  • HP G7 לסוגיו
  • IBM M3 לסוגיו
  • DELL X20 (שוב, תחליפו את ה-X ב-620,720,420 וכו', לא חשוב האות)

אלו שרתים שניתן ניתן לשדרג מעבדים אבל רק לאותה משפחה (כלומר Xeon V1, לרשימה הזו וגם אז, רק ה-E5-2XXX או E5-4XXX אם יש לכם שרתים עם 4 תושבות למעבדים), כך שאתם יכולים לדוגמא לעבור ממעבדים עם 4 ליבות, למעבדים עם 12 ליבות. השדרוג יוצא יותר זול מהדוגמאות לעיל, אבל הביצועים, למען האמת, לא יהיו כאלו גבוהים כי הם לא כוללים טכנולוגיות יותר מתקדמות שקיימות ב-Xeon V4 והזכרון מאוד איטי בהשוואה לשרתים הכוללים זכרון DDR4.

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

שרת NAS מהיר.

נדמיין לנו סיטואציה: יש לנו מחלקת פיתוח ויש לנו 2 שרתי ESXI שמיועדים לדברים שאינם פרודקשן. עם אותו שרת ישן אנחנו יכולים לספק שרותי NAS ל-2 שרתי ה-ESXI במהירות 10 ג'יגה.

כיצד? די פשוט:

בשרת הישן אנחנו נתקין בקר RAID די מודרני (LSI/AVAGO) ונחליף את כל הדיסקים לדיסקים SATA או NL-SAS (אנחנו לא רוצים להשקיע יותר מדי כסף, נכון? זה לא פרודקשן) ואנחנו נוסיף דיסק SSD (יחיד או זוג, תלוי בכם) שישמש כ-Cache מהיר. את ה-Back Plane של השרת אנחנו ננתק מבקר ה-RAID הפנימי ונחבר לבקר ה-RAID החדש.
כרטיס נוסף שנצטרך הוא כרטיס רשת QSFP (יש גם +SFP) של 10 ג'יגהביט עם 2 פורטים (אפשר להתקין 2 כרטיסים כאלו עם כניסה יחידה בכל אחד מהם, מכיוון שבשרת יש לנו רק PCIe 2.0) ובשרתים נתקין גם כרטיס רשת כזה.
מה עם סוויצ'? לא צריך. אנחנו מחברים כבל DAC בין ה-NAS לבין כל שרת ESXI.

מבחינת מערכת הפעלה, זה כבר תלוי בכם: אתם יכולים להתקין לכם Windows עם Storage Spaces, לינוקס רגיל ולהגדיר דברים ידנית, FreeNAS ויש עוד מספר פתרונות. אחרי ההתקנה של הפתרון אנחנו יכולים לבחור מה אנחנו רוצים לייצא החוצה (לא לשכוח להגדיר את ה-SSD כ-Cache במערכת שהקמנו) – בין אם זה NFS או iSCSI או CIFS ו"לשדך" את זה למערכת ה-ESXi (ה-CIFS הוא למקרים אם אתם משתמשים ב-Hyper-V לדוגמא).

והרי לנו שרת NAS שיכול לתת לנו פתרון שעוקף פתרונות NAS הרבה יותר טובים מפתרונות NAS זולים סגורים.

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

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

וירטואליזציה ודיסקים מקומיים. כדאי?

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

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

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

ל-NAS יש יתרון אחד שדווקא לא קיים במרבית פתרונות הוירטואליזציה והוא קשור לאופטימיזציה. הדרייברים שנמצאים בתוכנת הוירטואליזציה הם דרייברים בסיסיים. הם מאפשרים עבודה רציפה עם הדיסקים ותו לא. כך לדוגמא אינך יכול להכניס לשרת וירטואליזציה 1-2 דיסקים SSD ולהגדיר אותם כ-Cache (ה-Read Cache במקרה של vSphere לדוגמא, מיועד להאצת עבודה חוזרת של מכונות VM, לא לשמש כ-Cache ל-Datastore). לעומת זאת, אם נרים NAS על שרת ישן (זה יכול להיות גם PC עם דיסקים במקרים שאין תקציב) ונכניס לו 1-2 דיסקים SSD, נוכל בעזרת התוכנה ב-NAS להגדיר אותם כ-Cache. בנוסף, אם אנחנו רוצים מהירות גישה רצינית אל/מאת ה-NAS ולא להיות "חנוקים" במהירות של 1 ג'יגהביט – אפשר לרכוש בזול כרטיסי רשת QSFP (או +SFP) שנותנים חיבור במהירות 10 ג'יגהביט עם פורטים כפולים וכבלי DAC ולחבר אותם בין ה-NAS ל-2 שרתים שמריצים מכונות וירטואליות. כך הדברים ירוצו הרבה יותר מהר ואין צורך לרכוש סוויצ' 10 ג'יגהביט יקר לשם כך (אגב, התוספת מחיר על כך מגיעה בד"כ בסביבות ה-300$).

מצד שני, יש בהחלט מקום בשימוש בדיסקים מקומיים כאשר אנחנו משתמשים בתצורת Hyper Converge. בקונפיגורציה כזו, המערכת צריכה לפחות SSD אחד על מספר קטן של דיסקים מכניים והיא משתמשת ב-SSD לשם כתיבה/קריאה מואצת וכמובן כ-Cache (רק שחשוב לשים לב איזה SSD Intense אתם רוכשים, אם רכשתם את הלא נכון, הביצועים יהיו מופחתים) אך גם כאן חשוב לשים לב לא רק לסוג ה-Intense אלא גם לסוג החיבור של ה-SSD. חיבור SATA לדוגמא "נחנק" במהירות 560 מגהבייט ואילו SSD בחיבור U.2/NVME יתן ביצועים ורוחב פס עד פי 4-5 בהשוואה ל-SATA.

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

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

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

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

  • עבודות פרויקט: חברת XYZ מעוניינת בפרויקט מעבר תשתית ל-ABC. לאחר שאקבל את המפרט, אני אוכל לדעת פחות או יותר את כמות העבודה ואוכל לתמחר את ההקמה ב-2 אפשרויות מקובלות:
    • אפשרות ראשונה היא אפשרות Fixed לפרויקט – אני אבקש נניח 1000 שקל עבור הפרויקט. בדרך הזו אני קובע את המחיר כמחיר קבוע ללא כמות שעות שאדרש על מנת להקים את הפרויקט. היתרון הוא יותר לכיוון הלקוח: הלקוח יודע שהוא יצטרך לשלם 1000 שקל ולא שקל אחד מעבר לכך. החסרון שלה הוא בכך שאם אני כפרילאנסר אצטרך להשקיע יותר שעות ממה שחשבתי מלכתחילה, אני אפסיד על הפרויקט. מחיר פר פרויקט יותר מתאים לפרויקטים גדולים כאשר המחירים נעים בין 6 ל-7 ספרות ואין אפשרות לתשלום פר שעה.
    • אפשרות שניה היא מחיר פר שעה: באפשרות זו הפרילאנסר מציין מחיר לשעה וכמות שעות מוערכת שיקח להקים את הפרויקט. אפשרות זו עוזרת להימנע מבעיות בהמשך הדרך אם צצות להם פעילויות שיש צורך לבצע שלא נלקחו בחשבון (מכיוון שהן לא היו ידועות) מכיוון שהלקוח יצטרך לשלם על שעות עבודה נוספות על דברים מעין אלו, לעומת מחיר Fixed ששם הפרילאנסר יצטרך לספוג את הפעילות הבלתי צפויה. שוב, בפרויקטים גודלים – החברה הקבלנית תצטרך במקרים רבים לספוג את הפעילות הבלתי צפויה אם היא לא העריכה זאת מראש. היתרון ללקוח בעבודה עם בנק שעות הוא שניתן להשתמש בשעות הנותרים לצרכי תמיכה או לצרכים אחרים שהוגדרו מראש ללא תשלום נוסף.
  • עבודות Pre Sale כאיש מקצוע מלווה: חברה מעוניינת לשווק לגוף גדול מוצר או שרות. לרוב אנשי ה-Pre Sale אין את הידע המקצועי הרחב שיש לפרילאנסר שנותן כבר שרות/הטמעה למוצר, ולכן במקרים רבים חברות שונות מבקשות מפרילאנסר להצטרף אליהן לפגישות עם הגופים הגדולים על מנת לשכנע את הגוף הגדול לרכוש את אותו מוצר או שרות. לעיתים הפרילאנסר יצטרך להכין Demo או מצגת או ניירות עבודה עבור אותן פגישות.
    בעבודות כאלו, מול חברות אינטגרציה גדולות (כמו Matrix) – בד"כ אפשר לסגור את הנושא בכך שהפרילאנסר ירשום את שעות העבודה ושעות הפגישות ויגיש אחת לחודש חשבונית על כך. לעומת זאת, יש לא מעט מקרים עם חברות אינטגרציה יותר קטנות המבטיחות לפרילאנסר שאם הן יצליחו למכור את המוצר/שרות – הוא יוכל להרוויח מכך כסף, כך שהוא לא ירוויח משעות הפגישה/הכנת מסמכים/Demo וכו' וכאן אני חייב להדגיש עבור חבריי הפריאלנסרים: עם הבטחות אי אפשר לקנות בסופרמרקט ולכן אני ממליץ להתעקש על תשלום שעות על הדברים הללו (תתפלאו, אישית אני שבע מרורים מהבטחות שבסוף לא התקיימו כי הגוף הגדול החליט ללכת על מוצר/שרות אחר ואני נשארתי מבלי שקיבלתי אגורה שחוקה על כל ההשקעה שלי).
  • עבודות שזמנן אינו ידוע: חברה מעוניינת שתבצע איזו עבודה, ובהמשך הדרך לבצע עבודות נוספות זהות ללקוחות החברה. גם כאן מופרחות להן הבטחות שמדובר בכמות שעות גדולה, תצטרך להתחייב לבצע את העבודה במהירות רבה, וכמובן – מחיר נמוך כאילו מדובר במאות שעות לחודש. הבעיה: לא ניתן להעריך את כמות שעות העבודה ומתי הדברים יתבצעו, מכיוון שמדובר בתלות בגורמים שונים.
    במקרים כאלו, אני ממליץ לבחור במסלול בנק שעות שהלקוח יצטרך להחליט את כמות השעות והיא תשולם ב-X תשלומים (מקדמה, תשלומים חודשיים בהתאם לפריסה שסיכמת עם הלקוח). מדוע דרך זו? מכיוון שכפרילאנסר, תצטרך במוקדם או במאוחר להתחייב לזמנים ותאריכים מסויימים עבור לקוחות אחרים והדבר האחרון שהם מעוניינים זה בפרילאנסר "מבריז" עבור לקוחות אחרים. אינך מעוניין להגיע למצב שהלקוח שהבטיח "מאות שעות" סיפק לך בחודש מסויים 4 שעות עבודה ומכיוון שהתחייבת לו, לא תוכל להתחייב לאחר ובכך להפסיד עבודות. לכן, קבעו בנק שעות, ותנו ללקוח לשבור את הראש איך להשתמש בבנק השעות, ואתם לא תגיעו למצב של פרנסה מופחתת בגלל הבטחות.
  • עבודות ריטיינר (כמות שעות חודשית שנמכרת ללקוח): הנה משהו שחשבתי שהוא מוכר ומוסכם, אולם להפתעתי התברר לי שלא כך, ולכן אסביר את הדברים החשובים בעבודות ריטיינר:
    • הלקוח קונה X שעות בחודש. ה-X שעות היא כמות מינימום. במידה והפרילאנסר עובד יותר שעות מעבר ל-X, הלקוח צריך לשלם על כמות השעות הנוספת (מומלץ לפרילאנסר להודיע ללקוח לפני סיום ניצול ה-X שעות).
    • חשוב לקבוע על מה תינתן העבודה: במסגרת החוזה, יש לציין על מה תינתן העבודה, על אלו מערכות ואלו אפליקציות. הלקוח רוצה יותר? כנסו למו"מ על מחיר. (יש כמובן פרילאנסרים שתמורת הריטיינר הם יעשו הכל, חוץ מטאטוא המשרד…).
  • שיתופי פעולה: כפרילאנסרים, ככל שתהיו יותר מפורסמים, כך תקבלו יותר ויותר פניות לשיתופי פעולה – בביצוע עבודות, במכירת מוצר או שרות וכו'. אין בכך שום דבר רע כמובן, ומה שמביא הכנסות – מבורך, אבל חשוב לזכור, כמו בעניין ה-Pre Sale: אם מבקשים מכם דברים, גבו על כך תשלום ואל תתנו לאמרות חלקלקות להוציא מכם עבודות בחינם. תזכרו שאתם עדיין צריכים לשלם למדינה מסים, שכ"ד/משכנתא, אוכל וכו' וכו'.
  • עבודות דרך צד ג': בלא מעט מקרים תקבלו הצעות עבודה דרך חברת אינטגרציה אצל לקוח שלה. גם כאן, כמו בבנק שעות, חשוב לבדוק את כמות השעות ולא להאמין להבטחות שיהיו עוד לקוחות ובהתאם לקבוע את מחירכם (החברה כמובן תוסיף מחיר תקורה כלשהי, ולכן חשוב לקבוע מה יהיה מחיר השעה שלכם) – אל תתנו מחיר של 60 שעות בחודש כמו מחיר של 200 שעות בחודש.

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

בהצלחה

וירטואליזציה כקוד פתוח – כפתרון טוב

לפני כשבועיים פרסמתי את הפוסט הזה שמדבר על פתרונות אלטרנטיביים ל-vSphere של VMWare. הפעם אני רוצה לדבר על פתרונות קוד פתוח כפתרונות טובים לוירטואליזציה ומדוע RHV/oVirt הוא פתרון שעולה על רוב פתרונות הקוד הפתוח.

פתרונות וירטואליזציה בקוד פתוח מתחלקים בעצם ל-2: אלו שמעוניינים לנהל מספר קטן של שרתים פיזיים וצרכי הוירטואליזציה שלהם בסיסיים, ואלו שמעוניינים בפתרון וירטואליזציה מלא כולל הדברים המתקדמים, משהו כתחליף ל-Hyper-V (עם הניהול המרכזי) או תחליף ל-ESXI+vCenter.

כשמדובר בצרכים בסיסיים לוירטואליזציה ומדובר בכמות קטנה של שרתים (נניח 2-5), ומדובר, לשם השוואה, בדברים ש-ESXi עצמאי (ללא vCenter) יכול לתת – אז הפתרונות שהצעתי בפוסט הקודם יכולים לתת זאת ללא בעיה. יותר מכך, כל הפתרונות (למעט שימוש ב-KVM וב-libvirt עם סקריפטים) שהצעתי גם יכולים לתת לכם ניהול מרוכז של השרתים שלכם בממשק Web.

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

  • שימוש ב-vSwitch (בגירסת הקוד הפתוח – Open vSwitch) כ-SDN
  • הקמה אוטומטית של מכונות VM
  • שימוש ב-Grafana לתצוגת מצבי מכונות, דיסקים, מעבדים וכו'
  • High Availability מלא
  • אופטימיזציה לשימוש ב-NVME SSD תוך הגדלת I/O Threads
  • תמיכה מובנית ב-DR
  • יצוא/יבוא OVA/OVF
  • תמיכה במעבדי Power של IBM
  • תמיכה בכל פרוטוקולי הסטורג' (NFS, iSCSI, Fiber) + דיסקים מקומיים ו-GlusterFS
  • תמיכה במעבדים חדשים (EPYC, Xeon SP – ברוב הפתרונות המוצעים זה לא יעבוד טוב, במיוחד כשמדובר ב-HA).
  • ניהול מרוכז של כמות שרתים גדולה (עד 400 מכונות פיזיות)
  • פרופילים (סוגי מכונות, גדלים ועוד) כולל High Performance VMs.
  • תמיכה מורחבת ל-Over Commit
  • יבוא/יצוא של Images מ-OpenStack Glance (לא חייבים OpenStack מותקן בחברה).
  • פורטל למשתמשים (לאלו שצריכים לגשת למספר מכונות VM, ולנהל את אותן מכונות VM)
  • תמיכה במספר סוגי LDAP (כולל AD)
  • התממשקות ל-vCenter ויבוא מכונות VM
  • אפשרות לעבוד במצב הרגיל או במצב HCI.
  • תמיכה מלאה ב-GPU וב-VDI.
  • ועוד הרבה פונקציות אחרות.

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

האם פתרון כמו RHV/oVirt יכול להיות תחליף מלא ל-vSphere? התשובה היא: עדיין לא. העניין קשור יותר ל-Kernel ולדברים מתקדמים אחרים שלא קיימים ב-RHEL-7/CentOS-7 (שעליהם oVirt/RHV רץ):

  • Fault Tolerance עדיין לא זמין בגירסה הנוכחית (4.2)
  • VAAI/VVol – יש תמיכה ב-Kernel 4.X כך שנצטרך להמתין ל-RHEL-8/CentOS-8.
  • תוספים כמו vRealize ואחרים (שהם בתשלום) – יש להם חלופות. חלקם בחינם, חלקם בתשלום.

בכל הקשור לפתרונות וירטואליזציה, הגענו לזמנים טובים, למען האמת. רק לפני 3 שנים אם חברה גדולה היתה שואלת אותי לגבי פתרונות אחרים ל-VMWare או Hyper-V, הייתי ממליץ להם לנהל מו"מ בינם לבין מיקרוסופט ו-VMWare כי הפתרונות לא היו מספיק לדעתי טובים לשום Enterprise. פתרונות כמו Proxmox או פתרונות מבוססי Xen היו קיימים, אך לדעתי הם אינם נותנים מענה מספק ל-Enterprise (אם כי הם היו בהחלט יכולים לתת מענה לעסקים קטנים). בשנים האחרונות, החברה שהשקיעה הכי הרבה בפיתוח פתרון וירטואליזציה טוב היתה דווקא רד-האט. המצב בשוק פשוט התהפך: מיקרוסופט ו-VMWare היו עסוקים בפתרונות וירטואליזציה ואילו רד-האט היו עסוקים בפיתוח פתרונות מבוססי קונטיינרים (OpenShift) וב-3 השנים האחרונות רד-האט משקיעה הרבה יותר בפיתוח פתרון וירטואליזציה וגם בשיפור OpenShift, בשעה שמיקרוסופט ו-VMWare בשנתיים האחרונות יותר מתעסקים בפתרונות קונטיינרים.

לסיכום: שום פתרון (פתוח או סגור) אינו Drop In Replacement. לכל פתרון יש יתרונות וחסרונות וכדאי לשקול את הדברים. בכל מקרה תהיה תקופת מעבר ויהיה צורך לפתור לא מעט בעיות. פתרונות בקוד פתוח לא מחייבים תשלום Up front (למעט במוצר מסחרי כמו RHV, אם כי יש Trial חינמי), אבל כן מחייבים יעוץ, אינטגרציה והדרכה – שזה כן עולה כסף.

תובנות על OpenShift בחברות גדולות

יוצא לי בלא מעט מקרים לתת יעוץ לחברות גדולות לגבי עניין המעבר ל-Devops, שימוש בקונטיינרים, Docker, שימוש ב-Jenkins ושאר כלים. כמובן, כמו תמיד, בחברות גדולות, אף אחד אינו רץ להטמיע טכנולוגיה זו או אחרת רק בגלל שחץ בן חמו (או נציגי Presale של רד-האט, אין לי קשר אליהם) המליץ עליה. יחד עם זאת, בדרך כלל ההמלצה שלי לפני שמרימים אפילו PoC של OpenShift – אני מבקש מהחברה שתתן לי להיות "הטיפש" – להיות עם צוות שינסה את הדברים החדשים ובעצם ללמוד את התהליכים שהצוות משתמש בהם – החל מכתיבת קוד, שימוש ב-SCM, קומפילציה, טסטים, תהליכים נוספים עד לתוצר הסופי (קבצים בינאריים, Artifacts וכו').

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

  1. ניהול קוד (Source Code Management – SCM)
    ברוב המקרים שישבתי לפגישת היכרות ושיחה על המערכות הקיימות, בד"כ מערכת ניהול הקוד היתה TFS של מיקרוסופט או בחלק מהמקרים SVN. מקומות בודדים הכניסו איזו "תת מערכת" של GIT (בשימוש של Gitlab או BitBucket).
    הבעיה: שום מערכת קונטיינרים המבוססת על Kubernetes לא תומכת באופן רשמי לא ב-TFS ולא ב-SVN. כולן תומכות באופן טבעי ב-GIT.
    הפתרונות שיש הם מאוד עקיפים:
    עם TFS יש פתרון די עקיף לבעיה כפי שמוסבר כאן.
    עם SVN הפתרון הוא למשוך את הקוד למכונה מקומית שמחוברת לשרת GIT, ולאחר מכן לבצע Commit, Push לשרת ה-GIT המקומי. זה פתרון די "מכוער" ובעייתי מכיוון שאם מישהו שכח להוריד ולהעלות קוד ל-GIT, ה-Build יהיה בעייתי. אגב, שרת SVN הוא יחסית קל מאוד להמרה ל-GIT, במידה והחברה מעוניינת לעבור ל-GIT.
  2. מכונות Windows ולינוקס ביחד.

    לא מעט חברות גדולות כותבות קוד ל-Windows וסקריפטים ל-Windows (ראיתי גם מקרים של Build ל-JAR/WAR שכתובים ב-Batch file), וכאן ישנה בעיה מהותית – Kuberenetes בעצמו לא רץ בצורה טובה על Windows והפתרון שיגיע בשנה הבאה יאפשר גם ל-Kubernetes וגם ל-OpenShift להשתמש ב-Nodes שהם גם Windows וגם לינוקס (אם כי שרתי ה-Master וה-Infra יצטרכו להיות מבוססי לינוקס).
    עד אז תהיה בעיה לקמפל קוד בצורה יציבה של דברים כמו DOT Net (כדאי לעבור ל-Dot Net Core שנתמך ורץ על לינוקס), ויהיה צורך להמיר קבצי batch ל-shell כדי לקמפל את הדברים על Windows.

  3. בחירת אסטרטגיה ב-OpenShift
    באופן עקרוני, שימוש ב-OpenShift מחייב בחירת אסטרטגיה, ו-OpenShift תומך ב-4 אסטרטגיות פופולריות: Docker, Source to image (S2I), Jenkins Pipeline ו-Custom (שהוא מאוד מתקדם וברוב המקרים לא יהיה בו שימוש אלא במקרים מיוחדים ששאר האסטרטגיות אינן עונות על כך)

    1. אסטרטגיית Docker מאפשרת שימוש ב-Images קיימים מבחוץ (ממקומות כמו Docker Hub לדוגמא) ושניבנו פנימית כחלק מהרמת אפליקציות. יש עם האסטרטגיה הזו 3 בעיות:
      1. רוב ה-Images שתמצאו בחוץ לא יפעלו עם OpenShift כי הם רצים כ-root ו-OpenShift בנוי בראש ובראשונה לאבטחה הדוקה ולכן הוא חוסם מיידית הרצה של Images כאלו (אפשר לבטל זאת אבל אז מישהו יחטוף על כך ממחלקת אבטחת מידע)
      2. בלא מעט מקרים שוחררו Images שמריצים מספר אפליקציות במקביל בתוך אותו Image וזה הורס כל דבר שקשור לגדילה רוחבית (Scaling) ולכן לא מומלץ להשתמש ב-Image כזה.
      3. טכנית, מבחינת אבטחה בקונטיינרים, דברים צריכים לרוץ רק ב-Foreground ולא ב-background ולכן קונטיינרים שיריצו דברים ב-background (שרותים כמו nginx, apache, postfix ועוד ועוד) – הקונטיינר "ימות" לאחר זמן קצר והמערכת תנסה להקים אותו שוב ושוב, מה שיצור loop (במיוחד אם מופעל Replication Controller – RC).
    2. אסטרטגיית Source to image (כלומר S2I): עם אסטרטגיה זו מערכת OpenShift מושכת ImageStream (כלומר Image "שלד"), יוצרת Image חדש שאליו היא "שופכת" את הקוד מ-GIT, מבצעת שינויים שצריך (הרשאות, התקנת קבצים נוספים כמו דרך PHAR ב-PHP או NPM עבור Javascript ועוד ועוד), ולבסוף בונה Image סופי שאותו המערכת מריצה ומקימה POD עם קונטיינר המכיל את ה-Image. באסטרטגיה זו ניתן "לקשור" (דרך Webhook) בין REPO של GIT לבין אפליקצייה ב-OpenShift וברגע שיש שינוי ב-GIT, המערכת תבנה אוטומטית Image חדש וכשתסיים היא תוריד את ה-POD הקיים ותפעיל מיידית את ה-POD עם הקונטיינר החדש (ניתן כמובן לבצע Blue/Green Deployment – פרטים כאן וזה קיים לא רק ברמת אפליקציות אלא גם ברמת מכונות)
    3. אסטרטגיית Jenkins: עם אסטרטגיה זו אנחנו מגדירים הכל מראש: מאיפה הקוד ימשך, מה ה-pipelines וכו' וכו' ו-OpenShift יקים בכל פעם קונטיינר Jenkins, יקמפל, יריץ את ה-pipelines, יפזר מה שצריך לפזר, יבנה Image חדש ויריץ POD עם קונטיינר המבוסס על ה-Image החדש. הדרך הזו יכולה להתאים לאלו שכבר משתמשים ב-Jenkins על לינוקס.

ישנם עוד חלקים הקשורים להקמת מערכת שיש צורך לערב הן את מחלקת אבטחת מידע והן את צוות ה-Storage. בגופים פיננסיים ובטחוניים יהיה צורך לשים דגש על שרתי Registry מקומיים (לחשיפה מופחתת לאינטרנט, אבל עדיין יש צורך לשאוב קבצי Image, בלי זה אי אפשר להקים שום דבר, ואין זה משנה אם מדובר ב-OpenShift או בכל מערכת אחרת מבוססת Kubernetes), שילוב עם Active Directory, הרשאות וכו' (מובנה ב-OpenShift, לא קיים ב-Kubernetes) ועוד דברים רבים.

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