מה זה גיבוי ומה הופך פתרון גיבוי לפתרון טוב

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

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

 נתחיל בהגדרה מילונית, מה זה גיבוי?

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

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

של נתונים – פתרון גיבוי כולל בדרך כלל את היכולת לבחור אילו נתונים מגובים ובהתאם למדיניות הארגון לשמור את סוגי המידע השונים על פי הצורך (מידע פיננסי 7 שנים, מידע רפואי 90 שנים וכו')

לשחזור המידע המקורי – פתרון גיבוי כולל את האפשרות לשחזר את המידע בעת הצורך

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

לא כל הגיבויים נולדו שווים?

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

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

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

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

מה עוד יכול פתרון טוב לכלול?

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

בשבוע שעבר הוכרזה חבילת העדכונים SP6 עבור Commvault 11. אחד הכלים המעניינים ביותר שנכללו בחבילה זו תחת Early Release הוא כלי מיגרציה של מידע מגובה מתוכנת הגיבוי הקודמת אל תוך ObjectStore מקוטלג של Commvault. הכלי מספק מענה לאחד האתגרים הכי משמעותיים בפרויקטים של החלפת פתרון גיבוי, ברוב המקרים, הפתרון הכי נפוץ עד היום היה פשוט להשאיר בצד את פתרון הגיבוי הישן לצרכי שחזור עד סיום ה retention. אם הלקוח הוא לא חברה בת יומיים התהליך הזה יכולת לקחת כמה שנים טובות שבהן צריך להמשיך לתחזק את הפתרון הישן, גם אם בתחזוקה בסיסית ביותר, לצד הפתרון החדש, Commvault  מאפשרת עכשיו להתגבר על פרויקט המרת הקלטות הכואב ולבצע מעבר מלא, כולל ה retention אל פתרון הגיבוי החדש.

אז מה עושים עם זה בפועל?

מדיניות גיבוי נפוצה היא מדיניות 3-2-1: שלושה העתקים של המידע, על שני סוגי מדיה שונים, לפחות העתק אחד מחוץ לאתר. על פי מרבית המקורות מייחסים הצלם דיוויד קרוג היה הראשון לנסח את המדיניות הזו והוא מקבל את הקרדיט הזה אפילו במסמך ההמלצות של US-CERT  כך שכנראה יש בזה משהו. לאחרונה ראיתי הרחבה של החוקיות הזו בבלוג של Veeam. זה לא פוסט חדש אבל נתקלתי בו רק לאחרונה והוא מדבר על 3-2-1-0 כאשר 0 הוא 0 טעויות. היכולת לבצע ולידציה של הגיבוי שנקראת אצלם SureBackup מסייעת לוודא שמשימות הגיבוי אכן התבצעו באופן תקין וכי ההעתקים קריאים ונגישים.

גם בשימוש ב snap manager for exchange  למשל, ניתן לשלב במשימת הsnap shot הרצה של eseutil כדי לוודא שההעתק שנוצר תקין. כאן, כשאני מזכיר את NetApp, אני בעצם סוגר מעגל שלם אל ראשית הבלוג וכאן התחיל הדיון אותו הזכרתי, מהו גיבוי? האם סנפשוטים הם גיבוי? לא, לדעתי לא, לא לבד בכל אופן. סנפשוטים יכולים להיות חלק מפתרון הגיבוי, הם במרבית המקרים הדרך הכי מהירה ליצור העתק של המידע וכן, במרבית המקרים, גם הדרך הכי מהירה לשחזר מידע מהעתק קצר טווח אבל, לבדם, הם לא עונים על מה שמגדיר בעיני פתרון גיבוי טוב, הם לא מקטלגים את המידע, לא שומרים אותו על עוד סוג מדיה, לא מוציאים העתק מחוץ לאתר וכו'.

פתרון כמו Commvault, פתרון כמו Veeam ברמות הרישוי הגבוהות או פתרון IntelliSnap שהוא רכיב Commvault המשולב כ OEM במערכות NetApp FAS, פתרון כזה משתמש באופן מובנה ותחת מדיניות גיבוי ארגונית אחת ביכולות הסנפשוט או הרפליקציה של מערכת האחסון וזה כבר עונה להגדרות שפירטתי.

איפה נרשמים?

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

אשמח לשמוע מה דעתכם

שלכם,

ניר מליק

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

מערכות קטנות (פיזית) וסקסיות, דגמים חדשים של NetApp All Flash

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

בשבוע שעבר הושקה באופן רשמי מערכת ה NetApp All Flash FAS A200 הסקסית והנה היא כאן לפניכם

בחזית 24 דיסקים SSD ומאחור שני בקרים, 8 פורטים 10/16Gb ועוד 2 פורטים 10Gb יעודיים לקישוריות קלאסטר.

a200-back

המערכת תומכת בגידול עד 144 דיסקים עבור זוג בקרים יחיד ותמיכה בתצורת Scale-Out בת 8 בקרים. אם נזכרים בדיסקים של 1.44MB אז זה ממש מרשים לחשוב על 24 דיסקים של 15.3TB או 1PB  אפקטיבי במארז של 2U !

a200-front

בנוסף, כדי לעשות עוד קצת שרירים, הושקה השבוע אחות למערכת ה High End, מערכת ה A700, קוראים לה A700s והיא מספקת את אותם ביצועים אבל בלי כל כרטיסי ההרחבה והמארז הענק ככה שמי שצריך רק את העוצמה אבל בלי כל הגמישות הזו, מערכת ה A700s מגיעה בתצורת 4U וכולל גם היא 2 בקרים מאחור עם 24 דיסקים בחזית.

עדיין קשה לקרוא למכונה הזו מכונה קטנה, 8 חריצי PCIe, פורטים מובנים של 40GbE ו 32Gb FCP, טרה של RAM…מסחרר!

עכשיו, אם עוצרים לחשוב, מצרפים את השקת המכונות החדשות האלו לפוסט הקודם שדיבר על Fabric Pool והפוטנציאל כאן הוא אין סופי, מערכת All Flash שמספקת, נגיד, אם נהיה שמרנים, 1PB effective capacity במארז פצפון של 2U, משלחת כמה מאות אלפי IOps בזמני תגובה של חצי מילי-שניה בכל השרתים והשירותים, ודוחפת החוצה ל S3 את כל הבלוקים הקרים שלה, מה שמתקבל כאן זה נפח אינסופי של All Flash בחסות ה DataFabric! מוצפן, דחוס, מדודפ, מנוהל ממיקום מרכזי, מתרפלק למערכות אחרות, מתממשק אל כל מנועי האוטומציה והאורקסטרציה, תומך באופן מלא בכל ההייפרויזורים והקונטיינרים ועונה בכל הפרוטוקולים הנפוצים, זו ארמדה שלמה במארז של 2U, מקסימום 4U. לאף מתחרה בשוק אין כלים כאלו, פשוט אין. חלק אומרים שיש להם אבל פשוט אין.

אגב למי שדאג, השבוע הוכרזה ONTAP 9.1 RC2 ככה שנראה שההשקה הרשמית של 9.1 כבר מעבר לפינה. אחד החידושים בהכרזה הזו נמצא בצד השני של הקשת, אם אמרתי שיש מערכות חדשות שהן קטנות וסקסיות אז RC2 מאפשר מהצד השני בריון אחד שקט, מדף הדיסקים החדש DS460C המכיל 60 דיסקים בגודל 3.5" LFF במארז של 4U עם קישוריות 12Gb SAS.

תחת גרסאת מערכת ההפעלה הנדרשת, המדף נתמך בכל המערכות מסדרה 8000 ומעלה. talk about density!

שלכם תמיד,

ניר מליק

אולימפיאדה, ברברים ועננים – NetApp Fabric Pool

אולימפיאדה, ברברים ועננים – NetApp Fabric Pool

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

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

מערכות אחסון מודרניות חיות היום גם הן על האיזון בין הקצוות, בין דיסקים גדולים מאד המסתובבים באיטיות ודיסקים קטנים מאד מהירים. העולם בו אנו חיים נשלט על ידי שתי אימפריות ישנות, אימפריית ה SAS שדגלה תמיד בביצועים על חשבון נפחים ואימפריית ה SATA שדגלה בנפחים על חשבון ביצועים. מבחינה היסטורית, אנחנו נמצאים עמוק בימיה האחרונים של האימפריה הראשונה, הברברים של ה SSD עומדים על חומות אימפריית ה SAS וברור שיימי האימפריה ספורים. כאיש ימי הביניים תמיד צחקתי שאם המסמכים המקוריים נכתבו באנגלית אז זו לא היסטוריה אלא רכילות, חוק פרטי זה תקף גם לגבי האימפריה השניה כנראה. נכון, עוד קצת מוקדם להספיד לגמרי את אימפריית ה SATA אבל לא מוגזם לשער כי הפשיטות של שבטי הענן גורמים גם למנהיגי אימפריה זו לרעוד מאחורי ביצורי ה helium encased drives וה shingled drives  . העלויות הנמוכות לשימוש באחסון אובייקטים S3 ואף יותר מכך Glacier הופכות מיום ליום גם את השימוש בדיסקים מסוג SATA לפחות הגיוני, בטח לשימושים כמו גיבוי או ארכוב. נכון לעכשיו, תחילת דצמבר 2016, עלות טרה אחד S3 בשירות AWS הוא כ 31$ לחודש ועלות טרה אחד בשירות Glacier הוא כ 11.5$ לחודש והמחירים כל הזמן יורדים.

אחד מסודות ההצלחה של כל אחת מהאימפריות הגדולות בהיסטוריה היה תמיד היכולת להתפתח ולהתאים את האימפריה לזמנים המשתנים, פרגמטיות שכזו היתה מאפיין של האימפריה הרומית, האימפריה העותומנית ואפילו הצלחתה של הנצרות במאות הראשונות לספירה מיוחסת לפרגמטיות שהנהיג השליח פאולוס. NetApp מוכיחה בשנתיים האחרונות שהיא אימפריה פרגמטית. סל המוצרים האטרקטיבי, ביחד עם תפיסת הפעלה כוללת – מארג המידע או ה Data Fabric, מספקים מענה למרבית אתגרי המידע בעולם המחשוב היום, מערכות אחודות מובילות בעולם ה All Flash, מערכות SAN לסביבות high density, מערכות SolidFire לניהול אחסון במודל ענן, פתרונות לגיבוי חכם אל הענן, פתרונות מבוססי תוכנה בלבד software defined, מערכות וירטואליות לסביבות ענן, כלים להגירה בין פתרונות NFS מקומיים לשירות אובייקט בענן, NetApp היא אתלט קרב עשר מדהים – כוח מתפרץ וגם סיבולת לטווח ארוך, מהירות וגם טכניקה, ליצרן הזה יש מענה מוביל והוא חלק ממארג שלם של כלים ולא מענה נקודתי או חלקי.

יכולת חדשה שמדגישה את השילוב הזה בין היכולות והדיסציפלינות היא יכולת ה Fabric Pool החדשה שנחשפה לאחרונה בכנס ה Insight, התייחסתי אליה בקצרה באחד הפוסטים הקודמים ועכשיו אני רוצה להרחיב עליה קצת. יכולת זו שתהיה זמינה בקרוב, מאפשרת להשתמש בו זמנית בשני כלים משני קצוות הקשת, מחד, לאמץ את הברברים של ה SSD ולהשתמש במערכת עתירת ביצועים מובילה על מנת לספק מאות אלפי IOps בזמני תגובה הנמדדים כיום במיקרו-שניות ומאידך, על פי מסורת שבטי הענן, להכיר בעובדה שבסופו של יום, מרבית המידע בארגון אינו מידע "חם" כלומר, חלק ניכר מהמידע שאנחנו מחזיקים הוא מידע שלא משתמשים בו ולהעביר באופן אוטומטי ושקוף את המידע ה"קר" אל שכבת אחסון משנית מבוססת פרוטוקול S3, אחסון אובייקטים סטנדרטי בין אם בוחרים ליישם שכבה משנית זו על ידי פתרון מקומי כמו NetApp StorageGrid או פתרון מרוחק כמו AWS S3.

פשוט כך, ללא צורך לשנות שום דבר מצד ה front-end, ללא הגבלה על פרוטוקול הגישה, ללא כל צורך בשינוי מצד האפליקציות או הרגלי המשתמשים, באופן שקוף לחלוטין, מערכת האחסון תנהל לעצמה את עדכוני ה Meta-Data ותדע להעביר בלוקים קרים אל הענן כך שמחד מערכות הארגון יקבלו שירות ברמה של All Flash ומאידך לא נהיה חייבים לשמור את כל המידע על דיסקים יקרים. בואו נרחיב לגבי השקיפות הזו: אחד הפקטורים המשמעותיים במערכות All Flash הוא חסכון בנפח האחסון, יכולת ה Fabric Pool שקופה לחלוטין לטכנולוגיות ה Efficiency המובנות ב All Flash FAS, כל החיסכון שמתקבל בשימוש ב in-line De-Duplication, In-Line Compression ו in-Line Compaction נשמר, המערכת מודעת לחסכון ושומרת עליו גם במעבר הבלוקים הקרים לענן. אותה שקיפות נכונה גם ליכולת ה Volume Encryption שנשמרת, אין ביצוע Decrypt כאשר מעבירים מידע ויתר מזאת ניתן כמובן לבצע הצפנה על הצפנה ולהצפין את הבלוקים גם במנגנון המובנה ב StorageGrid  למשל או יכולת ההצפנה של S3.

fabric-pool

מבחינה מעשית, כל מה שנדרש לעשות זה להגדיר קישור אל AWS ואז יש שני דברים להגדיר מצד מערכת האחסון, עבור אילו Volume'ים אנחנו רוצים להפעיל את יכולת ה Fabric Pool ואם אנחנו רוצים להפעיל אותה עבור כלל המידע ב Volume או רק על הסנפשוטים. נשמע פשוט? אכן פשוט. אפשר להפנות כמה מערכות אחסון אל אותו מנוי S3 וכמובן שהפתרון נתמך גם בשימוש ביכולת multi-node scale-out כלומר גם כאשר מערכת ה All Flash FAS שלנו כוללת יותר מזוג בקרים אחד, הפתרון נתמך, עובד ושקוף.

which-volume

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

report

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

מי שרוצה ללמוד עוד קצת היסטוריה מוזמן לפנות לפודקאסט המדהים של דן קרלין ומי שרוצה לקרוא עוד קצת על Fabric Pool מוזמן לקרוא את הפוסט הבא של ג'ף בקסטר

כמו תמיד אשמח לשמוע מה דעתכם על הפוסט, על Fabric Pool ועל החיים

שלכם,

ניר מליק

*הערה – כן, אני יודע שכבר יש דיסקי SSD יותר גדולים מדסיקי NL-SAS אבל התמחור שלהם משאיר אותם עדיין קצת פחות רלונטיים עבור מרבית הלקוחות בישראל