פודקאסט מספר 355 של רברס עם פלטפורמה - אורי ורן מארחים את אסף נתנזון לשיחה על טכנולוגיות חדשות, אחזור מידע, פטנטים ומהירות האור בישראל. אסף עובד ב Dell EMC (הרצליה) ומתמקד בשני היבטים -העתיד של Data Protection - לא במובן של Security אלא של גיבוי (Backup) ואחזור מידע (Data Recovery) - טרנדים +5 שנים קדימה.עבודה עם Dell Capital - זרוע ההשקעות של Dell, שאחראית על השקעות בכל הפורטפוליו (כולל Pivotal וכו’), עזרה בכל הקשור להערכות שווי (Evaluation) של חברות. מה מפתחים היום בישראל?המשרד הישראלי של Dell מתבסס על מספר רכישות - אסף עצמו הגיע רשמית ל-Dell לפני שנתיים עם הרכישה של EMC, ולשם דרך סטארטאפ בשם Kashya שעסק ב-Continuations Replication - טכנולוגיה שמאפשרת ליצור עותק של Block Device מרחוק, ולאפשר חזרה לכל נקודה בזמן לאחר מכן.היום זה נמצא בתוך מוצר שנקרא RecoverPoint, ויש גם עבודה של גרסא למכונות וירטואליות (Virtual Machines).יש עוד שני מוצרים תחת RecoverPoint -גיבוי לענן (כרגע ל-AWS) ועוד אחד שעדיין לא מדברים עליו.נראה שהעולם מתקדם בשני כיוונים, לכאורה סותרים - מצד אחד לקחת מערכת בודדת ולהפוך אותה לאמינה ככל האפשר, ומצד שני להניח ששום מערכת לא אמינה לחלוטין, ולפתח דרכים להתמודד עם זה (Clustering למשל).חשוב להבדיל בין שני פרמטרים - זמינות (Availability) ויכולת אחזור (Recoverability):עצם העבודה שהמערכת אמינה לא מגן מפני טעויות, למשל כשמישהו מחק טבלה ממסד נתונים, ועכשיו צריך לשחזר מנקודה שקודמת לטעות.עולם ה-Disaster Recovery - במקרה של אסון טבע שמשמיד איזור שלם, כאשר מבחינת Latency לא תמיד ניתן לפזר את המערכת על מרחקים מספיק גדולים כדי לשלול את ההסתברות לנזק בכל המקומות במידה מספקת. וגם אם כן - זה לא מגן מטעות אנוש או באג לוגי.סיכוי מול סיכון - מה הסיכוי שמשהו כזה יקרה בחיי חברה, ותצטרך לעלות חזרה מגיבוי - פעם בחמש שנים בערך זו הערכה סבירה? ואם כן, אנחנו מדברים על חזרה ברזולוציה מאוד גבוהה (שניות בודדות?) - יש דרישה כזו?ראשית, בעולם הגיבוי (Backup) הדרישות לא כאלה חמורות (לא שניות), וגם הערכת ההתפלגות הרבה יותר נפוצה מפעם בחמש שנים - זה יכול לקרות אפילו כשאיבדתי גישה לקובץ במחשב הנייד שנמחק בטעות ואני רוצה לשחזר, וזה הרבה יותר תדיר.עולם ה-Disaster Recovery עוסק לרוב באירועים פיסיים (שריפה, שטפון, וכו’)בהיבט של תקלה לוגית, השאלה היא כמה מידע אתה מוכן לאבד - נקודת אחזור פעם ביום? כך שש שעות? כל רבע שעה במקרה של של Virtual Machines (אם כי במקרה כזה הביצועים יהיו בלתי נסבלים)?זה גם תלוי הקשר - רבע שעה של טרנזקציות בבנק זה לא משהו שאתה מוכן לאבד, כנ”ל לגבי רבע שעה של עסקאות ב-Amazon למשל.טכנולגיית ה-Continuous Replication משלבת בין Disaster Recovery והצורך לעלות עם אתר חלופי כמה שיותר מהר, ועולם הטעויות הלוגיות, בו נרצה לחזור כמה שיותר מהר לנקודה שקדמה לתקלה או לטעות. הרעיון היה לא להתבסס על Snapshots של ה - Storage (כי הביצועים מחרידים, ב-VMware למשל זה עדיין די ככה).מומלץ לקרוא את ה-Retrospective של הנפילה של GitHub חזרה לכיוון הברזלים, וגיבוי ל- Block Device - “מה שיושב מתחת למערכת הקבצים” - דיסק (פיסי או לוגי), שמקצה מרחב כתובות (0 --> גודל הדיסק) ומאפשר פעולות בסיסיות (כתיבה, קריאה)מערכת ההפעלה היא זו שמתקשרת עם ה - Block Device (איפה לאחסן את הקבצים, מה לקרוא וכו’)מערכת הקבצים יוצרת מעיין שכבת אבסטרקציה מעל ה - Block Device, שמאפשרת אחסון קבצים, מצביעים ועודדוגמאות ל - Block Device עשויים להיות SSD פיסי, שירות EBS של AWS ואחרים.את הבלוק הזה לוקחים, ויוצרים עבורו העתק מתמשך (Continuous Replication) - צריך איזשהו דרייבר בדרך, Data Tap בין ה- Block Device לבין מי שכותב אליו (גרסה וירטואלית של מחבר T) - בעבר ידענו לשים את זה בתוך מערכת ההפעלה, או בתוך ה-Storage עצמו אם זו מערכת פיסית.במערכות וירטואליות ו-Containers, אותו Data Tap יכול להיות חלק ממערכת ההפעלה של ה-VM, או בתוך ה-Hypervisor עצמו.האתגר הוא ההתנהלות כשמתרחשות תקלות - לדעת לא לאבד אף כתיבה כשמשהו נופל, לאפשר למכונה להמשיך מאותה נקודה ולא להתחיל לקרוא מהדיסק את כל המידע מחדש וכו’.אתגרים נוספים הם לנהל את המערכת כך שניתן להגיע לכל נקודה בזמן, וכמובן ביצועים (Performance) וזמינות (Availability).ה-Data Tap יוצא אל המערכת (הרפליקציה) דרך הרשת - במקרה הזה יש רכיב (Appliance) וירטואלי בדרך, שיודע לבצע בקרה ואופטימיזציה (ולהכיל Policies במידת הצורך), ולשלוח את המידע למכונה אחרת שמנהלת עותק מרוחק - שמכיל עותק של ה-Virtual Machine ו-Journal (בדומה ל Redo Log / Undo