Bunch-O-Balloons & some hot air from Pure

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

היזם נתן כדוגמא את הסיפור על Bunch-O-Balloons, מכירים?

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

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

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

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

בכל מקרה, אתמול היה גם ה Analyst Day של Pure Storage שפומפם אצלנו בתעשיה יפה וכולנו חיכינו לשמוע מה יתחבא מאחורי הפרגוד.

ובכן, לא הרבה.

Pure Fusion

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

שירות ניהול מרכזי למערכות Pure תחת מעטה שיווקי ומטעה (רואים מה עשיתי כאן עם מעטה ומטעה?!), לא הרבה יותר מזה, זה נחמד שהם משתמשים בז'רגון ענני כמו availability zone ומוסיפים קצת אי דיוקים טכניים כמו scale out אבל בסופו של דבר זה ממשק ניהול של כמה מערכות שלא מייצר שום תוכן חדש מעבר למה שהמערכות המנוהלות כבר יודעות לייצר.

Portworks Data Services

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

סך הכל הכרזה קצת מאכזבת ואני מזכיר לכם שכשמגיע להם פירגון אני אכן מפרגן להם כמו כאן כשהם השיקו את תצורת ה Active/Active שלהם

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

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

ניר מליק

אמרתי לכם!

אמרתי לכם! הייתי הראשון לזהות!

הדבר הזה פשוט מטורף.

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

CPOC!

זה היה הדמו שעזר לנטו להפוך לכוכב בתוך החברה (CPOC!)

כמה דברים השתנו מאז, הרעיון של NPS היה רעיון חדשני, לשים מערכת אחסון פיזית ליד הענן, ומאז נטאפ כבר יודעת לספק במקום זה מערכת וירטואלית לחלוטין שרצה על הענן בתוך הסביבה הוירטואלית של לקוחות ובמקביל, ספקיות הענן עצמן מספקות את השירות של מערכת ליד הענן בעצמן, שירותים כמו Azure NetApp Files למשל שהם שירות של Azure לכל דבר ועניין רק שמאחוריו יש מערכת אחסון All Flash פיזית של NetApp.

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

אלו היו ימים די תמימים, עבורי לפחות, שבהם דיברנו ענן אבל בסוף מכרנו מערכות אחסון פיזיות. כל כך הרבה השתנה מאז, חלק מהמוצרים שנטו מדבר עליהם כבר לא קיימים והיכולות שלהם הוטמעו בתוך מוצרים אחרים ובאופן כללי הפורטפוליו של שירותי הענן השונים של נטאפ מאד התרחב, מהיכולת להעביר מידע קר לענן  דרך היכולת להעביר מידע לענן תוך כדי המרת הפורמט שלו ועד מערכת ניהול מידע ארגוני חכמה שרלוונטית לכולם, לא רק ללקוחות נטאפ וגם ללקוחות cloud native (תזכירו לי לכתוב בקרוב על Data Sense?!) וההכרזה של היום היא אחת הקפיצות הכי מרשימות של הסיפור של נטאפ קדימה.

היום אנחנו מכריזים על משהו חדש ביחד עם החברים מ AWS, FSxO או בשם המלא FSx for netApp ONTAP

FSxO הופך בפועל את נטאפ לספקית האחסון של AWS כלומר כל לקוח AWS, בין אם הוא לקוח נטאפ ותיק או לקוח שמעולם לא שמע על נטאפ, לקוח EC2 או EKS, VMware on cloud, זה לא משנה, יכול לצרוך את שירות האחסון שלנו בצורה שקופה לחלוטין מתוך שכבת הענן של AWS, כולל סנפשוטים, רפליקציה, יכולות דחיסה וביטול כפילויות, NFS, SMB, iSCSI, FabricPool  שאני אוהב, Flash Cache,  הכל כולל הכל!

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

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

עבור לקוחות קיימים של נטאפ, אפשר להסתכל על שלושה Use Case סופר מהירים וכדאיים והראשון הוא DR. זה סופר קל פשוט להגדיר Snap Mirror ולא לנהל שם דבר יותר, כל התשתית עבור FSxO היא מנוהלת על ידי AWS וכל מה שהלקוח צריך לעות זה להגדיר מדיניות רפליקציה ולשכוח מזה עד יום פקודה.

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

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

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

