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

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

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

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

קונטיינרים ומכונות וירטואליות – השילוב הנחוץ

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

הפעם נדבר על דבר הפוך וחדש.

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

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

כאן נכנס לתמונה כלי חדש של רד-האט שנקרא Kubevirt.

Kubevirt בעקרון עושה משהו הפוך ממה ש-CRI-O עם Kata containers עושה: עם CRI-O אנחנו מריצים קונטיינרים בתוך VM מינימלי, ואילו Kubevirt מריץ מכונה וירטואלית בתוך POD, וכן, אני מדבר על המכונה הוירטואלית המלאה – עם OS ואפליקציות משלה, שמתורגמת ישירות מ-VMWare או מ-OVA.

במילים אחרות – אנחנו נריץ VM כ-קונטיינר! (וכן, נקבל את האבטחה המלאה של ה-VM).

כך ניתן בעצם עם Kubevirt לקחת את אותן מכונות וירטואליות שלא ניתן להמיר לקונטיינרים ולהריץ אותן ישירות בתוך Kubernetes או OpenShift ובדרך להנות מדברים כמו Scaling ועוד תופינים שמערכת Kubernetes/OpenShift נותנת, מבלי שנהיה תקועים עם דברים שאי אפשר להמיר לקונטיינרים. כך לדוגמא אצל אותה חברה פיננסית גדולה, כל מה שאצטרך בעצם לעשות, זה להמיר את ה-VM (ליתר דיוק את הדיסק) ל-Persistent Volume ובקובץ ה-YAML להשתמש ב-PVC על מנת "לחבר" את ה"דיסק") לאותו VM.

יש גם מגבלות נכון לגירסה הנוכחית כמו:

  • אפשר להשתמש רק בדיסק קשיח יחיד
  • יש רק כרטיס רשת אחד, וגם איתו אי אפשר לשחק הרבה הואיל והמערכת מבצעת Proxy בין ה-VM לתקשורת של ה-POD.

רד-האט, מפתחת Kubevirt, פרסמה לאחרונה פוסט בנושא.

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

למעוניינים, באתר Kubevirt יש מספר דוגמאות איך ניתן להשתמש בכלי הן עם Minikube, הן בתוך Cluster של Kubernetes, הן בתוך AWS, והן בתוך GCP.

לסיכום: Kubevirt נותן סוף סוף את האפשרות לחברות לקחת מכונות וירטואליות ולהעביר אותן לעבוד יחד עם Kubernetes או OpenShift. אינני מדבר על ההעברה של כל תשתית הוירטואליזציה ל-Kubernetes (אני לא מוצא יתרון בהעברת מכונת SAP), אלא לדברים שאנחנו צריכים כחלק מעבודות מתודת Devops, CI/CD וכו'. במקרים שקשה או לא ניתן להעביר מכונות וירטואליות לפורמט קונטיינרים, הרבה יותר קל להעביר מכונה וירטואלית מפורמט VMware לפורמט KVM ולהריץ את אותה מכונה וירטואלית כמו שהיא – כקונטיינר.

הערה: הכלי נמצא במצב Preview והוא עדיין בפיתוח.

 

סטטוס וירטואליזציה מבוססת קוד פתוח – סוף 2018

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

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

אני מודה שעד לאחרונה כל עניין הוירטואליזציה בקוד פתוח לא ממש תפס אחוז גדול בתחום ההטמעות ב-Enterprise. כמעט כולם הולכים ל-VMware, חברות שכמעט כל התשתית שלהם מבוססת מיקרוסופט משתמשים ב-Hyper-V ואלו שרוצים Hyper Converged הולכים על Nutanix או Simplivity. אחרי הכל – למוצרים האלו יש תמיכה, יש בארץ אינטגרטורים, לא צריך לקנות מחו"ל רשיונות, יצרני החומרה מאשרים שהמוצרים עובדים עם הברזלים. בקיצור, סבבה אגוזים.

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

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

בפוסט זה אציג, כמו בפוסטים קודמים – 3 מערכות (Proxmox, oVirt/RHV, OpenStack) ולמי הם מתאימים ומה השוני שלהם.

נתחיל במערכת שמתאימה יותר לחברה קטנה או ל-LAB מקומי: Proxmox.

תוכנת Proxmox מתאימה ליישומי וירטואליזציה הן על מערכות ישנות (כן, אותו שרת G7 של HP שיושב שם בצד) והן על מערכות חדשות. המערכת עצמה היא יחסית קלה ללימוד, ומי שעבד על ESXi עם vCenter בצורה לא מקצועית (כלומר לא עבר קורסים והכשרות של VMware) יוכל להקים תוך דקות ספורות מכונות וירטואליות על דיסקים מקומיים, לחבר NFS או iSCSI וגם להשתמש ב-HA ולבצע Live Migration (כל עוד יש אחסון משותף, זו לפחות הדרך המומלצת). בקיצור -אם אתם צריכים להקים מערכת וירטואליזציה על מספר קטן של שרתים, ללא הקמה של רשתות וירטואליות מורכבות או דברים הרבה יותר מורכבים (DVSwitch?) – אז Proxmox יכול להתאים למשימה.

