תגית: AWS

Live Blogging remotely – Nutanix .Next

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

https://www.nutanix.com/next/on-demand-ty#inline6373619250112

בשנה שעברה לא נסעתי לכנס .Next בברצלונה כי הייתי באותו שבוע בהופעה של טיילור סוויפט עם הבת שלי, סיפרתי לכם על זה כאן.

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

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

נראה כמה זמן אחזיק מול המסך.

לדעתי אמורים להיות שם מעל 4000 איש!

על הבמה מנדי דאליוול, מנהלת השיוק העולמית של נוטניקס כדי לפתוח רשמית את האירוע. היא מעדכנת שיש בכנס מעל 5000 איש ולא 4000 כמו שניחשתי, וואוו!

רשימת הספונסרים שהיא מקריאה מאד מרשימה, שימו לב במיוחד לאומניסה ולPure Storage!

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

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

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

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

עכשיו רג'יב שואל את הקהל באיזה עוד מערכות אחסון הם היו רוצים שנתמוך ומכריז רשמית שנתמוך גם ב Pure Storage! כבר בקיץ הקרוב נאפשר גישה ל Early Access ועד סוף השנה נשיק תמיכה רשמית.

Flash Stack with Nutanix הוא פתרון מאוחד לנוטקניס, סיסקו עם שרתי הלהב שלהם UCS ועם מערכות האחסון של Pure.

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

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

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

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

בית חולים צף שמכיל מעל 1000 מיטות המשיך לתת שירות ללא כל תקלה אפילו כחלק מהשרתים נרטבו במי ים כמו שקורה לפעמים על ספינות, mission critical resiliency למקסימום.

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

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

כמובן שהוא מזכיר את ההכרזה האחרונה על תמיכה ב GCP לפתרונות NC2.

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

ההכרזה על NKP היא חלק מהחזון שנקרא project beacon, לאפשר לפתח אפליקציה פעם אחת ולהריץ אותה בכל מקום שנדרש על כל פלטפורמה שצריך. כהמשך לחזון הזה, AOS יהיה גם AWS Cloud Native. עכשיו נוכל לספק את שירותי האחסון של נוטניקס ללא חובה להריץ שרתי Bare Metal יקרים בענן. בשלב מאוחר יותר נוכל להריץ את AOS אפילו על שרתי Bare Metal בחדרי השרתים של הלקוחות בלי הייפרווייזור, כלומר נוכל לספק את שירותי האחסון שלנו על כל דבר שנצרה ולספק חוויה חלקה וזהה לא משנה איפה האפליקציה שלנו חיה.

מי מכם שפגש אותי בשיחות על AI יודע כמה אני אוהב את Tractor supply כסיפור לקוח. אני אוהב את זה שהם מגדירים את עצמם כחברת rural life style, בלי ספק מאז ההתפוצצות של ילוסטון חלקאות ובקר זה לגמרי לייפסטייל בכל העולם. עכשיו הם מספרים על הבמה איך כל אחד מ 52,000 העובדים שלהם מקושר ל GenAI ארגוני להאיץ ולייעל תהליכים באופן חוצה ארגון.

אחרי שהשקנו את GPT-in-a-Box לפני שנתיים ושנה שעברה את NAI, שניהם התמקדו בעיקר ב LLM, עכשיו השירות מספק agentic AI מלא כחבילה אחת. reasoning, guardrails, פלטרפומה מלאה ומקיפה גם הודות לשת"פ עם NVIDIA.

עד כאן רג'יב להיום.

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

אני אעצור את הלייב כאן ברשומתכם מקווה שהיה מעניין!

בברכת בשורות טובות,

שישובו כל החטופים והחטופות במהרה אמן וכל החיילים והחיילות בריאים ושלמים!

שלכם כרגיל,

ניר מליק

9-1-1, BCP & GCP

Disney+ 9-1-1 זה בית ספר לBCP?

בזמן האחרון אני צופה בדיסני+ בסדרת מכבי אש בשם 9-1-1,הגעתי אליה דרך קליפים קצרים בyoutube shorts ומשחקת בה ג'ניפר לאב היואיט האהובה משולחן לחמישה (כולנו זקנים מספיק כאן בשביל לזכור את שרה משולחן לחמישה?)

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

אז זהירות ספויילר אם אתם צופים כמוני 😊

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

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

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

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

ענן חדש בא לשכונה

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

