תגית: india

רכבת הרים, חומרה תוכנה ואכזבה

כל שנה מתחילה בסימן שאלה

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

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

1yr

Caringo – תוכנה זה קשה

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

חלק מהפתרון חייב גישה לאותו המידע בו זמנית בצורת קבצים (NFS+SMB) ובצורת אובייקטים (S3 compatible) ולכן הפתרון שלנו כלל שת"פ עם החברים מקרינגו.

Caringo SWARM הוא פתרון software defined storage המספק מערכת אחסון אובייקטים די מגניבה, הפתרון סקלבילי, מאפשר כמובן להגדיר מדיניות erasure coding ברורה, מאפשר הכלת מדיניות worm לשימור מידע בהתאם למדיניות הארגון ומספק ממשק ניהול ודיווח ברורים ונוחים.

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

Caringo Drive הוא תוסף פשוט המאפשר גישה בפרוטקול SMB שנראה ומתנהג פשוט כמו תיקיית רשת לסביבת חלונות, למשתמש הקצה זה נראה כמו תיקיה רגילה לגמרי.

פתרונות כמו קרינגו מאפשרים הרבה מאד גמישות תפעולית אבל התקנה של פתרון SDS נקי יכולה להיות די מאתגרת, הליך ה sizing לא טריויאלי ויש הרבה מאד חלקים שונים להתקין ולוודא שכל החלקים מנגנים ביחד באופן חלק

מצד שני – חומרה זה גם קשה

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

Dell EMC הכריזה על מהלך הפוך עבור פתרונות ScaleIO ומעכשיו ניתן לרכוש את המוצר, שהיה עד לא מזמן מוצר תוכנה בלבד, רק על גבי שרתי Dell כחלק מפתרונות VxRAck FLEX.

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

Management pack for VMware VROPS

לפני כמה חודשים סיפרתי לכם על ה Plug-In שלנו ל VMware vRealize Log Insight והיום אני רוצה לספר לכם על ה Management Pack החדש שלנו עבור VMware vRealize Operations. גם הכלי החדש הזה כמובן זמין ללקוחות ללא עלות נוספת מאתר התמיכה שלנו וללא מגבלות על כמות מערכות או נפחים.

vRealize Operations או VROPs, הוא הכלי של VMware לניטור ובקרה של סביבת IT. ככל שעולים ברמת הרישוי, עולים ברמת הבקרה מניטור התשתית אל רמת השרתים הווירטואליים והאפליקציות. יצרנים רבים מספקים חבילות ניהול ורובם גובים עבורן הון קטן. התאמת חבילת ניהול שכזו למוצרים דורשת ידע והתמחות ונוצר שוק חיצוני של שחקנים כמו Blue Medora שמוכרים חבילות עבור יצרנים אחרים ותלוי בהסכם עם היצרן הספציפי החבילות יכולות להיות מוכרות רשמית על ידי היצרן או שלא מוכרות רשמית אלא רק עובדות.

בכל מקרה, מה ש VROPs רוצה לספק לנו זה הקללה המוכרת של single pane of glass לניטור כל מה שיש לנו, ה Management Packs השונות מאפשרות לנו לקשר את הפלטפורמה גם למארזי שרתי להב או מתגי SAN וכו'.

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

קהילה

מדי פעם אני מציק וקורא לכולכם לתמוך בקהילה (כאן למשל) ולכן אני שמח לחלוק ולעדכן שמצאתי עוד בלוג IT בעברית. הבלוג http://virtual.sites.co.il/ מתגאה בתואר בלוג הוירטואליזציה העברי הראשון והוא מנוהל על ידי קבוצה הכוללת את מיכאל מליז'ונק (עוד אחד מה vExpert אבל לא אני לא מתמרמר ולא מתבאס בכלל!), יניב ויינברג ובן חגי. בקרו בבלוג שלהם ותהנו.

זה הכל להפעם,

שלכם,

ניר מליק

הקרמה באה בבעיטת סיבוב ואז היא הריצה Vdbench

ואוו איך הקרמה התפוצצה לי בפרצוף מהר הפעם.

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

