קונטיינרים ומכונות וירטואליות – השילוב הנחוץ

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

הפעם נדבר על דבר הפוך וחדש.

סיפור קטן: לפני מס' חודשים ישבתי בישיבה אצל חברה פיננסית גדולה מאוד שכולם מכירים. מטרת הישיבה – שיחה על מעבר עתידי לתצורת עבודה של Devops, שימוש ב-CI/CD, קונטיינרים, מתודות וכו'. בדרך כלל בישיבה כזו אני מבקש לדעת מה הכלים שהם משתמשים כרגע, כמו שרתי אפליקציות, קומפיילרים, מערכות הפעלה וכלים אחרים, ולפי זה ניתן להעריך בהערכה גסה מה יהיה קל להעביר לקונטיינרים ול-Micro Services. במקרה של אותה חברה, מבלי לפרט דברים, היו כמה דברים שלהעביר אותם לקונטיינרים יהיה סיפור סופר-מורכב, ובחלק מהמקרים כנראה שלא אפשרי מכל מיני סיבות שלא אכנס אליהם כדי לא לחשוף פרטים. אלו הדברים שבדרך כלל אני רושם לעצמי בצד לבדוק מה ניתן לעשות עבור הלקוח.

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

כאן נכנס לתמונה כלי חדש של רד-האט שנקרא Kubevirt.

Kubevirt בעקרון עושה משהו הפוך ממה ש-CRI-O עם Kata containers עושה: עם CRI-O אנחנו מריצים קונטיינרים בתוך VM מינימלי, ואילו Kubevirt מריץ מכונה וירטואלית בתוך POD, וכן, אני מדבר על המכונה הוירטואלית המלאה – עם OS ואפליקציות משלה, שמתורגמת ישירות מ-VMWare או מ-OVA.

במילים אחרות – אנחנו נריץ VM כ-קונטיינר! (וכן, נקבל את האבטחה המלאה של ה-VM).

כך ניתן בעצם עם Kubevirt לקחת את אותן מכונות וירטואליות שלא ניתן להמיר לקונטיינרים ולהריץ אותן ישירות בתוך Kubernetes או OpenShift ובדרך להנות מדברים כמו Scaling ועוד תופינים שמערכת Kubernetes/OpenShift נותנת, מבלי שנהיה תקועים עם דברים שאי אפשר להמיר לקונטיינרים. כך לדוגמא אצל אותה חברה פיננסית גדולה, כל מה שאצטרך בעצם לעשות, זה להמיר את ה-VM (ליתר דיוק את הדיסק) ל-Persistent Volume ובקובץ ה-YAML להשתמש ב-PVC על מנת "לחבר" את ה"דיסק") לאותו VM.

יש גם מגבלות נכון לגירסה הנוכחית כמו:

  • אפשר להשתמש רק בדיסק קשיח יחיד
  • יש רק כרטיס רשת אחד, וגם איתו אי אפשר לשחק הרבה הואיל והמערכת מבצעת Proxy בין ה-VM לתקשורת של ה-POD.

רד-האט, מפתחת Kubevirt, פרסמה לאחרונה פוסט בנושא.

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

למעוניינים, באתר Kubevirt יש מספר דוגמאות איך ניתן להשתמש בכלי הן עם Minikube, הן בתוך Cluster של Kubernetes, הן בתוך AWS, והן בתוך GCP.

לסיכום: Kubevirt נותן סוף סוף את האפשרות לחברות לקחת מכונות וירטואליות ולהעביר אותן לעבוד יחד עם Kubernetes או OpenShift. אינני מדבר על ההעברה של כל תשתית הוירטואליזציה ל-Kubernetes (אני לא מוצא יתרון בהעברת מכונת SAP), אלא לדברים שאנחנו צריכים כחלק מעבודות מתודת Devops, CI/CD וכו'. במקרים שקשה או לא ניתן להעביר מכונות וירטואליות לפורמט קונטיינרים, הרבה יותר קל להעביר מכונה וירטואלית מפורמט VMware לפורמט KVM ולהריץ את אותה מכונה וירטואלית כמו שהיא – כקונטיינר.

הערה: הכלי נמצא במצב Preview והוא עדיין בפיתוח.

 

