כשהאתר דורש יותר ויותר משאבים בפתאומיות

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

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

  • הגדלת משאבי המכונה הוירטואלית (יותר זכרון, יותר ליבות)
  • אופטימיזציה של מערכת האתר – טיוב שאלות SQL, בניה יותר טובה של Cache, אולי מעבר ל-NGINX, שינוי PHP לעבודה כ-FPM ועוד ועוד..
  • שכפול והקמת מכונה זהה ומעל המכונות Load Balancer תוך מתן פתרון גם ל-SQL (שיטות Master/Slave, Multi Master ועוד)
  • אם אתם משתמשים בשרותי ענן כמו אמזון ושרותים כמו RDS, אולי תעברו ל-Instances יותר גדולים, אחסון יותר מהיר וכו'.

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

אך לשיטות האלו יש מספר בעיות:

  • אם האתר עצמו מאוחסן ב-NFS או OCFS2 לדוגמא, תקלה בקוד או חדירה ע"י פורץ ושינוי הקוד (כמו במקרים של Defacement) – תשפיע על כל השרתים שלך. כנ"ל בעת שדרוג -אם השדרוג לא מצליח, שום אתר לא באוויר וכולם מקבלים את אותה שגיאה. בנוסף, אתם מייצרים צוואר בקבוק חדש מכיוון שכל פעם שהאתר צריך ולו את הקובץ הכי קטן – הוא צריך לבצע קריאה ל-Storage, ו-NFS לדוגמא פשוט לא מתאים לזה, אתם יוצרים צוואר בקבוק חדש.
  • מחיר – להוסיף עוד VM + Load Balancer זה לא כזה יקר (לעסק שמתפרנס [גם] מהאינטרנט לדוגמא), אבל כשאתה צריך להוסיף עוד 20 מכונות VM העסק מתחיל להיות קצת יקר וזה לא חשוב אם מדובר בספק אירוח ישראלי או בענן ציבורי.
  • תחזית: כמה הולכים להיכנס לאתר? אתה לא יודע. אתה יכול להעריך בהערכה גסה, אבל אתה לא תדע אם יכנסו פחות או יותר ואם אנשים לא עפו מהאתר או לא הצליחו להיכנס בגלל שהשרתים היו עמוסים, בגלל תקלה, ובקיצור – עניין הניחוש הזה קשה כמו לנחש כמה אנשים יגיעו לחתונה..

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

