יום חמישי, 25 ביולי 2019

372 Zadara

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

הפרק בחסות Dropbox, שהם גם ספונסרים של Reversim Summit 2019 (כבר יש וידאו, ותמונות וסיכום…)

יאיר, נשוי + 3 מאלוני אבא, בתחום האחסון כבר ~20 שנה - 
  • תואר במדעי המחשב בטכניון ומשם התחלה בעולם האחסון, תחילה בחברה בשם StoreAge (שעסקה ב - Storage virtualization). 
  • ב-2006 החברה נרכשה ע”י LSI (שהתחילה בתוך הטכניון ומשם עברה לעיירת הקייט הציורית נשר). ויאיר המשיך כמפתח-ראש צוות-מנהל פיתוח.
  • ב-2010 החטיבה נמכרה ל- NetApp וכולם הלכו הביתה (הלינק היום בכלל הולך לאתר של Broadcom). יאיר, יחד עם המנכ”ל וה-CTO הלכו להקים משהו חדש. 

אז Zadara קמה בתאריך העברי ז’ באדר א’ , ומשם הגיע השם Z Adar A . . . 
  • זהו תאריך חשוב במסורת היהודית - תאריך הולדתו ופטירתו של משה רבנו. 
  • השנה היא כבר 2011 - יש עננים בחוץ, Cluodera כבר תפוס, CloudAge פחות תופס . . . Zadara it is.
  • אז מה חסר עכשיו בעולם? נראה שיש פער בין יכולות האחסון שקיימות ב - Data Centers של הארגון הטיפוסי (מבוססי IBM ו-EMC וכו’), לבין מה שקיים בענן הציבורי (Public Cloud), שב-2011 זה כמעט רק AWS - ובעיקר S3 ו EBS. אפילו S4 עוד לא היה.
  • גם EBS היה עדיין מאוד בסיסי - Block בלבד, אם אפשרות להגדיר Capacity ודי זהו.
  • נראה היה שה-Storage מהווה את אחד החסמים העיקריים של ארגונים לעבוד לענן.
    • מערכות האחסון בענן לא היו ברמה הנדרשת, וארגונים שהיו רגילים לביצועים, קיבולת ויכולת התאמות (Customization) ברמה מאוד גבוהה (Lift & Shift, שמצריך שכבת חומרה עם אותן יכולות).
    • מי שכתב את האפליקציה שלו מחדש באותו תקופה (מי אמר Netflix?) כבר כתב אותן לתוך עולם ה-S3 ו - Object Storage, כבר עם Interface אחר - 
      • או מבוסס מכונות “commodity” עם אחסון כללי כלשהו - הנחה בעייתית, שצריכה להכיר בזה שמכונות נופלות (ואיתן הדאטה) כנתון. הגיוני אולי ל-Netflix כ - Cloud Native, פחות לארגון הממוצע.
      • הרבה חברות לא רצו לכתוב מחדש - “פשוט” לקחת את ה - Workload הקיים ולהעביר לענן (משיקולי תקציב בדר”כ, נכונים יותר או פחות). זה נכון עד היום - Lift & Shift של Legacy systems ש”עובדות יפה” ב-Data Center on premise, וצריכות משיקולים כלשהם לעבור לענן.
  • חשוב לשים לב שיש גם את הצד השני - רצון לקחת את ה - Cloud Economics (כל שמגיע כל כך יפה מ - AWS/GCP/Azure) “ולהרוויח” אותם גם On-premise - להפסיק לדאוג ל - Hardware refresh למשל (פחת, מערכת מתיישנת וכו’). 
    • הרעיון של IaaS הוא שהכל הופך לשירות - לא צריך לתכנן מראש, אין חוזים לטווח ארוך אלא רק עלות לפי שימוש בפועל. מי שנותן את השירות נותן הבטחה ל - SLA וזהו.
    • איפה זה פוגש את מי שנמצא בענן ורוצה לעבור ל - On-premise? מערכות ה-Legacy  שאנחנו מכירים היום לא מאפשרות את זה באמת.
  • ב- Zadara מאמינים שעולם הענן קיים גם כ”ענן פרטי”, ורוצים לאפשר ענן כזה - למשל מאפשרים Storage as as service גם ב - Private cloud: מתקינים את המערכת אצל הלקוח, בלי שהוא קונה שום דבר אלא משלם רק עבור שימוש בפועל. Stop buying Storage . . .
  • איך זה עובד ברמה הפרקטית? הרי מישהו צריך ללכת לחבר את הכבלים או לשדרג מדי פעם . . .
    • המערכת בנויה כך שניתן לתפעל הכל מרחוק - שולחים ללקוח את ה - Hardware (שהוא Commodity - שרתים סטנדרטיים של Intel, Cisco, Dell וכו’), והמערכת היא Software Defined Storage. מבקשים Remote Access Permissions ומבצעים את ההתקנה מרחוק.
    • מעיין Data Center מנוהל בתוך ה - Data Center של הלקוח.
  • איך זה עובד בענן? נניח שאנחנו רצים על AWS - איך זה עובד? מכונות של EC2? משהו בחוץ?
    • לא רצים בתוך ה - EC2 אלא בחוץ - מעבר לעלויות (AWS ישמחו כמובן…), Zadara מריצים את “הענן שלהם” (ה - clusters) ב - Data Centers שונים (עם Co-location, למשל Equnix) שנמצאים מאוד קרוב ל - Data Centers של “הגדולים” (Hyper-scale Clouds).
      • מחזיקים כיום מעל 15 Data Centers כאלה בעולם (חוף מערבי ומזרחי של ארה”ב, אירלנד, גרמניה, יפן, סינגפור, קוריאה, אוסטרליה, קנדה . . .), כשבדר”כ החיבור ל-AWS הוא ב - Direct Connect (חיבור פרטי ומאובטח, גם מבחינת Bandwidth, ישירות ל-AWS), עם מודל עסקי שונה (משלם בעיקר “על הקו”, ופחות לפי Traffic in - Traffic out, למעט הגבלות שונות, בעיקר כשיש הרבה Write מה-EC2).
      • אחד היתרונות של היכולת הזו “לרוץ מחוץ לענן” הוא היכולת ל - Multi-cloud solution - על אותה מערכת אחסון / Block File / Object, אפשר לגשת בו זמנית גם מ - AWS, גם מ - GCP גם מ Azure וגם מה - On-Premise.
        • יש פתרון שנקרא Zadara Cloud on-premise, שמאפשר להגיע מה - On-Premise ל - Cloud (ב-Co-location), ומשם לגשת לאחד מספקי הענן לבחירתך: גם Multi-cloud וגם On-Premise עם חיבוריות ביניהם. מאוד מעניין.

