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

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

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

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

אני רוצה לתת דוגמא מעולם ה-appliance שאני בונה ללקוחות לפעמים. לקוח פוטנציאלי פונה אליי, מציין שהם מפתחים תוכנה XYZ והם מעוניינים שאפתח להם פתרון "סגור" – כלומר קופסא (או Image, או שניהם) שיריצו את התוכנה, שהפתרון שלי יכלול הפצת לינוקס מינימלית כולל כל מה שהם צריכים, סקריפטים לעדכון (אוטומטי או ידני), ותמיכה מלאה בכל הפונקציונאליות של הקופסא (מספר חיבורי רשת, SNMP וכו').

בדרך כלל ההסכם שלי מול חברות כאלו הוא פשוט:

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

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

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

הבעיות של היום ומחר – עם פתרונות של אתמול ושלשום

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

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

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

  • ההמלצות טובות ונכונות (אם יהיו לי הערות או נקודות מסויימות – אציין אותן)
  • הרעיון העקרוני בהמלצות נכון, אבל מומלץ לשלב פלטפורמות X,Y וטכנולוגיות A,B.
  • אתם שילמתם על היעוץ הזה? ברצינות? אתם נמצאים בשנות ה-90 או ה-2000 או מה?

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

להלן שתי דוגמאות, מהחודשים האחרונים:

  • חברה מסויימת רצתה להריץ פלטפורמה מסויימת על לינוקס מספר רב של פעמים. המערכת אמורה להיות פתוחה לרשת וההפניות יועברו דרך Load Balancer (אני לא יכול לפרט עקב הסכמי סודיות). היעוץ שהם קיבלו: לרכוש 18 שרתים עם מפרט די "כבד", רכישה של Load Balancer חומרתי, סטורג' מפלצתי, לכל הברזלים רשיון VMWare Enterprise.
    ההצעה שלי (שהתקבלה): במקום 18 שרתים עם מפרט כבד, 2 שרתים עם מפרט נמוך, 4 שרתים עם מפרט כבד (יחסית, הרבה זכרון), מערכת OpenShift, ושרת נוסף קטן שיריץ ESXI כדי להריץ 2 מכונות VM שמריצות Windows. סטורג' – או בניה או לרכוש משהו קטן מכיוון שאין צורך ב-IOPS רציני או כמות אחסון גדולה. הפלטפורמה תרוץ כולה על קונטיינרים, ובהתבסס על הסטטיסטיקה שנמסרה לי, אני מתקשה להאמין שתהיה צריכת משאבים של יותר מ-40% בכל השרתים.
  • חברת מדיה מסויימת רצתה לאחסן תכנים רבים ולהערכתם הם יגדלו בכל שנה בסביבות ה-100-150 טרהבייט. הדרישה – אפשרות גדילה ללא SPOF (כלומר: Single Point of Failure) ומבלי לרדת בכמות רוחב הפס הפנימי, אדרבא – אם אפשר שתהיה גדולה יותר ויותר – הם ישמחו. כאן לא היתה חברה מסויימת שנתנה יעוץ, אלא החברה ביקשה מכל מפיצי הסטורג'ים הגדולים והמוכרים בארץ, ואני התבקשתי להמליץ על אחת מההצעות.
    הבעיה: אף הצעה לא כללה פתרון אחסון Scale Out. כל ההצעות היו פחות או יותר "תוסיף מדף" ובקשר לשרידות – קנה שתי ראשים. לפיכך המלצתי הפשוטה (שהתקבלה) היתה: זרקו את ההצעות ובקשו או פתרון Scale Out או לבנות פתרון Scale Out מבוסס קוד פתוח או תוכנה סגורה שמציעות יצרני שרתים וחברות אחרות, ורשת עם Backbone של 40 ג'יגהביט שיגדלו בהמשך לכיוון ה-100 ג'יגהביט.

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

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

ה"פקקים" בדרך לביצוע פרויקטים

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

אתן דוגמא (בלי שמות): לפני שנתיים בערך, הוזמנתי ע"י חברת סטארט-אפ שעסקה בתחום טרנדי מסוים – לבוא ולתת שרותי אינטגרציה ב-OS. הסטארט אפ היה מאוד ידוע, הושקעו בו מאות מיליוני דולרים, כך שעבודה איתם יכלה להניב עבודות נוספות מבחינה פוטנציאלית בתחומים שאני יכול לסייע. מה רע? הוזמנתי לראיון הראשוני. מהטלפון עד זימון הראיון עברו בערך חודשיים. נו, אולי האנשים סופר עסוקים, לך תדע. הגעתי לראיון, היתה כימיה טובה, וכבר למחרת נמסר לי כי התקבלתי. מעולה, רק שמאז עברה חצי שנה עד שסוף סוף קיבלתי את ה-NDA והחוזה לחתימה (חתיכת חוזה, אם אני זוכר נכון, בסביבות 120 עמודים!) וכשסוף סוף הוזמנתי להתחיל לעבוד (עניין של עוד חודשיים וחצי) – חשכו עיניי. המוצר היה אמור לצאת בעוד חצי שנה, ורק 30% מהמוצר מוכן! הסטטוה הזה הפליא אותי הואיל ואני מכיר חלק מצוות הפיתוח והוא ממש לא איטי – כשהייתי צריך מהם דברים מסוימים, זה בוצע תוך דקות ספורות, אבל כל שאר החלקים בפרויקט – זוחלים בקצב צב.

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

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

האידיליה הזו במקרים רבים נשברת על ידי צוותי הנהלה. לי כמובן אין שום דבר נגד צוותי ניהול, אך הבעיה המהותית שמתרחשת זה שדברים שמצריכים החלטה עוברים לדרג ניהולי, וחלק מאותם מנהלים מוסיף לעצמו עוד ועוד דברים וכתוצאה מכך – החלטות מתקבלות לאט (ידידנו האמריקאיים מומחים בכך, תאמינו לי. הם אלו שהמציאו את ה-Project Manager, Product Manager, Director ושלל תארים נוספים) וכך מתרחשים לדוגמא השהיות: נניח ואני צריך עוד שלוש שרתים כדי לבצע עבודה. שום איש IT לא יכול לאשר רכישות כאלו, אז זה צריך לטפס למנמ"ר, ל-CTO, ל-CFO ולמנכ"ל. מכיוון שלכל אחד מהם יש "בצלחת" דברים רבים שהוא צריך לעקוב/להחליט לגביהם, הזמן שיקח עד שיגיעו שרתים – נמדד בחודשים, ועד אז אותו חלק שאני צריך לבצע – מוקפא, מה שאומר שאותו פרויקט יתארך ויהיה צורך לשלם יותר לעובדים החיצוניים.

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

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

יש לכם שרתים/סטורג' של HPE עם SAS SSD? מומלץ לקרוא

חברת HPE הוציאו לאחרונה עדכון דחוף לקושחות עבור מספר דיסקים SSD בחיבור SAS שנמצאים על מגוון הציוד ש-HPE מוכרת: שרתים (Proliant, Apollo), ועבור פתרוות אחסון: (JBOD D3xxx, D6xxx, D8xxx, MSA, StoreVirtual 4335,StoreVirtual 3200). דגמי הדיסקים וכל ההערות ולינקים לאפליקציות תיקון מופיעים במסמך ש-HPE פרסמה.

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

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

עקב באג בקושחת הבקר על דיסק ה-SSD, לאחר 32,768 שעות (כלומר 3 שנים, 270 יום, ו-8 שעות) כל הנתונים על דיסק ה-SSD יעלמו. זה לא "אם", לא "אולי", זה ודאי. מישהו כתב קוד די דבילי וזו התוצאה. התיקון עצמו משכתב קושחה חדשה לכונן ה-SSD ועל מנת שהקוד יפעל, יש צורך ב-Reboot למערכת (HPE כותבים שאין צורך לעשות Reboot, מהיכרות קודמת עם בקרי ה-Smart של HPE, אני ממליץ דווקא כן לעשות Reboot). התיקון הזה ימנע את ה-Time Bomb לכונני ה-SSD הנ"ל.

עכשיו הגירסה היותר "גיקית" לאנשים שצריכים לטפל בדברים. הדברים שאני כותב רלוונטיים למערכות VMWare ESXi ולהפצות לינוקס השונות (כרגע, רשמית, בלינוקס ההפצות הנתמכות הן RedHat, CentOS, SuSE, אם אתם עם אובונטו או דביאן, תצטרכו קצת להכיר את rpm2cpio).

מבחינה טכנית, לאחר הזמן הנ"ל (3 שנים, 270 יום, 8 שעות), מה שיקרה הוא שהמפות שהבקר משתמש בהם כדי לדעת היכן כל דבר מאוחסן, אלו תאים (Cells) דפוקים, אופטימיזציה וכו' – ימחקו. ה-DATA עדיין נשאר על שבבי ה-Flash, אבל בלי המפות אי אפשר לעשות כלום, אין כאן לצערי תהליך Rebuild שאפשר לעשות (טכנית, זה אפשרי, אם מלחימים JTAG ל-SSD ו"מדברים" ישירות עם הבקר SSD, אבל אז צריך להכיר את הבקר, פקודות, אסמבלר של ARM וכו' – והידע הזה לא קיים ציבורית).

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

  • בלינוקס קיים זמן רב שרות מובנה של עדכון קושחה מבלי שתצטרך לבדוק/לנחש איזה חומרה יש לך בתוך השרת. כל מה שצריך זה להתקין את חבילת fwupd מהפצת הלינוקס שלך, להריץ (כ-root) פקודה fwupdmgr get-updates ואת הפקודה fwupdmgr update והמערכת תוריד אוטומטית את הקושחות הרלוונטיות לשרת/מחשב שלך. כשתבצע Reboot הוא יפעיל אפליקציה דרך ה-UEFI שמעדכנת את הקושחות שצריך, וכשזה מסתיים, המערכת תבצע אוטומטית reboot ובכך העניין טופל. הבעיה? ב-HPE בקושי שולחים עדכוני קושחה לשרות הזה.
  • HPE מוציאים שני עדכונים שונים שמיועדים ל-SSD שונים. HPE כבר הוציאו אפליקציה בלינוקס מאוד ותיקה שיכולה לתשאל את בקר ה-SMART (היא נקראת: hpacucli) אלו דיסקים יש ובכך להשוות דגמים ולהתקין את הקושחה, אבל לא, הצורה שהם כתבו את סקריפט העדכונים תגרום לאנשי לינוקס ותיקים לרענן את קטלוג הקללות שלהם.

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

  • הראשונה – לתשאל את הבקר, וזה במקרה אם אתה מריץ לינוקס פיזית על השרת, פקודה כמו hpacucli ctrl slot=0 pd all show תציג לך את הדיסקים, דגם, מספר סידורי וכו', כאן grep ו-awk יכולים לעזור לך לעשות סדר ולמצוא את הנתונים.
  • השניה – לבצע reboot לשרת ולהיכנס לתפריט ה-SMART. שם מופיעים לך דגמי הדיסקים.
  • השלישית, קצת פחות מומלצת – ללכת לשרת, להוציא דיסק SSD החוצה ולהשוות את הדגם.

אם יש לך דיסקים שנכללים בעדכון, תצטרך לבחור להוריד את הסקריפט הרלוונטי, לעקוב אחרי ההוראות ולשלוח את העדכונים שיעברו דרך ה-SMART ישירות לבקר ה-SSD ויעדכנו אותו. האפשרות האחרת שיש זה להוריד SPP, להוריד את החבילות, לשים באיזו מכונת Windows או לזרוק הכל לדיסק און קי (לשים את החבילות תחת תיקיית packages/ ) ולהשתמש ב-SUM. זה כמובן אומר שתצטרך להשבית את המכונה עד שתעדכן את הקושחות באותם דיסקים.

חשוב לזכור: תהליך עדכון קושחת בקר SSD מבצע Reboot לאותו דיסק SSD (לא לשרת), ולכן יכולים "לקפוץ" לכם התראות על בעייתיות באותו דיסק SSD, עד שהמערכת "מבינה" שהדיסק תקין, קחו זאת בחשבון לפני שאתם נזעקים ממערכת ההתראות שלכם, ובגלל זה אני ממליץ במקרים שמדובר בשרת שמריץ ESXi לעשות את העדכונים לאחר שהעפתם ממנו (עם live migrate) את כל מכונות ה-VM ולאחר ה-Reboot לתת ל-DRS להזיז מכונות VM לשרת המעודכן (אם אין DRS, תזיזו ידנית).

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

קצת על Scale Out עם פלטפורמות יעודיות

בשנים האחרונות אנחנו עדים ליותר ויותר פלטפורמות שעובדות בשיטות של Scale Out. הפלטפורמה הכי ידועה לדברים כאלו היא כמובן Kubernetes, אך כמובן שישנן פלטפורמות אחרות שקשורות יותר לעיבוד נתונים – Kafka או Cassandra לדוגמא, כל אחת מהן פלטפורמה לצרכים שונים, אבל מבחינת צרכי חומרה, הצרכים הם פחות או יותר זהים: מעבדים בינוניים (לא צריך כמות מפוצצת של ליבות, יספיקו 8-16), ולא צריך דיסקים (קשיחים או SSD) יקרים.

כלומר – אם אתה צריך להריץ פלטפורמה שעובדת ב-Scale Out מקומית בתשתית שלך, אל תנסה לחפש את היוקרתי עם כל מילות הבאז האחרונות, אלא ההיפך – מי הספק שיכול לתת לך את ההצעה הכי זולה שתעמוד במפרט שנקבע מראש, SLA שאתה צריך וכו'. ב-Scale Out אין את מושגי השרידות מעולם ה-Scale Up. אין Heart beat, אין Active/Passive, Active/Active וכו'. עם Scale Out בדרך כלל הפלטפורמה תהיה בנויה כך שאם שרת למטה/אינו זמין/אינו פעיל, המערכת תאזן את עצמה אוטומטית (למי שמשתמש ב-Kubernetes ורוצה לראות זאת – תורידו Node ותראו איך זה עובד).

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

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

אחת השגיאות שאפשר לראות בפורומים שונים, זה שאנשים שעובדים עם פתרונות Scale Out מחפשים איך לאחסן את כמות הנתונים שהולכת וגודלת והם עדיין לא מכירים/מבינים את עניין ההוספה המתמדת של ברזלים ודיסקים מקומיים – והם תמיד יקבלו את הצעות הפתרונות שמתאימים ל-Scale Up: לתכנן את הגדילה למשך שנה וכו' וכו' ואז לבחור סטורג'. זו טעות, כי בעולם המדידות/דגימות ושימוש בפלטפורמות Scale Out אתה מחפש לקבל כמה שיותר מידע, לא כמה שפחות, ויכול להיות שהחודש הקרוב אתה תוסיף עוד 4 טרה מידע לחודש אבל בעוד 3 חודשים זה יקפוץ ל-15 טרה לחודש. בגדלים כאלו, שום פתרון סטורג' קנייני אינו מתאים, אלא אם רוצים "לשרוף" את תקציב החברה, ולכן יש צורך ללכת לפי הפתרון של הפלטפורמה, לא לפי שם/דגם של סטורג'.

ולכן:

  • אם הולכים להשתמש בפלטפורמה שהיא בראש ובראשונה Scale Out לצרכי עיבוד נתונים/קליטת נתונים – נצטרך דיסקים ושרת מהקצה הנמוך-בינוני, מבלי להשקיע יותר מדי כספים פר ברזל (קחו דיסקים בסיסיים, בפוסט קרוב אסביר לגבי הגדרות אחסון מקומי למערכות כמו Kafka ו-Cassandra), (אגב, אם אתם רוצים להריץ Kafka בענן, אמזון לדוגמא שמחה להציע לכם את MSK).
  • אם אנחנו רוצים לשמור כמות גדולה מאוד של מידע לאחר עיבוד או ארכיבאי כשהכמות גודלת כל הזמן, או שאנחנו צריכים Object Storage – פתרון אחסון Scale Out (כמו Gluster) יתאים יותר לשימושים הללו מכיוון שעלות הגדילה היא זולה, והביצועים גודלים ככל שמוסיפים ברזלים לאותו אחסון.

לסיכום: בעולם ה-Enterprise, הסטורג' הקנייני היה ה-דבר הכי חשוב וקריטי. אין סטורג', שום דבר לא פועל. מאז הגיעו ספקי הענן הציבורי הגדולים שהכריזו שאצלם אין ולא יהיה שום סטורג' מרכזי, ובמקביל התפתחו יותר ויותר פלטפורמות שמחזירות את השימוש בדיסקים מקומיים ומאפשרות לבנות אחסון מדיסקים זולים וממשאבים צנועים, וזהו בדיוק החלק שבמחלקות ה-IT או ה-CIO/CTO צריכים להבין: אל תנסו לכפות פתרון Scale Up על פתרון Scale Out.

קצת לפני שמכריזים על זוכה במכרז

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

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

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

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

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

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

  • לא לרכוש את השרות כ-SAAS (שימו לב: אני לא מדבר על מחיר). כשספק ענן ציבורי מציע שרות כ-SAAS, אתם יודעים שאותו ספק יהיה קיים ב-3-5 השנים הקרובות ולכן שרותי ענן שונים בתצורת SAAS אין בעיה לשכור אותם, אולם כשחברה בונה לך פתרון ומנגישה לך אותו כ-SAAS, אותה משרד/חברה מכניסה את עצמה למצב של "בת ערובה" אם בהמשך אין הסכמה על מחירים, או אם המשרד/גוף לא מרוצים מהביצועים, לדוגמא.
    אני רוצה לסייג: אם אתם צריכים לרכוש Firewall או כל אפליקציה שכוללת OS לינוקסאי דרך ה-Market של ספק הענן זה בסדר, אבל אם זה משהו שמפותח עבורכם – בקשו שיתקינו את הדברים על התשתית הוירטואלית שלכם, מקומית או בחשבון ענן שלכם.
  • על מה זה רץ? ברוב המקרים כיום הפיתוח של פתרון עבורכם יבוצע תוך שימוש בפלטרפורמה כזו או אחרת. חשוב מאוד לבדוק איזו פלטפורמה ואיזו גירסה, האם יש בה שימוש כיום, האם יש קליפים או עדויות לגבי אותה פלטפורמה? מתי עדכנו אותה לאחרונה? הדבר האחרון שאתם רוצים זה שספק מציע ישתמש במשהו ישן שכבר כמעט מת – בשביל לבנות עבורכם את מה שהנכם מבקשים.
  • חישובי ענן ציבורי. אם השרות שאתם רוצים צריך לרוץ על ספק ענן ציבורי, עדיף שהחברה/גוף המבקש הצעות יבקש הקמה על התשתית בחשבון הענן שלו ועדיף לבדוק היטב מה יש בסעיפי התמיכה. כך לדוגמא, רבים כשעוברים לענן מחפשים לקחת את שרותי התמיכה היקרים ביותר (24/7 פלטינום או כל שם אחר) מבלי להבין שבמקרה ויש תקלה והיא קיימת לא רק בחשבון החברה אלא גם אצל אחרים – לא תקבלו שרות יותר מהיר ותצטרכו לחכות לפתרון התקלה כמו כולם.
  • אם כבר מדברים על חישובי ענן ציבורי: שרותים. ספקי ענן ציבורי מציעים שרותים שונים שהם אבולוציוניים, כלומר – בהתחלה הוצעה שרות בשם X, לאחר זמן מה הוצע שרות Y שהוא בעצם "אבולוציה" של שרות X וכו'. במקרים רבים יש גם הפרשי מחיר ניכרים בין השרותים וגם הבדלי ביצועים רציניים, אך הבעיה היא שמציעים גדולים לא ממש טורחים (לא ממש באשמתם כש-AWS מציעים כמעט כל יום שרותים חדשים) להכיר את השרותים השונים ולכן כדאי לראות מה יש בהצעה ולהחליף בשרותים מודרניים יותר או במקרים מסוימים אם יש את הידע – להקים את הדברים עצמאית בתשתית הענן.
  • גישה לקוד מקור ותיעודו: כיום כשמפתחים לענן ציבורי ומשתמשים בפלטפורמות/ספריות שונות, ברוב המקרים הקוד עצמו פתוח וזמין וכדאי להחיל זאת גם לדברים שמפותחים עבור משרדים/גופים/חברות – המציע הולך לפתח עבורך משהו? דרוש את קוד המקור ותיעוד API ודברים שונים ששונו.
  • אבטחה: תמיד חשוב לזכור – ענן ציבורי נותן אפס אבטחה. אפשר לשכור שרותים שונים ולבצע הגדרות שונות כדי לקבל אבטחה ברמה טובה, אבל זה לא מגיע כברירת מחדל ולא בחינם. כדאי שגוף חיצוני (לא מטעם המציע) יבדוק את המערכת, ואם יש תקציב – לבצע Code Auditing.

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

המעבר ל-10 ג'יגהביט למעבדה קטנה

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

כפרילאנסר, אחת הסברות שאני שומע שוב ושוב בעולם ה-Enterprise מכל מיני מנמר"ים/CTO/CIO – זו התרשמות, שלא לאמר התפעלות – משרתים חדשים שמיוצרים על ידי המובילים: לנובו, Dell, Cisco, HPE, ואחרים. תראה להם מכונה עם 4 מעבדים – והם פותחים עיניים (טוב, עד שהם רואים את תגית המחיר). אותו דבר קורה כשמדברים על ציוד תקשורת – רוב החברות בארץ משתמשות עדיין בתקשורת 1 ג'יגהביט, 10 ג'יגהביט, 25 ג'יגהביט, Infiniband (במקרים מסויימים) במהירות 56 ג'יגהביט היא השיא. 100 ג'יגה ומעלה? נדיר למצוא, גם במקומות שהתקציב מאפשר ועל 400 ג'יגהביט – לא שמעתי שום מקום שמשתמש בזה.

עם כניסת ספקי העננים בשנים האחרונות (או בשמם היותר ידוע: Hyperscalers), חל דבר מעניין מאוד: ברוב מוחלט של המקרים (ואני מדבר על מעל 95%) אף ספק כזה לא היה מוכן לרכוש ציוד של Enterprise – בין אם מדובר בשרתים, סוויצ'ים, סטורג', גיבויים וכו'. הסיבות די פשוטות: הסיבה הראשונה קשורה למחיר החסר פרופורציות לחלוטין פר ברזל, והסיבה השניה – הציוד לא יכול לעמוד בדרישות שלהם, וכך בהחלה כל ספק Hyperscaler החל לתכנן ולבנות את הציוד שלו, ואז הגיעו פייסבוק שחוללו מהפכה והחליטו לפתוח את כל המפרטים של הציוד שלהם, כולל סכימות וכו' תחת מטריית ה-OCP (ר"ת Open Compute Project). לקח קצת זמן עד שענן החשדות מצד ספקי Hyperscalers ירד ואז כולם החלו לשתף את המפרטים. התוצאה: מאות חברות חדשות שקמו שהחלו לתכנן ולמכור את הציוד לספקי ה-Hyperscalers במחירים יותר נמוכים ממה שביקשו ספקי ציוד ה-Enterprise בשעה שהציוד נתן הרבה יותר מבחינת ביצועים.

מאז החלו לזלוג לשוק ה-Enterprise חלק קטן מאותו ציוד: למי שמכיר את הקופסאות JBOD 4U – כן, זה התחיל ב-OCP. מתגי תקשורת שבעבר היו מערכות סגורות עד הקצה – כיום יש יותר ויותר מתגים שמשתמשים במעבד רשת של Broadcom ושבב X86 של אינטל שמריץ לינוקס כדי לנהל את הכל ואתה מבצע בעצם את הכל דרך לינוקס עם הפקודות הידועות והמוכרות.

אז כמו שבקצה העליון שבו נמצאות חברות ה-Hyperscalers התרחש שינוי, גם בקצה התחתון התרחשו ומתרחשים שינויים שמטרתם בסופו של יום להביא חלק מטכנולוגיות ה-Enterprise – אל הקצה התחתון, למעבדה הקטנה, המעבדה הביתית, לאותם אנשים שלא יכולים להוציא 50K על ציוד כדי להריץ LAB נורמלי.

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

  • מחיר המתג וההמרה ל-10 ג'יגהביט יקר מדי
  • בשביל מה צריך את זה? 1 ג'יגהביט מספיק
  • קשה לחבר מעל 2 מחשבים בלי מתג
  • קשה להגדיר

אז נתחיל מהסיבה הפשוטה ביותר: רוחב פס מוגבל. נניח שיש לכם NAS, לא חשוב איזה NAS. נניח שיש בו 4 דיסקים מכניים (בלי להזכיר שום SSD) ונניח שהם מוגדרים ב-RAID כלשהו (לא חשוב איזה). מהירות ממוצעת לקריאה/כתיבה של דיסק מכני היא נעה בין 100-200 מגהבייט לשניה וזה לדיסק יחיד. נכפיל ב-4 לצרכי קריאה לדוגמא, ואנחנו מקבלים מהירות שנעה בין 400 ל-800 מגהבייט. תזכורת: מהירות 1 ג'יגהביט מתורגמת בערך ל-120 מגהבייט, כלומר דיסק יחיד "חונק" את חיבור ה-1 ג'יגהביט. יבואו אנשים ויאמרו "אפשר לצוות מספר חיבורים", שזה נכון, אז בואו נצוות 4 חיבורים של 1 ג'יגהביט ונקבל מהירות ברוטו תיאורתית של … 480 מגהבייט, כלומר את החיבור המצוות אנחנו "נחנוק" עם תעבורה של בערך 2.5 דיסקים קשיחים מכניים (שוב, לא מזכיר SSD שזורק מיד כל חיבור 1 ג'יגהביט).

נעבור למחיר: האם מתג של 10 ג'יגהביט הוא יקר מדי? אם אתה רוצה לרכוש מתג Enterprise של סיסקו או HPE – כן, זה יעלה לך כמה אלפי דולרים. אם לעומת זאת תרכוש מתג של חברת MicroTik, המחיר יפתיע אותך בהחלט. לי לדוגמא, מתג של 16 פורטים +SFP במהירות 10 ג'יגהביט עלה לי 1500 שקל וזה כולל משלוח ומסים. אם אתה רוצה לעומת זאת לחבר רק 2-3 שרתים ואולי מחשב, אז מתג כמו MikroTik CRS305-1G-4S+in יעלה לך 604 שקלים, כולל משלוח מסים (זה המתג שבתמונה).

מה לגבי כרטיסים לחבר למחשבים ושרתים? פה eBay יכול לעזור לך: כרטיס רשת של Mellanox מסוג ConnectX-3 כמו הכרטיס הזה עולה 142 שקל לכרטיס (שימו לב, רוב ההצעות האחרות מדברות על 150+ שקל לכרטיס, ואם אתם משתמשים ב-ESXi רכשו את ה-Connect-X3 ומעלה, לישנים אין יותר תמיכה ב-VMWare), שזה הרבה פחות מהמחיר של כרטיס רשת טוב לשרת במהירות 1 ג'יגה.

כבלים – נחסוך את הרכישה של סיבים אופטיים. לא צריך אותם יותר (בתור אחד שיש לו 3 חתולים שנהנים מדי פעם לבדוק את השיניים שלהם על כבלים כאלו – הם עמידים בצורה מעולה!), במקום זה נשתמש בכבל DAC TwinAX נחושת וכאן תלוי מה האורך שאתם צריכים. אם המחשבים שלכם יושבים במקום אחד וצמודים, כבל של 1 מטר יספיק, והכבל הכי זול שמצאתי זה מהסוחר הזה ב-eBay במחיר של 26.64 שקל. בניגוד לסיבים, לא צריך ג'יביקים ובכלל, המתגים של MicroTik עובדים עם כל כבל – נחושת או סיב או כל GBIC, אין בדיקה ואין חסימות.

אחרי שקנינו, קיבלנו את הכל וחיברנו, בד"כ ההגדרות עצמן הם פשוטות ויש אולי צורך לשנות את הגדרות ה-Jumbo Frames (שינוי MTU ל-9000) – ואפשר להתחיל לעבוד.

אז אם יש לנו 3 מחשבים, העלות תהיה: 604 שקל למתג, 426 שקל ל-3 כרטיסים, 80 שקל לכבלים. סך הכל: 1110 שקל. פתאום 10 ג'יגהביט זה לא כזה יקר? 🙂

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

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

 

המעבר ממונוליטי ל-Microservices

כל מי שנמצא ברמה ניהולית של IT (מנמ"ר/CTO/CIO וכו') בוודאי מכיר את הדבר הבא: חברה מעוניינת לפתח מוצר גדול, "הדבר הבא" בתחום שלהם. מתקיימות מספר ישיבות עם גורמים שונים בחברה ותוך כדי כותבים מפרט ארוך מה הולך להיות בתוך המוצר, במה הולכים לתמוך בתוך המוצר וכו' וכו'.

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

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

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

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

פרויקט גדול מורכב מחלקים רבים שצריך לכתוב. בשיטה המונוליטית כל החלקים משתלבים אחד עם השני (Linking) כך שאי אפשר לשלב קוד בחופשיות של מפתחים שונים. צריך לבדוק כל חלק שמבצעים לו Commit שהוא לא שובר חלקים אחרים במוצר. בשיטת ה-Microservices (אני אקרא לזה מ"ש במשך פוסט זה) עושים דברים בשיטה הפוכה: כל חלק שצריך לכתוב, יכתב באופן עצמאי לחלוטין, הוא יכול להיות כתוב בשפה אחרות או עם פלטפורמה/Framework שונה מחלקים אחרים – כל עוד לאותו חלק יהיה ממשק RESTful API שאליו נוכל לשלוח פרמטרים (דרך YAML, JSON וכו') ונוכל לקבל נתונים בחזרה מאותו חלק בפורמט שנרצה.

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

לאחר שהחלקים השונים נכתבו (או במהלכם) – אנחנו נשתמש במערכת אורקסטרציה לקונטיינרים (כמו Kubernetes/OpenShift) בכדי להריץ כל חלק בקונטיינר/POD והתקשורת בין החלקים תהיה דרך HTTP/HTTPS ודרך פרוטוקולים אלו נשתמש ב-API כך שכל חלק יוכל לדבר עם חלקים אחרים.

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

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

אנסה לסכם את הפוסט כך: כיום, אם יש צורך בפיתוח אפליקציות גדולות ומורכבות, עדיף לעבוד במתודות ה-Microservices (ואגב, לחובבי ה-Mainframe – כן, אפשר לעשות זאת בקרוב גם על Mainframe של IBM עם Z/OS) שנותנות יתרונות רבים מאוד על פני המתודה המונוליטית. נכון, Kubernetes הוא לא בדיוק דבר קליל ללימוד אך מצד שני, המאמץ שווה, מה גם שאם אתם הולכים להשתמש בעננים ציבוריים, החיים הרבה יותר קלים עם שרותי הקונטיינרים הטבעיים שאותם ספקי ענן ציבורי מציעים.

להלן מצגת (קצת ישנה) על הנושא (ותודה ליבגני זיסליס על הלינק):

כשצריך הגנות על מכונות וירטואליות

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

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

אינטל בזמנו פיתחה את ה-SGX, שזו מערכת שמאפשרת לנו ליצור איזור מאובטח שעליו ירוץ קוד בצורה מוצפנת כך שגם מנהל Hypervisor עם תוכנות זדוניות לא יוכל לסרוק את אותו זכרון ולמצוא מה רץ. ה-SGX עצמו כבר נפרץ (אינטל הוציאה תיקון), אבל בכל מקרה הפתרון עצמו היה בעייתי עוד מלכתחילה: האפליקציה המוצפנת היתה צריכה להיות מאוד קטנה (עד 64 מגהבייט זכרון), והביצועים (במיוחד ה-Floating Point) היו, איך נאמר בעדינות … לא משהו להתגאות בו. ב-VMWare לא רצו לנגוע בזה גם עם מקל ארוך.

ואז הגיעה חברת AMD ובשנת 2017 היא פירסמה על תוספות חדשות שיהיו זמינים במעבדים שלה לשרתים (EPYC) ובמעבדים לצרכים מקצועיים (Ryzen Pro): התוספות הן SEV ו-SME (והתוספת החדשה: SEV-ES – להצפין גם רגיסטרים במעבד שמשומשים ע"י אותו VM מוצפן). ה-SEV איפשר להצפין את מכונת ה-VM עם מפתח יחודי שמגיע מתוך מעבד ARM שנמצא במעבד EPYC (כן, מעבד בתוך מעבד) ו-SME שמצפין את הזכרון של ה-VM.

היתרונות של SEV ו-SME הם בכך ש:

  1. אין צורך לעשות שינויים מהותיים ב-VM (רק להחליף Kernel לאחד שתומך ב-SME/SEV)
  2. ההצפנה היא ברמת חומרה, כך שה"קנס" ברמת ביצועים הוא מאוד מינימלי
  3. המפתחות הם יחודיים ולכל VM יש מפתח משלו שמונפק ע"י המעבד. ניתן להנפיק עד 105 מפתחות (כל VM מקבל מפתח אחד, כך שאפשר להריץ עד 105 מכונות VM מוצפנות בשרת עם מעבד EPYC יחיד או 210 בשרת עם שני מעבדי EPYC).

החסרונות:

  1. אי אפשר להצפין מכונות Windows, לפחות עד שמיקרוסופט לא תוסיף את תמיכת ההצפנה ל-OS עצמו.
  2. VMware בשלב זה אינה תומכת בפונקציות אלו מ-AMD או אינטל (תיכף ארחיב על הפתרון של אינטל) – זה יתווסף בגירסה 6.8 או 7.0 ולכן אם אתם צריכים זאת עכשיו, תצטרכו לעבור ל-KVM או על אחת הפלטפורמות שמבוססות על KVM (בכל מקרה יש צורך לבצע את ההחלפת Kernel).

באינטל ראו את הפתרון של AMD והחליטו שגם הם יוציאו משהו דומה: תכירו את TME (כלומר Total Memory Encryption) ואת MKTME (כלומר: Multi Key Total Memory Encryption). אפשר לקרוא על הפתרון הזה בקצרה כאן, אך אני יאמר מראש: אל תבנו על הפתרון הזה, הוא לא זמין באף מעבד נוכחי.

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

  • כן, הפתרון רץ אך על מנת להשתמש בו, יש צורך בידע טוב בלינוקס. אם צריכים את הפתרון ל"מחר בבוקר" – תצטרכו לבצע שינויים הן ברמת ה-HyperVisor והן ברמת ה-VM.
  • הפתרון אינו מבטיח הגנות נגד דברים אחרים כמו Side Memory Attack, DDoS.
  • הפתרון הוא יחסית צעיר (ב-AMD פיתחו אותו בכלל עבור הגנת הקונסולות של סוני ומיקרוסופט ואז החליטו שזה רעיון מעולה להעביר אותו למעבדים לשרתים) ולפיכך מתגלים בו באגים (ו-AMD משחררת קושחות לתיקון).
  • כיום הפתרון של AMD נמצא בשימוש בשרתים החדשים (דור 10) של HPE שמבוססים על מעבדי EPYC (כלומר DL325 ו-DL385) בשילוב ה-Root of Trust של HPE והחברה (HPE) טוענת שזה הפתרון הכי מאובטח שיש להם להציע לשוק.
  • זה לא לפרודקשן אם ה-VM שלכם צריך לרוץ בחוץ או ה-Hypervisor שלכם מחובר לאינטרנט (יש לא מעט כאלו).

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

לסיכום: השיטה ש-AMD מציגה על מנת להגן על מכונות VM נגד האזנה למכונות VM היא שיטה טובה מאוד (ובגלל זה אינטל גם מעתיקים אותה), אך זהו פתרון חדש, וככזה הוא יכול להתאים למאמצים מוקדמים (Early Adopters) עם ידע בלינוקס. אני מאמין שבעוד שנה, הפתרון יתבגר יותר ובמקביל נראה הצעות מספקי ענן ציבורי לשכור Instances שיתמכו ב-SEV/SME, כך שה-Instances שלכם יהיו מוצפנים מספיק טוב בכדי לא לאפשר (באופן עקרוני) לגורמים זרים שיש להם גישה לברזל – לחטט בזכרון של ה-VM שלכם.

הפתרון למעבר מ-VM לקונטיינר: Kubevirt

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

כל מי שהתחיל ומשתמש בקונטיינרים, Kubernetes וכו' – מבין בוודאי שקונטיינרים אינם מכונות וירטואליות. בניגוד ל-VM, קונטיינר מקבל שרותי OS ממערכת ההפעלה המותקנת על ה-VM (או על הברזל) שמריץ את הקונטיינר, ולפיכך קונטיינרים ברוב המקרים הם דברים די קטנים בהשוואה למערכת הפעלה מלאה שמותקנת ב-VM, גם כשהיא מותקנת כ-Minimal.

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

ישנם גם מקרים שאי אפשר להמיר מכונת VM לקונטיינרים חדשים. מקרים כמו:

  • האפליקציה רצה ומבוססת על Windows
  • האפליקציה רצה על גירסת לינוקס מאוד ישנה
  • האפליקציה רצה על מערכת הפעלה שאינה מבוססת לינוקס
  • ה-VM נבנה ע"י מומחה חיצוני ולאף אחד אין מושג ירוק איך הדברים מוגדרים ב-VM (לדוגמא: Cobol ישן)

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

וכאן נכנסת לתמונה אפליקציית Kubevirt.

אפליקציית Kubevirt מרחיבה בעצם את Kubernetes/OpenShift ומוסיפה למערכת תמיכה בקונטיינרים מסוג נוסף: קונטיינר שמריץ VM. כך בעצם אפשר לקחת VM מהדוגמאות לעיל ו"להכניס" אותו לתוך קונטיינר, כך שנוכל להריץ אותו כמו שאנחנו מפעילים קונטיינרים נוספים, ובכך נוכל להשתמש באפליקציה שרצה ב-VM, נוכל לשכפל את הקונטיינר לפי פרמטרים שנרצה, נוכל לשדרג את הקונטיינר ועוד ועוד.

מאחורי הקלעים, מה ש-Kubevirt עושה, הוא להשתמש ב-KVM (הוירטואליזציה המצויה בכל לינוקס) ובספריית Libvirt וספריות נוספות בכדי ליצור POD ובתוך ה-POD להריץ VM. את אותו VM אנחנו נגדיר בעזרת קבצי YAML, כמו שמגדירים כל דבר ב-Kubernetes, וכך נוכל להגדיר כמות זכרון, היכן הדיסק הוירטואלי יושב, האם ה-VM יהיה בעצם Immutable (כלומר שכל שינוי ל-VM ימחק ברגע שה-VM "כובה"), ועוד פונקציות נוספות. הגישה ל-VM תוכל להתבצע בכלים הרגילים (SSH, RDP) או VNC וחיבור סריאלי וירטואלי (במקרה שמדובר בלינוקס או כל מערכת תואמת UNIX אחרת).

מכיוון שב-Kubernetes אפשר להשתמש בכל מיני "דרייברים" (Storage Classes, Volumes), נצטרך להמיר בשלב ראשון את הדיסקים הוירטואליים של ה-VM מהפורמט הנוכחי (VMDK ב-vSphere) לפורמט ש-KVM ו-libvirt יכולים להבין ולהשתמש. סוג הדיסק שאנחנו נצטרך יהיה RAW וכלי ההמרה (שצריך לרוץ תחת לינוקס) הוא virt-v2v (זה קצת יותר מורכב ממה שהקישור מראה). מהרגע שביצענו זאת, אנחנו "מנתקים" בעצם את ה-VM מהוירטואליזציה הנוכחית (נניח vSphere), אבל ה-VM עדיין נשאר ב-vSphere. ברגע שיש לנו את הקובץ בפורמט RAW, נוכל להשתמש בכלי כמו CDI כדי לבצע Import של ה-Image לתוך Volume שנגדיר. אחרי שהצלחנו (שוב, לא דבר כל כך קל, אלא אם אתם משתמשים ב-Openshift דרך ה-WEB UI), אנחנו נגדיר POD עם ה-VM ושם אנחנו נבחר דברים כמו כמות זכרון, מערכת הפעלה, וכו'. בזמן ההגדרות נוכל להוסיף דיסקים וירטואליים חדשים ל-VM ועוד. לאחר שהתהליך מסתיים ונפעיל את ה-VM, תופיע כתובת IP שדרכה נוכל להתחבר אל ה-VM.

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

  • Kubevirt עובד על כל גירסת Kubernetes מ-1.10 ומעלה, ו-OpenShift 3.11 ומעלה.
  • בשביל לקבל ביצועים טובים עם ה-VM, יש צורך בתמיכת Nested Virtualization (אם ה-Kubernetes שלכם רץ כמכונה וירטואלית).
  • עננים ציבוריים: אם אתם רוצים להריץ Kubevirt על ענן ציבורי, תצטרכו לבחור Instances שכוללים תמיכת Nested Virtualization. גם לאז'ור וגם לגוגל יש מכונות כאלו, ב-AWS אין ולפיכך ב-AWS מכונות VM כאלו ירוצו יותר לאט מאחר ומדובר באמולציית X86-64 בתוכנה.
  • דיסקים וירטואליים: מכיוון שאין Thin Provisioning בשיטה כזו, הווליומים יהיו גדולים (כמה שהגדרתם ב-VM בהתחלה תחת vSphere), לכן אם הגדרתם את ה-VM עם דיסק של 100 ג'יגה אבל השתמשתם רק ב-15 ג'יגה, הקטינו את הדיסק (הוראות נמצאות כאן אם מדובר ב-vSphere).
    נקודה נוספת חשובה לגבי דיסקים וירטואליים: אפשר לצרף אותם ישירות ל-Image של הקונטיינר אך הדבר אינו מומלץ (אלא אם אתם רוצים להפיץ את ה-Image החוצה).
  • קישוריות ל-VM ותקשורת: במקור כברירת מחדל יש ל-VM חיבור רשת יחיד. יחד עם זאת ניתן להשתמש ב-Multus או Genie כדי להוסיף דברים רבים הקשורים לרשת: VLAN, Bridges, אפילו PXE Boot – תשתוללו חופשי.
  • ניתן לשכפל את ה-VM לפי כל פרמטר שתרצו כדי לעמוד בעומסים. לשם כך תצטרכו להגדיר בקובץ YAML את ה-AccessModes לפי הצרכים שלכם.
  • KVM – מכיוון שה-VM שלכם ירוץ תחת KVM, כדאי להכיר את KVM. תרימו מכונת לינוקס, תפעילו Nested Virtualization ותריצו את Virt Manager (נקרא גם VMM). יש המון פונקציות והגדרות וכדאי להכיר אותם לפני כן, אחרת תקבלו הפתעות (במיוחד אם מכונת ה-VM שלכם משתמשת ב-UEFI. יש תמיכה ל-UEFI אבל תצטרכו להגדיר כמה דברים לשם כך).

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

אם אתם רוצים עוד הסברים על Kubevirt כולל הדגמה של לינוקס ו-Windows Server 2012, אתם מוזמנים לצפות בקליפ (הארוך – שעה) הבא.

לסיכום: אם אתם רוצים לעבור לקונטיינרים והדבר היחיד שמפריע זה מכונה אחת (או מספר מכונות) שבעייתי להמיר אותן ידנית לקבצי Docker Images ושירוצו כקונטיינרים טבעיים, Kubevirt יכול לסייע בכך. חברות כמו SAP, nVidia, Cloudflare כבר משתמשות ב-Kubevirt. חשוב לציין: Kubevirt עדיין לא מוגדר כגירסה סופית (מצד שני, גם Kubernetes לא מוגדר כך). אם אתם משתמשים ב-OpenShift מגירסה 3.10 ומעלה (גם בגירסת OKD – גירסת הקוד הפתוח) – קל מאוד לשלב את Kubevirt והחל מגירסה 4.2 – ה-Kubevirt יהיה חלק אינטגרלי (בגירסה הנ"ל תוכלו להתחבר ישירות ל-vCenter ולהמיר את ה-VM בכמה קליקים).
מיקרוסופט וגוגל כבר מזמן הבינו שאם רוצים למשוך את הלקוחות אליהם כדי שישתמשו בשרותי ה-Kubernetes שלהם, צריך לעזור ללקוחות בכך שיציעו המרה של מכונות VM להרצה בתוך קונטיינרים, וזה יהיה כנראה ה"גל" הבא.