נתחיל מהעובדה שבנתב"ג, אחרי שעמדתי 55 דקות בתור לביטחון ועוד 50 דקות בתור לצ'ק-אין למרות שעשיתי צ'ק-אין באתר של טורקיש ולכאורה אני אמור להגיע לאקספרס צ'ק-אין, הודיעו לי שאני לא יכול לעלות לטיסה לאיסטנבול. המטוס שאמור להגיע מאיסטנבול לקחת אותנו מאחר, הוא עדיין לא המריא מאיסטנבול ואין סיכוי שנספיק לעלות על טיסת ההמשך שלנו לדלהי. אחרי המתנה ארוכה ומעצבנת, סתם בעמידה מול דלפקי הצ'ק-אין, העבירו אותי לטיסת לופטהנזה לפרנקפורט. הקונקשן בפרנקפורט עוד יותר קצר ושדה התעופה עוד יותר גדול אז אחרי ריצה – נסיעה ברכבת הפנימית – ריצה – שיחה מתנשפת עם נציגת air india הספקתי לארגן לעצמי מקום ביציאת חירום לטיסת ההמשך הארוכה ואז הגיעה נקודת האור הכמעט יחידה בנסיעה הזו, הספקתי לאכול שתי נקניקיות ולשתות בירה אחת לפני שעליתי לטיסת ההמשך. אני מקצין קצת כי לא באמת הספקתי לשתות את הבירה אבל הרשו לי לעלות איתה לטיסה וככה זכיתי להיות מהאחרונים שעולים על 787 עמוס ולקבל מבטים של כל הנוסעים "הנה השיכור שבגללו אנחנו מתעכבים" למרות שלא היה עיכוב בכלל ועליתי בזמן תפסיקו להסתכל עלי don’t you judge me! אגב 787 אכן מטוס נחמד מאד וכשמטים את המשענת אחורה המושב מחליק טיפה קדימה, די קול.

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

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

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

real workloads

Vdbench הוא כלי של אורקל שמיועד לבדיקות עומסים ותקינות של מערכות אחסון. מדובר בכלי פשוט מבוסס Java ולכן ירוץ כמעט על כל מערכת הפעלה שתתקלו בה כולל הפצות Windows, UX, AIX, לינוקס, Mac ואפילו RaspBerry Pi (למרות שקשה לי לראות מה המטרה להריץ עומסים מכלי כל כך קטן, אולי אם מריצים כמה במקביל).

אם הכלי הוא כלי Java אז צריך Java . אם קיבלתם שרת ריק, כמוני, ואם השרת שלכם הוא שרת ממשפחת הפדורה, כל מה שצריך לעשות זה להריץ yum install java. צריך הרשאות root לבצע את זה אז אם אתם ל root  ואני מקווה שאתם לא עובדים עם root סתם אז תריצו sudo yum install java. השרת צריך גישה לאינטרנט כדי שהתהליך הזה יעבוד חלק, הוא יגש לrepository, יוריד לעצמו את כל מה שהוא צריך ואחרי כמה דקות ושני אישורים זה מה שאתם רוצים לראות:

Installed:

  java-1.8.0-openjdk.x86_64 1:1.8.0.141-1.b16.el7_3

Dependency Installed:

  copy-jdk-configs.noarch 0:1.2-1.el7                                  fontconfig.x86_64 0:

  fontpackages-filesystem.noarch 0:1.44-8.el7                          giflib.x86_64 0:4.1.

  java-1.8.0-openjdk-headless.x86_64 1:1.8.0.141-1.b16.el7_3           javapackages-tools.n

  libICE.x86_64 0:1.0.9-2.el7                                          libSM.x86_64 0:1.2.2

  libXcomposite.x86_64 0:0.4.4-4.1.el7                                 libXext.x86_64 0:1.3

  libXfont.x86_64 0:1.5.1-2.el7                                        libXi.x86_64 0:1.7.4

  libXrender.x86_64 0:0.9.8-2.1.el7                                    libXtst.x86_64 0:1.2

  libfontenc.x86_64 0:1.1.2-3.el7                                      libxslt.x86_64 0:1.1

  lksctp-tools.x86_64 0:1.0.17-2.el7                                   python-javapackages.

  python-lxml.x86_64 0:3.2.1-4.el7                                     ttmkfdir.x86_64 0:3.

  tzdata-java.noarch 0:2017b-1.el7                                     xorg-x11-font-utils.

  xorg-x11-fonts-Type1.noarch 0:7.5-9.el7

