קונטיינרים וגדילה, צרכים מול מציאות

עבדכם הנאמן ממשיך בביקורים בחברות גדולות במשק הישראלי בנסיון להסביר יותר לגבי קונטיינרים, מערכות אורקסטרציה לקונטיינרים (מה שמבוסס Kubernetes), תמיכה ב-CI/CD וכו', אך אחד הדברים שקשה להעביר להנהלות השונות, הוא עניין ה-Scaling הרוחבי, שהוא אחד ההבדלים המהותיים בין עבודה עם מכונות VM ו-Scale קבוע, לבין קונטיינרים עם Scale דינמי.

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

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

אם היינו לוקחים אתר מסחרי ו"ממירים" אותו לעבודה כקונטיינרים על ענן ציבורי כלשהו, רוב התקלות היו נמנעות, כי מערכת כמו Kubernetes/OpenShift יודעות לבצע Scaling אוטומטית אם פשוט מגדירים זאת, בין אם מדובר בגדילה או בהקטנה, בהתאם לעומסים. אתם עובדים עם אמזון וצריכים עכשיו להרים 500 קונטיינרים וכבר הגדרתם את הכל באותו ענן? תוך דקות ספורות הכל יהיה למעלה ואם תצטרכו יותר קונטיינרים עקב עומסים, יקח למערכת שניות ספורות להוסיף קונטיינרים, וזה אחד ההבדלים הגדולים בין קונטיינרים ל-VM (או EC2 Instance): ל-VM לוקח מספר דקות כדי להיווצר ולהיות מוגדר לעבודה יחד עם השאר. גרוע מכך: אם המערכת רצה On Premise, אז בעצם צריך לנחש כמה מכונות להקים ומערכות וירטואליה אינן טובות בהוספה אוטומטית של מכונות VM (וכמובן – בענן ציבורי יש הרבה יותר משאבים ממה שיש On Premise או בכל ספק Hosting מקומי).

קונטיינרים הם דברים חד פעמיים, שנהרסים בתום עבודה (או כשהם קורסים עקב שגיאה/באג), וכשמתחילים להשתמש בכלי CI/CD עם קונטיינרים, כמות הקונטיינרים שתרוץ במקביל מתחילה לטפס במהירות. אם לדוגמא נשתמש בכלי כמו Jenkins עם תמיכה בקונטיינרים ונגדיר את Jenkins לעקוב אחרי כל מיני Repositories של קוד שמפתחים כותבים, ברגע שמבצעים Commit, מערכת Jenkins תקים קונטיינר ותבנה בתוכו את הקוד. נניח שיש לנו מספר Repositories ומספר עבודות ב-Jenkins שזה מה שהן עושות, נראה שהמערכת מהר מאוד תקים מספר קונטיינרים, ואם נגדיר את המערכת להריץ טסטים על קונטיינרים שנבנו מ-Build אחרון, נקבל מספר כפול ותוך זמן קצר כולם יכולים לראות שמשאבים מנוצלים במהירות, הן מבחינת Compute וכמובן מבחינת אחסון (תסתכלו על הגרפים של ה-VM שמריצים את ה-Kubernetes/OpenShift). היתרון הגדול כמובן בקונטיינרים, זה שהכל נבנה מאפס, ואין יותר "אצלי זה עובד אז אם לך לא עובד, זו בעיה שלך".

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

