VMWARE – עמוד 5 – הבלוג של חץ ביז

הפתרון למעבר מ-VM לקונטיינר: Kubevirt

(הערה: לפני כשנתיים כתבתי את הפוסט הזה על Kubevirt. מאז דברים רבים השתנו ופוסט זה הוא פוסט עדכון לכלי).

כל מי שהתחיל ומשתמש בקונטיינרים, Kubernetes וכו' – מבין בוודאי שקונטיינרים אינם מכונות וירטואליות. בניגוד ל-VM, קונטיינר מקבל שרותי OS ממערכת ההפעלה המותקנת על ה-VM (או על הברזל) שמריץ את הקונטיינר, ולפיכך קונטיינרים ברוב המקרים הם דברים די קטנים בהשוואה למערכת הפעלה מלאה שמותקנת ב-VM, גם כשהיא מותקנת כ-Minimal.

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

ישנם גם מקרים שאי אפשר להמיר מכונת VM לקונטיינרים חדשים. מקרים כמו:

האפליקציה רצה ומבוססת על Windows
האפליקציה רצה על גירסת לינוקס מאוד ישנה
האפליקציה רצה על מערכת הפעלה שאינה מבוססת לינוקס
ה-VM נבנה ע"י מומחה חיצוני ולאף אחד אין מושג ירוק איך הדברים מוגדרים ב-VM (לדוגמא: Cobol ישן)

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

וכאן נכנסת לתמונה אפליקציית Kubevirt.

אפליקציית Kubevirt מרחיבה בעצם את Kubernetes/OpenShift ומוסיפה למערכת תמיכה בקונטיינרים מסוג נוסף: קונטיינר שמריץ VM. כך בעצם אפשר לקחת VM מהדוגמאות לעיל ו"להכניס" אותו לתוך קונטיינר, כך שנוכל להריץ אותו כמו שאנחנו מפעילים קונטיינרים נוספים, ובכך נוכל להשתמש באפליקציה שרצה ב-VM, נוכל לשכפל את הקונטיינר לפי פרמטרים שנרצה, נוכל לשדרג את הקונטיינר ועוד ועוד.

מאחורי הקלעים, מה ש-Kubevirt עושה, הוא להשתמש ב-KVM (הוירטואליזציה המצויה בכל לינוקס) ובספריית Libvirt וספריות נוספות בכדי ליצור POD ובתוך ה-POD להריץ VM. את אותו VM אנחנו נגדיר בעזרת קבצי YAML, כמו שמגדירים כל דבר ב-Kubernetes, וכך נוכל להגדיר כמות זכרון, היכן הדיסק הוירטואלי יושב, האם ה-VM יהיה בעצם Immutable (כלומר שכל שינוי ל-VM ימחק ברגע שה-VM "כובה"), ועוד פונקציות נוספות. הגישה ל-VM תוכל להתבצע בכלים הרגילים (SSH, RDP) או VNC וחיבור סריאלי וירטואלי (במקרה שמדובר בלינוקס או כל מערכת תואמת UNIX אחרת).

מכיוון שב-Kubernetes אפשר להשתמש בכל מיני "דרייברים" (Storage Classes, Volumes), נצטרך להמיר בשלב ראשון את הדיסקים הוירטואליים של ה-VM מהפורמט הנוכחי (VMDK ב-vSphere) לפורמט ש-KVM ו-libvirt יכולים להבין ולהשתמש. סוג הדיסק שאנחנו נצטרך יהיה RAW וכלי ההמרה (שצריך לרוץ תחת לינוקס) הוא virt-v2v (זה קצת יותר מורכב ממה שהקישור מראה). מהרגע שביצענו זאת, אנחנו "מנתקים" בעצם את ה-VM מהוירטואליזציה הנוכחית (נניח vSphere), אבל ה-VM עדיין נשאר ב-vSphere. ברגע שיש לנו את הקובץ בפורמט RAW, נוכל להשתמש בכלי כמו CDI כדי לבצע Import של ה-Image לתוך Volume שנגדיר. אחרי שהצלחנו (שוב, לא דבר כל כך קל, אלא אם אתם משתמשים ב-Openshift דרך ה-WEB UI), אנחנו נגדיר POD עם ה-VM ושם אנחנו נבחר דברים כמו כמות זכרון, מערכת הפעלה, וכו'. בזמן ההגדרות נוכל להוסיף דיסקים וירטואליים חדשים ל-VM ועוד. לאחר שהתהליך מסתיים ונפעיל את ה-VM, תופיע כתובת IP שדרכה נוכל להתחבר אל ה-VM.

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