וירטואליזציה: לחזור לברזלים?

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

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

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

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

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

  • עלויות מטפסות: אם נניח יש לנו כיום 10 שרתים שמריצים את כל הדברים בוירטואליזציה ועתה נוסיף 10 שרתים נוספים שיריצו דברים "על הברזל", הדברים מסביב יעלו יותר: קירור, חשמל, תחזוקת השרת (מבחינת תוכנה וחומרה). בהתחלה זה נשמע כאילו מדובר בעלות קטנה, אולם מכיוון שאנחנו צריכים לאמץ את השרתים (כי לשם כך אנחנו מבצעים V2P) – עלויות החשמל והקירור יעלו באופן רציני.
  • שדרוג חומרה: תעיפו מבט בחומרת השרתים. לעיתים השקעה של כמה מאות או אלפי דולרים חד פעמית בשדרוג מעבדים ו/או זכרון יכולה להאיץ את הביצועים של המכונות הוירטואליות ולחסוך מעבר מוירטואלי ל"ברזל".
  • להתראות לדברים הנחמדים: וירטואליזציה נותנת לנו פונקציואנליות שקצת קשה להשגה כשדברים רצים ישירות "על הברזל". קחו לדוגמא Snapshot – סביר להניח שאינכם משתמשים ב-ZFS על הברזל, כך שיצירת Snapshot של הברזל היא קצת בעייתית (במיוחד אם אין לכם LVM או שלא הגדרתם ווליום לוגי שיאחסן את ה-Snapshots בנפרד). רוצים HA? לא תוכלו להשתמש ב-HA שהוירטואליזציה מספקת, תצטרכו פתרון נפרד, ובהצלחה בבניית Fault tollerance על ברזלים, ואלו רק חלק קטן מהפונקציונאליות שוירטואליזציה נותנת וריצה "על הברזל" לא נותנת.
  • גיבוי ושחזור – הרבה יותר איטיים מאשר גיבוי ושחזור מכונות וירטואליות.

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

תכירו את Kubevirt

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

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

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

אחת הבעיות שנוצרות מהכנסת קונטיינרים ומערכת ניהול/אורקסטרציה (כמו Kubernetes, OpenShift, Docker-swarm ואחרים) היא שמעתה צריך לנהל 2 מערכות שונות. האחת לניהול השרתים הוירטואליים שלכם (Hyper-V, vSphere) ואחד לניהול הקונטיינרים שלכם ולמרות שברמה העקרונית שתיהן מרימות דברים שהם מופרדים (קונטיינרים, VM), יש תהום של הבדלים ביניהם:

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

יחד עם זאת, לא היה נחמד יותר להשתמש ב-Kubernetes (או OpenShift או CAAS של SuSE)?

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

תכירו את Kubevirt.