ההכרזה הזו של GCP כוללת בתוכה גם הכרזה על השת"פ הבא של גוגל ושלנו ובקרוב נוכל להשתמש בשרתי ה bare metal החדשים על מנת לספק עליהם את שירות ה NC2 שלנו ולהשלים את "שלושת הגדולים". אני לא חושב שיצא לי לכתוב על NC2 בצורה מסודרת כאן עד היום אז שווה להזכיר, NC2 זו היכולת לפרוס את כלל שכבת התוכנה של Nutanix על גבי שרתים יעודיים בסביבת הענן הנבחרת על ידי הלקוח, AWS, Azure וכאמור בקרוב מאד GCP. ההטמעה נעשית בתוך החשבון של הלקוח, בתוך הפרוייקט ותלוי בבחירת הלקוח יכולה להעשות בתוך ה VPC/VNET של הלקוח. את הרישוי הנדרש ניתן לרכוש ישירות דרך ה App Store/Market Place או לחלופין דרך שותף הנוטקניס האהוב עליכם במודל Bring Your Own ומרבית הרשיונות הקיימים הם Portable כלומר ניתן לשמר השקעה ו"לקחת" רשיונות קיימים איתכם לענן.

NC2 מאפשר את העליה המהירה ביותר לענן הציבורי מכל פתרון אחר, אותם כלים, אותן יכולות, אותם נהלים והגדרות, רק בענן ובקרוב מאד בכל העננים, זו התשתית האמיתית ל Hybrid Multi Cloud כולל כמובן לנייד עומסי עבודה באופן מהיר בין הענן הפרטי והענן הציבורי, התממשקות לסביבות Object שונות לטובת Tiering או DR, ובמרבית המקרים, חסכון עלויות משמעותי בהשוואה בין NC2  ובין IaaS Native.

הסיבה לחסכון הכספי מול EC2  למשל או Compute Engines, היא הגמישות והדחיסות (Density). כשאנחנו צורכים שירותי מחשבו במודל IaaS אנחנו כפופים לגודל ה T Shirt שהספקית בחרה עבורנו והרבה פעמים נאלצים לשלם על זיכרון כדי לקבל מעבד מהיר, על מעבד מהיר כדי לקבל עוד נפח אחסון וכו'. בתשתיות NC2 אנחנו יכולים להגדיר מכונות וירטואליות בהתאם לצרוך האמיתי שלנו ועל ידי זה לבטל את מה שנקרא micro waste, לבטל את כל העודפים האלו שאנחנו משלמים עליהם סתם. איפה שעדיין יש עודפים כאלו, במצב Native אין מה לעשות איתם, ובמודל של NC2 זה "ספייר" שנשאר שלנו במערכת ואפשר באופן דינאמי להקצות אותו למערכות אחרות.

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

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

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

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

פסח מורכב

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

בברכת בשורות טובות,

שישובו כל החטופים והחטופות במהרה אמן וכל החיילים והחיילות בריאים ושלמים!

שלכם כרגיל,

ניר מליק

למה הם עוזבים את הענן?

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

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

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

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

למי הענן כן מתאים לפי הניתוח שלהם? ללקוחות בתחילת דרכם או לקוחות מאד דינאמיים. אם אתם לקוח שרק מתחיל, שאולי עוד אין לכם אפילו לקוחות, הענן הוא הדרך הכי מהירה ולהתניע וגם אם זה יותר יקר לכל ג'יגה אחסון ופעימת מעבד, זה לא משנה, העיקר להתניע. אם אתם לקוח מאד דינאמי, למשל אתר מסחר שב Black Friday או Cyber Monday מכפיל בסדר גודל את היקף התנועה שלו, אין כמו הענן לאפשר את הדינאמיות הזו. אפילו עבור Hey עצמם הם אומרים, זה היה מהותי מאד בתחילת הדרך, כשהם ציפו לשלושים אלף משתמשים בשישה חודשים ובפועל הגיעו לשלוש מאות אלף משתמשים בשלושה שבועות אבל היום, כשהעומס והגידול צפויים, הענן הרבה יותר יקר ולא מספק יתרונות מספיק מהותיים.

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

טיעון משמעותי נוסף שהם טוענים הוא טיעון השרידות והגמישות. עם כל הכבוד לתשתיות הענן החסונות, הם אומרים, כאשר US-East-1 של אמזון נופל, חצי מהאינטרנט נופל איתו, זו לא הרשת המבוזרת אותה תכננו בDARPA הם טוענים ושוב הם קצת הולכים לאיבוד עם טיעונים רומנטיים שלא רק שהרשת צריכה להיות מבוזרת אלא גם שהם מעדיפים לשלם את הכסף שלהם לחברות קטנות כמוהם ושבחברה גדולה כמו אמזון או גוגל אפילו שהם משלמים מיליונים כל שנה אף אחד לא סופר אותם ולה עונה להם לטלפון. אם לך כלקוח שלנו ה Hey, הם אומרים, יש בעיה, כל החברה מתגייסת לעזור וזה יגיע מהר מאד גם לרמה שלנו המנהלים הכי בכירים. זו טענה מוזרה משני הכיוונים, ראשית כי אני מכיר את מערכי התמיכה של ספקיות הענן, אתה לא באמת לבד אם יש לך בעיה שם, ושנית כי זו לא חכמה להשוות חברה קטנה\בינונית וחברה ענקית, אם Hey יום אחד תגיע לקנה המידה של ג'ימייל, הרי גם אם דיויד וארון ירצו הם לא יהיו מסוגלים להתערב בכל קריאת שירות וכל תקלה ללקוח, גם אם הוא לקוח בינוני שמשלם להם מיליונים.

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

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

