נקודות שיצרני Storage לא רוצים שתדעו

כפרילאנסר שמוכר שרות הטמעה/התקנה של SDS (כלומר Software Defined Storage) אני משתדל בדרך כלל להיות מעודכן גם ב"רכילות" של מה קורה אצל אלו שמוכרים פתרונות כ"קופסאות סגורות", מה-NetApp ו-Dell/EMC ועד ליצרני פתרונות AFA (כלומר All Flash Array) למיניהם. תמיד נחמד לדעת על כל מיני פתרונות שיצרני ה-AFA מכניסים או הולכים להכניס בשעה שהגדולים .. המהנדסים שלהם מדברים על פתרונות כאלו בארוחת צהרים, ההנהלה לא הכניסה את זה ל-Road Map עדיין.

כשזה מגיע ל-SDS, החיים קלים ופשוטים: הלקוח רוכש שרת, עם כל הציוד הנדרש, דיסקים וכו', הוא נניח שוכר את שרותיי, אני מציע לו מספר פתרונות, בין בקוד פתוח או סגור (כולם מבוססי לינוקס למעט Windows – ב-Windows יש לו כיום את Storage Spaces [שהוא אגב, אינטרגלי ב-Windows Server 2016] והוא ממש לא צריך אותי לשם כך), הלקוח בוחר, מרימים גירסה, אני מגדיר את כל מה שהלקוח מבקש, מריצים סידרת טסטים ואם הוא מרוצה – מכניסים לפרודקשן. במקרה ויש לו בעיות עם המערכת הוא פונה אליי ואני מטפל בבעיה אם מדובר בתוכנה או מבקש ממנו לפנות למי שהוא קנה ממנו את הברזל כדי להחליף דיסק/זכרון/לוח/כרטיס-רשת וכו'. פשוט וקל.

אבל כשזה מגיע לסטורג' סגור, אני ממליץ לעבוד בשיטה שאני קורא לה "הבן של מי אתה?"

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

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

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

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

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

  • אם אתם חושבים לרכוש סטורג' – ראשית מומלץ לבדוק לגבי המוצר שאתם רוצים לרכוש – האם הוא מוצר שיוצר בעבר ע"י חברה אחרת שנרכשה ע"י אותה חברה גדולה שאתה רוצה לרכוש ממנה. אם כן – עדיף לחפש מוצר אחר.
  • אם כבר רכשתם מוצר מחברה קטנה שנרכשה ע"י החברה הגדולה, תפנו זמן לצוות הטכני ותתנו להם הוראה להתחיל להתעמק ב"בפנוכו" של הסטורג', לא ברמת GUI אלא ברמת CLI. לא צריך לנסות דברים שיזיקו, אבל כדאי שיכירו את הפקודות, קבצי הקונפיגורציה ומי עושה מה.
    • עוד משהו שאתם יכולים לעשות – זה להיעזר בחברים ולרכוש בנק שעות תמיכה מאינטגרטור שמכיר את הסטורג' הזה. אישית אינני נותן שרותים לסטורג' סגורים, אבל מהיכרות עם חברים שנתנו תמיכה לכל מיני חברות ועסקים שיש להם סטורג'ים כאלו – ההשקעה בבנק שעות כזה הצילה חברות לא פעם ולא פעמיים בהשוואה ל"טקס מעבר-בגהינום" של התמיכה בחברה הגדולה. קנו לכם כמה עשרות שעות שיהיה לכם שקט במקרה של תקלות (יהיה לכם עדיין את היתרון שבמקרה ויש תקלת חומרה – החברה הגדולה תשלח נציג שיבוא ויחליף את הציוד התקול).
  • העולם עובר ל-Software Defined Everything, מסטורג' לרשת ודברים נוספים, ולכן מומלץ לשקול בחיוב לקחת פתרון Software Defined Storage. אל תאמינו לי, תשאלו את VMWare, Microsoft, Red Hat, Amazon וחברות מפורסמות אחרות. עם SDS אין לך שום "מסע גהינום" של תמיכה, יועץ/אינטגרטור נותן לך תמיכה ואם אינך מרוצה אפשר להחליף אותו ביועץ/אינטגרטור או חברה שנותנת את אותם שרותים ואם יש תקלת חומרה – החברה שמכרה לך את הברזל תחליף לך את הציוד, כך שזמן ההשבתה מתקצר משמעותית, יש למי לפנות וניתן לקבל בזמן קצר פתרונות.

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

כמה מילים על הטמעת CUDA