Dependency Updated:

  nspr.x86_64 0:4.13.1-1.0.el7_3          nss.x86_64 0:3.28.4-1.2.el7_3          nss-sysini

  nss-tools.x86_64 0:3.28.4-1.2.el7_3     nss-util.x86_64 0:3.28.4-1.0.el7_3

Complete!

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

מה הכוונה משהו סביר לעבודה? החלק החשוב בבדיקות כאלו הוא לדמות משהו ריאלי, אין הרבה טעם להריץ 100% read IO של בלוקים בגודל 2K. למה? כי אין הרבה אפליקציות שככה נראה הIO Pattern שלהן אז למרות שנקבל מספרים די מגניבים, אלו מספרים חסרי משמעות יישומית ללקוח. היות וניסינו לעבוד מסודר ועשינו את עבודת ההכנה ידענו איך נראה ה workload של הלקוח לשרת בודד וככה בנינו את קובץ ההגדרות שלנו ואז אפשר לשחק עם הקובץ, להריץ אותו לדמות שרת בודד, להריץ אותו לדמות כמה שרתים, להוריד את ה performance peak, להריץ רק את performance peak וכן הלאה. הסיבה להוריד את ה performance peak או להריץ רק את השיא היא שלפעמים יש שונות מאד גדולה בין מה שהשרת עושה במהלך רוב הזמן ומה שהוא עושה בשיא הביצועים, במקרה שלנו למשל, בשיא הפעילות השרת מריץ בלוקים פי 2 יותר גדולים בקריאה ופי 10 יותר גדולים בכתיבה (batch job) ולכן כדאי לראות כמה וריאציות שונות של היחס בין אלו לאלו.

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

*

* Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

*

 * Author: Henk Vandenbergh.

*

 *Example 1: Single run, one raw disk

 *SD:      Storage Definition

*WD:    Workload Definition

*RD:     Run Definition

*

sd=sd1,lun=/dev/rdsk/c0t0d0sx

wd=wd1,sd=sd1,xfersize=4096,rdpct=100

rd=run1,wd=wd1,iorate=100,elapsed=10,interval=1

 *Single raw disk, 100% random read of 4k records at i/o rate of 100 for 10 seconds

SD מגדיר את הדיסקים אליהם אנחנו רוצים לכתוב, במקרה הזה דיסק בודד שנמצא בנתיב /dev/rdsk/c0t0d0sx

WD מגדיר מה מרצים כלומר איך נראה ה workload, בדוגמה הזו מדובר על בלוקים בגודל 4K ואגב, אפשר פשוט לכתוב 4K במקום 4096 ומדובר כאן על 100% קריאה – rdpct=100 – read percent 100

RD מגדיר כמה מריצים וכאן מוגדר להריץ iorate=100 כלומר 100 פעמים מה שמוגדר ב WD.

לבדיקות ביצועים אמינות ויציבות כדאי להריץ לפני כן workload בסיסי של fillup שמטרתו די ברורה מהשם שלו, למלא את הדיסקים לפחות באופן חלקי. למה? כי כולנו יודעים שמערכת ריקה לא מתנהגת כמו מערכת מלאה או מלאה חלקית, אם היא ריקה אז אין תחרות על משאבים, תהליכי ה metadata פשוטים יותר, אין בעיות למצוא מקום פנוי לבצע תהליכי כתיבה, כל תהליכי הקריאה פשוטים, אין בשום מקום תהליכי scrub או תהליכי garbage collection, הכל נקי וחלק ופנוי ולא אמין.

ההרצה בפועל היא פקודה מאד פשוטה

./vdbench -f configfilename

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

