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

זמינות

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

זה הכל להפעם,

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

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

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

ניר מליק

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

RPO Zero from downunder

RPO Zero from downunder

הפוסט הקודם נכתב מיפן, התחנה הראשונה בסיבוב של שבועיים שכללו את טוקיו, סידני, מלבורן ובריסביין. הנסיעה כולה תוכננה סביב כנס גרטנר בסידני (השם המלא של האירוע הוא IT Infrastructure, Operations Management and Data Center Summit אבל אף אחד לא משתמש בו) במסגרתו הרציתי על הפתרונות החדשים שהשקנו לאחרונה ביניהם דגם חדש למערכת האחסון הראשית שלנו, F6212 המספקת מעל 4PB נטו בארון אחד, מערכת ייעודית לגיבוי, אותה הזכרתי בקצרה בפוסט קודם אבל מאז הוכרזה רשמית וקיבלה את השם InfiniGuard, פתרון אחסון סמוך-ענן שנקרא Neutrix שאפרט עליו בפעם הבאה והפתרון עליו אני רוצה לפרט קצת היום, פתרון רפליקציה המספק RPO-0 ללא תלות במרחק או רוחב פס בשם InfiniSync.

 

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

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

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

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

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

פתרון InfiniSync בא לגשר על הפער בין הפשטות היחסית של רפליקציה א-סינכרונית ורמת ההגנה של רפליקציה סינכרונית. הוא בא להחליף את הצורף ב Bunker site ולאפשר ללקוח לבצע רפליקציה א-סינכרונית בלבד אל האתר המרוחק מבלי לוותר על רמת ההגנה.

מה שעשינו זה לבנות מערכת על בסיס העקרונות של קופסא שחורה, כמו במטוסים, מערכת מחשוב מוקשחת הכוללת דיסקים מקומיים מבוססי SSD, סוללה פנימית, אנטנת Wi-Fi ומודם סלולרי עצמאי. המערכת בנויה בתוך קופסא קשיחה העמידה, עטופה בציפוי מבודד המגן מפני אש וחום ומוכלת בתוך כלוב המגן מפני רעידות. המערכת נבדקה ומאושרת לעמידה בעומס משקל של 2.2 טון, אש ישירה בטמפרטורה של 945 מעלות מעל שעה, חום ישיר בטמפרטורה של 260 מעלות מעל חמש שעות, נפילה מגובה 5 מטר, רעידות של 50Hz ו 1.6G, אטומה למים בעומק עד 3 מטרים ואפילו חסינה מפני חדירה של מוט חודר (תמיד בסרטי אסונות מישהו משתפד על עמוד במקרה של רעידת אדמה או תאונה).

 

Showdown_in_Mega_City_Trinity_Death

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

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

ininisync

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

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

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

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

 

שלכם,

ניר מליק