לפני רכישה – כדאי לחשוב קדימה

כאן בארץ, לא חסרים ארגונים ועסקים שההתמחות שלהם היא בשיווק מוצרים לעסקים וחברות בכל מה שקשור ל-IT – בין אם מדובר בתוכנה, חומרה, שרותי אינטגרציה, תמיכה וכו'. זה הביזנס שלהם ומרביתם יכולים למכור לך כמעט כל מה שתרצה – בין אם זה כונן דיסקטים 5.25" ועד Mainframe – כולל שילוב ואינטגרציה של מה שהם מוכרים. לגטימי? בהחלט.

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

המקרה הראשון התרחש לפני מס' חודשים: קורא נאמן של הבלוג פנה אל עבדכם הנאמן בשאלה פשוטה: החברה הגדולה שהוא עובד שם מתכננים לרכוש 4 דיסקים Optane של אינטל מסוג P4800X דרך יצרן השרתים של החברה. הסיבה לרכישת הדיסקים האלו? מצגת שהראתה להם שבביצועי SQL – הדיסקים הללו יהיו מעולים לצרכיהם, הרבה יותר מכל סטורג' שהם יחברו (בקטע הזה המצגת צודקת. דגם ה-Optane הזה בהחלט מתאים ונותן ביצועים מטורפים!). הדיסקים האלו יכנסו לתוך שרת R740 של DELL, ימופו לתוך VM שיריץ שרת Windows Server 2016 ו-SQL Server. אמרתי לו שלדעתי תהיה בעיית ביצועים, אבל אם הם מעוניינים, אשמח לבדוק להם את העניין – בתשלום. החברה הסכימה. (בכל זאת, 2500$ פר SSD, כלומר $10000 דולר במחירי ארה"ב…)

תודות לכמה יבואנים הצלחתי להשיג את הציוד להשאלה אליי ל-LAB. השרת פורק, חיברתי את ה-backplane עם כניסות U.2, הצמדתי לדיסקים חיישני חום, הפעלתי והתחלתי להריץ בדיקות עומסים שונים. לקח 10 דקות עד שאחד ה-SSD הגיע ל-95 מעלות חום. כמה דקות אחרי זה שאר ה-SSD הגיעו בערך לאותו חום – והביצועים החלו לצלול. סיכום הדו"ח שלי ללקוח הצביע על הבעיה הפשוטה: הן שרתי ה-R740 (וגם כל שרת 2U של HPE או לנובו לצורך העניין) אינם מתאימים בתצורה זו ל-SSD מבוסס Optane של אינטל. הדיסקים הללו מפיקים הרבה יותר חום מדיסקים מכניים או SSD מתחרים. הדרך היחידה להכניס 4 כרטיסים כאלו היא לרכוש 4 SSD כאלו בתצורת AIC (כלומר כרטיס PCIe) ואז למפות אותם. עדיף במקום שרת 2U להשתמש בשרת 3U (אבל אז גם מחיר השרת מטפס הואיל ומה ש-DELL מוכרת בגירסת 3U זה שרת עם 4 מעבדים).

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

  • אבטחה – עם כל הכבוד ל-Kubernetes, הפלטפורמה עדיין אינה מאובטחת כמו OpenShift (תודות ל-SELinux ועוד מספר רכיבים).
  • Auditing, Compliance – בחברות גדולות ומשרדים ממשלתיים מאוד רוצים את זה.
  • מיגרציה בהמשך – תחשבו 4 שנים קדימה, אם Kubernetes עדיין תהיה קיימת, יהיה קשה מאוד להעביר אליה דברים שבנינו השנה לגירסה שתצא אז. במוצר כמו OpenShift היצרן מציע כלים לבצע מיגרציה.

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

המקרה השלישי קשור יותר ל"התלהבות" הולכת וגודלת לכל ה-Hyper Converge בוירטואליזציה (למי שלא מכיר: מערכות כמו vSAN, Simplivity, Nutanix מציעות להקים שרתים שיתנו את כל השרותים הכוללים Storage, Network, Compute – ללא צורך בסטורג' מאסיבי, סוויצ'ים יקרים וכו').

כמו תמיד, חברות כמו VMWare ואחרות לא המציאו מאפס את עניין ה-Scale Out הזה. מערכות File System ל-Scale Out קיימות זמן רב, כמו Lustre FS, מערכת Open Vswitch לצרכי Network, ופתרונות וירטואליזציה שונים הציעו זאת בסביבת HPC כבר זמן רב.  החולשה שיש ב-HPC קיימת בדיוק אותו דבר גם בפתרונות וירטואליזציה Scale Out: אם אתה צריך כמות IOPS מאסיבית של 7 ספרות ומעלה, תצטרך או לרכוש סטורג' יעודי או לרכוש הרבה יותר שרתים פיזיים מכפי שאתה צריך עבור Compute. אם אין לך צרכים כאלו, אז כן, פתרון Hyper Converge יכול להיות פתרון טוב.

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

טיפ: כשרוצים להוסיף דיסקים SSD מקומיים בשרת

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

בניגוד לשרתים רגילים שרוכשים מ-HP/לנובו/DELL ששם אתם מקבלים שרות מהקצה עד הקצה, בשרתי Tier 1 אתה מקבל אפס תמיכה טכנית (הדבר היחיד שכן מוכנים לעשות עבורך הוא להחליף ציוד תקול) והתשובה הקבועה שתקבל מהתמיכה הטכנית היא משהו כמו: זה שרת Tier-1, אין תמיכה טכנית, כך שאם מישהו רוצה לרכוש שרת כזה, עדיף שיכיר היטב איך לזהות חולשות ובעיות תכנוניות של לוח אם, איוורור, נתיבי PCIe מבחינה לוגית (לא רק פיזית) ועוד, אחרת בקלות אפשר לרכוש "פיל לבן". כך לדוגמא השרת בתמונה למעלה היה אמור להירכש על ידי חברה מסויימת בארץ – למטרת הקמת "סטורג'" מאוד מהיר (כל הדיסקים שנכנסים מקדימה הם SSD NVME בלבד). הם פנו לכל מיני אינטגרטורים שנתנו המלצה חיובית לרכישה ואז הם פנו אל עבדכם הנאמן דרך בלוג זה והמלצתי היתה שלא לרכוש מהסיבות הבאות:

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

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

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

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

טכנית, אני ממליץ לרכוש מיצרן השרת דיסקים SSD מבוססי SATA ולא SAS מכיוון ש-SATA Enterprise עבר כברת דרך ארוכה באמינות, ויתרון הערוץ הכפול לא רלוונטי בשרתים מודרניים הואיל ובקר ה-RAID הראשי מוטמע בלוח האם, כך שאם יש תקלה, השרת מושבת בכל מקרה. מבחינת ביצועים – כיום SATA עוקף SAS (ב-SSD).

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

יש לכם כבר 8 ורוצים להוסיף עוד? סביר להניח שתצטרכו בנוסף לדיסקים SSD לרכוש "Extension Kit" לשרת עצמו. אצל חלק מהיצרנים מדובר על מספר כבלים וכרטיס SAS Expander שאותו יש לחבר אל כניסות בקר ה-RAID ומה-SAS Expander לחבר את כל הכבלים אל ה-Backplane. יש מקרים שאתם תצטרכו לעשות זאת ויש מקרים שטכנאי מטעם היצרן יבוא ויעשה זאת (תלוי בחוזה שלכם מול יצרן השרתים). אם מדובר לעומת זאת בשרת ישן (נניח G7/G8 של HPE או R710/R720 של DELL או M2/M3 של IBM) – תהיה לכם בעיה כלשהי, ההסבר לגביה – בהמשך הפוסט.

יהיו מקרים, כמובן, שבחברה מסויימת ירצו להרחיב מעבר ל-16 דיסקים. במקרים כאלו בדרך כלל היצרן ימכור ללקוח כרטיס SAS Expander בערך כמו שיש פה בתמונה משמאל שמאפשר חיבור של 24 דיסקים. מבחינת חיבוריות – אין שום בעיה לחבר את הכל כמו במקרה של הרחבה מ-8 ל-16.

הבעיה – צוואר בקבוק.כמעט כל בקר RAID, בין אם מדובר בכרטיס ובין אם מדובר בשבב שנמצא על לוח האם, תופס 8 נתיבי PCIe (כלומר PCIe X8) ו-PCIe 3.0 X8 (שנמצאים בשרתים מודרניים) יכול להעביר ברוטו עד 8 ג'יגהבייט (קצת פחות בפועל). אם נזכור ש-SSD כשקורא נתונים – מעביר אותם במהירות של 450-550 מגהבייט לשניה, ונכפיל את זה כפול כמות ה-SSD בשרת (אני לא ממליץ על RAID-5 כמו שכתבתי לעיל, אבל מי באמת מקשיב?) – ואנחנו יכולים להגיע למצב שבקר ה-RAID "יחנק" עוד במצב של 16 דיסקים. אם כל הדיסקים (24) מחוברים ל-RAID והמערכת מוגדרת כ-RAID-5 על כל הדיסקים – הביצועים פשוט יצנחו בכל מה שקשור לקריאת נתונים. המצב חמור יותר בשרתים ישנים ששם בקר ה-RAID משתמש ב-PCIe 2.0 X8 שאז יש מחצית מרוחב הפס והבקר "יחנק" מ-8 דיסקים SSD אם המערכת קוראת וכותבת מכל הדיסקים במקביל.

לכן – אם מתעקשים להכניס לדוגמא 24 דיסקים SSD בשרת אחד (או בשרת ישן לעבוד עם יותר מ-8 דיסקים SSD), יש לשקול את האפשרויות הבאות:

  • להוסיף בקר RAID עם 2 כניסות SFF 8087 ולחבר אליו את ה-8 דיסקים SSD (אחרי 16). בשרתים ישנים אפשר לרכוש 2 בקרי RAID עם 2 כניסות SFF 8087 ולחבר אליהם את הדיסקים. החסרון בשיטה זו: אין RAID "המשכי" לכל הדיסקים, אבל גם לכך יש פתרון, המשיכו לקרוא.
  • לעצור ב-16 דיסקים.
  • לרכוש במקום בקר RAID – כרטיסי HBA (או כרטיס RAID במצב IT MODE) ולהקים RAID מבוסס תוכנה (כל מערכת הפעלה מאפשרת זאת, ויש גם תוכנות יעודיות לכך כמו FreeNAS, UnRaid, XPEnology ועוד). שימו לב – החלפת בקרים אינה דבר מומלץ ואינו נתמך רשמית על ידי יצרני השרתים.
  • לפצל לשרתים נפרדים. 2 שרתים עם 8 דיסקים SSD יתנו עבודה יותר מהירה.

לסיכום: זה שיש 24 מקומות לדיסקים SSD בשרת, לא אומר שהשרת באמת בנוי להפעיל 24 דיסקים SSD (ובשרתים ישנים – יותר מ-8 SSD במקביל, גם אם מדובר בבקר עם 4 כניסות SFF-8087), בדיוק כמו שרוב מוחלט של השרתים שנמכרים לחברות לא יכולים להפעיל 24 דיסקים SSD NVME (אל תנסו. תכנון הקירור, גם בדגמים הכי חדשים של DELL/HPE/לנובו לא מתאים לכך). עדיף לחלק את הדיסקים בין 2 מכונות פיזיות, ואם אתם מתעקשים "להפציץ" מכונה אחת בדיסקים SSD – עדיף לייעד אותה לשימוש כ-NAS עם מפרט נמוך ולהריץ את הדברים הדורשים ביצועים בשרת אחר.

תחום ה-VDI וענן – עדכון מצב

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

על מנת להבין את הבעיה, נתחיל בהתחלה הפשוטה: כל ספקי הענן ישמחו לאפשר לך לשכור מכונה (Instance או VM) מבוססת Windows, בין אם מדובר על Windows Server 2012, 2016 או אפילו 2019. אין שום בעיה. רוצה משהו כמו Windows 10 או גירסה מתחת? תשכח מזה. ספקית ענן כמו אמזון שמחה להציע משהו "דומה ל-Windows 10" לדוגמא. מה שתקבל בעצם זה Windows Server 2016 ששינו לו מספר גדול של ערכים ב-Registry, שהותקן עליו Windows Experience וגם מספר אפליקציות בסיסיות. יש גם את חבילת ה"פלוס" שכוללת אופיס, אבל אז אתה משלם תוספת שכוללת תשלום חודשי למיקרוסופט לא רק על ה-OS, אלא גם על ה-Office שמותקן ב-Instance. למכונה כזו אתה יכול להתחבר עם כלים שונים שמתאימים לכל מערכת הפעלה קיימת, כולל סלולרי/טאבלט/כרומבוק וכו'.

אז מדוע אף אחד לא מציע מכונה מבוססת Windows 10? אחרי הכל, שרות שידע להקים מכונה כזו מ-אפס או אפילו לקחת Sysprep שלך ו"להלביש" אותו על ה-OS זה לא משהו כזה מסובך לכתוב…

הבעיה מגיעה מכיוון רדמונד. מיקרוסופט לא רוצה (ולפעמים גם נלחמת באמצעים משפטיים) ששום ספק יציע שרות כזה, ולא חשוב אם מדובר בספק ענן ענק, או בחברת Hosting פצפונת. מבחינת מיקרוסופט, המוצרים היחידים מבחינת OS המוצעים לספקי Hosting וענן כאחד – הם אלו הכלולים תחת רשיון SPLA בהם הספק משלם למיקרוסופט כל חודש על רשיונות ה-Windows Servers (וכלים אחרים) ואת המחיר הוא מגלגל על הלקוח. במסגרת הדברים המוצעים ב-SPLA, אין שום הצעה/שורה למערכת דסקטופ כלשהי, ולא חשוב אם מדובר בגירסת Home או Enterprise.

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

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

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

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

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

בקיצור: אם ספקי הענן יציעו שרות של מכונות וירטואליות עם Windows 10 כ-שרות VDI והם יגבו כמו שהם גובים כיום על Instances, המחיר הכולל פשוט לא יהיה שווה מכיוון שעלויות התקשורת יהיו אסטרונומיות. החברות יצטרכו להציע חבילות Bundle הכוללות מספר טרהבייט תעבורה בחודש עם שרות VDI.

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

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

נקודות למחשבה לגבי מעבר לענן (2019)

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

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

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

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

נניח וירון בוחר את השיטה להחליף "ברזלים" – נניח R710/R720 ב-R740 – העלות שלו תהיה Fixed ומשולמת מראש. נניח לשם הדוגמא ש-R740 עולה 10,000$ ויש לו 3 שרתים ישנים והוא מעוניין להחליף את כולם, אז העלות תהיה בעצם 30,000$. במחיר הזה ירון מקבל את האפשרות להביר מכונות VM לתשתית החדשה תוך שימוש ברשיונות קיימים (בדרך כלל, קיימות גם חריגות) והוא יכול בהמשך להוסיף עוד מכונות VM ללא עלות נוספת (שוב, למעט מקרים של רשיונות ל-OS וכו').

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

אז בואו נחשב מחיר: יש לנו 50 מכונות VM שפרוסים על 3 שרתים והם יתנו שרות לפחות ל-3 שנים הקרובות. מחיר פר VM יצא 600$. אפשר כמובן לקצץ ולרדת ל-2 שרתים עם מעבדים חזקים מרובי ליבות וכמות זכרון משמעותית (נניח 256 ג'יגה פר שרת פיזי). חושבים שזה יעזור? מהרגע שעוברים ממעבדים כמו Xeon SP Silver למשהו יותר רציני – המחיר יטפס בכמה אלפי דולרים, כך שלא בטוח שאם נרד בכמות השרתים (אך נשדרג במעמד ההזמנה את אלו שאנחנו רוצים לרכוש במפרט יותר "כבד") זה יעזור. אנחנו יכולים לרדת במחיר VM מ-600$ נניח ל-500$ ואפילו $400. המחיר ירד יותר אם אותן מכונות VM יעבדו יותר שנים, כמו לדוגמא 5 שנים – אז אנחנו יכולים לרדת ל-$133 פר VM.

נניח עתה שירון רוצה להסתכל על הפתרונות בענן. שיהיה מה להשוות.

אז בואו נאמר שב-AWS ניקח מכונה צנועה, 2 ליבות, 8 ג'יגה זכרון, תעבורת תקשורת נמוכה ו-80 ג'יגה דיסק (EBS). המחיר לחודש – 80$. את המחיר הזה ניתן "לחתוך" אם ירון מוכן לשלם לשנה מראש או 3 שנים מראש על אותו VM. אם זה לשנה, הוא יצטרך לשלם $1740 ואם זה ל-3 שנים, אז הוא יצטרך לשלם $1159 (כלומר אפקטיבית הוא כביכול ישלם 32.20$ לחודש) – אז בתכל'ס ניתן להגיע למחירים טובים פר VM (זה קיים אצל כל ספקי הענן הגדולים, אגב). יש,אגב, מסלולים שונים, תלוי בספק הענן.

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

  • רוצים קו יעודי (MPLS) של 100 מגה נניח מחברתכם אל אמזון? זה יעלה כמה אלפי דולרים, לאמזון ולספק התשתיות שלכם.
  • לא רוצים פתרון MPLS אלא VPN? אין בעיה. התשלום יהיה על ה-Instance שיריץ את פתרון ה-VPN ועל התעבורה היוצאת מאמזון אליכם (משלמים על הכיוון מאמזון החוצה, לא להיפך)
  • יציאה לאינטרנט – אתם משלמים על כל ביט שיוצא החוצה לאינטרנט מהתשתית שלכם בענן, ותלוי גם לאן התקשורת יוצאת – כל אזור והמחיר שלו (המחיר הולך פר ג'יגהבייט)
  • רוצים לגבות את התכנים? רעיון מעולה! כל ספקי הענן מציעים שרותי אחסון שונים (כמו S3 ועוד) ויש עלויות של כמה סנטים פר ג'יגהבייט (תלוי בענן, ובסוג שרידות שאתם מחפשים עבור הגיבוי).
  • כתובות IP אמיתיות – כל כתובת עולה כסף ואם ביקשתם הקצאת כתובות ולא השתמשתם – המחיר פר IP קופץ פי 3-4 (המחיר הוא בדרך כלל ל-IP אמיתי בשימוש בסביבות 1-2$ לחודש)
  • החלטתם להשתמש בשירותים שונים כדי לחסוך הקמה ותחזוקה של שרות דומה? יש מחירים Pay as you go ויש מקרים שאפשר לשלם מראש ולחסוך. ככל שיש יותר שימוש, המחיר עולה.

(עכשיו אתם מבינים מדוע אני מתייחס לעננים המקומיים שמציעות חברות תקשורת מקומיות שונות שמריצות תשתית של VMWare או Hyper-V כבדיחה?)

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

  • ב-On Prem אתה משלם על הציוד פעם אחת ואם אתה רוצה להוסיף נניח עוד מכונות VM, העלות תהיה אפסית (למעט במקרים שצריך שדרוג ציוד).
  • ב-On Prem כשיש תקלה, אפשר לטפל בה מקומית 24X7 ולא תלוים בספק הענן (אם משתמשים בשרותים של ספק הענן לדוגמא) עד שיתקנו את התקלה.
  • בענן אפשר תוך דקות ספורות להתחבר לשרותים שונים שחוסכים הקמת שרתים/הגדרות/תחזוקה ואפשר להשתמש ישירות בשירות. כך לדוגמא, במקום להחזיק Cluster של SQL, אפשר להשתמש בשרותי RDS.
  • בענן מחירי ה-VM יותר זולים – אם מוכנים לשלם מראש.
  • בענן אתה תמיד רץ על תשתית חזקה ואף אחד לא מכניס את ה-Instances שלך למכונות שכבר עמוסות. במקרים רבים ה-Instances רצים על מעבדים יחודיים חזקים שלא זמינים לשוק הרחב.
  • שרותי תמיכה בענן ישירות מספק הענן – אינם זולים.
  • נקודה חשובה: ב-On Prem אין לך הפתעות במחיר או בחשבונית חודשית.
  • כשזה מגיע לתשלום – בענן אין "שוטף/שוטף פלוס". התשלום הוא בתחילת החודש הבא.

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

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

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

על דיסקים מכניים גדולים ו-RAID

מי שעוקב אחרי חדשות טכנולוגיות יכול למצוא אחת לכמה חודשים הכרזות של יצרני דיסקים שונים על דיסקים חדשים, לפעמים על שיטת קריאה/כתיבה חדשה. כך לדוגמא, חברת Showa Denko K. K. הכריזה כי היא סיימה לפתח ראש MAMR חדש לדיסקים קשיחים עבור חברת טושיבה, וטושיבה תוציא דיסקים קשיחים בגודל 18 טרה המבוססים על טכנולוגיה זו במשך השנה. צפו להכרזות דומות מצד שאר היצרנים.

כיום, בין אם יש לך שרת שאתה מכניס בו דיסקים קשיחים ומחבר אותו לבקר RAID כלשהו, ובין אם יש לך סטורג' קנייני – כל היצרנים ישמחו למכור לך דיסקים קשיחים גדולים – בין אם ישירות מיבואן יצרן הדיסקים ובין אם דרך החברה שרכשת ממנה את השרת או הסטורג'. רוצה מדף עם 12 דיסקים של 10 טרהבייט? בשמחה! תחתום פה ופה, תעביר כרטיס אשראי או תשלח צ'ק וטכנאי בדרך אליך להתקין את המדף לסטורג' ולהגדיר אותו. אין צורך לדאוג, גם הדיסקים הגדולים שנמכרים כיום נמכרים עם SAS Dual Port לחבר ל-2 כרטיסי RAID (אם אתה רוצה להכניס את זה לשרת, בסטורג' זה אוטומטי).

אבל האם זה שווה לרכוש את הדיסקים הללו? בכל זאת, אם קנינו מדף של 12 דיסקים בגודל 10 טרה, אנחנו נקבל ברוטו 120 טרהבייט, זה שקט להרבה זמן מבחינת אחסון פנוי!

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

לשם פוסט זה, נניח ויש לנו את ה-12 דיסקים של 10 טרה, והם מורכבים בסטורג' או בשרת עצמאי עם 2 בקרי RAID (או אחד, זה לא ממש משנה מבחינת מהירות קבלת נתונים, ה-Dual Port ב-SAS הוא יותר לשרידות, אם כי במצב שהולך לך בקר, אני הייתי ממליץ לך להשבית את השרת עד שיגיע טכנאי עם חלק חלופי. אתה לא רוצה לסכן את ה-DATA שלך!). נניח שהגדרנו RAID, נניח 5 או 6 (במצב של 1 זה הרבה יותר מסוכן) או כל "RAID" בסטורג'.

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

וכאן… מתחילות הבעיות והסיכונים צצים…

  • אם הדיסקים נמצאים בשרת והם מחוברים לבקר RAID (וזה לא חשוב איזה RAID הגדרתם, למעט כמובן 0 שאז הלך ה-DATA) – השחזור לא רק שיהיה איטי ויקח מספר ימים, אלא שאתם תסבלו מביצועים נמוכים מאוד באותם ימים הואיל וכל מערך ה-RAID צריך לעבוד בעצם כפול: גם לשרת את הצרכים שלכם, וגם לקרוא מהחלקים השונים של הדיסקים על מנת לכתוב את ה-DATA מחדש על הדיסק החלופי.
  • מכיוון שאתם מאמצים את המערכת – יש סיכוי שדיסק נוסף יפסיק לעבוד, הואיל והמערכת עובדת נון סטופ.
  • במקרים של שרת ו-RAID מבוסס בקר חומרה, הכתיבה היא "הכל" – גם אם היה לכם ב-RAID חומר בגודל 10 ג'יגהבייט, הוא יבצע Rebuild של 10 טרהבייט, מכיוון שבקר RAID הוא דבר די טיפש.
  • במקרים של סטורג' (או Software defined Storage) – שיטת ה-Rebuild תהיה שונה, וכמות ה-DATA שתיכתב על הדיסק תהיה כמו שאר הדיסקים באותו "RAID", כך אם יש חומר של 10 ג'יגה, יכתב 10 ג'יגה. ההבדל הגדול בין סטורג' לבין שרת עם בקר RAID חומרה – זה שהסטורג' יודע "להסתיר" את האיטיות עם דיסקים SSD, עם Flash Cache וטריקים אחרים, אבל עדיין – תורגש איטיות.

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

  • חברו את הדיסקים ל-HBA ולא לבקר RAID (אפשר לרכוש בקרי LSI עם IT MODE או להחליף להם קושחה).
  • השתמשו בתוכנה כדי לבצע RAID. יש הרבה פתרונות – החל מ-FreeNAS, ZFS, XPEnology, או Storage Spaces של מיקרוסופט. הכל תלוי בהעדפה שלכם.
  • השתמשו ב-SSD שהוא Mixed Intensed או SSD שמתאים ל-Enterprise אם המהירות חשובה לכם. ההמלצה שלי היא ללכת על Optane 900P או DC P4800X (אם יש לכם את התקציב) של אינטל על מנת לקבל Latency מאוד נמוך וביצועים גבוהים מאוד (שימו לב – אם השרת אינו חדש, אז ה-Optane לא יוכל לבצע Boot ואם בשרת אין תושבות PCIe 3.0 – אז הוא לא יעבוד).
  • אם אתם משתמשים ב-ZFS, אל תשכחו להגדיר תהליך "קרצוף" (scrub) של הדיסקים לפחות אחת לשבוע (התהליך עובר על כל ה-DATA והיכן שהוא מוצע בעיות, הוא משכתב את ה-DATA למקום פנוי אחר, כך שהעבודה תהיה חלקה).
  • גיבויים, גיבויים, גיבויים – תוכנות גיבוי זה טוב, אבל snapshots ברמת האחסון הם יותר טובים והשחזור הרבה יותר מהיר. דאגו שתהיה מכונה אחרת עם מקום פנוי לקבל את ה-Snapshots.

ככלל, לא חשוב אם האחסון שלכם הוא NAS שבניתם או סטורג' שקניתם, אם כמות האחסון שלכם נעה בין מאות טרהבייט לפטהבייט – עדיף לעבור לפתרון Scale Out (וכשאני מדבר על Scale Out אני מדבר על מספר מכונות [גם נקראות Nodes]) המכילים את הדיסקים או JBOD המחוברים לאותן מכונות. פתרונות כאלו יודעים להתמודד גם עם מצבים שמספר דיסקים קשיחים מתקלקלים במקביל ומענה לדרישה מוגברת של תעבורת נתונים הלוך ושוב לשרתים/מהשרתים.

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

השלב הבא בוירטואליזציה של Oracle

חברת אורקל, אחת מחברות התוכנה הגדולות והותיקות בעולם, מפתחת ומוכרת 2 מוצרי וירטואליזציה. הראשון, לדסקטופ, VirtualBox ניתן להורדה בחינם ולשימושים שאינם מסחריים (התוכנה עצמה היא חינמית גם בשימוש מסחרי אולם ה-Extensions חינמיים רק בשימוש שאינו מסחרי ומחייבים רכישה לשימוש מסחרי). המוצר השני של חברת Oracle בכל הקשור לוירטואליזציה הוא Oracle VM Server. מוצר זה הוא מוצר מסחרי שמיועד לארגונים, והוא בעקרון מבוסס Xen Server החופשי עם תוספות שאורקל כתבה. המוצר נמצא בשימוש אצל לא מעט חברות גדולות, לפחות בנק אחד בישראל (שידוע לי) ובעוד מקומות.

אחת הבעיות שחברת Oracle ניצבת בפניהם, כמו אצל ארגונים אחרים שמשתמשים ב-Xen Server, זה שפיתוח המוצר די "קפא" וחברת Citrix איחדה את המוצר עם מוצרים אחרים מתוצרתה. הגירסה החופשית מתפתחת בקצב איטי מאוד וכשמשווים להתפתחות של וירטואליזציה אחרת כמו KVM/QEMU – אז האחרון מוביל בכל פיתוח אפשרי, הן מבחינת תמיכת וירטואליזציה במעבדים אחרים (כולל מעבדי Power של IBM), ממשקים (API), ושל פונקציונאליות נוספת.

ואורקל .. בהחלט מודעת לכך.

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

(הערה: את כל הדברים אני כותב מתוך מעקב אחרי Mailing lists שונים שאני עוקב אחריהם בכל מה שקשור לפיתוח וירטואליזציה).

באורקל מודעים לכך שישנה אי תאימות בין Xen, מכונות וירטואליות שניבנו על הפתרון לבין KVM ופתרונות ניהול וירטואליזציה המבוססים על KVM כמו RHV/oVirt, עוד מהרמה הבסיסית של דרייברים. הדברים פשוט שונים, ולכן ב-Oracle מפתחים טלאים חדשים כך שניתן יהיה להריץ מכונות Xen באופן "טבעי" על KVM מבלי לשנות את ה-VM. הטלאים שפורסמו הם בבחינה RFC בלבד ולא מיועדים בשלב זה לאינטגרציה עם ה-Kernel אולם אני מאמין שבמהלך החודשים הקרובים לאחר שאורקל תאסוף פידבק מספק, הם יוציאו טלאים לשילוב ב-Kernel הרשמי וכמובן ישולבו במוצר העתידי של אורקל.

Xen, בסופו של דבר, הוא רק מנוע, Xen Server היא הפלטפורמה, כמו ש-KVM הוא בעצם המנוע של QEMU, ולכן צריך גם פלטפורמה חדשה, וכאן – למרות שאין שום הכרזה, ניתן לראות ב-Mailing Lists של oVirt – מיילים של עובדי אורקל (יש לא מעט מהם, מעובדים שונים) שמנסים לבדוק את ה-Oracle Linux ומריצים טסטים אוטומטיים שונים שהם כותבים.

המסקנה שלי לאחר מעקב של מס' חודשים אחרי המיילים: אורקל הולכת לבצע מעין "Fork" ל-oVirt ולהוציא מוצר מסחרי שבעצם מבוסס oVirt אך אני מהמר שעם ממשק משתמש אחר ועם תוספות שלא יהיו קיימים ב-RHV (הגירסה המסחרית של רד-האט) כמ יבוא מ-Xen Server של הגדרות ו-VM ללא צורך בהמרת המכונה לפורמט KVM ואני בטוח שיהיו גם תוספות אחרות שכבר קיימות ב-KVM ועדיין לא קיימות ב-Xen.

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

אני פחות שמח לראות חברות כמו רד-האט שעדיין אינה מבינה את הלקוח שמוציא את הצ'ק לרכוש את המוצר ואת צרכיו. לא מעט פעמים "נדנדתי" למנהלים שונים ברד-האט לבצע שינויים שאני בטוח שלקוחות שמעוניינים להתנסות במוצר ירצו – ולשווא (לדוגמא: להריץ מערכת מלאה של oVirt כ-Nested Virtualization, דבר ש-VMWare תמכה עוד בגירסה 3 שנקראה ESX-Server. דוגמא אחרת: כיבוי כל המערכת, מבלי שהלקוח יתחיל ללמוד Ansible, התאוששות מהירה מקריסת חשמל ועוד).

חבל ש-SuSE לא נכנסת לזירה, היה יכול להיות בהחלט מעניין.

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

עדכון ליבה בשרתי לינוקס – ללא Reboot

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

בלינוקס – ברוב המקרים אינך צריך לעשות Reboot לשרת גם לאחר שביצעת עדכונים. במקרה הכי גרוע אתה פשוט יכול להפעיל מחדש את השרותים שרצים על השרות – לאחר התקנת העדכונים. חברות כמו רד-האט ו-SuSE עושות את הכל כדי לשמור תאימות בינארית של 100% כך שקונפיגורציות ודברים אחרים פשוט אינם משתנים (ב-2 ההפצות, כשמתקינים גירסה חדשה של תוכנה על הגירסה הישנה, המערכת תייצר קבצי rpmsave באותה תיקיה שנשמרות בה ההגדרות של האפליקציה, כך שתוכל לראות מה השתנה).

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

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

לאחר זמן מה יצאה רד-האט עם kpatch וחברת SuSE יצאה עם Live patching. קנוניקל לא נשארה מאחור והם הכריזו על שרות שנקרא livepatch.

כל השרותים לעיל – הם בתשלום בלבד, כלומר העדכונים צריכים לעבור דרך מערכת עדכונים מורשית של ההפצה בלבד. לא מדובר באיזו חבילת RPM או DEB שאפשר להוריד ולהתקין חופשי על כל השרתים בחברה. ב-רד האט יש צורך לעשות זאת דרך שרות Satellite וב-SuSE דרך SuSE Manager. באובונטו נותנים בונוס למשתמשים – מי שנרשם, יכול לעדכן דרך שרות livepatch עד כ-3 מכונות דסקטופ בלבד (לא שרתים, זה כבר בתשלום).

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

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

לסיכום: אם יש לכם שרתי לינוקס בפרודקשן והם שרתים מבוססים על Red Hat או SuSE או אובונטו בתשלום – כדאי להשתמש בשרות ה-Live Patching ותחסכו לעצמכם דאגות על אבטחה וענייני Reboot.

עדכון מערכות לינוקס ו-Windows ממקום אחד

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

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

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

האם יש פתרון טוב לכך?

כן, ל-SuSE יש פתרון: SuSE Manager

תוכנת SuSE Manager מאפשרת מספר דברים:

  • לעדכן הפצות לינוקס חופשיות (CentOS, Scientific Linux, OpenSuSE, Fedora, Ubuntu)
  • לעדכן הפצות לינוקס מסחריות (Red Hat, Oracle Linux, SuSE SLE)
  • להתממשק ל-SCOM כך שניתן יהיה לעדכן את הפצות הלינוקס ישירות דרך ה-SCOM
  • לנטר את כל המערכות המבוססות לינוקס.
  • לבצע Provision ולהתקין לינוקס על מכונות פיזיות ווירטואליות (בשימוש AutoYast/Kickstart)
  • ועוד

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

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

ומה עם אלו שמעוניינים במשהו חופשי?

SuSE Manager ו-Red Hat Satellite מבוססות על תוכנה בשם Spacewalk, כאשר SuSE ו-רד-האט מוסיפים הרחבות משלהם, כך ש-Spacewalk לדוגמא לא מתממשק ל-SCOM ולא יאפשר עדכון מרוכז של מכונות לינוקס ו-Windows כך שניתן לעדכן רק מכונות לינוקס.

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

להתקדם בתחום

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

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

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

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

אז מה אתה יכול לעשות כדי לשפר את סיכוייך למצוא עבודה טובה בעתיד?

יש כמה דברים.

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

במקומות גדולים החל לצוץ לו תפקיד חדש לאחרונה (לא באופן רשמי, לפחות ממה שאני יודע) והוא "Cloud Admin" – מה שאתה עושה מקומית, עכשיו בענן, רק שבענן לא יחכה לך איזה סטורג' של Netapp/EMC, אין לך סוויצ'ים, אין לך פיירוול (את זה אפשר להוסיף, כ-Appliance) והכל בעצם נעשה בתוכנה, בין אם דרך ממשק ווב, אבל יותר דרך ממשק CLI וכאן כבר צריך ללמוד איך להגדיר דברים, החל ממכונות VM, נטוורקינג, דיסקים קשיחים וירטואליים ועוד ועוד. בלינק שפירסמתי לעיל יש גם קורסים לכל ספקי הענן הגדולים, כך שאפשר ללמוד שם גם איך להשתמש בענן ואיך לנהל משאבים. העננים הפופולריים ביותר הם של אמזון (AWS) ו-Azure של מיקרוסופט. קצת פחות פופולרי (והרבה יותר טכני) הוא הענן של גוגל, לכן מומלץ ללמוד לפחות את הענן שבו החברה משתמשת ואולי את הענן השני הפופולרי.

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

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

איש ה-Devops טוב צריך לדעת כמה דברים חשובים:

  • הוא צריך להכיר טוב לינוקס, ברמה של כתיבת סקריפטים, הגדרות לינוקס, ניהול חבילות
  • הוא צריך להכיר את עולם הקונטיינרים – החל משימוש ב-Docker כדי לבנות Images, והוא צריך להכיר Kubernetes (או OpenShift או Caas) כדי לבצע אורקסטרציה בין הקונטיינרים השונים שירוצו, שרותים, רשתות, Scaling ועוד.
  • הוא צריך להכיר כלי CI/CD על מנת לאפשר ביצוע Build אוטומטי דרך כלים כמו Jenkins או Teamcity לדוגמא.
  • הוא צריך להכיר כלי ניהול קוד טוב. כל כלי שיודע לעבוד עם GIT זה טוב, בין אם מדובר ב-Bit Bucket או GitLab או כלי אחר, וכדאי להכיר את הדברים לא רק ברמת ממשק הווב אלא גם להכיר את GIT עצמו.
  • "קוד כתשתית" – אחד הדברים ש"רצים חזק" כיום הם כלים שכותבים איתם "קוד" לניהול תשתית כמו הענן הפנימי שלכם בענן הציבורי, כלי כמו Terraform או Ansible או SALT הם כלים מעולים לכך.
  • שפות – BASH מאוד יעזור לכתיבת סקריפטים פשוטים, מומלץ להכיר גם Python.
  • שרותים – כל ספק ענן ציבורי מספק מאות שרותים שונים. תצטרכו עם הכלים הנ"ל להגדיר ולהשתמש בשרותים הנ"ל ואצל כל ספק ענן זה שונה. כן. Not Fun.
  • ניטור באופן שונה – מכיוון שיש הרבה שרותים שספק הענן מציע ולך אין גישה לתשתית השרותים, תצטרך להשתמש בכלים שונים לניטור, סביר להניח דרך כלי הניטור של ספק הענן.

כמו שאתם רואים – ערימה לא קטנה של דברים. אגב, כמעט את כולם ניתן ללמוד ב-Linux Academy בלינק שנתתי לעיל.

חשוב להבין – אף אחד לא מצפה שתכירו את כל מה שציינתי לעיל בעל פה ו"על השפיץ", אלא להבין את עקרון הדברים ואיך דברים עובדים ואולי שתוכל לתת דוגמא קטנה. אם לדוגמא אתה מכיר כלי כמו Bit Bucket ואין לך מושג ירוק ב-GitLab, או אם אתה לא מכיר מהזה Federation ב-Kubernetes אף אחד לא יפסול אותך בגלל זה.

לסיכום: לא לכל אחד מתאים להיות Devops, וזה בהחלט מובן. יחד עם זאת, חשוב לעדכן את הידע כדי להישאר רלוונטיים בשוק העבודה כשכירים. תמיד מומלץ לנסות ללמוד דברים חדשים ולהתנסות, וכיום לדוגמא רוב ספקי הענן יתנו לך איזו חבילה חינמית לכמה חודשים ואם אתם לומדים דרך ה-Linux Academy אז הם נותנים לכם 6 שרתים וירטואליים להתנסות (זמנית, השרתים נכבים אחרי שעה, אבל זה מספיק בשביל לבדוק פקודות או הגדרות מסויימות).

בהצלחה.

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

עבדכם הנאמן ממשיך בביקורים בחברות גדולות במשק הישראלי בנסיון להסביר יותר לגבי קונטיינרים, מערכות אורקסטרציה לקונטיינרים (מה שמבוסס 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.

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