כשאין נסיון מספק בתחום

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

כפרילאנסר – החיים מאוד דינמיים ומאוד תובעניים. ככל שאתה מכוון ליותר "גבוה" לפרויקטים והזדמנויות רווחיות – אתה צריך "להשיל" תחומים מסויימים בגלל שהשוק באותם תחומים מוצף בעצמאים שיהיו מוכנים לתת מחיר תחרותי מאוד. לדוגמא: תחזוקת מכונות Windows Desktop או תחזוקת שרתי Windows – יש מספיק בשוק שיציעו מחירים של 70-150 לשעה. אם אני אבקש "מאות" שקלים לשעה, ההצעה תידחה ולכן בדברים כאלו צריך לוותר ולכוון לדברים היותר רווחיים – קונטיינריזציה, עננים ציבוריים, כלי CI/CD, אוטומציה, אינטגרציית לינוקס, מערכות  משובצות, HPC, Scale Out, אחסונים גדולים (מעל פטה) ועוד.

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

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

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

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

וכך, כשכיר, בעת הראיון, אתה יכול לאמר את האמת: אין לי נסיון בנושא X מחברה קודמת, אבל יש לי ידע טוב בנושא X ואתה יכול לקרוא בעצמך את הפוסטים שכתבתי בבלוג שלי בכתובת XYZ. בשביל המראיין, הפוסטים האלו מראים את הידע שלך, ואת העובדה שאתה יכול לפתור בעיות. אותו דבר לגבי מפתח – פוסטים עם קישורים ל-Github עם קוד משלך עוזר הרבה יותר מ-1001 המלצות, גם אם מדובר בסקריפט BASH פשוט, באוטומציה פשוטה וכו'. מישהו יכול לראות, להתרשם, ואז להמשיך במסלול עד לחתימת חוזה עבודה איתך.

עוד נקודה לשכירים – להכיר תחומים או דברים מסויימים ברמת ה-Overview וברמת תפעול כלשהי: כשכיר, יש סיכוי שהולך וגודל כל הזמן שתצטרך לעבוד (בין אם ב-IT או ב-Devops) מול ענן ציבורי כלשהו, ורוב החברות עובדות מול ענן ציבורי אחד. יחד עם זאת, יש סיכוי לא קטן שבחברה אחרת שתעבוד, הם עובדים עם ענן ציבורי אחר, ולכן, בזמן שאתה עובד באותה חברה נוכחית, תתחיל להכיר את העננים Azure, GCP, AWS ואם אתה צריך הדרכה אונליין, הנה קישור Referral שיכול לעזור לך להכיר את העננים האחרים, כך שאם ישאלו אותך אם יש לך נסיון ב-AWS לדוגמא, תוכל לענות "כן".

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

תכירו: 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.

פרויקט נימבוס – מחשוב הענן הממשלתי

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

