תקלות בפלאפון ומה כולם יכולים ללמוד מכך

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

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

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

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

וכאן מגיעה הבעיה שנמצאת אצל חברות רבות (שוב, לא מדבר ספציפית על פלאפון או על כל חברה אחרת): אין תכנון מספק ל-Roll Back. אני בערך 26 שנה בתחום, והיו לי מאות מקרים שבהם שדרוגים שברו מערכות פרודקשן, גם כשב-LAB הכל עבד פרפקט. מה לעשות, דברים כאלו מתרחשים גם כשעושים את כל המאמצים למנוע את התקלות.

בעבר הרחוק, אמצעי העזר שעמדו לרשותך היו קבצי TAR (בלינוקס, יוניקס) שהכנת לפני השדרוג (אם כמובן גיבית את הכל והתוכנה לא זורקת איזה קובץ so באיזה חור נידח והוא לא כלול בקובץ TAR) או גיבוי לקלטת. עם מערכות Solaris היה אפשר להשתמש ב-Veritas Volume Manager כדי ליצור Snapshot, בלינוקס בזמנו היה LVM אבל לא היה Snapshot וב-Windows (לפני שנות ה-2000) המצב לא היה טוב יותר.

עכשיו ב-2018 דברים השתנו. הרוב רץ על VM כיום אז אין בעיה ליצור Snapshot לכל המכונות המושפעות משדרוג ואם יש תקלה, אפשר לחזור אחורה. כל DB מאפשר לעשות dump שבמקרה הצורך ניתן לשחזרו, ובכל מערכת DR ניתן לעשות את הסינכרון הדו כיווני המתמשך כשעושים עבודת שדרוג.

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

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

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

התחרות בין AMD לאינטל על ריבוי ליבות

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

נתחיל מאינטל: היא הציגה את המעבד I7-8086K במלאת 40 שנה למעבד הנוסטלגי 8086 שהתחיל את כל מהפכת ה-PC. המעבד הזה הוא בעצם ה-I7-8700K רק שבתוכו יש פיסת סיליקון מובחרת שיכולה להיות מואצת למהירות 5 ג'יגהרץ (בחלק מהליבות, לא כולם) ואינטל דורשת עליו מחיר יותר גבוה מה-8700K.

אבל את עיקר הכותרות קיבלה אינטל מהצגת מעבד עתידי כלשהו שיכיל לא פחות מ-28 ליבות ושהודגם רץ במהירות 5 ג'יגהרץ. כל מי שקצת מבין בכמות ליבות פר מעבד ובמהירות שעון וראה את ההכרזה – חכך את ראשו כי המספרים לא ממש מסתדרים, ורק אחרי ההדגמה התגלה ה"טריק" של אינטל: הם לקחו בעצם מעבד מאוד יקר ממשפחת השרתים (השמועות מדברות על Xeon SP Platinum 8180 שעולה 10000$), ביטלו לו את נעילת ההאצה, והדגימו אותו על לוח אם סופר-מפלצתי והקירור היה קירור מאסיבי – Chiller שדורש 1000W בקירור מים. כל הטרראם הזה הוא אינו פתרון שאינטל יכולה למכור (זה לא פתרון שאתה יכול לרכוש הביתה או לחדר שרתים בחברה אלא אם יש לך מערכת הזנת חשמל מאוד גבוהה) וסביר להניח שאינטל גם לא תמכור מעבד כזה במהירות הזו (תזכרו – בשביל פתרון כזה צריך ספקי כח מיוחדים, לוח אם מיוחד וחתיכת פתרון קירור חיצוני). מדוע אינטל לא ציינו בהדגמה שמדובר ב-Overclock? כי הם "שכחו".

מדוע בעצם אינטל נכנסים לתחרות הזו? כי AMD המתחרים יכריזו למחרת על מעבדי Threadripper עם 32 ליבות (ולאינטל יש מחלקת ריגול שלמה כך שהם יודעים על הדברים מראש) אז הם יצאו בהכרזה מוקדמת על מעבד חדש. האם כדאי להתחיל להתלהב ואולי בהמשך לרכוש מעבד כזה? אני בספק. סביר להניח שכשאינטל תמכור מעבד כזה, המחיר שלו יהיה לא פחות מ-4000$, ועדיף לחברות שרוצות דבר כזה ורק מעבדים של אינטל – לרכוש מכונה עם 2 מעבדים עם 14 ליבות (כמו ה-i9-7940X או מה שאינטל תוציא בחודשים הקרובים), שם המחיר יהיה הרבה זול וצריכת החשמל תהיה נמוכה בהרבה. אינטל גם הכריזה לאחר הכנס כי יהיה גם מעבד עם 22 ליבות לצרכנים (שוב, כמו ה-Xeon SP Gold 6152).

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

נעבור מכך, אם כן – ל-AMD.

בכנס של AMD הכריזו על מספר מוצרים עתידיים (בלי יותר מדי פרטים) ועל מעבדי ה-Threadripper החדשים שיקבלו את ארכיטקטורת +Zen שתשפר ביצועים בכל הקשור לתקשורת פנימית בין הליבות ותקשורת עם הזכרון, וכאן AMD הכריזה על 2 מעבדים חדשים במשפחת ה-Threadripper: מעבד אחד עם 24 ליבות ומעבד שני עם 32 ליבות. AMD שמחו להציג את תוכנת Blender עם השוואה מול המעבד ה-i9-7980XE של אינטל שמכיל 18 ליבות וכמובן שהמעבד עם 24 ליבות של AMD ניצח. באותו הזדמנות AMD הציגו שוב את Blender עם 32 ליבות אולם הפעם ההשוואה היתה ללא תצוגה מהצד של אינטל.