סוף שבוע נעים ושנה טובה לכולם!

שלכם,

ניר מליק

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

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

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

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

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

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

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

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

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

מילה אישית

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

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

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

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

ניר מליק

לייב בלוגינג – Strategic Cloud Migration – CMS, Microsoft & IsraelClouds

ממשיך ברצף הלייבים והפעם כנס של CMS ו IsraelClouds ביחד עם מיקרוסופט

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

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

מה זה Datacenter? חוות שרתים

מה זה region? אתר הבנוי לפחות משני datacenter או יותר נכון להגיד שני availability zones שמייצגים לפחות datacenter אחד

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

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

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

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

איך בכלל מתחילים מיגרציה לענן?

שלב ראשון לבצע הערכה ואפיון, assessment, כדי להבין מה יש לנו בכלל להעביר אל הענן

עוברים לדוגמאות והדגמות עכשיו על ידי דין עובדיה מ CMS

דמו של תהליך מיגרציה ולאחריו דמו של virtual desktop של מיקרוסופט

Azure migrate מאפשר לנו להוריד מ Azure כלי הגירה אל סביבת ה Hyper-V שלנו

הכלי מותקן בסביבה שלנו כשרת וירטואלי כלומר אנחנו מורידים VHD

לאחר ההתקנה והאוטנטיקציה אנחנו צריכים להוסיף את ה Hyepr-V Host שלנו ואז יבוצע הליך discovery אוטומטי להצגת המכונות הוירטואליות שיש לנו על ה Host

עכשיו ניתן לבצע תהליך Assessment אוטומטי כדי להקל עלינו בבחירה של סוג ה Cloud VM שלנו

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

הרפליקציה מוצפנת כדי להגן על המידע שלנו In Transit.

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

בשלב הזה עוברים להדגים virtual desktop אבל end user זה קצת פחות התחום שלי

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

ואפילו יש כיבוד כמו כנס אמיתי:-) מי שנשאר עד סוף האירוע מקבל שובר לפיצה או לוולט, טאצ' נחמד!

SalesForce Live Israel

מצטער אבל לא היה לי זמן להשתתף בצורה פעילה אבל ה Key Note היה מאד מקצועי ומעניין והמוצר של Bonobo שהוצג על ידי אפרת רפופורט נשמע סופר מגניב

כרגע אני מקשיב לסשן SMB שמונחה על ידי מורן שור (גילוי נאות מורן היא חברה טובה)

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

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

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

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

ניר מליק

לייב בלוגינג – Lift and shift an Apache Kafka cluster to Amazon MSK Floor28 Webinar

יאללה פעם שלישית אני צורח!

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

https://www.linkedin.com/posts/strati-georgopoulos_how-to-use-an-old-phone-as-a-home-security-ugcPost-6710808561468923904-M1dg

יאללה מתחילים

MSK הוא שירות לניהול קלאסטרים של קפקא

השירות נולד מהצורך לפשט את המורכבות בניהול הקלאסטרים ולפנות את המפתחים שלנו לנהל את האפקליציות ולא התשתית

גרסאות נתמכות 1.1.1 2.2.1 2.3.1 2.4.1

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

השירות מספק ברוקרים ו Zoo-קיפרים

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

השירות מספק הצפנה at rest ומתממשק לניהול מפתחות ההצפנה על ידי KMS

קיימת תמיכה גם בהצפנה ברמת TLS עבור data in transit

תאימות לרגולציות כמו HIPPA, PCI וכו'

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

הקלסטר תומך בזמינות של 99.9% ומוגדר על 2 או 3 AZ's בהתאם לדרישת הלקוח

AWS טוענים לחסכון של 40% בעלות התחזוקה מול עלות תחזוקה של קלאסטר עצמאי

אין תשלום על התעבורה בין הברוקרים והZOO-קיפרים

עכשיו למיגרציה עצמה –