anan

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

  1. אחד הדברים הבולטים לטובה במסמך הוא התייחסות למחשוב ענן כמו שספקי הענן הציבורי מציגים ומוכרים ולא כל מיני "ענני צעצוע" שכל מיני חברות בארץ מציעות/מוכרות. התנאים עצמם ישר פוסלים את אותם "ענני צעצוע" בכך שיש דרישות שלספקים בארץ אין אותם, הן מבחינת הכנסות והן מבחינת Availability Zones (שמשום מה במסמך הם נקראים "Domains"), מיקומים גיאוגרפים וכו' ואף אחד מהספקים בארץ גם לא מציע 500+ שרותים שונים באותו ענן.
  2. אני שמח לראות שבמשרד האוצר מחפשים שהזוכה יקים בעצם Region אחד ובתוכו Availability Zones אולם לעניות דעתי, חשוב שבמשרד יתעקשו על כך שה-AZ יהיו במרחק רב אחד מהשני.
  3. נקודה שלדעתי חסרה במסמך וחשוב שתצוין (ושהמשרד יעמוד על כך) – שה-AZ יהיה מחובר בחיבורי תקשורת מספקי אינטרנט שונים ולא מספק יחיד. רק לפני חודשים ספורים אלפי אתרים נותקו מהאינטרנט עקב "תקלת תקשורת" של ספק אינטרנט מרכזי. האם משרד האוצר רוצה לחוות חוויה כזו?
  4. אם המתמודדים הם בעצם ספקי הענן הציבורי, מומלץ לבקש לדעתי במסמכי המכרז כי הספק הזוכה ייבא וישתמש בציוד שלהם ולא בציוד COTS. הציוד של ספקי הענן שונה לחלוטין מציוד שחברות רוכשות החל ברמת המעבדים, זכרונות, לוחות, אחסון, תשתיות תקשורת וכו' ויש סיבה טובה לכך – ביצועים הרבה יותר גבוהים.
  5. בבקשה, בבקשה – בלי Azure Stack. כתבתי כאן מדוע לא.
  6. נקודה נוספת שאולי כדאי שמשרד האוצר יחשוב לגביה – שה-AZ יהיו מחוץ ל-Data Centers של ספקי האינטרנט שונים במיקומים כמו הגליל ובאר שבע לדוגמא. בחירה במקומות כאלו יכולה לייצר באופן ישיר מספר מקומות עבודה ובאופן עקיף לאורך זמן – יותר ויותר חברות שיעבדו במקומות אלו.

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

  • מיקרוסופט – Azure
  • אמזון – AWS
  • גוגל – GCP
  • אורקל – Oracle Cloud
  • IBM Cloud

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

יש משהו אחד שקצת לא מסתדר לי עם המכרז והפרויקט עצמו. כן, זה בהחלט דבר טוב שמשרד האוצר עושה צעדים להקים פה Region, אבל הבעיה הגדולה ביותר קשורה לשיטות העבודה והפיתוח במשרדי הממשלה השונים ושוחחתי בעבר עם לא מעט עובדים במשרדים הממשלתיים על כך: צריך לשנות מקצה לקצה את כל מתודות העבודה. להתחיל לעבוד מול GIT, לשלב CI/CD, אוטומציה, להוריד כמה שיותר את העבודה עם מכונות וירטואליות ולהתחיל לעבוד מול קונטיינרים ומול שרות/פלטפורמה כמו Kubernetes/OpenShift, לעבוד במתודה של Scale Out, להשתמש ב-Object Storage, להתחיל לעבוד במתודות Serverless אולי, ועוד ועוד – וכל אלו הם דברים שונים ממה שהמשרדים משתמשים כיום. אם משרד האוצר הולך לשלם על Region עם מספר AZ ושיטות העבודה ישארו השיטות הישנות, אז ניצול ה-Region יהיה אחוזים בודדים בלבד, ובכך יווצר בזבוז כספים משווע (ומה לעשות, לא מדובר פה בתשלום חד פעמי אלא חודשי), ולכן אני תוהה אם משרד האוצר מוכן כבר עכשיו לתכנן מהלך הדרגתי לעבור למתודות העבודה החדשות.

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

כמה מילים על Azure Stack וספקי אינטרנט

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

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

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

מערכת Azure Stack בנויה לשימוש ב-2 אופנים: Connected ו-Disconnected, כאשר ב-Connected אתם יכולים להעביר את התשתית הוירטואלית/מכונות/קונטיינרים/אחסון לענן האמיתי של Azure ובמצב Disconnected – האינטרנט מנותק, והכל רץ מקומית בארונות של ספק ה-Azure Stack שלכם (או אצלכם מקומית אם רכשתם את המערכת).

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

