מערכות משובצות ומצבי "קיוסק"

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

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

  • עדכוני אבטחה – קשה להתקין עדכוני אבטחה ל-Windows כשאין לך תקשורת חיצונית, ומה לעשות ש-Windows דורש המון עדכוני אבטחה.
  • מחיר רשיון – 150-200$ לרשיון Windows Pro (מחיר שונה ל-Windows Embedded אבל כיום המוצר מאבד פופולריות במהירות לטובת פתרונות מבוססי Linux).
  • קבלת Latency נמוך – לא חשוב כמה תכוונן את Windows, תמיד יהיו "קפיצות" שישבשו את ה-Latency.

לכן הרוב עוברים למערכות מבוססות ARM.

לוחות מבוססי מעבדי ARM כדוגמת I.MX6/7/8 ומעבדים אחרים קיימים בשוק זמן רב ובשנים האחרונות המחירים צונחים (בעיקר עקב פופולריות של Raspberry Pi). מחשב קטן שרק לפני כמה שנים היה עולה מאות דולרים, צנח למחירים שכיום נמדדים בעשרות דולרים (כולל אחסון קבוע כמו eMMC). פאנלים ללוחות כאלו קל לחבר (דרך LVDS לדוגמא) והתוספת ל-Touch היא דולרים בודדים, ולכן יש רצון מצד חברות שונות לבנות פתרונות שאותם הם משלבים במוצריהם – הכוללים מעבדי ARM, עם צג מגע וחוויית משתמש טובה. יש אפילו חברה מסויימת שמייצרת Appliance בגודל 1U .. .עם מסך מגע נשלף. לאן הגענו….