מכונות VM הם פתרון טוב, אבל יש כיום פתרון יותר טוב והוא כמובן קונטיינרים: אפשר להקים קונטיינרים שיריצו את הקוד PHP, קונטיינרים שיתנו את שרות ה-WEB עצמו, קונטיינרים ל-SQL, קונטיינרים ל-Cache וכו'. הקונטיינרים עצמם אינם דורשים משאבים גדולים – מכיוון שהקונטיינר לא צריך את כל מערכת ההפעלה מותקנת בו אלא אך ורק חלק שצריך להריץ אפליקציה ספציפית, אפשר להפעיל קונטיינרים עם כמות זכרון קטנה (נניח 512 מגהבייט זכרון) בהתאם לצרכים. בנוסף, קונטיינרים הם דבר שניתן לשכפל מאוד מהר (בניגוד ל-VM – קונטיינר משוכפל בשניות). כך בעצם ניתן "להמיר" את האתר שלך למספר קונטיינרים שישוכפלו בין מכונות VM (או Instances), תקבל Load Balancer בחינם, והמערכת תדע לגדול ולקטון בהתאם לצרכיך.

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

  • להקים מספר קונטיינרים שיתפזרו בין VM שונים, יאוחדו לקבוצות וכך המערכת תוכל "לדבר" בין החלקים
  • אם יש תקלה בקונטיינר מסוים, אפשר להרוג אותו והמערכת תקים מיד קונטיינר אחר זהה, כך שאם לדוגמא מישהו פרץ לקונטיינר מסוים, הפגיעה היא מקומית (תלוי כמובן בהגדרות היכן נמצאים הקבצים שנפגעו – בקונטיינר או על NFS/OCFS2 וכו'), ניתן להרוג את הקונטיינר ולהמשיך (כדאי כמובן לתקן את הקוד)
  • עם מערכת כמו Kubernetes ניתן לבצע תהליך הטמעה של גירסה חדשה כך שעדיין ישמרו גירסאות ישנות ולעבור לחדשות לפי קצב שיוחלט (לפי גילוי באגים ותיקונם וכו') וכך יחסך מצב של השבתת מערכת רק כי צריך להחליף גירסה.
  • אפשר להשתמש בהפצות לינוקס אחרות (או בקונטיינרים של Windows – אם אתם מריצים WIndows Server 2016) בתוך הקונטיינרים כך שאין זה משנה מה ההפצת לינוקס שמותקנת על ה-VM עצמו.
  • אין צורך בהגדרות זהות פר VM – ישנה מערכת ETCD שדואגת שההגדרות בין ה-Nodes יהיו זהות לחלוטין בין אחת לשניה באופן אוטומטי.
  • יעילות פר VM – הפצות כמו Atomic, CoreOS, RancherOS ואחרות – ניתן להתקין אותן על ה-VM ובכך לחסוך RAM שתפוס בד"כ על ידי הפצת הלינוקס ב-Node עצמו (אחרי התקנת הפצות כפי שציינתי לעיל – הזכרון התפוס נע בין 50-100 מגהבייט בלבד וה-Node גם עושה Boot מאוד מהר) ובאותו זכרון פנוי ניתן להשתמש לטובת הקונטיינרים.
  • על אותה מערכת Kubernetes ניתן גם להעלות קונטיינרים אחרים עם גרסאות שונות של האתר, לא צריך VM חדש לשם כך.
  • ויש עוד יתרונות.

במילים אחרות: מערכת Kubernetes מאפשרת לכם בעצם לעבוד בצורה יותר מאורגנת כאשר כל חלק הוא נפרד ורץ בקונטיינר משלו, כך שיותר קל לטפל בבעיות שצצות במקום "לנחש" היכן הן. בנוסף, מערכת Kubernetes כוללת כבר את כל עניין גדילה, High Availability, שרידות, Load-Balancing ללא צורך בתשלום על שרותים אלו בנפרד.

אפשר כמובן לעבוד על Kubernetes בלבד (ויש כמובן גם API – שהוא יותר "client") לשפות שונות כמו PHP, Python, דוט.נט ועוד, אולם אם בחברה יש מספר מפתחים לאתר, אני ממליץ להשתמש בכלי כמו OpenShift Origin כדי לבצע את כל הדברים ב-Kubernetes (כולל דברים ש-Kubernetes לא עושה כמו בניית קונטיינרים, עבודה כמשתמשים וקבוצות ועוד) או בכלי אוטומציה אחרים לבצע הן את הדברים דרך Kubernetes והן את ה"מסביב".

מבחינת עבודה עם Kubernetes – המערכת הזו כתובה ופועלת מעולה – כשזה נמצא על ספק ענן ציבורי כמו גוגל או אמזון. אם זה בתשתית של ספק אירוח מקומי, יש צורך לבצע "שמיניות באויר" בכדי להתחבר למכונות הללו מבחוץ כי היא פשוט בנויה לשימוש פנימי כאשר תקשורת מבחוץ מגיעה דרך תשתית ספק הענן. ב-OpenShift לעומת זאת, פתרו זאת עם HA-PROXY ועם ניתוב חכם כך שאין צורך להסתמך על שרות כמו Load Balancing של ספק ענן חכם ואפשר להשתמש בפתרון המובנה.

מבחינה טכנית, לאלו שיש כבר אתרים גדולים, אין היום שום כלי למיטב ידיעתי שיכול לעשות לאתר שלכם המרה ממצב שהוא רץ על Shared Hosting או VPS/VM או Instance למצב קונטיינר. את הדברים יש צורך לבצע ידנית ויכול להיות שיהיה צורך לבצע מספר שינויים קטנים בתהליך העבודה (שימוש ב-GIT, הפרדה בין תהליכים ועוד) וכמובן יש צורך במחשבה ובבניית תהליך כיצד להכניס את OpenShift לעבודה אצלכם (כך שלא מדובר במשהו שמבצעים בכמה שעות או ביום עבודה אחד).

לסיכום: אם יש לכם אתר שמקסימום נכנסים אליו כמה מאות בודדים של מבקרים שרק קוראים מאמרים לדוגמא, מעבר לקונטיינרים לא יסייע לכם יותר מדי. לעומת זאת אם יש לכם אתרים (או אפליקציות Web – היינו הך במקרה זה) שניגשים אליהם אלפים, עשרות אלפים ומעלה – קונטיינריזציה של המערכת תוכל לעזור הרבה הן בעמידה בעומסים, שרידות ועוד. אגב, אם אתם התחלתם להשתמש ב-Windows Server 2016 – גירסת ה-Kubernetes האחרונה תומכת גם בכם. באם אתם רוצים לבצע את כל התהליך באופן יעיל – אני ממליץ להשתמש ב-OpenShift ולא ישירות ב-Kubernetes.

גילוי נאות
מעבר לקונטיינרים הוא שרות שניתן ע"י חץ ביז

הכלים שמתאימים לניהול תשתיות וירטואליזציה

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

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

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

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

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

ענן פנימי

יש לכולם כיום תשתיות וירטואליזציה כמו vSphere או Hyper-V ואותן תשתיות עושות את העבודה בצורה לא רעה, אבל לפעמים צריך להתרחב – להוסיף דברים כמו קונטיינרים, ושרותי AAS שונים פנימיים, בין אם זה DB, Storage, imaging ועוד ועוד והפתרונות שהזכרתי בהתחלה לא בנויים לתת את השרותים הללו (אם שמוליק מהפיתוח צריך DB של 2 ג'יגהבייט, עם הפתרונות שהזכרתי בהתחלה תצטרך להקים לו VM או להקצות לו ב-DB הראשי מקום, והקצאה לטסטים לדוגמא ב-DB הראשי זה לא בדיוק רעיון טוב).

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

מערכת Open Stack קיימת כקוד פתוח שניתנת להורדה כאן ובנוסף היא קיימת כפרויקט RDO למשתמשי Fedora/CentOS/RedHat. שימו לב, המערכת מאוד מורכבת ואינה מקבלת תמיכה רשמית.

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

קונטיינרים

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

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

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

ישנם פתרונות רבים בקוד פתוח לבצע את הדברים הנ"ל אולם הפתרון הכי פופולרי הוא Kubernetes שמאפשר דרך ה-Shell/CLI לעשות את הדברים הללו וכמובן ניתן להכניס את הכל לסקריפטים. Kubernetes מתאים למי שמכין קונטיינרים בעצמו / משתמש בקונטיינרים שניבנו ע"י אחרים, אולם Kubernetes אינו כולל את כל ה-Life Cycle של קונטיינרים ואינטגרציה עם כלי CI/CD, ממשק משתמש טוב, ניהול משתמשים ופרויקטים ועוד פונקציות רבות ש-Kubernetes אינו כולל.

לפיכך הכלי שאני ממליץ לדברים אלו הוא OpenShift (גירסה מסחרית) או OpenShift Origin (גירסת קוד פתוח) – של רד-האט. כלי נוסף שאני ממליץ עליו הוא Rancher שיתרונו הגדול על פני OpenShift הוא בכך שזו מערכת Multi Platform.

ניהול תשתיות וירטואליזציה

בין אם יש לכם בחברה OpenStack, קונטיינרים, vSphere, Hyper-V, או תשתית בעננים ציבוריים כמו Amazon AWS, Google Cloud Platform או Microsoft Azure – ניהול דברים אלו מצריך כלי ניהול נפרדים (או במקרה של כלי אוטומציה – כתיבת חלקים נפרדים).

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

חשוב לציין – Cloudforms הוא "כלי מתרחב" – כלומר זהו כלי שניתן להרחבה לא רק ע"י תוספים אלא ע"י כתיבה ב-YAML כל מיני פונקציות נוספות שמתאימים לארגון. רבים מנסים להשוות את Cloudforms ל-"vcenter עם תמיכה בתשתיות נוספות", אך השוואה זו מוטעית. Cloudforms יכול להתרחב בצורה משמעותית בהשוואה ל-vcenter/VCSA והוא כולל מערכת שלמה לביצוע Orchestration, Life Cycle, עמידה בסטנדרטים פנימיים ועוד.

תשתית וירטואליזציה מתחרה

מקודם התייחסתי ל-OpenStack שיכול להתאים להקמת ענן פרטי בחברה, אולם לעיתים חברות מחפשות מערכת "פחות מפלצתית", משהו שיותר מזכיר את ה-vSphere או את ה-Hyper-V. הסיבות יכולות להיות קשורות בתקציב קטן או שאין תקציב גדול להרחבת תשתית וירטואליציה ב-R&D, מעבדות וכו'. איך אמר לי לקוח פעם "תבנה לי מטוס בתקציב של רכב סובארו".

כולם מכירים כמובן את VirtualBox, אך כלי זה אינו מתאים לסביבה מעבר לכמה מכונות VM בודדות שרצות על ברזל יחיד. הפתרון הכי טוב שיש בקוד פתוח הוא oVirt (גירסת קוד פתוח) או RHEV (בגירסה המסחרית) של רד-האט. שתי המוצרים מבוססים על פלטפורמת KVM בלינוקס והמוצרים יודעים לא רק להתממשק לסביבות וירטואליזציה אחרות (במידה וצריך), אלא לעשות את כל מה שמצפים מתשתית וירטואליזציה: Live Migration, Cloning, High Availability, Fault Tolerance, Load Balancing ועוד.

סיכום

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

קונטיינרים: ה"קרב" בין OpenShift ל-Docker DataCenter

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

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

בימים האחרונים השתמשתי בגירסת ה-Trial ל-Docker DataCenter (ובקיצור: DDC), למדתי אותה, הקמתי אותה אצלי ב-LAB הקטן שלי. השתמשתי ב-Swarm שבתוכו (שזה בעצם ה-Scheduler ועוד) ובשאר הכלים שגירסת ה-Enterprise כוללת. הייתי צריך להקים כ-5 מכונות וירטואליות (Nodes) כדי שהדברים יעבדו, עוד לפני שיכלתי להקים קונטיינר אחד. בסופו של דבר, המערכת עבדה בצורה טובה, יחסית. (אם כי נתקלתי באיזה באג או 2 שמצאתי להם "עיקוף").

מבחינת מחיר: DDC אינו זול. מחיר גירסת ה-Enterprise פר Node הוא 1500$ לשנה (כפי שניתן לראות כאן, גללו לאמצע הדף). על מנת להרים מערכת Enterprise, תצטרכו לרכוש לפחות 5 רשיונות: manager, registry, cache – אלו הם חלקים שרצים כ-VM נפרדים ב-DDC, עוד Node ל-Worker (שעליו בתכל'ס רצים הקונטיינרים) ותצטרכו מינימום עוד אחד אם אתם רוצים שרידות ועמידה בעומסים. (אפשר כמובן להריץ את החלקים השונים כקונטיינרים, אבל Docker ממליצים להרים את החלקי ניהול כמכונות VM נפרדות), כלומר אנחנו מתחילים במחיר של 7500$ לשנה. כל Node נוסף – עוד $1500.

הבעיות עם DDC פחות קשורות לבאגים או תכונות, אלא בעיה כללית שיש לחברת Docker בכל מה שקשור ל-Enterprise. הבעיה הראשית שלהם מאוד מזכירה את ההתנהגות של חברת רד-האט בצעירותה: רד-האט היתה משחררת גירסת לינוקס חדשה כל שנה ושוברת את התאימות הבינארית בין גירסה לגירסה. גירסה 5 לא תאמה לגירסה 4, גירסה 6 לא תאמה ל-5, גירסה 7 היתה עולם אחר לגמרי שלא תאם לגרסאות קודמות מבחינה בינארית. כלי ניהול הגיעו ונעלמו כלעומת שבאו, ויצרני תוכנה וחומרה התעצבנו מכל המהלכים הללו והן הביעו את דעתן בשיחות מול רד-האט ובעיתונות הטכנולוגית. לקח לרד-האט במשך שנתיים להבין שהדרך הזו אינה מקובלת לא על יצרני תוכנה וחומרה, ולא על Enterprise וכך נולדה משפחת ה-RHEL (כאשר כל הפיתוחים ושבירת התאימות עברו לגירסת Fedora), וכיום RHEL ניתנת עם תמיכה ועדכונים ל-10 שנים. ב-Docker לעומת זאת, שבירת התאימות היא עניין שבשגרה לגבי מוצרי הקוד פתוח, ומה לגבי הגירסה המסחרית שחברות משלמות? אה, לזה הם מוכנים לתת עדכונים ותיקונים למשך .. שנה אחת. מי בדיוק ה-Enterprise שמוכן לקנות מוצר שיהיה לו תמיכה ותיקונים לשנה אחת בלבד ובשנה אחר כך ב-DDC תישבר התאימות? שאלה מעולה!

ב-רד האט, למודי הנסיון, הדברים שונים לחלוטין.

ברד-האט יודעים שחברות לא ששות כל כך מהר לשלם עבור מוצרים שמיועדים לסביבות פיתוח, טסטים, QA, סביבות אוטומציה וכל דבר שאינו פרודקשן, ולכן רד האט אומרת: קחו את מוצר ה-OpenShift Container Platform (ובקיצור: OSCP) בחינם או את גירסת OpenShift Origin היציבה (נכון להרגע זו גירסה 1.4, כל עוד אתה מארח את הכל על התשתית שלך או תשתית הענן שלך), רק תזכור – זה לא מקבל תמיכה! כלומר את OSCP אפשר להרים על הלאפטופ (מספיק מכונת VM אחת או על הפצת הלינוקס במכונה ללא VM) או בשרתים הפנימיים לפיתוח וכו'. מעוניין בגירסה מסחרית עם תמיכה? הנה המחירון של Grey Matter. כפי שאתם יכולים לראות, על כל Node המחיר הוא 2724 ליש"ט ואם ה-Node הוא שרת פיזי, המחיר הוא 6810 ליש"ט (זה לפני מו"מ כמובן) עם תמיכה לשנה, ויש גם מחיר ל-3 שנים תמיכה, סטנדרט או פרימיום.

כלומר אם נניח יש לך 4 מכונות VM בפרודקשן שיריצו את ה-OpenShift והקונטיינרים, ושאר המכונות הם פיתוח, טסטים וכו' ואתה רוצה שרות תמיכה מרד-האט למכונות הפרודקשן, אתה יכול לרכוש 4 רשיונות. זה בדיוק כמו שאצל חברות רבות שרתי הפרודקשן מריצים RHEL עם רשיונות ואילו שאר המכונות של העובדים, פיתוח, טסטים וכו' – מריצים CentOS.

בסופו של יום, 2 המוצרים מציעים טכנולוגיות שונות. האחת (DDC) משתמשת ב-Swarm כדי לנהל את ה-Scheduling, Load Balancing, FT וכו' ואילו השניה משתמשת ב-Kubernetes. רוצה לדעת מי יותר פופולרי? תשאל את המפתחים ואנשי ה-Devops בחברתכם מי מכיר מה, אתה תקבל תשובה מהר מאוד מדוע Kubernetes כה פופולרית (כי היא קלה להתקנה וניהול בהשוואה ל-Swarm). ה-OpenShift של רד-האט תומך בגדילה של עד 1000 Nodes, ועד 120,000 pods. במילים אחרות, עם מערכת OpenShift אחת אתה יכול תיאורתית לארח את האתרים ואפליקציות בגדלים ענקיים!

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

תכירו את Open Shift

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

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

אם נסתכל בתשתית ה-Corporate במחלקות הפיתוח לדוגמא, נמצא במקרים שרת SCM כמו GIT (או SVN, מרקיוריאל ואפילו רחמנא ליצלן .. CVS וכו'), אלו שהחלו להיכנס לעולם ה-CI/CD הקימו בוודאי שרת Jenkins ואולי כמה Slaves, אם החברה מפתחת ב-JAVA אז יש בוודאי איזה שרת Nexus, בנוסף ישנם מספר שרתים שמריצים אפליקציות Web, שרת Apache או NGINX (או IIS). הכל רץ טוב ויפה (כשזה רץ…), אבל כשצריך להגדיל את התשתית, מישהו יצטרך לחפש כדורים נגד כאבי ראש עם כל הבירוקרטיה שיש ב-Corporate.

עם Open Shift הדברים שונים. Open Shift (שאגב, היא מערכת PAAS לכל דבר ועניין!) משתמשת בקונטיינרים כדי להריץ את מה שאתה צריך כשכל דבר רץ בקונטיינר נפרד. יש לך אפליקציה ב-PHP שצריכה לכתוב ל-MySQL? כמה קליקים ויש לך 2 קונטיינרים, תוסיף Route ושתיהם מדברים אחד עם השני, שתיהם לא צריכים לשם טסטים לדוגמא להיות עם יותר מ-1 ג'יגה זכרון (סה"כ ל-2 הקונטיינרים) ושתיהם יחד לא יצטרכו יותר מליבה אחת של המעבד בשרת וזה ירוץ מעולה תחת POD יחיד (POD זו ההגדרה של מספר קונטיינרים שרצים בקבוצה). רוצים לגדול עם האפליקציית PHP? שתי קליקים עם העכבר בממשק ה-WEB ותוך שניות ספורות יש עוד קונטיינרים שמוכנים לקבל גולשים, ולא – אתה לא צריך לשבור את הראש על Routing, על Load Balancing וכו' – בתוך Open Shift יש את Kubernetes שעושה את העבודה לבד ברקע. כך גם אם קונטיינר מסוים יפול, המערכת תרים מיידית קונטיינר נוסף תוך שניות ספורות (במקום לחכות כמה דקות עד שיקום VM עם כל התהליכים שהוא צריך לאתחל) והמערכת יכולה להמשיך לתת שרות.

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

אז איך בעצם זה עובד? הנה תהליך עבודה פשוט לדוגמא:

מפתח כותב קוד ובודק אותו מקומית. לאחר שהוא מרוצה מהקוד, הוא "דוחף" אותו ל-SCM של החברה ואז מערכת ה-CI/CD נכנסת לפעולה (אם זה פרויקט קיים), מקמפלת את הקוד, מריצה בדיקות או מה שמוגדר ב-Pipeline ולסיום היא פונה ל-Open Shift. ה-Open Shift לוקח את הקבצים הבינאריים (Artifacts לדוגמא) ובונה מהם יחד עם הדברים שצריך (סביבת ריצה וכו') קונטיינר והמערכת מפעילה את הקונטיינר. המפתח יכול לקבל הודעה במייל שהכל מוכן וכשהוא נכנס לפורטל של Open Shift, יש URL שלחיצה עליו תעביר את המפתח לאתר שהקונטיינר מריץ. עכשיו המפתח יכול להוסיף תכונות, לתקן וכו' – והכל חוזר מחדש. מפתחים בד"כ לא עובדים לבד – והמערכת תומכת בקבוצות כך שמפתחים יכולים לעבוד יחדיו על אותו פרויקט.

צריך להריץ Deployment בשיטות כמו Blue-Green או AB? שתי השיטות נתמכות.

אחרי שהקוד מוכן, נרצה להריץ אותו בפרודקשן. מה אז?

כאן מגיע יתרון גדול של Open Shift. לא משנה איזו תשתית וירטואליזציה יש לך, תהיה הפופולרית ביותר או אזוטרית ביותר, בין אם זה מקומית או בענן פרטי או ציבורי – Open Shift תרוץ. כל מה שאתה צריך זה מספר מכונות VM (או ברזלים פיזיים) ו-Subnet כתובות פרטי וציבורי. מה שנשאר לך לעשות זה להקים Open Shift במכונה אחת (או כאשכול), "לשדך" את שאר מכונות ה-VM שיריצו מערכת Atomic Host (זו גירסת לינוקס מאוד מצומצמת שנועדה להריץ קונטיינרים) ומשם לקמפל את הגירסה היציבה ולהריץ אותה עם רפליקציה. מערכת ה-Kubernetes הפנימית תדע להפיץ את הקונטיינרים בין מכונות ה-VM (וכן, יש גם Auto Scaling ו-HA) ואם אתם מריצים את זה בענן, שרות ה-Load Balancer ידע להעביר את התעבורה ל-IP חיצוני (לא צריך ציוד יעודי יותר בתוך החברה שיעשה LB). קונטיינר נופל? VM נופל? המערכת תדע להתאושש לבד.

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

עד כה כל הטכנולוגיה שדיברתי עליה מדברת על הרצת דברים שכתובים ללינוקס, אבל מה עם אלו שכותבים ב-DotNet? ובכן, מאז שמיקרוסופט ורד-האט חתמו על הסכמי שת"פ, האהבה פורחת ביניהם וכיום ניתן לקחת אפליקציות שכתובות ב- #C עם DotNet ולבנות אותן על לינוקס ולהרים קונטיינר כזה. בשלב זה טכנולוגיות הקונטיינרים של מיקרוסופט עדיין לא עובדת ישירות טוב עם Open Shift אבל אפשר לבנות להריץ אפליקציות כפי שציינתי. אגב, ניתן לשלוט על Open Shift בעזרת ה-CLI גם מתוך Windows (כל מה שצריך זה להתקין Ruby, Git ולהריץ מספר קטן של פקודות).

להלן הדגמה של ASP שרץ עם Open Shift:

הוידאו הבא ידגים איך מקימים מערכת CI/CD מלאה יחד עם Open Shift:

ומה לגבי הטמעת מערכת כזו בחברה?

גם כאן, כמו ב-CloudForms/ManageIQ ישנם מספר גרסאות:

  • יש גירסה שרצה על הענן של רד-האט ומשלמים Pay As you Go, בין אם ב-VM או בברזלים נפרדים.
  • יש גירסת קוד פתוח (גירסה שמהנדסי רד-האט מפתחים, יכולים לצוץ באגים!) שנקראת Open Shift Origin.
  • וישנה גירסת ה-Open Shift Enterprise בתשלום עם תמיכה לשנה או 3 שנים במסלולים שונים.

מבחינת הטמעה וקאסטומיזציה – זה מאוד תלוי בחברה ובדרישות. הקוד של Open Shift כתוב ב-GO.

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

לסיכום: קונטיינרים יכולים לחסוך הקמת VM מרובים ותחזוקתם. מערכת Open Shift יכולה להקל בצורה רצינית על כל תהליך הקמת סביבות הרצת טסטים, פרודקשן, ועוד. בכל מה שקשור למעבר לענן, Open Shift מקלה על בחירת ספקי ענן ובמקביל מגדילה את המבחר ספקים (כך לדוגמא אפשר להשתמש בספק כמו Digital Ocean עם מכונות במחירים זולים בהרבה מספקי ענן ציבורי ובמקרים רבים החבילה תכלול מספיק תעבורה כך שלא תצטרכו לשלם על כך בנוסף!)

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

שאלות ותשובות על Cloudforms/ManageIQ

מאז שפירסמתי את הפוסט לגבי Cloudforms/ManageIQ קיבלתי במייל מספר שאלות והחלטתי שזו הזדמנות טובה לפרסם את השאלות והתשובות בפוסט אחד (שאני אעדכן לפי הצורך). הסימון, כרגיל הוא ש: (שאלה) ת: (תשובה). למען היעילות, בכל מקום שאכתוב CF/MIQ אני מתכוון כמובן ל-Cloudforms/ManageIQ

ש: האם CF/MIQ מתאים להחליף את הממשק ה-Windows/Flash/Web של vSphere?
ת: באופן עקרוני CF/MIQ בהחלט יכולים להחליף הממשק הקנייני של vSphere (או vCenter כפי רבים מכירים זאת), כמו שהוא יכול להחליף את ממשק ה-SCVMM בכל מה שקשור למכונות VM, אבל שימוש בכלי כזה רק לשם החלפת ממשק כמוהו כחיסול זבוב עם תותח 🙂

חשוב – שימוש ב-CF/MIQ אינו מייתר רכישת vSphere. ה-CF/MIQ מתממשק ישירות ל-CF/MIQ ולפיכך יש צורך ברכישת הרשיון vSphere.

המטרה העיקרית של CF/MIQ היא לנהל Life Cycle מלא של מכונות VM, וכדי לייעל תהליכים להקמת VM שאינם קשורים ישירות לפלטפורמת ה-VM שלך (פרטית או ענן). תהליכים הקשורים לבירוקרטיה בחברה, אורך חיי VM, פורטל בקשות הקמת VM ע"י הצוותים השונים בחברה, מימוש נהלים, עדכוני אבטחה (בשלב זה במכונות Linux Guest) ועוד. אם נשווה את זה לכלים המוכרים בתחום VMWare למשל, אז זה משהו כמו vRealize Orchestrator + vCenter Server – רק ש-CF/MIQ לוקחים את זה צעד קדימה לאפשר לך להתחבר גם לפלטפורמות VM אחרות ולעננים פרטיים וציבוריים.

ש: אם יש לי מספר פלטפורמות VM שונות, האם מספיקה מכונה אחת עם CF/MIQ?
ת: לא. לכל פלטפורמת VM יש צורך במכונת CF/MIQ. כל מכונה מתחברת לפלטפורמת ה-VM והתקשורת מבוצעת למעשה בין שרתי CF/MIQ שמעבירים את הפעולות הלאה לפלטפורמת ה-VM השונה יחד עם המידע והתוכן.

ש: האם ניתן להשתמש בחלק מה-Appliances גם בגירסה הפתוחה (MIQ) וגם בגירסה המסחרית (CF)
ת: ברוב המקרים התשובה היא "כן", אבל אז אינך יכול לקבל תמיכה רשמית למערכות CF/MIQ. חברות שמעוניינות בפתרון, צריכות או להשתמש בגירסה המסחרית או בגירסה החופשיה (ללא תמיכה רשמית).

ש: האם ישנה פלטפורמת אוטומציה ב-CF/MIQ?
ת: בהחלט! בברירת המחדל CF/MIQ תומכת ב-Puppet יחד עם Foreman, ניתן להשתמש גם ב-Chef וב-Ansible.

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

ש: איזו גירסה יותר מעודכנת ועם יותר Features ואיזו גירסה נחשבת יציבה?
ת: ה-ManageIQ כולל את "המילה האחרונה" מבחינת תכונות המערכת. זו המערכת שמפותחת מדי יום (לתוך GIT מרכזי פתוח) וניתן לשלוף את הגירסה האחרונה או גרסאות קודמות. האם מערכת כזו נחשבת יציבה? כל עוד לא הולכים ל-Bleeding Edge (או ה-Master ב-GIT) – אז יחסית כן, אם כי יכולים לצוץ באגים פה ושם.

לעומת זאת ה-Cloudform זו מערכת שמבוססת על ManageIQ אם כי לא על הגירסה האחרונה של ManageIQ. לגירסה זו נערכים בדיקות ומתוקנים באגים ורק למוצר הרשמי ניתנת התמיכה הרשמית של רד-האט.

ש: מה המחיר של Cloudforms?
ת: עניין המחיר הוא דינמי, זה תלוי על איזו מכונה אתה מריץ את CF, כמה Appliances אתה צריך, מהו סוג השרות שאתה מחפש (NBD, 24/7 וכו'), האם אתם משתמשים בעוד מוצרי רד-האט וכו'. אינני יכול לתת מספרים אבל אני כן יכול לרמוז שהמחיר נמוך ממחיר vRealize Operations (ואתה מקבל יותר, ואף אחד לא "יושב לך על הצוואר" מבחינת כמות VM) 🙂

ש: אנחנו משתמשים באובונטו במערכות שלנו, האם המוצר (המסחרי או הפתוח) יכול לרוץ על VM אובונטו?
ת: מכיוון שה-CF הוא Appliance, הוא מגיע כ-VM מוכן שצריך רק לבצע לו Deploy, להגדיר כתובת IP (או DHCP), להיכנס למסך הניהול ולהגדיר את שאר הדברים משם (ניתן כמובן לבצע SSH ולהשתמש במכונה כמכונת לינוקס אם רוצים לשנות דברים, לא מומלץ אם לא מכירים CF/MIQ).
יחד עם זאת, אם אתם משתמשים בגירסת ManageIQ, ישנם הוראות ברשת איך להקים זאת על VM מבוסס אובונטו (ולכך כמובן לא ניתן לקבל תמיכה מרד-האט).

ש: היכן ניתן לראות רשימת Features שקיימים בגירסה האחרונה?
ת: הנה (לחצו להגדלה)

ש: בחברתנו חוששים להכניס מוצרים כאלו מכיוון שבמקרים רבים התיעוד לוקה בחסר. האם למוצר יש תיעוד מלא שנגיש ללקוחות?
ת: במקרה של Cloudforms כלקוח אתה מקבל גישה מלאה ואתה יכול להוריד את ההסברים וההוראות כקבצי PDF. בנוסף יש גם ספרות רשמית שניתנת להורדה.
גם ל-ManageIQ יש תיעוד (ברובו אותו תיעוד של Cloudforms) אולם יש לשים לב לשינויים שיש פה ושם בין ManageIQ לבין Cloudforms.

ש: האם למעט מחיר ה-Appliance (אם החלטנו לרכוש אותו) יש עלות נוספת שצריך לשלם לפלטפורמת ה-VM?
ת: במקרים של ספקי ענן ציבוריים, תצטרך לשלם לספק הענן הציבורי על Instance של מכונת לינוקס (לא ניתן בשלב זה לרכוש מכונה מוכנה + רשיון דרך ה-AWS Marketplace לדוגמא) + הדיסק והתעבורה.

ש: האם יש תמיכה ב-Cluster/High Availability?
ת: בהחלט! זה אחד הדברים הראשונים שהתיעוד מסביר איך לעשות אם אתה רוצה להשתמש במערכת כ-Cluster.

ש: כמה זמן לוקח לאינטגרטור מטעם רד-האט בארץ להקים PoC של Cloudform מקומית? האם יש גירסת Trial?
ת: זה מאוד תלוי ב-Scope של ה-PoC ותלוי במסמך ה-SoW. לדוגמא: הקמה של Appliance וחיבור לפלטפורמת ה-VM הנוכחית שלכם אפשר לבצע תוך יום עבודה. קאסטומיזציה, טפסים, כתיבת תוספים – אלו דברים שלוקחים זמן נוסף. כל פרויקט לגופו.

לגבי Trial – בהחלט יש.

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

ש: יש לנו שרתים פיזיים רבים (שאינם מריצים VM אלא אפליקציות יעודיות). האם CF/MIQ יכול לסייע בהקמה/ניהול?
ת: כן. ה-CF/MIQ כולל התחברות לשרת PXE וניתן גם להתממשק ל-IPMI שיש בשרת, כך שהוא יכול להתקין מערכת עם Kickstart ולהריץ עליה אוטומציה לבצע דברים שדרושים לשרת.

ש: יש תמיכה ב-LDAP/Active Directory?
ת: בהחלט. מטרת המערכת בסופו של דבר לתת למספר אנשים גדול בחברה להיכנס ולמלא בקשות שונות ולמנהלים לתת הוראות ואישורים.

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

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

כשזה מגיע לניהול מערכות VM

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

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

אבל מה לעשות, ברוב המקרים הטכנולוגיות הן שונות. להרבה חברות לדוגמא יש את Hyper-V מצד אחד או vSphere מקומי ומצד שני הם רוצים לעבוד עם אמזון או גוגל (או במקרים יותר מעניינים – Hyper-V עם אמזון או גוגל). אז לאמזון יש כלי שבקרוב יצא שיתן לך לחבר את AWS אל ה-vSphere שלך (חכו לחשבוניות השוק..), אבל גם פתרון כזה לא מכסה אפילו עשירית ממה ש-AWS מציע מבחינת שרותים וכשזה מגיע לחסכון – אתה חייב להכיר את השרותים השונים בכדי לחסוך. יש מקרים גם שצריך להרים עננים פרטיים (כמו ה-OpenStack) ומה לגבי קונטיינרים? מיקרוסופט ואחרים מאוד מעודדים להשתמש בקונטיינרים.

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

העניין הוא שחברות רוצות כלי שיש לו:

  • GUI
  • פופולריות רצינית בשוק כך שאפשר למצוא פתרונות לבעיות
  • שניתן להרחבה בקלות בעתיד
  • שיש לו "אבא" – שאפשר לקבל ממנו את התמיכה (ואם ה"אבא" לא אחראי על הקוד שלו, אפשר לתבוע לו את הצורה… שיטה מקובלת מאוד אצל האמריקאים, מה שנקרא indemnification).

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

תכירו את Cloudforms של חברת רד-האט.

ה-Cloudforms הוא כלי מרכזי שמאפשר למנהלי IT (ואחרים – כמו מפתחים, בודקי תוכנה ואחרים, הכל לפי הרשאות) לראות ולנהל את כל תשתית הענן שלהם ולא משנה ממה היא מורכבת. יש לכם Hyper-V? OpenStack? GCE? AWS? Kubernetes? ברזלים ללא VM? (ועוד רבים אחרים, יש ערימות תוספים) – אין שום בעיה. תגדירו אותם במערכת ותתחילו לעבוד. צריכים Orchestration? יש בפנים. רוצים לנהל אותה מבחוץ עם Puppet או Ansible? זה כבר כלול. רוצים גרפים יפים כדי להראות על מסך 50" בחדר ה-NOC? חיבור ל-Grafana מבוצע בקלות! צריכים להעביר VM מכאן בישראל לענן כלשהו ולא חשוב איזה ענן? אין שום בעיה! צריכים סטטיסטיקות מה קורה עם התשתית? כמה קליקים ויש לכם גם את זה. גדילה אוטומטית במקרים של עומס? יש. ויש עוד פונקציות נוספות רבות.

כלי כזה יכול לסייע ולהאיץ תהליכים בחברה בכל הקשור לתשתיות ה-VM/קונטיינרים שלכם. סתם סיטואציה: ספק ענן כלשהו בא עם הבטחות מכאן ועד להודעה חדשה והנה קרדיטים לנסיון. אין בעיה. חברו את החשבון שלכם בענן ל-Cloudforms ותנו למערכת להעביר כמה מכונות VM מכאן לשם. לא תהיו מרוצים? כמה קליקים ואפשר להעביר את המכונות בחזרה לתשתית שלכם מקומית או בענן שאתם כבר משתמשים.

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

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

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

איזה מהמוצרים מתאים לכם? אם אתם חברה שאין בה אנשי לינוקס עם ידע רציני, ואתם לוקחים אינטגרטור רק להקמה ואולי לתמיכה – אז גירסת ה-Cloudforms תתאים לכם (יש גם Trial ל-PoC). לעומת זאת, אם אתם חברה שלינוקס זה חלק מהתשתיות שלכם ויש לכם אנשי לינוקס עם ידע רציני, אז ManageIQ יכול להיות פתרון די טוב עבורכם (כל עוד אינכם צריכים תמיכה רשמית).

פתרון אלטרנטיבי אחר (גם מבוסס לינוקס) הוא SuSE Manager (עם תמיכה ישראלית של סוזה ישראל) והוא יותר מתאים לחברות שלא מחפשות להשתמש בשרותים שספק הענן מציע (SQL, מייל וכו') אלא אך ורק להריץ מכונות VM, לנהל את מכונות ה-VM, עדכונים, Policy וכו'. המוצר זמין כגירסה מסחרית בלבד (עם גירסת Trial ל-60 יום).

הנה וידאו של חברה גדולה (General Mills) שעברה להשתמש ב-Cloudforms.

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

על דיסקים SSD בתצורת NVMe/PCIe

בשנתיים האחרונות נכנסה טכנולוגיית דיסקים (SSD) חדשה לשוק – טכנולוגיית ה-NVMe SSD (או PCI SSD – זה אותו דבר). רבים לקחו את עניין ה-SSD הנ"ל כמשהו שהוא יותר אבולוציה מאשר רבולוציה. עד היום היה לנו דיסקים SATA, NL-SAS, SAS ועכשיו יש לנו PCI/NVMe. לא?

זהו, שלא כל כך.

טכנולוגיית ה-NVMe משנה את כל עניין התקשורת של הדיסק SSD עם המחשב. בעבר בכל שרת שמכבד את עצמו היה בקר RAID שאליו היו מחוברים דיסקים. בחלק מהמקרים הדיסקים היו מחוברים ל-2 בקרי RAID, בחלק מהמקרים חצי מהדיסקים בשרת היו מחוברים לבקר אחד והחצי השני לבקר אחר, כל יצרן והשטיקים שלו.

ואז הגיע ה-NVMe SSD עם "הפתעה": אין בקר RAID. תכניסו דיסק NVMe/PCIe לתוך השרת שלכם (אם הוא תומך בטכנולוגיה), כנסו להגדרות ה-RAID חומרה שלכם והופס .. הדיסקים החדשים לא מופיעים. לא, לא מדובר בתקלה. מדובר במשהו שתוכנן כך מראש.

בקרי RAID נועדו בראש ובראשונה ליצור לנו "אשכולות" של דיסקים שיחדיו יוכרו כ-RAID Volume. קח לדוגמא אנו יכולים לקחת מספר דיסקים ולבנות RAID 5, או 2 דיסקים ולבנות מהם RAID-1 או RAID-0 אם אנחנו רוצים לאכסן דברים שלא אכפת לנו שימחקו אם דיסק נפל (לדוגמא: Cache לאפליקציות). בקר ה-RAID גם "לקח אחריות" על כל מה שקורה מבחינת חיי ותקינות הדיסקים: בעיות כתיבה/קריאה? הוא יקרא מדיסק אחר. צריך לשמור נתונים בעת הפסקת חשמל? יש זכרון וסוללה על בקר ה-RAID וכך הנתונים ישמרו עד שיחזור החשמל וכשהוא יחזור הבקר יכתוב את הנתונים בצורה נכונה לדיסקים. זה הרעיון המרכזי של בקר RAID.

ב-NVMe לעומת זאת, הדיסק לא מדבר לשום בקר. הדיסק, כמו כל כרטיס PCIe, מדבר ישירות למערכת דרך ה-DMI, כלומר הנתונים עוברים ישירות אל הזכרון (RAM) בשרת וכך נחסך כל ה"תיווך" של הבקר.

אבל עדיין – כמו שכולנו יודעים – צריך בקר לאמצעי אחסון. יש תקלות קריאה/כתיבה, צריך לשמור נתונים בעת הפסקת חשמל, וכאן בדיוק הסיבה מדוע דיסק NVMe הוא דיסק שהוא יקר מדיסק SATA SSD או SAS SSD. בתוך הדיסק עצמו יש בקר (בחלק מהמקרים עם מעבד ARM בעל 2 או 3 ליבות) שכבר מטפל בכל עניין תעבורה ותחזוקת הנתונים. הדיסק עצמו מחולק פנימית ל-RAID-0 (רק בניגוד ל-RAID-0 רגיל, במקרה ויש תקלה בנתונים, הבקר יודע לטפל בה מבלי שהנתונים ינזקו), יש "סופר כבלים" (Super Capacitors) שיודעים לשמור נתונים במקרה של הפסקת חשמל, ומבחינת ביצועים – ה-NVMe ל-Enterprise נע בסביבות ה-2.4 ג'יגהבייט כתיבה לשניה ו-3 ג'יגהבייט קריאה לשניה. יותר זריז מכל SSD RAID שתכינו!

ומה לגבי עמידות/שרידות? הרי לא תסכימו לזרוק את כל הנתונים על דיסק אחד מבלי שיהיה לכך איזה סוג של בטחון, והתשובה לכך נקראת DWPD או Endurance (תלוי ביצרן דיסקים). ה-DWPD מציין כמה פעמים אתה יכול לכתוב על כל הדיסק נתונים ביום והדיסק עדיין יהיה תקין. קחו לדוגמא את ה-DC P3600 של אינטל, שמתאים ל-Enterprise: אם נניח מדובר בגירסת 2 טרהבייט, אז אתה יכול לכתוב עליו עד 6 טרהבייט ליום (מחיקה וכתיבה) והדיסק יעבוד טוב ויעמוד באחריות יצרן.

אז כפי שניתן להבין – אין כיום שום בקר RAID לדיסקים PCI SSD ושיטת העבודה צריכה להיות שונה. חושבים לדוגמא להרים ESXI על מערכת עם 2+ דיסקים כאלו? בהצלחה, תצטרכו לפרמט כל דיסק כ-Datastore בפני עצמו. לעומת זאת, אם אתם מרימים מערכת הפעלה Windows, ודאו שמדובר ב-Windows 2012 ואם זה לינוקס אז Ubuntu LTD האחרון או RedHat/CentOS 7 ומעלה. בתוך מערכת ההפעלה תוכלו לבחור את הדיסקים ולהקים את ה-RAID שרציתם (ותרו על RAID-0 – לא תקבלו ביצועים יותר גבוהים בגלל הארכיטקטורה של NVMe ו-RAID-5 יהווה בזבוז ושחיקת דיסקים לשווא). כמובן שלשם כך יהיה כדאי לצרף לשרת דיסק SSD שאינו NVMe/PCIe כדי להתקין עליו את מערכת ההפעלה.

באם אתם חושבים להרים שרת קבצים (לא חשוב איזו מערכת הפעלה) שתהיה מאוד מהירה וניתנת לגידול בהוספת דיסקים או JBOF – אז מערכת מבוססת דיסקים כאלו (ועדיף שתהיה מחוברת לכרטיסי רשת 10 ג'יגהביט ומעלה בלבד!) תהיה פתרון מעולה. אם אתם רוצים פונקציות כמו הסטורג'ים הגדולים (טוב, לפחות חלק מהפונקציות) כמו DeDup, Compression וכו' – כדאי לחשוב על ZFS.

לסיכום: דיסקים PCIe SSD הם ההווה והעתיד בכל מה שקשור לביצועים. זה לא אומר שצריך לזרוק את כל הדיסקים SAS לפח (מגנטי או SSD) אבל אם משלבים את ה-NVMe SSD כדאי לקחת בחשבון את היתרונות שלו ולהיערך בהתאם ואם אתם קונים שרתים חדשים, אני ממליץ לוודא כי ניתן להכניס אליהם דיסקים של יצרנים אחרים (במיוחד סמסונג, סאנדיסק ואינטל – כולם מאוד אמינים, מנסיון) ואתם לא "נעולים" רק על הדיסקים שמשווק יצרן השרתים שלכם (כמו HPE דור 9) מכיוון שהתחרות בשוק כיום מאוד אגרסיבית והמחירים צונחים משנה לשנה בעשרות אחוזים. דיסקים כאלו גם יכולים להוות בסיס טוב אם אתם רוצים להרים אשכולות (Clusters) מכיוון שכל דיסק נחשב כמספר דיסקים+בקר RAID. השמיים הם הגבול.

אהההמ.. ואם אתם רוצים להקים "חייה" של דיסקים NVMe, תכירו את המכונות האלו של SuperMicro 🙂

על "ספריות" וריבוי עננים

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

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

הבעיה הכי גדולה בד"כ כשמנסים להתממשק במקביל לענן פרטי וענן ציבורי, זה שכל ענן מצריך סקריפטים ו/או אפליקציות שונות להתחבר אליהם. ה-vSphere Client שלך לדוגמא לא יכול לדבר עם Azure או GCE, ולמרות שניתן לחבר אותו ל-AWS, לא ניתן לבצע דברים מרובים שקשורים בסטורג' בענן כמו S3 או דברים אחרים (כמו EFS לדוגמא). חמור מכך – כשיש לך תשתית מורכבת בענן הפרטי ובענן ציבורי, שתיהם יצטרכו תחזוקה אחרת. אחרי הכל, אם אתה משתמש לדוגמא ב-CloudFormation של אמזון, זה לא יעזור לך ממש מול כל ענן אחר, פרטי או ציבורי.

ישנם מספר פתרונות לכך, כולם מבוססים על ספריית libcloud של Apache והם:

פתרונות אלו יכולים לתת לחברה חופש לעבוד כמעט עם כל פתרונות וירטואליזציה מקומית (למעט Hyper-V – זה יותר באשמת מיקרוסופט שעדיין לא מתקנת את התמיכה שלה ב-libvirt) ובמקביל מאפשרת לעבוד עם כל ענן ציבורי, מהגדולים ועד הקטנים (הרשימה המלאה כאן). כך לדוגמא, אם אתה רוצה להרים מספר מכונות עם תשתית רשת פשוטה לצורך ביצוע עבודות שונות, אתה יכול לבחור לדוגמא ב-Digital Ocean או Linode ששם המחירים יותר זולים מהמחירים של ספקי הענן הגדולים ובנוסף אתה לא משלם על התעבורה החוצה (עד 3 או 5 טרהבייט כל חודש). אינך צריך לבנות את הסקריפטים מאפס אלא פשוט להשתמש בספריית libcloud ובפתרון שמתאים לשפה שאתם עובדים איתה כדי להרים את התשתית, לבצע שינויים וכו' ובכך תוכל בשימוש בספריה הזו לשלוט בכל תשתיות הענן שאתם משתמשים ללא צורך בכתיבה מיותרת של ערימות סקריפטים.

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

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

עוד נקודות חשובות לפני מעבר לענן

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

הנקודה הראשונה היא עניין הידע הטכני שקיים באותה חברה. בסטארטאפים לדוגמא, כל עניין ההקמה, תחזוקה, הגדרות, אוטומציה – נופל על איש (או צוות, בהתאם לגודל הסטארטאפ) ה-Devops. מכיוון שרוב מוחלט של הסטארטאפים מקימים את התשתית שלהם בגוגל או באמזון, קיימת חובה מצד איש ה-Devops לדעת היטב דברים כמו Bash, Python הבנה של פורמט קבצים כמו JSON, YAML וכמובן אוטומציה כמו Puppet או Chef, Ansible. בלי זה – איש ה-Devops לא יתקבל לעבוד ב-Startup. זה שמישהו מכיר סיסטם Windows או ניסה פעם אובונטו וגם אם הוא יודע PowerShell, ידע זה לא ירשים את המראיין והוא יפסול את המועמד.

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

לסיכום נקודה זו: Azure יותר מתאים לחברות שיש להן תשתית בסיס שמורכבת מתשתיות מבוססות מיקרוסופט (AD וכו') וגם יש לאותה חברה שרתי Linux (סתם דוגמא: 70 VM של Windows ו-30 לינווקס) עם אנשים שרובם מבינים בתשתית של מיקרוסופט. אם המצב לעומת זאת הפוך, הפתרונות של גוגל ושל אמזון (לעניות דעתי) יתאימו הרבה יותר לעבודה.

הנקודה השניה החשובה לדעתי זו המחשבה של העברת מכונות אחת לאחת מה-DC שלכם לענן (לדוגמא: העברת 100 VM מה-DC שלכם לענן הציבורי). לא חשוב איך תסתכלו או איזה ספק ענן תבחרו, החשבוניות שתקבלו יהיו מבהילות מסיבה אחת פשוטה: שום ספק ענן ציבורי לא מחפש למשוך לקוחות רק כדי לארח את ה-VM שלהם כ"ספק טיפש" כמו אלפי ספקי VPS בעולם. כל הנקודה של ספקי הענן היא שתשתמשו בשירותים שלהם. אל תרימו Exchange לדוגמא, אלא תשתמשו בשרותי המייל שלהם. אל תרימו SQL משלכם אלא תשתמשו בפתרון ה-SQL שלהם ובכך תוכלו להתחיל בקטן ולגדול עד למימדים מפלצתיים, הכל בתשלום לפי שעה (חלקם לפי דקה) ובמקרים כמו אמזון (בחלק מהמקרים) – ההמלצות הם להשתמש בדברים כמו Serverless ללא צורך ב-VM יעודי, במקום להשתמש ב-Load Balancer הקלאסי שכולנו מכירים – להשתמש בשרות (החדש) ALB שעושה Load Balancing לאפליקציות במקום שכבות.

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

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

בהצלחה 🙂

המעבר לעננים

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

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

האם המעבר לאופיס 365 תגרום ל-Corporates השונים בארץ לעבור לגמרי לענן? לעניות דעתי – לא כל כך מהר. בשביל Mail, השהיה (Latency) של 100 מילישניות לערך אינה כזה עניין גדול, לא מרגישים את זה, אך כשמדובר ב-RDP או פרוטוקולים אחרים כמו HTTP ואחרים – העניין הופך לבעייתי ובכלל בארץ, בניגוד לסטארטאפים שמתחילים מהדקה הראשונה עבודה על ענן, ה-Corporates מאוד שמרנים ויקח זמן עד שהם יעברו לענן. גוגל, אמזון ומיקרוסופט מודעות בהחלט לעניין, ומיקרוסופט לדוגמא מכינה את ה-Azure Stack – הנה לך אדוני המנמ"ר/CTO "מיני Azure" שכולו יושב ב-Data Center שלך. כל ה-DATA שלך יושב בחווה שלכם ושום דבר לא זז החוצה אם לא תרצה, ואם תרצה – תוכל לחבר את ה-Stack הזה בקלות ל-Azure הענן. גם אמזון התכוננו לרגע הזה והם חתמו עם VMWare על פרויקט חדש שנקרא VMWare Cloud on AWS שנותן לך גם פתרון שמשלב את ה-Data Center שלך עם AWS כך שתוכל להתרחב מה-DC שלך החוצה ל-AWS (והפוך). גם לגוגל יש פתרון שהוא בפיתוח ובשלב זה אין עליו מידע פתוח.

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

ובכל זאת, חברות רבות "מסתקרנות" לגבי מעבר לענן. הסיפורים של כל מיני סטארטאפים איך הם נותנים שרות למליוני אנשים ומשלמים רק כמה אלפי דולרים בודדים בחודש לספק הענן גורם לסקרנות ולרצון להתנסות, המחירים בסנטים גם קורצים לחברה שמסתקרנת רצון לטבול אצבעות, ואז הן הולכות למחשבונים של ספקי הענן ואחרי מספר חישובים הן נרתעות. סתם דוגמא: באמזון, שרת Windows יחיד עם 8 ליבות ו-32 ג'יגה זכרון עם דיסק (EBS) של 200 ג'יגה יעלה לחברה $733 בחודש וזה כמובן לא כולל תעבורה החוצה וגם התמיכה של אמזון היא ברמת הבסיס. זול – זה לא. (אגב, גם בגוגל וגם במיקרוסופט המחיר יהיה פחות או יותר זהה) – אז הרעיון לנסות מעבר כלשהו נכנס בחזרה למגירה.

הרווח הגדול של ספקי הענן הגדולים מגיע מהשכרת שרתים ובמיוחד מהליבות (cores). הם מוכרים כל ליבה במחיר מוערך של 30-50$ לחודש וגם הזכרון אינו זול (בערך 10-20$ לחודש, תלוי בקונפיגורציה, מערכת הפעלה, סוג תקשורת וכו'). מדוע? כי כמות הליבות שניתנת למכירה בשרת אינה כה גדולה. שרת עם 16 ליבות אפשר למכור לדוגמא ל-20 לקוחות שכל אחד מקבל ליבה, אבל לא ל-30 לקוחות – כי הלקוחות רוצים ביצועים (בניגוד לספקי VPS שדוחפים עשרות לקוחות על מכונה עם 8 ליבות). ספקי הענן יכולים לרכוש שרתים עם 8 מעבדים כשכל אחד מהם כולל 16 ליבות לדוגמא, אבל העלות של שרת כזה גבוהה מדי בשבילם ולכן ברוב המקרים אם תבדקו מה המעבד שנמצא במכונה שלקחתם מספק הענן, תמצאו שהמכונה מכילה מעבדים כמו Xeon E5 26XX (כלומר מקסימום 2 מעבדים ועד 8 ליבות פר מעבד, ברוב הזמן זה יהיה דגם של 4 ליבות). יש לספקי הענן גם מכונות עם מספר מעבדים וליבות גדולים, אך המחיר – גבוה בהרבה מהמחיר שציינתי.

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

אז איך לדוגמא חברת X תוכל להתנסות בענן ציבורי מבלי לשרוף אלפי דולרים בחודש על PoC?

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

אחרי שפתחנו חשבון אצל ספק הענן, נצטרך לבחור מה הפרויקט שאנחנו הולכים להעביר ואלו VM הולכים לעשות מעבר, והכי חשוב – כמה ג'יגהבייט/טרהבייט אתם הולכים להעביר לספק ענן. אם מדובר לדוגמא בג'יגהבייטים בודדים או עשרות בודדות של ג'יגהבייט, אפשר להעלות את קבצי ה-VM דרך האינטנט, אך אם מדובר בעשרות או מאות ג'יגהבייט או יותר – כדאי להשתמש בשרותי ה-import/export Disk של ספק הענן, כלומר תצטרכו להכין דיסק קשיח (או פתרון אחר בהתאם לספק הענן) ולשלוח אותו לפי הוראות ספק הענן. המחיר – דווקא די זול, בסביבות ה-80$ ועוד 2.50 דולר פר שעת עבודה להעלאת הנתונים (אמזון לדוגמא).

לאחר שהנתונים יועלו לספק הענן, נצטרך להתחיל לבנות את התשתית המאובטחת שלנו מבחינת כתובות IP פנימיות, Subnet, Internet Gateway וכו' וכו' ולהחיל אותם על ה-VM שלנו שבענן (אצל חלק מהספקים יש צורך בהקמת ה-VM מהגיבוי שהעלתם/שלחתם, אצל חלק זה אוטומטי). אחרי שיש לנו את ה-VM למעלה, יכול להיות שנצטרך לשנות כתובות IP בהתאם לתשתית שהגדרנו. המטרה הסופית היא שבסוף כל ה-VM ששלחתם יעלו ותהיה לכם תקשורת אליהם בדיוק כמו שיש אצלכם ב-DC (אם כי ישנם שינויים שתצטרכו לעשות, כמו לא לתת כתובת IP חיצונית לכל שרת אלא לעבוד בצורה מסודרת מול Gateway או עם Bastion אם אתם עובדים עם מכונות לינוקס). הכל עובד? מצוין. בשלב זה תתחילו לעבוד עם המערכת כמו שהיא בימים או שבועות הקרובים. קיבלתם קרדיט, זה לא עולה לכם שקל, נצלו את זה 🙂

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

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

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

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

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

ולמי שמעוניין לעבור את התהליך או לקבל יעוץ – אשמח לסייע 🙂