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

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

ניר מליק

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

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

זה הכל להפעם,

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

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

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

ניר מליק

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

שלכם כרגיל,

ניר מליק

 

אני כל כך עייף!

למה אני עייף?

מהיום שהיא נולדה, לבת שלי יש גלאי מובנה לאיכות השינה שלי.

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

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

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

על חשיבותם של בלוגים

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

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

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

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

ענן או לא, עדיין צריך שרתים, והרבה

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

no cloud

VMworld

שבועיים אחרי האח הגדול בוגאס, השבוע התקיים VMworld EMEA בעיר הנהדרת ברצלונה אבל אותי השאירו בבית אז אני לא מפרגן לאף אחד שנסע! VMware ממשיכה במהלך לגישור בין תשתיות ה On Premises לסביבות הענן ומכריזה על היכולת להריץ אפליקציות באופן חלק על שכבת וירטואליזציה גמישה באתר הלקוח, בענן הפרטי, הענן הציבורי או AWS וכם מעמיקה את יכולות אבטחת מידע שלה, צעד 2 הינו צעד חובה בשביל צעד 1, VMware בונה גשר ועושה מאמץ שלא להשאיר רווחים לאחרים להכנס בינה לבין הספקיות.

***עריכה***

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

 אפל

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

פנסים סולאריים

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

led

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

שלכם תמיד,

ניר מליק

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

 

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

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

שלכם תמיד,

ניר מליק

VMware VMworld 2016 roundup

ואוו איזה שפע, מאיפה מתחילים?

בשבוע שעבר התקיים VMworld Barcelona ובניגוד לשנים קודמות, האירוע של EMEA  לא היה רק שידור חוזר של האירוע האמריקאי אלא כלל שפע של הכרזות ולקראתו הוכרז גם שיתוף הפעולה האסטרטגי בין VMware לספקית מחשוב הענן הגדולה בעולם, Amazon (כולל היכולת למתוח את רשת התקשורת אל הענן הציבורי באמצעות NSX!)

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

אז צוללים קדימה:

VSAN

שני חידושים משמעותיים בגרסה 6.5 של מוצר SDS זה:

Virtual SAN iSCSI Service – אחד החסמים העיקריים לשימוש בפתרונות HCI הוא החשש מפני "גן סגור" היות ופתרונות אלו נוטים לשרת רק את עצמם. שירות ה iSCSI החדש של VSAN מאפשר לספק שירות Block storage גם לשרתים שאינם חלק מסביבת ה VMware עליה פעיל שירות ה VSAN ובכך נפרצת חומת הגן. מנגנון הניהול הינו אותו מנגנון ניהול ומבחינתו פשוט נוצר אובייקט חדש שמוצג החוצה ב LUN + iSCSI Target.

2-node direct connect – כבר בגרסה קודמת הוכרזה תמיכה בכמות מינימאלית של 2 שרתים בסביבת VSAN ועכשיו תצורה זו נתמכת גם בקישור 10Gb ישיר בין שרתי ה Host. תצורה זו מורידה עוד יותר את סף הכניסה וחוסכת בעלויות הפתרון המינימאלי הנתמך.

מבחינת רישוי, פתרון All Flash VSAN נתמך גם בגרסת רישוי Standard כך שמי שצריך ביצועים גבוהים אך לא חייב פיצ'רים מתקדמים יכול להסתפק ברישוי הפשוט יותר, שוב, סף כניסה נמוך יותר. נראה ש VMware עושה הרבה מאמץ להפוך את המוצר ל commodity.

vSphere 6.5 והתשתית שמתחת

VMFS 6.5 – תמיכה ב auto space reclamation – יכולת חדשה הנשענת על VAAI הישן והטוב וספציפית על VAAI UNMAP – בלוקים פנויים משוחררים עכשיו באופן אוטומטי למערך האחסון לשימוש על ידי volume אחרים

HA high availability – גרסה זו כוללת שיפורים משמעותיים בניהול ההתאוששות – ראשית, שיפור ביכולת לתעדף את סדר עליית שרתים הוירטואליים במקרה של HA ועכשיו ניתן לגם לסמן ששרתים בעדיפות נמוכה ימתינו לקבל hart beat מהשרתים שכבר עלו בעדיפות ראשונה או אפילו ימתינו לקבל hart beat מאפליקציה ספציפית.  יכולת זו מורחבת עוד יותר על ידי יכולת אורקסטרציה מובנית לתהליכי HA שם אנחנו יכולים לסמן קבוצות שתרים כתלויות אחת של השניה, אם שרתי אפליקציה תלויים בשרתי DB אז ניתן לקשור אותם ספציפית אחד לשני.

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

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

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

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

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

אשמח לשמוע מה דעתכם, תרגישו חופשי.

שלכם,

ניר מליק