לקוח כזה בסופו של דבר צריך לבנות Image שיוכנס ב-eMMC של הלוח. ה-Image אמור לכלול את כל חלקי התוכנה ויש מספר אפשרויות:

  • לינוקס "רגיל" – אפשרות אחת היא לקחת הפצת לינוקס רגילה (Debian, CentOS וכו') עם Kernel שמגיע מיצרן (או שהאינטגרטור מקמפל תוך שימוש ב-BSP, Cross compiler וכו') ופשוט מקימים לינוקס עם התקנת התוכנות הנדרשות (בשימוש yum/apt) וההגדרות הכרוכות בכך, ולבסוף מכינים Image. יש כלים כמו kickstart (ל-CentOS) או Preseed (ל-Debian) כדי להכין Image כזה.
    הבעיה בשיטה זו היא שיש צורך בידע רציני להגדיר את הסביבה הגרפית (Xorg, Wayland, שימוש ב-OpenGL וכו') מכיוון שאין אוטומציה שניתן להשאיל מ-X86 ויש צורך להשקיע מאמצים מרובים להגדיר את הכל.
    חסרון נוסף: אבטחה. במקרים רבים החבילות המגיעות עם תלויות שאין בהן צורך עבור אותה מערכת משובצת ולכן יש לקמפל את החבילות מחדש ללא אותן תלויות או במקרה היותר קשה – לבטל/להחליף תלויות באחרות. חבילות מיותרות ופונקציונאליות שאינה דרושה, גם אם אינן מופעלות יכולות פוטנציאלית לגרום לחורי אבטחה במערכת.
  • Yocto – אחד הכלים הכי פופולריים. עם Yocto אפשר ליצור Image מצומצם לדברים שאנו צריכים בלבד. מערכת Yocto בונה לנו את כל המערכת ולבסוף מכינה Image שניתן "לזרוק" על כרטיס מיקרו SD או על eMMC. המערכת מספיק חכמה בשביל לא לקמפל חבילות שכבר קומפלו ולא היה בהן שינויים, וכל יצרן לוחות ARM תומך בה.
    החסרון עם Yocto: בלא מעט מקרים תצטרך לדעת איך לבנות Recipe כדי להוסיף את החבילה שאתה רוצה ועם אלו ספריות ו-Compile Flags לעיתים. בנוסף – תצטרך להוסיף את ההגדרות לכל חבילה שתרצה בתוך ה-Yocto. בכל הקשור לגרפיקה – גם כאן, תצטרך לשבור את הראש איך להגדיר את הדברים.
  • Boot2QT – זהו מוצר של חברת TrollTech שמשתמש ב-Yocto כדי לבנות מערכת גרפית מוכנה. לא תצטרך לשבור את הראש על Touch, על הגדרות Frame Buffer או Xorg ופרמטרים אחרים. מוצר הדגל של החברה (QT Creator) נותן לך לכתוב אפליקציות גרפיות ולנסות אותן על מחשבך או ישירות על המערכת המשובצת (מבלי להכין כל פעם Image מחדש כדי לנסות את הקוד שכתבת). המערכת קטנה ועולה תוך שניות ספורות. היא גם הופכת את החיים להרבה יותר קלים מבחינת שימוש ב-Yocto והיא מסתירה לא מעט חלקים מורכבים ומטפלת בקומפילציה.
    החסרון: זו מערכת מסחרית. ישנה גירסה חופשית אך אם תשתמש בה, תצטרך לשחרר את כל הקוד שכתבת באפליקציה הגרפית.
  • Android – עוד פתרון שחברת "אגד" לדוגמא – שמחה לאמץ אותו לנהגים כמערכת קופה/כרטוס. כל יצרן מערכת ARM בדרך כלל משחרר גירסת אנדרואיד ולחברה שרוצה להשתמש בכך, ניתן לקחת את גירסת האנדרואיד ולהוריד חלקים שאין צורך בהם, ואם צריך לכתוב אפליקציות יעודיות, לא חסרים מפתחי אנדרואיד (וכן, יש גם מצב קיוסק באנדרואיד) כך שניתן לכתוב את האפליקציה ולשלב אותה ב-Android הפנימי שיווצר ל-Image שירוץ על המערכת. אם צריכים חבילות לינוקס, אפשר להרים מערכת כמו Linux Deploy שתרוץ ברקע, להקים הפצת לינוקס מינימלית שצריכים עם החבילות הדרושות ואז מהאפליקציה שלכם לתקשר דרך Socket או דרך TCP אל האפליקציה (אישית עשיתי זאת פעמיים וזה הציל פעם אחת פרויקט מביטול מאחר והאפשרויות האחרונות לא אפשרו התקנת חבילות מסויימות).
    החסרון: אם מחפשים Boot של 3-5 שניות – תשכחו מזה. בנוסף, קימפול קרנל למערכת אנדרואיד אינו עניין פשוט הואיל ויש לא מעט חלקים שאנדרואיד כן צריך והפצות לינוקס רגילות לא צריכות.

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

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

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

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

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

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

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

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

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

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

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

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

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

וירטואליזציה והעתיד

עולם הוירטואליזציה ידע ב-30+ שנים האחרונות תהפוכות רבות. זה התחיל ב-IBM עם המיינפריים, המשך למערכות יוניקס השונות עם פתרונות מסוגים שונים (רובם מבוססי חומרה), המשיך בצעדים קטנים בעולם ה-PC (בדסקטופ, לא בשרתים), ובשרתים מודרניים זה התחיל עם "מעין וירטואליזציה" כמו chroot, jails ובסולאריס עם Zones.

עד שהגיעו VMWare שגם הם התחילו בהתחלה בדסקטופ (ה-Workstation, אחרי זה ה-GSX, אחרי זה ESX ולבסוף ESXI) והם "לקחו את הקופה" בכל הקשור להצעת וירטואליזציה מלאה. מה שהיית יכול (בד"כ) להריץ על שרת בודד, אתה יכול להריץ בשרת וירטואלי ללא שינויים. VMware נכנסה לשוק די ריק וכבשה אותו ורק לאחר מספר שנים נכנסה מיקרוסופט עם ה-Hyper-V ולאחריה נכנסו אחרים כמו אורקל עם ה-VM Server שלהם וגם רד האט עם RHEV (כיום זה נקרא RHV), ופתרונות אחרים כמו Proxmox ואחרים.

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

  • פתרון וירטואליזציה רגיל – ערימת שרתים שכל התוכן נשמר בדיסקים מקומיים.
  • פתרון וירטואליזציה רגיל – עם NAS או SAN כאשר ה-DATA נשמר על אותו פתרון אחסון.
  • פתרון וירטואליזציה hyperconvergence – שבו הכל יושב בארון אחד ובלוגיקה מאוחדת – ה-storage, הרשת (נהיית כמעט כולה וירטואלית – SDN ), וה-Compute – כמו פתרונות של Nutanix, או Simplivity או RHV (לשעבר RHEV, בגירסה החדשה 4.2 שתצא בקרוב).
  • פתרון וירטואליזציה משולב קונטיינרים – מכונות ה-VM משמשות כ-nodes והקונטיינרים רצים בתוך ה-Nodes.
  • פתרון של קונטיינרים בלבד – ה-Nodes יושבים על מכונות פיזיות (ללא וירטואליזציה) והקונטיינרים רצים על המכונות הפיזיות (פתרון לא מומלץ, הואיל וכך קשה לנטר ולטפל בשרתים).

קונטיינרים נכנסו בסערה לשוק ב-4 שנים האחרונות כאשר Docker הוביל בשוק שהיה עד כה עם פתרון Zones של Solaris ומספר פתרונות לא-ממש-משוייפים בלינוקס כמו LXC והפשוטים כמו chroot ו-jails (שקיים לגרסאות BSD). פתרון הקונטיינרים הראה לעולם מה שמנהלי Solaris ולינוקס ידעו ממזמן – אתה יכול להרים קונטיינר ב-2-3 שניות ולהריץ עליו אפליקציות. הפתרון היה מוגבל, אבל הוא בהחלט הצית את הדמיון ומספר אנשים החלו לעבוד על פתרון משלים בגוגל ולאחר זמן מה גוגל החליטו להוציא את הפתרון שלהם שמשתלב עם Docker ונקרא Kubernetes (או בקיצור: K8S ובתרגום השם מיוונית: טייס – pilot) ו-K8S נותן לך פתרון כמעט מלא לקונטיינרים – החל בשרידות, גדילה דינמית, בדיקת "בריאות" קונטיינרים, תקשורת ביניהם (באמצעות תוסף צד ג' – יש מספר פתרונות מובילים) ועוד ועוד.

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

זה המצב כרגע בשוק.

ומה העתיד צופה לנו?

מי שנמצא בתחום המחשבים עשרות שנים יכול בוודאי לראות שפתרונות ישנים תמיד עושים "סיבוב" נוסף וחוזרים כפתרונות מודרניים. קחו Mainframe מלפני 30+ שנה, דברים עתיקים כמו System/360 של IBM ונוכל לראות שם ש-IBM הריצו מערכות נפרדות כ… קונטיינרים, בשמות אחרים, במושגים שונים, אבל במבט על – אפשר להשוות זאת לקונטיינרים והנה כיום השוק חוזר ל.. קונטיינרים. אותו דבר בוירטואליזציה (גם שם ל-IBM יש הרבה קרדיט ו.. אלפי פטנטים. אם IBM היתה רוצה להתנהג כמו שמיקרוסופט התנהגה בשנות ה-90 – הייתם משלמים היום הרבה הרבה יותר על פתרונות וירוטאליזציה וקונטיינרים).

לעניות דעתי, הדבר הבא שיכנס – יהיו הקונטיינרים VC (לא, אני לא מדבר על vCenter שבין כה הולך למות לטובת VCSA לשמחתי). מה זה קונטיינרים VC? התשובה לכך היא Virtualized Containers ויש מספר חברות (הכי גדולה היא אינטל עם ה-Clear Containers) שיציעו זאת.

איפה זה נכנס? הבעיה כיום עם קונטיינרים היא שההפרדה בין קונטיינר לקונטיינר היא חלקית. אם נפעיל קונטיינר A ונכנס אליו, הוא לא יכול לדבר כברירת מחדל עם קונטיינרים אחרים או עם ה-host אלא אם נגדיר לו כך ספציפית (בצורה של Volume או בהגדרות רשת). יחד עם זאת, אם אני מצליח לקבל גישת root ל-host עצמו, אני לא רק שיכול לראות את כל התליכים שהקונטיינרים מריצים, אני יכול לשבש את כל המערכת. יש פתרונות לכך כמו SELinux ו-AppArmor אבל הרוב לא משתמשים בכך ובחברות גדולות כמו בנקים וכו' העניין די מעכב הכנסת פתרונות מבוססי קונטיינרים. (אצל חברות הענן כמו אמזון וגוגל, המצב שונה לחלוטין וגם אם תצליח לפרוץ את הקונטיינר – לא ממש תגיע ל-host, והם משתמשים בפתרונות חומרה כדי להגן על הדברים, פתרונות חומרה משלהם שהם אינם מוכרים. ככלל, שרתים אצל יצרני הענן שונים מאוד בתצורה הסופית מהשרתים שחברות קונות).

כאן נכנסים ה-VC. ה-Virtualized Containers הם בעצם מכונות וירטואליות לכל דבר ועניין שיריצו את האפליקציה שלכם, רק שהם בנוים בצורה אחרת. לדוגמא עניין ה-BIOS ותצורת ה-PC הקלאסית – הועפו החוצה ודברים רבים שונו כך שה-VC לא יצרכו משאבים כמו VM רגיל, אבל מצד שני תקבל את ההגנות של וירטואליזציה כך שגם אם יש לך root ל-host עצמו, זה לא אומר שתוכל לראות תהליכים רצים (תוכל לראות מכונות וירטואליות שרצות אבל די קל גם להגן עליהן עם פתרונות הצפנה, שימוש ב-HSM וכו' וכו').

אפשר לקבל מעט יותר פרטים על כך ב-Kata Containers , הגירסה הבאה של OpenStack כאן שתתמוך בפתרון VC, ואני משער ש-Kubernetes יתמכו בהמשך גם ב-VC של חברות אחרות ושל אינטל.

ומה עם הפתרונות של VMware?  ל-VMWare כיום יש את vSphere integrated containers אבל אני מאמין שב-vSphere 7 הפתרון יהיה שונה, וגם ב-VMWare יבינו שרעיון ה-VC הוא רעיון לא רע בכלל להטמעה ושימוש, ומכיוון שב-VMWare יש צוות ענק של אנשי לינוקס, הם יכינו פתרון כזה (הימור שלי: פתרון ה-VC שלהם יתאם ללינוקס, לא ממש ל-Windows, לפחות לא בגירסה הראשונה) כך שתוכל להרים לך קונטיינר או VM, וזה לא ישנה הרבה, והפתרון יכלול גם Scale Out דינמי. (אין לי NDA מול VMWare וידע פנימי רשמי מה שקורה שם ולכן אני מסייג את הדברים, אלו רק שמועות ששמעתי).

עוד תחום שלדעתי יקבל יותר ויותר מקום (אך הדבר יקח זמן עקב שמרנות של חברות) הם מעבדי ARM. חברות כמו Qualcomm, Cavium ואחרות מתחילות להוציא מעבדי ARM V8-A עם 16/32/64 ליבות, מיקרוסופט עובדת ותשחרר בקרוב Windows 2016 לשרתי ARM ויש שמועות שגם ב-VMware וחברות אחרות עובדים על כך (הפצות לינוקס לשרתי ARM כבר קיימים כיום (גירסת SuSE קיימת כאן, וכאן ההכרזה של רד-האט, וכאן של Ubuntu). הרעיון עצמו הוא פשוט: בשרתים כאלו יש לך עשרות ליבות ואתה לא צריך לשלם 10000$ על מעבד כזה, והליבות הללו יכולות להריץ דברים קטנים ביעילות מופלאה. קונטיינרים הם (יחסית) קטנים, אז למה שלא תריץ את הקונטיינרים שלך על מעבדי ARM? צריך ברזלים? HPE הכריזו על כמה דגמים, DELL ו-Lenovo ממלאים את פיהם מים כרגע, אבל בוודאות אני יכול לאמר לכם – הם בונים כאלו בימים אלו לקראת הכרזה בקרוב.

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

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

יהיה בהחלט מעניין 🙂