החסרונות של Azure Stack לעומת היתרונות – גדולים:

  • הסיבה המרכזית שחברות עוברות לענן – זה ה-Scaling שאותו לא מקבלים באותה צורה ובאותו גדול בהשוואה לענן עצמו. כנ"ל לגבי שרידות – לכל ספק ענן ציבורי יש Zones ויש Regions ואפשר להקים שרידות נפלאה. איזו שרידות תקים ב-Azure Stack? בין שרתים שהכל מקומית? אנשים שוכחים בכל פעם את התקלות שיש פה לכל מיני ISP שמשביתות אלפי לקוחות במכה אחת, ובענן ציבורי אפשר לבנות מערכת שגם תעמוד ברעידות אדמה, זה לא כזה מסובך.
  • ביצועים – עם Azure Stack אנחנו חוזרים שוב למודל ה-Enterprise מבחינת ציוד, וזאת בניגוד מוחלט למה שיש בענן ציבורי: באף ענן ציבורי אין שרתי מותג, אין דיסקים Enterprise, אין מתגים של מותג מסוים – הכל בניה "מקומית", החל מרמת המעבד והזכרון וכלה באוורור, ובעברית: מכונת VM שרצה בענן תרוץ יותר לאט על השרתים הקנייניים שמריצים את Azure Stack כי גם המעבד וגם הזכרון שונים (ספקי ענן רוכשים גרסאות Custom של מעבדים וזכרונות הרבה יותר מהירים ממה שיש בשרתים הרגילים).
  • מחירים: בניגוד למצב רגיל שאתה לוקח מספק Hosting כלשהו מכונת VM נניח עם 4 ליבות, 8 ג'יגה זכרון, 40 ג'יגה דיסק ותעבורה של 5 מגהביט והכל כלול במחיר אחד – כאן הכל שונה, אתה משלם על כל פיפס בנפרד. נתראה בחשבונית החודשית (וכן – התכוונתי ל-Azure Stack. מיקרוסופט מכתיבה זאת).
  • שרותים – הבסיסיים נמצאים + עוד כמה שרותים. השאר? עדיין נמצאים רק בענן הציבורי.
  • תאימות API בין ריצה ב-Azure Stack ל-Azure הרגיל – חלקית בלבד. תצטרכו לעשות לא מעט פליק פלאק כדי להעביר דברים מהענן מקומית וההיפך.

מיקרוסופט מנסה כבר שנתיים למכור את ה-Azure Stack ואין לה הרבה הצלחה עם זה. היא גם מוציאה את Azure Stack HCI שמנסה להתחרות בפתרונות מקומיים (vSAN, Nutantix, Simplivity) שהיתרון היחיד שלו – זה אינטגרציה עם Azure. זה יכול להיות מעניין אולי עבור חלק מהחברות, רק שכדאי לקחת בחשבון שלהגדיר את הדברים שם – אתם תתלשו שערות מהראש.

לסיכום: אני לא מוצא ממש יתרונות לשימוש ב-Azure Stack מקומי או אצל ספק ISP. אם אתם צריכים משהו סגור וגדול – תחשבו על Open Stack כי גם עם Azure Stack תצטרכו צוות שלם (שעדיף שידע לינוקס) כדי לתחזק את הדבר הזה, שלא לדבר על כך שאתם תצטרכו לרכוש את הכל מחדש (אין אפשרות להשתמש בציוד קיים), רק שבמקרה של Open Stack אתם יכולים להשתמש בתשתית קיימת והוא גם הרבה יותר זול. אם אתם מחפשים להשתמש בגלל ה-Latency, אז תחשבו לשלב שימוש בשרות CDN וכך יהיה אפשר לנטרל חלק גדול מה-Latency.

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

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

התשובה הפשוטה: אתה לא ממש יכול לעשות זאת, לפחות לא מה שאתה חושב שיצא.

ברשותכם, אסביר.

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

ב-Xeon לעומת זאת, אינטל עדיין ממשיכה לפרסם את המהירות – ליבה אחת עמוסה 100% ומספרים נוספים לגבי 2 ליבות, 4 ליבות – שהם עמוסים, מה המהירות שלהם. להלן דוגמא מטבלת המהירות של מעבדי Xeon החדשים שיצאו החודש:

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

