שכפול של נתוני העותק לאחסון מרוחק מגן על הנתונים במקרה של אסון באתר הראשי, ומפחית את כמות האחסון הנדרשת באתר הראשי. המטרה של הרפליקציה היא להחזיר את הנתונים במצבים של אובדן נתונים והשפעה על מערכות הייצור, בגלל בעיות כמו כשל בחומרה, בעיות בתוכנה או אירוע באתר. שכפול נתונים תומך גם ביצירת עותקים מרוחקים של נתוני בדיקה/פיתוח, אבטחת איכות וניתוח. אפשר לשכפל נתונים ממכשיר גיבוי/שחזור אחד למכשיר שני (מרוחק) או לענן למטרות שחזור, תוכנית התאוששות מאסון (DR) או בדיקה ופיתוח.
התבניות לגיבוי נתונים קובעות את השיטה, לוח הזמנים והתדירות של שכפול הנתונים לאתר מרוחק. התבנית לגיבוי נתונים מגדירה איך להעביר ולאחסן נתונים ביעילות במכשיר הגיבוי או השחזור המרוחק. שכפול הנתונים נשלט על ידי כללי המדיניות של התבניות הנפרדות:
כללי המדיניות "ייצור לשיקוף" מגינים על נתוני האפליקציה או המכונה הווירטואלית מפני כשל באתר, על ידי שיקוף של עותק מלא של הנתונים האלה לאתר ייצור מרוחק. האפליקציות מתעדכנות כל הזמן, ואפשר להפעיל אותן מחדש בהתראה קצרה באתר המרוחק על ידי גישה לנתונים מהעותק המרוחק של ה-DR. אפשר להתייחס לשיקוף נתונים כאל שכפול עם אופטימיזציה של גישה לאתר מרוחק. פרטים נוספים זמינים במאמר שכפול מדיניות מסביבת הייצור לסביבת השיקוף.
כללי המדיניות של Snapshot to OnVault משתמשים בחיבור HTTPS כדי לשלוח נתונים לאחסון שמוגדר על ידי OnVault Pool. אפשרות הדחיסה מופעלת כברירת מחדל במאגרי OnVault. פרטים נוספים זמינים בקטע שליחת קובצי Snapshot למאגר אחד או יותר של OnVault.
שליחת קובצי snapshot למאגר אחד או יותר של OnVault
המדיניות "תמונת מצב ל-OnVault" מאפשרת לשלוח נתונים של תמונת מצב למיקום שמוגדר על ידי מאגר OnVault. לוח הזמנים שבמדיניות משמש לשליחת תמונת המצב האחרונה שנוצרה על ידי המדיניות של תבנית המדיניות "ייצור לתמונת מצב" למיקום שמוגדר על ידי מאגר OnVault. בדרך כלל משתמשים במאגר האחסון של OnVault לשמירה לטווח ארוך. לפרטים על מאגר OnVault, קראו את המאמר שליחת תמונות מצב למאגר OnVault אחד או יותר.
כששולחים נתונים לאחסון שמוגדר על ידי מאגר OnVault, משתמשים בחיבור HTTPS כדי להבטיח את אבטחת הנתונים ברשת. אפשרות הדחיסה של מאגר OnVault מופעלת כברירת מחדל כדי לצמצם את התנועה ברשת.
אחרי ההטמעה הראשונית של קובץ ה-snapshot המלא, רק השינויים בנתונים נשלחים למאגר OnVault. זהו אותו מודל מצטבר תמידי שמשמש כללי מדיניות אחרים.
כשניגשים לנתונים במאגר של מאגר OnVault, חשוב לשים לב לנקודות הבאות:
מכשירים לגיבוי או לשחזור יכולים ליצור שיבוטים.
אי אפשר ליצור LiveClones.
OnVault למספר מאגרי OnVault
אפשר לשלוח נתוני אפליקציות לכמה יעדי OnVault בענן. כל יעד OnVault נשלט על ידי כללי מדיניות נפרדים, כך שתדירות העדכון ותקופות השמירה יכולות להיות שונות (למשל, עדכונים מקומיים תכופים עם תקופת שמירה קצרה, יחד עם עדכונים פחות תכופים לענן עם תקופת שמירה ארוכה).
אפשר להשתמש ב-Multi-target OnVault בכל סוגי האפליקציות, כולל Direct-to-OnVault עם מכונות וירטואליות של VMware. במקרה כזה, הנתונים נכתבים ישירות למאגר OnVault הראשון, תוך עקיפת מאגר קובצי ה-snapshot, ואז נקראים ממאגר OnVault הראשון ונשלחים לאחרים.
שכפול מדיניות מסביבת הייצור לסביבת השיקוף
מדיניות של שכפול בסביבת ייצור מספקת אמצעי לשכפול עותק של נתוני האפליקציה או המכונה הווירטואלית למכשיר גיבוי/שחזור יעד, וגישה לנתונים ללא חלון שחזור, מה שמאפשר RTO נמוך מאוד. במקרה הצורך, תוכלו לבצע מעבר חזרה לאתר הייצור עם קבוצת נתונים זהה שמשוכפלת בין מכשירי הגיבוי/השחזור המקומיים והמרוחקים.
StreamSnap
StreamSnap מאפשר זמינות גבוהה בכך שהוא מאפשר לשמור עותק מרוחק של האחסון וההגדרות של האפליקציה, כשהוא מעודכן ומוכן לתרחיש של יתירות כשל. אם אפליקציה שמנוהלת על ידי StreamSnap נכשלת, אתם יכולים לטעון גיבוי יתירות כשל של האפליקציה מהאתר המרוחק. אחרי שהבעיה נפתרה, אפשר לשחזר את הגיבוי של הסנכרון החוזר לאתר המקומי עם השינויים האחרונים, ואז להחזיר את האפליקציה לאתר הייצור.
StreamSnap משכפל תמונות מצב של נתונים למכשיר גיבוי/שחזור מרוחק דרך רשת IP עם רוחב פס באיכות גבוהה, שיכולה לספק יעדי נקודת שחזור (RPO) של שעה אחת בלבד.
במכונות וירטואליות של VMware, שכפול תמונת המצב מועבר במקביל למכשיר הגיבוי/השחזור השני. כדי לא להמתין עד להשלמת המשימה של קובץ ה-snapshot המקומי לפני התחלת הרפליקציה, מתבצע סטרימינג של מכונת VMware וירטואלית.
באפליקציות של מכונות וירטואליות שהן לא של VMware, שכפול קובץ ה-snapshot מתרחש אחרי שהמשימה של קובץ ה-snapshot המקומי מסתיימת.
כללי מדיניות של ייצור לשיקוף עם שכפול של StreamSnap קשורים לכללי מדיניות ספציפיים של ייצור לתמונת מצב. הם משתמשים בהגדרות לוח הזמנים והתדירות של המדיניות המשויכת ליצירת תמונת מצב של סביבת הייצור.
כדי לשמור גיבויים מכמה נקודות זמן זמינות באתר המרוחק, אפשר להחיל מדיניות שמירה ב-StreamSnap. כששומרים גיבויים במכשיר המרוחק, נוצר גיבוי חדש במכשיר המרוחק עם תאריך תפוגה שנקבע בהגדרות המדיניות. כל גיבוי מרחוק תומך בכל הפעולות שזמינות בגיבוי מקומי כשניגשים אליו ממנהל האפליקציות.
כדי לשכפל תמונות מצב של נתונים למכשיר המרוחק, צריך חיבור יציב לרשת. רוחב הפס שנדרש בחיבור לרשת קשור ישירות לגודל האפליקציה (העתקה ראשונית) ולכמות השינויים (לעדכונים מצטברים).
טכנולוגיית רפליקציית נתונים של Backup and DR:
- הגנה על הנתונים במקרה של אובדן או נזק פוטנציאליים, במיקומים מרוחקים, במרכזי נתונים ובאזורים גיאוגרפיים שונים. אם מתרחשת הפרעה, שכפול הנתונים מאפשר לחדש במהירות את הגישה לנתונים ואת השימוש בהם.
- שימוש יעיל ברוחב הפס של הרשת באמצעות טכנולוגיית דחיסה.
- מבטל את הצורך במאיץ או בכלי אופטימיזציה ייעודי של WAN.
- שמירה על סדר הכתיבה, גם בכמה מספרי LUN בקבוצת אפליקציות עקביות.
- משתלב עם מנהל העמידות של Backup and DR.
- הצפנת נתונים באמצעות תקן ההצפנה AES-256. האימות בין המכשירים מתבצע באמצעות אישורי RSA של 2048 ביט.
שיטות שכפול
התבניות לגיבוי נתונים קובעות את השיטה, לוח הזמנים והתדירות של שכפול הנתונים לאתר מרוחק. התבנית לגיבוי נתונים מגדירה איך להעביר ולאחסן נתונים ביעילות במכשיר הגיבוי/השחזור המרוחק. פרופילי המשאבים מגדירים איפה לאחסן את הנתונים. אפשר לאחסן נתונים באופן מקומי או במכשיר גיבוי/שחזור מרוחק שאליו הנתונים ישוכפלו.
אפשר להטמיע שכפול נתונים במגוון שיטות:
- שיקוף נתונים: כללי מדיניות של שיקוף נתונים מסביבת הייצור מגנים על נתוני האפליקציה או המכונה הווירטואלית מפני כשל באתר, באמצעות שיקוף של עותק מלא של הנתונים האלה לאתר ייצור מרוחק. האפליקציות מתעדכנות כל הזמן, ואפשר להפעיל אותן מחדש באופן מיידי באתר המרוחק על ידי גישה לנתונים מהעותק המרוחק של ה-DR. אפשר להתייחס לשיקוף נתונים כאל שכפול עם אופטימיזציה של הגישה לאתר מרוחק. אפשר לשכפל נתונים בין אתר ייצור לאתר משוכפל באמצעות שיטת השכפול StreamSnap. מידע נוסף זמין בדף רפליקציה של סביבת הייצור לסביבת המראה.
תמונת מצב ל-OnVault וישירות ל-OnVault: כללי המדיניות של OnVault שולחים נתונים דרך הרשת ל-Cloud Storage. כללי המדיניות האלה מאפשרים לשלוח נתונים של אפליקציות ומכונות וירטואליות לאחסון שמוגדר על ידי מאגר OnVault של Backup and DR. מידע נוסף זמין בדף שכפול למאגר אובייקטים שמוגדר על ידי מאגר OnVault של Backup and DR.
אלה היתרונות של כל שיטת שכפול.
| שיטת הרפליקציה | שימוש מומלץ | יתרונות | חסרונות |
|---|---|---|---|
| תמונת מצב ל-OnVault או ישירות ל-OnVault | שימור לטווח קצר, בינוני וארוך. | משתלם
הדחיסה מפחיתה את צריכת רוחב הפס הנתונים מוצפנים בזמן ההעברה, ואפשר גם להצפין אותם במנוחה |
שימוש גבוה יותר ברוחב הפס.
אי אפשר להריץ אפליקציות באחסון שמוגדר על ידי מאגר OnVault. |
| סנכרון נתונים: StreamSnap | תוכנית התאוששות מאסון (DR) לאפליקציות שדורשות RPO קצר יותר. | יעד להתאוששות מאסון (RPO) של שעה בלבד, עם גישה כמעט מיידית לנתונים ויתירות כשל
דחוס ומוצפן משכפל גם כמויות גדולות של נתונים. שומר גיבויים מכמה נקודות זמן זמינות במכשיר המרוחק אפשר להשתמש בטכנולוגיית StreamSnap לשכפול יומנים בין מכשירים מקומיים ומרוחקים |
צריכת רוחב פס גבוהה יותר |
בחירת Storage Pool לנתונים משוכפלים
כדי לבחור את מאגר האחסון של היעד שבו יישמרו נתוני הרפליקציה הנכנסים של 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 כבר קיים והוא כבוי, מכשיר הגיבוי/השחזור משתמש בו כיעד למכונות הווירטואליות המשוכפלות.לוחצים על הכפתור האפור שמירת ההגדרות.
הגדרת רפליקציה של StreamSnap
בהתאם לדרישות שלכם לגבי שיקוף של סביבת הייצור כדי לשכפל עותק של הנתונים למכשיר גיבוי/שחזור שני, אתם יכולים לבצע את יתירות הכשל של גיבוי שכפול של StreamSnap לאתר ייצור נתונים משוכפל במכשיר גיבוי/שחזור שני. לאחר מכן, אפשר לשכפל את השינויים שבוצעו באתר ה-DR בחזרה (failback) לסביבת הייצור במכשיר הגיבוי/השחזור המקומי.
- אפשר להשתמש בכמה גיבויים של סנכרון חוזר כדי לשכפל את השינויים המצטברים שבוצעו באתר ה-DR בחזרה לסביבת הייצור.
- אפשר לטעון, לשכפל או לשחזר גיבויים של Syncback באתר הייצור כדי לשחזר את הגישה.
כדי לנהל אפליקציה או VM באמצעות מדיניות שכפול של StreamSnap:
- מוודאים ששני המכשירים מוגדרים ומחוברים (מחליפים אישורי אבטחה) ופועלים במצב שיתוף.
ב-Backup Plans, יוצרים תבנית שכוללת אחד מכל אחד מהפריטים הבאים:
- מדיניות המעבר מסביבת הייצור לסביבת תמונת המצב. מדיניות הייצור לשיקוף שמשתמשת באפשרות השכפול של StreamSnap קשורה למדיניות ספציפית של תמונת מצב. דרישות המדיניות של StreamSnap כוללות את הגדרות התזמון והתדירות של מדיניות ה-snapshot המשויכת בתבנית. לא תוכלו לשמור את מדיניות הרפליקציה של StreamSnap בלי מדיניות בסיסית משויכת של תמונת מצב בתבנית.
- מדיניות בנושא סביבת ייצור וסביבת Mirror. המדיניות של סביבת הייצור לשיקוף משתמשת ברפליקציה של StreamSnap. גיבויים מרחוק תומכים בכל הפעולות שזמינות בגיבוי מקומי כשניגשים אליהם דרך מנהל האפליקציות.
ב-Backup Plans, יוצרים פרופיל משאבים שמציין איפה לאחסן את הנתונים באופן מקומי ואיפה לשכפל אותם. איך יוצרים פרופיל משאבים
ב-App Manager, בוחרים את נתוני האפליקציה שרוצים לנהל, ואז מחילים את תבנית המדיניות כדי לנהל אפליקציות או מכונות וירטואליות.
תמונות המצב נוצרות באופן מקומי ומשוכפלות למכשיר מרוחק. הנתונים זמינים במכשיר המרוחק כדי לספק את הגמישות של גישה מיידית. הגיבויים מופיעים במערכת המרוחקת כשלוחצים על הלחצן Remote Snap בחלון Restore ב-App Manager.
בודקים את יתירות הכשל למכשיר המרוחק, כמו שמתואר בקטע בדיקת יתירות כשל.
בהתאם לדרישות שלכם לגבי שכפול עותק של הנתונים למכשיר שני, אתם יכולים לבצע יתירות כשל של גיבוי שכפול של StreamSnap לאתר ייצור במכשיר שני. לאחר מכן, אפשר לשכפל את השינויים שבוצעו באתר ה-DR בחזרה (failback) לסביבת הייצור במכשיר המקומי. לפרטים, ראו את הדף מעבר לגיבוי בעת כשל וחזרה למצב תקין.
טיפול בשגיאות במשימות של StreamSnap
כשמחילים על אפליקציה או על מכונה וירטואלית תבנית לגיבוי נתונים שכוללת מדיניות שכפול של StreamSnap ומדיניות של תמונת מצב, הכלי למעקב מתעד את התוצאות של משימת StreamSnap. בזמן שהיא פועלת, משימת StreamSnap מופיעה כמשימה אחת ב-Monitor. בסיום הרפליקציה, שתי משימות מופיעות ב-Monitor: אחת למשימת הסנאפשוט והשנייה למשימת StreamSnap.
שימו לב לדרכים הבאות שבהן מכשיר הגיבוי/השחזור עוקב אחרי המשימות האלה:
- אם הרפליקציה מצליחה, שני פריטי משימות נפרדים מופיעים ברשימת המשימות בדף Jobs עם הסטטוס Succeeded. לשתי המשימות יש את אותו Job Name, אבל למשימת StreamSnap יש גם את הסיומת S ב-Job Name.
- אם משימה נכשלת, בין אם זו משימת StreamSnap או משימת תמונת מצב, שתי רשומות של משימות מופיעות ברשימת המשימות בדף Jobs כדי לזהות איזו משימה הצליחה ואיזו נכשלה.
שעות ההתחלה והסיום של רשומת המשימה של StreamSnap ושל רשומת המשימה של תמונת המצב יהיו זהות ב-Monitor. משך הזמן בפועל של שלב תמונת המצב מופיע בדף Statistics של משימת StreamSnap.
בטבלה הבאה מפורטת ההתנהגות של היסטוריית המשימות והטיפול בשגיאות, בהתאם להצלחה או לכישלון של מדיניות הסנאפשוט ומדיניות הרפליקציה של StreamSnap כשמשתמשים בהן כדי להגן על אפליקציה.
| תרחיש הגנה | התנהגות היסטוריית הפעולות |
|---|---|
| שתי המשימות, של תמונת המצב ושל StreamSnap, מסתיימות בהצלחה | שתי משימות נפרדות מופיעות ברשימת המשימות עם הסטטוס Succeeded כשהמשימה מסתיימת. לשתי הרשומות של המשימות יש את אותו Job Name, אבל למשימה של StreamSnap יש גם את הסיומת S ב-Job Name. |
| משימת Snapshot מצליחה, משימת StreamSnap נכשלת | למשימת הסנאפשוט, רשומת משימה אחת מופיעה ברשימת המשימות עם הסטטוס Succeeded.
המערכת מנסה להפעיל את משימת 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, שמציינות את מספר הניסיונות החוזרים.
אם משימת תמונת המצב נכשלת, המערכת מנסה שוב. אם הניסיון החוזר מצליח, אפשר להמשיך במשימת השכפול. רק אם משימת ה-snapshot נכשלת גם אחרי ניסיונות חוזרים, משימת ה-StreamSnap נכשלת.
כשמפעילים משימת StreamSnap חדשה בזמן שמשימת StreamSnap קיימת כבר פועלת, המשימה החדשה מפוצלת באופן אוטומטי לשתי משימות (snap+replicate) לפני שהיא נכנסת לתור. בתרחיש הזה, החלק של ה-snap במשימה השנייה יכול לפעול במקביל לחלק של ה-replicate במשימה השנייה. החלק של השכפול במשימה השנייה ממתין עד שהמשימה של קובץ ה-Snapshot תסתיים, ורק אז הוא מופעל.
שכפול תמונת מצב על פי דרישה
במסוף לניהול המכשיר, אתם יכולים לשכפל את קובץ ה-snapshot המקומי או את ה-StreamSnap מכל מכשיר מותאם לכל מכשיר מותאם, באמצעות האפשרות Replicate מהתפריט הנפתח בקטע של פרטי קובץ האימג'. הרפליקציה תמיד תהיה השינויים מהגיבוי שנבחר לגיבוי האחרון באתר המרוחק. לכן, אם יש כמה גיבויים שצריך לשכפל, מומלץ לשכפל אותם מהישן ביותר לחדש ביותר. אתם יכולים לציין תקופת שמירה משלכם בזמן שכפול הגיבוי. מידע נוסף מופיע בקטע שכפול גיבוי.
שכפול גיבוי
כדי לשכפל גיבוי, פועלים לפי ההוראות הבאות:
לוחצים על הכרטיסייה App Manager ובוחרים באפשרות Applications מהרשימה הנפתחת.
הדף Applications ייפתח.
בוחרים את האפליקציה עם הגיבוי שרוצים לשכפל, ואז בוחרים באפשרות Access מהרשימה הנפתחת בפינה הימנית התחתונה של הדף Applications. נפתח הדף Access, שבו מופיעה רשימה של הגיבויים שנוצרו בתצוגת ציר הזמן. אפשר לבחור ולשכפל גם גיבויים של תמונות מצב וגם גיבויים מרחוק, כולל גיבויים של StreamSnap.
בוחרים גיבוי ואז בוחרים באפשרות Replicate מרשימת פעולות הגישה.
הדף Replicate נפתח.
בתפריט הנפתח Destination, בוחרים את מכשיר היעד לרפליקציה.
בקטע Expiration, בוחרים אחת מהאפשרויות הבאות לגיבוי המשוכפל החדש:
- Same as source: בוחרים באפשרות Same as Source כדי להגדיר את אותו תאריך תפוגה כמו של גיבוי המקור.
- Retain: בוחרים באפשרות Retain כדי להגדיר את משך הזמן עד לתפוגה של הגיבוי המשוכפל בשעות, ימים, שבועות, חודשים או שנים.
- Expire on: בוחרים באפשרות Expire on אם רוצים להגדיר תאריך תפוגה ספציפי לרפליקה.
- Expire on: בוחרים באפשרות Expire on ומציינים את תאריך התפוגה של הגיבוי המשוכפל.
- Never Expire: בוחרים באפשרות Never אם לא רוצים שהתוקף של הגיבוי המשוכפל יפוג אף פעם.
לוחצים על שליחה.