יותר ויותר חברות משתמשות היום בתוכנות תלת מימד, תוכנות הדמיית ויזואליזציה, והמון המון חישובים מסוגים שונים, בין אם מדובר במסחר (Algotrading) והמון דברים אחרים, וגם לאחרונה CUDA נכנס גם בשימוש עם קונטיינרים – מספר קונטיינרים יכולים להשתמש ב-GPU יחיד או מספר GPU שנמצאים בשרת (זה פחות מתאים לכרטיסי GTX ויותר מתאים בכרטיסים כמו Grid, Tesla וכו').

לפני שניגש לעניינים הטכניים של הטמעת CUDA, כדאי קודם כל להכיר את הכרטיסים של nVidia שתומכים ב-CUDA. באופן עקרוני, כל צ'יפ של nVidia תומך ב-CUDA. לדוגמא: במחשב הנייד הישן שאני כותב את הפוסט הזה קיים מעבד (די עגלה) GT 720M של nVidia ולמרות שהוא ישן – הוא תומך ב-CUDA ואני נעזר בתמיכה הזו לרנדר וידאו באדובי פרמייר טרום פרסום הוידאו ביוטיוב.

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

  1. כרטיסי ה-Quadro מגיעים עם יותר זכרון (בגרסאות הדסקטופ, לא בגירסאות ה-Mobile) בהשוואה ל-GTX. בכרטיסים מסויימים יש לא פחות מ-24 ג'יגהבייט זכרון (שהוא מאוד יקר), מה שנותן לאפליקציות שמשתמשות ב-CUDA יותר מקום והביצועים מהירים פי כמה בהשוואה ל-GTX.
  2. הכרטיס כולו בנוי בצורה מעט שונה (אם כי לא רואים זאת ישר). כרטיסי Quadro מיועדים לעבוד 24/7 באופן רציף בתפוקה מלאה, וזאת בניגוד למשתמש טיפוסי של GTX שמשחק פה ושם משחקים או מרנדר וידאו מלא (או 2) ביום. הכרטיסים בנויים עם איוורור מעט שונה וגם האחריות בהתאם – לכרטיס Quadro יש אחריות ל-5 שנים.
  3. לכרטיסי Quadro יש דרייברים מיוחדים המפעילים פונקציות שאינן פעילות כלל ב-GTX. החסרון (אם אפשר לקרוא לזה כך) זה שכרטיסי Quadro אינם מתאימים כל כך למשחקים אך הם בהחלט מתאימים לעבודות מאסיביות והדרייברים מאפשרים שלל תכונות שדרושות בדיוק לסוג העבודות הללו.

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

מכאן נעבור להתקנת CUDA.

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

  • כשזה מגיע לגירסת לינוקס – אין להתקין גירסת לינוקס שמיועדת לדסקטופ, כלומר אובונטו 15,16,17 (בין אם בגרסאות 04. או 10.) שמיועדות לדסקטופ אינן מתאימות לפרודקשן הואיל והעבודות שירוצו עם ה-CUDA הן למשך מספר שנים ולא לשנה שנתיים, ובנוסף – נדרשת יציבות מקסימלית ולכן יש להתקין את אחת מהפצות הלינוקס הבאות:
    • גירסת CentOS 7.3 (ואם אתם עדיין מתעקשים על גירסה 6 של CentOS – אז CentOS 6.9)
    • SLES 12 SP2 ומעלה – של SuSE
    • Debian 8-Jessie או Debian 9-Stretch. ניתן להשתמש גם ב-Debian 7-Wheezy אולם סביר להניח שיהיו בעיות קומפילציית מודולים בהמשך, קחו זאת בחשבון.
    • אובונטו – הנה הפתעה לקוראים: הגירסה היחידה המומלצת היא Ubuntu 16.04.2 LTS (אם יש לכם 16.04.01 – בצעו שדרוג ל-16.04.02). זו הגירסה היחידה לשרתים שקנוניקל משחררת ותעמוד מאחורי גירסה זו ל-5 שנים הקרובות. שאר הגרסאות מיועדות לדסקטופ והן משתנות תדיר, דבר שממש לא מומלץ להתקין בשרת.
  • אחת הטעויות הנפוצות (במיוחד מאנשי לינוקס שהתחילו עם אובונטו) היא התקנת סביבה גרפית גם בשרת. זו טעות, במיוחד אם אתם משתמשים בכרטיס GTX לעבודות CUDA. ה-GPU צריך לרנדר את הסביבה הגרפית 60 פעם בשניה (או 50 בחלק מהמקרים) וזה סתם מוסיף עבודה ל-GPU ולכן: בשרת, לא מתקינים סביבת עבודה גרפית. תתרגלו לטרמינל, מה קרה? 🙂
  • לא להריץ update/upgrade סתם כך! במקרים רבים עדכון הפצת הלינוקס ישדרג גם את הספריות והקרנל ובמקרים רבים אין קרנל מודול ל-GPU שמקומפל לקרנל החדש, מה שמצריך או קימפול מחדש או שימוש ב-kmod/dkms כדי לקמפל מודולים לקרנל החדש. שימוש בקרנל חדש מצריך reboot ולכן עדכונים ושדרוגים – יש לבצע בסוף יום עבודה או לקראת סופ"ש על מנת שלא להפיל עבודות שמשתמשות ב-CUDA.
  • לא להפעיל RAID תוכנה על השרת. תלוי בסוג העבודה, יכול להיות שבנוסף ל-GPU, גם ה-CPU יהיה מלא בעבודה ולכן בד"כ מומלץ שלא להקים RAID תוכנה אלא RAID חומרה עם כרטיס (למעט בשרתים בהם יש RAID חומרה על לוח האם). אני מודע לכך שזו נשמעת המלצה מוזרה, אולם ראיתי מקרים כאלו ש-RAID תוכנה נפל (במיוחד שמדובר בדיסקים SATA "ביתיים" פשוטים) כשה-CPU היה חנוק עם כל הליבות שלו. כרטיס RAID פשוט עולה 50$ ואם המערכת שלכם הולכת לייצר המוני קבצים לקריאה וכתיבה סימולטנית – חברו אותה לסטורג' או במינימום NAS טוב.
  • אם יש לכם הפצת CentOS – השתדלו לא להשתמש בקרנלים מ-ElRepo Repository. ה-REPO הזה נותן קרנלים חדשים ל-CentOS אולם מנסיוני הם מלאים באגים כרימון.

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

בהצלחה.

גילוי נאות
הטמעות ותיקון תקלות הקשורות ב-CUDA זה חלק מהשרות ש"חץ ביז" נותן

על הקשחות תחנות עבודה/דסקטופ ושרתים

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

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

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

  • אנשים מסתכלים על המאמרים של מיקרוסופט וחושבים שעניין האבטחה זה כמו שמיקרוסופט מפרסמת – 3-5 עמודים בלינקים שונים ואפשר לסמן ✔ על הנושא. זהו, שזה לא. אבטחת מידע רצינית בין אם זה על דסקטופ או שרת היא הרבה יותר מורכבת ואתם מוזמנים להעיף מבט על ה-CIS Benchmark שנחשב ה-דבר בהקשחה. על Windows 10 בלבד מדובר על 942 עמודים. Windows Server 2012 R2? זה 732 עמודים. (ועם CIS זה הולך לפי ניקוד לגבי השינויים שעושים, כל דבר מקבל ניקוד שונה)
  • אין "הקשחה אחידה". איש אבטחת המידע רוצה את מקסימום האבטחה, איש ה-IT רוצה פחות כדי שהוא אשכרה יוכל לעבוד בצורה נוחה, ולכן זה יקח לא מעט זמן לעבור על הנקודות ולבצע את הדברים.
  • "חיתוך פינות" – הנה משהו שאני שומע שוב ושוב מלקוחות פוטנציאליים: "כבר עשית את רוב העבודה ללקוחות קודמים, תביא את זה, נעשה תיאומים ונגמור עניין". הבעיה – עדיין לא פגשתי לקוח שמוכן שקוד או סקריפטים שכתבתי עבורו – יעברו הלאה ללקוחות אחרים, גם אם מדובר בדברים שכתבתי בביתי עם ה-LAB שלי. לקוחות רוצים משהו פשוט: שילמנו? זה נשאר אצלנו וזה לא עובר לאף לקוח, אז צריך לכתוב מחדש דברים שוב ושוב.
  • אוטומציה – האם אפשר לעשות את הדברים בצורה אוטומטית פחות או יותר? (להריץ אוטומציה בלי הגדרות פר שרת ששונים מאחד לשני יוביל להשבתה של המערכות שלכם. ראיתי כבר מישהו שניסה זאת פעם) – בהחלט, אבל זה דורש עבודה של 2-3 חודשים של כתיבה ומימוש כל הסעיפים והגדרת קובץ שבו יהיה אפשר לבחור מה יהיה enabled ומה יהיה Disabled, וכן, אני מדבר על אוטומציה ל-Windows עם דברים כמו Ansible.זו עבודה שאינה קלה שמצריכה המון snapshots הואיל וכל מימוש סעיף ובחינתו מצריך snapshot ו-rollback לאחר הבדיקה.
  • תחנות עבודה / דסקטופ – אפשר גם לעשות שם אוטומציה בנוגע להקשחה אולם עדיף לעשות Image מאסטר ולשכפל בין התחנות, תוך יצירת שינויים בהתאם לתפקיד התחנה/דסקטופ.
  • רגולציה / Conformance tests – יש הבדל ענק בין חברה לייבוא שימורים לבין חברת ביטוח או בנק שרוצים הקשחות. במקרים של הגופים הגדולים, חוץ ממחלקת אבטחת מידע צריך לערב את המחלקה שאחרית על מימוש רגולציות ו-Conformance tests (ראיתי מקרה שעבודה ענקית של הקשחה בוטלה ברגע האחרון לפני מימוש רק כי לא עירבו את המחלקה הזו. עבודה עבורי של חצי שנה נעלמה במחי מייל אחד מאותה מחלקה).
  • שילוב הקשחה של Windows ו-Linux. רעיון נחמד, לא ניתן לביצוע מכיוון שמדובר במערכות לגמרי שונות שמצריכות סקריפטים שונים לחלוטין.

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

שידור וידאו: על קידוד וצרות של רוחב פס ומחיר (חלק 2)

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

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

  • חברת HOT: הערוצים המתורגמים משודרים דרך מערכת הכבלים עם מערכת DOCSIS כאשר ישנו מרכז בקרה שמשדר את הדברים המוקלטים/מתורגמים מהמרכז דרך המערכות החוצה לגולשים. מערכת ה-DOCSIS היא מערכת מעולה לדברים האלו והחיבור הקואקסיאלי של הכבלים מאפשר שידורים ו-DATA ברוחבי פס פנומנליים. עם DOCSIS 4 לדוגמא, אפשר להגיע למהירות חיבור אינטרנט (ושידור) של 1 ג'יגהביט פר בית! (במאמר מוסגר אציין כי יש לי השגות לגבי ההגדרות שמגדירים בארץ. צפיתם פעם בכבלים ופתאום התמונה קפאה או שראיתם קוביות? על זה אני מדבר). לעומת זאת הערוצים המוזרמים ישירות מחו"ל (CNN, ערוצי ספורט זרים, ערוצי סדרות בשפות זרות וכו') נקלטים בצלחות לווין גדולות בעמק האלה ומועברים דרך כבלי תקשורת למרכז בראש העין ומשם לצופים.
  • חברת Yes: בחברת Yes הדברים מעט שונים. לכל לקוח יש צלחת לווין והלקוח קולט דרכה את כל השידורים שהחברה מנגישה ללקוחותיה. שידורים מתורגמים מועלים דרך צלחת לווין שלהם והשידור נקלט על ידי צלחות הלווין של הלקוחות.
  • עידן/עידן+ – עד לפני מס' חודשים, השידורים בעידן היו שידורים אנלוגיים באיכות SD. החל מחודש מרץ 2017 בעידן עברו סוף סוף לשידור/קליטה עם DVB-T2 שמאפשר קליטת שידורים עד Full-HD אולם למעט ערוץ 1 (שמשדר ב-HD, לא Full HD) השאר עדיין משדרים ב-SD וכפי הנראה בקרוב יעברו לשדר ב-HD או Full HD. עוד פרטים תוכלו לקרוא באתר המצוין GoDigital.

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

