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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המלצות וטיפים לגבי רכישת ציוד ל-AI/Deep learning

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

אז אני קודם כל רוצות להודות לחברת CRG שהשאילה לי ציודים (כרטיסי GPU ומכונות) כדי לבדוק פה ב-LAB את הדברים לפני שאני כותב את הפוסט הזה.

נתחיל במקרים פשוטים ונמשיך ביותר מורכבים.

תחנות עבודה
בלא מעט מקרים יש צורך בתחנות עבודה למפתחים ואחד הדברים שצריך להחליט הוא כמובן סוג ה-GPU וכמה כרטיסי GPU. במידה ומדובר בכרטיס אחד ולא ממש מחפשים ביצועים אלא יותר לנסיונות – מומלץ לרכוש כרטיס כמו RTX 2080 או RTX 2080TI, אך לא מומלץ לרכוש RTX 2070 ומטה. הסיבה לכך שכרטיסים כמו RTX 2070 ומטה אינם כוללים חיבור NVLINK (שהוא חיבור מהיר בין הכרטיסים – 100 ג'יגהביט לשניה) כך ש-2 כרטיסי RTX 2070 יעבדו יותר לאט בהשוואה לכרטיסים כמו RTX 2080 או RTX 2080TI עם חיבור NVLINK ביניהם (ניתן לחבר מקסימום 2 כרטיסים). אם מעוניינים בכרטיסים יותר מהירים אך עדיין לא להיכנס לתחומי ה-Quadro וה-Tesla, ניתן לרכוש את ה-Titan RTX.

כמות ה-GPU המקסימלית המומלצת בתחנת עבודה היא עד 3 ויש לכך מספר סיבות:

  1. אם רוצים לעבוד מקומית על התחנה (הכוונה לחבר אליה מסך מקלדת ועכבר), יש צורך ב-GPU כמו RTX כדי לחבר אליו מסך. בחלק מתחנות העבודה יש חיבור VGA אולם זהו חיבור שמיועד לניהול התחנה מבחינת סיסטם ולא לעבודה רציפה (העבודה כדסקטופ לינוקס גרפי תהיה איטית, ויש פה ושם מספר באגים בקוד התצוגה של שבבי הניהול).
  2. הכרטיסים הללו מפיקים המון חום וצריכת החשמל גבוהה – עם 4 כרטיסי GPU ו-2 מעבדים מגיעים בקלות ל-1400 וואט ומעלה.
  3. זה מרעיש.
  4. לפעמים צריכים את התושבת להכנסת ציוד אחר – כרטיסי רשת 10 ג'יגה, חיבור לסטורג' ועוד.

בקיצור – צריכים להכניס מעל 3 כרטיסים לצורך AI/DL? תחשבו על שרתים.

לרכוש כרטיסי TESLA?
כרטיסי ה-Tesla הם כרטיסים מאוד יקרים. החסרון שלהם בהשוואה לכרטיסי RTX היא המהירות שהם עובדים (בערך חצי ממהירות השעון בהשוואה לכרטיס RTX 2080TI), אבל היתרון שלהם הוא בכך שיש להם זכרון בדרגה גבוהה יותר (ECC), אחריות יותר ארוכה, ויותר זכרון מכרטיסי RTX (למעט RTX TITAN שמכיל 24 ג'יגה זכרון בהשוואה ל-11 ב-RTX 2080TI) וניתן לשרשר אותם כדי לקבל מהירות תעבורת נתונים מאוד גבוהה (למעט כרטיס Tesla T4 שאינו כולל NVLink).

שרתים לצרכי AI/DL
כל יצרן שמייצר שרתים (כולל כאלו שפחות ידועים כמו ASUS ו-PNY) מייצר שרתים מיוחדים למטרה זו. המפרטים מגוונים ומבחינת גדלים – מתחיל ב-1U ונגמר גם ב-20U. הפופולריים בד"כ הם 2U או 4U. בדרך כלל ב-2U תוכלו להכניס עד 4 כרטיסים וב-4U תוכלו להכניס (תלוי בדגם וביצרן) עד 16 כרטיסי GPU Dual Slot. בשרתי 1U-2U לא מומלץ להכניס כרטיסי GTX/RTX מכיוון שבעת עבודה רצינית, האיוורור שמגיע דרך המפוח אינו מספיק חזק ולפיכך ה-GPU מאט את פעילותו ומהירות השעון יורדת. כרטיסים כמו Quadro (שאגב, הוא פחות מתאים ל-AI/DL, הוא יותר לתלת מימד ווידאו) ו-RTX לפיכך יותר מתאימים לתחנות עבודה ואילו הכרטיסים לשרתים אינם כוללים מאוורר.

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

לינוקס וכרטיסים ל-AI/DL
באופן עקרוני, הורדת גירסת ה-CUDA מאתר nVidia (בגירסת הקובץ run) מכילה בתוכה כבר את הדרייבר היציב שתומך בכל הכרטיסים, כך שאין צורך להתקין בנוסף דרייבר של nvidia. יחד עם זאת, שימוש במעבד הגרפי הפנימי של אינטל או בממשק הניהול של המכונה בתצורה גרפית והתקנת ה-CUDA יכולים ליצור קונפליקטים שלא יאפשרו למכונה יותר להיכנס למצב גרפי. ניתן בהתקנת ה-CUDA לבטל התקנת OpenGL, אך לפעמים גם זה אינו עוזר (במיוחד כשיש שבב ניהול במכונה של ASpeed) ולכן חשוב להתקין את הפצת הלינוקס ללא סביבה גרפית אלא טרמינל בלבד. אם מעוניינים לעבוד עם שרת מרחוק ובכל זאת רוצים להשתמש בסביבה גרפית, עדיף להתקין תוכנה כמו NX Server של חברת NoMachine או להתקין VNC. אם אתם צריכים גם סביבה גרפית וגם להשתמש בדברים כמו TensorFlow עם OpenGL, מומלץ לרכוש את Nomachine Workstation שכוללת קידוד חומרה של H.264 כך שהדסקטופ הגרפי המרוחק יהיה מהיר מאוד עם תצוגה מעולה.

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

בניה עצמית
בלא מעט מקרים רוצים להשמיש ציוד קיים ופשוט רוצים לרכוש את הכרטיסים ולהכניס אותם פנימה לשרת או תחנת עבודה שקיימת בחברה. אחרי הכל – תושבות פנויות יש, אז פשוט נרכוש ונגמור עניין.
וכאן צצה בעיה: לא כל תושבת PCIe X16 היא באמת כזו. בחלק מהמקרים החיבור הפיזי הוא X16 אולם אם יש כרטיס נוסף במחשב, החיבור ירד מבחינה אלקטרונית ל-X8, ואם מכניסים GPU נוסף (שלישי) אותו חיבור ירד ל-X4. בניקוד למשחקים ועריכת וידאו, ב-AI/DL מהירות ה-PCIe חשובה (גם אם אתם משתמשים ב-NVLink – החומר צריך לעבור דרך ה-CPU) ולכן רק לוחות מסויימים או תחנות עבודה מסויימות שכוללות במפרט נתיבי X16 אלקטרוניים (ויותר מתושבת אחת, ובלי "תנאים") יכולים להתאים לכך.

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

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

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

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

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

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

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

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

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

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

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

פרילאנסרים: תמצאו את החתול

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

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

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

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

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

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

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

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

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

בהצלחה.

להתקדם בתחום

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

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

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

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

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

יש כמה דברים.

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

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

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

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

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

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

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

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

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

בהצלחה.

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

עבדכם הנאמן ממשיך בביקורים בחברות גדולות במשק הישראלי בנסיון להסביר יותר לגבי קונטיינרים, מערכות אורקסטרציה לקונטיינרים (מה שמבוסס Kubernetes), תמיכה ב-CI/CD וכו', אך אחד הדברים שקשה להעביר להנהלות השונות, הוא עניין ה-Scaling הרוחבי, שהוא אחד ההבדלים המהותיים בין עבודה עם מכונות VM ו-Scale קבוע, לבין קונטיינרים עם Scale דינמי.

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

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

אם היינו לוקחים אתר מסחרי ו"ממירים" אותו לעבודה כקונטיינרים על ענן ציבורי כלשהו, רוב התקלות היו נמנעות, כי מערכת כמו Kubernetes/OpenShift יודעות לבצע Scaling אוטומטית אם פשוט מגדירים זאת, בין אם מדובר בגדילה או בהקטנה, בהתאם לעומסים. אתם עובדים עם אמזון וצריכים עכשיו להרים 500 קונטיינרים וכבר הגדרתם את הכל באותו ענן? תוך דקות ספורות הכל יהיה למעלה ואם תצטרכו יותר קונטיינרים עקב עומסים, יקח למערכת שניות ספורות להוסיף קונטיינרים, וזה אחד ההבדלים הגדולים בין קונטיינרים ל-VM (או EC2 Instance): ל-VM לוקח מספר דקות כדי להיווצר ולהיות מוגדר לעבודה יחד עם השאר. גרוע מכך: אם המערכת רצה On Premise, אז בעצם צריך לנחש כמה מכונות להקים ומערכות וירטואליה אינן טובות בהוספה אוטומטית של מכונות VM (וכמובן – בענן ציבורי יש הרבה יותר משאבים ממה שיש On Premise או בכל ספק Hosting מקומי).

קונטיינרים הם דברים חד פעמיים, שנהרסים בתום עבודה (או כשהם קורסים עקב שגיאה/באג), וכשמתחילים להשתמש בכלי CI/CD עם קונטיינרים, כמות הקונטיינרים שתרוץ במקביל מתחילה לטפס במהירות. אם לדוגמא נשתמש בכלי כמו Jenkins עם תמיכה בקונטיינרים ונגדיר את Jenkins לעקוב אחרי כל מיני Repositories של קוד שמפתחים כותבים, ברגע שמבצעים Commit, מערכת Jenkins תקים קונטיינר ותבנה בתוכו את הקוד. נניח שיש לנו מספר Repositories ומספר עבודות ב-Jenkins שזה מה שהן עושות, נראה שהמערכת מהר מאוד תקים מספר קונטיינרים, ואם נגדיר את המערכת להריץ טסטים על קונטיינרים שנבנו מ-Build אחרון, נקבל מספר כפול ותוך זמן קצר כולם יכולים לראות שמשאבים מנוצלים במהירות, הן מבחינת Compute וכמובן מבחינת אחסון (תסתכלו על הגרפים של ה-VM שמריצים את ה-Kubernetes/OpenShift). היתרון הגדול כמובן בקונטיינרים, זה שהכל נבנה מאפס, ואין יותר "אצלי זה עובד אז אם לך לא עובד, זו בעיה שלך".

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

אבל הבעיה מתחילה שצריכים להריץ קונטיינרים ומערכת כמו OpenShift/Kubernetes – כדי לשרת את הקהל בחוץ. כמות הגולשים היא דינמית, והמערכת צריכה להיות בנויה בצורה שונה בהשוואה לעבודה מול מערכות VM או EC2 Instances. דוגמא פשוטה: אם אנחנו רוצים לכתוב תכנים החוצה מהקונטיינר (שוב, קונטיינר הוא דבר חד פעמי וכשהוא נהרס, המערכת מוחקת הכל אלא אם הקונטיינר נבנה עם הגדרות של כתיבה חיצונית בדרכים מסויימות), זה שלאותו VM יהיה גם 10 טרהבייט דיסק קשיח וירטואלי לא יעזור במאומה כי שיטת אחסון הנתונים היא שונה, יהיה צורך במקרים רבים וכשיש כמות גדולה של כתיבה ודרישה לשרידות רצינית – להשתמש ב-Object Storage שמבוצע ב-Scale Out שאינו בנוי על VM שמאוחסן על איזה Datastore ב-vSphere, וכאן כבר יש צורך או בסטורג' Scale Out קנייני שיודע לתמוך ב-Object Storage או להקים מערכת שתרוץ כ-VM על הברזלים וגם הקונטיינרים ירוצו על הברזלים עצמם ללא וירטואליזציה (למעט קונטיינרים מסויימים שאיננו סומכים עליהם ונוכל להריץ אותם עם וירטואליזציה קטנה כמו עם Kata Containers) ומעל זה יכול להיות שנצטרך להריץ איזה Load Balancer כלשהו (אם כי מערכות Kubernetes/OpenShift נותנות פתרון Load Balancing אבל לא בטוח שחברות ירצו להשתמש בו לצרכים של אתרים חשופים). פתרונות כאלו לא יתנו לנו גמישות מקסימלית כמו שרות הרצת קונטיינרים שספקי הענן מציעים (בגלל שלהם יש הרבה יותר משאבים).

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

  • ענן פרטי עם OpenStack: הפתרון הזה יכול לתת לנו את הכל ביחד. אנחנו יכולים להשתמש בסטורג' קנייני כלשהו ולחבר אותו ל-OpenStack כדי לקבל שרותים כמו Object Storage, Block Storage וכו' או שאנחנו יכולים להקים VM בכל שרת ולהריץ עליו Ceph.
  • עבודה במצב Hybrid: יש לנו מקומית מערכת OpenShift או Kubernetes פנימית שעליה אנחנו מבצעים פיתוח וכו', ואת האתרים הציבוריים אנחנו נשתמש בשרותי הקונטיינרים שספק הענן שבחרנו מציע. אם לדוגמא החברה משתמשת ב-Azure, אז הם יכולים להשתמש בשרות AKS. באמזון יש את אותו שרות (בערך) שנקרא EKS (או Fargate ששם אמזון מנהלת את ה-Kubernetes ואתה מריץ את הקונטיינרים) ובענן של גוגל יש את GKE. ה-Hybrid מומלץ לחברות שהרגולטור אוסר עליהן להוציא הכל החוצה.
  • עבודה "באותו ענן" – במקומות בהן בחרו לעבוד לדוגמא עם Azure, ניתן לרכוש מיצרן השרתים המועדף עליכם את Azure Stack – זהו פתרון שרץ על הברזלים אצלכם מקומית עם חיבור ל-Azure, כך שאפשר להשתמש באותם שרותים, מקומית או בענן בחוץ. עם עננים אחרים, אתם משתמשים בשרותי ה-Kubernetes של ספק הענן כך שהשינויים להריץ דברים מקומית או בענן הם די מינוריים וניתן להפריד את ההגדרות לקבצים שונים. בהמשך השנה, גם אמזון וגם גוגל יציעו לכם ברזלים ותוכנה להריץ את השרותים שאתם מריצים בענן – מקומית ובענן, כמו ה-Azure Stack.
  • שימוש ב-OpenShift – מערכת OpenShift קיימת לשימוש מקומי בשרתים שלכם או ב-OpenShift בענן שקיים אצל כל ספקיות הענן.

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

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

סקירה: מיקרו שרת של HPE דור 10

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

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

נתחיל במפרט הטכני:

  • מעבדים – AMD Opteron (קיימים 3 דגמים: X3216, X3418, X3421). הדגם שמיובא לארץ הוא הדגם הנמוך עם מעבד X3216 עם 2 ליבות, 1 מגה זכרון מטמון, APU מובנה, ומבחינת כח – הוא הכי נמוך עם הספק של 12-15 וואט). שאר הדגמים הם עם 4 ליבות, 2 מגה זכרון מטמון, כח גרפי מעט יותר חזק, והספק של 12-35 וואט.
  • זכרון – עד 32 ג'יגהבייט (ECC).
  • אחסון: 4 דיסקים קשיחים בגודל 3.5 אינטש ללא תמיכה להחלפה חמה, ואפשרות להוסיף דיסק 2.5 אינטש בחיבור SATA (לצרכים של Boot או Cache עם SSD).
  • חיבור PCIe: ישנם 2 תושבות, הראשונה היא PCIe X8 והשניה היא PCIe X1 בחיבור של PCIe X4.
  • חיבורי רשת – 2 חיבורים של 1 ג'יגה עם LOM
  • חיבורי תצוגה – 2 חיבורי Display Port כולל תמיכה ברזולוציית 4K.
  • חיבורי USB – כ-2 חיבורי USB 2.0 ו-2 חיבורי USB 3.0.

נתחיל בקהל היעד: קהל היעד למכונה זו (בשימוש כ-NAS) הם אלו שמעוניינים ליצור לעצמם גיבויים – הן מבחינת תכנים שקיימים להם, גיבוי מכונות Windows או לינוקס. HPE רשמית ממליצה על מערכת הפעלה ClearOS שמתאימה ל-SMB/SOHO אבל כמובן כל מערכת הפעלה מודרנית תרוץ ללא בעיות על מכונה כזו. (שימו לב: המערכות שנמכרות בארץ עם X3216 יהיו איטיות בהרבה מ-2 האופציות האחרות ש-HPE מוכרת ולכן לא כדאי "להשתולל" עם התקנת שרותים רבים על המכונה).

למי שמעוניין להקים LAB קטן לעצמו ורוצה את המכונה הזו כשרת NFS או iSCSI או SMB/CIFS – כדאי שיקח בחשבון שהביצועים שהמערכת שנמכרת בארץ, מנפיקה ביצועים די איטיים, כך שאם אתה רוצה להרים מספר דו ספרתי של VM, אולי עדיף שתחפש פתרון אחר או … תצטייד בסבלנות (או שתכניס כרטיסי 10 ג'יגהביט ו-SSD ל-NAS וכרטיסי 10 ג'יגה לשרתים האחרים שלך).

מבחינת המעבד עצמו, HPE ו-AMD עשו בסופו של דבר עיסקה לא רעה בכלל: ל-AMD יש מלאי רציני של מעבדי Opteron ישנים שהם רוצים להיפטר מהם (לטובת ה-Ryzen V1000 ו-EPYC Embedded), ו-HP חיפשו מעבדים לשרתים בקצה הנמוך מאוד ובמחיר זול מאוד. AMD, לפי השמועות, מוכרים את המעבדים בכחמישית מהמחיר שאינטל מבקשת על אותו מפרט וה-Opteron (לפחות ה-X3421) נותן פייט די רציני למעבדי ה-Atom C3000 של אינטל. התוצאה: הלקוח מקבל מכונה עם ביצועים די מכובדים כ-NAS (שוב, לא הגירסה שנמכרת בארץ) במחיר מאוד נמוך של כמה מאות דולרים. אגב, אחד השימושים הכי מעניינים שיצא לי לשמוע עליו בשימוש מכונות כאלו, אגב, הם מקומות עם תקציב די קטן שמריצים קונטיינרים. לפחות מ-2 מקומות (בחו"ל) שמעתי שהם מרוצים מהתוצאות.

מבחינתי, הבעיה המרכזית במכונות הללו היא התכנון שלהם. ב-HPE יכלו לדוגמא לוותר על יציאת Display Port אחת ולהחליף את חיבורי הרשת הקבועים בחיבור של מודול, כך שהלקוח היה יכול להחליף בין 2 חיבורי 1 ג'יגה ל-2 חיבורי 10 ג'יגה, ובנוסף הם יכלו להוסיף ללוח האם כניסת M.2 PCIe X4. הוספת 2 הדברים הללו היו יכולים לשדרג מכונה כזו לביצועי NAS מכובדים מאוד, לשמש כ-Storage למספר קטן של מכונות פיזיות המריצות וירטואליזציה ועוד, אבל כנראה ש-HPE מעדיפים שאם אתה רוצה משהו עם ביצועים קצת יותר גבוהים – תכיר את המכונות שלנו שמבוססות Xeon SP או AMD EPYC – שהן כמובן הרבה הרבה יותר יקרות.

לסיכום: האם הייתי ממליץ לאחרים לרכוש את המכונה הזו? כן, אם הצרכים שלהם הם מה שציינתי לעיל. אם הם צריכים משהו יותר חזק, אז עדיף שיחפשו את הגירסה עם מעבד X3421 או שיחפש פתרון NAS אחר או שיבנה לעצמו NAS. אישית, אני מקווה בזמן הקרוב לבחון לוח אם חדש (שעדיין לא יצא – מחברת ASRock Rack) המבוסס על מעבד EPYC Embedded ושתומך בהרבה יותר דיסקים קשיחים, יש בו כניסת M.2, תושבת PCIe X16 ו-2 כניסות 10 ג'יגהביט מובנות – ואת זה להכניס למארז 2U.

על קונטיינרים ו-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. (הוידאו ארוך: שעה וחצי!)

על תחנות עבודה/שרתים ל-AI/DL

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

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

לפני שניגש לעניין התחנות, נסתכל על ה-GPU והשאלה הראשונה שצריכה להישאל היא: האם בחברה משתמשים ב-CUDA או ב-OpenCL? אם מדובר ב-CUDA, אז כרטיסים של חברת nVidia יכולים להיכלל. אם מדובר לעומת זאת ב-OpenCL, אז כרטיסים של AMD מסידרת Instinct (דרך פלטפורמת ROCm), ה-GPU הפנימי של מעבדי אינטל (לחישובים קטנים, או ב-CPU עצמו, זה גם עובד על מעבדים של AMD) או לכרטיסים שאינטל תוציא בשנה הבאה.

השאלה הבאה צריכה להישאל היא לגבי "שרשור" כרטיסי GPU. ל-nVidia יש את ה-NVLink שמאפשר להצמיד זוג כרטיסים ולקבל תקשורת ביניהם במהירות 100 ג'יגהביט לשניה. ל-AMD עם כרטיסי MI50 ו-MI60 יש את AMD Infinity Fabric לחבר בין זוג כרטיסים ולקבל מהירות של 200 ג'יגהביט לשניה. לכן חשוב לדעת מראש כמה כרטיסי GPU יהיו בתחנה, והאם אתם רוצים להצמיד כל זוג.

השאלה הבאה: כמה כרטיסים יהיו במכונה?

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

אם אנחנו מדברים על 3 כרטיסים ואנחנו מתכוונים גם להשתמש גם באחסון בתצורת חיבור M.2 – מומלץ להסתכל על פתרון מבוסס AMD Threadripper מהסיבה הפשוטה שמעבד זה מציע יותר נתיבי PCIe (כ-64 נתיבים) בהשוואה לכל מעבד דסקטופ של אינטל. מעבד זה הוא היחיד שמאפשר לחבר 3 כרטיסים. לגבי כמות ליבות – יש מספר דגמים, כמו 2950X עם 16 ליבות, 2970WX עם 24 ליבות ו-2990WX עם 32 ליבות. ההבדל בינם מבחינת מחיר – כמה מאות בודדות של דולרים.

אם אנחנו מדברים על 4 כרטיסים (עם או בלי הצמדה) אני ממליץ להסתכל על פתרון מבוסס AMD EPYC. מעבד זה נותן לנו לא פחות מ-128 נתיבי PCIe, כך שאפשר "להשתולל" מבחינת מפרט מבלי "לחטוף" במחיר, הואיל ומעבד EPYC נחשב מעבד זול מבחינת מחיר (אבל הוא מעולה מבחינת ביצעים). מכיוון ש-EPYC הוא מעבד לתחנות עבודה יעודיות ושרתים, נזכיר גם את מעבדי Xeon SP של אינטל, ובמקרה כזה נצטרך פתרון של 2 מעבדים (תלוי בכמות הליבות שאנחנו רוצים). אם אנחנו מעוניינים בכמות גדולה של ליבות (16 ומעלה) עדיף לבחור את הפתרון של AMD מבחינת מחיר זול יותר.

אחרי שדיברנו על ה-GPU, השאלה הבאה תהיה: איזו מערכת הפעלה רוצים להריץ על המכונה? גם ב-AI וגם ב-DL רוב הדברים הזמינים ונתמכים – רצים על לינוקס, פחות על Windows. יש הרבה דברים פופולריים כמו TensorFlow שירוצו על Windows, אך יש פחות תמיכה על כך מהקהילה.

השאלה הבאה: מחשב בניה עצמית או מותג? אפשר לרכוש את החלקים ולהרכיב, או שאפשר לרכוש מכונות מותג. כל אחד והעדפותיו. אם אתם מחפשים מכונות מבוססות EPYC, ל-Gigabyte יש את W291-Z00 ואת SuperMicro עם השם המאוד-קליט A+ Server 4023S-TRT. מכונות מבוססות Xeon או מעבדי אינטל – תמצאו אצל כל יצרן.

דברים שכדאי לבדוק לפני הקניה:

  • כרטיס רשת 10 ג'יגהביט – אם יש לכם כמות גדולה של תכנים שצריכה להיות מוזרמת אל התחנה, מומלץ להשתמש בכרטיס 10 ג'יגהביט בין האחסון המרוכז לתחנת העבודה. אם מדובר על מאות קבצי BLOB (תמונות וכו') בדקה, כדאי לשדרג ל-25/40/50 ג'יגהביט.
  • כמה סשן של פעילות צורך זכרון GPU? כרטיסי RTX מעל 2080TI יקרים מאוד, כדאי אולי לרכוש זוג כרטיסים "ביתיים" מאשר כרטיס אחד שעולה הרבה יותר.
  • אם כל התוכן שצריך לעבור "אימון" לא עולה על 2 טרהבייט ויש מכונה אחת – כדאי לרכוש 2 מקלות אחסון כמו סמסונג 970 PRO (או EVO 860) ולהגדיר אותם כ-RAID-0 ולאחסן את התוכן עליהם.

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

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

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

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

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