במקרה חרום

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

נתחיל בעניין ה-DR/DRP. כן, אני מודע לכך שהנושא היה "שוס" ב-3 השנים האחרונות, ערימות של מסמכים נכתבו על הנושא פנימית וחיצונית בחברות שונות בארץ ובעולם וכמובן שחברות רבות רכשו חבילות תוכנה/שרותים ורכשו ציוד שיושב באיזו שהיא חווה (או באחד מהעננים הציבוריים) והמערכת מסתנכרנת תדיר בין ישראל לבין המיקום השני. הפתרון הזה הוא פתרון מעולה כאשר חברה נותנת שרותים לקהל לקוחותיה שנמצאים מחוץ לחברה. במקרים כאלו, התשתית המרוחקת (לאחר שינוי DNS) תתן שרותים וכשהתשתית הישראלית תחזור לפעילות, הנתונים יסתנכרנו ארצה.

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

אין תקשורת. החוצה.

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

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

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

  • שימוש ב-DNS פנימי, 2 שרתי DNS שמסונכרנים ביניהם תדיר עם AD ו-DHCP. (סביר להניח שזה מצב קיים אצל הרוב, אבל יש כאלו שהעבירו את זה לענן. תתפלאו).
  • שרת מייל פנימי – נכון, אין אפשרות לקבל/לשלוח מיילים מחוץ לחברה אך במקרים רבים המיילים/יומנים הם פנימיים ולכן שרת מייל פנימי יוכל לבצע זאת. (מכיוון שאינני מומחה Exchange, כדאי לשאול את מיקרוסופט איך מסנכרנים שרת כזה ל-365 אחרי שהתקשורת חוזרת).
  • שרתים (VM) שעברו לענן – כדאי להקים אותם פנימית בחברה עם DB ו-Snapshot שמתעדכן תדיר, עם כתובות FQDN זהות פנימית לשרתי DNS שציינתי בנקודה הראשונה, כך ששירותים חיוניים יופעלו מהתשתית המקומית בהיעדר תקשורת החוצה.
  • גיבוי – לוודא היטב שיש גיבוי מקומי והוא תקין (כן, מומלץ להריץ Verify על הקלטות). תזכרו – אין תקשורת, אין DR מרוחק.

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

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

אנשי שיווק מול אנשי מקצוע

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

ואז שאלתי: איזה פתרון וירטואליזציה אתם הולכים להריץ? הם נקבו בשם מוצר. תשובתי: זה לא ירוץ.

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

תשובתי: אם אדוני מעוניין, אשמח לחבר אותו ל-LAB אצלי, שם המוצר שבחרתם רץ, ואשמח להראות לאדוני שהמוצר שבחרו אינו עושה את אותם דברים עם הברזלים שיש לכם.

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

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

עוד דוגמא: חברה מסויימת פנתה אליי בקשר למוצר שהם משתמשים וכבדרך אגב אותו אדם שפנה אליי סיפר לי שגם להם יש שרתים כמו שרכשתי (X3550 M3 של IBM) והם בדיוק הולכים  לרכוש הרחבת זכרון ל-256 ג'יגהבייט. הסברתי לבחור משהו פשוט: אתה תרחיב זכרון, ותראה נחיתה של 40% בביצועים. הוא לא האמין, הנציג שמוכר לו את הזכרון לא סיפר לו כלום על כך, אז שלחתי לו מסמך של לנובו שמראה שבשרתים עם מעבדים המבוססים על פלטפורמה של Westmere או Sandy Bridge, ברגע שממלאים את הזכרון, מהירות הזכרון יורדת מ-1333 מגהרץ ל-800 מגהרץ. אז יהיה יותר RAM, אבל הגישה תהיה יותר איטית. עדיף להוסיף שרתים – וזה ההבדל בין מישהו מקצועי לאיש שיווק.

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

  1. הפתרון שלהם מתאים אולי לשנת 2000, לא לשנת 2018.
  2. אין שום גדילה אופקית בפתרונות שהציעו
  3. אין שום שרידות רצינית בפתרונות שהציעו
  4. אין שום עדכוני אבטחה בפתרונות שהציעו.
  5. ההשקעה הכספית הראשונית גבוהה.
  6. הפתרון שהצעתי לאותה חברה הוא פתרון מבוסס קונטיינרים בענן. לאותה חברה יש ספק ענן מועדף ובכל הקשור לתמחור – יש לפנות לאיש השיווק של אותו ספק ענן.

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

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

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

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