כשזה מגיע ל-SD, HD ו-Full HD, אפשר לאמר פחות או יותר שהתעשיה בישראל הסתדרה, אבל אז מגיעה לה בעיית ה-4K (לא נדבר על כאן על 8K שחברה כמו NHK משדרת ביפן ועוד בשידור חי!) והבעיה היא רוחב פס. ל-HOT אין ממש בעיה כי הכל נחשב כ"תשתית פנימית", אולם ל-Yes ועידן יש ויש בעיה: שידור 4K עם אודיו 5.1 דורש רוחב פס של פי כמה וכמה בהשוואה להיום, שלא לדבר על כך ש-VOD דרך האינטרנט הוא בעייתי בישראל הואיל וחיבור האינטרנט הוא א-סינכרוני כך שכל העלאה של תכנים ע"י אחד מתושבי הבית או שימוש נרחב של תושבי הבית באינטרנט (צפיה ביוטיוב, משחקים אונליין וכו') די מהר "חונקת" את חוויית הצפיה ב-4K (אתם מוזמנים לנסות זאת בחבילת ה-4K של נטפליקס), ומה קורה עם עידן/עידן+? לא יכולים עם DVB-T2 לתמוך ב-4K בכלל, עד שיצא DVB-T3 עוד שנה וחצי כמדומני.

גם בארצות אחרות כמו ארה"ב הבעיה לא פחות חמורה מאצלנו. שם כבר משדרים רוב הזמן HD (ובחלק מהמקרים FULL HD) אולם כשזה מגיע ל-4K, מאפשרים זאת דרך האינטרנט בלבד באתרים יעודיים של הרשתות או רשתות VOD מבוססות אינטרנט כמו Netflix, CBS Access או Amazon וידאו וכו'.

