גרטנר, עננים, פלטפורמות ולמות

דילמה מוסרית

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

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

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

תקראו עד הסוף היום, על תעצרו במונטי פייטון בסדר?

גרטנר

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

gartner

Pure מכריזים על פתרון חדש לעולם ה hybrid cloud

לאחרונה קצת ניגחתי את Pure והנה שוב הזדמנות לפרגן במקום. בשבוע שעבר הם הכריזו על פתרון חדש  שמאפשר להריץ את מערכת ההפעלה שלהם גם על גבי תשתיות AWS וככה לספק חוויה דומה (אותם API) באתר הלקוח או בענן. יכולת זו מצטרפת ליכולת הקיימת לבצע טירינג של סנפשוטים לענן (יכולת שנקראת אצלם CloudSnap) שדומה ליכולת של NetApp שנקראתFabric Pool.

כתבתי כבר על החשיבות של hybrid cloud ושל data mobility כמו גם data governance. הסיפור של פיור מצטרף כאן לסיפור ה Data Fabric של NetApp וכמובן לסיפור ה Neutrix שלנו באינפינידט. הפער בין חדר השרתים והענן הוא האתגר הגדול של עולם ה IT כי לפחות בעתיד הנראה לעין גם פתרונות On Premises וגם פתרונות Cloud יחיו זה לצד זה ולכל אופציה יהיו היתרונות והחסרונות שלה.

אמזון סנובול אדג' חדש

גם באמזון, שיצרו למעשה את עולם ה Public Cloud ומובילים אותו בבטחה גם מבחינת הגודל וגם מבחינת החדשנות, רואים את הפער ומספקים פתרונות שונים כדי לצמצם אותו. כתבתי בעבר על שירותי המיגרציה של גוגל והזכרתי שם את ה Snowmobile של אמזון והשבוע במסגרת RE:Invent הם הכריזו על מוצר חדש באותה סדרה או למעשה בסדרה הקטנה יותר שנקראת Snowball Edge. המוצר החדש כולל יכולות מחשוב חזקות יותר ותמיכה בכרטיסי האצה גרפיים GPU. הסדרה הזו למעשה תוקפת את הפער מהכיוון ההפוך ומאפשרת לפתח כלים בענן ואז "להביא" אותם, פיזית, בתוך מארז מוגן ומוקשח, אל חדר השרתים או איפה שצריך אותם כדי שירוצו בפועל.

פלטפורמות ובהמות משא דרום אמריקאיות

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

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

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

יש כאן למשל כלי שכל חברה, או מחלקה בתוך החברה, יכולה לאמץ לעצמה גם בלי לזעזע את כלל המבנה הארגוני או להוציא תקציבים גדולים, הכלי נקרא 5 הלמות. סתם הוא נקראה 5 הלמה, the 5 whys, ובדוגמא שלפנינו, אמזון משתמשת בכלי הזה כדי לבצע תחקיר למציאת שורש הבעיה, Root cause Analysis. מספרים לנו שעובד אחד פצע את האצבע על מסוע.

למה הוא פצע את האצבע? כי היא נתפסה במסוע

למה האצבע נתפסה במסוע? כי העובד ניסה לתפוס את התיק שלו

למה הוא ניסה לתפוס את התיק שלו? כי התיק היה מונח על המסוע והמסוע פתאום התחיל לפעול

למה התיק היה על המסוע? כי העובד השתמש במסוע כשולחן

למה העובד השתמש במסוע כשולחן? כי הוא היה צריך להניח את התיק ולא היה במקום שולחן

פתרון לבעיה – לוודא שיהיו שולחנות במיקומים נחוצים או לפחות שולחנות מתקפלים ניידים זמינים למי שצריך אותם

הגירה של שירותי קבצים בשרת חלונות 2019 החדש

בתחילת הפוסט הזכרתי שהייתי בקוריאה בשבוע שעבר ואחד הדברים שדיברנו עליהם הרבה היה מיגרציות. לקוחות בכל העולם רגילים שפרויקט מיגרציה של סטורג' זה פרויקט גדול מסובל ויקר והרבה פעמים גם מסוכן. עבור רובם זה לא נכון עבור ככה הם רגילים ובשוק מסורתי כמו קוריאה זה נכון כפליים. דיברנו הרבה על העובדה שעם כלים כמו VMware vSphere Storage vMotion או Live Migration המקביל ב Hyper-V, לקוחות בכלל לא צריכים עזרה בשביל להעביר באופן קל וחלק את מרבית חדר השרתים שלהם ממערכת אחסון אחת לשנייה.