Kubevirt עובד על כל גירסת Kubernetes מ-1.10 ומעלה, ו-OpenShift 3.11 ומעלה.
בשביל לקבל ביצועים טובים עם ה-VM, יש צורך בתמיכת Nested Virtualization (אם ה-Kubernetes שלכם רץ כמכונה וירטואלית).
עננים ציבוריים: אם אתם רוצים להריץ Kubevirt על ענן ציבורי, תצטרכו לבחור Instances שכוללים תמיכת Nested Virtualization. גם לאז'ור וגם לגוגל יש מכונות כאלו, ב-AWS אין ולפיכך ב-AWS מכונות VM כאלו ירוצו יותר לאט מאחר ומדובר באמולציית X86-64 בתוכנה.
דיסקים וירטואליים: מכיוון שאין Thin Provisioning בשיטה כזו, הווליומים יהיו גדולים (כמה שהגדרתם ב-VM בהתחלה תחת vSphere), לכן אם הגדרתם את ה-VM עם דיסק של 100 ג'יגה אבל השתמשתם רק ב-15 ג'יגה, הקטינו את הדיסק (הוראות נמצאות כאן אם מדובר ב-vSphere).
נקודה נוספת חשובה לגבי דיסקים וירטואליים: אפשר לצרף אותם ישירות ל-Image של הקונטיינר אך הדבר אינו מומלץ (אלא אם אתם רוצים להפיץ את ה-Image החוצה).
קישוריות ל-VM ותקשורת: במקור כברירת מחדל יש ל-VM חיבור רשת יחיד. יחד עם זאת ניתן להשתמש ב-Multus או Genie כדי להוסיף דברים רבים הקשורים לרשת: VLAN, Bridges, אפילו PXE Boot – תשתוללו חופשי.
ניתן לשכפל את ה-VM לפי כל פרמטר שתרצו כדי לעמוד בעומסים. לשם כך תצטרכו להגדיר בקובץ YAML את ה-AccessModes לפי הצרכים שלכם.
KVM – מכיוון שה-VM שלכם ירוץ תחת KVM, כדאי להכיר את KVM. תרימו מכונת לינוקס, תפעילו Nested Virtualization ותריצו את Virt Manager (נקרא גם VMM). יש המון פונקציות והגדרות וכדאי להכיר אותם לפני כן, אחרת תקבלו הפתעות (במיוחד אם מכונת ה-VM שלכם משתמשת ב-UEFI. יש תמיכה ל-UEFI אבל תצטרכו להגדיר כמה דברים לשם כך).

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

אם אתם רוצים עוד הסברים על Kubevirt כולל הדגמה של לינוקס ו-Windows Server 2012, אתם מוזמנים לצפות בקליפ (הארוך – שעה) הבא.