למעשה כל כלי מיגרציה קיים שאתם מכירים יכול לעבוד עבורכם גם במעבר אל MSK

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

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

בדוגמא השניה יש צורך לשמר את המידע וכאן באה המלצה להשתמש ב Mirror Maker v2

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

kafka Connect משמשת אותנו להזרים מידע בין קלאסטרים ויכולה גם להזרים מידע מקלאסטרים מסוגים שונים כמו קסנדרה וכו'

בשלב הזה נפל לי החשמל בבית, נקווה שיחזור מהר ונוכל להמשיך בוובינר ובעדכון הלייב של הבלוג 🙂

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

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

יש אפילו אפשרות שנקראת Migration Incentives בה נותנים קרדיטים חינם כדי שתוכלו לתרגל ולבחון דברים לפני המיגרציה!

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

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

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

ניר מליק

לייב בלוגינג AWS Pricing Models Floor28 Webinar

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

https://floor28.co.il/

ההדרכה הפעם מתרכזת בשירותי סטורג', איזה כיף!

שירותי האחסון מחולקים ל3 קטגוריות עיקריות, Block, File ו Object, מוקד ההדרכה הפעם הוא שירות הבלוק, EBS וקצת על RDS.

שירותי File כוללים את EFS (שירות NFS) ואת FSX לשירותי קבצים של windows או luster. FSX משתמש ב S3 ב backed ככה שהוא מאד cost effective וכן highly available. ל EFS יש שני טירים של אחסון, סטנדרט (8 סנט לגיגה לחודש) וטיר של infriquent access בעלות של 2.5 סנט לגיגה לחודש. FSX עולה רק 1.3 סנט לחודש ל סינגל AZ או 2.5 לגיגה לחודש ל multi-AZ. אגב FSX תומך באינטגרציה ל Active Directory כיוון שהוא כאמור מכוון לסביבות windows. לא תאמינו אבל השירות הזה, FSX, כולל גם deduplication שאמור לחסוך כ 505 מעלות האחסון בשירות זה. זה די דהים כי זה נוגד את הקונספט של שירותי הענן בדרך כלל שמחייבים על נפח מוקצה בכלל, למה להם לחסוך לנו בנפחים?

עיצה ראשונה לחסכון בעלויות EBS היא למחוק volumes שאינם בשימוש, נשמע טרוויאלי אבל מסתבר שיש הרבה משתמשים שמוחקים את ה EC2 Instance שלהם אבל לא מוחקים את ה EBS שמחובר אליהם. ניתן למנוע טעויות כאלו אם בהקמת הEC2 אנחנו מגדירים גם delete on termination עבור ה EBS שהוגדרו עבורו, יש לישם לב שזה אכן מה שאנחנו רוצים כדי למנוע מצב הפוף של מחיקת מידע בטעות במחיקה של instance.

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

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

לגבי snapshots בגדול הם ממליצים שוב את אותה עיצה ראשונית של למחוק סנפשוטים ישנים שאין בהם צורך יותר ושכדאי ליישם את ה retention policy שלנו על ידי יכולת life cycle management.

עוברים עכשיו ל S3

S3 standard, S3 intelligent tiering, standard IA, One Zone IA, Glacier, Deep Archive, אם בוחרים את השירות הנכון ניתן לחסוך עשרות אחוזים בהאתם לגישה בפועל שלנו אל המידע, ככל שהמידע "קר" יותר ניתן לאחסון אותו על שכבה נמוכה יותר ולחסוך מלא כסף אבל צריך לזכור שיש עלויות למשיכת מידע בטירים הזולים באמת ויש גם מינימום של זמן שמירה ומינים יחידת נפח לחיוב.

יש לשים לב שלכל אובייקט יש 8Kb ועוד 32Kb של overhead לmetadata. ה 8Kb הראשונים מחוייבים לפי Tier יקר גם אם המידע נמצא ב Tier נמוך.

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

שירות storage analysis עולה גם הוא כסף, 10 בסנט למליון אובייקטים לחודש

שירות שמוצג בדמו הוא שירות trusted advisor שיודע להראות לנו under utilized EBS volumes. ניתן להשתמש בלמבדה להריץ בדיקה אוטומטית של ווליומים שאינם בשימוש מעל פרק זמן מוגדר מראש.