הבעיה ב-2 המעבדים החדשים פשוטה וקשורה למשפחת ה-Threadripper שהוא בעצם גירסה קצוצה של מעבדי EPYC לשרתים של AMD. במעבדי EPYC, תצורת הזכרון היא 8 ערוצים (כלומר אם נניח אתם רוצים שיהיה בשרת 128 ג'יגהבייט זכרון, עליכם למלא את כל 8 התושבות במקלות של 16 ג'יגהבייט ולא 4 מקלות של 32 ג'יגהבייט כדי לקבל ביצועים אופטימליים). ב-Threadripper תצורת הזכרון היא כמחצית מכך (4 ערוצים) כי Threadripper במקור היה עד 16 ליבות והיה צורך על כל רביעיית ליבות למלא זכרון ב-4 תושבות. עם המעבדים החדשים לעומת זאת, תצורת הזכרון נשארת אותו דבר כך שמעבד עם 32 ליבות, כך שמחצית מהליבות לא מקבלים גישה ישירה לזכרון, מה שפוגע בביצועים. נוסיף את הנקודה ש-AMD מדגישה תאימות לאחור (כך שאם יש לך מערכת עם Threadripper ואתה רוצה לשדרג למעבד עם 32 ג'יגהבייט זכרון, כל מה שתצטרך לעשות הוא פשוט לשדרג BIOS/UEFI ולהחליף לאחר מכן מעבד, רק אל תנסו לעשות Overclocking, לשם כך תצטרכו לוח חדש יותר עם אותם חלקים אך עם ערכת VRM משופרת, המעבדים החדשים צריכים יותר מתח).

יוצא מכך שההכרזות של AMD על מעבדי Threadripper החדשים (שיצאו באוגוסט) הם לא משהו שכל כך שווה להתלהב ממנו. כן, סביר להניח ש-AMD ימכרו מעבדי Threadripper עם 32 ליבות ו-64 ניבים במחיר של פחות מ-2000$ (מעבד לשרתים EPYC 7551P עם 32 ליבות עולה כיום 2300$) ומי שרוצה מעבדי AMD עם 32 ליבות ומקסימום ביצועים למעבד, עדיף שירכוש את EPYC (כותב שורות אלו מתכנן להחליף מספר שרתים בפתרונות מבוססי EPYC, הביצועים בוירטואליזציה מעולים בהשוואה למחיר פר מעבד ובצריכת החשמל שלהם).

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

ה-LAB הבא: פרק 11 – החום

אתחיל בתמונה: מה שאתם רואים משמאל לקוח מתוך vSphere (מתוך ה-VCSA) ומציג בעצם את העומס על 2 שרתים שנמצאים כאשכול אצלי (הם ב-DRS כך שהעומס מחולק וב-2 המכונות מצב המעבד נראה כך). כמו שאתם יכולים לראות, העומס על המעבדים הוא קטן מאוד.

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

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

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

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

בתכנון השרתים.

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

בשרתים לעומת זאת, אפשר לראות את התכנון הלקוי שאפיין שרתי 1U בעשור האחרון. קשה להאשים את היצרנים – בסופו של דבר, רעש זה הפרמטר האחרון שהם התחשבו בו, ולכן הם החליטו שהפתרון הכי טוב לשרתים הם צלעות על המעבדים, ו-6-7 מאווררים קטנים אך חזקים בחזית השרת (אחרי הכוננים וה-Backplane), כך ששרתי 1U של היצרנים המוכרים מרעישים בברירת המחדל כשחם בחדר, גם כשהמעבדים לא עושים כמעט כלום. אגב, בשרתים מהדור האחרון היצרנים (לפחות HPE) "נזכרו" בחלק מהדגמים להשתמש בפתרונות כמו צינורות נחושת להעברת האויר ובכך השרתים יותר שקטים, רק שרוב האנשים לא ממש חושבים לרכוש שרתים מהדור האחרון ל-LAB הביתה..

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

אז מה? לא לקנות שרתים 1U? אם אתה לא יכול לסגור אותם בחדר ממוזג או לשים אותם במקום שיש בו מיזוג שפועל רצוף (במיוחד בימים כאלו שהחום ביום יכול להגיע ל-36 מעלות ומעלה) – אז יהיה עדיף לוותר על הפיתוי ולחשוב על פתרון אחר.

אם לעומת זאת, אתה רוצה לבנות שרת 1U אז תוכל להשתמש במס' טריקים שיוכלו לעזור לך "להשתיק" את השרת גם ללא צורך במזגן:

  • בחר במעבד נכון. אם לא מדובר בשרת וירטואליזציה אלא שרת קבצים או מדיה, אפשר לקנות לוחות שמשובץ בתוכם מעבד (שלא ניתן להחלפה) או לחלופין קנה מעבד שמעטפת צריכת החשמל שלו נמוכה (AMD לדוגמא הוציאו את ה-Ryzen 5 2400GE שמעטפת צריכת החשמל שלו היא 35 וואט ועדיין יש לו מעבד גרפי מכובד לדברים פשוטים ויש לו 4 ליבות).
  • השתמש בפתרון איוורור אקטיבי הכולל מאוורר. לחברת Dynatron לדוגמא יש מאוורר ל-1U וכל עוד המעבד לא מתאמץ אתה לא ממש תשמע אותו (כך שזה לא ל-HTPC עם מעבד חלש וישן). לעומת זאת לאותו מעבד AMD שציינתי לעיל הוא בהחלט יכול להתאים הואיל וכמות החום שהוא יוציא היא קטנה.
  • את המאווררים בקופסת 1U מומלץ לזרוק לפח ולרכוש מאווררי 40 מ"מ של חברת Noctua. אלו מאווררים שתוכננו מלכתחילה להיות שקטים מאוד והם כוללים גם 2 ערכות חוטים כדי להשתיק את המאווררים עוד יותר, והם כוללים גם גומיות בצדדים להשתקת ויברציות. בקיצור – אלו מאווררים מעולים.

