יצירת העברה של נפח אחסון

בדף הזה מוסבר איך ליצור העברה בכמות גדולה.

לפני שמתחילים

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

לתשומת ליבכם

• התכונות הבאות לא נתמכות בנפחי יעד במהלך תהליך ההעברה:

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

  • רמת השירות של Flex File.

• אפשר להעביר FlexGroups לנפח אחסון גדול. ברמת השירות Flex Unified, מאגר היעדים צריך להיות מאגר בעל קיבולת גדולה.

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

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

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

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

• לפני שיוצרים העברה של נפח, צריך לוודא שיש לכם גישה ל-CLI וההרשאות הנדרשות במערכת ONTAP של המקור. צריך להריץ פקודות CLI במערכת ONTAP של המקור תוך שעה מתהליך ההעברה.

• אי אפשר להעביר נפח עם תמונות מצב חסינות לשינויים לנפח שמשתמש בסיווג אוטומטי לרמות אחסון.

• אי אפשר להעביר נפח מקור למספר יעדים באותו פרויקט בו-זמנית.

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

יצירת העברה של נפח אחסון

כדי ליצור העברת נפח אחסון באמצעות מסוףGoogle Cloud או Google Cloud CLI, פועלים לפי ההוראות הבאות.

המסוף

1. נכנסים לדף NetApp Volumes במסוף Google Cloud .

   מעבר אל NetApp Volumes

2. בתפריט הגנה על נתונים, לוחצים על העברות.

3. לוחצים על העברה מ-ONTAP.

4. בקטע Storage pool details (פרטי מאגר האחסון), מבצעים את הפעולות הבאות:

   1. לוחצים על בחירת מאגר אחסון.

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

   3. לוחצים על בחירה.

5. בקטע Volume details (פרטי נפח), מבצעים את הפעולות הבאות:

   1. מזינים את השם של נפח האחסון של היעד בשדה Destination volume name (שם נפח האחסון של היעד).

      זהירות: הבחירה שלכם היא סופית.

   2. אופציונלי: מזינים תיאור לנפח בשדה Description.

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

7. בקטע Share name, מזינים את שם השיתוף של אמצעי האחסון בשדה Share name. השם של השיתוף חייב להיות ייחודי במיקום. מומלץ להשתמש בשם של נפח היעד בתור שם השיתוף.

   זהירות: הבחירה שלכם היא סופית.

8. בקטע Capacity configuration, מזינים את נפח הקיבולת בשדה Capacity.

9. אופציונלי: אם מאגר האחסון שנבחר מאפשר העברה אוטומטית בין רמות:

   1. אם רוצים להפעיל את ההעברה האוטומטית לרמות אחסון שונות עבור הנפח, מסמנים את התיבה Enable auto-tiering.

   2. בשדה ימי סף קירור מציינים סף קירור של 2 עד 183 ימים. ערך ברירת המחדל של סף ההמתנה הוא 31 ימים.

   3. כשעוברים למאגר Flex Unified עם הפעלה של העברה אוטומטית בין רמות, מסמנים את תיבת הסימון Enable hot tier bypass (הפעלת מעקף של רמת הגישה המהירה). אחרי שההעברה תושלם, תוכלו להשבית את הדילוג על רמות חמות.

10. אופציונלי: אם בחרתם באחת מהאפשרויות של NFS בהגדרת הפרוטוקול, אתם יכולים לציין כללי ייצוא לנפח בקטע Export rules (כללי ייצוא).

11. אופציונלי: בקטע Snapshot configuration (הגדרת תמונת מצב), מבצעים את השלבים הבאים:

    1. בוחרים באפשרות הצגת ספריית תמונות המצב כדי לאפשר ללקוחות גישה למערכת הקבצים לגרסאות של תמונות מצב. מידע נוסף מופיע במאמר סקירה כללית על תמונות מצב של נפחים ב-NetApp Volumes.

    2. בוחרים באפשרות Allow scheduled snapshots (מתן הרשאה לצילום תמונות מצב מתוזמן) כדי להגדיר את עוצמת הקול לצילום תמונות מצב באופן אוטומטי. אפשר לציין את מספר התמונות לשימור במרווחי זמן של שעה, יום, שבוע וחודש. השעות מצוינות לפי שעון UTC. אם תגיעו למספר המקסימלי של תמונות מצב, תמונת המצב הכי ישנה תימחק.

    3. בודקים את הבחירות של תמונת המצב.