כשהדגימו כלים של S3 קצת איבדתי ריכוז אבל הכלים נראים יעילים סך הכל

זה הכל להיום, תודה למי שעקב כאן ותודה לצוות Floor 28

כמו תמיד אשמח לפידבק,

ניר מליק

לייב בלוגינג EC2 Image Builder Floor28 webinar

לייב בלוגינג? למה לא, מזמן לא עשינו את זה

הפעם אני בהדרכה של Floor28 על EC2 Image builder, שירות חדש לבניה של גולדן אימג'ז:

מה זה בכלל גולדן אימג'?

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

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

  1. אנחנו רואים שהרבה לקוחות מתקשים לבנות ולנהל אימג'ים טובים – חוסר בידע ומשאבים
  2. יש חברות שיש להן ידע אבל בוחורות שלא לתחזק מערכות אוטומציה לצרכים כאלו לצד מערכות Ci/CD שכבר יש להן
  3. קושי בבדיקת אימג'ים לפני עליה לאוויר
  4. השפעה קשה על פרודקשן אם מפספסים תקלות לפני שימוש באימג' חדש

מה הלקוחות ביקשו?

  1. לקוחות ביקשו מאמזון שירות אוטומטי לבניה של אימג'ים שלא יידרוש שימוש בקוד
  2. ביקשו להשתמש ביכולות של אמזון לבדיקות אוטומטיות של אימג'ים
  3. אימג'ים בטוחים לפי סטנדרטים מקובלים בתעשיה ויכולת להוסיף סטנדרטים ספיציים ללקוחות לפי תחום העיסוק שלהם
  4. הפצה של אימג'ים בין חשבונות ובין ריג'נים
  5. יכולת לבנות ולהתשמת באימג'ים האלו גם On-Prem

אז מה זה השירות החדש?

  1. שירות אוטומציה מבוסס GUI
  2. יכולת בדיקות
  3. שיפור זמני uptime

השירות תומך גם בווידוז 212R2 ומעלה וגם בלינוקס ובכל הפצה של לינוקס שנתמכת ב AWS

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

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

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

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

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

מן הסתם צריך לתת לשירות עצמו הרשאות IAM כדי שיוכל לרוץ בעצמו

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

צריך להגדיר דיפולט סאבנט וסקיוריטי גרופ (לא חובה)

תהליך בניית האימג' כולל כמובן לוגים כדי שנוכל לנתח במקרה של כשלון בבניה של אימג'

אפשר לקשר את שירות הפצת הרשיונות שלנו לתהליך בנית האימג' אם יש לנו צורך כזה ברקע מי שמבצע את התהליך זה SSM או Systems Manager ככה שאפשר לראות דרכו את תהליך הבניה עצמו

זהו, סיימנו, סה"כ די straight forward וברור

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

זוכרים שבפוסט הקודם שלי הזכרתי את ה Snowball Edge החדש? אם כן אז אתם בטח זוכרים גם שאמרתי שזו דוגמא לאפשרות לגשר על הפער בין חדר השרתים והענן, בין המחשוב המקומי ומחשוב הציבורי המבוזר. מסתבר שמאוחר יותר באותו היום ממש שפרסמתי את הפוסט, אמזון הכריזו גם על מוצר חדש בעל השם המלחיץ AWS Outposts. אמזון נכנסת חזק אל המחשוב המקומי ומאפשרת שתי חלופות, הראשונה למי שרוצה להשתמש בשכבת הניהול של VMware והשניה מיועדת למי שרוצה חווית ניהול זהה לניהול AWS בענן הציבורי.   ההכרזה הזו היא תזכורת לכמה דברים, הראשון הוא שהמחשוב המקומי לא מת, יש עדיין סיבות טובות להחזיק חדרי שרתים והשניה היא שהענן הוא לא רק "להיפטר מהברזלים" אלא גם מודל תפעול ותמחור, הטמעה של פתרון ענן פרטי מנוהל מאפשרת ללקוחות לצרוך שירותי מחשוב במודל ענן וזה אמור להיות החלק המעניין, לא איפה הCPU רץ אלא איך צורכים את משאבי ה CPU, איך משלמים עליהם, איך מתחזקים אותם ואיך מקבלים עוד מהם אם צריך.

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