הפצה מול הפצה: רד האט מול SuSE

בעולם ה-Enterprise יש כיום 2 הפצות לינוקס מרכזיות שנותנות פתרונות מלאים לשוק זה והן RHEL של חברת Red Hat ו-SLE של חברת SuSE. הפעם ננסה לבחון מי מהן טובה יותר בכל מיני קטגוריות, לא כולן טכניות.

נתחיל מבחינה טכנית של הטמעה ושימוש: לשתי ההפצות יש התקנה מסודרת שיודעת לתמוך במגוון ציודים שיש בשרת, בין אם הן רצות "על הברזל" או על מכונה וירטואלית או כ-Image בסיס לקונטיינר. ב-99% מהמקרים לא תצטרך לחפש דרייברים נוספים (למעט כרטיסים של nVidia, אם כי SuSE מציעה פתרון שאינו מצריך חיפוש והורדה של דרייברים). אם כל מה שאתם עושים בלינוקס נמצא בתוך החבילות של ההפצה, אין שום בעיה לעבוד עם כל אחת מההפצות, והשינויים בין הפצה אחת לשניה אינם כה מהותיים. פה yum ושם zypper.

למרות זאת, עם כל האהבה שלי ל-CentOS/RHEL, ל-SuSE יש מספר יתרונות על רד-האט שחשוב לדעת עליהם, לדוגמא:

  • הפצת SLE מתקדמת יותר מההפצת לינוקס של רד-האט. יש שם Kernel חדש יותר, והכלים עצמם יותר מעודכנים ויותר מודרניים, כך שאם לדוגמא מתקינים Kubernetes, אז לא צריך לחפש אותם במאגר צד ג' כלשהו, מה שמגיע עם ההפצה זו הגירסה האחרונה היציבה, וכנ"ל שאר כלים נוספים כולל קומפיילרים וסביבות פיתוח יותר עדכניות.
  • הפצת SLE קלה יותר להגדרת דברים. ב-SLE יש כלים כמו yast2 שמאפשרים להגדיר הרבה דברים במערכת, החל מ-NFS, iSCSI, רשת ועוד ועוד מבלי לדעת איזה פרמטרים להכניס בקבצי ההגדרה.
  • ויש עוד דברים…

נמשיך מכאן להפצות עבור שימוש בכלים או פלטפורמות יחודיות להפצה. לדוגמא OpenShift במקרה של Red Hat, או SES במקרה של SuSE או OpenStack במקרה של שתי ההפצות: הגרסאות שההפצות מוציאות רצות אך ורק על הפצות הלינוקס מתוצרתיהן, כך שלדוגמא OpenShift לא ירוץ על SLE וגירסת ה-SES או OpenStack של SuSE לא ירוצו על מערכת של Red Hat (ניתן כמובן לעשות טריקים שכן ירוצו אך לא תקבלו לכך תמיכה רשמית). לכל אחת מההפצות יש שינויים ותוספים יחודיים לה (לדוגמא מערכת OpenAttic שנמצאת ב-SES), כך שבמקרים כאלו אם ארגון מסויים מעוניין במערכת של אחד היצרנים והפצת הלינוקס אינה ההפצה הרגילה של שאר מערכותיו, הוא יכול להתקין את את ההפצה והפלטפורמה כמעין "Appliance". הן מערכות RHEL והן מערכות SLE ניתנות להגדרה בקלות לניטור ולביצוע פעולות אחרות והן אינן מערכות סגורות.

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

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

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

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

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

הערה
הדברים הנכתבים כאן הינם דעתי האישית, אינני כותב מטעם Red Hat

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

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

קצת על קורסים ללינוקס

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