חזרה לרגע ל - Basics: הזכרנו מוקדם יותר שני סוגי אחסון ש-AWS הציעו - Block Storage ו - Object Storage. מה הם סוגי ה - Storage הנפוצים באופן כללי, או במילים אחרות - מה Zadara מאפשרת (Features) שלפחות בזמנו AWS לא אפשרו?
  • לגבי Basics - מערכות אחסון מאופיינות בהרבה דברים . . . יש כמה אלמנטים עיקריים - 
    • סוג המדיה - המדיה המוכרת היא Hard  Disk Drives (מאיזור שנות ה-50): פלטות מגנטיות מסתובבות עם ראש קורא, capacity גבוה (14Tb נשמע סביר לגמרי נכון להקלטת הפרק), וביצועים סבירים (כמה ms); סוג נוסף של מדיה הם ה-Solid State Drives (משנות ה-90 פחות או יותר): טכנולוגית Flash, כתיבה וקריאה הרבה יותר מהירות, אין חלקים נעים וביצועים ב Sub-ms.
    • מעבר לזה יש מאפיינים נוספים - Data Protection Layer (ששומר גם על רמה מסויימת של יתירות Redundancy)
    •  יש כל מיני סוגי פרוטוקולים לגישה, וגם כאן העולם התקדם וזה משפיע על Hardware Refresh: אם למשל עברת ממערכת מבוססת SaaS או SATA שהייתה יותר איטית, ועכשיו יש NVMe ו NVMe over-Fabrics שהם פרוטוקולים הרבה יותר מהירים לגישה למדיה שהיא מבוססת Flash (כשיצא ה-Flash, צוואר הבקבוק של האחסון עבר מהמדיה (סיבוב הדיסק) לפרוטוקול, ואז הגיעו ה- PCI ומעל זה את ה - NVMf על מנת להתמודד עם זה…) - לקוחות רוצים לעבור ל-NVMe בלי לשלם יותר, ו - Zadara עושים את ה - Hardware refresh עבורם.
    • רגע, רגע רגע . . .מה זה NVMe? למה זה חשוב?
      • אוקיי - Non-Volatile Memory Extension הוא פרוטוקול שמאפשר לגשת ב-RDMA ישירות אל המדיה. בהפשטה - אפשר “לשים פוינטר” ישירות אל הדיסק, ולהתייחס אל הדיסק כאל זיכרון לא נדיף. זמן גישה? סדרי גודל של עשרות ns, ועבור NVMe Drives מדובר ב-ms בודדות (סדר גודל של כ - x1000 יותר מהר).
      • המדיה הטובה ביותר כיום מגיע משילוב של Micron ו - Intel, ונקראת 3D Xpoint, וזמן הגישה הוא סביב ה -10ms (בתנאי שמדובר ב - Attached Storage - מחובר למכונה עם PCI).
  • למשתמש בסוף חשוף איזשהו API - 
    • ב-AWS חשפו את ה Block Storage למשל - הגישה הכי ישירה למערכת אחסון: כתובת וגודל (Size) - “אני רוצה מדיה פיסית מכתובת מסויימת ל-Size מסויים”. זה היה EBS. אחריו הגיע Provisioned IOPS, שזה EBS מעל SSD שמבטיח IOPS מסויימים. 
    • בינתיים, ה - File System הוא בעצם שכבה שנמצאת מעל ה-Block ,ויש הרבה סוגי של file systems - מערכות של NAS מדברות על file System מעל רשת, ויש רמה שלישית שהיא ה - Object - לשים אובייקטים על המדיה עם פרוטוקול הרבה יותר פשוט מזה של ה - File System: בעיקר Put, Get, Delete וכו’ - וזה כבר דומה ל-S3.
  • ואכן, AWS התחילו עם S3, שהיא המערכת Object Storage הכי מפורסמת וגדולה כיום (והכי טובה? אין המון מתחרים באמת), ועבור ה-Block הם נתנו רק את EBS.
  • אחת הבעיות הראשונות שהיו ל-AWS עם ה-EBS הייתה Bad Neighbors (ידוע גם כ - noisy neighbor) - אם על אותו Block היו שתי כתיבות, קשה (מאוד) לקבל Predictable Performance.
    • זה, כאשר EBS הוא ברשת (לא מחובר ישירות למכונה שלך). יש גם אפשרות לפתרון אחר עם דיסק מקומי, אבל זה כבר משהו קצת אחר.
    • חשוב לשים לב שמדובר בדיסק נדיף - אם המערכת קורסת, הדאטה נעלם איתה.

