בדף הזה יש סקירה כללית על התכונה 'העברת נפח'.
מידע על העברת נפח
התכונה 'העברת נפחים' מאפשרת להעביר נפחים ממקורות מבוססי ONTAP אל Google Cloud NetApp Volumes באמצעות העברה מבוססת SnapMirror. SnapMirror פועל ברמת נפח האחסון ויכול לשכפל נפח מקור לנפח יעד במערכת אחרת.
ל-SnapMirror יש הרבה יתרונות בהשוואה לשיטות רגילות להעתקת נתונים:
הוא פועל בכל רשת IP ועמיד לבעיות ברשת, ותומך במגוון רחב של מהירויות רשת וזמני השהיה.
הוא מעתיק רק את הנתונים שבשימוש.
אחרי העברה ראשונית של נתוני בסיס, ההעברות הבאות הן מצטברות, והמערכת מעתיקה רק את הנתונים שהשתנו ללא הגבלת זמן. החישוב של השינויים בהעברות מצטברות הוא מהיר במיוחד ולא תלוי בסוג הנתונים שמאוחסנים באמצעי האחסון.
ההעברות שומרות על יעילות האחסון. אם נפח המקור מכיל נתונים שבוצעה בהם דה-דופליקציה או דחיסה, היתרונות האלה עוברים הלאה ומקטינים את כמות הנתונים להעברה.
כל ההעברות מוצפנות בזמן ההעברה.
אתם יכולים להשתמש בנפח התנועה מהמקור בלי שתהיה לכך השפעה משמעותית על הביצועים.
אחרי שההעברה הבסיסית מסתיימת, אפשר להשתמש באמצעי האחסון של היעד במצב קריאה בלבד.
כל הנתונים מועברים, כולל מטא-נתונים כמו רשימות מורכבות של בקרת גישה (ACL) וקבצים נעולים.
SnapMirror מעביר נפחי אחסון בין מערכות ONTAP, גם בין מיקומים גיאוגרפיים שונים.
Google Cloud NetApp Volumes משתמש ב-SnapMirror לשכפול נפח בין NetApp Volumes באזורים שונים של Google. בנוסף, אפשר להשתמש ב-SnapMirror כדי לשכפל בין נפחים חיצוניים מבוססי ONTAP לבין נפחי NetApp, וזה נקרא שכפול היברידי.
יש שני סוגים של שכפולים היברידיים:
העברת נפח מיועדת להעברות חד-פעמיות מ-ONTAP אל NetApp Volumes.
שכפול חיצוני מיועד לשכפולים שמתבצעים באופן שוטף לצורך תוכנית התאוששות מאסון (DR), שבהם אפשר להפוך את כיוון השכפול.
סקירה כללית של תהליך המיגרציה
שכפול היברידי מבטיח העברות נתונים מהירות, עקביות ומלאות ממקור ליעד, עם השפעה מינימלית על הסביבה שלכם. התהליך הזה כולל את השלבים הבאים:
אימות
במהלך שלב האימות, אדמינים של אחסון במערכת המקורית של ONTAP צריכים להעניק ל-NetApp Volumes הרשאה לאחזר נפח מהמערכת המקורית. הפעולה הזו מתבצעת באמצעות שלבים אדמיניסטרטיביים במערכת ONTAP של המקור, שנקראים cluster peering ו-SVM peering. תהליך העברת הנפח יוצר את פקודות ONTAP שהאדמינים צריכים להריץ במערכת המקור.
העברה של קבוצת הבסיס
אחרי שמגדירים העברה, תמונת מצב יוצרת נקודת עקביות במערכת המקור. כל הנתונים שצולמו בתמונת המצב הזו, כולל תמונות מצב ישנות יותר, מועברים ל-NetApp Volumes במהלך שלב ראשוני שנקרא העברת בסיס.
העברה של נתוני הבסיס יכולה להימשך דקות, שעות, ימים או שבועות. המשך הזה תלוי בגורמים הבאים:
כמות הנתונים בתמונת המצב.
מהירות הרשת בין מערכת המקור ONTAP לבין NetApp Volumes.
הגדרת התפוקה של NetApp Volumes.
במהלך העברת הבסיס, נפח המקור ממשיך לשרת את עומס העבודה שלכם והנתונים מתווספים, משתנים או נמחקים. השינויים האלה לא משפיעים על התמונה של המצב שמשמשת כנקודת העקביות של תוכנית הבסיס. בזמן שהבסיס מתבצע, נפח היעד לא זמין ללקוחות. אחרי שההעתקה הראשונית מסתיימת, נפח היעד עובר למצב אונליין וזמין לגישת לקוח במצב קריאה בלבד. שימו לב שלנפח היעד יהיה כתובת IP שונה.
בניגוד לשכפול נפח, העברה של נפח לא יכולה לקרוא את הפרמטרים של נפח המקור, כמו גודל, בחירות פרוטוקול ומדיניות ייצוא או צילום תמונת מצב. לכן, צריך להגדיר את ההגדרות האלה בצורה נכונה עבור נפח היעד.
עכשיו אפשר להתחיל לצרף או למפות את נפח האחסון של היעד למכונות וירטואליות כדי להתכונן לסיום ההעברה.
העברות מצטברות
אחרי שההעברה הבסיסית תושלם, המיגרציה תפעיל העברות מצטברות מדי שעה.
בכל העברה מצטברת מתבצעות הפעולות הבאות:
מצלם תמונת מצב חדשה של נפח המקור.
הפונקציה מחשבת את השינויים בנתונים בין התמונה הנוכחית לבין התמונה הקודמת.
מתחיל להעביר את השינויים האלה ליעד.
אם מתרחשים הרבה שינויים מאז תמונת המצב של קו הבסיס, וההעברה המצטברת עדיין פועלת כשההעברה הבאה לפי שעה מתוזמנת, ההעברה הזו תדלג. בהעברה המצטברת הבאה, המערכת מצלמת תמונה חדשה של המקור, מוחקת את התמונה הכי ישנה של SnapMirror, מחשבת את השינויים ומעבירה אותם.
לקוחות שמטמיעים את אמצעי האחסון של היעד רואים תצוגה לקריאה בלבד עם תוכן סטטי. עם זאת, אחרי שההעברה המצטברת מסתיימת, התוכן של אמצעי האחסון מתעדכן באופן מיידי מהתמונה הקודמת של השכפול לתמונה האחרונה, באמצעות פעולה אטומית אחת.
אלא אם כמות הנתונים החדשים שנוספו לנפח המקור חורגת ממה שאפשר להעביר בתוך שעה, הגודל של ההעברה המצטברת קטן עם כל העברה מוצלחת. התהליך הזה נמשך עד שהקצב מתייצב על קצב שמוגדר על ידי קצב השינוי השעתי של נפח המקור, וזה עשוי לקחת כמה איטרציות. אחרי שמגיעים למצב יציב, אפשר לתזמן מעבר. כדי למזער את זמן ההשבתה הנדרש במהלך המעבר החד למערכת אחרת (cutover), המטרה היא לצמצם את השינויים בין נפחי האחסון של המקור והיעד.
מעבר חד למערכת אחרת (cutover)
במהלך מעבר, אתם מעבירים את עומסי העבודה מהנפח של המקור לנפח של היעד בלי לאבד נתונים (RPO = 0) ועם זמן השבתה מינימלי (RTO). תהליך המעבר כולל את שלבי המשנה הבאים:
הפסקת השינויים
העברות מצטברות הן אסינכרוניות, ולכן יכול להיות שבנפח המקור יש שינויים שעדיין לא משתקפים בנפח היעד. כדי לסנכרן, צריך להפסיק את כל השינויים בווליום המקור על ידי:
הפסקת כל האפליקציות שמשנות נתונים.
אופציונלי: משנים את הרשאות הגישה לנפח האחסון לקריאה בלבד כדי למנוע מכל לקוח לשנות את הנתונים.
המתנה להעברה הנוכחית
מוודאים שכל ההעברות המצטברות שפועלות הושלמו.
ביצוע העברה ידנית מצטברת
מבצעים העברה מצטברת ידנית כדי לשלוח את הנתונים העדכניים למערכת היעד. הפעולה אמורה להימשך כמה שניות עד כמה דקות, בהתאם לנפח הנתונים שהשתנו מאז ההעברה האחרונה, מהירות הרשת ומגבלות התפוקה של נפחי היעד.
אחרי שההעברה המצטברת הידנית מסתיימת, הנתונים העדכניים ביותר זמינים ביעד.
הפסקת השכפול
מריצים את פעולת העצירה על השכפול כדי להפוך את עוצמת הקול של היעד לקריאה וכתיבה. כך מסיימים את העברת הנתונים.
הגדרה מחדש והפעלה מחדש של אפליקציות
צריך להגדיר מחדש את האפליקציות כך שישתמשו בנפח היעד ואז להפעיל אותן מחדש. חשוב לוודא שכל הגישה לנתונים בווליום המקור הופסקה כדי למנוע שימוש מקרי בווליום המקור על ידי אפליקציה כלשהי.
הסרת המשאבים
אם המעבר הושלם בהצלחה, אפשר לבצע את שלבי הניקוי הבאים:
מחיקת שכפול שהופסק: כשמוחקים את השכפול שהופסק, משאב השכפול נמחק אבל נפח האחסון של היעד לא נמחק. במהלך התהליך הזה נמחק גם קשר ה-SnapMirror שבו נעשה שימוש בקצה העורפי עם מערכת המקור.
הסרת שיוך בין מקבצים: אם זה היה קשר ה-SnapMirror האחרון בין NetApp Volumes לבין מקבץ המקור, אפשר להסיר את השיוך בין המקבצים ממערכת ONTAP של המקור. בנוסף, אפשר להסיר כל רשת שהוגדרה רק למטרות העברה בין המקור ליעד.