אבל לפני כן, הבה נסתכל על קורסים, לאו דווקא על לינוקס. יש לא מעט קורסים על מוצרי מיקרוסופט, אורקל, VMWare, ועל מוצרים רבים אחרים. המכנה המשותף של כולם – מה שאותם לומדים בכיתה ומתאמנים במחשבים בכיתה, מתאמנים במחשבים ובבית ובמה שתעבדו בחברה – המוצר יהיה זהה לחלוטין. ה-Windows Server שלמדתם עליו בקורס? אותו דבר בעבודה, אותם פקודות, ומה שלמדתם תוכלו ליישם מיידית עליו.

בלינוקס – זה שונה. ישנה חלוקה די ברורה של הפצות לינוקס: רד-האט ו-CentOS תמצאו בחברות, אובונטו יותר בסטארטאפים, SuSE מתחילה להיכנס יותר לארץ ו-Debian בד"כ אצל הוותיקים (כמו תמיד, מלחמות הפצה קיימות מכאן עד הודעה חדשה, אבל זה נושא לפוסט אחר). כך לדוגמא יכול להיות שתוכנה מסויימת בגירסה X קיימת כחבילות מוכנות להתקנה על אובונטו אך אותן חבילות לא ירוצו על הפצת לינוקס אחרת (ולמתחכמים: כן, קיים כלי בשם alien שממיר חבילות, אבל לא תמיד זה עובד וזה ממש לא משהו קל לשימוש למישהו שרק התחיל אתמול ללמוד לינוקס). פקודות התקנת חבילות הן שונות, בלא מעט מקרים גם קבצי ההגדרות לתוכנות פופולריות כמו Apache או NGINX נמצאות במיקומים שונים ובחלק קטן מהמקרים – גם ההגדרות עצמן שונות ואפילו התקנת הלינוקס שונה: כשמתקינים לדוגמא רד-האט או CentOS עם הגדרות ברירת המחדל, המערכת תפרמט את הדיסק לווליומים שונים כך שאם תרצה להוסיף מחר דיסק קשיח, תצטרך פשוט להגדיל את הווליום ולגמור עניין בשעה שחלק אחר מההפצות כלל לא טורח לעשות זאת וכשצריך להוסיף דיסק – צריך להעביר קבצים, ליצור קישור בין תיקיות ולבצע שלל פעולות אחרות.

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

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

