שכפול של נתוני העתקה לאחסון מרוחק מגן על הנתונים במקרה של אסון באתר הראשי, ומקטין את כמות האחסון הנדרשת באתר הראשי. מטרת השכפול היא להחזיר את הנתונים במקרים של אובדן נתונים ופגיעה במערכות הייצור בגלל בעיות כמו כשל בחומרה, בעיות בתוכנה או אירוע באתר. רפליקציית נתונים תומכת גם ביצירת עותקים מרחוק של נתוני בדיקה/פיתוח, נתוני QA ונתוני ניתוח. אפשר לשכפל נתונים ממכשיר גיבוי/שחזור אחד למכשיר שני (מרוחק) או לענן לצורך שחזור, התאוששות מאסון או בדיקה ופיתוח.
תבניות הגיבוי קובעות את השיטה, את לוח הזמנים ואת התדירות של שכפול הנתונים באתר מרוחק. תבנית הגיבוי מגדירה איך להעביר ולאחסן נתונים בצורה יעילה במכשיר הגיבוי או השחזור המרוחק. שכפול הנתונים נשלט על ידי מדיניות התבניות הבודדות:
מדיניות של העברה מ-Production ל-Mirror מגנה על הנתונים של האפליקציה או המכונה הווירטואלית מפני כשל באתר, על ידי יצירת עותק מלא של הנתונים שמשוכפל לאתר Production מרוחק. האפליקציות מתעדכנות באופן שוטף, ואפשר להפעיל אותן מחדש בהתראה קצרה באתר המרוחק על ידי גישה לנתונים מעותק ה-DR המרוחק. שיקוף נתונים יכול להיחשב כשיכפול עם גישה אופטימלית לאתר מרוחק. פרטים נוספים זמינים במאמר העתקת מדיניות מהסביבה הפרודקטיבית לסביבת המראה.
מדיניות של Snapshot to OnVault משתמשת בחיבור HTTPS כדי לשלוח נתונים לאחסון שמוגדר על ידי OnVault Pool. האפשרות 'דחיסה' מופעלת כברירת מחדל ב-OnVault Pools. פרטים נוספים זמינים בקטע שליחת תמונות מצב למאגר אחד או יותר של OnVault.
שליחת תמונות מצב למאגר אחד או יותר של OnVault
המדיניות 'תמונת מצב ל-OnVault' מאפשרת לשלוח נתוני תמונת מצב למיקום שמוגדר על ידי מאגר OnVault. לוח זמנים במדיניות משמש לשליחת תמונת המצב האחרונה שצולמה על ידי מדיניות התבנית של מדיניות הייצור לתמונת מצב למיקום שהוגדר במאגר OnVault. בדרך כלל משתמשים באחסון במאגר OnVault לשימור לטווח ארוך. פרטים על מאגר OnVault זמינים במאמר שליחת תמונות מצב למאגר OnVault אחד או יותר.
כששולחים נתונים לאחסון שמוגדר על ידי מאגר OnVault, נעשה שימוש בחיבור HTTPS כדי להבטיח את אבטחת הנתונים ברשת. אפשרות הדחיסה של מאגר OnVault מופעלת כברירת מחדל כדי לצמצם את תעבורת הרשת.
אחרי ההעברה הראשונית של התמונה המלאה, רק השינויים בנתונים נשלחים למאגר OnVault. זהו אותו מודל של גיבוי מצטבר שמשמש במדיניות אחרת.
כשניגשים לנתונים במאגר אחסון של OnVault, חשוב לשים לב לנקודות הבאות:
מכשירי גיבוי ושחזור יכולים ליצור שיבוטים.
אי אפשר ליצור שיבוטים בזמן אמת.
מ-OnVault לכמה מאגרי OnVault
אפשר לשלוח נתוני אפליקציות לכמה יעדי OnVault בענן. כל יעד OnVault נשלט על ידי מדיניות נפרדת, כך שתדירות העדכון וזמני השמירה יכולים להיות שונים (לדוגמה, עדכונים מקומיים בתדירות גבוהה עם שמירה לזמן קצר, יחד עם עדכונים לענן בתדירות נמוכה יותר עם שמירה לטווח ארוך).
יש תמיכה ב-Multi-target OnVault בכל סוגי האפליקציות, כולל Direct-to-OnVault עם מכונות וירטואליות של VMware. במקרה כזה, הנתונים נכתבים ישירות למאגר הראשון של OnVault, בלי לעבור דרך מאגר התמונות, ואז נשלפים מהמאגר הראשון של OnVault ונשלחים למאגרים האחרים.
שכפול מדיניות בסביבת ייצור
מדיניות שיקוף של סביבת ייצור מספקת אמצעי לשכפול עותק של נתוני האפליקציה או המכונה הווירטואלית למכשיר גיבוי או שחזור יעד, ולגישה לנתונים ללא חלון שחזור, וכך מאפשרת RTO נמוך מאוד. במקרה הצורך, אפשר לבצע מעבר חזרה לאתר הפרודקשן עם מערך נתונים זהה שמשוכפל בין מכשירי הגיבוי והשחזור המקומיים והמרוחקים.
StreamSnap
StreamSnap מאפשר זמינות גבוהה בכך שהוא מאפשר לכם לשמור עותק מרוחק של האחסון וההגדרות של אפליקציה, כך שהם יהיו עדכניים ומוכנים לתרחיש של מעבר לגיבוי (failover). אם אפליקציה שמנוהלת על ידי StreamSnap נכשלת, אתם מעלים גיבוי למעבר לשעת חירום של האפליקציה מהאתר המרוחק. אחרי שהבעיה תיפתר, תוכלו לשחזר את הגיבוי של syncback לאתר המקומי עם השינויים האחרונים, ואז לבצע מעבר חזרה של האפליקציה לאתר הייצור.
StreamSnap משכפל תמונות מצב של נתונים למכשיר גיבוי או שחזור מרוחק דרך רשת IP עם רוחב פס באיכות גבוהה, שיכול לספק RPO נמוך של שעה אחת.
במכונות וירטואליות של VMware, שכפול תמונת המצב מועבר בסטרימינג למכשיר השני לגיבוי או לשחזור במקביל. הזרמת מכונת VMware וירטואלית מתבצעת כדי לא לחכות עד שהמשימה של צילום התמונה המקומית תסתיים לפני שמתחילים את השכפול.
באפליקציות של מכונות וירטואליות שאינן VMware, השכפול של התמונות מתבצע אחרי שמשימת התמונות המקומיות מסתיימת.
הפקה לשיקוף מדיניות עם שכפול StreamSnap קשורה למדיניות ספציפית של הפקה לצילום תמונת מצב. הם משתמשים בהגדרות של לוח הזמנים והתדירות של ההפקה המשויכת למדיניות ה-snapshot.
אפשר לשמור גיבויים מכמה נקודות זמן זמינות באתר המרוחק על ידי החלת שמירת נתונים במדיניות StreamSnap. כששומרים גיבויים במכשיר המרוחק, גיבוי חדש נוצר במכשיר המרוחק עם תאריך תפוגה שנקבע לפי הגדרות המדיניות. כל גיבוי מרחוק תומך בכל הפעולות שזמינות בגיבוי מקומי כשניגשים אליו דרך מרכז ניהול האפליקציות.
שכפול StreamSnap דורש חיבור רשת אמין כדי לשכפל תמונות מצב של נתונים למכשיר המרוחק. רוחב הפס שנדרש בחיבור לרשת קשור ישירות לגודל האפליקציה (העתק ראשוני) ולגודל השינוי (לעדכונים מצטברים).
טכנולוגיית שכפול נתונים של Backup and DR:
- הגנה על נתונים במקרה של אובדן או נזק פוטנציאליים, במיקומים מרוחקים, במרכזי נתונים ובאזורים גיאוגרפיים שונים. אם מתרחשת הפרעה, שכפול הנתונים מאפשר לחדש במהירות את הגישה לנתונים האלה ואת השימוש בהם.
- השימוש ברוחב הפס ברשת יעיל ככל האפשר בזכות טכנולוגיית הדחיסה.
- מבטל את הצורך במאיץ או בכלי אופטימיזציה ייעודיים של WAN.
- שומר על סדר הכתיבה, גם בכמה LUN בקבוצת עקביות.
- השירות משתלב עם Backup and DR resiliency director.
- הצפנת נתונים באמצעות תקן ההצפנה AES-256. האימות בין מכשירי ה-Appliance מתבצע באמצעות אישורי RSA של 2048 ביט.
שיטות שכפול
תבניות הגיבוי קובעות את השיטה, לוח הזמנים והתדירות של שכפול הנתונים באתר מרוחק. תבנית הגיבוי מגדירה איך להעביר ולאחסן נתונים בצורה יעילה במכשיר הגיבוי או השחזור המרוחק. פרופילי משאבים מגדירים איפה לאחסן את הנתונים. הנתונים יכולים להישמר באופן מקומי או במכשיר גיבוי/שחזור מרוחק שאליו הנתונים ישוכפלו.
אפשר להטמיע שכפול נתונים באמצעות מגוון שיטות שונות:
- שיקוף נתונים: מדיניות שיקוף נתונים מ-Production מגנה על הנתונים באפליקציה או במכונה הווירטואלית מפני כשל באתר, באמצעות שיקוף של עותק מלא של הנתונים באתר Production מרוחק. הבקשות מתעדכנות באופן שוטף, ואפשר להפעיל אותן מחדש בהתראה קצרה באתר המרוחק על ידי גישה לנתונים מהעותק המרוחק של DR. שיקוף נתונים יכול להיחשב כשיכפול שעבר אופטימיזציה לגישה לאתר מרוחק. שיקוף נתונים בין אתר ייצור לאתר משוקף זמין בשיטת השכפול StreamSnap. מידע נוסף מופיע בדף שכפול משרת ייצור לשרת שיקוף.
Snapshot to OnVault and direct to OnVault: מדיניות OnVault שולחת נתונים ברשת אל Cloud Storage. המדיניות הזו מאפשרת לשלוח נתונים של אפליקציות ומכונות וירטואליות לאחסון שמוגדר על ידי מאגר Backup and DR OnVault. מידע נוסף זמין בדף שכפול לאחסון אובייקטים שמוגדר על ידי מאגר Backup and DR OnVault.
אלה היתרונות של כל שיטת שכפול.
| שיטת השכפול | שימוש מומלץ | יתרונות | חסרונות |
|---|---|---|---|
| תמונה במסגרת ל-OnVault או ישירות ל-OnVault | שימור לטווח קצר, בינוני וארוך. | חסכוני
דחיסה מפחיתה את צריכת רוחב הפס הנתונים מוצפנים בזמן ההעברה, ואפשר גם כשהם במצב מנוחה |
שימוש גבוה יותר ברוחב הפס.
אי אפשר להפעיל אפליקציות באחסון שמוגדר על ידי מאגר OnVault. |
| שיקוף נתונים: StreamSnap | התאוששות מאסון (DR) לאפליקציות שנדרש להן RPO קצר יותר. | יעד להתאוששות מאסון (RPO) של שעה בלבד עם גישה כמעט מיידית לנתונים ומעבר לגיבוי בעת כשל
דחיסה והצפנה שכפול של כמויות גדולות של נתונים. שומר גיבויים מכמה נקודות זמן זמינות במכשיר המרוחק אפשר להשתמש בטכנולוגיית StreamSnap לשכפול יומנים בין מכשירים מקומיים ומרוחקים |
צריכת רוחב פס גבוהה יותר |
בחירת מאגר אחסון לנתונים משוכפלים
כדי לבחור את מאגר האחסון של היעד שבו ישמרו נתוני השכפול של StreamSnap:
- לוחצים על הכרטיסייה ניהול ובוחרים באפשרות מכשירי חשמל מהתפריט הנפתח.
- בוחרים מכשיר.
- לוחצים על Configure Appliance (הגדרת מכשיר) כדי לפתוח את הדף Appliance Configuration (הגדרת מכשיר).
- עוברים אל System (מערכת), אל Configuration (הגדרה) ואז אל Appliance Settings (הגדרות המכשיר).
- לוחצים על הכרטיסייה אחסון. יופיע תפריט נפתח שבו תוכלו לבחור את מאגר תמונות המצב של היעד לנתונים משוכפלים שמגיעים למכשיר הגיבוי או השחזור הזה.
(אופציונלי ל-VMware בלבד) אפשר לשנות את ההגדרה הזו למכונות וירטואליות של VMware אם רוצים שהן יועברו למאגר נתונים של ESX במקום זאת. מסמנים את התיבה VM override (שינוי הגדרות של מכונה וירטואלית) ומבצעים את הבחירות הבאות:
- בוחרים את vCenter כדי לנהל את הפעולה. מומלץ ש-vCenter הזה יהיה באתר DR.
- בוחרים מארח ESXi לאירוח המכונות הווירטואליות של VMware. מארח ESXi הזה צריך להיות גם באתר DR, והוא צריך להיות מופעל וזמין בכל זמן. אפשר לבחור רק מארח ESXi אחד.
- בוחרים את מאגרי הנתונים שיכילו את נתוני ה-DR. במאגרי הנתונים צריך להיות מקום לאחסון קובצי ה-VMDK (דיסקים וירטואליים) המשוכפלים. אם בוחרים כמה מאגרי נתונים, מכשיר הגיבוי או השחזור ישתמש בכל אחד מהם בתורו.
מכשיר הגיבוי/השחזור ייצור מכונות וירטואליות חדשות באתר DR באמצעות השם
DR-<original VM name>. לדוגמה, אם המכונה הווירטואלית המקורית נקראת testvm, העותק לשחזור מאסון ייקרא DR-testvm. אם ה-VM כבר קיים והוא כבוי, מכשיר הגיבוי או השחזור משתמש בו כיעד ל-VM המשוכפל.לוחצים על הכפתור האפור שמירת ההגדרות.
הגדרת שכפול של StreamSnap
בהתאם לדרישות שלכם לגבי שיקוף נתוני הייצור לצורך שכפול עותק של הנתונים במכשיר גיבוי/שחזור שני, אתם יכולים לבצע מעבר לגיבוי חלופי של גיבוי שכפול StreamSnap לאתר ייצור נתונים משוקף במכשיר גיבוי/שחזור שני. לאחר מכן, אפשר לשכפל את השינויים שבוצעו באתר DR בחזרה (מעבר חזרה) לסביבת הייצור במכשיר הגיבוי או השחזור המקומי.
- אפשר להשתמש בכמה גיבויים של סנכרון חוזר כדי לשכפל שינויים מצטברים שבוצעו באתר DR בחזרה לסביבת הייצור.
- אפשר להעלות, לשכפל או לשחזר גיבויים של Syncback באתר הייצור כדי לשחזר את הגישה.
כדי לנהל אפליקציה או מכונת VM באמצעות מדיניות שכפול של StreamSnap:
- מוודאים ששני המכשירים מוגדרים ומצורפים (מחליפים אישורי אבטחה), ופועלים במצב שיתוף.
בקטע Backup Plans, יוצרים תבנית שכוללת כל אחד מהפריטים הבאים:
- מדיניות מ-Production אל Snapshot. הפקות שמשקפות מדיניות שמשתמשת באפשרות השכפול StreamSnap קשורות למדיניות ספציפית של תמונת מצב. מדיניות StreamSnap מחייבת את הגדרות התזמון והתדירות של מדיניות הצילום המשויכת בתבנית. לא תוכלו לשמור את מדיניות השכפול של StreamSnap בלי מדיניות בסיסית של תמונת מצב שמשויכת לתבנית.
- מדיניות בנושא העברה מסביבת ייצור לסביבת שיקוף. המדיניות של שיקוף מנתוני הייצור משתמשת בשכפול StreamSnap. גיבויים מרחוק תומכים בכל הפעולות שזמינות בגיבוי מקומי כשניגשים אליהם במרכז ניהול האפליקציות.
בתוכניות הגיבוי, יוצרים פרופיל משאבים שמציין איפה לאחסן את הנתונים באופן מקומי ואיפה לשכפל את הנתונים. אפשר לעיין בדף יצירת פרופיל משאב.
במרכז ניהול האפליקציות, בוחרים את נתוני האפליקציה שרוצים לנהל, ואז מחילים את תבנית המדיניות כדי לנהל אפליקציות או מכונות וירטואליות.
התמונות נוצרות באופן מקומי ומשוכפלות למכשיר מרוחק. הנתונים זמינים במכשיר המרוחק, כך שמתאפשרת גישה מיידית. הגיבויים מופיעים במערכת המרוחקת כשלוחצים על הלחצן Remote Snap בחלון Restore בApp Manager.
בודקים את המעבר לגיבוי במכשיר המרוחק כמו שמתואר במאמר בדיקת מעבר לגיבוי
בהתאם לדרישות השכפול שלכם ליצירת עותק של הנתונים במכשיר שני, אתם יכולים להפעיל את המעבר לגיבוי חלופי של גיבוי שכפול StreamSnap לאתר ייצור במכשיר שני. לאחר מכן, אפשר לשכפל את השינויים שבוצעו באתר DR בחזרה (מעבר חזרה) לסביבת הייצור במכשיר המקומי. פרטים נוספים זמינים בדף מעבר לגיבוי (Failover) וחזרה מגיבוי (Failback).
טיפול בשגיאות במשימות StreamSnap
כשבתבנית גיבוי יש מדיניות שכפול של StreamSnap ומדיניות צילום תמונת מצב, ואתם מחילים את תבנית הגיבוי הזו על אפליקציה או על מכונה וירטואלית, התוצאות של משימת StreamSnap נרשמות במעקב. בזמן ההרצה, משימת StreamSnap מופיעה כמשימה יחידה בMonitor. אחרי שהשכפול מסתיים, שתי משימות מופיעות בMonitor: אחת למשימת התמונה ואחת למשימת StreamSnap.
שימו לב לדרכים הבאות שבהן מכשיר גיבוי או שחזור עוקב אחרי המשימות האלה:
- אם השכפול מצליח, שני ערכים נפרדים של משימות מופיעים ברשימת המשימות בדף משימות עם הסטטוס הושלם. לשתי רשומות העבודות יש את אותו שם עבודה, מלבד העובדה שעבודת StreamSnap כוללת גם סיומת S בשם העבודה שלה.
- אם יש כשל במשימה, בין אם במשימת StreamSnap או במשימת הצילום, יופיעו שני ערכים של משימות ברשימת המשימות בדף משימות כדי לזהות איזו משימה הצליחה ואיזו משימה נכשלה.
שעת ההתחלה ושעת הסיום של רשומת המשימה StreamSnap ושל רשומת המשימה של התמונה המיידית יהיו זהות במרכז הבקרה. הזמן בפועל של שלב הצילום מופיע בדף Statistics של משימת StreamSnap.
בטבלה הבאה מפורטים היסטוריית העבודות והתנהגות הטיפול בשגיאות על סמך ההצלחה או הכישלון של מדיניות הצילום ומדיניות השכפול של StreamSnap כשמשתמשים בהן כדי להגן על אפליקציה.
| תרחיש הגנה | התנהגות של היסטוריית הפעולות |
|---|---|
| גם צילומי המסך וגם משימות StreamSnap מצליחים | שני רשומות נפרדות של משימות יופיעו ברשימת המשימות עם הסטטוס הושלם כשהמשימה תסתיים. לשתי רשומות העבודות יש אותו שם עבודה, מלבד העובדה שעבודת StreamSnap כוללת גם סיומת S בשם העבודה שלה. |
| משימת צילום תמונת מצב מצליחה, משימת StreamSnap נכשלת | לגבי משימת הצילום, מופיע רשומה אחת של משימה ברשימת המשימות עם הסטטוס הושלם.
המערכת מנסה לבצע את העבודה של StreamSnap עד שלוש פעמים. |
| גם הצילום וגם העברת הנתונים נכשלים, אבל המכשיר מנסה שוב | רשומה אחת של משימת StreamSnap מופיעה ברשימת המשימות עם הסטטוס Retried.
אם משימת ה-snapshot מצליחה אבל משימת ה-StreamSnap עדיין נכשלת, נוצרות שתי רשומות של משימות ולא יתבצעו ניסיונות חוזרים נוספים של StreamSnap. |
| גם קובץ ה-snapshot הבודד וגם משימות StreamSnap נכשלים אחרי מספר הניסיונות החוזרים המקסימלי | רשומה אחת של משימת StreamSnap מופיעה ברשימת המשימות עם הסטטוס Failed. |
ניסיונות חוזרים של שכפול StreamSnap
שכפול StreamSnap (SnapReplicate) משכפל תמונת מצב בנקודת זמן של האפליקציה המקורית. מידע נוסף זמין בדף יצירת שכפול של StreamSnap כדי לשקף מדיניות.
יתרונות
שכפול StreamSnap למארחים שונים יכול לפעול במקביל, ולכן השכפול למארחים מרובים יכול להסתיים הרבה יותר מהר.
אם שלב יצירת תמונת המצב של משימת StreamSnap מצליח אבל שלב StreamSnap נכשל, המערכת מנסה שוב את שלב StreamSnap עד שלוש פעמים נוספות לפני שמשימת StreamSnap נכשלת. למשימת StreamSnap יש סיומת של S ואחריה האות a, b או c, שמציינת את מספר הניסיונות החוזרים.
אם עבודת יצירת תמונת המצב נכשלת, מתבצע ניסיון חוזר. אם הניסיון מחדש מצליח, אפשר להמשיך את עבודת השכפול. אם משימת הצילום נכשלת גם אחרי ניסיונות חוזרים, רק אז משימת StreamSnap נכשלת.
כשמריצים משימת StreamSnap חדשה בזמן שמשימת StreamSnap קיימת כבר פועלת, משימת StreamSnap החדשה מפולחת אוטומטית לשתי משימות (snap+replicate) לפני שהיא מתווספת לתור. בתרחיש הזה, החלק של הצילום של המשימה השנייה יכול לפעול במקביל לחלק של השכפול של המשימה השנייה. החלק של השכפול בעבודה השנייה ממתין עד שהעבודה של יצירת תמונת המצב תסתיים לפני שהוא מופעל.
שכפול של תמונות מצב לפי דרישה
מסוף ניהול ה-appliance מאפשר לשכפל את התמונה המקומית או את StreamSnap מכל appliance שמשויך לכל appliance שמשויך באמצעות האפשרות Replicate (שכפול) בתפריט הנפתח של פרטי התמונה. השכפול תמיד יכלול את השינויים מהגיבוי שנבחר לגיבוי האחרון באתר המרוחק. לכן, אם יש כמה גיבויים לשכפול, מומלץ לשכפל אותם מהישן לחדש. אתם יכולים לספק תקופת שמירה משלכם בזמן השכפול של הגיבוי. אפשר לעיין בקטע שכפול גיבוי.
שכפול גיבוי
כדי לשכפל גיבוי:
לוחצים על הכרטיסייה App Manager (המרכז לניהול אפליקציות) ובוחרים באפשרות Applications (אפליקציות) מהרשימה הנפתחת.
ייפתח הדף Applications.
בוחרים את האפליקציה עם הגיבוי שרוצים לשכפל, ואז בוחרים באפשרות גישה מהרשימה הנפתחת בפינה השמאלית התחתונה של הדף אפליקציות. ייפתח הדף Access (גישה) שבו מוצגים הגיבויים שנוצרו בתצוגת ציר הזמן. אפשר לבחור ולשכפל גם גיבויים של תמונת מצב וגם גיבויים מרחוק, כולל גיבויים של StreamSnap.
בוחרים גיבוי ואז בוחרים באפשרות Replicate (שכפול) מתוך רשימת פעולות הגישה.
ייפתח הדף Replicate.
בתפריט הנפתח יעד, בוחרים את מכשיר היעד לשכפול.
בקטע תפוגה, בוחרים אחת מהאפשרויות הבאות לגיבוי המשוכפל החדש:
- זהה למקור: בוחרים באפשרות זהה למקור אם רוצים להגדיר את אותו תאריך תפוגה כמו הגיבוי של המקור.
- שמירה: בוחרים באפשרות שמירה אם רוצים להגדיר את משך התפוגה של הגיבוי המשוכפל בשעות, בימים, בשבועות, בחודשים או בשנים.
- תפוגה בתאריך: בוחרים באפשרות תפוגה בתאריך אם רוצים להגדיר תאריך תפוגה לשכפול.
- Expire on (תפוגה בתאריך): בוחרים באפשרות Expire on (תפוגה בתאריך) ומציינים את תאריך התפוגה של הגיבוי המשוכפל.
- Never Expire (לעולם לא יפוג תוקף): בוחרים באפשרות Never (לעולם לא) אם לא רוצים שהגיבוי המשוכפל יפוג תוקף אף פעם.
לוחצים על שליחה.