אבל הבעיה מתחילה שצריכים להריץ קונטיינרים ומערכת כמו OpenShift/Kubernetes – כדי לשרת את הקהל בחוץ. כמות הגולשים היא דינמית, והמערכת צריכה להיות בנויה בצורה שונה בהשוואה לעבודה מול מערכות VM או EC2 Instances. דוגמא פשוטה: אם אנחנו רוצים לכתוב תכנים החוצה מהקונטיינר (שוב, קונטיינר הוא דבר חד פעמי וכשהוא נהרס, המערכת מוחקת הכל אלא אם הקונטיינר נבנה עם הגדרות של כתיבה חיצונית בדרכים מסויימות), זה שלאותו VM יהיה גם 10 טרהבייט דיסק קשיח וירטואלי לא יעזור במאומה כי שיטת אחסון הנתונים היא שונה, יהיה צורך במקרים רבים וכשיש כמות גדולה של כתיבה ודרישה לשרידות רצינית – להשתמש ב-Object Storage שמבוצע ב-Scale Out שאינו בנוי על VM שמאוחסן על איזה Datastore ב-vSphere, וכאן כבר יש צורך או בסטורג' Scale Out קנייני שיודע לתמוך ב-Object Storage או להקים מערכת שתרוץ כ-VM על הברזלים וגם הקונטיינרים ירוצו על הברזלים עצמם ללא וירטואליזציה (למעט קונטיינרים מסויימים שאיננו סומכים עליהם ונוכל להריץ אותם עם וירטואליזציה קטנה כמו עם Kata Containers) ומעל זה יכול להיות שנצטרך להריץ איזה Load Balancer כלשהו (אם כי מערכות Kubernetes/OpenShift נותנות פתרון Load Balancing אבל לא בטוח שחברות ירצו להשתמש בו לצרכים של אתרים חשופים). פתרונות כאלו לא יתנו לנו גמישות מקסימלית כמו שרות הרצת קונטיינרים שספקי הענן מציעים (בגלל שלהם יש הרבה יותר משאבים).

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

  • ענן פרטי עם OpenStack: הפתרון הזה יכול לתת לנו את הכל ביחד. אנחנו יכולים להשתמש בסטורג' קנייני כלשהו ולחבר אותו ל-OpenStack כדי לקבל שרותים כמו Object Storage, Block Storage וכו' או שאנחנו יכולים להקים VM בכל שרת ולהריץ עליו Ceph.
  • עבודה במצב Hybrid: יש לנו מקומית מערכת OpenShift או Kubernetes פנימית שעליה אנחנו מבצעים פיתוח וכו', ואת האתרים הציבוריים אנחנו נשתמש בשרותי הקונטיינרים שספק הענן שבחרנו מציע. אם לדוגמא החברה משתמשת ב-Azure, אז הם יכולים להשתמש בשרות AKS. באמזון יש את אותו שרות (בערך) שנקרא EKS (או Fargate ששם אמזון מנהלת את ה-Kubernetes ואתה מריץ את הקונטיינרים) ובענן של גוגל יש את GKE. ה-Hybrid מומלץ לחברות שהרגולטור אוסר עליהן להוציא הכל החוצה.
  • עבודה "באותו ענן" – במקומות בהן בחרו לעבוד לדוגמא עם Azure, ניתן לרכוש מיצרן השרתים המועדף עליכם את Azure Stack – זהו פתרון שרץ על הברזלים אצלכם מקומית עם חיבור ל-Azure, כך שאפשר להשתמש באותם שרותים, מקומית או בענן בחוץ. עם עננים אחרים, אתם משתמשים בשרותי ה-Kubernetes של ספק הענן כך שהשינויים להריץ דברים מקומית או בענן הם די מינוריים וניתן להפריד את ההגדרות לקבצים שונים. בהמשך השנה, גם אמזון וגם גוגל יציעו לכם ברזלים ותוכנה להריץ את השרותים שאתם מריצים בענן – מקומית ובענן, כמו ה-Azure Stack.
  • שימוש ב-OpenShift – מערכת OpenShift קיימת לשימוש מקומי בשרתים שלכם או ב-OpenShift בענן שקיים אצל כל ספקיות הענן.

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

אם יש לכם שאלות, אתם מוזמנים לפנות אליי.

כמה מילים על KVM ועל Open Stack

אנשי IT רבים, כשהם מדברים על וירטואליזציה, הם מדברים בד”כ על אחת מ-2 הפתרונות הידועים: VMware עם סל הפתרונות שלו או פתרונות מבוססי Hyper-V של מיקרוסופט. חלק קטן מהאנשים גם מכיר פתרונות מבוססי Xen כמו הפתרון של Citrix.

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

חלק עיקרי מ-Open Stack הוא החלק של הוירטואליזציה, העיבוד, ה-Compute ולמרות ש-Open Stack יכול לעבוד כמעט עם כל פתרון וירטואליזציה, בברירת המחדל שלו הוא משתמש ב-KVM של רד האט.