אילו Features ראיתם שהלקוחות צריכים ולא קיימים כבר אצל אותם ספקי ענן גדולים? מבחינת FS Abstraction זה בערך היה שם, מבחינת ביצועים כנראה שלא, מה עוד?
  • בזמנו ל-AWS לא היה File System - לא NFS ולא SMB (הגיעו בערך לפני כ-3 שנים ושנה בהתאמה)
  • לא היה Performance ברמה נדרשת - אפשר היה להגיע לעשרות אלפי IOPS, כשלקוחות נדרשים לעיתים לעשרות אלפי IOPS ומעלה.
  • הייתה מגבלה מבחינת Capacity
  • הייתה (ובמידה מסויימת עדיין יש) בעיה עם זה שב-Block Storage אפשר לעשות Attach רק לשרת (Server) בודד. אם תרצה למשל להריץ Cluster של Microsoft (למעשה Share Storage של SQL Server) על שני שרתים שניגשים לאותו הדיסק שמשותף ביניהם - אין לזה מענה בשלושת ספקי הענן הגדולים.
  • זה דומה ב - Casandra למשל . . .זו ארכיטקטורה שרואים גם ב-Oracle SQL למשל - היכולת לעשות Clustering מאלצת Shared Storage (והם גם בונים על Network attached). מערכות ה - NoSQL (כמו Casandra ו-Hadoop) עברו להניח Commodity Hardware ובלי Network Attached Storage - בעצם Distributed File System.