הבעיה המרכזית של כולם זה שהם רוצים לשדר 4K אך עם רוחב פס של SD. הם מוכנים לעשות החלפה של כל הציוד (כולל הממירים בבית, תחום שהיה להם קרב לא קטן עם ה-FCC בשנה שעברה) אבל הם לא רוצים בעיות של רוחב פס בין אם בשידור לוויני או שידור תכנים דרך האינטרנט בחיבור DSL או אחר, ולכן רובם לא עברו ל-4K ורק חלק קטן משדר ב-Full HD.

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

  • הוא עדיין לא מאפשר שידור 4K ברוחב פס של SD עם אודיו 5.1. הוא צורך פחות רוחב פס מ-H.264, אבל בשבילם (במיוחד בארה"ב) זה לא מספיק.
  • הבעיה הכי גדולה: כסף, או ליתר דיוק – תמלוגים והגוף האחראי על התמלוגים (MPEG-LA) דורש סכומים שלדעת כל הגופים שרוצים להשתמש (ומשתמשים) ב-Codec – הסכומים מאוד גבוהים.

מי שכן עשה משהו בנידון היו חברות הצפיה בוידאו ברשת כמו Netflix ואמזון, שאימצו מקודד חדש שמגיע מגוגל בשם VP9. המקודד נמצא בשימוש כשמורידים תכנים לטלפון/טאבלט ולאט לאט הם מכניסים אותו לשימוש בצפיה ישירה. יש עוד "לקוח" שמשתמש בצורה כבדה מאוד ב-VP9 יחד עם מקודד האודיו Opus. אולי שמעתם עליהם – יוטיוב. ברוב המקרים זה הפורמט שיוטיוב מגישים לגולשים למעט במקרים של דפדפן אקספלורר, ודפדפן ספארי (שתומך עד H.264). יותר מכך, בהשוואה שנערכה בין H.265 ל-VP9 מול H.264, הצליחו 2 המקודדים לתת ב-Bitrate יותר נמוך תוצאות יותר טובות מאשר ב-Bit Rate גבוה של H.264.

גם VP9 וגם Opus נכנסים תחת פורמט הקונטיינר WebM, והפורמט נתמך בדיוק באותם מקומות כמו שיוטיוב נתמך, כך שאם חושבים להקים תשתית כזו, רוב המשתמשים יוכלו לקבל וידאו ואודיו / אודיו בלבד – ברוב המכשירים כאשר ניתן להוסיף FallBack ל-H.264 (או AAC או MP3 במקרים של אודיו בלבד).

ישנו עוד מקודד אחד שכל החברות הידועות (גוגל, מיקרוסופט, מוזילה, נטפליקס, אמזון, אדובי, הולו וכמובן חברות חומרה כמו AMD, ARM, nVidia, סיסקו, ברודקום ואינטל) עובדים יחד תחת עמותת המלכ"ר Alliance for Open Media. שם המקודד: AV1. המטרה? ליצור משהו יותר טוב בהרבה מ-H.265 ללא צורך בתשלום על תמלוגים. פשוט תטמיע ותשתמש.

אבל זה לא נעצר כאן: מקודד AV1 כבר כיום (מי שרוצה לנסות את המקודד, אהלן וסהלן, נדרש ידע בלינוקס וידע עמוק בשימוש במקודדים) מוביל על HEVC והתוצאה שחברות השידור המסורתיות רוצות לראות – 50% מרוחב הפס של H.265, כלומר רבע מ-H.264 – ואז האימוץ יחל. כבר כיום טלפונים כמו גלקסי S8 ו- +S8 תומכים ב-AV1 (לא בברירת מחדל) ומכשירים סלולריים רבים יתמכו בו, חברות השידור באינטרנט כבר עושות ניסויים על AV1 וישחררו תמיכה בו ברגע שהוא יצא, דפדפנים כמו כרום, פיירפוקס ו-Edge יתמכו בו וכל מי שלא יתמוך בו יעמוד בפני אפשרות של שימוש ב-AV1 איכותי ללא תשלום תמלוגים לשידור, או תשלום מחירים גבוהים ל-MPEG-LA עם H.265. אתם יכולים לנחש את ההמשך.

אז האם כדאי לעבור ל-VP9/Opus? זה תלוי.

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

לעומת זאת, חברות שידור אינטרנט שלהם אין ציוד בחוץ בכל מיני מרכזים וממירים ללקוחות – יכולים להמיר קבצים ל-VP9, כפי שציינתי לעיל – הצצה ביוטיוב עם דפדפן כרום/פיירפוקס/Edge תראה לך מה זו איכות של VP9 – ובכך להנות בחסכון ברוחב פס (כשמקודדים ב-Bit Rate יותר נמוך אך עדיין שומר על איכות כמו H.264) ובגודל הקבצים אם אתם מאפשרים הורדת הקבצים ללקוחות (אפשר להשתמש ב-DRM כמו של Widevine כדי להגן על התוכן).

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

 

שידור וידאו: על קידוד וצרות של רוחב פס ומחיר (חלק 1)

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

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

בעבר אתרי אינטרנט רבים העבירו שידור וידאו או קליפים בקידוד WMV של מיקרוסופט או VC, או VCM בחלק הקטן מהמקרים, אולם כיום כולם (למעט אתרים שלא עודכנו שנים ועדיין חושבים שהעולם הוא עדיין ברובו משתמש במיקרוסופט) עברו לשדר בקידוד של MPEG-4 עם פרופיל Base או Main והאודיו מגיע או כ-AAC או כ-MP3. היתרונות של מקודדים (Codecs) אלו הוא בכך שכל מערכת הפעלה, טלפונים סלולריים וטאבלטים – תומכים בכך וכל מי שמשדר מעוניין להגיע לכמה שיותר קהל מבלי שהגולשים יצטרכו להתקין אפליקציות/תוספים מיוחדים, מה שגורם במקרים רבים לתקלות ולאנשים שאין להם תמיכה והם נוטשים וממשיכים הלאה.

אז כיצד בעצם אפשר לדחוס יותר משתמשים על אותו רוחב פס?

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

אבל יש פתרון אחר, שכולו קוד פתוח ונתמך בפלטפורמות כמו Wowza ואחרים (כן, גם במערכות בלוגים כמו WordPress) שנקרא Opus שמגיע מ-קרן Xiph ומהנדסים רבים בעולם עובדים בהתנדבות בזמנם הפנוי על פיתוחו. גירסה 1.2 (ו-1.2.1) שוחררה לא מזמן. אתם יכולים להיכנס לדף הזה, לגלול לאמצע ולבחור בקידוד וב-Bit Rate. אני ממליץ לבחור שם Opus 1.2 עם 32 קילוביט לשניה ולנגן ותתרשמו בעצמכם מהאיכות.

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

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

אז מה עושים? לשמחתנו ב-HTML5 יש אפשרות לקבוע Fallback כך שאם הציוד של הלקוח אינו תומך ב-Opus, הוא יועבר לגירסה ב-MP3 או AAC.

לסיכום: חסכון של 75% ברוחב הפס פר משתמש אינו רע והוא שומר על איכות דגימה של 48 קילוהרץ, ואתה לא משלם אגורה שחוקה כתמלוגים על שימוש בקידוד זה.

מה רע? 🙂

בפוסט הבא נדבר על ה"חבר" של Opus – קידוד וידאו VP9.

קונטיינרים, OpenStack ושינוי מערכות

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

אז החלטתי לכתוב פוסט שינסה לתת כמה טיפים לגבי נושאים אלו.

נתחיל ב-OpenStack: למרות שזו פלטפורמה מעולה לוירטואליזציה ומערכת ליצירת שרותי PAAS/SAAS/IAAS, כדאי לקחת בחשבון את העלויות שלה. כן, ישנה גירסה חופשית אך גירסה זו משתנה מדי כמה חודשים ואין שום בטחון שגירסה שתצא עוד חצי שנה תהא תואמת לגירסה הנוכחית ולכן מומלץ לחברות שרוצות OpenStack לרכוש את הגירסה שהפצות הלינוקס ומספר חברות אחרות מציעות (לא את הגירסה שכל מיני חברות מציעות של HP כ-Helion כי זו גירסה די מתה). המחיר אינו זול (מ-20K$ ומעלה) אולם אתם כחברה יכולים להיות שקטים שהמערכת שלכם תיתמך לשנים הקרובות (בין 3 ל-5, תלוי איזו גירסה קניתם ומתי) ותקבל עדכוני אבטחה ותיקוני באגים קריטיים.

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

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

יחד עם זאת, מעבר לקונטיינרים מחייב הבנה כי קונטיינרים אינם מכונות וירטואליות והדברים עובדים בצורה שונה לחלוטין בכל הרמות, החל מהקמה, הרצה, עדכוני קונטיינרים, כתיבה/קריאה ל-Shared storage חיצוני ועוד ועוד.

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

כך לדוגמא, אם יש לכם אפליקציית JAVA שרצה על JBoss, תצטרכו קודם לחפש לכם פתרון אחר במקום JBoss (כמו Wildfly, tomcat וכו'), להעביר את הקוד של האפליקציה ל-GIT ואז להשתמש בכלים כמו S2I או מערכות כמו Jenkins כדי להקים את ה-Images שכוללים את האפליקציית Server להרצת ה-JAVA וכשהיא תרוץ, היא תפעיל את האפליקציה שלכם שכתבתם ב-JAVA (או להשתמש ב-OpenShift שיעשה לכם את רוב העבודה 🙂 )

למרות ש-OpenStack יכול להריץ קונטיינרים, מומלץ יהיה להשתמש במערכת Scheduling כמו OpenShift, Kubernetes, Docker Swarm, Rancher ואחרות כדי להריץ את הקונטיינרים, כלומר אם משתמשים ב-OpenStack, עדיף להרים מכונות VM שישמשו כ-Nodes כדי להריץ את הדברים הללו.

כשזה מגיע ל-Storage, אינני ממליץ לזרוק את ה-Storage מהחלון, אולם כדאי לחשוב על חלוקה מעט שונה של ה-Storage לצרכים השונים. OpenStack יכול להסתדר עם iSCSI ו-NFS, אולם קונטיינרים צריכים NFS בלבד. אם אתם משתמשים ב-Object Storage על מנת לאחסן קבצים סטטיים או תמונות לדוגמא, יכול להיות שיהיה עדיף להקים "מיני סטורג'" שמורכב משרת עם דיסקים + JBOD (במקרה הצורך) הואיל ו-Object Storage אינו מצריך מהירות גבוהה.

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

גילוי נאות
שרותים אלו ניתנים ע"י חץ ביז

העתיד: דיסקים, Storage ו-NVME-OF

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

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

התשובה: במקרים של דיסקים מכניים – בהחלט. במקרים של SSD – זה יוצא ההיפך. קחו דיסק SSD בחיבור SATA ותקבלו לדוגמא מהירות קריאה של 550 מגהבייט לשניה. לזה, שום SAS לא הגיע עם דיסקים מכניים (אלא אם מכניסים את ה-Cache של הבקר אבל זה יפה במבחנים, לא לעבודה במציאות) וכך עולם הדיסקים חזר "אחורה" ל-SATA ופורמט ה-SAS די "מת" למרות מאמצים מצד יצרני בקרים ושרתים להוציא (מאוחר מדי, LSI היו הראשונים להוציא מוצרים ב-2013) את SAS-12G, וכך המצב בשנתיים האחרונות בשוק הוא שדיסקים SSD קיימים בגירסאות SATA בלבד – אבל הדיסקים עצמם מכילים את כל תכונות ה-Enterprise כמו תיקון תקלות אוטומטי, שמירת מידע עצמאית בעת הפסקת חשמל, שרידות גבוהה בעבודות כבדות ועוד.

דיסקים SSD מבוססים SATA מאפשרים לחברות להמשיך לעבוד כאילו הם עובדים עם דיסקים מכניים או דיסקים SSD ישנים, ורבים נוטים עדיין לעשות את הטעות לעבוד כ-RAID-5,50,60 כשהם שוכחים 2 דברים מאוד חשובים:

ה-RAID-5 וה"אחים" שלו 50,60 ביצעו 2 דברים חשובים: נתנו ביצועים גבוהים הנובעים מעבודה עם ריבוי דיסקים וחלוקת העבודה בין הדיסקים, ושרידות יותר גבוהה מכיוון שאם הולך דיסק אחד או 2 (בהתאם לשלב ה-RAID) – המערכת היתה ניתנת לשיקום לאחר החלפת הדיסקים. עם SSD לעומת זאת (גירסת Enterprise!) הביצועים שהדיסקים האלו מוציאים די "חונקים" כל כרטיס רשת. תחשבו על כך: 2 דיסקים SSD ב-RAID-0 מוציאים מהירות תיאורתית של 1100 מגהבייט לשניה (בקריאה). נתרגם זאת לג'יגהביט ונקבל .. 8 ג'יגהביט, כלומר כרטיס רשת של 10 ג'יגהביט יהיה תפוס ב-80% בזמן שהוא משדר את ה-DATA מצמד הדיסקים, ושוב – אני מדבר על 2 דיסקים בלבד. אז מה בעצם נותן בקר דיסקים? ביצועים? יש כבר לדיסקים, לא צריך גם Cache. שרידות? ב-SSD ל-Enterprise יש יכולות הרבה יותר מרשימות של שרידות פנימית מאשר כמעט כל בקר RAID בשוק. ובכל זאת, חברות ממשיכות לעבוד כך. מדוע? אני חושב שזה עניין של הרגל.

בשנתיים האחרונות נכנסנו לעידן חדש של דיסקים SSD, מה שבהתחלה נקרא PCI SSD והיום פשוט נקרא NVME SSD. לדיסקים הללו לא תמצאו שום RAID כי הדיסק מחובר ישירות לתושבת PCIE X4 (בחיבור שנקרא כיום U.2, חלק מהיצרנים לצערי עדיין משתמשים בחיבור קנייני משלהם, לרווחתם של יצרני הדיסקים והשרתים, לצערם של הלקוחות ש"ננעלים" בכך שלא ניתן להכניס דיסקים יותר טובים מצד ג'). הדיסקים הללו כיחידות עצמאיות נותנות יותר ביצועים מכל מה שתשיג עם SSD ו-RAID, מהירויות של 2-4 ג'יגהבייט לשניה בקריאה ועד 2 ג'יגהבייט בכתיבה עם עשרות עד מאות אלפי IOPS (וכמובן את המילה האחרונה בשרידות, ושוב – שרידות הרבה יותר גבוהה מכל דיסק מכני שאתם מכירים) ושם כבר אין RAID (ואם רוצים RAID 0,1,10 – עושים זאת בתוכנה. הביצועים לא יהיו נמוכים יותר בהשוואה לבקר יעודי, האמינו לי, גם אם תנסו את זה על מעבד i5 פשוט [ניסיתי בעצמי מול בקר יוקרתי של LSI ]).

מי שבתחום כבר בוודאי מכיר את כל מה שכתבתי, אבל מה בעצם הלאה?

אם נסתכל מבחינת דיסקים, בשנה הנוכחית השוק מנסה להסתגל למצב חדש שבו יש הרבה יותר ביקוש מהיצע. דיסקים NVME SSD של 3-4 טרהבייט, גם אם תנפנף מול היצרן בכרטיס אשראי פלטיניום, תשלום מיידי או ערימת מזומנים – תיאלץ במקרים רבים לחכות וזה כרגע עדיין "מכה" ב-HP, DELL וגם ב-Lenovo. היצרנים נתפסו "במערומיהם" עם דרישות היסטריות לשבבי Flash מצד כל יצרני המחשבים והטלפונים. כולם רוצים שבבי NAND ועכשיו. יצרני השבבים גדלים (חברת TSMC לדוגמא, אחת החברות הגדולות ליצור שבבים – מתכננת בניה של FAB נוסף בסין בדיוק בשביל זה) ושבבי ה-3D NAND החדשים מאפשרים ליצור שבבים עם כמות אחסון יותר גדלה בליטוגרפיה בשיטות יותר "ישנות" כך שניתן פר Waffer ליצור יותר שבבים. שלבים אלו ואחרים יתורגמו לשחרור לחץ בשוק במהלך השנה שנתיים הקרובות.

אבל גם אם הבעיה תיפתר, נמצא את עצמנו בבעיה אחרת: בשביל ביצועים רציניים צריך NVME SSD וגם אם יש לך דיסקים חדשים וגדולים כאלו, איך בדיוק תשתמש בהם? זה לא שיש לך בקר RAID להגדיר Virtual Disk שעל זה אתה מתקין Windows, Linux, vSphere וכו'.. אפשר כמובן להוסיף דיסק קשיח כלשהו (ולהשתמש בבקר הפנימי כדי לבנות RAID-1 מדיסקים פשוטים) כדי להתקין את מערכת ההפעלה וכו', אבל הדבר הבא שהיצרנים ידחפו נקרא NVME-OF (זהירות, לינק לקובץ PDF). זהו הסטנדרט חדש שנבנה ע"י החברות שבנו את סטנדרט NVME, ועם הסטנדרט הזה אנחנו משתמשים בכמה מושגים שבוודאי שמעתם עליהם:

  • ה-AFA (כלומר All Flash Array) – מערכת סטורג' (או שרת) שבנוי כולו מדיסקים NVME SSD.
  • על מה נעביר את הנתונים? זוכרים ROCE? אז הוא חוזר לסיבוב נוסף, ולאלו שאוהבים לשפוך כסף כאילו אין מחר (בנקים, מכוני מחקר יוקרתיים וכו') – Infiniband.
  • ובאיזו שיטה? זוכרים iSCSI? אז נגזור משם את ה-Target ו-Initiator, שיהיה לכם חיים יותר קלים.
  • אבל מה עם כתובות IP וכו'? זה ישאר, רק שהפעם זה "נעקר" מה-OS ומועבר לביצוע ע"י כרטיס הרשת (כלומר TCP Offload).

עכשיו נשלב את הכל ביחד: נבנה שרת מבוסס Dual Xeon עם 128 ג'יגה (עדיף יותר, תלוי בכמות ה-Clients וכו') מבוסס לינוקס עם קרנל 4.8.7 ומעלה, עליו נרים מערכת שתהווה בעצם Target ובה ישבו לא רק הדיסקים אלא גם מספר כרטיסי רשת עם פס רחב (25 ג'יגה ומעלה או Infiniband). הכרטיסים יחוברו למתג תואם ומשם יחוברו לשאר השרתים שאנו מעוניינים. את חלוקת ה-Volumes וכו' נעשה על ה-Linux והמערכת בלינוקס תשדר זאת דרך ה-ROCE כבלוקים (אפשר עם שילוב TCP/IP, אפשר גם בלי אבל אז יתחילו הצרחות ממחלקת ה-IT) וה-Initiator בשרתים יתחבר ל-Target (יהיו גם אפשרויות אותנטיקציה, הצפנה וכו'). שרתים ישנים יוכלו להעלות את ה-Initiator לדוגמא דרך IPXE (או PXE לחובבי טכנולוגיה קלאסית) ומשם ה-OS יעלה ויקבל תמיכה מלאה כאילו מדובר בדיסקים מקומיים.

והביצועים? אם נשווה זאת לדיסקים NVME מקומיים, ההבדל יהיה באחוזים בודדים. מכיוון שכל השיטה מעיפה כל דבר שמוסיף Latency, הביצועים נראים כאילו מדובר בדיסקים מקומיים, רק שאין צורך לבצע תחזוקת דיסקים פר שרת והכל מבוצע ממקום אחד (ומנסיון, התחזוקה לא כזו מורכבת). סתם דוגמא: גם אם שפכתם כסף והפכתם את המערכת תקשורת שלכם ל-100 ג'יגהביט, תקבלו (במספר חיבורים במקביל) קצב של 93 ג'יגהביט בקריאה, ו-40 ג'יגהביט בכתיבה. עכשיו תנסו לדמיין מערכת VDI לאלפי משתמשים ואיך זה יעבוד, וכן – יש Initiators ללינוקס, Windows ול-VMWare כבר כיום.

כמובן שחובבי מיקרוסופט לא ישארו בצד ואם הם רוצים להקים לעצמם Target מבוסס Windows Storage Server אז הם יצטרכו להמתין קצת לגירסה הבאה.

לסיכום: דיברתי כאן על דיסקים SSD, על תקשורת שגבוהה בהרבה מ-10 ג'יגהביט, על NVME-OF (ממש על קצה המזלג). הטכנולוגיה קיימת כבר כיום (חברת Mellanox  כבר דוחפת ומדגימה אותה), אבל שום חברה לא עוברת מהיום למחר לטכנולוגיה חדשה שמצריכה החלפת מתגים וכרטיסי רשת ורכישה רצינית של NVME SSD ושרתים לכך. אלו דברים שלוקחים זמן, לפעמים שנים – אבל זהו הכיוון שהשוק ל-Data Center עובר אליו. חברות סטורג' רבות ישמחו למכור לכם את הפתרון לאחסון מחר בבוקר, אבל לפחות מבחינת TCO ו-ROI (ואם החברה מוכנה לאמץ מעט ראש פתוח) אני ממליץ לחשוב על פתרון בניה עצמית. הוא הרבה יותר קל ממה שרבים נוטים לחשוב (סתם דוגמא: הוא הרבה יותר קל מאשר הקמה וניהול של שרת ZFS) והוא פתרון שיכול להיות Scale Out די בקלות וזול בהרבה אם חושבים להרחיב – מאשר פתרון קנייני.

מוגש כחומר למחשבה 🙂

על דחיית פרוייקטים והמחיר הכרוך בכך

הנה משהו שקרה לי כעצמאי לא פעם ולא פעמיים (למען האמת, הפעם האחרונה זה קרה לי השבוע): חברת XYZ, חברה גדולה וידועה, רצתה לבצע פרויקט מיגרציה משיטות העבודה הקלאסיות שהיא עובדת עם הכלים הישנים – לכלים חדשים, לעבוד ב-Agile עם CI/CD, עם GIT ועוד.

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

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

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

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

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

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

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

לכן, במידה ובוחרים כל דבר שקשור לתשתיות, פלטפורמה, או כלי עבודה שונים, בין אם הם מבוססי קוד פתוח או סגור (ההמלצה שלי תמיד היא לעבוד עם כלי שמבוסס קוד פתוח) – היא לראות האם ב-Road Map של החברה יש שדרוגים ומעבר לטכנולוגיות ומתודות עדכניות. חברה כמו VMWare לדוגמא "פספסה מעט את הרכבת" בכל הקשור לקונטיינרים ו-OpenStack, אבל גירסה 7 שתצא בהמשך תתן יכולות להרצת קונטיינרים ותמשיך לשפר את ה-VMware Integrated OpenStack שלהם. גם חברה כמו Red Hat שהבינה שקונטיינרים הולכים להיות ה"בון טון" זרקה בגירסה 3 את כל הטכנולגיה של ה-Cartridges שלהם לטובת קונטיינרים וכיום הם מפתחים לגירסה הקרובה עבודה מלאה מול שרתי Windows Server 2016 ועושה את החיים הרבה יותר קלים לשימוש בפונקציות מסויימות ע"י אימוץ kompose.io לדוגמא. לעומת זאת, חברה מסויימת מאוד גדולה וידועה (שלא אציין את שמה אך כל איש IT מכיר אותה) מציגה את עצמה כחברה עם שרותי ענן "מתקדמים" וכל מה שמקבלים כשנרשמים – הם תשתיות כאילו אנחנו נמצאים בשנת 2010 (ולסקרנים מביניכם – לא, אינני מדבר על מיקרוסופט..)

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

מחשבות על Nano Scale

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

קחו לדוגמא את עניין הוירטואליזציה ואם תקפצו ל-IBM, תראו שהחברה מימשה רעיונות וירטואליציה הרבה לפני כולם ב-Main Frame שלה. קונטיינרים? קיימים במערכות יוניקס במימושים שונים כבר עשרות שנים. עם הזמן המימושים השתפרו ולעולם ה-PC נכנסה הוירטואליזציה ע"י כל מיני חברות ובראשם VMWare ובכל מה שקשור לקונטיינרים – Sun, IBM ואחרות מימשו בצורות שונות עד שהגענו ללינוקס עם קונטיינרים כפי שהם מוכרים היום ולאחרונה גם מיקרוסופט הצטרפה לעגלת הקונטיינרים (הם נכנסו לוירטואליזציה מעט אחרי ש-ESXI-3 של VMWare יצא).

תחומים "חדשים" (שוב, הם היו ממזמן ב-Main Frame במימוש שונה בעבר) היו ה-Micro Services, ה-Serverless ומושגים שהיום חזרו להיות טרנדיים רק שהם היום הרבה יותר נוחים. קחו לדוגמא את אמזון שממשת את עניין ה-Serverless בעזרת מספר חלקים קריטיים כמו Lambda, DynamoDB ועוד. בתצורה הזו אתה לא חושב על שרתים, אתה לא חושב על קונטיינרים או על תצורת מחשוב קלאסית. המושגים שונים לגמרי.

בעולם המחשוב כיום, כשמריצים אפליקציה על VM או על קונטיינר, כמעט תמיד יווצר בזבוז משאבים. אתה מקים VM של 4 ג'יגהבייט בשעה שהאפליקציה צריכה 2.5 ג'יגהבייט.נכון, טכנולוגיית Memory Balooning פותרת בעיה זו בוירטואליזציה מקומית כמו ESXI, אבל מה קורה בענן ציבורי? שם הספק לא כל כך יכול להשתמש בטכנולוגיה כזו כי הוא לא "משחק" את המשחקים של Over Provisioning מטורף כמו ספקי הוסטינג קטנים. ב-ESXI אפשר לקבוע שמכונה תוזז למכונה פיזית אחרת אם היא פתאום צריכה הרבה יותר משאבים ממה שהיא היתה צריכה לפני זמן קצר, בענן קצת קשה לעשות זאת וכלקוח אינך יכול להעביר את ה-Instance שלך ממכונה פיזית אחת לשניה כמו ב-vSphere. הבעיה קיימת פחות (אך עדיין קיימת) עם קונטיינרים – גם שם אתה צריך להגדיר לקונטיינר כמה זכרון יהיה לאפליקציה/ות בתוך הקונטיינר אולם אם הן לא משתמשות בזכרון, אז נוצר בזבוז (שוב, עם אותם הסתייגויות כמו ל-VM).

הפתרון של Micro Servicess הוא פתרון טוב, אבל לעניות דעתי פתרון טוב יותר יהיה ברמת ה-Nano.

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

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

תארו לכם שאפליקציות שיש כיום – יהיה ניתן לפרק אותם ל-Nano Scale, כלומר פיסות קוד שצריכות קילובייטים (ולא מגהבייטים או ג'יגהבייטים) והם יכולים לתקשר עם פיסות קוד אחרות במהירות ללא צורך בבנייה של תשתית עם האמצעים הרגילים כמו Load Balancer או HAProxy או דברים כאלו. פיסות הקוד (בחלוקה לדוגמא שכל פונקציה היא "נאנו מכונה") יוכלו לבצע פעולות, לשדר את התוצאה ולמות ופיסות אחרות יכולות לקום והכל תוך מילישניות – לפי הצרכים. הדבר שכן קיים כיום בתצורה מאוד דומה היא ב-GPU (כמו של nVidia) ששם יש אלפי ליבות וכל ליבה יכולה לעשות דברים מאוד בסיסיים אך עבודה של מאות ליבות ביחד יוצרת משהו שלם שמועבר למחשב.

כיום יש לנו משהו קרוב לכך ב-Micro Services יחד עם ה-Serverless שנותן בערך את אותו רעיון, אך עדיין זהו דבר בעייתי מכמה סיבות:

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

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

השאלה – מי ירים את הכפפה.

מעבר לעננים – מבחינה כספית (מאמר עדכון)

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

בקשר לחלק השני של השאלה, התשובה הפשוטה ביותר היא לא. אם אתם משתמשים בסטורג' מסחרי, בוירטואליזציה מסחרית (VMWare, Hyper-V, Oracle VM Server) – עלויות המעבר לא רק שיהיו גבוהות, התשלום החודשי יהיה גבוה בהרבה ממה שאתם משלמים כיום. חישבו על כך: כל שרת וירטואלי עם 2 ליבות ומעלה, 8 ג'יגה זכרון ומעלה – יעלה לכם מאות דולרים בחודש ולא חשוב אצל איזה ספק ענן ציבורי תבחרו – ועוד לא דיברתי על עלות התקשורת החוצה, עלות הדיסק הקשיח הוירטואלי, עלות התקשורת בין ספק הענן למשרדכם וכמובן עלות התקשורת בין השרתים לבין הלקוחות.

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

לגבי שאר המכונות, אם רוצים להעביר לענן, הדבר הראשון עוד לפני שבכלל בוחרים ספק אינטרנט, הוא למדוד כמה משאבים האפליקציות באמת צריכות. נניח ויש לכם אפליקציית JAVA או דוט נט והגדרתם VM עם 2 ליבות ו-16 ג'יגהבייט זכרון. השתמשו בכלים הסטטיסטיים של הוירטואליזציה כדי "לחפור" בהיסטריה של אותו VM האם באמת יש שימוש ב-2 ליבות וב-16 ג'יגהבייט זכרון או שאולי מכונה זו לדוגמא יכולה להסתפק בליבה אחת ו-8 ג'יגהבייט זכרון.

דוגמא נוספת: אפליקציות כמו שרתי Web שפותחים עשרות או מאות תתי-תהליכים בהתאם לכמות החיבורים. נניח שבניתם שרת Web גדול שיקבל כמות גדולה של משתמשים כדי להפעיל אפליקציית Web שהם צריכים ויצרתם לכך 2 מכונות עם 8 ליבות וירטואליות ו-32 ג'יגהבייט זכרון בכל אחת מהמכונות. האם פתרון של 4 מכונות קטנות יותר (2 ליבות ו-8 ג'יגה זכרון) כשמאחוריהן עומד Load Balancer יהיה יעיל יותר? מבחינת עבודה בתשתית ענן, 4 מכונות קטנות עולות פחות מ-2 מכונות גדולות. באמזון לדוגמא, 4 מכונות בגודל כפי שתיארתי לעיל יעלו לכם $319 ואילו 2 מכונות גדולות כפי שתיארתי לעיל יעלו לכם $631, כלומר כמעט כפול (לא כולל דיסק, Snapshots, תעבורה וכו'). גם אם נגדיל ל-6 מכונות קטנות, עדיין המחיר יצא יותר זול מ-2 מכונות גדולות.

עוד נקודה קריטית לפני מעבר לענן היא הצורך לשנות את צורת העבודה כך שבעצם האפליקציה שתרוץ תהיה החשובה והשרת והתשתית יהיו פחות חשובים. כך לדוגמא אם יש לנו אפליקציה שצריכה לקבל כמות משתנה של משתמשים שהכמות קטנה בזמנים מסויימים ומאוד גדולה בזמנים אחרים – במקרים כאלו כדאי לחשוב על העברת האפליקציה לקונטיינרים ושימוש בתשתית קונטיינריזציה בענן (ECS באמזון, GKE בגוגל או OpenShift אם אתם רוצים להריץ משלכם משהו שיותר מתאים ל-Enterprise). בעזרת תשתית זו ניתן להוסיף אוטומטית קונטיינרים משוכפלים ומכונות נוספות (שיארחו את הקונטיינרים) וכמות הקונטיינרים והמכונות תרד אוטומטית בהתאם לכמות המשתמשים באותו זמן (כמובן שניתן להגביל את כמות המכונות שיתווספו, אם לדוגמא משהו קורה שיוצר תעבורה מזוייפת, עקב תקלות וכו'). לאלו שלא רוצים קונטיינרים או לא יכולים (קוד שרץ על Windows בלבד שלא בנוי לעבוד על קונטיינר או שהחברה לא רוצה לעבור ל-Windows Server 2016) – אפשר להקים מכונות (Instances) שישוכפלו דרך מתודת AutoScale לפי כמות המשתמשים שמתחברים או לפי כמות המשאבים שנצרכים – כך שקונטיינרים או מכונות (בהתאם לסיטואציה) הן תמיד זהות וה-Data האמיתי מגיע מבחוץ (NFS או אחסון שיתופי אחר לדוגמא).

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

ומה לגבי סטורג'? בניגוד לסטורג' שיש אצלכם בחברה, אצל ספקי ענן אין "סטורג'" באותו מובן. ישנו File או Block Storage שאתם קונים למכונות לפי גודל שאתם רוצים, לפי IOPS שאתם מבקשים (בזהירות – בחירה לא נכונה של סוג אחסון תפציץ לכם את החשבון באלפי או עשרות אלפי דולרים!). אם יש לכם אלפי קבצים סטטיים, אפשר להשתמש ב-S3 (יש כזה לא רק לאמזון, אלא גם למיקרוסופט ולגוגל) לאחסן שם את הקבצים וכמובן אפשר לשמור לשם גיבויים, (אם כי S3 אינו File Storage רגיל עם הרשאות שיש ל-NTFS/CIFS, חשוב לזכור). ככלל, בענן מומלץ יותר לבנות לקבוצות שרתים "מיני סטורג'" משותף בינם מאשר לנסות לעשות זאת על Block Storage ענקי – זה גם יצא זול בהרבה.

נקודה נוספת שמתאימה לחברות גדולות שיש בהן תשתית ענן פרטי והן רוצות לשלב חלק מהתשתית בענן ציבורי והתקציב שלהן בנוי כך שמחלקת המחשוב מחייבת מחלקות אחרות – כדאי יהיה לכלול בתקציב מערכת CMP (או Cloud Management Platform). הסיבה לכך היא פשוטה: כשמתחילים להשתמש ב-AutoScale לגדילה דינמית, יהיה קשה לחשב כמות משאבים פר שרת, הואיל וברגע אחד לאפליקציה של מחלקה מסויימת יש 2 שרתים ולאחר שעתיים יש 20 שרתים. מערכת CMP טובה (המלצתי כאן בעבר על CloudForms) תדע לא רק לחשב את הדברים אוטומטית, אלא גם ניתן יהיה לבנות דרכה את כל תהליך הבקשה, אישורים ובניית המכונה ללא צורך בלימוד שפה סגורה או כלים סגורים (שלא בטוח אם מחר זה יהיה קיים.. תראו מה קרה ל-vCloud Air לדוגמא).

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