ישנם קורסים online שניתן לרכוש ב-20-40$ של UDEMY ואחרים (והח"מ קנה מספר קורסים כאלו), רק שהבעיה איתם שאתה בעצם "מהמר" על הקורס. לפעמים קשה להבין מילולית את המדריך (במיוחד שהמדריך מהודו ותלוי כמה הוא עבד על המבטא האנגלי שלו), לפעמים ההסבר אינו מספק ואי אפשר ליצור קשר עם המדריך כדי שיסביר בקצרה על מה מדובר, ולפעמים ההסבר כלל לא מכוון כלפי רמת לימוד שהלומד נמצא בה. אני יכול לדוגמא להסביר במשך שעתיים על Linux Schedulers וההבדלים ביניהם אבל אם המאזין לא יודע מה זה processes, ההסבר הולך לפח.

עד לפני כמה חודשים היה לי קשה להמליץ על אתר מסוים ללימוד כי הרבה מאוד אתרים מכרו לימוד על לינוקס בצורה די "חפיפניקית". זכור לי מקרה בו רציתי קצת יותר להעמיק את הידע על MySQL ולקחתי קורס ב-lynda.com על הנושא וכל הקורס דיבר רק על CRUD (כלומר create, read, update, delete), שום דבר על אינדקסים, join, left,right, מנועי database וכו' או קורס Python שלקחתי מאתר אחר ורק לאחר התשלום הבנתי שהמדריך כלל לא מתכוון להתעכב על ההבדלים בין Python 2.7 ו-Python 3 ומעלה, דבר די בעייתי שאתה מנסה להבין קוד שמישהו אחר כתב ממזמן …

כיום אני ממליץ בחום על Linux Academy (ולמעוניינים הנה קוד referral – ה-7 ימים הראשונים בחינם והשאר בתשלום חודשי של 29.50$). ההבדל בינו לבין אתרים אחרים הוא שבכל מה שקשור ללינוקס, יש שם הדרכות רבות לא רק על לינוקס אלא גם על כלים לעבוד איתם בלינוקס, אוטומציה, שפות תכנות, MySQL, וכמובן – עבודה בעננים ציבוריים שונים. יש להם 4 יתרונות גדולים על פני אתרים אחרים:

  • מכירים את זה שאתם משלמים ושוכחים להיכנס וללמוד? כבר בהתחלת כל קורס תקבלו אפשרות לקבוע לכם לוח זמנים ללימוד (ימים ושעות) והמערכת תשלח לכם התראות לפני כן על מנת לתזכר אתכם להיכנס ולהמשיך ללמוד..
  • לא הבנתם משהו? לכל קורס יש פורום, יש flash cards שאחרים כתבו כך שתוכלו ללמוד ולהיזכר בסיוע אחרים בדיוק באותם דברים שאתם מתקשים.
  • אין לכם סביבת לינוקס או שאתם לומדים על דברים הקשורים לעננים ואין לכם תקציב חופשי לחשבון ענן? אל דאגה: אתם מקבלים עד 6 שרתים ללא תשלום נוסף לנסות את הדברים שאתם לומדים בקורס. תתקינו Putty ואתם מסודרים.
  • כשתיכנסו לאתר תוכלו לראות מצד שמאל למעלה ציורית של ענן כתום – זהו החלק של Cloud Assesment, זהו החלק שיכול לבדוק אם אתם מוכנים לבחינה בנושאי ענן שונים כמו Solution Architect וכו'. יש גם את האייקון השלישי משמאל שנקרא Scale Your Code והוא יותר מורכב מהרצאות של אחרים על דברים שהם עשו.

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

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

הבאג הקריטי במעבדי אינטל – עדכונים

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

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

בפעם שעברה דיברתי על הנחתה בביצועים בין 5 ל-30%, וכאן יש לעדכן: זה תלוי במעבדים בשרתים. מעבדים עד 5 שנים אחורה. מעבדים כמו Xeon E3/E5/E7 V3 ומעלה יש בתוכם פונקציונאליות שעוזרת למגר את הנחתת הביצועים כך שלא תהיה הנחתה משמעותית בביצועים, אולי אחוזים בודדים.

במעבדים היותר ישנים (שרתים כמו DELL דור 11 ומטה, HPE דור 7 ומטה, לנובו/IBM דור M3 ומטה) עדיין יורגשו הנחתות בביצועים במקרים מסויימים. המקרה הכי נפוץ שמצאתי הוא שכשמריצים שרתים כאלו כ-Hypervisor (כמו Hyper-V או ESXi) ומריצים את המכונות דרך Datastore שעובד על דיסקים מקומיים. מכיוון שלשרתים אלו אין אפשרות להיות משודרגים למעבדים מדור 3 ו-4 (טוב, למעט SuperMicro ששם אתה יכול להחליף לוח אם, בנוסף למעבדים, ובנוסף גם זכרון..) – האפשרויות שישנם הינן:

  • להקים מכונת VM שמחוברת לבקר דיסקים ולהריץ עליה מערכת שרות קבצים NFS/iSCSI.
  • להקים פתרון כמו שתיארתי לעיל אבל בתצורה פיזית.
  • לקנות פתרון סטורג' כלשהו.

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

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

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

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

לסיכום: מכיוון שרוב החברות הגדולות כבר לא מחזיקות בשרתים ישנים – אז הבעיה אינה כל כך חמורה בכל הקשור ל-Meltdown. בנוגע ל-Spectre בגירסה הראשונה, העדכון לא מוריד ביצועים (והתיקונים לגירסה השניה יעשו הן ע"י יצרניות מערכות הפעלה והן ע"י יצרניות אפליקציות). עדיין נשארו בעיות בכל הקשור ל-Spectre על טלפונים מבוססי אנדרואיד ועדכונים יצאו ע"י יצרני הטלפונים (ואם יש לכם מכשירים ישנים, אולי כדאי להחליף להם ROM למשהו כמו LineageOS). מבחינת ספקי ענן – כולם משתמשים בציוד די חדיש וכולם מעדכנים את כל השרתים שלהם, יכול להיות שתקבלו הודעה מנומסת מהן לעשות Reboot ל-Instances שלכם. מבחינת מחשבי Desktop, לאפטופים – ההנחתה בביצועים כמעט ולא קיימת. מה שהכי חשוב – יש לעדכן את כל השרתים ולבצע לאחר מכן Reboot לאותם שרתים.

כשענק כמו גוגל מתחרה ב-Docker

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

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

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

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

אבל מה קורה שחברה די קטנה נתקלת בענק שיכול למחוץ אותה בקלות? אני מדבר על חברת Docker מול חברה שאולי שמעתם עליה .. גוגל.

ל-Docker יש מספר מוצרים. את המוצר החופשי Docker להרצת קונטיינרים – כולם שמעו עליו, וזהו כלי מעולה להרים קונטיינרים אבל הכלי לא מספק שום דבר בכל מה שקשור להרצת מספר קונטיינרים, תקשורת ביניהם, ניהול וניטור מרוכז, שרידות, Load Balancing וכו'. בשביל זה תצטרך לשלם על גירסת ה-Docker Enterprise שקיימת ב-3 גרסאות (אפשר לקרוא על כך כאן).

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

מאז יצאו מספר תוכנות שעושות מה ש-Kubernetes עושה פחות או יותר – כמו DC/OS, Apache Mesos ועוד. במקביל יצאו מוצרים מסחריים (וחלקם חופשיים) ש"עטפו" את Kubernetes כך שאפשר למכור זאת לחברות יחד עם שרותי תמיכה מסביב לשעון, וגם Docker יצאה עם פתרון ה-Enterprise שלה.

העניין הוא ש-Kubernetes כבש את השוק. מדוע זה משנה? אם נחשוב על אנשי ה-Devops והמפתחים בחברה שנתקלים בתקלה, הסיכוי שהם ימצאו פתרון עם Kubernetes הוא הרבה יותר גבוה מאשר פתרונות אחרים שאינם מבוססים Kubernetes. נהיה יותר פרקטיים: חברתכם מחפשת 2-3 מפתחים שיעבדו עם קונטיינרים. אם תשאל לגבי הידע שלהם ב-Kubernetes, אתה תמצא שיש הרבה יותר אנשים עם הידע הנ"ל מאשר עם Apache Mesos, DC/OS או עם הפתרון המסחרי של Docker. מפתחים ואנשי מקצוע אחרים לומדים בעצמם דברים שהם פופולריים, ופחות דברים שלא נמצאים בשימוש רב.

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

לכן אני ממליץ לחברות לא להמר על הסוס הלא נכון. עוברים לקונטיינרים? קחו פתרונות פופולריים – בין אם זה Kubernetes עצמו או מוצר ש"עוטף" את Kubernetes ומשתמש במנוע עצמו. זה יכול להיות מוצר כמו של חברת SuSE (ה-CAAS שלהם), זה יכול להיות OpenShift של רד-האט, זה יכול להיות Rancher ויש עוד מספר פתרונות. אלו פתרונות שמתעדכנים ככל שגירסת Kubernetes מתפתחת, ולכם כחברה יהיה יותר קל בהטמעת פתרונות מבוססי קונטיינרים.

פתרון GlusterFS – היכן הוא מתאים לכם?

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

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

נתחיל בהצהרה די פשוטה: למרות שטכנית ניתן לבנות את GlusterFS כפתרון שיכול לתת "פייט" רציני לכל פתרון אחסון Scale Up מסחרי, לא תמצאו אותי מחר אץ רץ לחברות תקשורת, בנקים וכו' וממליץ להם בחום לזרוק את פתרון האחסון שלהם לטובת GlusterFS, בדיוק כמו שפתרון VSAN של VMWare אינו פתרון להחליף סטורג' רציני עתיר משאבים. אלו 2 דברים שונים לחלוטין.

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

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

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

סיטואציה ראשונה
כאחד שנותן שרותי תמיכה ל-vSphere לגרסאותיו השונות, יש לי מילים חמות לאמר על VSAN. זהו פתרון אמין מאוד עם שרידות גבוהה מאוד ללא צורך בסטורג'. עם VSAN אפשר להגדיר פונקציות שונות כמו פונקציית שרידות מאוד גבוהה כך שמתוך קבוצה של 3 שרתים פיזיים, 2 נכבים, אפשר להגדיר ש-VM קריטי עדיין ישרוד.
הבעיה המרכזית עם VSAN אינה טכנית, אלא בעיה כספית. במחיר של $2500 לרשיון פר מעבד, על קבוצה של 3 שרתים פיזיים, אנחנו מדברים על 15,000$ וזה לא כולל את הרשיון היעודי של vSphere ולא כולל תמיכה של 3 שנים (שזה עוד 15,000$) ועוד לא הגענו בכלל למחירי הדיסקים – במיוחד שעם VSAN חובה ללכת בתצורת קבוצות של 2+1 (כלומר 2 דיסקים מכניים ו-1 SSD אם כי אפשר ללכת בתצורה היותר יקרה של 3 SSD ונוסיף לכך שאתה צריך שרתים מהדור האחרון או לפניו כדי להריץ את כל הדברים. מחיר כזה, לדעתי, אינו מוצדק עבור Dev, stage, testing, POC וכו'. במחיר כזה חברות כבר יחשבו על קניית אחסון יעודי.

במקום זה, אנחנו יכולים לקחת 3 מכונות שדווקא אינן חדשות (כל עוד בקר הדיסקים שלהם תומך ב-6 ג'יגהביט SATA/SAS, אם זה תומך רק ב-SATA 2.0, אז אפשר להכניס כרטיס בקר צד ג') כמו דור 7 של HP, דור 11 של DELL, דור 3 של LENOVO, ולמלא אותן בדיסקים. ניקח דוגמא: 10 דיסקים SATA של WD RED PRO (מחיר של 319$ באמזון פר דיסק, המחיר קצת יותר יקר אצל המפיץ בארץ) או WD GOLD Enterprise בגודל 10 טרה שעולה $361 פר דיסק, או Seagate מסידרת EXOS ל-Enterprise בגודל 10 טרהבייט שגם עולה $360. סה"כ עד כה – בערך $3600 (פר שרת). נוסיף עוד 2 דיסקים SSD – אם מחפשים זול וטוב, אז 2 דיסקים מה-850 PRO של סמסונג יוכלים לעבוד טוב (סה"כ 418$)ואם המכונה היא 2U, אז 2 כרטיסי SSD PCIE מסוג אינטל 900P 280GB AIC בתצורת PCIE (סה"כ 780$) יכולים לתת Cache די רציני למכונה.

ניקח את הבקר (ואת כרטיסי ה-PCIE) ונצמיד את כולם למכונת VM, נצמיד לה 32 ג'יגהבייט זכרון ו-4 ליבות, ועליה נרים GlusterFS (אם אתם מעוניינים בדחיסה, Dedup ושאר תפנוקים – יש צורך להקים עליה ZFS ועל זה GlusterFS), נחבר את המכונות ברשת פרטית וברשת "ציבורית") (כלומר 2 כרטיסי רשת וירטואלית פר VM של GlusterFS) והרי לנו תחליף ל-VSAN שיכול לתת לנו iSCSI, CIFS, NFS, אחסון אובייקטים (Object Storage) ועוד ועוד. בשביל ביצועים ושרידות נצטרך עוד מכונה כזו (עדיף עוד 2) – ויש לנו אחסון עם שרידות חזקה וביצועים גבוהים, ובו זמנית אפשר להריץ על השרתים עוד מכונות VM, ואת כל זה נעשה דרך ה-vSphere, כך שמבחינת עלות – שילמנו רק על החומרה ולא הפכנו את השרתים היעודיים לסטורג' בלבד (כך שלא נצטרך לבזבז שרתים). מבחינת גיבוי – זה VM ואפשר לגבות בכל תוכנה שמשתמשים בחברה (רק שחשוב לזכור לא לגבות את כל ה-VM שמריצים GlusterFS אלא רק אחד, חבל לשמור את הנתונים באותו גיבוי 3 פעמים).

סיטואציה שניה – אפליקציות
קונטיינרים הם ה"שוס" בשנתיים האחרונות ורבים מעבירים חלק מהמערכות לרוץ בקונטיינרים, שזה מעולה, אבל בחלק מהמקרים עדיין מעדיפים להריץ אפליקציות מסויימות בהכפלה וכו', לדוגמא MySQL על 2-3 מכונות VM, שרתי Front ו-Back על מספר מכונות VM ועוד. בכל המקרים הללו, באותם שרתים ניתן להקים GlusterFS כ-VM כמו שתיארתי לעיל (עם פחות דיסקים, רק חשוב שיהיה לפחות SSD אחד שישמש כ-Cache) ואז ה-DATA של האפליקציה (לדוגמא עם MySQL התיקיה var/lib/mysql/) תשב ב-GlusterFS (איך עושים? עוקבים אחרי ההוראות כאן), ה-WWW של שרת ה-Web ישב ב-GlusterFS וכו' וכו'. יהיו מספר שינויים קטנים שצריך לבצע (אולי להשתמש ב-HAProxy), וכך נוכל לקבל שרידות רצינית ומהירות משופרת בהרבה מכיוון שכל שרת אפליקציות יכול לקבל נתונים משרת GlusterFS קרוב וסינכרון הנתונים הוא מיידי – מבלי להשקיע כספים רבים.

סיטואציה שלישית – קונטיינרים/Kubernetes/Openshift
קונטיינרים רצים בד"כ על שרתי VM וקבצי ה-YAML, קבצי קונפיגורציות יושבים על דיסקים מקומיים אך ניתן להגדיר את ה-VM שירוצו על דיסקים וירטואליים שה-vSphere יקבל מ-GlusterFS דרך NFS או iSCSI. בנוסף, ניתן להגדיר Volumes עבור ה-Pods שישתמשו ב-GlusterFS (גם Kubernetes וגם אפליקציות שמריצות את Kubernetes כמנוע כמו Rancher, OpenShift וכו' תומכים ב-GlusterFS החל מ-Kubernetes 1.5). ואנחנו יכולים להשתמש לדוגמא ב-Volume מסויים במספר Pods במקביל, ועם GlusterFS ניתן לוותר על הרצת קבצי YAML/JSON ליצור את ה-Volumes ולגשת ישר ל-Volume Claim, המערכת תיצור את ה-Volume אוטומטית.

סיטואציה רביעית – בענן
מכיוון של-GlusterFS לא אכפת מה נמצא מתחתיו (דיסק מסכן, EBS וכו'), אפשר להקים את GlusterFS גם בענן. כל מה שאנחנו נצטרך הם מספר Instances (מומלץ 3 ומעלה לפרודקשן, 2 לטסטים) ולאותם Instances (שישמשו כ-Nodes) נחבר 2-3 אחסוני EBS ונתקין את GlusterFS ומשם אנחנו יכולים להשתמש ב-GlusterFS כפתרון אחסון לצרכים שלנו.

סיטואציה חמישית – קרוב רחוק
הקמה של GlusterFS זה דבר טוב ועוזר, אולם לפעמים אנחנו צריכים את הנתונים בחוץ, בחוות שרתים אחרת בארץ או בחו"ל. לשם כך, החל מ-GlusterFS 3.8 ומעלה ניתן להריץ Geo Replication לסנכרן בין מספר Volumes (בשיטת Master/Slave), ואפשר גם לספק צרכים "מופרעים" כאלו:

סיטואציה 6 – פתרון אחסון ל-VDI
הקמת VDI למאות עובדים זה פרויקט מורכב עם עלויות אסטרונומיות. (בימים אלו אני מנסה בבית להקים פתרון VDI עם דגש על מחירים נמוכים, ברגע שאצליח, אפרסם פוסט על כך). יש צורך לשלם למיקרוסופט, ל-VMWare וכמובן כל נציג מכירות יאמר לך – All Flash Array, כך שאם תרצה פתרון VDI טוב, תחשוב על כך סכום של 7 ספרות.

האם GlusterFS יכול לחסוך כאן במחיר? התשובה היא בהחלט. נתחיל בגירסה הזולה: זוכרים שהמלצתי על השרתים הישנים להרצת GlusterFS? אנחנו נשתמש בכאלו בגודל 2U עם פאנל קידמי של כונני 2.5 אינטש כך שאפשר יהיה להכניס בין 16 ל-24 דיסקים 2.5". לתוכם נכניס דיסקים 850 PRO של סמסונג בגודל שתבחרו, יש עד 2 טרהבייט (יש לוודא שהבקר דיסקים תומך במצב JBOD ושהוא תומך ב-SATA-3, אם לא – יש צורך בבקר אחר) ונכניס את הדיסקים הנ"ל למגירות ונצטרך לרכוש או אינטל 900P בגודל 480 ג'יגה או 2 כרטיסי אינטל 900P בגודל 280 ג'יגה, הכל לפי התקציב (עם 2 כרטיסים השרידות הרבה יותר גבוהה). על כל שרת כזה נקים ZFS עם Hot Spare ל-2 דיסקים SSD. כל ה-RAID יוגדר דרך ה-ZFS (כלומר RAIDZ לפי תצורה שמחליטים) ועל זה נקים את GlusterFS. את החיבור בין השרתים נחבר ב-10 ג'יגהביט (נחושת, SFF, FC – החלטה שלכם) ואת הזכרון נמלא ב-ECC 3 8500R (שהוא פחות מהיר אבל המהירות אינה ממש חשובה כשהשרת משמש Node ל-Gluster, הזכרון משמש בראש וראשונה כ-Cache ב-ZFS) עד המקסימום. המחיר לא כזה יקר: 2000 שקל (תלוי מהיכן אתם קונים) ל-192 ג'יגהבייט זכרון. נצטרך 3 מכונות. שימו לב: בשרת כזה נרוץ "על הברזל" ללא וירטואליזציה כלל ונוכל לגבות אותו כמו כל תחנת לינוקס (אם כי צריך לגבות רק אחד מהם, לא את שלושתם).

אם יש לכם כמה וכמה שרתים ישנים, אפשר לפצל את כמות הדיסקים לפי כמות השרתים הישנים שלכם (לדוגמא – 6 דיסקים בשרת 1U) ובכך לקבל ביצועים יותר גבוהים הואיל ולא מדובר בסיטואציית Active/Passive אלא עבודת קריאה/כתיבה מקבילית לכל המכונות.

אם מצד שני יש תקציב – אפשר לרכוש 3 שרתים כשהפאנל הקדמי שלהם הוא NVME ונרכוש דיסקים NVME U.2 – גם סמסונג וגם אינטל מוכרים דיסקים מעולים, והעלות משתנה לפי גודל הדיסק והפירמה שקונים ממנה. מבחינת רשת, תצטרכו לחשוב איך לחבר את הכל מכיוון שברוטו, תעבורת הקריאה מגיעה בין 40-60 ג'יגהבייט לשניה. אפשרי לצמד מס' כרטיסי רשת 10 ג'יגהביט או לרכוש כרטיסים ו-Switch של 40 ג'יגהביט (מלאנוקס, אינטל וכו' ישמחו למכור לכם). עם ההצעה הזו, המחיר שתצטרכו לשלם בהשוואה לפתרון אחסון מבוסס AFA (כלומר All Flash Array) יהיה נמוך יותר ב-50-70% מפתרון קופסא, וגם יש לכם שרידות יותר גבוהה.

בכל שאר הפרמטרים (וירטואליזציה, רשיונות וכו') – הכל נשאר אותו דבר.

ומה עם תמיכה? רד האט מוכרת את פתרון ה-GlusterFS כמוצר (Red Hat Gluster Storage) עם תמיכה מסביב לשעון.

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

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