כמו מהשמיים גיליתי שאפילו מיגרציה של קבצים משרתי Windows זה לא מה שהיה פעם. מיקרוסופט תומכת היום במיגרציה של קבצים משרתי Windows ישנים, אפילו שרתי 2003 שכבר לא נתמכים רשמית, אל שרתי Windows 2019 פיזיים או וירטואליים או לשירותי הקבצים של Azure באמצעות כלי מובנה שנקרא Storage Migration Service או SMS וכן, השירות הזה מובנה בשרתי 2019 ושרתי WAC (Windows Admin Center).

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

טוב, יצא פוסט עמוס מכל טוב,

שלכם כמו תמיד,

ניר מליק

מודעות פרסומת

קהילה,vRNI, Hyper-Flex, פיניקס ולימון כבוש

חיי קהילה  – אני ממשיך ללחוץ עליכם

בפוסט הקודם המלצתי לכולכם לחלוק את הידע שלכם עם הקהילה.

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

eli-florental

השבוע גיליתי גם שידידי היקר, נתנאל בן שושן, מנהל תחום מיקרוסופט אצלנו בחברת We Ankor הוא אחד מתשעת החברים המכובדים בקהילה המיוחדת של VMware vExpert בישראל. זה אומר שגם הוא ממשיך את המסורת שהתחיל כ Microsoft MVP ומשקיע זמן ואנרגיה כדי לחלוק את הידע הרב שצבר עם קהילת ה IT שסביבנו.

VMware vRNI

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

באותו אירוע דיבר גם אבי יושי, מהנדס מערכות בכיר ב VMware ישראל, שהציג את פתרון ה VMware vRNI או בשמו המלא, vRealize Network Insight. כלי מאד חזק לוויזואליזציה של התעבורה בחדר השרתים. אחד האתגרים הנפוצים בבניית סט חוקי אבטחת מידע בסביבות מורכבות הוא מיפוי ומעקב אחר הגורמים השונים, לאיזה שרת מותר לתקשר עם איזה בסיס נתונים, איזה שירות Web מנסה להגיע אל איזה כרטיס רשת וכדומה. ככל שהסביבה גדולה ומורכבת יותר כך האתגר הזה מורכב יותר. תשתיות וירטואליזציה ותשתיות Software Defined מוסיפות נדבך של מורכבות כי חלק מהתעבורה ולפעמים חלק ניכר מהתעבורה כלל לא מגיע אל חומות האש הארגוניות או מתגי ה Layer 3 שלנו ולכן התעבורה אינה גלויה לתהליכי NetFlow.

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

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

vrni-vrealize-network-insight-application-connectivity

בתצלום הזה אנו רואים מיפוי של שירות web ספציפי לניתוח סוגי התעבורה השונים שלו

Microsegmentation-analysis.png

היום אירוע שני אירועי התפרצות לבתים במושב בו אני גר ובדיון בקבוצת הווטסאפ שלנו הזכירו כי "קו המגע לעולם ייפרץ". אחד הקוים המנחים ביישום מיקרו-סגמנטציה, ה use case הכי נפוץ של NSX, הוא שבתצורה זו קל יותר לגלות פריצה ולהכיל אותה משהתרחשה. ללא מיקרו-סגמנטציה, בעולם של VLAN'ים גדולים, מרגע שנפרץ משאב אחד, התנועה האופקית בתוך שכבת האבטחה שלו קלה יחסית ולפעמים גם נשארת חבויה ולכן השילוב של שני הכלים, vRNI+NSX יכול לייצר פתרון אבטחת מידע מאד אפקטיבי.

Cisco Hyper-Flex

בנושא אחר, יצא לי לשחק לאחרונה קצת עם פתרון ה Hype-Flex של Cisco. פתרונות ה hyper-Converged  הם נושא מאד חם בתקופה האחרונה ובטח יצא לכם לשמוע על הרכישה המשמעותית של HPE את SimpliVity.