המערכת הבאה יותר מתאימה לחברות שמריצות מערכות וירטואליזציה מורכבות עם רשתות וירטואליות שונות (המערכת משתמשת ב-Open Virtual Network ו-Open vSwitch, וכן רשתות SDN), סטורג'ים בפרוטוקולים שונים, חיבור ל-OpenStack, ודברים נוספים. המערכת היא oVirt. טכנית, oVirt נבנתה מגירסה 4 להריץ מערכות גדולות וכשאני מציין גדולות, אני מדבר על אלפי ועשרות אלפי מכונות וירטואליות. בשעה שפתרונות כמו ProxMox מתרכזים ב-Bridge Networking, מערכת oVirt תומכת במספר פתרונות רשתות וירטואליות, והיא בין המערכות היחידות שתומכות גם בפלטפורמות שאינן X86-64 כמו מערכות Power ו-S390 של IBM. מבחינת HA, היא בין המערכות המובילות בדיקות ברמת חומרה (דרך ILO/IMM/IDRAC) מה קורה לברזל והיא יודעת להעביר את ה-VM אם יש תקלה ולטפל בשרתים פיזיים בעייתיים – החל מהקמה של חדשים, שדרוג קיימים ועוד. מערכת oVirt מבוססת על מערכת KVM האחרונה (כן, אותה חברה שמפתחת את oVirt היא אותה חברה שמפתחת את KVM – זו רד-האט) כך שיש תמיכה בציודים וירטואליים חדשים, מערכות UEFI וירטואליות מודרניות ועוד), התממשקות ל-VCenter, המרה יעילה של מכונות וירטואליות ל-oVirt, תמיכה ב-AD/LDAP ועוד שורה ארוכה של פונקציות. בהשוואה ל-Proxmox, מערכת oVirt היא מפלצת ולכן היא פחות מתאימה לרוץ על שרתים עם מכונות וירטואליות שמאוחסנות על דיסקים מקומיים. oVirt, אגב, מגיעה מוכנה לשימוש הן כשרת שיתחבר לסטורג' והן כ-Hyper Converged.

oVirt מתאימה להטמעות גדולות הן כ-PoC והן כפרודקשן כל עוד יש בחברה ידע פנימי (או יועץ חיצוני) שיכול לתת תמיכה. מנהלים שמנוסים עם VMWare או Hyper-V ואינם מנוסים מספיק או בעלי ידע רציני בלינוקס יתקשו בניהול מערכת כזו ללא השקעה בלימוד הדברים, והסיבה לכך פשוטה: oVirt אינה מנסה להיות העתק של VMware והדגש של oVirt הוא יותר על פונקציונאליות מאשר חזותיות (אם כי חל שיפור ניכר בחלק הזה בגירסה 4.2 ובגירסה 4.3 שתצא במהלך 2019). חברות שמעוניינות במוצר ארוז ובתמיכה רשמית עם רשיונות – ניתן לרכוש את מוצר ה-RHV עם תמיכה.

ומכאן – למפלצת הגדולה: OpenStack.

אם oVirt היא מערכת גדולה, OpenStack היא גודזילה לכל דבר ועניין. ההבדל הגדול בין oVirt ל-OpenStack הוא ש-OpenStack מנסה לתת לך הכל מהכל. וירטואליזציה? יש. קונטיינרים? יש את Zun שמאפשר להריץ קונטיינרים כ-שרות. DB כ-שרות? יש. אחסון תואם S3? יש. אחסון Images ודברים אחרים? יש. צריך Load Balancer? תכיר את Octavia, ויש עוד עשרות חלקים. עם oVirt לעומת זאת – המיקוד הוא לכיוון מתן שרותי וירטואליזציה והשרותים מסביב, לא יותר מכך.

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

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

ומה העתיד?

פתרונות הוירטואליזציה ממשיכים להתקדם, גם הפתרונות המסחריים הסגורים אך גם הפתרונות מבוססי הקוד הפתוח. ב-VMWare הכריזו בכנס האחרון על ESXI ל-ARM, פלטפורמה שנכנסת יותר ויותר לספקי הענן הציבורי ו"זוחלת" לכיוון ה-Enterprise (תסתכלו על Ampere). פתרון הוירטואליזציה KVM ו-QEMU (שבהם כל מערכת בנייה כמו Yocto משתמשות) יש תמיכה בעשרות מעבדי ARM כבר 6 שנים ומעלה, מערכת OpenStack תומכת ב-ARM, ו-oVirt תתמוך כנראה בגירסה הבאה (אם לא תהיה גירסה כזו, אני כנראה בשנה הבאה ארכוש שרת ARM ואבצע BUILD לכך. מהנדסי רד-האט ישראל – תתכוננו להצקות ממני 🙂 ). עוד ארכיטקטורה שהולכת להיתמך היא מעבדים זולים מבוססי MIPS החדשים.

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

מבחינת אחסון: ישנו תהליך יחסית די חדש שיכנס לאט דרך יצרני ה-SSD והוא "העפה" של מערכת הבקר מה-SSD כך שמערכת הוירטואליזציה תחליט איך לנהל את ה-SSD, איך לבצע Garbage Collection לפי העומסים במכונה, לפי המכונות הוירטואליות שירוצו ועוד. אינטל גם תוציא את ה-Optane DC Persistent Memory – מקלות אחסון שיושבים היכן שמקלות הזכרון יושבים, מכילים הרבה יותר אחסון ממקלות זכרון ECC רגילים ועם ביצועים קרובים לביצועי זכרון. תמיכה לכך ב-OpenStack תהיה קיימת בקרוב (להלן השקפים), רק שמחכים למעבדים ושרתים מבוססי Cannon Lake SP.
עוד תחום אחסון שיקבל Boost רציני בוירטואליזציה הוא NVMEoF שיתן Latency מאוד נמוך.

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

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