וזו התוצאה הצפויה, הכלי מדווח שהוא יוצר את קובץ הפלט, שההתקנים מחוברים ושהוא מתחיל לעבוד על קובץ הקונפיגורציה שבחרתם. הפלט למטה מראה לנו בערך 6000 IOps של כתיבה בלבד בבלוקים של 256K, זה שלב ה fillup ובבלוקים כאלו גדולים גם זמן התגובה (latency) בהתאם

 

13:30:44.188 Created output directory '/home/vdbench50406/ outputfilename

13:30:44.202 input argument scanned: '- configfilename

13:30:44.202 input argument scanned: '- outputfilename

13:30:44.341 Starting slave: /home/vdbench50406/vdbench SlaveJvm -m localhost

13:30:44.865 All slaves are now connected

13:30:46.001 Starting RD=fillup; I/O rate: 15000; elapsed=30000; For loops: threads=32

Aug 02, 2017  interval        i/o   MB/sec   bytes   read     resp     read    write     re

                             rate  1024**2     i/o    pct     time     resp     resp      m

13:31:06.042         1    6073.95  1518.49  262144   0.00   51.710    0.000   51.710  107.9

13:31:26.049         2    6148.60  1537.15  262144   0.00   51.924    0.000   51.924  103.0

13:31:46.045         3    6184.25  1546.06  262144   0.00   51.756    0.000   51.756  106.2

 

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

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

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

20170801_191543

זהו, יצא די ארוך הפעם, מקווה שיועיל למישהו.

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

20170803_082600

אל תהססו לספר לי מה דעתכם.

שלכם תמיד,

ניר מליק

 

How to PoC, Cisco UCS M5 and some other stuff

How to PoC

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

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

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

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

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

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

העיצה האחרונה בנושא להפעם היא ההכנה ברמה האישית, חובה לנסות בעצמך במעבדה כל דבר שאתה מתכנן לעשות אצל הלקוח כדי לדעת איך נראית התוצאה הרצויה ולנסות, אם אפשר, גם לתת מענה אם מקבלים תוצאה אחרת. כדאי מאד להביא איתך כל מה שאולי יהיה נחוץ ל PoC מוצלח, אני הבאתי איתי הפעם גם מפתח שוודי כי אמרו לי שאולי יהיה צורך להזיז את המכונה מחדר שרתים אחד לשני. הבאתי גם שני סטים של מתאמי חשמל, כבל RJ45, טושים מחיקים, מתאם VGA-HDMI, דיסק קשיח נייד, דיסק-און-קי ומחברת. אלו דברים שבכל מקרה כדאי שיהיו בתיק אבל אם אתה נוסע במיוחד להודו כדי להדגים משהו, כדאי מאד שיהיה לך כל מה שאתה צריך בשביל להדגים אותו. על הדרך הכנתי גם על המחשב שלי עותק של כל תוכנה ו virtual appliance שיש לנו שחשבתי שנזקק לו וגם הורדתי מראש חלק ניכר מהתיעוד שחשבתי שיהיה בו צורך (ומצאתי עצמי עושה השלמות תוך כדי כי לא חשבתי על הכל )

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

 

Cisco UCS M5

Cisco הציגה לא מזמן את דור 5 של השרתים שלה, שרתי ה UCS. השרתים החדשים תומכים בסדרת המעבדים החדשה של Intel, Scalable Processors או בקיצור SP, מספקים תמיכה בכמות כפולה של RAM לעומת דגמים מקבילים בדור הקודם וכן תמיכה בכמות גדולה יותר של מאיצים גרפיים כולל תמיכה בשני כרטיסי Nvidia בשרת הלהב הכי פופולרי, B200. הדור החדש כולל כרגע שני שרתי להב ושלושה שרתי Rackmount.

במקביל הוצג דור חדש למערכת הניהול, UCS director 6.5, שכולל מעבר לתמיכה בדור השרתים החדש גם שדרוג ביכולות האוטומציה לפריסה של פתרונות flexpod אוטומציה של תהליכים בסביבות hyper-flex.