הפתרון מבוסס שרתי Cisco בתצורת Rack ככה שכבר אנחנו יודעים שמבחינת החומרה אנחנו מקבלים פתרון מאד איכותי. כל השרתים מקושרים ל Cisco UCS FI סטנדרטי אז אין עקומת לימוד גדולה מדי לניהול תשתית החומרה וכשאני אני מתכוון שאין עקומת לימוד גדולה מדי אני מתכוון שגם ככה ממשק הניהול של UCS  הוא ממשק מעולה ונוח לשימוש. אגב, היות ומדובר באותו FI, ניתן לנהל גם סביבת Hyper-Flex וגם סביבת UCS רגילה באמצעות אותם מתגי ניהול, זה די נוח ללקוחות קיימים וכן מאפשר את הגמישות לקשר אל ה Hyper-Flex Cluster גם שרתי Compute בלבד מתוך מערך ה UCS Blade או שרתי UCS Rack אחרים המקושרים אל ה FI. אין צורך ברישוי Hyper-Flex עבור שרתי Compute only.

הקלאסטר כולל מינימום של 3 שרתים ועל כל שרת מותקן Storage Controller האחראי לכלל פעילות ה IO מול הדיסקים המקומיים בשרתים. מערכת ה"אחסון" משתמש בטופולוגית log structured שמאפשרת כתיבה ל buffer, ביצוע inline dedup/compression והורדה סיקוונסיאלית של המידע הנכתב אל הדיסקים. יכולות אלו משמעותיות מבחינת ביצועים בתצורות היברידיות ומבחינת flash cell wear leveling בתצורות all flash. תהליך ה stripe מתבצע על כלל הדיסקים המוקצים לקלאסטר על מנת לרתום את כל הספינדלים לתהליכי ה IOps. כלל ה Storage controllers נגישים לפעילות IOps ב pNFS לשרתי ה Compute כדי לא ליצור צוואר בקבוק בגישה אל המידע. תהליכי ה Snap Shot הם תהליכי redirect on write זריזים ויעילים כמקובל בימינו.

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

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

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

hyperflex

The Phoenix Project

בפוסט הקודם דיברתי גם על the phoenix project והבטחתי לחזור ולהתייחס אליו. אז מה למדתי?

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

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

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

דבר נוסף שביל אנחנו לומדים בתהליך הוא השליטה בכמות העבודה, איך מחליטים איזו עבודה אנחנו מוכנים לקבל על עצמנו? שוב במתודה שביל לומד מניהול רצפות הייצור, אם מקבלים את כל העבודות שזורקים לכיוון רצפת הייצור ומקבלים אותן ללא סינון או סידור, תורי העבודה מתארכים, אין דרך יעילה לאזן את המשאבים (חומרי הגלם, המכונות, העובדים, אותו תנור קריטי שהזכרתי) ולכן כל העבודות, כל המשימות כולן מתעכבות, ככל שעומס העבודה יגבר כך למעשה יגברו רק האיחורים התיקונים והמשימות שיש לבצע שוב מחדש כי לא בוצעו כראוי בפעם הראשונה. אריק מספר כאן לביל על תיאוריות ייצור כמו lean, TQM ועל the theory of constraints ומראה שאם יש משאב קריטי שמנוצל במאה אחוז, למעשה הוא לא ממש יעיל כי הוא לא מסוגל לקבל שום עבודה חדשה, ככל שיש לנו יותר משימות פתוחות או יותר work-in-progress כך יתארך הזמן הנדרש להשלים כל משימה, להשלים כל WIP. באחד הפרקים בספר, שוב מגלים שיש עיקוב מאד גדול בפרויקט הכי חשוב של החברה, פרויקט פיניקס. תחקיר קצר מעלה שברנט אמר על משימה שקיבל שהיא תיקח רק 45 דקות אבל בפועל לקח לו מעל שבוע להשלים אותה. לאחר כמה ימים ארוכים של המתנה ברנט התפנה לאותה משימה שאכן לקחה בערך 45 דקות לביצוע. זמן העבודה בפועל לקח 45 דקות אבל משך הזמן המלאה לביצוע המשימה צריך לכלול את זמן ההמתנה להתפנות המשאב כלומר, שבוע + 45 דקות.

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

לימון כבוש

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

שוטפים היטב את הלימונים – עבור צנצנת בגודל כמו של צנצנת נס-קפה נדרשים כשישה לימונים יפים

חוצים את הלימונים לאורך ואז פורסים לרוחב לפרוסות.

lemon-knife

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

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

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

lemon-small

שומרים מחוץ למקרר שלושה ימים ואוכלים בתיאבון. מה שלא נאכל מיד נשמר במקרר לתקופה מאד ארוכה.

lemon-finished

כמו תמיד אשמח לשמוע מה דעתכם, אל תהססו!

שלכם,

ניר מליק