12. לוחצים על הבא.

13. בקטע פרטי ההעברה, מזינים שם למשאב ההעברה בשדה שם ההעברה.

14. לוחצים על הבא.

15. בקטע פרטי אשכול המקור, מבצעים את הפעולות הבאות:

    1. מזינים את שם אשכול המקור בשדה שם האשכול.

    2. מזינים את השם של מכונת האחסון הווירטואלית (SVM), שנקראת גם vserver, בשדה Storage VM name (שם מכונת האחסון הווירטואלית). ה-SVM שמארח את נפח האחסון של המקור.

    3. מזינים את השם של נפח האחסון של המקור בשדה שם נפח האחסון.

    4. מזינים את כתובת ה-IP של Intercluster-LIF (IC-LIF) בשדה Inter-cluster IP. לכל צומת באשכול המקור נדרש IC-LIF. מציינים את כל ה-IC-LIFs כרשימה מופרדת בפסיקים.

    5. אופציונלי: מזינים תיאור של המיקום של אשכול המקור בשדה מיקום.

16. לוחצים על 'הבא'.

17. בודקים את ההגדרות ולוחצים על יצירה כדי להתחיל בתהליך ההעברה.

הערה: אם מופיעה השגיאה Unable to find the resource you requested, צריך לחכות 30 שניות וללחוץ על Retry (ניסיון חוזר).

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

צריך לאמת את חיבור SnapMirror בין מערכת ONTAP המקורית לבין NetApp Volumes. מריצים את הפקודה cluster peer create באשכול המקור ONTAP. אם אין פירינג קודם, הערך Migration pending cluster peering from ONTAP source cluster מופיע בכרטיסייה Migration. אם מערכת המקור משתמשת במצב ONTAP, אל תריצו את cluster peer create ישירות עליה. במקום זאת, מריצים את הפקודה peer_cluster.py עם PEER_MODE=accept. מידע נוסף זמין במאמר סקריפט של שיתוף פעולה בין אשכולות.

אם לוחצים על 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

כשמעבירים למאגר Flex Unified עם הפעלה של העברה אוטומטית בין רמות, צריך תמיד להפעיל את האפשרות 'דילוג על רמה פעילה' במהלך ההעברה. אחרי שההעברה מסתיימת, אפשר להשבית את המעקף של רמת הגישה המהירה. משתמשים בפקודה gcloud beta netapp volumes create כדי ליצור נפח אחסון עם הפעלה של שכבות אחסון אוטומטיות.

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

--tiering-policy=tier-action=ENABLED,cooling-threshold-days=DAYS,enable-hot-tier-bypass-mode=on

הבלוק 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 beta 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 \
--tiering-policy=tier-action=ENABLED,cooling-threshold-days=31,enable-hot-tier-bypass-mode=on

כדי לעמוד בדרישות הנפח, צריך לציין את כל הפרמטרים האופציונליים הרלוונטיים. לדוגמה, יכול להיות שיהיה צורך במדיניות ייצוא עבור נפח אחסון 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 מדפיס את הפקודות לשיתוף פעולה בין אשכולות שצריך להריץ במערכת המקור. אם מערכת המקור משתמשת במצב ONTAP, אל תריצו את cluster peer create ישירות במערכת. במקום זאת, מריצים את הפקודה peer_cluster.py עם PEER_MODE=accept. מידע נוסף מופיע במאמר סקריפט ליצירת חיבור בין אשכולות.

• בנוסף, אם לא הוגדר כבר שיוך בין מכונות וירטואליות של 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 שמארח את ה-IC-LIFs של NetApp Volumes.

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 כהעברה.

הערה: תוקף בקשת ה-peering יפוג אם פרטי המקור שגויים או אם פקודות ה-peering שסופקו על ידי NetApp Volumes לא יופעלו במערכת המקורית תוך שעה. חותמת הזמן המדויקת מופיעה בפרמטר commandExpiryTime. כדי לשנות פרמטרים או להפעיל מחדש את תהליך הפירינג, משתמשים בפקודה gcloud netapp volumes replications establish-peering. אפשרות אחרת היא למחוק את השכפול וליצור אותו מחדש.

המאמרים הבאים

ניהול העברות של נפח אחסון