שימו לב להגדרה של Amazon ל serverless

" Serverless is the native architecture of the cloud that enables you to shift more of your operational responsibilities to AWS"

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

וורדלי מביא כאן הגדרה רחבה יותר:

an event driven, utility based, stateless, code execution environment

event driven – מבוססת אירועים, אין שרת שעומד ברקע ומקשיב, יש משהו שגורם לחתיכת הקוד שלנו לרוץ באופן יזום

utility based – אנחנו משלמים רק על מה שאנחנו צורכים

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

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

Data mobility – Mark Watney, Homeland security and Dolores Abernathy

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

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

rurecieving

קרדיט תמלול

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

השבוע אני במרתון של העונה השנייה של ווסטוורלד. לדעתי הסדרה היא יצירת מופת ואני מאד מקווה שהיא לא תלך לאיבוד כמו שקרה לסדרה אבודים בזמנו. פתאום, באמצע פרק 4, זה קפץ לי לראש, הקשר בין מט דיימון, זיהוי פנים ודולורס היפה. צוות ה IT של דלוס לא דאגו לגיבוי Off Site כמו שצריך ובעצם כל עלילת העונה השנייה מתאפשרת רק בגלל שהם דחפו את כל המידע הקריטי שלהם אל הראש של אבא של דולורס, Old man Peter Abernathy, זו הסיבה היחידה שבעצם QA לא מכסחים את כל האתר בכוח (מעניין שדווקא QA הם כוח השיטור והאכיפה).

אחד האתגרים הכי גדולים בעולם ה IT היום הוא Data Mobility. הפיזיקה ולמעשה גם הגיאוגרפיה עדיין מערימות קשיים על היכול להזיז מידע בין נקודת היצירה שלו, נקודת העיבוד שלו ונקודת הצריכה שלו. בעולם ה IoT יש ניסיון להעביר לפחות חלק ממשימות העיבוד אל הקצה, אל המצלמות\רגשים עצמם כדי להתגבר על הצורך להעביר מידע מעשרות, מאות ולפעמים אלפי נקודות קצה אל מערכת מרכזית. בעולם מחשוב הענן לעומת זאת, הבעיה של Data Mobility הפתיעה חלק מהמשתמשים. נראה שבראשית ימי הענן אף אחד לא חשב שיום אחד יהיה צורך לצאת מהענן או לעבור בין ענן אחד לשני או אפילו, כמו שהזכרתי בנוגע למערכת זיהוי הפנים, לבצע תהליך שכולל שלושה ספקי ענן שונים בו זמנית.

כשאנחנו מתחברים אל מערכת הניהול שלנו באמזון למשל, אנחנו יכולים להקים כמה עשרות שרתים כמה קליקים של עכבר. בעולמות של קונטיינרים אנחנו יודעים להרים כמה אלפי קונטיינרים בכמה שורות פקודה. מחשוב, Compute, בענן זה בדרך כלל באמת קל וזריז כמו שמספרים לנו. אבל מידע זה אחרת. כמה זמן ייקח להעביר 10 טרה אל הסביבה שהקמת באמזון? כמה זמן ייקח להעביר 100 טרה? כמה זמן ייקח להעביר פטה? כמה יעלה לכם להעביר 350 טרה מאמזון אל גוגל? כמה יעלה לכם להעביר 200 טרה מאז'ור אל חדר השרתים שלכם בחזרה? אתם יודעים בכלל איך לעשות זה?

INFINIDAT Neutrix

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

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

AWS SLA

ואותו הדבר גם ב Azure:

azure sla

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

aws latency

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

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

grego

שלכם כרגיל,

ניר מליק

 

גיוסים, הכרזות ואירועי ירי

חדשות INFINIDAT

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

