נישט אהין, נישט אהער

נישט אהין, נישט אהער ביידיש – לא פה ולא שם

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

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

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

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

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

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

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

מילה אישית

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

והנה, ככה נראית החצר הקדמית שלנו במהלך סגר 3.5:

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

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

ניר מליק

פוקה-יוקה, קאיזן ומכרזים מחורבנים

סיפרתי לכם פעם כמה אני שונא מכרזים?

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

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

אצלנו, מאד מקובל לבצע תהליך אפיון מאד מפורט כולל שימוש בכלי אפיון כמו למשל VMware Capacity Planner או ניתוח קבצי NAR של מערכות EMC, Perfstat במערכות NetApp וכו'. אנחנו לאחרונה משתמשים קצת ב mitrend כדי לאסוף ולנתח ביצועים של מערכות שונות וליצר גראפים נוחים לשימוש.

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

במזרח נתקלתי לאחרונה בכמה מקרים שבהם אין שום דרישת ביצועים במכרז, כלום. נפח אחסון נדרש וזהו. עכשיו מתחיל החלק האומנותי, בחלק מהמקרים אין שום דבר אחר, ואז אני חושב לעצמי שמי שפרסם את המכרז פשוט לא מבין בסטורג', קורה. במקרים אחרים רואים משהו אחר, והוא מטריד הרבה יותר, מישהו מפרסם מכרז ללא דרישת ביצועים אבל עם מפרט מאד מדויק של מערכת האחסון שהוא דורש, כמו נניח דגם מעבדים ספציפי או יכולת גידול לכמות בקרים גדולה פי 20 ממה שהוא דורש ביום הראשון. במקרים כאלו ברורה כוונת המשורר, הרי אלא אם אתה יצרן מערכות אחסון בעצמך, אין לך דרך ריאלית לבדוק את ההשפעה על הביצועים בשימוש במעבד 3GHz לעומת שימוש במעבד 3.2GHz  וגם בואו נהיה הוגנים, בניגוד למה שמראים לנו במצגות בכנסים, הסיכוי שאנחנו נישאר עם אותה מערכת בדיוק גם בגידול פי 20 לא סביר כל כך, הרי גם אם אתה בר מזל והעסק שלך אכן גדל פי 20 בטווח הנראה לעין, הארכיטקטורה שלך תשתנה עוד מיליון פעמים בדרך כדי לתמוך בכזה גידול, שום דבר שעובד ב1 לא עובד ב 20 as is, אז למה לקשקש?!

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

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

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

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

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

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

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

עלו והפוקה-יוקו כולכם! קאיזן על בתיכם ומשפחותיכם ומועדים לשמחה!

שלכם,

ניר מליק

זמינות, ביצועים, גיוסים ורכישות עצובות

זמינות

בפוסט הקודם דיברנו על Data Mobility כאחד המאפיינים של Neutrix Cloud והשבוע אפשר לדבר על מאפיין נוסף, Availability.

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

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

*מי שרוצה לקרוא עוד על תשיעיות וזמינות מוזמן לקריאה נוספת בוויקיפדיה

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

azure sla

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

neutrix sfd16

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

amazon cnet

amazon twitter

amazon verge

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

aws zednet

אגב התמונה של Neutrix היא צילום מסך מתוך מצגת שהעביר אריק קולברג שלנו במסגרת Storage FIeld Day 16 ואתם מוזמנים לצפות בה כאן אם אתם רוצים ללמוד עוד קצת על Neutrix

וסתם ככה כדרך אגב במסגרת SFD 16 בריאן קרמודי שלנו העביר מצגת עם neural Cache ואפשר לראות כאן מה חושב ריי לוקזי על היכולת שלנו לספק מעל 90% מה REad IOPS שלנו מתוך ה Cache

ביצועים או יש ביצועים ויש ביצועים

חברת NetApp שחררה לאחרונה תוצאות SPC-1 מאד מרשימות עבור מערכות ה A800 שלה.

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

שימו לב למבנה המערכת. 12 בקרים של הסדרה הכי גבוה של היצרן בשביל לדחוף סה"כ 273 טרה ברוטו עם רמת ניצולת של 66% בלבד כלומר 182 טרה או 15 טרה לבקר. מכירים הרבה אפליקציות בחיים האמתיים שדורשות ארכיטקטורה כל כך מוזרה? שמסוגלות לחיות בכזו סביבה בכלל? מה גם שבשביל לקבל את הביצועים האלו היה צורך לכבות Inline Dedup, לכבות Aggr level Dedup ולא לבצע Snapshots בכלל.

netapp cluster spc-1

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

זו אגב הסיבה שאנחנו משתדלים להשתמש רק ב workload אמיתי של לקוחות כחלק מאתגר ה Faster Then All Flash שלנו עליו סיפרתי לכם כאן וכאן. בסופו של דבר, מרבית מערכות האחסון בעולם לא משרתות איזה כלי בדיקות כמו VDbench אלא מערכת אמיתית כמו MS-SQL, אורקל או SAP HANA וזה אמור להיות הרבה יותר מעניין עבור לקוחות מאשר מה תיאורטית המכונה היתה עושה במעבדה בתנאים אידיאליים. החיים לא אידיאליים.

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

* אני בכוונה כותב פעולות בשניה ולא IOPS כי פעולות SPC-1 הן לא IO טהור אלא מנסות לדמות טרנזקציה הכוללת כמה IO בכל טרנזקציה. אחרת אפשר היה לשאול מה בעצם כל כך מרשים ב 200K IOPS  לכל בקר בימינו

גיוסים

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

למי שלא מכיר SQream מייצרים Database מבוסס GPU  ככה שהשאילתות רצות על כמה אלפי ליבות ולא רק על 24 או 48 או כמה ליבות שיש ל CPU של השרת. הקונץ היפה הוא שמדובר ב Database העונה לשפת SQL סטנדרטית ככה שלא צריך ללמד DBA זקנים טריקים חדשים (כן כן SQL זו שפה ולא רק מוצר של מיקרוסופט מי היה מאמין).

בשדה התעופה בדרך הביתה פגשתי אותם שוב והיה לנו קצת יותר זמן לקשקש (אתם חייבים לי בירה!) ואז גיליתי ש SQream השלימה לא מזמן סיבוב גיוס מאליבבה שהשקיעה 24 מליון דולר בחברה בסדרה B. כל הכבוד חברים המשיכו ככה!

רכישות עצובות

בפוסט שנקרא there is no I in team סיפרתי לכם ש Tintri עומדת בפני פשיטת רגל ואכן בשבוע שעבר זה קרה, החברה הודיעה על סגירת פעילות וDDN הודיעו שהחלו משא ומתן לרכישת נכסי החברה. זה צעד מעניין מצד DDN כי אין להם מוצר שמתחרה בקטגוריה של production storage ויש כאן פוטנציאל להקפיץ אותם אל תוך הטבלה של הקטגוריה הזו אבל מצד שני גם בשיא כוחה טינרטי הייתה שחקן נישה קטן ועכשיו DDN צריכה לשחק בשוק חדש ולא מוכר לה עם מוצר שגורר אחריו שם בעייתי. ימים יגידו אם אכן הם ישלימו את הרכישה והאם היא השתלמה להם.

זה הכל להפעם,

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

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

*ההשתתפות אסורה על ליאור קמרט שגילה לי את הטעות במקור

ניר מליק