אז למעשה המערכת יושבת מחוץ ל-AWS, מחוברת ב - Direct Connect (הרבה קווים במקביל, כך שאפשר להגיע להרבה יותר מ 10Gb/s) - האם אין מחיר ב - Latency? יש הבדל?
  • “הקנס” קיים, אבל הוא די זניח עבור מרבית ה - workloads - אנחנו מדברים על סדרי גודל של חצי מילי-שנייה, ועבור הרבה workloads שאינם Latency-incentive זה לא כל כך בעייתי.

קפיצה חדה לעתיד ולטרנדים - עולם ה-Storage מתפתח - מה אנחנו רואים היום? מה הלקוחות רוצים? מה הספקים רוקחים?
  • טרנד ראשון ומאוד ברור הוא No Data Gravity - בעולם אוטופי, “אני בכלל לא רוצה לדעת איפה ה-Data שלי נמצא”. אני רוצה שהאפליקציה תוכל לעבור ממקום למקום, ויחד איתה גם הגישה ל-Data. כשנוח לי אני עובד On-Premise ומתי שלא אז ב-Cloud, אני רוצה לעבוד עם GCP ולפעמים עם AWS - וזה מוביל לטרנד מאוד בולט של דרישה ל Hybrid Cloud.
    • רואים שגם ה - Hyper-scale Cloud Providers בונים פתרונות כאלה - AWS למשל יצאו עם Outposts, שזה בעצם אפשרות לרוץ עם AWS On-Premise, ורואים גם פתרונות דומים של VMware ושל EMC (ו-Zadara), שיוצרים חיבוריות בין ה - On-Premise ל - Cloud.
  • את כל הנושא של ה Hybrid Cloud אנחנו מכנים Any-Any-Any: בפלטפורמה שלנו, עם ארכיטקטורה מאוד מיוחדת, אנחנו מאפשרים להריץ Any Protocol (משמע - Block, File, Object) ב - Any Location (אם זה On-Premise או בענן), ואפשר להזיז את ה-Data לכל מקום. זהו אתגר שהיום הרבה פרמטרים מאפשרים להתמודד איתו - יכולות Networking שהולכות ומשתפרות במהירות, פרוטוקולים חדשים ועוד דברים שמאפשרים להעביר מידע בצורה חכמה.
    • להגיד No Data Gravity זה עדיין מוגזם כי כמובן שיש לזה עדיין משקל, ויש גם את העניין הזה עם מהירות האור (בטיפול).
  • אז איך זה עובד? יש לי למשל Data Center אחד באסיה ושני באמריקה, ואני רוצה שה-Services ירוצו על שניהם “בלי לדעת” איפה ה-Data נמצא - עדיין יש Latency, בכל זאת יש אוקיאנוס באמצע . . .
    • לפי מה שאנחנו מתארים, הארכיטקטורה הנכונה ל-Hybrid cloud היא למקם את ה - On-Premise שלי בסמוך (מאוד) ל - Data Center של ספק הענן, ומה שביניהם הוא ה-Data שלי, ואז לא משנה לי אם האפליקציה שלי רצה בענן או On-Premise - היא מסתכלת על אותו ה-Data. ברגע שאנחנו צריכים לדלג מעל יבשות ואוקיאנוסים, יהיה מחיר ב-Latency - מהירות האור עדיין כאן, לפחות עד שיוכח אחרת . . .
    • שאלנו לאין העולם הולך, לא אמרנו שיש פתרונות להכל . . . בפועל כמובן שיש מרחק פיזי בין המיקומים השונים, ואחד המפתחות טמון ביעילות העברת הנתונים - לא תמיד צריך להעביר הכל ואפשר להעביר on-the-fly רק את מה שצריך לגשת אליו, אפשר לעשות Tiering  ו-Fetching חכמים, ועוד כל מיני יכולות העברה של Data - חלק ב-Background וחלק On-Demand, וחלק אולי לא צריך להעביר - לפעמים יש tiers שונים או רפליקציות במקומות שונים, יש חברות שמאפשרות Global File System, ואז מאותה מערכת קבצים אפשר לגשת מכל מיני Home Offices  -יש הרבה פתרונות, ואחד המפתחות הוא הפתרון האינטיליגנטי של העברת המידע הנכון למקום הנכון. מעיין CDN רק עם Data . . .
  • טרנד נוסף - הצורך ההולך וגדל ב - Capacity - פתרונות של HDD היום נעים סביב ה - 14Tb, ויש פתרונות SSD סביב 60Tb ועובדים על 100Tb.

