ניהול עם אופטימיזציה מסייע לתפעול אמין יותר של קונטיינרים – חלק ג'

כתב: אנדריאס ניב, ארכיטקט ראשי לתחום השירותים הפיננסיים ברד-האט (Red Hat)

גילוי שירות (Service Discovery)

בשימוש בטכנולוגיות ותהליכים כמו מיקרו-שירותים (Microsevices), קונטיינרים ו-DevOPs, מסוגלים גופי IT להגיב במהירות ובגמישות לדרישות עסקיות חדשות.

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

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

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

הרחבת יישומים ותשתיות

כאשר מדובר בגידול (Scaling) – תהליך שייתמך על ידי מערכת ניהול הקונטיינרים – יש שני סוגים שונים:

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

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

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

אספקת אחסון Persistent

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

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

יתר על כן, אחסון Persitent משפר את חוויית המשתמש בתפעול של יישומי Stateful ו-Stateless. לכן קל יותר למנהלנים לנהל, להשתמש ולהקצות אחסון עבור יישומים.

פתרונות קוד פתוח מציעים פוטנציאל גדול יותר במונחי חדשנות

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

קונטיינרי Linux המבוססים על פורמט Docker נתמכים על ידי חברת IT מובילות רבות, החל מאמזון (Amazon), גוגל (Google) ו-HPE, דרך יבמ (IBM), מיקרוסופט (Microsoft) ורד-האט. לכן נוצר סטנדרט תעשייה אותו מעריכים גם ארגוני אנטרפרייז בכל המגזרים, אשר משתמשים בקונטיינרי Linux עבור פיתוח.

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

לפי Github, כ-1,000 מפתחים מחברות המספקות תוכנה ולקוחותיהם עובדים על פרויקט הקוד הפתוח Kubernetes, אשר יוצר את הבסיס לניהול קונטיינרים בפתרונות רבים.

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

לחלק א' לחצו כאן.

לחלק ב' לחצו כאן.