במכונות דסקטופ/תחנות עבודה/שרתי Tower אפשר להשתמש בפתרונות צינון-מעגל-סגור (Closed Loop Cooler או CLC), ששם יש רדיאטור, 2 או 3 מאווררים חזקים, ותעבורת מים שעוברת בצינורות ומגיעה לחלק שנמצא ישירות על המעבד, בין החומר הטרמי על המעבד לחלק שסופג את החום ומצנן את המעבד. שום פתרון שמבוסס על קירור אוויר אינו יעיל כמו CLC או כל פתרון קירור נוזלי.

וכך, לא חשוב איזה שרת 1U או 2U יש לך, גם אם המאווררים פעילים ב-100% ולא חשוב כמה CFM הם יכולים לדחוף, גם האווררים עם 2 מדחפים – הקירור עצמו אינו יעיל מספיק לקרר מעבד כשכל הליבות עמוסות לחלוטין ולפיכך מהירות המעבד תרד. אגב – המספרים בטבלה למעלה שאינטל מפרסמים? יהיה אולי ניתן להגיע אליהם בשרת 3U ומעלה כשהמאווררים מוחלפים ב-CLC. מנסיון.

לכן, אם המעבדים שלך מתוייגים לעבוד עד מהירות מקסימלית של 4 ג'יגהרץ – תזכור שאתה לא תקבל 4 ג'יגהרץ, ולא חשוב מה תגדיר ב-BIOS (בין כה אי אפשר לעשות Overclocking – הכל חסום ב-BIOS ומעבדי Xeon נעולים ל-Overclocking). אם אתה מחפש ביצועים יותר גבוהים לאפליקציות מסוימות, עליך לבצע 2 דברים:

  • לוודא שהאפליקציה שלך רצה ותומכת ב-Multi Threading
  • להצמיד למכונה הוירטואלית שמריצה את האפליקציה – עוד ליבות, עדיף במתודת CPU Pinning
  • הגדרות Governance ב-CPU ל-Performance ועוד.

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

כשצריכים סטורג' לעסק קטן

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

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

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

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

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

הבעיה המרכזית לפחות ממה שאני רואה – שיש לא מעט כאלו שרוצים משהו שניתן להרחיב, שניתן להכניס 8-12 דיסקים (דיסקים מכניים הם יחסית זולים כיום, גם בגודל 8 טרהבייט), יש כאלו שרוצים חיבור כפול של 10 ג'יגהביט לשרידות, והרוב המוחלט שיודע שיש שרתים שנמכרים כיד שניה במחירים של 1000-3000 שקל – רוצים פתרון יותר זול ממה שהשניים מציעים. אחרי הכל, פתרון כמו Synology DiskStation DS3617xs מתחיל במחיר של $3000 עם 0 דיסקים.

האם יש איזה פתרון שעונה על הדברים הבאים?

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

יש.

הפתרון נקרא XPEnology. זוהי גירסת הקוד הפתוח של ה-Boot שחברת Synology משתמשת בה, וישנה תוכנה עיקרית שמותקנת לאחר מכן שנקראת DSM – שהיא ה"מנוע" של כל הסטורג'. חשוב לציין: ל-XPEnology אין תמיכה רשמית מצד Synology או אף יצרן סטורג' אחר ולא ניתן לקנות מהם תמיכה בנפרד. 

היתרון הגדול של XPEnology הוא שאין צורך לרכוש חומרה מיוחדת. גם מעבד i7 ישן עם 8-16 ג'יגה זכרון יעשו את העבודה, ואת החומרה הזו תמיד ניתן לשדרג (אם כי החלפה של לוח אם ומעבד יצריכו, סביר להניח – התקנה חדשה. ה-XPENology מבוסס אמנם על לינוקס, אולם הוא רחוק שנות אמור מכל הפצת לינוקס שלא משנה מה החומרה שתזרוק לה – תכיר את הכל אוטומטית ב-Boot הבא), ולכן את ההתקנה הראשונית צריך לעשות מישהו שמכיר טוב את XPEnology, או שלא תצליחו אפילו לעשות Boot לקובץ ה-ISO הקטנטן. מנסיון. זה, אגב, גם החסרון שלה – הקושי בהתקנה עצמה.

