על עסקים קטנים ומעבר לעננים. כדאי?

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

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

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

אתן דוגמא: אתם קוראים את הבלוג הזה, שהוא חלק ממספר בלוגים שעבדכם הנאמן כותב. כל הבלוגים רוצים בשרת וירטואלי עצמאי שהיה נמצא בחברת Digital Ocean ועתה הוא נמצא באמזון תחת Amazon Lightsail. האתר עצמו, וה-Database שלו ושרת ה-Web – כולם מותקנים על שרת וירטואלי יחיד שעולה לי בחודש 40$. זה מה שאני משלם בכל חודש, בין אם נכנסו 3 גולשים או 2000 גולשים ביום, מכיוון שכמות ה-DATA היוצאת מהשרת אינה עוברת את כמות ה-DATA המוקצית עבורי בחבילה. יש חבילות כמובן יקרות יותר ויש זולות יותר, בהתאם לצרכי הלקוח והחברות המציעות שרותים אלו ושאני יכול להמליץ עליהן (כולל Amazon Lightsail שהזכרתי לעיל) הן Digital Ocean ו-Linode ויש כמובן חברות נוספות בהתאם להמלצות שאתם יכולים לקבל מאחרים אולם אלו ההצעות הפופולריות ורציניות.

כמובן שגם ספקי הענן הציבורי מציעים מוצרים כמו קונטיינרים, מכונות וירטואליות וכו', אולם שם התעריפים שונים מההצעות לעיל. לדוגמא: אם באמזון ניקח מכונה ב-EC2 (לא בחבילת ה-Lightsail) כמו המכונה שיש לי, המחיר יהיה $43.63 עד לתעבורה של 100 ג'יגהבייט, אולם אם מחר אפרסם פוסט שיהפך לויראלי, אני אגיע בקלות גם לתשלום של 50-100$ לחודש. אם נבנה ב-Google Cloud את אותו מפרט של מכונה (מכונה מבוססת לינוקס, 2 ליבות, 4 ג'יגהביייט זכרון, 40 ג'יגה דיסק SSD ו-100 ג'יגהבייט תעבורה החוצה) נגיע ל-$61.22. ב-Azure אותה חבילה תעלה לנו $48.42. כך יוצא שהלקוח משלם יותר על פחות. (אגב, ב-Azure תצטרכו לשלם יותר כי הדיסק מוגדר "זמני", ודיסק מבוסס רשת עולה יותר). הערה: המחירים יכולים להיות אצל חלק מהספקים זולים יותר – אם אתם משלמים מראש שנה או שנתיים.

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

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

על עלויות תמיכה של מוצרי קוד פתוח

עולם הקוד פתוח כיום נותן מגוון מוצרים הקשורים לתשתיות שונות, Software Defined, וירטואליזציה ועוד, ובמקרים רבים חברות רבות מעוניינות באותם מוצרי פרויקטים בקוד פתוח, ומדוע לא? לבצע Download, להתקין ולעבוד עם זה, בלי עלויות של רשיונות פר שנה, פר שרת, פר חיבור ופר השד-יודע-מה…

להלן מס' דוגמאות של מוצרים:

  • GlusterFS
  • Ceph
  • oVirt
  • OpenStack
  • ManageIQ
  • Kubernetes
  • OpenShift Origin

2 המוצרים הראשונים הם Software Defined Storage, השלישי והרביעי הם מוצרי וירטואליזציה, והמוצר החמישי הוא מוצר לניהול מקיף של תשתיות וירטואליזציה ועוד – מקומית ובענן ו-2 האחרונים הם לניהול קונטיינרים לכל המוצרים הללו נלווית עלות של 0 שקלים כלומר אתה יכול להיכנס לאתרים, להוריד ולהשתמש.

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

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

לכן, בדרך כלל כשמעוניינים באחד המוצרים הנ"ל לדוגמא, יש לקחת בחשבון שאם אין בחברה ידע מעמיק על המוצר או על מערכת ההפעלה (כמו במקרים שיש רק Windows ב-90% מהתשתית ואין שם אף אחד שמבין לעומק בלינוקס) – יהיה צורך ברכישת בנק שעות תמיכה שנתי על המוצר או על הפתרון ובד"כ מדובר על כמה עשרות אלפי שקלים (בין 15K ל-40K, תלוי במוצר, תלוי אם מדובר רק בתחזוקה או בהקמה, תלוי בכמות שעות ותלוי ממי רוכשים והאם יש באמת ידע לעסק שמציע פתרון או שמדובר בעסק שחותך מחירים ולוקח מישהו מהודו כך שרוב הרווח עובר אליו ולא להודי) כך שאם אין בחברה ידע – המוצר כבר לא ממש "חינם".

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

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

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

דעה: הפרויקט בוטל/נפל/מעוכב/סטטוס-לא-ידוע

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

הסיטואציה די ידועה: טכנולוגיה חדשה נכנסה לשוק בשנה שנתיים האחרונות (זה לא משנה אם מדובר בקונטיינרים, Application Servers חדשים, Hyper Converge, SDN ושלל פתרונות חדשים אחרים) והנהלות חברות בינוניות וגדולות מעוניינות להכניס את אחת מהטכנולוגיות לחברה. הם פונים לחברת אינטגרציה שהם מכירים ומתחילים לדון בנושא ומבקשים לקבל מידע גם על פתרונות מתחרים (לפעמים ישירות מחברות משווקות או מחברות אינטגרציה אחרות), מידע כמה הפתרון יציב, עלויות רשיון, עלויות הטמעה, TCO, ROI ושלל מספרים ונתונים אחרים. לאחר זמן מה, ההנהלה ואנשים טכניים של החברה מתכנסים לחדר ישיבות והם מקבלים מנציגים חיצוניים שונים הדגמות והסברים על הפתרונות. בד"כ לאחר זמן מה החברה מחליטה ללכת על פתרון מסוים ואותה חברת אינטגרציה שנבחרת מתבקשת להקים PoC (כלומר Proof of Concept) בתשתיות הפנימיות של החברה על מנת להתרשם ו"לשחק" עם הפתרון.

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

להלן מס' דוגמאות מדוע מתרחשת הנפילה:

  • אי תאימות: לפני ה-PoC (או ה-Pilot) אף אחד לא טרח להציג מה הולך לעבור ל-Pilot ועצם ההמרה עצמה מצריכה כמות שעות גדולה כדי להמיר את האפליקציה לעבוד בסביבה החדשה. אני מכיר לדוגמא מקרה שבו חברה מסויימת רצתה להריץ אפליקציה ב-JAVA בקונטיינר. אין שום בעיה לבצע זאת, רק שהאפליקציה בכלל כתובה ב-++C והלקוח מתעקש שהאפליקציה תהיה אפליקציית JAVA, כלומר מישהו צריך לבצע porting של הקוד מ-++C ל-JAVA, וכל מי שמכיר את השפות יודע שמדובר ברוב המקרים במאות אם לא אלפי שעות עבודה שכלל לא סוכמו מבחינת מי ימיר והעלויות הנלוות. מקרה אחר שאני מכיר הוא שאפליקציה רצה בכלל תחת DOS ומה לעשות.. קונטיינרים לא מריצים DOS (זה אפשרי אבל די מורכב, במיוחד אם האפליקציה מעוניינת ליצור קשר עם .. מודם חיצוני עבור קופות רושמות בודדות. כן, שמעתי על בקשה כזו)
  • התנגדות לא רשמית מהצוותים: ההנהלה מעוניינת בפרויקט כולל מחלקת IT, אבל כשזה מגיע למפתחים ולשאר צוותים שצריכים להשתתף בפרויקט, אז פתאום זה-לא-דחוף, "אין זמן", יש דברים אחרים בראש למנהלי צוותים ובקיצור – יורדים מכל העניין, רק לא רשמית. (כן, אני מכיר 2 חברות ששילמו מקדמה ועד היום לא בוצע מאומה).
  • עוד דבר שקשור הוא הקפאה של הדברים, לעיתים עוד ברמת ה-PoC. התקבלה החלטה לצאת ל-PoC ואז התקבלה החלטה הפוכה. מדוע? אף אחד לא אומר. את זה אפשר לראות במיוחד במוסדות גדולים כמו חברות ממשלתיות. הדבר הכי לא נעים זה לחברות האינטגרציה הגדולות ששכרו אנשים חיצוניים כדי לעמוד ב-PoC ובפרויקט ועכשיו הפרויקט קפוא.

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

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

לכן, אם רוצים לבצע PoC או פיילוט, כדאי, לעניות דעתי, לוודא את הדברים הבאים:

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

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

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

כשמעוניינים בהקמת מערכת ניטור לארגון

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

בד"כ ארגונים מעוניינים בהחלפת מערכת ניטור בגלל אחת הנסיבות הבאות:

  • מחיר: יכול להיות שהמערכת הוטמעה בגלל מחיר נמוך (או אפסי) כשהתשתית ב-IT היתה די קטנה אולם עתה שצריך להוסיף כך וכך בדיקות, יש צורך לשלם כמה אלפי דולרים לרשיונות (ובמקרים רבים הרשיונות הם לתקופות ולא תשלום חד פעמי לתמיד). במקרים אחרים החברה אימצה שימוש במערכת ניטור מבוססת SAAS שצריך לשלם עליה כל חודש ועתה החליטו שעדיף להקים משהו פנימי שלא צריך לשלם הרבה.
  • אי גדילה – במקרים רבים החברה מעוניינת במערכת שלא רק יודעת לנטר דיסק/רשת/מעבד לשרתים אלא לתת הרבה יותר מידע פר ציוד ובהתאם לסוג הציוד (לדוגמא: IPMI מפורט לשרתים, גרף תעבורה עם התראות פר פורט ב-Switch וכו') והמערכת הנוכחית לא נותנת זאת.
  • החלטות הנהלה: החברה לא מעוניינת במערכת הנוכחית ורוצה משהו אחר וזו ההחלטה הסופית.

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

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

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

  • פתרון SAAS. נשמע מעולה, השאלה האם אתה מעוניין לתת לגורם כלשהו לדעת כל דבר מה שעובר אצלך במערכת? (כמות מכונות, מצב מכונות, לאן נכנס ויוצא טראפיק וכו'). הבעיה השניה עם SAAS זה שאתה לא יודע מה הם נוהלי האבטחה (אם יש, מעבר להודעת ה-PR שמופיעה באתר), מה קורה אם פורצים אל תשתית ה-SAAS של אותה חברה שמציעה את השרות, או מה קורה אם שרות ה-SAAS נופל כי התכנון היה גרוע.
    חסרון נוסף: האנשים הנוכחיים שלך אולי יכירו איך לכתוב לזה סקריפטים כדי להוסיף תמיכה בדברים, אבל ברוב המקרים לא תמצא אנשים שכירים חדשים שמכירים את הפתרונות הללו.
  • פתרון קנייני – קצת פחות חמור מ-SAAS, אולם רוב החברות דווקא מעדיפות שלא לרכוש פתרון קנייני בקוד סגור. גם כאן, עקומת הלמידה תחזור בכל פעם שיש לך מישהו חדש מכיוון שרוב האנשים לא מכירים כתיבות סקריפטים וכו' לתוכנות קנייניות.
  • פתרון קוד פתוח הוא דבר מעולה בכך שיש לך את הקוד ואתה יכול לעשות עם הדברים כרצונך. בנוסף, בתוכנות כמו Zabbix, Cacti, Icinga וכו' תוכל למצוא פורומים וגם פרילאנסרים בארץ שנותנים שרות על כלים אלו.
    יחד עם זאת – חשוב לשים לב לאותיות הקטנות. תוכנות ניטור כמו OpenNMS זמינות כקוד פתוח, אולם הגירסה הפתוחה אינה יציבה ואין לה תמיכה מסחרית והגירסה המסחרים שבקוד פתוח כן זמינה עם תמיכה, אך המחיר הוא שנתי כפי שניתן לראות בלינק לעיל.

מתוך האפשרויות לעיל, אני ממליץ ללכת על פתרון מבוסס קוד פתוח. כאן, וכאן תוכלו למצוא מספר תוכנות בקוד פתוח. תוכנה כמו Cacti טובה לגרפים, אבל פחות טובה להתראות. תוכנה כמו Zabbix טובה לגרפים והתראות ויש לה תמיכה מעולה ב-Windows. תוכנה כמו Icinga (שהיא בעצם Fork של Nagios) היא תוכנה מעולה אך מורכבת מאוד ומתאימה לאלו שנטשו את Nagios אבל רוצים עדיין משהו מוכר. לאלו שמחפשים לעומת זאת מערכת ניטור אבל שנותנת הרבה הרבה יותר מידע מאחרים ולהשקיע המון במערכת (ובתמורה תקבל אפשרויות שאילתות מאוד עמוקות עם התממשקות לכל ממשק קיים כמעט) – אז Prometheus של חברת Sound Cloud יכולה להיות הכלי בשבילכם (אם כי אני לא רואה לזה חבילה מסחרית).

יהיה הפתרון אשר יהיה, אני ממליץ לחלק את העבודה ל-3 חלקים (זאת כמובן לאחר שבחרתם תוכנת ניטור):

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

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

בהצלחה

קצת על עולם ה-NVMEoF וסטורג' חזקים

אם נסתכל היום בכל חברה בינונית וגדולה שיש לה כמה עשרות שרתים פיזיים ומעלה – בד"כ נמצא סטורג' קנייני כלשהו, בין אם זה NetApp, HPE, Dell/EMC, IBM. Hitachi ואחרים. הסיבה לכך היא די פשוטה: הפתרונות הללו נותנים ביצועים גבוהים וגם נותנים פתרונות לצרכים השונים, החל ב-LUN ש"מפורמט" ל-iSCSI (כשצריך),iSCSI, NFS, CIFS, Snapshots ועוד ועוד. הפתרונות הללו במקרים רבים היו יותר טובים מפתרונות Software defined storage בעבר בגלל מה שהיה מבחינת חומרה בתוך הסטורג' הקנייני, בין אם זה שימוש ב-NVRAM, בכרטיסי האצה, ב-SSD (שלא חושבו כחלק מכמות המקום הפנויה בסטורג', מה שנקרא גם Vault) – ובקיצור, שורת טכנולוגיות שמובנים בתוך הסטורג' שנותנים ביצועים נאותים שמתאימים לאותן חברות.

בשנים האחרונות ישנם פתרונות אחרים המבוססים על Software Defined Storage (בקיצור: SDS) המוטמעים כחלק מפתרון וירטואליזציה, פתרונות כמו VSAN של VMware, או Nutanix או Simplivity ואחרים. בפתרונות כאלו בכל שרת יש דיסקים שמשמשים לאותן מכונות VM שרצים בשרת והדיסקים גם משמשים לאחסון ושרידות של VM אחרים, כך שאם שרת פיזי נופל, ה-VM יופעל מחדש במכונה פיזית אחרת (מה שנקרא: HA) או שה-VM ממשיך לפעול מהעתק רצוף שרץ על מכונה אחרת (מה שנקרא Fault Tolerance או FT בקיצור). במקרים כמו של VSAN ניתן כמובן להגדיל את האחסון בכך שמוסיפים עוד שלישיית דיסקים (2 איטיים ואחד SSD מהיר) בכל פעם שמגדילים את האחסון, אם כי ההמלצה "בין השורות" היא שעדיף להוסיף שרת פיזי נוסף ולפזר את המכונות VM ביניהם כדי לקבל יותר IOPS. השיטה הזו טובה (וב-VMware ישראל נותנים לדוגמא את ערוץ 10 שעבר לעבוד כך), אך החסרון המשמעותי של השיטה הזו היא שזה לא תמיד עובד טוב. כך לדוגמא, אם מכונות VM צריכים SSD שהוא Mixed Intense, ה-VSAN לא תמיד ידע להעביר אותו למכונה אחרת שגם שם יש SSD שהוא Mixed Intense ובכך אנחנו עלולים לקבל ביצועים מופחתים, רק בגלל שה-DRS החליט להעביר את ה-VM בגלל עומסים (אני מכיר את זה אישית מה-LAB שלי).

כיום פתרונות ה-SDS תופסים יותר ויותר מקום של כבוד (לפחות בחו"ל), כאשר הלקוח בעצם צריך לרכוש את התוכנת SDS והוא מריץ את התוכנה על הברזלים שיש לו, כאשר אותם ברזלים הם שרתים מהיצרנים המובילים (Dell, Lenovo, HPE, SuperMicro, Cisco) ואותו הלקוח מקבל בעצם בחבילה את כל הפונקציות שהוא רגיל לקבל מיצרן סטורג' קנייני, כולל כל החיבורים שהוא צריך (FC, FCOE, Ethernet, Infiniband) ויש ל-SDS תמיכה והתממשקות לכל הפלטפורמות המובילות וגם לתוכנות גיבוי המובילות.

גם בפתרונות SDS וגם בפתרונות קנייניים, בד"כ הפתרונות מבוססים על דיסקים SSD בחיבורי SAS/SAS2/SATA או על דיסקים מכניים או שילוב שלהם (כאשר פתרון האחסון יודע להעביר נתונים שאינם נקראים תדיר לדיסקים המכניים ונתונים שנקראים/נכתבים תדיר ל-SSD, או במקרים אחרים שהמערכת מאפשרת ללקוח לבנות LUN או Share מ-SSD או מכני לפי צרכי הלקוח). אלו פתרונות טובים כאשר יש לנו עשרות שרתים עד מאות בודדות של שרתים פיזיים, כשהדרישה מבחינת ביצועי דיסק/סטורג' אינה כה גבוהה (כלומר שאפשר להסתדר עם IOPS של 5 ספרות נניח).

אבל מה קורה אם יש לנו מאות (ואולי יותר) של שרתים ואנחנו רוצים ביצועי דיסק מאוד גבוהים, בדיוק כמו ביצועים של דיסקים מקומיים? נסו לחשוב על בנקים ומוסדות פיננסיים גדולים שבשבילם כל מילישניה זה רווח או הפסד כספי? כאן נצטרך דברים הרבה יותר חזקים. יש כמובן פתרונות AFA (שזה All Flash Array) אבל הפתרונות האלו ו-Scale Out הם לצערי .. לא משהו.

בואו ננסה לדמיין משהו. דמיינו שצריך להקים פתרון מבוסס Flash בגודל 1 פטהבייט. סביר להניח שאתם מדמיינים ארון מלא בדיסקים, עם סוויצ' רציני מלמעלה (TOR או Top Of Rack).

מהדמיון נעבור למציאות, הביטו בתמונה הבאה (לחצו להגדלה):

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

בשרת ה-1U יש 36 מקומות למלבנים הללו, כך שבשרת 1U צנוע ניתן להכניס 576 טרהבייט, ובשרת 2U – כ-1152 טרהבייט, כלומר יותר מפטהבייט על שרת פיזי אחד!. הפתרון הזה שאתם רואים לעיל הוא הפתרון של סמסונג, לאינטל יש פתרון דומה (אם כי הקוביות קצת יותר מוארכות והם נקראים "סרגלים" – בתמונה משמאל ואינטל קוראת להם NGSFF). בפתרונות הללו אין שום בקרי RAID כלשהם (הכל מחובר דרך PCIe ומתגי PLX ישירות למעבד, כך שהביצועים מאוד גבוהים, בסביבות ה-3-4 ג'יגהבייט קריאה וכמעט 2 ג'יגהבייט כתיבה לשניה פר מקל).

וכאן אנחנו מתחילים להכיר את פתרון עם השם המפוצץ NVMEoF (ר"ת של NVME over Fiber, אם כי לא מדובר על Fiber Channel רגיל).

בוא נחשוב על חיבורים לשרת כזה. חיבור של 1 ג'יגהביט לא בא בחשבון וחיבור 10 ג'יגהביט "יחנק" עוד בפעילות של מקל יחיד! אנחנו צריכים פעילות של מס' מקלות NVME כדי לתת ביצועים סופר חזקים וסופר מהירים כדי שהמכונות שיחוברו לשרת כזה ירגישו כאילו הדיסק שהם מקבלים – הוא ממש מקומי, כלומר אנחנו צריכים חיבורים של 25,50,56 או 100 ג'יגהביט, כלומר או Ethernet או Infiniband.

מבחינת תעבורה מהירה, אנחנו צריכים לוותר על TCP/IP במהלך העברה של הנתונים (אך לא בזמן ה-Handshake הראשוני, בשביל זה עדיין אנחנו צריכים IPv4 או IPv6 ב-TCP/IP) ואז אנחנו עוברים לשימוש בטכנולוגיה שרבים מאיתנו מכירים… RDMA, זוכרים? היתרון הגדול עם RDMA הוא שהמעבד באותו שרת "מקור" לא צריך כמעט לעשות כלום, ומכיוון שאנחנו מעבירים בעצם "בלוקים", אז אנחנו מוותרים בדרך גם על שכבת ה-File System. מישהו שהסברתי לו על הנושא אמר לי "אה, זה בעצם מעין iSCSI על סטרואידים".. אפשר לאמר 🙂

ל-NVMEoF יש מספר יתרונות גדולים:

  • אפשר להכניס איזה גדלים שרוצים וכמה שרוצים. אפשר להתחיל ב-2 מלבנים של 8 טרה ואחר כך להוסיף עוד 4 של 16 ואחר כך עוד 4 של 8 טרהבייט. למערכת זה לא ישנה כלום. מבחינתה – יש עוד מקום לאחסן.
  • אין צורך לבנות מערכי RAID (כי .. אין RAID). במערכת שתרוץ על השרת נוכל לקבוע איך הנתונים ישמרו, מה הדחיסה שתהיה והיכן ישמר עותק נוסף של הנתונים.
  • ההשקעה למוסדות גדולים אינה כה גבוהה (לא ניכנס לחישובי ה-ROI, אפשר לכתוב ספר שלם על זה!). כן, יהיה צורך בהחלפת מתגים וכרטיסים בשרתים, והמוסדות יצטרכו להחליט עם מה הם עובדים – Infiniband או Ethernet (כבלי CAT 7 עם תיוג Class F יכולים להעביר 100 ג'יגה עד 15 מטר אורך, CAT 8 יתן עד 100 מטר 100 ג'יגהביט אך הוא עדיין לא אושר רשמית. כאן יש עוד פרטים לגבי 100 ג'יגה)
  • ישנן תוכנות שונות שנותנות את שרות ה-NVMEoF, חלקן כחול לבן כמו Kaminario, E8, Pure וכו'. כמו שכתבתי לעיל, אני ממליץ לרכוש תוכנה ולא פתרון חומרתי סגור מכיוון שעם תוכנה אפשר לעבור לפתרונות מתקדמים יותר בעתיד תוך שימור ההשקעה בברזלים, לא צריך לרכוש פתרון חומרתי סגור אחר ולהיפתר מהקודם.
  • מבחינת תמיכת חומרה – גם כאן, החבר'ה מיוקנעם ישמחו לסייע לכם (Mellanox), סמסונג, אינטל, Chelsio, Qlogic ואחרים, וכל יצרני המתגים המוכרים כבר תומכים בפתרונות NVMEoF.
  • מה עם פתרונות קוד פתוח? גירסת RHEL 8 שתצא (כנראה, כנראה..) עד סוף השנה תתן פתרון NVMEoF עד סוף השנה, וכל מערכות ההפעלה והוירטואליזציה יתמכו בפתרון.
  • כל הפתרונות (שאני מכיר) תומכים ב-Scale Out.

לסיכום: NVMEoF הוא בהחלט פתרון מעולה לעתיד. לפני שבועיים הרצתי אותו בבית (כפתרון וירטואלי, אין לי ממש כספים לדיסקים NVME ל-Enterprise) על Fedora 27. ובהחלט ה-Latency נמוך מאוד והביצועים מרשימים. אני תיארתי את הפתרון לעסקים גדולים כמו בנקים וכו' אולם כל חברה בינונית ומעלה יכולה להתחיל ב-PoC על מנת לבדוק בהמשך מימוש פרודקשן של פתרון כזה. לא צריך השקעה של מאות אלפי שקלים – מספיק 2-4 דיסקים NVME, כמה כרטיסי רשת במהירות של 25 ג'יגה ומעלה (ללא סוויצ') ושרת שיכול לקבל דיסקים כאלו, מערכת לינוקס עדכנית ואפשר לנסות ולשחק עם זה.
אפשר לאמר שאנחנו "חוזרים לאחור" הן מבחינת שיטת העברת הנתונים (RDMA) והן מבחינת מקום אחסון הנתונים (מחוץ לשרתי הוירטואליזציה/קונטיינרים) ובכך יש מעין "מלחמה" בין השיטות, רק שהפעם השיטה ה"ישנה" קיבלה זריקת חיזוק רצינית בכך ש-NVMEoF נותנת לנו ביצועים הרבה יותר גבוהים מבחינת דיסק בהשוואה לכל פתרון Hyper Converge.

למעוניינים, להלן וידאו של רד-האט יחד עם סמסונג ומלאנוקס שמסביר יותר על הדברים:

תכירו: Windows Server 2019

(לתוהים מה קרה שהחלטתי לכתוב על Windows – אמנם "חץ ביז" אינו נותן תמיכה רשמית ל-WIndows [בגלל שהשוק מוצף והמחיר נמוך], אבל הם מוציאים טכנולוגיות ואינני "אנטי מיקרוסופט")

מיקרוסופט הכריזה רשמית היום על גירסת Preview ל-Windows Server 2019. הגירסה זמינה להורדה (המפתחות כבר בתוך ה-ISO או VHDX) אבל כדאי לשים לב: זוהי גירסת CLI, תצטרכו להתקין כלים כדי להיכנס עם ממשק גרפי.

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

  • Cluster Set: כפי הנראה גם מיקרוסופט מבינה ש-Hyper Converge זה העתיד ומעתה ניתן להגדיל קלאסטרים וליצור Cluster ל-Compute, ל-Storage (הכוונה ל-Cluster של Storage Spaces Direct, כן, גם במיקרוסופט מבינים ש- Software Define Storage יותר עדיף מברזלים קנייניים), ומכונות ה-VM שלכם יכולים "לשוט" להם בתוך ה-Cluster Set לפי ביצועים או שרידות שתגדירו. נחמד.
  • Windows Defender מקבל חיזוק משמעותי בדמות ATP (כלומר Advanced Thread Protection) עם ערימת חיישנים וירטואליים לניטור זכרון, פסיקות (Interrupts) וכו'. אני ממליץ להיכנס ללינק שפרסמתי לעיל לקרוא את הדברים (ויש לא מעט). קצת מזכיר מעולם הסולאריס את DTrace רק שזה לשם הגנת המערכת.
  • מערכת WSL – מיקרוסופט מעתה משלבת את Windows System for Linux בתוך Windows Server 2019 כך שתוכלו להריץ את הפצת הלינוקס החביבה עליכם בתוך שרת Windows 2019. בנוסף מיקרוסופט מחזירה לחיים חלק ממה שהיה בעבר SFU (כלומר Services for Unix) עם SSH, TAR, CURL כך שיהיה אפשר לשלב את הדברים בתוך סקריפטים שלכם.
  • קונטיינרים – כן, מיקרוסופט עושה מאמצים כדי לשלב קונטיינרים ברמה הרבה יותר "טבעית", כך לדוגמא כל IMAGE לא ישקול 5 ג'יגהבייט והוא יקבל "דיאטה" ל-2 ג'יגה (הלו מיקרוסופט, בלינוקס זה בד"כ בין 100-200 מגה בשכבה הראשונה, דרושה עוד דיאטה), כך שתוכלו להריץ גם קונטיינרים של לינוקס ישירות בשרת Windows Server 2019. אוסיף כאן הערה אישית: כרגע ה-WSL נותן ביצועים מחרידים בכל הקשור ל-I/O של קבצים גם ב-2016 וגם ב-Windows 10, כך שבשלב זה הייתי ממליץ לאלו שרוצים להריץ קונטיינרים מבוססי לינוקס – תריצו את זה על מכונת לינוקס.
  • עוד על קונטיינרים – מיקרוסופט "מיישרת קו" עם השוק והיא תשלב את Kubernetes בתוך ה-Windows Server 2019 (כך שאם הלכתם על משהו שאינו תואם ל-Kubernetes – מומלץ לחשוב על "אחורה פנה")
  • פרויקט "הונולולו" – הממשק הגרפי החדש של מיקרוסופט ל-2019 שנותן לכם לא רק לנהל את השרת החדש, אלא גם להתממשק ל-Azure וליצור Hybrid Cloud.

עתה, הרשו לי לשתף אתכם במחשבותיי לגבי המערכת החדשה.

הקמתי את המערכת הזו ושיחקתי איתה פה אצלי ב-LAB הביתי שלי ואני חייב לציין שהתחושה שלי ש-Windows 2019 החדש יותר מזכיר משהו כמו WIndows Server 2016.1. יש שיפורים – אך הם אינם כאלו גדולים. מיקרוסופט כמובן תתנגד למה שציינתי ולראייה המחיר – Windows Server 2019 יהיה יותר יקר (במובן של CAL) מ-WIndows Server 2016 והסיבה לכך פשוטה: מיקרוסופט רוצים שפחות תתקינו את זה על הברזלים אצלכם ויותר תשתמשו בשרותי ה-Azure שלכם.

וכאן בגירסה זו של Windows Server, שרותי ה-Azure מודבקים על ימין ועל שמאל. רוצה DR? עם אז'ור. קלאסטרים, מיגרציה וכו'? עם Azure. זו כמובן זכותה של מיקרוסופט אבל זה די מאכזב לראות שמיקרוסופט שוב נוקטת בשיטות הישנות של כריכת שרות בשרות. אולי כדאי להזכיר למחלקה המשפטית של מיקרוסופט את השם "נילי קרוס"? (מי שהיתה נציבת ההגבלים העסקיים באיחוד האירופאי וקנסה את מיקרוסופט במיליארדי דולרים!). מן הראוי היה שמיקרוסופט תפתח איזה API לאפשר לשאר יצרני העננים הציבוריים (גוגל, אמזון) להתממשק ולאפשר לתחרות לעבוד.

לסיכום: Windows Server 2019 הוא בהחלט מוצר שמראה שמיקרוסופט דוחפת בכל הכח גם לעבודה של Multi Platform (לינוקס, Windows, קונטיינרים "טבעיים" וכו'), את עניין ה-Hyper Converge ואני מאמין שגם תהיה התממשקות מאוד הדוקה ל-Azure Stack לטובת חברות שמעוניינות להריץ את הכל פנימית על הברזלים המקומיים (עקב מגבלות חוקיות ורגולטריות). אלו בהחלט דברים מעולים, אך לעניות דעתי חוסר הפתיחות כלפי ספקי עננים מתחרים קצת פוגם בדברים.
גירסת ה-ISO זמינה במסגרת תוכנית Windows Insider וה-ISO יפעל עד חודש יולי. למנויים ל-LTSC תהיה גירסה של Windows Server 2019 בעוד מס' שבועות.

על מעבר לעננים, אירוח אתרים ועוד כמה דברים

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

נתחיל בתחום האירוח אתרים. עד היום חברות שונות בארץ ששוכרות מקומית מכונות וירטואליות/שרתים לשם אירוח האתרים מהסיבה הפשוטה של Latency ו-SEO (לנקודת ה-SEO לדעתי אין שום אחיזה בכל מה שנוגע ל-Latency ואני יכול להעיד שיש לי כמה מילות מפתח במקום ראשון בגוגל והשרת הוירטואלי שלי נמצא בכלל ב-Amazon Lightsail בוירג'יניה!). עד היום היה ניתן לארח את האתר שלכם בחו"ל ולהשתמש בשרות CDN כמו של Incapsula שלהם יש שרתי EDGE פה בישראל. החל מעתה, גם למתחרה הגדול שלהם (Cloudflare) יש נקודת EDGE פה בישראל כך שאפשר בהחלט להשיג Latency מאוד נמוך גם מבלי לשכור מכונות בארץ ובכך ניתן לחסוך בעלויות השכרה.

מכאן נעבור לעננים ציבוריים ולחברות בינוניות עד גדולות (במובן האמריקאי/אירופאי, פחות במובן הישראלי). בשנים האחרונות, עם כניסת העננים הציבוריים יותר ויותר לקידמת הבמה, חברות בסדר הגודל שהזכרתי לעיל "השתעשעו" (במובן של PoC, העברת מספר מכונות לענן ציבורי כלשהו לצרכי טסטים ו"טבילת אצבעות" וכו'). חברות רבות קיבלו קרדיטים מספקי הענן הציבורי (בסכומים הנעים מעשרות עד מאות אלפי דולרים). חברות רבות השתמשו באותם קרדיטים כדי להעביר תשתיות כלשהן לענן ובאותו זמן לפי כל החברות המודדות מכירות שרתים, מתגים, סטורג' וכו' (חברות כמו IDC, מורגן סטנלי, גרטנר ואחרים) הוציאו דוחות שכמות הציודים ל-DC/שרתים שנמכרת מאותם יצרנים הולכת וקטנה והטרנד הזה נמשך כבר יותר מ-5 שנים, אולם לקראת סוף 2016 האחוזים עלו במעט ואילו ב-2017 האחוזים עלו בצורה יפה (7% בהשוואה ל-2016) לפי הדו"ח של חברת Canalys שהופיע ב-The Register כאשר Cisco מכרה יותר מאשר Dell/EMC (ו-Dell/EMC מכרה יותר מ-HPE). דו"ח של חברת Morgan Stanley ציין פחות או יותר את אותם דברים בחודש שעבר.

אבל (וזה "אבל" גדול) – יש כאן גם טוויסט…

חברת ששמעו, התעניינו או הקימו PoC (או אולי עברו) לפתרונות HC (כלומר Hyperconverge) ראו שפתאום הם לא חייבים לרכוש את הסטורג'ים היקרים (מאוד) או סוויצ'ים סופר יקרים שעושים המון דברים. פתרונות Hyperconverge כמו ה-VSAN של VMWare, או Nutanix או SimpliVity או OpenStack (או RHV של רד-האט) נותנים גם ביצועים יפה וגם שרידות מרשימה – והכל רץ על שרתים סטנדרטיים כשהכל בעצם רץ כ-(Software defined (storage/network. ולפי 2 הדוחות, חברות מגלות יותר ויותר עניין בפתרונות כאלו מאשר הפתרונות הקאלסיים של ברזלים קניינים ויעודיים.

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

על קונטיינרים וחומרה

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

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

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

  • אפשר להקים הרבה פחות מכונות VM כדי לתת את אותו שרות.
  • קונטיינרים צריכים 30-70% פחות משאבים בהשוואה להרצת אותה אפליקציה שרצה ב-VM
  • מבחינת Scalability – קונטיינרים עושים את העבודה בצורה יותר טובה בהשוואה ל-Scaling של מכונות VM, והגדילה הרבה הרבה יותר מהירה בהתאם לעומסים.

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

אם נסתכל על חברות ענקיות כמו פייסבוק וגוגל, נראה שבהתחלה השרתים שלהם היו שרתים מאוד צנועים, והם פשוט הכניסו המון שרתים על מנת לבצע Scale Out עם מעבדי Xeon. לאחרונה, אותן חברות החלו לעבור לארכיטקטורות מתחרות, בגוגל לדוגמא עברו למעבדי Power של IBM ומעבדי ARM חדשים ו-Facebook גם מכניסים מעבדי ARM. זה לא ללקוחות שלהם, זה בשביל להריץ את הקונטיינרים שלהם.

לכל אחד מהארכיקטורות האחרות יש יתרונות על פני מעבדי ה-Xeon (גם החדשים) של אינטל:

  • למעבדי ARM יש את היתרון הגדול של כמות ליבות גדולה וצריכת חשמל נמוכה, מצב אידיאלי כאשר כל קונטיינר אינו צריך עוצמת מעבד רצינית ולפיכך ניתן להריץ יותר קונטיינרים פר מכונה פיזית מבלי לצרוך כמות חשמל כה גדולה. כך לדוגמא מערכת Apollo 10 של HPE תוכל בקרוב לקבל מעבדי ARM בגירסה יעודית. חברת Qualcomm לדוגמא יצרה מעבד שנקרא Centriq ויצרני שרתים מובילים שמחים לאמץ ולמכור שרתים עם פתרון זה.
  • למעבדי Power יש הרבה יותר כח מכל מעבד Xeon שיש לאינטל. אלו המעבדים שמפעילים את ה-MainFrame למיניהם ו-IBM מוכרת לדוגמא שורת מכונות שמריצות לינוקס בצורה טבעית עם אחריות ושרות מלאים (עם Red Hat 7.4) וכל מכונה יכולה להריץ הרבה יותר קונטיינרים בהשוואה למכונה מבוססת Xeon (תלוי כמובן במפרט).
    יתרון נוסף של מעבדי Power9 של IBM – זה שניתן להריץ קונטיינרים באופן טבעי ישירות על ה-Main Frame, ולקבל לא רק ביצועים טובים, אלא את השרידות הכי גבוהה שיש (זו המערכת היחידה שאתה יכול להוסיף זכרון, מעבדים כשהמערכת רצה).

נשאלת כמובן השאלה: מה עם תאימות בינארית? התשובה לכך היא די פשוטה: המערכת הפעלה שתרוץ בקונטיינרים כבר קיימת לקונטיינרים. מה שנשאר הוא לקמפל ספריות וקוד פנימי של החברה ובכך בעצם ליצור קבצים בינאריים לפלטפורמה שנבחרה וכך נוכל לבנות Images שהם אופטימליים (ללא שום המרות או אמולציות) לפלפורמה שנבחרה. לדוגמא – אם האפליקציות שהחברה כותבת הם ב-JAVA ורצים על Tomcat, אז ה-JDK קיים באתר של IBM ויש קונטיינר מוכן עם Tomcat ל-Power9. אותו הדבר קיים גם ל-ARM.

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

קצת על קורסים ללינוקס

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

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

בלינוקס – זה שונה. ישנה חלוקה די ברורה של הפצות לינוקס: רד-האט ו-CentOS תמצאו בחברות, אובונטו יותר בסטארטאפים, SuSE מתחילה להיכנס יותר לארץ ו-Debian בד"כ אצל הוותיקים (כמו תמיד, מלחמות הפצה קיימות מכאן עד הודעה חדשה, אבל זה נושא לפוסט אחר). כך לדוגמא יכול להיות שתוכנה מסויימת בגירסה X קיימת כחבילות מוכנות להתקנה על אובונטו אך אותן חבילות לא ירוצו על הפצת לינוקס אחרת (ולמתחכמים: כן, קיים כלי בשם alien שממיר חבילות, אבל לא תמיד זה עובד וזה ממש לא משהו קל לשימוש למישהו שרק התחיל אתמול ללמוד לינוקס). פקודות התקנת חבילות הן שונות, בלא מעט מקרים גם קבצי ההגדרות לתוכנות פופולריות כמו Apache או NGINX נמצאות במיקומים שונים ובחלק קטן מהמקרים – גם ההגדרות עצמן שונות ואפילו התקנת הלינוקס שונה: כשמתקינים לדוגמא רד-האט או CentOS עם הגדרות ברירת המחדל, המערכת תפרמט את הדיסק לווליומים שונים כך שאם תרצה להוסיף מחר דיסק קשיח, תצטרך פשוט להגדיל את הווליום ולגמור עניין בשעה שחלק אחר מההפצות כלל לא טורח לעשות זאת וכשצריך להוסיף דיסק – צריך להעביר קבצים, ליצור קישור בין תיקיות ולבצע שלל פעולות אחרות.

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

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

ישנם קורסים online שניתן לרכוש ב-20-40$ של UDEMY ואחרים (והח"מ קנה מספר קורסים כאלו), רק שהבעיה איתם שאתה בעצם "מהמר" על הקורס. לפעמים קשה להבין מילולית את המדריך (במיוחד שהמדריך מהודו ותלוי כמה הוא עבד על המבטא האנגלי שלו), לפעמים ההסבר אינו מספק ואי אפשר ליצור קשר עם המדריך כדי שיסביר בקצרה על מה מדובר, ולפעמים ההסבר כלל לא מכוון כלפי רמת לימוד שהלומד נמצא בה. אני יכול לדוגמא להסביר במשך שעתיים על Linux Schedulers וההבדלים ביניהם אבל אם המאזין לא יודע מה זה processes, ההסבר הולך לפח.

עד לפני כמה חודשים היה לי קשה להמליץ על אתר מסוים ללימוד כי הרבה מאוד אתרים מכרו לימוד על לינוקס בצורה די "חפיפניקית". זכור לי מקרה בו רציתי קצת יותר להעמיק את הידע על MySQL ולקחתי קורס ב-lynda.com על הנושא וכל הקורס דיבר רק על CRUD (כלומר create, read, update, delete), שום דבר על אינדקסים, join, left,right, מנועי database וכו' או קורס Python שלקחתי מאתר אחר ורק לאחר התשלום הבנתי שהמדריך כלל לא מתכוון להתעכב על ההבדלים בין Python 2.7 ו-Python 3 ומעלה, דבר די בעייתי שאתה מנסה להבין קוד שמישהו אחר כתב ממזמן …

כיום אני ממליץ בחום על Linux Academy (ולמעוניינים הנה קוד referral – ה-7 ימים הראשונים בחינם והשאר בתשלום חודשי של 29.50$). ההבדל בינו לבין אתרים אחרים הוא שבכל מה שקשור ללינוקס, יש שם הדרכות רבות לא רק על לינוקס אלא גם על כלים לעבוד איתם בלינוקס, אוטומציה, שפות תכנות, MySQL, וכמובן – עבודה בעננים ציבוריים שונים. יש להם 4 יתרונות גדולים על פני אתרים אחרים:

  • מכירים את זה שאתם משלמים ושוכחים להיכנס וללמוד? כבר בהתחלת כל קורס תקבלו אפשרות לקבוע לכם לוח זמנים ללימוד (ימים ושעות) והמערכת תשלח לכם התראות לפני כן על מנת לתזכר אתכם להיכנס ולהמשיך ללמוד..
  • לא הבנתם משהו? לכל קורס יש פורום, יש flash cards שאחרים כתבו כך שתוכלו ללמוד ולהיזכר בסיוע אחרים בדיוק באותם דברים שאתם מתקשים.
  • אין לכם סביבת לינוקס או שאתם לומדים על דברים הקשורים לעננים ואין לכם תקציב חופשי לחשבון ענן? אל דאגה: אתם מקבלים עד 6 שרתים ללא תשלום נוסף לנסות את הדברים שאתם לומדים בקורס. תתקינו Putty ואתם מסודרים.
  • כשתיכנסו לאתר תוכלו לראות מצד שמאל למעלה ציורית של ענן כתום – זהו החלק של Cloud Assesment, זהו החלק שיכול לבדוק אם אתם מוכנים לבחינה בנושאי ענן שונים כמו Solution Architect וכו'. יש גם את האייקון השלישי משמאל שנקרא Scale Your Code והוא יותר מורכב מהרצאות של אחרים על דברים שהם עשו.

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

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

הבאג הקריטי במעבדי אינטל – עדכונים

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

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

בפעם שעברה דיברתי על הנחתה בביצועים בין 5 ל-30%, וכאן יש לעדכן: זה תלוי במעבדים בשרתים. מעבדים עד 5 שנים אחורה. מעבדים כמו Xeon E3/E5/E7 V3 ומעלה יש בתוכם פונקציונאליות שעוזרת למגר את הנחתת הביצועים כך שלא תהיה הנחתה משמעותית בביצועים, אולי אחוזים בודדים.

במעבדים היותר ישנים (שרתים כמו DELL דור 11 ומטה, HPE דור 7 ומטה, לנובו/IBM דור M3 ומטה) עדיין יורגשו הנחתות בביצועים במקרים מסויימים. המקרה הכי נפוץ שמצאתי הוא שכשמריצים שרתים כאלו כ-Hypervisor (כמו Hyper-V או ESXi) ומריצים את המכונות דרך Datastore שעובד על דיסקים מקומיים. מכיוון שלשרתים אלו אין אפשרות להיות משודרגים למעבדים מדור 3 ו-4 (טוב, למעט SuperMicro ששם אתה יכול להחליף לוח אם, בנוסף למעבדים, ובנוסף גם זכרון..) – האפשרויות שישנם הינן:

  • להקים מכונת VM שמחוברת לבקר דיסקים ולהריץ עליה מערכת שרות קבצים NFS/iSCSI.
  • להקים פתרון כמו שתיארתי לעיל אבל בתצורה פיזית.
  • לקנות פתרון סטורג' כלשהו.

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

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

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

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

לסיכום: מכיוון שרוב החברות הגדולות כבר לא מחזיקות בשרתים ישנים – אז הבעיה אינה כל כך חמורה בכל הקשור ל-Meltdown. בנוגע ל-Spectre בגירסה הראשונה, העדכון לא מוריד ביצועים (והתיקונים לגירסה השניה יעשו הן ע"י יצרניות מערכות הפעלה והן ע"י יצרניות אפליקציות). עדיין נשארו בעיות בכל הקשור ל-Spectre על טלפונים מבוססי אנדרואיד ועדכונים יצאו ע"י יצרני הטלפונים (ואם יש לכם מכשירים ישנים, אולי כדאי להחליף להם ROM למשהו כמו LineageOS). מבחינת ספקי ענן – כולם משתמשים בציוד די חדיש וכולם מעדכנים את כל השרתים שלהם, יכול להיות שתקבלו הודעה מנומסת מהן לעשות Reboot ל-Instances שלכם. מבחינת מחשבי Desktop, לאפטופים – ההנחתה בביצועים כמעט ולא קיימת. מה שהכי חשוב – יש לעדכן את כל השרתים ולבצע לאחר מכן Reboot לאותם שרתים.