בדף הזה מוסבר איך ליצור העברה בכמות גדולה.
לפני שמתחילים
לפני שמגדירים העברה של נפח גדול של נתונים, מומלץ לעיין בתהליך העבודה של ההעברה. תהליך העברת נפח האחסון מתחיל ביצירת נפח אחסון ליעד וציון פרטי מערכת המקור. הפעולה הזו יוצרת משאב של נפח יעד ומשאב צאצא של שכפול ב-NetApp Volumes לניהול השכפול.
לתשומת ליבכם
התכונות הבאות לא נתמכות בנפחי היעד במהלך תהליך ההעברה:
שכפול נפח, נפח היעד כמקור לקסקדה. אפשר להפעיל שכפול של נפח אחסון אחרי המיגרציה.
רמת השירות של Flex File.
אפשר להעביר FlexGroups לנפח אחסון גדול. ברמת השירות Flex Unified, מאגר היעדים חייב להיות מאגר בעל קיבולת גדולה.
כשמגבים נפחי יעד, צריך להשתמש בגיבויים ידניים. אם תנסו להקצות מדיניות גיבוי לנפח יעד, הפעולה תיכשל.
בוחרים את מאגר האחסון הנכון ומוודאים שהנפח של יעד ההעתקה גדול מספיק כדי להכיל את הגודל הלוגי (לא הגודל הפיזי) של נפח המקור.
מציינים את שם השיתוף הנכון ואת סוגי הפרוטוקולים. שם השיתוף חייב להיות זהה למקור, וצריך לבחור בקפידה את סוגי הפרוטוקולים כי אי אפשר לשנות אותם אחרי יצירת אמצעי האחסון. הגדרות הפרוטוקול שתבחרו ימופו גם לסגנונות אבטחה של נפח.
מוודאים שסגנון האבטחה של עוצמת הקול של עוצמת הקול של היעד שאתם יוצרים תואם לסגנון האבטחה של עוצמת הקול של המקור.
לפני שיוצרים העברה של נפח, צריך לוודא שיש לכם גישה ל-CLI והרשאות נדרשות במערכת המקורית של ONTAP. צריך להריץ פקודות CLI במערכת ONTAP של המקור תוך שעה מתהליך ההעברה.
אי אפשר להעביר נפח עם תמונות מצב חסינות לשינויים לנפח שמשתמש בסיווג אוטומטי לרמות אחסון.
אי אפשר להעביר נפח מקור לכמה יעדים באותו פרויקט בו-זמנית.
יצירת העברה של נפח אחסון
כדי ליצור העברת נפח אחסון באמצעות מסוףGoogle Cloud או Google Cloud CLI, פועלים לפי ההוראות הבאות.
המסוף
נכנסים לדף NetApp Volumes במסוף Google Cloud .
בתפריט הגנה על נתונים, לוחצים על העברות.
לוחצים על העברה מ-ONTAP.
בקטע Destination volume details (פרטים על נפח היעד), מזינים את השם של נפח היעד בשדה Destination volume name (שם נפח היעד).
בקטע פרטים של מאגר אחסון, לוחצים על בחירת מאגר אחסון.
מהרשימה של מאגרי האחסון שמוצגת, בוחרים את מאגר האחסון הנדרש.
לוחצים על בחירה.
בקטע פרטי נפח האחסון, מזינים את שם השיתוף של נפח האחסון בשדה שם השיתוף. השם של השיתוף חייב להיות ייחודי במיקום. מומלץ להשתמש בשם של נפח היעד בתור שם השיתוף.
בקטע Capacity configuration, מזינים את נפח הקיבולת בשדה Capacity.
בקטע Protocol configuration, בוחרים את אותו פרוטוקול כמו נפח המקור. בפרוטוקולים מסוימים מוצגות אפשרויות שונות. מידע נוסף על אפשרויות הפרוטוקול זמין במאמר בנושא יצירת נפח חדש.
אופציונלי: בקטע Snapshot configuration (הגדרת תמונת מצב), מבצעים את השלבים הבאים:
בוחרים באפשרות הצגת ספריית תמונות המצב כדי לאפשר ללקוחות גישה למערכת הקבצים לגרסאות של תמונות מצב. מידע נוסף מופיע במאמר סקירה כללית על תמונות מצב של נפחים ב-NetApp Volumes.
בוחרים באפשרות Allow scheduled snapshots (מתן הרשאה לצילום תמונות מצב מתוזמן) כדי להגדיר את עוצמת הקול לצילום תמונות מצב באופן אוטומטי. אפשר לציין את מספר התמונות לשימור במרווחי זמן של שעה, יום, שבוע וחודש. השעות מצוינות לפי שעון UTC. אם תגיעו למספר המקסימלי של תמונות מצב, תמונת המצב הכי ישנה תימחק.
בודקים את הבחירות של תמונות המצב.
לוחצים על הבא.
בקטע פרטי ההעברה, מזינים שם למשאב ההעברה בשדה שם ההעברה.
לוחצים על הבא.
בקטע פרטי אשכול המקור, מבצעים את הפעולות הבאות:
מזינים את שם אשכול המקור בשדה שם האשכול.
מזינים את השם של Storage Virtual Machine (SVM), שנקרא גם vserver, בשדה Storage VM name (שם מכונת ה-VM לאחסון). ה-SVM שמארח את נפח האחסון של המקור.
מזינים את השם של נפח האחסון של המקור בשדה שם נפח האחסון.
מזינים את כתובת ה-IP של Intercluster-LIF (IC-LIF) בשדה Inter-cluster IP. לכל צומת באשכול המקור נדרש IC-LIF. מציינים את כל ממשקי IC-LIF כרשימה מופרדת בפסיקים.
אופציונלי: מזינים תיאור של המיקום של אשכול המקור בשדה מיקום.
לוחצים על 'הבא'.
בודקים את ההגדרות ולוחצים על יצירה כדי להתחיל בתהליך ההעברה.
אחרי שיוצרים את תהליך ההעברה, מועברים לתצוגת הפרטים של הנפח. לוחצים על הכרטיסייה העברה כדי לעקוב אחרי סטטוס ההעברה.
צריך לאמת את חיבור SnapMirror בין מערכת ONTAP המקורית לבין NetApp Volumes. מריצים את הפקודה cluster peer create באשכול המקור ONTAP. אם אין פירינג קודם, הערך Migration pending cluster peering from ONTAP source cluster מופיע בכרטיסייה Migration.
אם לוחצים על Initiate peering (הפעלת שירותי peering), מוצג דף צד עם הוראות. פועלים לפי ההוראות האלה ולוחצים על Check peering (בדיקת שיתוף פעולה). אחרי שההתאמה תצליח, דף הצד ייעלם וסטטוס ההעברה ישתנה להכנה. ההעברה של נתוני הבסיס מתבצעת עכשיו. העברה בסיסית יכולה להימשך דקות, שעות או ימים, בהתאם לכמות הנתונים שצריך להעביר ולמהירות הרשת. אחרי שההעברה הבסיסית תושלם, סטטוס ההעברה ישתנה למשוקף.
gcloud
כדי ליצור העברה של נפח:
gcloud netapp volumes create VOLUME_NAME --location=LOCATION \ --capacity=CAPACITY --protocols=PROTOCOL \ --share-name=SHARE_NAME --storage-pool=STORAGE_POOL \ --hybrid-replication-parameters=cluster-location=CLUSTER_LOCATION,peer-cluster-name=PEER_CLUSTER_NAME,peer-ip-addresses=PEER_IP_ADDRESSES,peer-svm-name=PEER_SVM_NAME,peer-volume-name=PEER_VOLUME_NAME,replication=REPLICATION,description=DESCRIPTION,labels=LABELS
הבלוק hybrid-replication-parameters מתחיל תהליך עבודה של העברה.
מחליפים את המידע הבא:
VOLUME_NAME: שם אמצעי האחסון. השם הזה חייב להיות ייחודי לכל מיקום.
LOCATION: המיקום של אמצעי האחסון.
CAPACITY: הקיבולת של הווליום. הוא מגדיר את הקיבולת שמוצגת ללקוחות NAS.
PROTOCOLS: פרוטוקולי ה-NAS שבאמצעותם מיוצא נפח האחסון.
SHARE_NAME: נתיב הייצוא של NFS או שם השיתוף של SMB של אמצעי האחסון.
STORAGE_POOL: מאגר האחסון שבו ייצור הכרך.
PEER_CLUSTER_NAME: השם של אשכול ONTAP שמארח את נפחי המקור.
PEER_IP_ADDRESSES: כתובות ה-IP של InterCluster-LIF של אשכול ONTAP. בכל צומת באשכול המקור צריך להיות IC-LIF אחד, מופרד באמצעות סימני #. חשוב לציין את כולם.בדוגמה הבאה אפשר לראות איך מוסיפים כמה כתובות IP של IC-LIF של אשכול ONTAP:
peer-ip-addresses=10.0.0.25#10.0.0.26
PEER_SVM_NAME: השם של המכונה הווירטואלית לאחסון (SVM), שנקראת גם vserver, שהיא הבעלים של נפח האחסון של המקור.
PEER_VOLUME_NAME: השם של נפח האחסון של המקור.
REPLICATION: השם של משאב השכפול שרוצים ליצור.
LARGE_VOLUME_CONSTITUENT_COUNT: הפרמטר הזה נדרש רק אם נפח המקור הוא FlexGroup. מידע נוסף זמין במאמר בנושא FlexGroups ונפחים גדולים.כדי ליצור נפח גדול, צריך להשתמש בפרמטרים
specify --large-volume trueו---multiple-endpoints trueגם כן.
CLUSTER_LOCATION:אופציונלי: תיאור של המיקום של אשכול המקור.
DESCRIPTION:אופציונלי: טקסט התיאור של משאב השכפול.
LABELS(אופציונלי): תוויות למשאב השכפול.בדוגמה הבאה מוצג אופן ההגדרה של צמדי מפתח/ערך לפרמטר
labels:labels=KEY1:VALUE1#KEY2:VALUE2
קריאה לדוגמה:
$ gcloud netapp volumes create ok-destination --location australia-southeast1 \ --capacity 100 --protocols=nfsv3 \ --share-name ok-destination --storage-pool okrause-pool \ --hybrid-replication-parameters=peer-cluster-name=au2se1cvo2sqa,peer-ip-addresses=10.0.0.25#10.0.0.26,peer-svm-name=svm_au2se1cvo2sqa,peer-volume-name=okrause_source,replication=okrause-replication
כדי לעמוד בדרישות הנפח, צריך לציין את כל הפרמטרים האופציונליים הרלוונטיים. לדוגמה, יכול להיות שיהיה צורך במדיניות ייצוא עבור נפח אחסון NFS.
חיפוש כל האפשרויות:
gcloud netapp volumes create --help
אחרי שיוצרים את נפח היעד ואת משאב השכפול, מערכת NetApp Volumes מנסה לבצע שיוך למערכת ONTAP של המקור. תהליך ה-peering הזה משמש כשלב אימות והרשאה, ומגן על אשכול המקור מפני בקשות זדוניות של SnapMirror. לכן, חשוב לוודא שאתם מבצעים שיתוף פעולה רק עם מערכות מהימנות.
מחפשים את השלבים הבאים:
gcloud netapp volumes replications list --volume=DESTINATION_VOLUME --location=REGION
אפשר להדפיס את סטטוס האימות הנוכחי בכל שלב. עם זאת, יכול להיות שיעברו עד חמש דקות מרגע שפעולה מקדמת את התהליך לשלב הבא ועד שיתבצעו שינויים במצב.
תהליך מוצלח של קישור בין רשתות כולל את השלבים הבאים:
היעד של NetApp Volumes שולח פינג למערכת המקור באמצעות
peer-ip-addressesשצוין.אם עדיין לא הוגדר שיתוף פעולה בין אשכולות, NetApp Volumes מדפיס את הפקודות לשיתוף פעולה בין אשכולות שצריך להריץ במערכת המקור.
בנוסף, אם לא הוגדר כבר שיוך בין מכונות וירטואליות של SVM, NetApp Volumes מדפיס את פקודות השיוך בין מכונות וירטואליות של vserver שצריך להריץ במערכת המקור.
השלבים הקודמים שבוצעו נדלגים, והתהליך ממשיך אוטומטית לשלב הבא.
בדיקת החיבור לרשת
NetApp Volumes מנסה לשלוח בקשת ICMP (ping) ל-IC-LIFs שציינתם בקטע peer-ip-addresses. אם הניסיון ייכשל, יוצג הסמל stateDetails
Cluster peering failed, please try again, שמציין בעיה ברשת. מידע נוסף זמין במאמר חיבור רשת ל Google Cloud פרויקט. אי אפשר להמשיך עד שיוצרים קישוריות לרשת בין מערכת המקור לבין NetApp Volumes. למטרות ניפוי באגים, נסו לבצע פינג לכתובת ה-IP של שער ה-CIDR /27 שמארח את NetApp Volumes IC-LIFs.
gcloud netapp volumes replications list --volume=DESTINATION_VOLUME --location=REGION \ --format="table(hybridPeeringDetails.subnetIp)"
הפעולה הזו תדפיס את ה-CIDR. מבצעים פינג לכתובת ה-IP הראשונה של הרשת ממערכת ONTAP של המקור, באמצעות אחד מממשקי ה-IC-LIF של המקור.
דוגמה:
source> ping -lif=YOUR_IC_LIF -vserver=VSERVER_HOSTING_SOURCE_VOLUME -destination=FIRST_IP_OF_SUBNET_IP
Cluster peering:
אם ICMP פועל, התהליך ממשיך לחיבור בין אשכולות. הסטטוס PENDING_CLUSTER_PEERING מוצג אם עדיין לא נוצר שיתוף פעולה.
מחפשים הוראות ליצירת שותפות בין אשכולות:
gcloud netapp volumes replications list --volume=DESTINATION_VOLUME --location=REGION \ --format="table(hybridPeeringDetails.command,hybridPeeringDetails.passphrase)"
התהליך הזה יוצר את הפקודה ואת ביטוי הסיסמה שנדרשים להרצה. מעתיקים את הפקודה cluster peer create ומדביקים אותה באשכול המקור, ואז מריצים אותה. תתבקשו להזין את ביטוי הסיסמה פעמיים.
SVM peering:
הפקודה cluster peer create מהשלב הקודם אמורה גם לבצע את הפירינג של ה-SVM באופן אוטומטי. אם זה לא קורה, המצב משתנה ל-PENDING_SVM_PEERING אחרי כמה שניות.
מאמתים את ה-SVM peering:
gcloud netapp volumes replications list --volume=DESTINATION_VOLUME --location=REGION
אם המצב הוא PENDING_SVM_PEERING, מריצים את הפקודה vserver peering:
gcloud netapp volumes replications list --volume=DESTINATION_VOLUME --location=REGION \ --format="table(hybridPeeringDetails.command)"
אחרי כמה שניות, הסטטוס משתנה לReady, והסטטוס של mirrorState משתנה לPreparing, שמציין שההעברה של נתוני הבסיס התחילה. אחרי שההעברה של נתוני הבסיס מסתיימת, הערך של mirrorState משתנה ל-Mirrored. העברת נפח מתבצעת בכל שעה, ומופעלת העברה מצטברת, שמסומנת ב-mirrorState כהעברה.