החדשות על הגיוס היו די מרעישות ולכן יכול להיות שחלקכם פספסתם את ההכרזה שלנו על מוצר חדש, Infinidat Backup Appliance או בשם חיבה, IBA. שוק המערכות הייעודיות לגיבוי לדיסק נשלט כבר כמה שנים על ידי DataDomain. בימי LTO-5 הרעיון של גיבוי לדיסק היה מהפכני, לא פחות. הסלוגן שלהם באותם ימים היה tape is dead ואני לפחות קניתי את זה. אני באמת מאוכזב מההכרזה על LTO-8. ציפיתי מכולנו ליותר. לא ציפיתי להגיע לקלטות של 30TB  לפני שאנחנו מגיעים ל shingled drives.

IBA הוא התרומה שלנו באינפינידט למלחמה בקלטות. פתרון האחסון שלנו, כזכור, עושה שימוש בדיסקים מסוג NL-SAS, וכל החומרה שלנו מבוססת "מוצרי מדף" ולכן אנחנו יכולים להציע מערכת מאד איכותית במחיר מאד תחרותי. אותה תפיסה מאפשרת לנו להציע פתרון מאד אגרסיבי גם לפתרון הbackup target שלנו. הפתרון מתבסס על מערכת ה InfiniBox F4000 שלנו הכוללת כמובן 3 בקרים או כמו שאנחנו קוראים להם Storage Nodes, 240 דיסקים מסוג 6TB NL-SAS, ועוד שלושה בקרים המהווים Dedup Engine או DDE.

המערכת מספקת 1PB נטו, קצב גיבוי של כ 40TB  לשעה (Native), מנגנון  Inline global Dedup העושה שימוש בגודל בלוק משתנה שיספק בפועל 20PB נפח לוגי זמין לשימוש ומגוון פרוטוקולי תקשורת כמו FC (VTL), CIFS, NFS ו OST.

IBA4260

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

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

בשימוש פרוטוקולים פתוחים הפתרון מתאים כמובן לשימוש על ידי כמעט כל תכנת גיבוי שקיימת בשוק היום, כמו שהזכרתי בעבר, אני אוהב את העובדה שאנחנו היצרן הראשון שעשה שימוש ב Open API החדש של Veeam והחל מגרסה 10 שלהם, ניתן מתוך ה GUI שלהם להגדיר, עבור מערכות האחסון שלנו, משימות Data protection שלנו כולל סנפשוטים, רפליקציה, הקמת virtual labs או sandbox וכמובן, עם הכרזת ה IBA, גם להגדיר ולהשתמש ב IBA כ target.

זו לא האינטגרציה היחידה כמובן והזכרתי מוקדם יותר את התמיכה ב OST לאינטגרציה עם Veritas NetBackup, יש תמיכה ב Oracle RMAN ועוד כל מני goodies.  בקיצור, אם אתם מחפשים פתרון גיבוי לדיסק איכותי במחיר תחרותי, אני כאן.

NetApp Insight Las Vegas

עם מעבר הדירה, החגים, העבודה ועוד כל מני תירוצים אחרים, אני מודה שלא הספקתי לעבור מספיק לעומק על ההכרזות של NetApp בכנס הטכני השנתי שלהם, Insight ב Vegas. אחד הדברים שכן הספקתי לראות זו ההכרזה המרשימה שלהם על כך שמנוע ה NFS של Azure מתבסס על ה NFS  של NetApp, הכרזה שמעידה לדעתי על כוח גדול בשוק ועל העובדה שנטאפ היא אכן לא רק יצרן אחסון ומי שהספיד אותה בשנים האחרונות מאד נחפז לעשות זאת. בדומה לשירות ה cloud sync שלהם, מדובר בשירות שלא נמכר כלל על ידי netApp אלא רק על ידי ספק השירות, מיקרוסופט במקרה של שירותי ה NFS או AWS במקרה של cloud sync.   ראיתי גם שיש עכשיו תמיכה ב snap mirror עבור SolidFire וה DataFabric שלהם הולך ומתעבה.

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