שלכם,

ניר מליק

מחשבות על AWS Virtual SAN

בסוף 2020, במסגרת re:invent, החברים באמזון השיקו סוגי דיסקים חדשים. הדיסק הכי מהיר בהיצע שלהם io2 block express שעליו כתבתי בלינקדאין וגם דיסק לשימוש כללי בשם GP3 עליו כתבתי כאן בבלוג של החברים שלי בסילק.  

בדיוק לפני שנה, בינואר 2021, הזכרתי ממש כאן בפוסט הזה את שני הפוסטים הקודמים שציינתי למעלה ותיארתי בקצרה את אחד האתגרים הטכניים להם אין מענה איכותי מובנה בפלטפורמות הענן וספציפית התייחסתי לאתגר בהעברת אפליקציות Enterprise Tier-1 אל הענן, אפליקציות המקבלות בחדר השרתים שלנו שירות ממערכת SAN המספקת מענה איכותי ויציב לעשרות או מאות טרה של מידע ולעשרות או מאות אלפי IOPS בזמני תגובה קצרים וקבועים.

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

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

בפוסט שפורסם מוקדם יותר החודש, AWS חשפה ארכיטקטורה קרובה. הפוסט מתאר שימוש בשרתי R5b לייצוג "בקרים" וה"בקרים" מקושרים למספר דיסקי io2 block express. ניתן להעלות ולהוריד באופן דינאמי את כמות ה"בקרים" בהתאם לדרישת הביצועים ויש תמיכה בפיצ'רים כמו EBS Snapshot או AWS Backup. גולת הכותרת היא כמובן ביצועים והם מדברים על עד מיליון IOPS בתצורה של 5 "בקרים" או חמישה מליון IOPS בתצורה של 8 "בקרים". אלו מספרים מאד מרשימים והם מלווים גם בעשרה עד ארבעים ג'יגה רוחב פס! נשאלת השאלה כמובן למה הגידול לא לינארי (אימוג'י של פרצוף חושב) ?

בכל מקרה כמובן שפתרונות יעודיים כמו סילק או פיור מוסיפים יכולות מתקדמות ומרשימות כמו יכולות של חסכון בנפח, סנפשוטים יעילים יותר, Thin Provisioning וכו' אבל השאלה היא עד מתי היתרונות האלו ישארו יחודיים והאם אמזון תוסיף יכולות כדוגמאת deduplication או Compression שקצת נוגדים את המודל הכלכלי של "הענן" שנשען כולו על Over provisioning?

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

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

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

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

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

image credit:By Whit Welles Wwelles14 – Own work, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=2821387

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

שלכם,

ניר מליק

אמרתי לכם!

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

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

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

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:

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

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

ניר מליק

לייב בלוגינג – 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 וברור

Got Silk?!

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

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

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

אפשר לראות שיש קשר ישיר בין גודל הדיסק ב GB וכמות ביצועי ה IOPS העומדת לרשותו. אפשר לראות בהערות גם שיש כמות ה CPU וכמות ה IOPS בגלל ששרתים עם יותר CPU יכולים לגבל הקצאת תקשורת נדיבה יותר, Network egress caps. משמעות הדברים היא שיתכנו מצבים בהם לקוחות צריכים לשלם על נפח דיסק ריק כדי לקבל יותר משאבי ביצועים ועל מעבדים מיותרים כדי לקבל יותר משאבי תקשורת אל הדיסקים.

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

אמזון קצת יותר מתוחכמים וקצת יותר קרובים למערכות All Flash של העשור האחרון כי הם אומרים ללקוחות שלא צריך לקנות עוד נפח בשביל ביצועים, אפשר לשלם ישירות על הביצועים. הם קוראים לזה Provisioned IOPS (io1), הלקוח במקרה הזה צריך לשלם פרמיה גם על הנפח וגם על הביצועים אבל לא צריך לשלם על "נפח ריק".

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

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

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

כלי שימושי נוסף שאנחנו מאפשרים ללקוחות הוא סנפשוטים רזים. תהליך יצירת סנפשוט בענן הוא תהליך ארוך ויקר. ב AWS למשל, בתהליך יצירת הסנפשוט מועתק המידע אל S3 ובכל סנפשוט נוסף יש להעתיק מידע נוסף, את המידע החדש. אנחנו מאפשרים ליצור סנפשוטים מידיים, מבוססי הצבעות בלבד, כך שאין צורך להזיז מידע או לשלם על נפח מידע נוסף ולכל סנפשוט ניתן לייצר View כלומר להשתמש בסנפשוט כהעתק עצמאי של המידע לשרתים אחרים, test/dev או אנליטיקה וכו'.

אנחנו רואים בבמוצע חסכון של 3:1 בשימוש ביכולות חסכון בנפח ולפחות עוד 30% חסכון על ידי שימוש בThin Provisioning וזה אומר שרק על ידי זה שריכזנו את המידע של הלקוח והכלנו עליו את היכולות האלו, הלקוח צורך עכשיו פחות מרבע מהנפח שהוא צרך קודם ובגלל שאנחנו לא נסנכים על ביצועי הדיסקים של תשתית הענן הרבע הזה הוא בדיסקים זולים יותר מהדיסקים הקודמים!

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

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

עדכון לפוסט!

כמו מהשמים שלחו לי לינק לסרטון הזה היום, החל מדקה 16:54 בערך אפשר לראות בדיוק כמה מורכבות האופציות לבחירת דיסקים ב AWS והתאמת ה EC2 instance לבחירה שלכם.

כבונוס, יש שם הדגמה של יכולות של blktrace. ביחד עם blkparse, btt ועוד סקריפט פייטון קטן (כן כן הרבה חלקים זזים) אפשר ממש להציג באופן קריא ונוח עד כמה ה IO שהשרת שלכם עושה הוא Sequential או Random, נתון שהרבה פעמים חסר לנו כשאנחנו באים לעשות סייזינג מסודר למערכות סטורג', אם אתם מאלו שעוד עושים כאלו דברים 🙂

credit AWS: https://youtu.be/wsMWANWNoqQ
credit AWS: https://youtu.be/wsMWANWNoqQ

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

שלכם,

ניר מליק

מפריז הביתה

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

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

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

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

https://www.cloudshare.com/blog/the-big-share-a-qa-with-technical-sales-leader-and-remote-veteran-nir-malik

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

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

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

SAS זה בעצם ראשי תיבות של Serial Attached SCSI והפרוטוקול הזו הוא המקשר בקשר point to point בין יחידות המחשוב שלנו לדיסקים. אחד הדברים המתאפשרים לנו עם זה להציג את אותה המדיה לכמה יחידות מחשוב ובכך לנתק את הקשר הישיר ביניהם. עכשיו ניתן לנתק את הקשר הגורדי הזה ובכך לאפשר הרבה יותר גמישות במבנה מערכת האחסון, ניתן להגדיל את המערכת בנפח אחסון (scale up) או בכוח מחשוב (scale out) באופן הרבה יותר גמיש מאי פעם. אם מערכות scale out קלאסיות מחייבות להגדיל גם את נפח האחסון לצד כוח המחשוב ויחידות האחסון מקושרות פיזית ליחידות מחשוב ספציפיות, עכשיו אפשר נגיד לחבר שמונה יחידות מחשוב לאותה יחידת אחסון.

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

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

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

ניר מליק

Mini Post – VMware HCX

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

הכלי כולל בתוכו שלוש תכונות עיקריות:

  1. מיגרציה מסביבות שאינן סביבות ESXi – הכלי יאפשר להסב מכונות מסביבות KVM+ Hyper-V אל סביבות ESXi ובעתיד יאפשר גם להסב מכונות מסביבות נוספות
  2. ניהול של משימות vMotion תוך הוספה של האצה ומקביליות או מה שהם קוראים עכשיו replication assisted vMotion ככה שאפשר לבצע ניוד של מספר רב של מכונות על פני מרחקים גדולים יותר (תחשבו ESXi Over AWS)
  3. התממשקות אל VMware SRM כך ש HCX מהווה שכבת הטרנספורט עבור SRM ומוסיף יכולות של wan optimization, הצפנה וכו'

לקריאה נוספת יש כאן את ה FAQ ואם אתם בעניין אז בקישור מטה תמצאו גם את הפרק הרלוונטי של vSpeaking והפעם עם איימי לואיס הלא היא @CommsNinja

https://www.vspeakingpodcast.com/episodes/125

למתקדמים יש אפילו דמו עם hands On Lab

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

ניר מליק