לסיכום: אם אתם רוצים לעבור לקונטיינרים והדבר היחיד שמפריע זה מכונה אחת (או מספר מכונות) שבעייתי להמיר אותן ידנית לקבצי Docker Images ושירוצו כקונטיינרים טבעיים, Kubevirt יכול לסייע בכך. חברות כמו SAP, nVidia, Cloudflare כבר משתמשות ב-Kubevirt. חשוב לציין: Kubevirt עדיין לא מוגדר כגירסה סופית (מצד שני, גם Kubernetes לא מוגדר כך). אם אתם משתמשים ב-OpenShift מגירסה 3.10 ומעלה (גם בגירסת OKD – גירסת הקוד הפתוח) – קל מאוד לשלב את Kubevirt והחל מגירסה 4.2 – ה-Kubevirt יהיה חלק אינטגרלי (בגירסה הנ"ל תוכלו להתחבר ישירות ל-vCenter ולהמיר את ה-VM בכמה קליקים).
מיקרוסופט וגוגל כבר מזמן הבינו שאם רוצים למשוך את הלקוחות אליהם כדי שישתמשו בשרותי ה-Kubernetes שלהם, צריך לעזור ללקוחות בכך שיציעו המרה של מכונות VM להרצה בתוך קונטיינרים, וזה יהיה כנראה ה"גל" הבא.

על מדיה דיגיטלית, ענן ציבורי וגדילה דינמית

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

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

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

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

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

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

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

כשצריך תשתית של עננים ציבוריים – מקומית

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

לפני כחודשיים כתבתי פוסט על Azure Stack (ועל "אחיו" – Azure Stack HCI), הפתרון של מיקרוסופט לחברות שדורשות ענן ציבורי בתשתית שנמצאת מקומית או ב-DC של אותן חברות. מאז אותו פוסט גם אמזון עדכנה את הפרטים לגבי המוצר המתחרה שלה: Outpost. לפי ה-FAQ העדכני והפוסט הזה שפורסם לפני מספר ימים מתאר אלו שרותים יהיו זמינים ב-Outpost. גם כאן, כמו עם Azure Stack, אתה לא יכול להשתמש בשרתים או סטורג' משלך, והשרות בעצם כולל השכרה/רכישה של ברזלים יחודיים של ספק הענן, וכמו בכל ההצעות – אתה חייב חיבור אינטרנט לאותה תשתית מכיוון שמי שמנהל את אותה תשתית ענן ציבורי שנמצאת מקומית ב-DC שלך – זה ספק הענן הציבורי בלבד.

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

גם גוגל החלה להציע פתרון משלה לאלו שרוצים תשתית ענן ציבורי אך מקומית ב-DC שלהם, אם כי הוא שונה מהמתחרים. אם אצל המתחרים השלב הראשון הוא רכישת/השכרת ברזלים, בגוגל פשוט ממליצים לך להשתמש בתשתית המקומית שלך או בתשתית הענן הציבורי שלהם או של אחרים ושם המוצר הוא Anthos. עם Anthos הלקוח מקבל את פלטפורמת הקונטיינרים של (Google Cloud (GKE לשימוש מקומי. זה לא בדיוק נשמע משהו מלהיב – אחרי הכל, לרוב החברות יש מאות ואלפי מכונות VM שהם לא רוצים/לא יכולים להמיר לקונטיינרים ולכן גוגל כוללים בחבילה גם את Anthos Migrate שמאפשר לך להעביר מכונות VM (בשלב זה מכונות מבוססות לינוקס בלבד) מ-VM ישירות לקונטיינר, כאשר המערכת של גוגל מנתחת את ה-VM, מקימה קונטיינרים, מזרימה אליהם את המידע ותוך רגעים ספורים אתה יכול להשתמש בקונטיינרים במקום במכונות ה-VM, גם כשהמכונות VM עדיין לא הועברו בשלמותם לפתרון של גוגל.

לגבי שאר ספקי הענן הציבורי:

ל-IBM יש Cloud Private שנותן לך בעצם Kubernetes עם שרותים נוספים של IBM שירוצו מקומית.
ל-Alibaba, Huawei, Baidu יש גם פתרונות מקומיים אבל אני בספק אם הלקוח הישראלי החשדן יסכים לשכור מהם שרותים שישבו מקומית.
Oracle מציעים את Oracle Cloud at customer – שכוללים את "רוב" השרותים שהם מציעים בענן (אחרי שנברתי בערימת מסמכים רוויי Buzzwords – קשה להבין מה הם בדיוק נותנים, מה עוד שהתיעוד שלהם לגבי ספקי ענן מתחרים לוקה בחסר ולכן לא מומלץ לסמוך על התיעוד שלהם).
VMware – נכון, VMWare היא אינה ספק ענן ציבורי, אבל עם מוצר כמו Tanzu אתה יכול להרים תשתית קונטיינרים/Kubernetes מקומית (PKS) ובעננים ציבוריים גדולים.

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

עננים ציבוריים: להתחיל בקטן ולגדול

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

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

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

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

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

ה-Lightsail של אמזון נועד להתחרות בחברות כמו Digital Ocean, Linode ואחרים, אולם המטרה העיקרית שלו היא לתת ללקוחות פתרונות מוכנים לאלו שאינם מכירים את הפלטפורמות של עננים ציבוריים ואותם סטארטאפים מעדיפים להשקיע את הזמן שלהם בבניית משהו שאפשר להדגים כ-PoC ואולי אפילו לגייס כמה לקוחות Beta ולהשתמש בשמם בהמשך כדי להשיג לקוחות משלמים.

במקרים כאלו ה-Lightsail הוא פתרון מעולה. השימוש בו ממש קל: אתה יכול להרים לך מספר מכונות, אתה יכול להשתמש בשרותי ה-DB המנוהלים של אמזון גם ללא הכרה של ה-RDS המורכב, אתה יכול להשתמש ב-Load Balancer הפשוט שאמזון מציעה כדי לנתב את התעבורה, ואתה יכול להשתמש בשרותי ה-Snapshot כדי לשכפל מכונות תוך דקות ספורות, ויש דברים נוספים שלא עולים לך כמעט כלום: אתה יכול להשתמש בשרות ה-SMS לשם משלוח מיילים החוצה (בכמויות שסטארטאפים קטנים מתחילים – הם לא ישלמו כלום), אתה יכול להרים GIT פרטי (5 משתמשים ראשונים זה בחינם), אתה יכול גם להשתמש בשרות ה-DB המנוהל עם אפשרות Cluster שיעבוד כ-Active/Passive עם גיבוי אוטומטי כל 5 דקות, ויש לך מגוון שרותים שאתה יכול להשתמש עם ה-Lightsail מבלי להכאיב לארנק.

ברגע שהסטארטאפ רוצה לגדול, Lightsail מאפשר לך להעביר את התשתית שלך כמו שהיא ל-AWS המלא. צור Snapshot למכונות, ותוכל להקים אותם כ-Instances ב-EC2 ואותו דבר לגבי ה-DB – תוכל להעביר אותו בקלות ל-RDS ולהשתמש בשרותים מתקדמים כמו רפליקות וכו'.

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

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

תכירו: vCompute Server של NVidia

במסגרת כנס VMWorld שנערך השבוע, חשפה NVidia את המוצר החדש שלה שהוא vCompute Server (נקרא לזה בקצרה VCS) שמתאים לאלו שצריכים להריץ עומסי AI, DL בסביבות וירטואליות.

עד היום, חברות שרצו להריץ למטרות Training ופיתוח עומסי AI בסביבה וירטואלית, היו צריכים לעשות זאת עם ה-vGPU ש-Nvidia מוכרת. בשיטה הזו מקצים חלק מכרטיס ה-GPU שיושב בשרת לכל VM (אגב, לידיעה: vSphere 6.7 U3 מאפשר לראשונה להצמיד מספר vGPU למכונת VM, לא רק vGPU יחיד).

לשיטה הזו יש כמה חסרונות רציניים:

ה-vGPU לא תוכנן מראש עם ה-CUDA לשימושי AI,DL. כן, הוא יכול להריץ זאת (גם מעבד גרפי נמוך מאוד כמו MX150 בלאפטופ יכול להריץ זאת), אך לא בצורה אופטימלית.
אם אתם משתמשים בקונטיינרים עם ה-Runtime Container של NVidia, זה לא היה מנצל את היכולות האמיתיות של הכרטיס (TCC, nVLink וכו') אלא היה מתייחס ל-vGPU בלבד.
אין תמיכת NVLink
אין אפשרות אגרגציה טבעית (מעבר למה שה-vGPU נותן).

הפתרון של NVidia הוא ה-VCS, מערכת חלופית שנותנת "vGPU" אבל למערכות AI,DL (כל עוד ה-VM לא מריץ שום דבר גרפי כי .. אין דרייבר גרפי).

מערכת ה-VCS פותרת את החסרונות של ה-vGPU ה"קלאסי" ונותנת את הפוקנציונאליות הבאה (אפשר לקרוא מעט יותר בהרחבה על כך בקובץ ה-PDF הזה):

אפשרות לחלק את ה-GPU לחלקים (Fraction) או לבצע אגרגציה של מספר v-GPU מכרטיסים שונים ובגדלים שונים.
מהירות עבודה יותר גבוהה (כי אין צורך לכרטיס לבצע רינדורי גרפיקה של מסכים וירטואליים/תלת מימד/וידאו וכו')
שימוש ב-NVLink בחיבור Peer to peer.
מיגרציה – מעתה אפשר לבצע vMotion (באשכולות לדוגמא) גם כשהמכונה רצה, לבצע suspend, resume.
תמיכה ב-Multi Tenant.
שימוש מ-NRC לקונטיינרים יהיה מהיר יותר, הואיל והמודול בלינוקס יודע להשתמש בכל היכולות של ה-GPU בשרת.

החסרונות:

אין דרייברים לגרפיקה (אז תשכחו מאובונטו גרפי – ואם אתם עדיין רוצים סביבה גרפית, תכירו את NoMachine)
אין דרייברים ל-Windows (כן, לכל גרסאות Windows)
אין יותר פרופילים קטנים, הן ברמת זכרון (המינימום הוא 4 ג'יגה, המקסימום הוא 48 ג'יגה) והן ברמת CPU (מינימום 4 ליבות, מקסימום 48 ליבות).
אין תמיכה ב-Quadro הישנים (יש תמיכה ב-Quadro RTX)

מבחינת רישוי: תצטרכו רישוי בתשלום שנתי, פר GPU.

פתרון ה-VCS בהחלט מתאים כמובן (ומומלץ) לשימוש עם Kubernetes, קונטיינרים וכו'.

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

מעבר לכך, עם ה-VCS יש סוף סוף ניצול לחיבור ה-NVLink והעברת המידע ב-GPU בין הכרטיסים במהירות של 100 ג'יגהביט לשניה. ב-RTX 2080TI יש רק חיבור אחד כך שניתן לצוות מקסימום זוג כרטיסים. אם נכניס 8 כרטיסים כאלו לשרת וננסה להשתמש בכולם (הגדרת TCC), המערכת תצטרך לעבוד יותר לאט הואיל וה-DATA צריך לעבור הלוך ושוב בין ה-GPU (דרך המעבד וה-RAM בשרת) לדיסק וההיפך, ואילו עם כרטיסי Tesla וכרטיסים אחרים לשרתים (Quadro RTX) ה-DATA עובר בין כרטיסי ה-GPU דרך ה-NVLINK כך שהדברים רצים הרבה יותר, ועוד לא הזכרתי שמבחינה חוקית NVidia אוסרת על הפעלת כרטיסי RTX 2080TI (או כל RTX "ביתי") על שרתים והם יכולים מחר בבוקר בעדכון CUDA ודרייבר פשוט לבטל אפשרות שימוש בכרטיסים ביתיים בשרתים, כך שחשוב לקחת זאת בחשבון.

עוד נקודה ש-NVidia הכריזו היא הקמה של Repo חדש לקונטיינרים שמשתמש ביכולות CUDA ונקרא NGC. זה לא ממש חדש (ומשתמשים בו ב-DGX שלהם), אבל הפעם זה פתוח לקהל. לתשומת לב צה"ל, חברות בטחוניות וכו' שלא ממש מוכנים/יכולים לעבוד באופן ישיר מול האינטרנט – אין שום בעיה להוריד מה-REPO של NGC (ואחרים למען האמת) ולאכסן זאת דרך Registry משלכם. הנה לינק איך עושים זאת עם לינוקס.

לסיכום: אם אתם צריכים/משתמשים במערכת וירטואליזציה לצורך AI/DL או לשימוש עם קונטיינרים, הפתרון החדש של NVidia יכול בהחלט להתאים לכם. קחו בחשבון שאם אתם צריכים מקסימום מהירות, עדיף לרכוש את כרטיסי ה-Tesla או כרטיסי ה-Quadro (או כרטיסים עם האות V) עם חיבור NVLink כפול בכל GPU.

עדכונים בנושאי וירטואליזציה ו-VDI

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

אתחיל בנושא VDI.

תודות לחברת CRG שהשאילה לי כרטיס AMD S7150 לצרכי בדיקות VDI – התחלתי לבדוק את הנושא. לצערי הכרטיס הזה לא ממש עובד על מעבדי Xeon ישנים (סידרה V1-V2). הזמנתי לוחות אם של Supermicro יד שניה מסוחר ישראלי ו… גיליתי להפתעתי שהלוחות פגומים (פגומים במובן שכאילו מישהו העביר פטיש על תושבות המעבדים ועיקם את רוב הפינים!). מכיוון ששילמתי ב-Paypal, הצלחתי להחזיר את הלוחות ולקבל את הכסף בחזרה, כך שלא יכלתי להתקדם הרבה עם הכרטיס והחלטתי להחזיר אותו ל-CRG.

לא הרמתי ידיים, החלטתי לבצע בדיקות סימולציות משתמשי דסקטופ (כלי מצוין לכך: LoginVSI, יש גירסת התנסות בחינם) במובנים הבסיסיים לצרכי רואה חשבון ועורכי דין שמדי פעם גם צופים פה ושם בוידאו. התברר לי שכשמדובר בכמות קטנה (5-8 תחנות) של משתמשים, ואם משתמשים ב-RDP בלבד – לא יהיה צורך בכרטיס GPU לצרכי VDI. המעבדים בשרת מודרני יכולים לעמוד יפה בעומס. (אני ביצעתי את הניסויים על מעבד דסקטופ AMD Ryzen 7 2700X, כך שמעבדי Xeon יכולים לעשות זאת בקלות).

מכאן נעבור לברזלים: אני ממליץ על שרת בתצורת TOWER מהסיבה הפשוטה שלרבים אין מקום להכניס שרת 1U/2U רגילים מבלי לרכוש ארון תקשורת בעומק 80 ס"מ, מה גם שהוא מרעיש. שרת במארז Tower בדרך כלל הרבה יותר שקט והאיוורור בו הרבה יותר טוב ויעיל.

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

מבחינת תקשורת: אני ממליץ חיבור 10 ג'יגהביט בין השרת ל-Switch (לרוב המתגים יש Uplink של 10 ג'יגה בחיבור +SFP) – אם כל המשתמשים צופים בוידאו – קידוד ה-RDP + קידוד H.264 + תעבורה של הדסקטופ לוקחים לא מעט.

אסכם את הנושא כך: עם ESXI חינמי, עם מכונה בתצורת Tower שכוללת 2 מעבדים של 8 ליבות כל אחד, 128 ג'יגהבייט זכרון, דיסקים מקומיים, NAS של Synology ומתג נורמלי – אפשר לייצר "סביבת VDI". הפתרון, כמובן, לא VDI כמו Horizon או Terminal Services והוא גם לא מתיימר לכך, הוא בסך הכל נועד להעביר כמות קטנה של מכונות פיזיות ישנות ולהמירן ל-VM ולעבוד עליהן. אם מדובר על עשרות של מכונות פיזיות וכו' – אז כדאי בהחלט לחשוב על פתרון VDI מלא.

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

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

עננים: במהלך השבועות הקרובים אתחיל להעלות קליפים נוספים הקשורים בתכנון מכונות על AWS, על שימוש ב-VPC (תתפלאו כמה חברות כלל לא מגדירות VPC ומשתמשות ב-Default), על Load Balacing ועוד.

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

שינוי רישוי JAVA SE

חברת אורקל רכשה את חברת SUN לפני מס' שנים ובעקבות הרכישה, פלטפורמת JAVA עברה לידי חברת אורקל. עד לשנה שעברה, הרישוי של חברת אורקל לגבי JAVA SE ומעלה (JAVA EE) היה די ברור וחברות רבות פשוט העדיפו לעבוד עם Java SE (כלומר: Java Stanadrd Edition) לפיתוח ולהתקין את ה-JRE (כלומר Java Runtime Edition) בשרתים, דסקטופים שצריכים זאת וכו'. מי שרצה להשתמש ב-JAVA הרשמי ב-Embedded היה צריך (ועדיין צריך) לשלם את המחיר המלא.

החל מהשנה, חברת אורקל שינתה את הרשיונות של JAVA (ואפשר לקרוא את ה-FAQ שלהם כאן). לאלו שרוצים לחסוך את הקריאה, אקצר את הדברים: כל עוד אתם צריכים את ה-JDK או ה-JRE מגירסה 8 ומעלה לשימוש שאינו מסחרי (כמו בבית), לאורקל אין שום בעיה איתכם ואתם יכולים להוריד ולהשתמש. אם לעומת זאת אתם חברה, או שהרמתם אתר מסחרי – אורקל רוצה מכם כסף, וכן, גם על JRE הם דורשים כסף.

כמה כסף? אם מדובר במכונת דסקטופ (צריך עדיין JRE לדוגמא כדי לנהל שרתים ישנים עם iLO-3 או iDrac) – תצטרכו לשלם מחיר של 2.5$ לחודש. אם אתם צריכים להתקין על שרתים, אז אתם צריכים לשלם על כל הליבות שיש בשרת, בהתאם לליבות הפיזיות שיש בשרת, לפי הטבלה הזו. כלומר אם יש לדוגמא יש לכם שרת שבו יש שני מעבדי Xeon כשלכל אחד מהם יש 8 ליבות, אז סך הכל יש בשרת 16 ליבות, וה-Core Factor הוא 0.5. נכפיל במחיר הרשמי של 25$ לחודש, ונראה שאנחנו צריכים לשלם על כל שרת כזה 200$ לחודש. נקודה שחשוב לציין: אם אתם משתמשים בוירטואליזציה שאינה Oracle VM (כמו VMWare) ואם הקמתם בשרת הזה רק מכונת VM אחת עם 4 ליבות וירטואליות שמשתמשת ב-JAVA, אתם עדיין צריכים לשלם על כל הליבות שבשרת. (אם הבנתי זאת נכון, צרו קשר עם נציג המכירות של אורקל כדי להיות בטוחים). אם אתם רוצים את קבצי ה-MSI, אגב, אתם נכללים בקטגוריה המסחרית ותצטרכו לשלם את מה שציינתי לעיל, כל חודש.

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

הפתרון הוא OpenJDK.

OpenJDK הוא מימוש קוד פתוח (שאורקל גם משתתפת בו) של ה-JDK בגירסת ה-Standard Edtition (אין גירסת OpenJDK ל-Enterprise Edition – זהו מוצר נפרד של אורקל שאין לו מתחרה בקוד פתוח) וברוב המקרים הוא משוחרר בסמיכות לגירסת JDK/JRE המסחרית שאורקל משחררת. אפשר לקרוא על ההבדלים כאן. בעקרון, לא אמור להיות הבדל בין גירסת OpenJDK לגירסת SE, רק שחשוב לציין – OpenJDK משוחרר תחת רשיון GPL, וכל שינוי שנעשה ב-JDK – יש לשחרר בחזרה לציבור.

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

אם בחרתם להשתמש ב-OpenJDK, כדאי מאוד לבדוק פנימית אם האפליקציות שלכם רצים ומגיבים כמו ה-JDK/JRE הרשמי של אורקל. הדברים אמורים לעבוד בדיוק אותו דבר למעט שימוש בכל מיני Applets להשתלטות מרחוק על ציוד ישן (שרתים) – שם יש לא מעט מקרים שמקשים לא עובדים טוב (במיוחד קיצורי מקשים). אתם יכולים לנסות להשתמש ב-OpenJDK כדי לבדוק אם יש תאימות, בכך שתתקינו את החלק שנקרא IcedTea (כן, שם "מתחרה" ל-Hotspot) וכדאי לשים לב למגבלות שלו.

בנוגע ל-JAVA SE ועננים: בעננים ציבוריים תצטרכו לשלם פר ליבות של ה-Instance שלכם אולם בעננים מקומיים זה תלוי מה הוירטואליזציה שרצה על הברזל הפיזי. בכל מקרה – צרו קשר עם נציגי המכירות של אורקל אם אתם רוצים רשיון מסחרי וכדי לדעת כמה צריך לשלם.

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

הבדלים בין Snapshot לגיבוי

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

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

מימוש ראשון VMWare Snapshot
מימוש שני – AWS Snapshot

נאמר שיש לנו VM שיש בתוכו קובץ טקסט שבו כתוב "חץ קנה פיתה". נשמור את הקובץ וניצור Snapshot. עתה, נפתח את הקובץ הנ"ל ונשנה את הטקסט כך שיהיה כתוב "חץ קנה פיתה עם פלאפל". נשמור את הקובץ באותו שם.

עכשיו נעקוב אחר התהליך הנ"ל מקרוב. ברגע שיצרנו את ה-Snapshot לאותו VM, הוא מתחיל בגודל 0 בתים (או משהו קרוב לכך, יכול להיות שה-snapshot יכלול בתים ספורים בהתחלה). ברגע שערכנו את אותו קובץ טקסט ושמרנו אותו, הוא אינו שומר את השינוי לדיסק הקשיח הוירטואלי, אלא שומר אותו לתוך ה-snapshot. אם נבדוק, נוכל לראות שגודל ה-snapshot גדל בכמות הבתים שהוספנו לאותו קובץ טקסט (את הדברים הרבה יותר קל לראות "מבפנים" אם משתמשים במערכת ZFS, שהיווה "השראה" ל-VMWare כיצד ליצור snapshots). אם לאחר שיצרנו קובץ Snapshot, עבר זמן ויצרנו קובץ snapshot חדש, כל השינויים שניצור מעתה ישמרו ב-Snapshot החדש, וה-snapshot הקודם יעבור למצב read only.

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

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

מכאן נעבור לנקודה היותר "פילוסופית" – האם snapshot יכול להחליף את מקומו של הגיבוי? זה תלוי.

במקרים כמו VMWare התשובה היא "לא ממש" הואיל ויצירת Snapshot הוא דבר שצריך לבצע "ידנית". המערכת לא תיצור עבורך snapshot אוטומטית (למרות שלמערכת יש בהחלט דבר שנקרא Changed Block Tracking שמופעל אוטומטית ובכך המערכת יודעת לזהות כל שינוי שבוצע בדיסק, ואין זה משנה איזו מערכת הפעלה מדובר, כי אותה מערכת עובדת בבלוקים, לא ב-File system) ולכן גיבוי של המערכת ע"י תוכנת גיבוי (Veeam, Arcserve ושאר תוכנות) היא דבר חשוב ואף הכרחי.

בעננים ציבוריים כמו AWS לעומת זאת, יש צורך לעבוד בשיטה שונה (שלצערי יש לא מעט שמתחילים לעבוד עם AWS ולא מפנימים זאת): ב-AWS כדאי לבנות את מכונות ה-VM כ"שלדים" (templates) ולשמור את הקבצים המשתנים ב-EFS או ב-S3. כך, בונים VM, מגדירים את הדברים הקבועים, מוסיפים סקריפט שידע להעתיק את הקבצים הנחוצים מ-S3 או EFS, יוצרים snapshot ולאחר מכן ממירים את זה ל-Image בפורמט AMI סגור. נדפק ה-VM? פשוט מקימים חדש מה-AMI כשאחד הפרמטרים הוא בעצם הרצה של הסקריפט שיצרנו כך שלאחר הקמת ה-VM/Instance – הוא יעתיק את הקבצים וידווח לנו מה כתובת ה-IP הפנימית של ה-VM החדש.

ב-ZFS הדברים שונים. מכיוון ש-Snapshot ב-ZFS אינו תופס מקום בדיסק (0 בתים), ישנה שיטה פשוטה ליצור אוטומטית snapshots כל זמן שתרצה. אני לדוגמא עובד עם ZFS שיוצר snapshots כל שעה, כל יום, כל שבוע, כל חודש, כל שנה – ומגדיר את המערכת שתשמור לי 50 snapshots אחורה. מבחינת שרידות, ZFS תומך במערך RAID (שנקרא RAIDZ) עד רמה שלישית (כלומר: המערכת יכולה לתפקד עד למצב שבו יש שלושה דיסקים תקולים) עם תמיכה מלאה ב-Hot Spare. מעבר לכך, מערכת ZFS נותנת גם "להשתולל" עם מערכי RAIDZ כך שניתן להקים שתי מערכות RAIDZ3 ולצוות אותן יחד כ-RAIDZ1. בזבוז מטורף של דיסקים? בהחלט, אבל למי שיש תקציב – בכיף. מה עם גיבוי לטייפ? יש כאלו שמגבים אחת לזמן מה לטייפ ויש כאלו שפשוט מעדיפים להשתמש בתשתית ה-ZFS ופקודות ה-send/receive המובנות על מנת לגבות את ה-ZFS למערכת מרוחקת. (אפשר כך לבנות אחסון DR בזול. אגב, מקומות רבים בחו"ל משתמשים בשיטה הזו).

לסיכום: "snapshot אינו מחליף גיבוי" – זו הצהרה שאינה נכונה תמיד. יש מקרים שזו הדרך היחידה שלך לגבות (עננים ציבוריים), ויש מקרים שמימוש ה-Snapshots (כמו ב-ZFS) אינו מצריך גיבוי לקלטת כל יום. לגיבוי יש מקום חשוב ול-snapshot יש גם מקום חשוב וביטול אחד ו"הילול" הדרך השניה אינה בהכרח התשובה הנכונה.

שינויים בעולם ה-IT בחברות

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

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

יחד עם זאת, יצא לי בכמה פעמים לשוחח עם מספר מנמר"ים, CTO ומנהלי מחלקות IT. השיחה בד"כ נסובה על דברים שהם מחפשים במועמד הבא לאייש משרה בתחום ה-IT, ושמתי לב לכמה דברים מעניינים שאני רוצה לשתף עמכם:

הדרישות גדלו: אם פעם היו מחפשים אצל המועמד ידע ב-Windows, ידע התחלתי-בינוני בלינוקס, ידע ב-VMWare ואולי קצת ידע ב-Networking, הפעם רוצים שהמועמד יהיה בעל נסיון בתחומים שהם אינם IT כל כך: תדע Jenkins, GitLab, Code bucket – ולא מדובר על ידע של התקנת הכלי (כמה זמן לוקח להתקין Jenkins? דקות ספורות, לא כולל plugins שאינם רשמיים וכו') – אלא גם כתיבת Pipelines, ידע בניהול גרסאות ב-GIT, ידע ב-Docker, ידע ב-Kubernetes, ידע בהגדרות עננים ציבוריים (AWS, Azure ולפעמים גם GCP). לא שמעתי על הרבה שרוצים ידע ב-Terraform אבל אני מניח שאת זה הם משאירים לאיש DEVOPS (כן, Devops זה מתודות, אבל לך תתקן אנשים).
משכורות – אתה הולך לרכוש דירה? הולך להרחיב את המשפחה? הולכת להיות לך הוצאה גדולה? כדאי שתעזוב את תחום ה-IT לטובת תחומים אחרים יותר רווחיים. המספרים ששמעתי נעים בין 13-20K ברוטו. טוב לצעירים, פחות טוב לנשואים, אבות לילדים וכו' וכו'.
Kubernetes, Helm, Terraform, Ansible, AWS, Azure – ורצוי גם ידע ב-Python, אלו הדרישות שדורשים מאנשי Devops, חוץ מידע בכלי CI/CD. שימו לב: בסטארטאפים מצפים מכם שתלמדו הרבה יותר ממה שציינתי – ומהר. כלי נוסף שחברות עדיין לא ממש גילו ויש מצב שירצו להריץ אותו – נקרא KOPS. ממליץ לכם להכיר אותו.
שכר לאנשי Devops: משום מה במקומות רבים חושבים שהשכר של איש Devops אמור להיות שכר כמו של איש IT. עצתי לכם: תדעו למכור את עצמכם ולהתמקח. עם כל הכבוד לתחום ה-IT, איש Devops צריך לדעת הרבה יותר וללמוד מהר דברים חדשים, התחום מתקדם במהירות מטורפת!
אל "תינעלו" על ענן ציבורי מסוים! ידוע לי שבחברות גדולות רבות פשוט "מתים" על Azure, אבל בשוק יש המון חברות (ובמיוחד סטארטאפים) שמשתמשים ב-AWS ו-GCP ועדיף לכם להכיר את כולם. כל ספקי הענן הציבורי מציעים כמות קרדיטים חינמית בתור התחלה אבל זה לא תמיד מספיק (תזכרו: הקרדיטים הראשוניים הם לזמן קצוב בלבד של חצי שנה או שנה). לכן אני ממליץ: תתנחמדו לאנשי מכירות של ספקי הענן הציבורי ותבקשו בנימוס קרדיטים. טיפ קטן: אני ממליץ ללמוד את הנושאים דרך Linux Academy (למרות השם שלהם, הם מלמדים גם על דברים שאינם לינוקס) ולהשתמש ב-Lab שלהם, אתם תקבלו מספר מכונות וירטואליות חינמיות שפועלות במשך זמן קצוב.
קראו בין השורות לגבי משרות. בלא מעט מקרים באתרים כמו Alljobs ניתן לקרוא את המפרט של נושאים שהחברה רוצה שהמועמד ידע ויכיר, אבל לפעמים אפשר לראות שהחברה בעצם מחפשת איש Devops שיהיה גם איש IT ואם אפשר – שיכין קפה לפעמים. ממשרות כאלו אין הרבה לאן להתקדם, חפשו דברים שמתאימים לכם, לא להיות כלבויניקים.
הנה משהו מעניין ששמעתי ולא מאדם אחד: אין לכם נסיון (חוץ ממה שהתנסיתם בבית)? אל תבקשו לעבוד בחינם. אתם יכולים לדבר על משכורת התחלתית כלשהי שתעלה לאחר תקופה מסויימת/דיון שכר וכו' – והכי חשוב, להיות כן: אם אין לך נסיון מספק, תאמר זאת ותאמר שאתה מוכן בשביל זה להסתפק במשכורת כלשהי (עדיף לא לציין מספר). תנסו לתחמן, יש סיכוי גדול שיתפסו זאת ולא יזמנו אתכם להמשך תהליך.

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

המעבר לענן ציבורי – התהליכים המקדימים

דמיינו לעצמכם סיטואציה פשוטה: יש לכם 20 שרתים בחברה (פיזיים) שמערכת vSphere רצה עליהם. הכל מתקתק ועובד טוב עד שיום אחד האחראי על ה-vSphere בחברה מפוטר עקב סיבה כלשהי. האם יהיה קשה למצוא עובד חלופי לאותה משרה? לא ממש, השאלה למה אתה מצפה: אם לדוגמא העובד שפוטר היה כותב סקריפטים ב-Powershell או ב-PERL לאוטומציה של ה-vSphere ורוב העבודה היתה נעשית באוטומציה כלשהי ללא שימוש ב-GUI – אז כן, אתה תתקשה למצוא מחליף (וגם אם תמצא, תצטרך לשלם לו הרבה יותר ממה שחשבת). אם לעומת זאת אתה מחפש מישהו שינהל רק ברמת הממשק Web, תמצא לא מעט כאלו בקלות ותוכל לשלם להם משכורת יותר נמוכה אפילו (תלוי בכישורי המו"מ שלך והבטחון העצמי של המועמד). מצד שני, אם יש לך תקלות שמתאפיינות במסך סגול וגוגל לא ממש עוזר – תתכונן לשלם והרבה, בין אם זה ל-VMware או למישהו מומחה.

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

מה בעצם העבודה שהרוב יציעו ויעשו? הם יעשו מה שאני קורא "Copy Paste". נניח שיש 10 מכונות VM, הם פשוט יעלו אותן לענן כ-Instances, יקצו להן כתובות IP חיצוניות פר Instance (תתפלאו כמה חוסר מקצועיות יש בנושא), יגדירו Security Group שנושאת מטוסים יכולה לעבור דרכו, חס ושלום VPC חדש ונורמלי, או ניתובים קצת יותר מוקשחים. אם הלקוח מתעקש על Firewall, אז יתקינו איזה משהו שקיים ב-Market עם חוקים מאוד "רפים". אני לא מנסה "ללכלך", אני בדרך כלל מי שמגיע אחרי כן לבדוק מדוע הדברים לא עובדים טוב וזה מה שאני מוצא. אני כמובן שלא אומר שכולם כך, יש דווקא לא מעט אנשים מקצועיים בתחום.

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

בהעברת התשתית לענן יש לנו 3 מטרות חשובות:

הורדת המחיר פר מכונה
קבלת ביצועים יותר גבוהים
הגנה יותר נאותה.

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

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

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

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

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