פודקאסט מספר 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 Log של Oracle), ובכך מאפשר לנוע על ציר הזמן של הגיבוי
- ולנושא אחר - הצד המדעי / הנדסי של חשיבה על פטנטים (אולי יעניין אתכם גם - יש פרק ישן של רברסים על הצד המשפטי) - העבודה היומיומית, המטרות, המוטיבציה
- למוטיבציה יש כמה מקורות -
- הגנתית - החברה לא מעוניינת שיתבעו אותה על פעילות שהיא עושה, ולכן מגנה על תהליכים ומוצרים (ויוצרת סוג של “מאזן אימה” מול אוסף הפטנטים של המתחרים)
- פטנטים מעלים את השווי של החברה - מעבר למוניטין הרשום, זה נחשב כמדד לחדשנות בחברה
- מה המוטיבציה למהנדס הבודד? בדומה לאקדמיה, יש כאן סוג של פרסום ומיתוג עצמי, ובחברות גדולות זה בדרך כלל גם מלווה בתמריץ כלכלי.
- לאסף עצמו יש בערך 250 פטנטים רשומים ועוד סדר גודל דומה בסטטוס Pending.
- איך נראית עבודה על פטנט?
- קודם כל צריך לחשוב על רעיון (אסף העביר לא מזמן סשן בסנט פטרסבורג על איך חושבים של רעיונות חדשניים), ואז צריך להגיש מסמך . . .
- בארגונים גדולים (Corporate) יש ועדה של מומחים בתחום, שאמורים לדון ולאשר את הפטנט להגשה; לאחר מכן ממונה עו”ד (מהחברה או חיצוני), שצריך להפוך את תיאור הפטנט למסמך פטנט רשמי, שבהתחלה עלול להראות קצת סתום עם תיאור מפורט של מה הפטנט עושה ועל מה הוא מגן (Claims), בשפה משפטית.
- הפטנט מוגש למשרד פטנטים (בארה”ב, בסין, בכל העולם - שיקולי עלות/תועלת), מוגדר כ-Pending, ואז יש תהליך של ~3 שנים (ממוצע) עד לסטטוס Granted.
- כמה זמן עבודה למהנדס עצמו על הפטנט? המסמך עצמו לוקח שעה-שעתיים, ועוד 30-60 דקות עם העו”ד. יש כאן עניין של ניסיון - בפעמים הראשונות הכל לוקח יותר זמן.
- בסטארטאפ הכל פחות מובנה: “צריך פטנטים” --> Brainstorm --> מחליטים ושולחים, תלוי כמה תקציב הוקצה לכך (עניין יקר, אז לא שולחים הרבה - עשרות אלפי $, כולל העו”ד).
- חלק שלישי - טרנדים בטכנולוגיה. אסף יושב בצומת מרכזי יחסית בכובע של Dell Capital, ורואה טרנדים בחומרה ותוכנה
- תוכנה - Functions as a Service ו- Serverless Computing. הכל הופך יותר מהיר ופשטות הפיתוח מהווה גורם משמעותי.
- מכיוון ה-Data Protection זה קצת הפוך - מאוד קל להשתמש בשירותים חיצוניים, וקל להגיע לאפליקציה אחת עם מספר גדול של מסדי נתונים חיצוניים. למפתח מאוד כיף והכל הכי פשוט שיש, אבל איש ה-Backup עומד בפני סיוט, כי צריך לדעת לגבות ולשחזר הכל --> זה חייב להיות אוטומטי.
- היום צריך בכל פעם סקריפט חדש של איש ה-IT, וזה לא Scalable במיוחד
- ברמת הבלוק, אם למשל יש Kubernetes שרץ תחת VMware, תיאורטית אפשר לקחת Snapshots ואת זה כבר יודעים לעשות.
- עיקר הבעיה היא ברמת הניהול בסביבת Cloud Native - ואיך להפוך אותו לשקוף ככל הניתן: אני יכול לעשות מאות גיבויים (וספקי הענן השונים מאפשרים את זה בקלות יחסית), אבל צריך לנהל אותם - מה קורה כשזה נכשל? מי שולח דוחות? איך משלמים על כל הנפח הזה? איך יוצרים קטלוג ויודעים מה נמצא איפה? לחברות גדולות (עם סיכון גדול במקרה של אובדן מידע) זה מאוד חשוב.
- שיטת ה “בוא נחכה שיבוא האקר עם רשימת כרטיסי האשראי של הלקוחות ואז נשלם לו שיתקן” פחות מומלצת.
- טרנד בולט נוסף - Edge Computing
- הולך להיות מאוד בולט עם עליית המכוניות האוטונומיות (הערכת סדר גודל של 8Tb ביום - אין היום איך לשלוח את זה לענן באופן יעיל)
- בהקשר של Edge Computing מדובר לרוב על מעיין micro Clouds במערכת היררכית, כשחלק מהעיבוד נעשה מקומית וחלק עולה לענן.
- שעון חכם יכול לשלוח הכל לענן לניתוח, זה לא כל כך הרבה מידע כיום. מעבר לזה כבר הופך מורכב.
- אנחנו מדברים על Data Centers שיכולים לשבת אצל ה-ISP או במחשב חזק של הרכב, שיעבד הרבה מהנתונים מקומית ויתקשר עם הענן ברמות שמעל.
- מתחילים להופיע Frameworks בנושא - GreenGrass של Amazon וגם EdgeX Foundry של Dell. ב-VMworld הייתה גם הכרזה על שיתוף פעולה בין VMware לבין Microsoft בנושא.
- מה לגבי Dell - ככל שהעולם הולך לכיוון של Public Clouds, הכל יושב אצל ספקי הענן המרכזיים, והם מתחילים יותר ויותר לייצר את החומרה עבור עצמם, במקום לרכוש (מ-Dell למשל).
- חברה כמו Amazon אכן מייצרת חומרה לעצמה (הרכישה של Annapurna Labs הייתה חלק מזה), אבל לרוב שירותי ענן זולים כשהחברה קטנה. כשגדלים זה כבר לא כל כך זול והשיקולים משתנים, כך השהדרישה לחומרה מחברות כמו Dell קיימת.
- מעבר לזה, יש את עניין האמינות - EBS לא אמין כמו Symmetrix VMAX (בגרסא האחרונה זה PowerMax) למשל, אין התחייבות לאמינות שחברה הרבה פעמים דורשת מהשרתים שלה.
- יש גם חלקים שלמים בתעשיות גדולות (בנקים למשל) שעדיין עובדים על Mainframe, והמעבר ל-Cloud Native יקח עוד זמן.
- ועדיין - איך חברה כמו Dell מסתכלת קדימה בעולם שהולך לכיוון Serverless?
- ראשית, הכל יהיה קיים גם בתוך ה-Data Centers של החברות - מעל Kubernetes יש את PKS, יש שיתוף פעולה בין VMware ל-Amazon שמאפשר לרכוש חומרה שמריצה VMware בתוך AWS, ובאופן כללי כולם הולכים לכיוון של Multi-Cloud.
- לאורך זמן, יש דברים יקרים בענן - המון Storage ללא תנועה, המון Compute שרץ כל הזמן. Serverless יהיה יעיל עם פרופיל השימוש מוטה Peaks, אבל על פרופיל עבודה קבוע יחסית, שירותי ענן עשויים להתגלות כמאוד יקרים ביחס לחומרה בבעלות החברה.
- תמיד יש ענייני רגולציה ו-Compliance, שגורמים לחברות בסקטורים מסויימים לא לזוז, וגם אם כן - המעבר מאפליקציות סטדרטיות ל-Cloud Native לוקח זמן.
- מעבר לכל זה, יש את כל מה שהזכרנו לגבי התפתחות ה-Edge Computing, שם יש ל-Dell פוטניאל עצום - Data Center נייד על גבי משאית, או בתוך רמזור למשל.
- מזכיר את המכולה ש-Microsoft הטביעו באוקיאנוס . . .
- עוד טרנד לפני סיום - Persistent Storage: אחרי המעברים מדיסקים מגנטיים ל-SSD, היום רואים את המעבר לפרוטוקולים של NVMe שמדברים על Latency הרבה יותר נמוך, זכרונות של 3D XPoint ו - N-RAM, שישנו את האופן שבו אפליקציות נראות, בעולם שמוטה זכרון (Memory centered) - יכולות גישה מאוד מהירה לזכרון עם עקביות (Persistence) של דיסק.
- ניתן להריץ בתוך המחשב שלך עם כמויות מאוד גדולות של זכרון; כשרוצים לצאת החוצה עדיין צריך לשלם ב-Latency - יש איזה עניין לא פתור עם מהירות האור, בעיקר עם זה שאי אפשר לעבור אותה (אלא אם אתה ברמזור בישראל, ואז הקול של הצפצוף קודם לאור מהרמזור).
- ברגע שנעבור לעולם מוטה זכרון, הרבה מה-Best Practices הנוכחיים יצטרכו להיות מתוקפים מחדש, וחלקם לא יהיו רלוונטיים (למשל - אם הנחנו שהגישה לזכרון מהירה x1000 מגישה לדיסק, לא בטוח שזה עדיין נכון).
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול
אין תגובות:
הוסף רשומת תגובה