בשרתי 2U יש יותר מקום וניתן לבצע כל מיני Hacks כדי להשתיק אותם ועל כך – בפרק הבא.

ה-LAB הבא פרק 10: חסימת פרסומות למכשירים בבית

קוראי בלוג זה הותיקים בוודאי יודעים על דעתי על פרסומות באתרים (אין לי בעיה עם פרסומות, כל עוד הם לא קופצים לך על הפרצוף ומפעילים מוסיקה בווליום בגלל שהעברת את העכבר בטעות ליידם ובוודאי לא פרסומות שגורמות למחשב לעבוד בצורה איטית!), ולכן החלטתי הפעם להדגים התקנה של אובונטו LTS עם PiHole, תוכנה בקוד חופשי שהופכת את המכונה שהיא רצה עליה לשרת DNS פנימי בבית/LAB כך שכל המשתמשים בבית שמשתמשים ברשת הפנימית/WIFI יוכלו לגלוש ללא פרסומות (כמעט).במילים אחרות, Pi Hole הוא מעין "פרוקסי" למכשירים/מחשבים בבית  שלך שמונע את הפרסומות מבלי שתצטרך להגדיר כל מכשיר/מחשב עם כל מיני חוסמי פרסומות.

לשם כך יש צורך ב-VM אבל למי שאין LAB או מערכת וירטואליזציה בבית, גם פתרון של Raspberry Pi-3 יעודי (ב-69$ כולל כל מה שצריך) יכול להיות פתרון מצוין לכך.

בעקרון מה ש-PiHole עושה הוא בעצם משמש כשרת DNS פנימי ויש צורך להגדיר בנתב הביתי את כתובת ה-DNS לשרות ה-DHCP אל ה-Pi Hole עצמו כך שכל בקשת DNS תעבור דרך האפליקציה ואם האתר מבקש גישה לשרת פרסומות, שרת הפרסומות חסום, וכך מקבלים גלישה טובה נטולת פרסומות (טוב, ברוב המקרים, לא כולם, במיוחד באתרים ישראליים ובפייסבוק). אם יש לכם שרת DNS פנימי כחלק מה-LAB, תוכלו להגדיר את ה-Pi Hole שיפנה אל שרת ה-DNS הפנימי הנוכחי שלכם ואם אתם רוצים שרת DHCP במקום שרות ה-DHCP של הנתב שלכם, אפשר לבטל שרות זה בנתב ולהפעיל זאת ב-Pi Hole.

בוידאו כאן תוכלו לראות הדגמה של הקמת שרת אובונטו LTS, הקמה והגדרות של Pi Hole.

ה-LAB הבא פרק 9: הרפתקאות עם שרתי HP דור 7