אם אנחנו כבר מדברים על ML ואחיותיו - יש משהו ב-workload עצמו שמעניין מבחינת Storage? דפוסי I/O מסויימים שרואים באפליקציות של ML ולא במקומות אחרים, או דפוסי Storage מיוחדים?
  • מה שמאפיין מאוד את ה-Big Data וה- Machine Learning זה Throughput מאוד גבוה (זמן טוב להשלים את הפרק עם Nvidia) - המערכות צורכות, קוראות ומעבדות כמויות גדולות של Data, ולא רוצים לחכות - יש כמויות גדולות של GPUs, וכבר מדברים על הדור הבא (של אחרי ה-GPU).
  • בסוף המערכת צריכה “לנגן”: אם תעשה משהו שהוא x10 יותר מהיר (אם באמצעות GPU או משהו אחר) - בסופו של דבר צריך להביא לו את ה-Data ולקחת את התוצרים - וה-Bottleneck רק עובר ממקום למקום, ו-Storage זה חלק מזה (“המטרה” כבר בן 35 ורק הופך ליותר נכון…).
  • זהו אותו Vicious Cycle - תוכנה מקדימה חומרה --> חומרה משתפרת --> חומרה מקדימה תוכנה --> תוכנה משתפרת --> . . . יצאו הרבה טכנולוגיות חדשות בשנים האחרונות, גם עבור Capacity גדול (לדוגמא - QLC, שמאפשר ארבעה ביטים באותו Cell של Flash, ומגדיל מאוד את ה-Capacity) וגם עבור Performance (פרוטוקולים חדשים, דורות חדשים של PCIe) - הדרישה להכל גדלה, Capacity ו-Performance: רוצים לגשת ליותר מידע יותר מהר, ומערכות האחסון כל הזמן רצות עם זה.
  • גם בחברה צעירה כמו Zadara, לעומת לפני כמה שנים ה - Average bill size כל הזמן הולך וגדל, לקוחות רוצים יותר ויותר Capacity ויותר ויותר Performance.
    • זה מדהים - גם אם לפעמים אתה לא מייצר יותר “Business” (בטח לא באופן אקספוננציאלי), על כל “טרנזקציה עסקית” שפעם הייתה מייצרת Datum מעניין אחד (או שהייתה יכולה להתמודד רק עם אחד והיה צריך “לחסוך”), היום הגישה היא “אפשר? אז קדימה”, ויכולות העיבוד וה-Insights שאפשר להפיק מ-Data גדלים הרבה יותר, אז על כל Datum אחד שפעם היה נשמר היום יש עשרה ויותר.
  • אפשר לבצע המון אנליזות על ה-Data ולהפיק מידע וידע לעסק - אפשר לעשות הרבה יותר.
  • טרנד שלישי משמעותי הוא מה שדי התחלנו איתו - X as a Service: מי שלא יתן את המוצר “as a Service” ישאר מאחור.
    • מי ש-IT אינו ה-Business שלו פשוט לא רוצה להתעסק עם זה - הרצון לצרוך גם Software as a Service וגם Infrastructure as a Service, וגם Platform as a Service - ושמישהו ידאג להכל: “אני לא רוצה לדעת מבעיות של Capacity - אני רוצה “endless capacity” ו - “endless performance” ו”לא רוצה לתעסק עם החלפה של Hardware” וכו’. יש רצון לצרוך לפי שימוש - מה שאני צורך, עבורו אני משלם, לא משנה איפה. ה - “as a Service” הוא מודל עסקי שכולם יעברו אליו.
    • ב - Zadara, מעבר ל - Cloud Providers, היינו חלוצים. לאחרונה רואים גם את Pure Storage ואת NetApp, ולאט לאט כולם מבינים שהמודל העסקי הנכון הוא OPEX ולא CAPEX.
    • האם אין כאן סתירה? מצד אחד לספק Storage as a Service עבור חברות שלא רוצות להיכנס All-in לענן ורוצות להישאר On-Premise . . . עבור חברות שהלכו לענן All-in כבר יש Storage as a Service.
      • לא כולם יכולים ללכת All-in - לפעמים רוצים רק Bursts: לשים את רוב ה - workload באחד הצדדים (ענן או On-premise), ורק כשיש צורך “רגעי” ביותר משתמשים גם בצד המשלים.
        • מקרה נפוץ (“הגיוני”) הוא שה - workload העיקרי (הצפוי, Predictable) מתבסס על חומרה on-premise, וה-Bursts הם תוך שימוש בענן - ואז לא צריך לרכוש מערכות שמשרתות את המקרים החריגים (אותם Bursts), “וחוסכים ככה המון כסף” 
        • אורי מגלגל עיניים, עד כמה שאפשר באודיו . . . זה בסדר כל עוד האפליקציה והפרמטרים הכלכליים הספציפיים של ספק הענן תומכים בזה, בגדול אנחנו עוד לא ממש שם, מחכים.
      • יש עוד סיבות, כמו למשל רגולציה - לא כולם יכולים לשים את ה-data שלהם בענן בגלל GDPR או רגולציות אירופאיות אחרות.
        • דווקא פה הענן” פועל לטובתך”, בגלל הפיזור הגיאוגרפי שלו  - אם אתה רוצה לאחסן את ה - Data באירופה, שיהיה באירופה.
        • גם לא תמיד נכון עד הסוף - כשמעלים את המידע ל-S3 אפשר אמנם להגיד איפה אני רוצה שזה יהיה - ועדיין לא כולם ששים שזה יהיה בידיים אמריקאיות (as-a-Service, אבל עדיין יש איזשהו AWS אמריקאי בקצה).
        • לסיכום הנקודה - יש Use Cases שבהם לקוח רוצה להישאר On-Premise, אבל עדיין לקבל Storage-as-a-Service, לפעמים אולי גם את ה - Database as a Service בחלק מהמקומות, אבל “במגרש שלך” ולא “במגרש שלהם”.
          • מעבר לזה שהלקוח רוצה את כל הסוגים - Block, File, Object וגם Tier 1, Tier 2, Tier 3 … - ואת הכל בפלטפורמה אחת.