כמה מחריד היה לראות את הפיד בטוויטר (מי שלא עוקב אחרי עדיין מוזמן לעשות את זה ב @maliknir) מתחלף מצהלות השמחה של כל מי שעד לא מזמן היה שותף שלי ב A-Team לציוצי דאגה ופחד, פיגוע הירי המטורף היה באותו המלון בו נערך הכנס ולמרות שהבלוג הזה רחוק מלהיות בלוג פוליטי, קשה לי עם העובדה שהאמריקאים לא קוראים לאירוע הזה פיגוע ולא חושבים שצריך לעשות משהו עם חוקי הנשק ההזויים שלהם. נכון שחוקים נוקשים לא יכולים למנוע 100% משום דבר אבל זה לא אומר שלא צריך לנסות וכמות אירועי הירי ההמוניים שלהם היא הזויה.

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

גלאי הצפה

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

בולגוגי ובי בים באפ

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

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

 

שלכם,

ניר מליק

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 ואני מהמר גם שרוב הפורטים בעולם עוד לא עברו הסבה והנה זו כבר טכנולוגיה של פעם, די מדהים.

 

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

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

שלכם תמיד,

ניר מליק

Stratoscale – on-premises AWS service

לאחרונה נתקלתי דרך הפיד של Eric Wright בציוץ של Brent Beshore. הציוץ המקורי כולל תמונה של דף מתוך ספר והכותרת היא The generalized uncertainty principal. הספר כבר לא מעודכן עד הסוף כי למשל בניין ההרכבה של NASA כבר אינו הבניין הכי גדול בעולם אלא רק אחד מארבע הגדולים ביותר אבל העקרון המוצג כמובן עדיין נכון ועדיין מאד מעניין: כאשר מתכננים מערכות גדולות ומורכבות, רמת המורכבות עולה באופן משמעותי, לא כל מה שעבר במודל המוקטן יעבוד באותה הצורה במערכת הגדולה. הדוגמאות שהם נותנים כאן די מגניבות:

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

law-of-unintended-consequences-with-complex-systems-at-scale-brent-beshore-eric-wright

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

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

ללקוחות כאלו פתרון Stratoscale מספק מענה איכותי על מנת לשמר את רמת השירות שמקבלים משתמשי הקצה תוך שיפור משמעותי של הכלים העומדים בפני מחלקות ה IT. בסופו של יום זה הרי מודל ה DevOps הקלאסי, משם התחלנו את הטרנד הזה, אנשי ה Ops מתקינים תשתית רובסטית ככל הניתן, אנשי ה Dev צורכים אותה באופן חלק ושקוף ככל הניתן, וכולם עובדים ביוחד באופן רציף כדי לצפות את הצרכים ולתכנן מראש את התהליכים ההדדיים.

startogeneral-view

פתרון Stratoscale מבוסס על תשתיות KVM על מנת לספק את שכבת הוירטואליזציה הבסיסית ומעל לשכבה זו מורכבים מראש ממשקי הניהול והבקרה כולל ממשקי Heat Map ברורים לאיתור עומסים ובעיות.

stratodash

stratoheat

stratostormanag

המערכת מספקת גם יכולות וירטאליזציה של תקשורת כלומר פתרון מתחרה לעולמות ה NSX/ACI כולל מיפוי ויזואלי מאד יפה של הקישורים והקשרים

stratonetworkפורטל ה App Store כולל קישור ישיר להורדה של אפליקציות נפוצות וניתן להתאים את התצוגה על פי הרשאות המשתמשים כולל גם היכולת לבצע התאמה מראש של האפליקציה לטמפלט ארגוני. כמובן שניתן להוסיף ל App Store גם אפליקציות שאינן מובנות בו מראש או אפליקציות פנים ארגוניות.

strato-appהפתרון כולל באופן מובנה יכולות software defined storage על מנת לאפשר את היישום שלו על פני כל פתרון אחסון כולל דיסקים מובנים בשרתים עצמם (בהתאם לטרנד של HCI) וכמות נכבדת של ממשקי API לניצול יכולות מערכות אחסון רבות כמו למשל ניהול יכולות ה Array Snap shot או יכולות רפליקציה מבוססות מערכת האחסון.

stratostormanag

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

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

שלכם,

ניר מליק