השבוע רכשתי (במחיר טוב! כמה? מוזמנים לקרוא את הפוסט שלי בנושא בבלוג העסקי) 3 שרתי HP DL360 G7. אלו שרתים די בסיסיים (בכל זאת, Xeon מלפני 8 שנים!) אבל קיבלתי אותם עם המון זכרון (208 ג'יגה!) ורציתי להקים עליהם VMWare vSphere 6.5 האחרון.

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

הדבר הראשון שהיתה בעיה – מערכת ה-iLO (זו מערכת הגישה מרחוק, ה-KVM המובנה פנימית) היתה לא מעודכנת (גירסה 1.15) וכתוצאה מכך לא היה ניתן כלל להיכנס לשרת מרחוק דרך דפדפן. לאחר בדיקות בגוגל התברר כי קודם כל יש לשדרג את הקושחה לגירסה 1.28 ורק לאחר מכן לשדרג לגירסת הקושחה האחרונה (נכון להרגע: 1.89). מכיוון שזו מערכת ישנה, אם אתם רוצים לראות את המסך מרחוק, תצטרכו .. להתקין JAVA ו"להילחם" בכרום שיתן לכם להוריד את קובץ ה-jnlp כדי שתוכלו להפעיל אותו. אם לעומת זאת אתם עם Firefox, מזלכם האיר לכם, יש תוסף יעודי "טבעי" של iLO ל-Firefox. בכל מקרה אין גירסת HTML5 לממשק ה-KVM לצפיה במסך. זה קיים רק ב-iLO 5 ומעלה ואי אפשר לשדרג iLO בשרת.

אחרי שסידרנו את עניין הגישה מרחוק, הדבר המומלץ הבא הוא לעדכן קושחות של השרתים. עדיין אין לנו מערכת הפעלה מותקנת ולכן מומלץ לעשות זאת עם קובץ ISO של יצרן השרת. כאן מגיעה הפתעה די מאכזבת: ל-HP אין שום בעיה שתורידו דרייברים ללא תשלום או רישום, אבל כשזה מגיע ל-ISO הזה הם רוצים שתשלמו על הארכת אחריות בכדי לקבל גישה לקובץ (שנקרא SPP – שזה Service Platform for Priliant וזו גירסה עצמונית של SUM – מערכת העדכון של HP). מכיוון שאין סיכוי שאני אשלם על שרת ישן "חידוש אחריות", פניתי ל"חבר האינטרנטי" (גוגל). נחסוך לכם את החיפוש, כאן אתם יכולים להוריד את ה-ISO מחודש יולי (מצאתי מקום אחר שנותן להוריד עדכון מהחודש, אבל אין שום הבדלים בין קבצי ה-ISO בכל מה שקשור לשרתים G7).

אז איך נפעיל את ה-ISO? שנתחיל לחפש USB Disk on key? לא צריך, אפשר דרך iLO.. כלומר אפשרי, אבל רק אחרי שתרכוש רשיון של iLO Advanced (אם אין לכם בשרת, לי לא היה באחד מהשרתים). כמה עולה? הו, טוב ששאלתם:

לשנה זה עולה $221 ול-3 שנים $339 וזה כמובן לא מזכה אתכם בשום תמיכה (התמיכה היחידה שתקבלו זה איפה להכניס את המספר ועדכונים.. שהם רק ל-iLO). טוב, גם הפעם אני לא ממש מעוניין לשלם על הרשיון אז שוב – גוגל שנותן לך לינק ל-Reddit כאן עם 2 רשיונות. תכניס, תפעיל (לא, זה לא מתחבר לאינטרנט לבדוק אם הרשיון "כשר").

אחרי שהפעלנו את הרשיון, ניתן להפעיל את ה-Remote Console, וניתן למפות קובץ ISO מהמכונה המקומית שלכם ולהפעיל את ה-SPP. כמות העדכונים שהיו היא .. אחת. עדכון לקושחת כרטיסי Qlogic. אם ציפיתם שהוא יעדכן את ה-iLO באותה הזדמנות – טעיתם. זה לא כולל עדכון של iLO. מדוע? ל-HP הפתרונים…

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

ל-HP יש IMAGE מוכן שתוכלו להריץ אותו דרך ה-iLO (אני ממליץ להכניס USB Disk on Key או כרטיס SD לשרת ועליו להתקין את ה-ESXi במקום דיסקים קשיחים). אתם מוזמנים להוריד אותו ולהתקין, הכל ילך חלק עד ש… תנסו להעמיס על השרת ותוך 6 דקות על השעון תיראו במסך ה-KVM מוצף בצבע סגול עם הודעות שגיאה ורגיסטרים. זה נראה כך:

לא, החומרה שלכם לא דפוקה, זה הדרייבר SMX של HP שהותאם לעבוד עם שרתים דור 9 ו-10, אבל בדרך הם שברו תאימות לשרתים דור 7 ו-8. מה עושים? משנסים מותניים, מתקינים VMWare PowerCLI ועוקבים אחר ההוראות כאן איך ליצור ISO חדש הכולל דרייברים מגירסה vSphere 6.0. אחרי שהכננו את ה-ISO, מפעילים דרך ה-iLO ומתקינים על ה-USB Disk on Key או על כרטיס ה-SD. מנסיון – זה עובד מעולה. עכשיו אפשר להתחיל לעבוד …

… בערך.

אם כל ה-Datastore שלכם מאוחסן באיזה סטורג' או NAS – אין בעיה שתתחילו לעבוד עם המערכת. לעומת זאת, אם אתם חושבים להכניס דיסקים SATA – תתבעסו לגלות שמהירות ה-SATA היא 3 ג'יגהביט (במקום 6 ג'יגהביט של SATA 3), כך שאו שתיקחו דיסקים SAS או שתחליפו לבקר אחר (ותשיגו כבל מיני SAS 8087 לחבר בין ה-Backplane לבין הכרטיס). חושבים להכניס SSD? קנו בקר אחר. איזה? כזה. מבחינת הרחבת זכרון, אתם יכולים להכניס עד 192 ג'יגהבייט אם זה זכרון 8500R (במהירות 1066 מגהרץ) או 288 ג'יגהבייט אם זה זכרון 10600R (במהירות 1333 מגהרץ).

ולבסוף רשמים: איך הרעש? כרגע מופעלים 2 מכונות כשבכל אחד מהם מעבדי X5650. אני כרגע מריץ סה"כ 10 מכונות VM (יהיו עוד הרבה) והם בחדר ממול, הרעש שהם עושים הוא פחות ממכונת ה-i5 שמתפקדת אצלי בתור NAS, כך שהם בהחלט שקטים.

לגבי חשמל .. היו רגעים שהגעתי לתצרוכת של 240-260 וואט, כרגע זה נראה כך:

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

לסיכום: האם הייתי ממליץ על רכישת שרתי DL360/DL380 G7? אני חושב שכן (כל עוד אין לך בעיה לעבור את המסכת שתיארתי לעיל אך מצד שני, בכל שרת תצטרך לעשות זאת פחות או יותר. בכל הקשור ל-iLO, פה זה עניין של מפתח מספרים, בשרתים אחרים מדובר במפתח חומרה כך שכן תצטרך לרכוש כזה, אם כי ב-eBay תוכל למצוא זאת בכמה דולרים).

ה-LAB הבא פרק 8: רשת 10 ג'יגהביט?

כשאנחנו בונים LAB לבית שלנו, אחת הנקודות החשובות היא חיבוריות בין אמצעי האחסון (NAS ברוב המקרים) לבין השרתים שלנו. אחרי הכל, לא חשוב איזו מערכת הפעלה השרתים יריצו, צריך לחבר אותם ל-NAS כדי להעביר נתונים, להתקין מכונות VM או קונטיינרים, להעביר נתונים וכו'. יש לנו בעצם 2 "רשתות" – הרשת האחת היא בין השרתים ל-NAS, והשניה היא בין השרתים (והשלישית זה תקשורת כניסה/יציאה לאינטרנט). בד"כ אנחנו נשתמש במתג (Switch) כלשהו כדי לחבר את הכל כך שכל מכונה תקבל כבל תקשורת אחד במהירות 1 ג'יגהביט או שנחבר מספר חיבורים פיזיים ב-Teaming כדי לקבל מהירות יותר גבוהה מ-1 ג'יגהביט.

נשאלת השאלה: האם אנחנו צריכים מהירות יותר גבוהה מ-1 ג'יגהביט? הבה נראה:

נתחיל ב-NAS שלנו (לא חשוב איזו מערכת הפעלה או איזה File System יש על ה-NAS). סביר להניח שהוא יכלול לפחות 4 דיסקים ומעלה. בואו נסתכל לדוגמא על דיסקים Red Pro של Western Digital (המתחרים נותנים את אותם נתונים). לחצו על התמונה להגדלה:

כפי שאתם יכולים לראות, דיסק קשיח שמעביר כמות נתונים גדולה ברציפות, מעביר אותם במהירות החל מ-164 מגהבייט לשניה ועד 240 מגהבייט לשניה במקרה של דיסק 10 טרהבייט. סביר להניח שנשתמש ב-RAID כלשהו (או RAIDZ ב-ZFS) כך שאם נעביר קובץ שמתחיל אפילו בג'יגהבייט אחד, מהר מאוד נגלה שצוואר הבקבוק שלנו הוא חיבור הרשת. אם תסתכלו אצלכם בעבודה, החיבור בין ה-SAN לשרתים כלל אינו מבוצע על כבל רשת נחושת אלא על סיב אופטי במהירות 8 ג'יגהביט ומעלה (או בחיבור SFF-8088 או SFF-8640, תלוי בסטורג'). מכיוון שלרובינו לא יהיה SAN בבית נצטרך בעצם למצוא דרך לבצע חיבור מהיר בין ה-NAS לבין השרתים. יש כמובן את שיטת ה-Teaming לחבר מס' כבלי נחושת Ethernet ביחד ליצור רוחב פס של 4 ג'יגהביט, אבל ישנו פתרון יותר טוב ומה שחשוב – יותר אמין.

לשם כך נצטרך 3 כרטיסי רשת 10 ג'יגהביט +SFP כאשר 2 מהם עם כניסה יחידה וכרטיס אחד עם כניסה כפולה. כאן לדוגמא אפשר לקנות 2 כרטיסים וזה יעלה בסביבות ה-240 שקלים (יכול להיות פחות), וכאן יש לנו כרטיס עם כניסה כפולה במחיר של 208 שקל (כדאי לדבר עם המוכר, הוא ישראלי). כדי לחבר בין הכרטיסים, מומלץ להשתמש בכבל DAC (כלומר Direct Attach Cable) בין ה-NAS לשרתים, נצטרך לפחות 2 כבלים (אם יש לך 2 שרתים) או יותר (אם יש לך יותר). כאן אפשר לרכוש חבילה של 10 כבלים (באורך 2 מטר) מסוג TwinAx Copper במחיר של 660 שקל + משלוח. אם לעומת זאת אתה רוצה לרכוש בבודדים, אתה יכול להציץ כאן ולרכוש ב-20$ כבל באורך 3 מטר. לאחר רכישה והתקנה, כל מה שנשאר לעשות זה להגדיר חיבוריות 10 ג'יגה, הגדרת Jumbo Frames ולהגדיר ב-DNS כתובת IP שונה כדי שקבלת/שליחת קבצים במכונות תהיה דרך ה-10 ג'יגהביט ולא דרך ה-1 ג'יגהביט.

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

על "חטיפת" עובדים על ידי המתחרים

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

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

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

גוגל, מיקרוסופט, אמזון, פייסבוק, ועוד חברות רבות אחרות עושות בדיוק את אותו דבר. הם "מטרגטים" עובדים מסויימים שהם בודקים מכל מיני מקורות שיש להם ידע מסויים ואז הם יוצרים קשר ומציעים הצעות מפתות. אתה מקבל משכורת של 30K בחודש? הנה 40K או 50K בחודש (לדוגמא), ואגב – עובדים רגילים שפונים לאמזון וכו' דווקא במקרים רבים לא מקבלים הצעות כה מפוצצות. רק ה"נוצצים" שבהם מקבלים הצעות מפתות. לא מאמינים? פנו לאמזון ולאחר הראיון בקשו הצעת שכר והשוו למה שקיבלתם – בשביל הספורט 🙂

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

אתחיל מהצד של העובדים: כפרילאנסר שעושה עבודות אצל לקוחות, במקרים רבים יש זמנים "מתים" במהלך העבודה שהשרתים עושים דברים מסוימים ונוצר "זמן מת" של 10-20 דקות ויוצא שבזמנים אלו נוצר סמול-טוק ביני לבין עובדי החברה, ונוצרת מעין שיחה שבמקרים רבים מובילה לכך שהעובד סקרן לגבי דברים כמו פרילאנס וגם עבדכם הנאמן מתעניין במה שהעובד עושה, ואולי זה יפליא מעסיקים רבים – אבל עובדים רבים לא בדיוק מרוצים ממקום עבודתם, חלקם לא מרוצה מהיחס אליהם, לחלקם לא מקשיבים מבחינת רעיונות והצעות, חלקם ממורמרים במקום עבודתם ולולא המינוס והמיסים והחובות והצורך לפרנס משפחה – הם מזמן היו אורזים דברים ומחפשים מקומות אחרים, ולאחרונה גם שמעתי חששות ממפתחים שונים מכך שחברות רוצות לייבא עובדים מחו"ל במשכורת זולה יותר והחשש מובן – אם אותו עובד מקבל 25-30K משכורת ברוטו והעובד ההודי ידרוש 10-15K, מדוע שימשיכו להעסיק אותו?

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

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

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

  • להקשיב: כפי שציינתי לעיל – בהרבה מקרים יש ניתוק בין ההנהלה לעובדים. החוכמה אינה מצויה תמיד אצל ההנהלה ולפעמים עובד או עובדים יכולים לגרום לחברה לחשוב פעמיים מלעשות צעד מסוים שרק בעתיד יתברר כצעד שגוי. פגישות אישיות ודלת פתוחה לעובדים (ללא צורך לתאם עם המנהל/האחראי שממונה על העובד) תוך דגש של "ישיבה בלתי רשמית" שבה ניתן לאמר הכל – יכולה לסייע לקבל פידבק אמיתי.
  • נתינת מענקים נקודתיים: עובד מסוים שכנע את ההנהלה לא לעשות צעד והרעיון התברר כמוצלח? כתבו לו צ'ק מענק. צוות מסוים הצליח לבצע דברים עוד לפני הזמן שנקבע? תנו לצוות מענק, תראו להם שאכפת לכם מהם והמאמץ שהם משקיעים.
  • "דיאטת ריצה לפיטורין": הנה משהו שחוזר בחברות רבות. הרבעון האחרון לא הכניס מספיק או שהחברה לא עמדה ביעדים שנמסרו למשקיעים? מיד רצים "להתייעל" ומקצצים נמרצות במצבת העובדים. אם ניקח לדוגמא צוות של 10 מפתחים שעובדים עד 7-8 בערב ונפטר 4-5 מהם, תקבלו 0% התייעלות ודברים שלא יסתיימו בזמן ולא ניתן להתחמק מכך. רוצים לקצץ? התאמצו לחפש דרכים אחרות לקצץ. עובד שחושש למקום עבודתו הוא עובד שיקפוץ בהזדמנות הראשונה לכל הצעה אחרת, גם אם ההצעה נותנת בדיוק את אותה משכורת ותנאים, ואם חושבים לקצץ בשכר – שההנהלה תתן דוגמא בסקטור הניהולי בקיצוץ שכר.
  • השקיעו בעובדים: הזמינו הרצאות והדרכות על נושאים טכנולוגיים וטכנולוגיות, בצעו רישום כחברה ללימודי Online ותנו לעובדים ללמוד דברים חדשים, גם אם אתם לא מכניסים אותם מחר בבוקר לתשתיות שלכם. תנו לעובד הרגשה שאשכרה משקיעים בו (ולא, ה"השקעה" של HR היא בדיחה עצובה), שלא הולכים לפטר מהיום למחר ושיש לו דלת פתוחה לשטוח את טענותיו. אם אתם מבינים שעובד בצרה פיננסית ואתם יכולים – הציעו לעובד הלוואה או מפרעה (מומלץ גם לפרסם הצעות כאלו בתוך החברה). הוא לא ישכח לכם את זה.
  • העלאות שכר: אין לי מספיק שערות בראש (ואני לא מקריח) מהסיפורים ששמעתי מכל מיני שכירים על ההעלות השכר העלובות שקיבלו. אולי כדאי לחשוב על העלאות טיפה יותר גדולות?

בסופו של יום, עובדים הם לא רובוטים. עבודה בשכר גבוה זה דבר טוב אך זהו אינו התנאי היחידי. גם אם עובד יקבל 50-60K משכורת בחודש והוא מרגיש ממורמר בעבודה, יכול להיות שהוא יסכים לעבור לחברה יותר "משפחתית" תמורת משכורת נמוכה יותר ועובד שמקבל את ה-25-30K בחודש וכיף לו בעבודה – אולי יסרב לעבור למתחרה שמציע 40K.

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

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

ה-LAB הבא פרק 6: כדאי לארח בחוות שרתים?

הפוסטים בסידרת ה-LAB הבא מקבלים כמות צופים נכבדה ובחלק מהמקרים יש תגובות מחוץ לבלוג. 2 תגובות מסוג שונה היו טלפונים שקיבלתי מ-2 חברות אינטרנט גדולות בארץ לארח שרתים. "בשביל מה לך הרעש והפסקות חשמל? בוא תארח אצלנו" הציעו הנציגים..

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

בשביל לענות על השאלה הזו, צריך לדעת מה אתה בעצם עושה עם השרתים והעלות של החשמל. נצא מתוך הנחה שאירוח 1U בחוות שרתים ידועה עולה 400 ש"ח + מעמ בערך.

נניח ויש לך שרת אחד, נניח שאתה מריץ עליו ESXI + VCSA/VCENTER, השאר מכונות VM שלך. הדבר הכי חשוב לדעת: אלו מעבדים וכמה אתה מאמץ את המעבדים – את זה תוכל לדעת מתוך הגרפים של ה-vCenter שלך. אם אתה משתמש במעבדים דגם L של Xeon – אז צריכת החשמל שלך תהיה בערך כמו של PC במאמץ דרגה בינונית (כלומר 40-50% CPU עמוס), כלומר סביר להניח שחשבון החשמל שלך יהיה בערך 100-150 שקל תוספת. מעבדים דגם E ודגם X צורכים פי 2 חשמל (כמעט) ולכן חשבון החשמל שלך, סביר להניח שבמאמץ דרג בינונית – ההפרש עם השרת יגיע בסביבות ה-300-400 שקל, ואז אם יש לך רק שרת אחד, עדיף אולי לאכסן אותן בחוות שרתים.

לעומת זאת, כאשר יש לך יותר שרתים, אפשר לפזר את העומס על השרתים השונים ואז צריכת החשמל שלך תהיה פחותה. להלן דוגמא של אחד מהשרתים שרכשתי כשרצים עליו (כרגע) 10 מכונות VM והוא עם מעבדים L5640 עם 64 ג'יגה זכרון. הגרף הוא של השבוע האחרון (לחצו להגדלה):

כרגע 2 השרתים שרכשתי מראים את אותה צריכת חשמל, כך ש-2 השרתים שלי ביחד צורכים סה"כ כ-200 וואט (הגרף מייצג שרת אחד וזה הקו הכחול, הקו הכתום הוא הגבול העליון שהספק יכול לתת). לא בדיוק מרקיע שחקים מבחינת חשבון חשמל :). סביר להניח שהצריכה תהיה הרבה יותר גבוהה אם אכניס מעבדים מסידרת E או X, אבל אני מעדיף לקחת מעבדים יותר איטיים עם יותר שרתים מאשר מספר שרתים יותר קטן עם מעבדים יותר חזקים – כשה-Idle שלהם עוקף בקלילות את ה-100 וואט. (רוב המכונות שלי "רעבות" לזכרון, פחות למשאבי CPU), כך שטכנית אם אמשיך בצריכה הנוכחית, בחשבון דו חודשי יתווסף לי לתשלום 160 שקלים ומכיוון שצריכת החשמל של המכונות נמוכה, ולא יוצא הרבה חום, אני לא צריך להפעיל מזגן.

אז אם אתה קונה 4 שרתים עם מעבדי X או מעבדי E5-2670 ומעלה (סה"כ 8 מעבדים) – אז יכול להיות שצריכת החשמל שלך תהיה גבוהה. מחיר קילוואט שעה בארץ הוא 55.29 אגורות, חלק לפי הצריכה הממוצעת (כלומר אם אתה צורך נניח 200 וואט לשעה, אז התשלום יהיה 11.058 אגורות לשעה), תכפיל ב-720 שעות לחודש, תכפיל ב-2 – וזו תהיה תוספת המחיר שתצטרך לשלם (אם צריך מזגן או סטורג', סוויצ' (שבין כה לא לוקח הרבה חשמל), תחשב ותוסיף) – ואז תוכל לדעת אם שווה לאחסן בחווה או לא. כלל הזהב הוא: נסה חודשיים בבית, תראה את החשבון שמגיע, תראה את החישוב שלך ואז תחליט.

היכן זה ממש לא משתלם? אם כל מכונה שלך היא בגודל 2U, אז תצטרך לשלם 700-800 שקל לחודש, ובשום מקרה שום שרת למגיע לצריכת חשמל של 1400-1600 שקל (בהשוואה לחשבון חשמל שהוא דו חודשי).

לסיכום: הרעיון לאחסן בחווה שרתים של LAB ביתי נשמע רעיון מפתה: אין צורך בארון שרתים, אין רעש, אין צורך במזגן בשביל זה. אבל כשחושבים מראש על דברים כמו מעבדים עם צריכת חשמל נמוכה וארון זול (מומלץ עם דלת זכוכית ולא דלת מחוררת שמוציאה את כל הרעש ועם 2 מאווררים מלמעלה) – אז רעיון האירוח מתאדה לו כשחושבים על המחיר שתצטרכו לשלם. במקרים רבים תרצו לבנות לעצמכם אולי שרת שקט (נניח שרת סטורג') ואז תצטרכו מארז 3U או 4U – ואירוח מכונה זו בלבד תעלה לכם 1050-1200 שקל לחודש, ואצלכם בבית – כמעט כלום. לכן מומלץ להרים את הדברים בבית, להריץ למשך חודשיים ולראות כמה חשמל צרכתם (ברוב מערכות ה-IPMI כמו iDRAC, IMM, ILO ניתן לראות זאת) ואז להחליט.

ה-LAB הבא: על צריכת חשמל

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

בואו ניקח מחשב דסקטופ רגיל. אנחנו נמצא בו מעבד של AMD או אינטל עם צריכת חשמל של עד 65 או 90 וואט (ללא Overclocking) זה ה-TDP שהוא ממוצע. מעבד כמו אינטל i7-6700K בעומס יצרוך 116 וואט. בחלק מהמקרים שיש שם גם כרטיס גרפי יעודי למשחקים וכו', צריכת החשמל שלו תהיה בין 100-300 וואט (ה-300 במקרים של VEGA מ-AMD, במקרים של nVidia זה בד"כ מגיע גג בצריכה מקסימלית ל-250 וואט). שאר הציודים במחשב לא ממש צורכים הרבה. מאוורר (גם בפעילות מלאה) צורך 0.6 וואט ודיסק קשיח צורך בין 5-9 וואט.

כלומר ספק כח של 300-500 וואט יכול בהחלט להספיק ל-PC רגיל. (שוב, בלי Overclocking)

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

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

כל העניין של חיבור תלת פאזי הוא מהסיבה שאנחנו רואים את זה בחוות שרתים. ארון 42U עם 20 שרתי 2U, או 40 שרתי 1U (או הרבה פחות אם השרת הוא עם U יותר גבוה) אז כן – צריכת החשמל עולה ועולה ואז באמת צריך חיבור תלת פאזי.

אבל בבית, מה בדיוק נקים? 2-4 שרתים? ברוב המקרים זה יהיה 2-3), זה יהיה כמו להפעיל 5 מחשבי PC בתצורת Desktop. נוסיף לכך את העניין שמדובר ב-LAB וברוב המקרים מה שנריץ לא יתפוס באופן קבוע את המעבדים בצריכת 100% אלא יותר לכיוון ה-20-40% כך שצריכת החשמל עצמה לא תהיה גבוהה.

בלוח החשמל שלנו יש לנו מתג ראשי שמקבל כמות מסויימת של אמפר (בחלק מהמקומות זה 24, בחלק 32 וכו' – צריך לשאול את חברת חשמל לגבי הבית שלך), והמתגים המשניים יכולים להעביר X אמפר לאותם נקודות להם מחוברת נקודת המשנה (בד"כ זה 10 או 16 אמפר, תלוי במתג המשני). כשמתכננים LAB, כדאי לחשב צריכה פר שרת (Amp = Watt/Volt) וכמובן יש לקחת בחשבון ציודים אחרים שמחוברים לאותו מתג משני, כך שאפשר בהחלט להגיע למצב שלא צריך להגיע לקניית הרחבה לחיבור תלת פאזי.

נקודה נוספת חשובה: סוג המעבד. מעבדים כמו Xxxxx (כמו X5670) ומעבדי E5 צורכים לא מעט וואט, אבל אפשר גם ללכת על מעבדי L עם מעטפת צריכת חשמל נמוכה (65 וואט). החסרון: המהירות נמוכה ב-1 ג'יגהרץ לערך ממעבד E5, כך שאם אתה מוכן לאיטיות קלה, תוכל לחסוך בחשמל.

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

כאב ראש: התקנת אפליקציות כבדות וממשקי משתמש בהווה

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

אחת הבעיות היותר מתסכלות בכל מיני אפליקציות כבדות – היא התקנה במערכות לינוקס (ואני לא מדבר על התקנת אפליקציות ב-DEB או RPM שבהם פקודת yum או apt עושה לך את העבודה). תרשו לי לתת 2 דוגמאות להקמת מערכת POC של אפליקציות כבדות כאלו.

נתחיל עם OpenStack. חברת קוקי יבואני נעליים (כן, שם מהסרטים) החליטה ש-Openstack זה יכול להיות אחלה פתרון בשבילם, אבל הם קודם רוצים ללמוד בכלל מה זה, ואם אפשר – שיקימו על VM את המערכת שהחבר'ה יוכלו להתרשם וקצת לשחק עם זה. בשום מקרה ה-VM לא הולך להיות שרת פרודקשן. במקרה כזה אם מישהו מחברת קוקי יצור איתי כפרילאנסר קשר לגבי זה, אשמח לדוגמא להפנות אותם לדף פרויקט ה-RDO כדי להקים את ה-OpenStack. כל איש סיסטם, גם אחד כזה שאין לו הרבה נסיון עם לינוקס יוכל לעקוב אחר ההוראות הכי פשוטות ולהקים מערכת. אחרי הכל, כל מה שאיש הסיסטם יצטרך לעשות זה להקים VM עם מערכת הפעלה CentOS 7, עם 32 ג'יגהבייט זכרון ועם 4 ליבות, לבצע SSH למערכת, לוודא ששם ה-hostname הוא אכן תקין ומופיע ב-DNS של החברה, ולהריץ את הפקודות. משם הכל יבוצע באופן אוטומטי ולבסוף גם יופיעו לו הוראות איך להתחבר למערכת.

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

ויש גם דוגמאות הפוכות: אותה חברת קוקי, נניח שהיא קראה בבלוג העסקי שלי על OpenShift והיא רוצה להקים אותו אצלה כדי "לשחק" עם הפלטפורמה. בחברה יש כבר נסיון עם קונטיינרים והם שוב פונים אליי, ואני אשמח להפנות אותם לדף הזה אם הם משתמשים במערכות Red Hat או לדף הזה אם הם משתמשים ב-CentOS וספציפית לחלק של הקונטיינרים עם Docker. הפקודה שם לא תעבוד כי מישהו שכח להוסיף פרמטר
(v /sys/fs/cgroup:/sys/fs/cgroup:rw-) ורק אחרי הוספת הפרמטר הקונטיינרים יעלו והמערכת תעבוד, אבל אחרי שהם יכנסו למערכת הם יראו שיש מספר "הפתעות" לא נעימות כמו:

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

אז אולי יש דרך אחרת להקים OpenShift? כן, יש Installer כלשהו וזה זמין כאן אך מכיוון שרובנו עובדים עם CentOS ולא עם RedHat אז עדיף לך ללכת לקישור לדף העליון שמוזכר לגבי CentOS, רק שאל תבנה על כך יותר מדי, רד-האט הוציאו את ה-Installer הזה לפנסיה מוקדמת. פתרון חלופי ל-Installer? רעיון טוב, בינתיים אין משהו. יש כמובן את הדרך של ההתקנה עם Ansible, רק שהיא מצריכה ידע כלשהו ב-Ansible והיא דרך די מעולה… לגרום לך להוציא שערות מהאף (אם אתה לא מכיר Ansible). יש כמובן דוגמאות באינטרנט איך אתה יוצר קובץ הגדרות די מינימלי ומריץ אותו מול תיקיה מסויימת ב-openshift-ansible (שאותו אתה צריך לשכפל מה-GIT) עם קובץ מה-GIT בשם openshift-ansible/playbook/byo/config.yml רק ש.. הפתעה, הקובץ config.yml לא קיים, ואף אחד לא טרח לעדכן את זה וגם כשאתה מצליח למצוא פתרון חלופי (כאן) תקבל כמה שגיאות בהרצת ה-playbook (הנה הטיקט שלי על כך) כאן.

(אגב, מי שמחפש להקים על הלאפטופ שלו את OpenShift, יש את minishift שהוא באמת קל להתקנה ולחובבי Kubernetes יש את minikube – הכל רץ על Windows, Mac ולינוקס כל עוד מותקן לכם פתרון וירטואליזציה בלאפטופ, אם כי יש בעיה להקים את זה על ESXI, המערכת מקימה בתוכה VM פנימי עם NAT ואז אינך יכול לגשת לשם ממשק web או לאפליקציות שלך. שינוי מ-NAT ל-Bridge לא עוזר).

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

  1. לבנות ממשק Web או ממשק טרמינל עם ncurses (זוהי ספריה שמאפשרת לך ליצור "GUI" טקסטואלי, משהו שמזכיר בעבר הרחוק את Magic ב-DOS למי שזוכר) שאיתם ניתן לבנות ממשק ששואל את המשתמש קבוצת שאלות כל פעם.
  2. ממשק ה-Web/GUI אמור לבדוק את הפרמטרים מיידית. הכנסת שם FQDN לא נכון? כתובת לא נכונה? פורט לא נכון? תיקיה לא נכונה? המערכת אמורה מיידית לסמן שהפרמטר בשדה זה שגוי (בד"כ עם מסגרת מלבנית אדומה סביב אותו שדה) ולא לתת למשתמש להמשיך הלאה עד שזה יתוקן.
  3. אפשרות חביבה שקיימת ב-oVirt היא שמירת קובץ תשובות, כך שאפשר במסגרת ממשק ההתקנה לאפשר למשתמש להעלות קובץ תשובות קודם, כך שאם צריך להקים את המערכת בשרת אחר, הדברים יהיו קלים ומהירים בהרבה.
  4. התקנה אוטומטית דרך SALT או Ansible הכלולים בחבילה אמורה להוציא גם פלט קריא אנושית כך שגם מישהו שאינו מומחה אוטומציה יוכל להבין מה בדיוק התקלה ואולי יוכל לתקן אותה. אחרי הכל – אם מישהו נמצא במסגרת Trial, הוא לא תמיד זכאי לתמיכה.

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