מילה אחת על הארכיטקטורה - Zadara מספקת סוג של Scale-Out Solution - רצים על Cluster של שרתים, עם חיבור מהיר של (בקרוב) 100Gb, ובעצם מייצרים (אולי בשונה מאחרים) Multi-Tenancy, שזה משהו שהחברה הסתכלה עליו מהיום הראשון.
    • כמו בענן הציבורי, גם ב - On-Premise ובטח ש- Services Providers מקומיים, שנותנים שירות ללקוחות שלהם, רוצים שכל לקוח (כל Tenant) יהיה עצמאי - עם Dedicated Resources ו - Predictable Performance ו - Privacy . . . 
    • אנחנו (Zadara) מאפשרים VLAN לכל אחד בנפרד, כך ששני לקוחות של החברה “לא יודעים אחד מהשני” ואף אחד לא יכול להפריע - מרימים לכל Tenant את ה - Virtual Machine שלו, ושם רץ ה - I/O stack שלו. 
      • בפועל, מרימים כמה Virtual Machines עם High Availability ביניהן, כשה - VM של כל לקוח נפרדים ומריצים I/O stack נפרד על ה Zadara Cloud.
      • לכל לקוח יש את ה - CPU וה - Memory שלו, ושם מתבצעים ה - I/O Processes שלו - ה-Rate Protection ו - Snapshots ו-Redirects ו-Writes וכל תהליכי עולם האחסון - הכל מתבצע על I/O Stack נפרד, כך שאם לקוח אחד עשה משהו שגרם לנפילה במערכת, השני לא מרגיש את זה, יש Fault Isolation מוחלט.
      • בנוסף, לכל לקוח יש Dedicated Drives - כל אחד רץ בנפרד.
    • המשמעות היא שניתן להריץ workloads שונים, לאפליקציות שונות או עבור Tenants שונים, או עבור יחידות שונות באותו הארגון - בנפרד לחלוטין.
      • החומרה הבסיסית שמופרדת היא Drive - עם ה - I/O Bus שלו והכל.
    • בנוסף - כל אחד יכול להריץ סוג אחר של Workload - אחד יכול להריץ משהו שהוא Flash-optimized (בונים עבורו VPSA - Virtual Private Storage Array, עבור Tier 1 למשל - עם Latency נמוך וביצועים גבוהים) והשני בכלל רצה Backup ,עם דיסקים זולים. עוד לקוח שלישי אולי בכלל רוצה Archive שמבוסס על Object Storage - ואנחנו (Zadara) מאפשרים להקים מגוון של פתרונות אחסון באותו הענן, כשהכל במודל Pay-as-you-go, רק לפי Capacity.
    • האם יש גם אפשרות של RAID? כן, וגם  Erasure Coding שזה בעצם RAID קצת יותר מתוחכם, שמאפשר לא רק Failure אחד אלא מספר Failures.
      • המשמעות של Erasure coding 9+3 היא שלוקחים כל פיסת מידע ומחלקים ל-12 חלקים - תשעה מהווים את ה - Data ושלושה משמשים כ - Parity, כך שניתן לשרוד עד שלוש נפילות.
        • אלו יכולות להיות נפילות של שרתים או של דיסקים - בסך הכל Redundancy גבוה.
      • ה - RAID הוא בין שרתים - אין אף Single Point of Failure ,שזה עוד פרמטר חשוב בארכיטקטורה - בענן באופן כללי ובכלל ככל שיש יותר שרתים, חייבים To plan for failures, ואי אפשר להניח ששרת שנופל זה משהו שיפיל את המערכת.

  • עוד קצת החברה לסיום - 
      • ממוקמים ביוקנעם, קרוב ל-100 עובדים - מרכז הפיתוח נמצא ביוקנעם, ויש גם מרכז גדול בקליפורניה (שם נמצאים ה - Headquarters וה-Marketing, Sales, תמיכה טכנית . . .)
      • יש עוד מרכז פיתוח בהודו - תולדה של היכרויות מהחברה הקודמת, יצא שהארכיטקט הראשי יושב בהודו, וסביבו מרכז פיתוח קטן של כ-10 עובדים.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול
Posted by at

אין תגובות:

הוסף רשומת תגובה

הירשם ל- תגובות לפרסום (Atom)