הערת שוליים חשובה שתשמח מאד הרבה מאד אנשי פריסייל שמוכרים שרתים באופן כללי: הדור החדש של מעבדי אינטל כולל יותר ערוצים ופחות רמות כלומר, אם הדור הנוכחי כלל עבור כל מעבד 4 ערוצים (Channel) וכל ערוץ תמך בעד 3 רמות (Rank), הדור החדש כולל 6 ערוצים עם שתי רמות. כמות רכיבי הזיכרון הכללית נשמרת (12), ההנחתה במהירות כאשר משתמשים בכמות גדולה של רכיבי זיכרון יורדת וסה"כ צריך להתעדכן בכללי האכלוס החדשים כדי שלא למכור בטעות ללקוחות כמות רכיבים לא נתמכות. אם אתם דומים לי אז תזדקקו לכמה וכמה קונפיגורציות עד שהמספרים החדשים יבואו לכם באופן טבעי.

intel 6 channel and rank

בשולי החדשות

Gartner 2017 Magic Quadrant for Solid-State Arrays

Gartner פרסמו לא מזמן את הדירוג שלהם למערכי אחסון מבוססי Flash, טיפה מוזר לראות את ריבוע הקסם כל כך עמוס הרי לא יכול להיות שכל מי שמשחק בקטגוריה הוא גם מוביל בקטגוריה, או שמשהו שתהליך הבדיקה דורש ריענון או שמערכי All Flash הפכו עד כדי כך Commodity שכל מי שנוגע בהם מצליח. אני מהמר על אופציה א'. עוד מעניין היה לראות בריבוע ה visionaries שTegile מדורגים טיפה יותר גבוה מטינטרי שהנפיקו בבורסה בניו-יורק לאחרונה. אמנם ההנפקה של טינטרי היתה קצת נמוכה אבל לא ידעתי שהחברים בטג'ייל עוד בכלל בביזנס אז הנה, כל יום לומדים משהו חדש.

MQ Graphic 7 17 17.jpg.imgo

 

 

Google Cloud Transfer Appliance

בשנים של איחור, אחרי שAWS מספקים גם Appliance בשם Snowball וגם את המגה-משאית שלהם Snowmobile, גם גוגל מצטרפים עם מארזי דיסקים מוקשחים המספקים עד 100TB במארז של 1U או 480TB במארז של 2U  (נפחים לפני דחיסה), המיועדים לאפשר ללקוחות העתקה של נפחי מידע גדולים מאתר הלקוח אל שירות הענן של גוגל בלי המורכבות והעלויות של הגירה על גבי קווי התקשורת.

 

Mellanox Spectrum-2

הולי שמולי, החברים ביקנעם היו כנראה מאד עסוקים בחודשים האחרונים והנה הם יוצאים בהכרזה על סדרת מתגי Ethernt חדשה שתומכת במהירויות 200 וגם 400 ג'יגה לשניה, רוב הלקוחות בארץ לדעתי עוד לא עברו ל 10Gb ואני מהמר גם שרוב הפורטים בעולם עוד לא עברו הסבה והנה זו כבר טכנולוגיה של פעם, די מדהים.

 

 זה הכל להפעם חברים,

אשמח לשמוע הערות והארות

שלכם תמיד,

ניר מליק

קצת מכל דבר – סכום חודש מרץ

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

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

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

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

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

בינתיים בעולם מקביל, @jessfraz כתבה פוסט רגזני על ההבדל התפיסתי בין קונטיינרים לשאר מיני ירקות וכנראה קלעה לדעת הקהל הטוויטרית או לפחות לדעתו של (@marioploria) כי הוא קנה שני דומיינים במיוחד לכבוד הפוסט שלה ועכשיו גם containers.win וגם containers.fail מפנים אל הפוסט שלה.

עמדתי לסיים את הפוסט הזה ולשלוח אבל פתאום ראיתי שחטיבת ה IP  של ברוקייד נרכשת על ידי Extreme Networks תמורת 55M דולר. 55M עבור חטיבת ה IP לעומת המחיר המלא שברודקום שילמו על החברה כולה בשנה שעבר, 5.5B (מיליארד!) דולר. זה פער די מדהים והוא מראה כנראה את הפער בין שווי של פעילות מובילה בעולם לבין חטיבה חלשה בתחום מוצף.

 

שלכם תמיד,

ניר מליק