אחרי ההתקנה וההפעלה – החיים (יחסית) דבש – יש לך ממשק גרפי מאוד עשיר (מהדפדפן) – בדיוק כמו כל מכשיר Synology או QNAP, וניתן להגדיר בקלות משתמשים, חיבור AD, שיתוף NFS, iSCSI, SMB (כולל Multipath). להתקין אפליקציות רבות (הרבה יותר ממה שמכשיר טיפוסי שנמכר – מכיוון שרוב המכשירים שנמכרים יכולים להכיל כמות קטנה של זכרון), מכונות וירטואליות, קונטיינרים ועוד.

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

להתקדם בתחום

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

בהצלחה.

על קונטיינרים ו-Windows Server 2019

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

ב-Windows Server 2019 ניתן להריץ קונטיינרים בדיוק כמו בלינוקס, כשאנחנו מדברים על קונטיינרים בודדים שאנחנו משתמשים ב-Docker, ואם אנחנו מעוניינים להריץ מספר קונטיינרים שמקושרים ביניהם – נשתמש ב-Docker Swarm.

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

אז .. איך Windows Server 2019 עם Kubernetes? התשובה: זה עובד. להכניס לפרודקשן? שלא תעיזו!. מיקרוסופט עדיין עובדים על זה.

ניסיתי בימים האחרונים את Windows Server 2019 עם Kubernetes (גירסה 1.13) והלן הערותיי:

  • תצטרכו לעבוד Multi OS, הווה אומר – ה-Master Node צריך לרוץ על מכונת לינוקס. אם אתם רוצים להשתמש בטריקים כמו HAProxy כדי לחשוף שרות (או NGINX) – תצטרכו גם Node מבוסס לינוקס, בנוסף למכונות Windows שישומשו כ-Nodes כדי להריץ אפליקציות מבוססות Windows.
  • בלינוקס Kubernetes משתמש ב-iptables כדי לנהל את התעבורה הפנימית. ב-Windows זה VFP כך שעדיין יש שימוש ב-Hyper-V. זה לא הולך לרדת.
  • מבחינת משאבים – Windows זה לא לינוקס, וכל קונטיינר מצריך פי 3 משאבים (במינימום!) בהשוואה לקונטיינר שרץ על לינוקס – גם בשביל קונטיינר שיציג Hello World, כך שאם אתם רוצים להריץ הרבה קונטיינרים מבוססי Windows – תצטרכו להקצות לא מעט משאבים לכך מבחינת מחשוב.
  • אין תאימות. בניתם דברים על Windows 10 או על Windows 2016 מבחינת קונטיינרים? תצטרכו לבנות אותם מחדש על Windows Server 2019.
  • וכן .. הכל עדיין דרך CLI (דרך PowerShell).

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

האם ניתן לקחת אפליקציות שונות ולהמיר אותן לקונטיינרים? לא, זה לא לינוקס. כיום רוב מה שנתמך כקונטיינר ב-Windows הם אפליקציות Net.

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