הרעיון של Kubevirt הוא די פשוט: בתוך Kubernetes יש דבר שנקרא CRI (ר"ת Container Runtime Interface). פרויקט oVirt מרחיב את ה-CRI ואת Kubernetes עצמו כך שיוכל להפעיל גם מכונות וירטואליות כאילו מדובר בהפעלת קונטיינרים. בד"כ ע"מ ליצור POD עם קונטיינר, אנחנו יוצרים קובץ בפורמט YAML (או JSON, בהתאם להעדפות), וכאן הדברים יהיו דומים. הנה דוגמא לקובץ YAML כזה.

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

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

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

המעבר מ-VM לקונטיינרים

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

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

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

אם אני מעוניין להציג דברים אחרים, אולי אתר מלא, אני אכנס לתיקיה שמוגדרת בשרת Web כ-DocumentRoot ואעביר לשם את הקבצים ואולי גם אתקין שם MySQL קטן כי האתר שלי מצריך Database. אני אוודא כי כניסות 80 ו-443 פתוחים לעולם. עכשיו הכל עובד, ואני אכנס אחת לתקופה כלשהי כדי לעדכן את התוכנה, ואת מערכת ההפעלה. אם תהיה לי הפסקת חשמל, ברגע שהחשמל יחזור אני אבצע Boot לפתרון הוירטואליזציה ואפעיל מחדש את ה-VM כדי שאנשים יוכלו לגלוש לאתר שלי.

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

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

כך בדיוק עולם הקונטיינרים בנוי.

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

כך שאם נחזור לדוגמא לעיל עם האתר, אנחנו בעצם נקים 2 קונטיינרים עם מיפוי לשרת הפיזי או ל-NFS/OCFS עם המידע הרלוונטי. זיכרו: בקונטיינרים – כל דבר שהולך להשתנות, מומלץ שיכתב/יקרא ממערכת מחוץ לקונטיינר, ודברים שהם קבועים – אנחנו נכלול אותם בעת בניית הקונטיינר בכתיבת קובץ DockerFile (שמהווה בעצם "סקריפט" לבניית הקונטיינר שלנו). יותר מכך – כשעובדים עם מספר קונטיינרים לא קטן, מאוד מומלץ להתחיל לעבוד עם מערכות כמו OpenShift, Kubernetes, Rancher ואחרים – ששם כבר ניתן "להזריק" לקונטיינר דברים רגישים כמו סיסמאות, מפתחות SSL – בעת הרצת הקונטיינר.

לכן, העברה של מערכת מ-VM לקונטיינרים בצורה של "1:1" לא רק שלא שווה, היא גם תעשה צרות (במיוחד שמריצים docker run והמערכת מקימה כל פעם מחדש קונטיינר חדש ולאיש צוות שלא מבין בקונטיינרים יש כאב ראש מדוע הקבצים לא נשמרים ומדוע כשהוא מתחבר לקונטיינר והוא מתנתק, הקונטיינר כבה). צריך לבדוק כל VM מה בעצם הוא עושה, מה האפליקציות שצריך ואז לבנות את הקונטיינרים השונים כדי שהדברים ירוצו, יחד עם מציאת פתרון NFS/OCFS2 ואחרים כדי למפות תיקיות לקונטיינר, דאגה ל-Scheduling ועוד.

קונטיינרים הם כלי מצוין במיוחד ל-2 פעולות:

  • בדיקות – מאוד קל להקים קונטיינרים במהלך תהליך CI/CD שיכלול את האפליקציות והספריות. כך אנחנו בעצם נחסוך יצירת קבצי הרצה שאותם נתקין על VM כדי לנסות. ברגע שהמערכת מסיימת לבצע בדיקות Unit testing לדוגמא או תהליכים אחרים – אפשר לקבוע שבסוף היא תקים קונטיינר המבוסס עם קובץ DockerFile (או שתשתמשו ב-Docker Compose שמבוסס פייתון אבל לא מחייב ידע בפייתון), וכך המערכת תקים קונטיינר עם הכל מוכן לשימוש ע"י צוות הפיתוח או צוותים אחרים.
  • שיווק – כמעט כל חברה שבונה היום מוצרים מבוססי Web ללקוח, בין אם זה שרת מייל, ניטור, אבטחה או 1001 דברים – החברות משתמשות ב-IMAGE כדי לשדרג, רק ש-IMG זה לא תמיד פתרון טוב או קליל, במיוחד אם צריכים לשלוח ללקוח שאין לו ל-Appliance חיבור אינטרנט וצריך לעדכן חבילה מסויימת ספציפית (נניח … openssl) ואז צריך לבנות לוגיקה שלמה שהמערכת תבין כל קובץ מהו ולאן הוא הולך ושלא ישבור כלום באמצע.
    עם קונטיינרים לעומת זאת – החיים הרבה יותר קלים. ה-Appliance יכול להכיל מערכת לינוקס מאוד מינימלית (כמו Atomic של רד-האט/סנטוס), והאפליקציה עצמה יכולה לשבת בקונטיינר כאשר כל קבצי ההגדרות וקבצים חשובים יושבים מחוץ לקונטיינר וממופים לקונטיינר. כך, במקרה של שדרוג, הלקוח יוריד קובץ חתום, המערכת תקבל את הקובץ החתום, תבדוק חתימה, ותפרוס אותו ל-file-system המקומי ואז בהרצה של מספר פקודות ניתן לכבות ולהפעיל את הקונטיינר החדש תוך מיפוי התיקיות החשובות – ועכשיו יש ללקוח Appliance מעודכן עם הגירסה החדשה של התוכנה (ובקשר לעדכון ה-VM עצמו או המכונה הפיזית שמריצה את הקונטיינר – אפשר להשתמש ב-ostree)

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

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

טכנולוגיה אינה דת

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

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

ישנם דברים שיכולים מאוד להתאים לאיש IT מקצועי עם שנים רבות של נסיון שפשוט לא יכולים להתאים למשתמשים רבים. אני יכול לתת דוגמא פשוטה: אני כותב את הפוסט הזה עם מחשב ASUS ChromeBox שמריץ את ChromeOS שרוב הזמן אני עובד עליו. מדוע? כי אני מקבל את החוויה של שימוש בכרום תוך 6 שניות מהפעלת המכשיר, אין לי חשש מבעיה של תקלת אחסון (הכל בענן או ברשת) ואין שום דבר שיכול לגרום למכונה הקטנה הזו "להיתקע". אם אני צריך דברים יותר מורכבים, אז אני משתמש ב-Crouton באותה מכונה ואז יש לי בנוסף ל-ChromeOS אובונטו או Debian ובלחיצה על צירוף מקשים יש לי Shell כדי לעשות דברים פשוטים או מורכבים ואני אפילו יכול להריץ אפליקציות Android על ה-ChromeBox הזה ללא צורך במכשיר סלולרי או טאבלט.

האם אני ממליץ את הקונפיגורציה הזו לאנשי IT? אם הם הטיפוסים שאוהבים "לחטט" ו"לשחק" עם דברים – אז כן, בהחלט. האם אני ממליץ להעביר תחנות של מזכירות ומשתמשים קלים אחרים ל-ChromeBox? לא, כי אין עדיין ב-ChromeOS שום תמיכה פנימית ל-Active Directory, לניהול מרוכז עם כלי System Center של מיקרוסופט (שחברות רבות משתמשות בו), אין עדיין מספיק כלים שיכולים להחליף או לתת חוויית שימוש דומה בכלים שיש בעולם של מיקרוסופט למשתמש הסופי. היכן כן אמליץ להטמיע אותו למשתמשי קצה? באותן חברות קטנות שהחליטו להשתמש בשרותי Google Apps (או מה שנקרא היום Google for Work) ושכל העבודה מתבצעת דרך דפדפן. עלויות התחזוקה שם הן מאוד קטנות וגם אם מתקלקלת קופסא כלשהי, שום מידע לא הולך לאיבוד.

דוגמא אחרת היא בתחום הוירטואליזציה. התחום הזה נחלק בין 2 חברות גדולות (VMWare, מיקרוסופט) ויש גם את המתחרים כמו Xen, אורקל (VM Server). בעולם חברות רבות החלו במעבר מוירטואליזציות שרצות מקומית על השרתים של החברה לשרותי ענן כמו Amazon, Azure וגם ל-Google Cloud. בישראל, לעומת זאת, המעבר לשרותים הנ"ל עדיין איטי וחלק גדול מהחברות לא חושבות לעבור (אם כי כן להשתמש בשרותים אחרים כמו אחסון, DNS וכו')

אם אנחנו מדברים על וירטואליזציה, ושוב – אנשי ה-IT שאוהבים "לשחק", אני ממליץ להם על הכרות עם KVM. זו וירטואליזציה בקוד פתוח שנותנת ביצועים כמו ESXI. למי שמצפה ל-GUI כמו שיש עם vCenter (או VCSA/VSA) או כמו כלים של מיקרוסופט – יתאכזב. ה-GUI שיש מהרגע הראשון הוא מאוד פשוט. KVM נבנה יותר לכיוון אנשים שאוהבים Command Line ומכיוון שהוא נכתב כך, ישנם עשרות כלים, חלקם חינמיים וחלקם בתשלום – שמאפשרים לך ניהול של שרתים פיזיים שמריצים KVM. אפשרות שתעניין אתכם אולי זה להריץ את oVirt (המנהל הרשמי להרצת מכונות KVM, זה יותר מזכיר את ה-vCenter). אפשרות נוספת בבית שלכם (אם יש לכם כרטיס nVidia במחשב וגם כרטיס onboard) היא להריץ Windows עם משחקים בביצועים של בערך 95-99% בהשוואה ל-Native. הנה הדגמה:

אגב, ספריה טובה שאני ממליץ עליה (לאלו שכותבים ב-Python, PHP וכו') היא ספריית libvirt. בעזרת ספריה זו אתם יכולים להתחבר גם ל-ESXi, גם ל-Hyper-V, גם ל-Xen, ל-VirtualBox ועוד כמה מערכות וירטואליזציה ולהריץ עליהם אפליקציות שאתם תכתבו, כך שאם יש לכם סביבה מעורבת, ספריה זו יכולה לעזור לכם לכתוב כלים לנהל, לדגום ביתר קלות.

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

הטריקים של אורקל עם OVS

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

נשמע משתלם, לא? 

לא בדיוק.

הבה נציץ מאחורי הקלעים: פתרון הוירטואליזציה שאורקל נותנים עם המערכת הוא פתרון שהיה נקרא בעבר Virtual Iron שהיה מבוסס על Xen. מאז שאורקל רכשו את החברה, הפיתוח הואט כנראה וכיום הוא אפילו לא משתווה למתחרה הישיר שלו – XenServer של Citrix. מה שאורקל שינו מאז במערכת הם שינויים קטנים ועדכונים (כך לדוגמא, אם אתה חושב להצמיד כרטיס PCI למכונה וירטואלית, תתכונן לכשלון, זה פועל בקושי. חושב על פתרון כמו Shared Memory בין מערכות וירטואליות שמריצות את אותה מערכת הפעלה? יש, אבל שלא תחשוב שזה כמו ESXI) אבל הם מתנדפים בהשוואה למערכות וירטואליות כמו ESXI או אפילו Hyper-V. אם אתם לא מכירים לינוקס טוב, תתכוננו להרבה תסכול, כי זה מה שה-GUI (ה-VM Manager) נותן: תצוגה מוזרה של דברים, נעילות של מכונות אם JOB נופל (לך חפש את ה-JOB ומהיכן לשחרר נעילה), ותשכח ממצב לראות סטטוס כללי של כל המכונות הוירטואליות שלך אם הם רצים, כמה זכרון הם משתמשים וכו'. רוצים סקירה קצת יותר עמוקה על המוצר? קחו, קראו בעצמכם.

לא מדובר פה באיזו "אשמה" של המערכת הוירטואלית עצמה (XEN) כלל וכלל! אם תיקחו לדוגמא את XenServer של Citrix, יש למוצר דווקא ממשק בכלל לא רע כי ל-Citrix יש הרבה יותר נסיון עם ממשקים, Windows וכו'. גם מבחינת תמחור קשה להתחרות במוצר של Citrix. אפשר להוריד אותו בחינם (קוד פתוח) ואפשר לקבל שרותי תמיכה בתשלום שנתי של $199 פר תושבת מעבד. 

פה בישראל, הבעיה חמורה בהרבה. הבעיה עצמה מתחילה בתמיכה, והח"מ, כאחד שעבד עם התמיכה של אורקל למוצר, אני יכול לתאר את אותה תמיכה כמתחת לכל ביקורת. תומכים שלא יודעים על מה הם סחים, אינטגרטורים של אורקל עצמה שמגיעים ולא יודעים מה הם מתקינים (או שמתקינים ושוכחים להתקין קבצי RPM שונים) או שלא יודעים להתקין דברים בצורה נכונה (ראיתי אישית מקרה של'קח להם יומיים לפתור תקלה של … invalid boot signature של GRUB. הם פירמטו את המכונה הפיזית, אני לא צוחק!). בשבוע האחרון ראיתי את ה"יעילות" של אורקל. עמית פתח באורקל תקלה על אחד מהשרתים הוירטואליים (שנתמך ע"י אורקל). לכלי איסוף לוגים של אורקל לקח כמעט 3 שעות עבודה ליצור קובץ שצריך לשלוח לתמיכה (אחרת הם לא עוזרים לך בכלים), אני החלטתי מנסיוני פשוט לפתור את העניין וסיימתי את התקלה (לאחר תיקונים והתקנות של חבילות חסרות שאורקל ישראל לא התקינו) לאחר דקות ספורות. אם לא הייתי נותן שרות ללקוח, הוא היה מושבת לפחות ליום!.

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

  1. ודא כי יש לך איש לינוקס מקצועי בחברה או פרילאנסר שנותן שרותים ושהוא מקצועי, עם המערכת OVS של אורקל, אתה בהחלט תצטרך את זה.
  2. אם החלטת ללכת על פתרון XEN, כדאי שתתקין על שרת טסטים את XenServer, הוא יותר מעודכן ויותר ידידותי לחובבי GUI (אם כי גם שם תצטרך איש לינוקס לכל האוטומציה, סקריפטים וכו').
  3. אל תאמין לכל מיני חומרים שיווקיים שמראים לך כי OVS יותר טוב מ-ESXI או Hyper-V. הייתי שמח לפרסם תוצאות ביצועים, אולם הרשיון של OVS אוסר זאת. 

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

מוגש כחומר למחשבה.