KVM שבעבר נתפס כמשהו “נחמד” אך רבים העדיפו לא להיכנס אליו (ואם להשתמש בפתרון מבוסס קוד פתוח אז פתרון מבוסס Xen), נתפס היום ככלי וירטואליזציה רציני מאוד. חברות כמו גוגל עם ה-Compute Engine שלה משתמשת ב-KVM, חברות Hosting רבות יורדות לאט מהפתרון שיש להם ועוברות להשתמש ב-KVM, וגם חברות שמציעות שרתים וירטואליים ממש בזול (כמו Digital Ocean) נותנות את הפתרון עם KVM ולא עם פתרונות וירטואליזציה אחרים. גם חברות ענק כמו IBM שבעבר היו נותנות פתרונות מבוססי VMWare או פתרונות אחרים, נותנות כיום פתרונות עם KVM ועם תוכנות נוספות משלימות. כך לדוגמא IBM מציעה פתרונות VDI עם שילוב פתרון של VERDE כאשר הוירטואליזציה עצמה היא KVM “נטו”.

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

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

יתרון גדול נוסף הוא שגם מבחינת Middlewear אינך מוגבל. אתה משתמש ב-SAN כלשהו? כל עוד אותו SAN יודע “לדבר” בפרוטוקולים כמו iSCSI או NFS וכל פתרון לינוקס/יוניקס ידוע, הוא יוכל לעבוד עם KVM. אתה מעוניין ב-Switch וירטואלי חזק שיודע לעשות פילטרים, QoS ודברים אחרים? פתרון כמו OpenVSwitch ישמח לגשר בין המכונות הוירטואליות שלך ולתת לך את מה שאתה צריך. פתרונות מבוססי VDI ל-Windows או Linux? אם זה Windows, אז יש לך פתרון RDP כבר בתוך ה-Windows (ומעליו יש לך VLC לראות את ה-Boot אם אתה רוצה), ובלינוקס אתה יכול להשתמש בפתרונות כמו NX שיחסוך לך תעבורה וגם יתן לך איכות תצוגה מעולה.

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

  • רוצה לעבוד עם סקריפטים? (סביר להניח שהתשובה שלך תהיה “כן”): אז הפתרון הראשי שתרצה לבדוק הוא Libvirt שנותן לך תמיכה בכל שפת סקריפטים ידועה ואפילו בשפה כמו #C. עם Libvirt אתה יכול לעשות אוטומציה להכל, כיד הדמיון הטובה עליך.כלי שיכול לעזור לך הרבה בתוך Libvirt הוא virsh, שניתן להריץ אותו דרך shell ולבצע דברים. אגב, עם Libvirt ניתן גם לנהל מערכות וירטואליות מתחרות כמו vCenter או שרתי VMware בחיבור יש ל-host.
  • רוצה קצת GUI על הלינוקס שלך? (נו טוב, יש גם כאלו). לשם כך יש כלי כמו Virt-Manager. עם הכלי הזה תוכל בקלות להרים מכונות, לראות צריכת משאבים וכו’. זה ל-vCenter כמובן, אבל זה כלי בסיסי מספיק כדי להתחיל ללמוד וגם לעקוב אחרי מערכות קיימות שרצות.
  • מה עם כלי רציני שרץ דרך דפדפן? אה, טוב ששאלתם, בשביל זה יש את oVirt. זה הכלי הכי רציני שנותן לך לנהל הכל ב-KVM.

אז מה ההבדל הגדול בין KVM ל-Open Stack? אפשר להשוות את ההבדל ביניהם להבדל בין vCenter ל-vCloud Director. ה-Open Stack מתאים למצבים שיש צורך בהמון, המון מחשוב ענן של אלפי שרתים וירטואליים, פריסה על פני כמה Data Centers, צורך בשרותים דמויי AWS של אמזון (כמו S3 וכו’) ובקיצור – כשמדובר על דברים גדולים, Open Stack יכול בהחלט להיות אופציה טובה.

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