לסיכום: כן, ניתן להריץ Kubernetes על Windows, אך עדיין תצטרכו לפחות מכונת לינוקס אחת שתהיה ה-Master (ואם זה פרודקשן, זוג מכונות לינוקס שיעבדו כ-HA). מיקרוסופט עדיין עובדת על זה. תהליך ההתקנה עדיין מורכב (אם כי בגירסה האחרונה יותר קל להוסיף מכונות Windows לאשכול Kubernetes, וחשוב לשנות את קובץ ה-YAML לביצוע Deploy כדי שקונטיינר Windows ירוץ על מכונת Windows. ברגע שיש לכם אשכול כזה רץ, אפשר להגדיר את כלי ה-CI/CD שלכם להשתמש גם ב-Nodes מבוססי Windows ואפשר כמובן להשתמש ב-Draft, Helm לעשות את החיים קצת יותר קלים. לחברות שחושבות לעבור ל-OpenShift – בקרוב תצא גירסה שתומכת גם במכונות Windows. כמובן שאפשר לחסוך את כל הכאב ראש – עם תעברו ל-Net Core.

למעוניינים – להלן וידאו הדגמה משבוע שעבר איך Kubernetes רץ על Windows. (הוידאו ארוך: שעה וחצי!)

הסברים והבהרות לגבי Scale Out בתחום אחסון

אחת למספר שנים מתרחשים שינויים מהותיים בתחום הסטורג'. לפני מס' שנים נכנס דבר שנקרא Object Storage – זו צורה שונה לאחסון קבצים ונתונים שבמקרים רבים אינה משתמשת ב-File system רגיל. חברות כמו Seagate לדוגמא הוציאו מספר דיסקים קשיחים ובנו חיבור חדש לדיסקים – חיבור Ethernet ישירות לדיסק, מה שמחייב כמובן מערכת אחסון אחרת. (נכון להרגע, הפתרון הזה יותר מתאים לחברות כמו אמזון, גוגל ומיקרוסופט, או לחברות שבונות את ה-Object Storage שלהם, גם מבחינת חומרה).

אחד השינויים הגדולים שנכנסו היה עניין ה-Scale Out וכיום כל יצרן סטורג' שמכבד את עצמו מציע דגם זה או אחר (או משפחה) של פתרונות אחסון Scale Out.

אך מהו בעצם פתרון Scale Out?

חברות אחסון רבות לקחו את המושג "Scale Out" לכיוון שהם רוצים. יש חברות שמייצרות HCI (כלומר Hyper Converged) שלקחו את המושג Scale Out לכיוון הוספת שרתים שיתנו לך יותר משאבי מחשוב/רשת/אחסון. חברות אחרות לוקחות את זה לכיוון שאם אתה מרים ערימת שרתים, אתה מתקין VM בכל אחד מהם שמחובר לדיסקים המקומיים בכל שרת וישנה תוכנה שמתחברת לכולם ובכך נוצר Storage (אין Networking גודל בכל מכונה והמכונה לאו דווקא מריצה מכונות VM אחרות) ויש כמובן את ה-Scale Out שעליו דיברתי בפוסט הקודם – ערימת שרתים מלאים דיסקים שלא מריצים מכונות VM או Payload משלך אלא תוכנה יעודית של יצרן הפתרון בלבד.

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

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

לא כל פתרון Scale Out מתאים לכל הסיטואציות. בתחום HCI לדוגמא, אתה יכול להוסיף עוד כמה טרהבייט בחישוב הכולל בכך שתוסיף עוד כמה דיסקים (מכניים/SSD) פר מכונה ובכך תקבל יותר אחסון ויותר IOPS, אבל פתרון כזה אינו מתאים אם לדוגמא אתה צריך מאות טרהבייטים עד פטהבייטים (ומעלה) של אחסון ואין לך צורך בהרבה מקום נוסף למכונות VM. בסיטואציה כזו אתה חייב פתרון אחסון Scale Out שידע לעמוד בשרידות של שרת אחד או 2 שנופלים ולא פתרון Scale Up (למרות שרוב פתרונות ה-Scale Up מתהדרים בכך שהם יכולים לגדול לפטהבייטים).

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

  • אם מדובר במערכת HCI שתהווה אלטרנטיבה ל-VSAN/Simplivity/Nutanix – אז יש את GlusterFS והוא מגיע יחד עם RHV.
  • אם מדובר במערכת Scale Out שלא הולכת לגדול מעבר למספר קטן של שרתים (כמה עשרות) – ניתן לרכוש את GlusterFS בנפרד.
  • אם צריכים מערכת אחסון שתורכב מעשרות שרתים ואחסון בגדלים של מאות טרהבייט ומעלה, או שתריץ מערכת ענן פרטי כמו OpenStack בחברה – מערכת SES של SuSE או Red Hat Ceph Storage יתנו לכם מערכת מבוססת CEPH שבנויה לדברים הללו (הפתרון של SuSE בארץ זול משמעותית בהשוואה למחיר שרד-האט מבקשים, ויש את אותה פונקציונאליות בשתיהן).
  • גם Ceph וגם GlusterFS מתאימות אם אתם הולכים להריץ קונטיינרים/Kubernetes/OpenShift על הברזלים.

לסיכום: פתרון Scale Out טוב (שאינו מבוסס HCI) הוא פתרון שנותן:

  • להגדיל את כמות האחסון למימדים גדולים (מאות טרהבייט ומעלה)
  • שרידות הרבה יותר גבוהה מפתרון Scale Up (מערכת ששורדת גם כששרת אחד או יותר המאחסנים את הפתרון נופלים)
  • תמיכה בסטנדרטים אחרונים (Object Storage, Persistent Volume, ,Cinder וכו')

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

סטורג' לחברות גדולות

הערת עריכה: בעקבות מספר תגובות והערות שקיבלתי, פוסט זה נערך מחדש.

הערה 2: למעוניינים, כתבתי פוסט נוסף לגבי הסברים בין Scale Out ל-Scale Up והוא נמצא כאן (אתם יכולים ללחוץ על הלינק והוא יפתח ב-TAB חדש).

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

מחיפושים שהרצתי לאחרונה בגוגל ומשיחות שערכתי עם מספר אנשים, ישנם מספר גופים שפרסמו RFI או מכרזים לסטורג'ים או שהולכים להוציא מכרז במהלך השנה. אלו תהליכים איטיים ורציתי לנצל את ההזדמנות ולדבר על סוג סטורג' מעט שונה, ה-Scale Out Software Defined Storage.

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

  • קונטיינרים / Kubernetes – הקונטיינרים הנחמדים האלו תופסים מקום, ואם מבצעים Scale Out גדול כך שמריצים לדוגמא מאות קונטיינרים – יש צורך בכמות אחסון גדולה, לא רק לקונטיינר אלא גם ל-Volume שמוצמד לקונטיינר, וברוב המקרים יש לפחות Volume אחד פר קונטיינר שאותו אנחנו רוצים לשמור גם לאחר שהקונטיינר מת.
  • לוגים ותובנות – ככל שיש לנו יותר מכונות וירטואליות, יותר מערכות Orchestration כמו Kubernetes או OpenShift יהיו לנו המון לוגים. אנחנו צריכים את הלוגים שלהם ואנחנו צריכים מערכת ניתוח רצינית (כמו כל המערכות שמבוססות Elastic) והדבר הזה תופס טרהבייטים כמו כלום.
  • מערכות Big Data שונות – יותר ויותר גופים מתעניינים, ומערכות אלו אוכלות אחסון כאילו אין מחר.

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

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

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

יש כמה דברים שכל גוף גדול שרוצה לרכוש סטורג' צריך:

  • תמיכה בפרוטוקולים ידועים (CIFS/NFS, iSCSI)
  • תמיכה בהאצת וירטואליזציה (VASA/VAAI)
  • תמיכה ב-Snapshots
  • מערכת ניהול מרוכזת
  • שרידות גבוהה
  • חלוקת עומסים בין החלקים השונים של המערכת
  • Tiering (מידע שמועבר מדיסקים SSD מהירים לדיסקים מכניים איטיים יותר וההיפך לפי הצורך)

עכשיו אוסיף עוד כמה דברים:

  • תמיכה ב-Kubernetes וב-Persistent Volumes
  • תמיכה ב-Object Storage (כמו S3)
  • תמיכה ב-Cinder (אחסון block)

עתה נעבור לפתרון סטורג' Scale Out שמבוסס על תוכנה (Software Defined)

בפתרון כזה אנחנו לא רוכשים ברזלים קנייניים של יצרן סטורג' כלשהו. במקום זה, אנחנו רוכשים (אחרי תהליך מכרז בו אנו מפרטים כמות סטורג' רצויה, כמות IOPS וכו' וכו') תוכנת סטורג' ומי שזכה מציין איזו חומרה צריך. כל יצרני התוכנה מבצעים Certify מול כל יצרני השרתים הפופולריים כך שלא תצטרכו לרכוש שרתים וציוד ממקור אחר שאין לו חוזה עמכם. החומרה עצמה מורכבת משרתים (לא צריך חזקים), דיסקים SSD ומכניים, כרטיסי רשת 50/100 ג'יגה, וסוויצ'. כל הציוד עצמו אנחנו רוכשים בדיוק מאותו ספק שזכה במכרז למכור שרתים לחברה, וממנו גם נקנה את הדיסקים, כרטיסי רשת ומהזוכה שמוכר לנו את הסוויצ'ים נרכוש 2 סוויצ'ים. לאחר הרכישה, ספק תוכנת הסטורג' יקים את התוכנה, יגדיר את מה שצריך להגדיר וכמובן יתן שרות במסגרת SLA וכל מה שיוגדר במכרז.

הערה: כל יצרני השרתים מוכרים גם פתרונות סטורג' Scale Out משלהם, רובם מצריכים רכישת הברזלים והמערכת מהם.

מדוע פתרון זה עדיף מפתרון סטורג' Scale Up כמו מה שיש ברוב החברות? מכמה סיבות:

  • תמיכה – יש לכם תמיכה מלאה מספק התוכנת סטורג', 24/7, כפי שהגדרתם בהסכם. בנוסף, אם ישנה תקלת חומרה, אתם פונים לאותו ספק שרתים שאתם רוכשים ממנו כל הזמן.
  • מחיר יותר זול – שדרוג דיסקים וזכרון בשרת הוא הרבה יותר זול משדרוג דיסקים בסטורג' קנייני.
  • גדילה יותר זולה – מחירי שרתים יורדים כל מספר חודשים, מה שקשה לאמר על מחירי סטורג' אם רוצים להוסיף מדפים, Flash Cache וכו', כך ניתן להוסיף שרתים, להגדיל את כמות ה-IOPS והמקום הפנוי בצורה יותר זולה.
  • שדרוג לפונקציונאליות נוספת – רוב יצרני ה-Software defined storage מוסיפים פונקציות בגרסאות מתקדמות, והספק יכול לדאוג לשדרוג מערכת קיימת. נסו לקבל פונקציונאליות נוספת משמעותית אחרי שקניתם סטורג' קנייני.
  • טכנולוגיות SSD יותר מתקדמות – סמסונג, אינטל, טושיבה, מיקרון, כולם עובדים על פיתוחים לדיסקים SSD יותר גדולים, מתקדמים, מהירים. כל יצרני השרתים ישמחו למכור לכם את הדיסקים הללו עם תמיכה ושרות מהיצרן שרתים שלכם ישירות. זה לא ממש קיים בסטורג' קנייני – מה שקניתם, זה מה יש (למעט דיסקים בגדלים שונים, אך לא טכנולוגיה שונה).
  • שרידות הרבה יותר גבוהה – כל תוכנת סטורג' מבוססת תוכנה יודעת לתת שרידות ברמת דיסקים או Nodes, כך שגם אם שרת נופל, המערכת ממשיכה לעבוד כרגיל ויש גם תוכנות שניתן איתן להגדיר שגם אם 2 שרתים נופלים – המערכת ממשיכה לעבוד.

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

מוקדש כחומר למחשבה. אם יש לכם שאלות, אתם תמיד מוזמנים ליצור קשר.