יצירת שכפול חיצוני

בדף הזה מוסבר איך ליצור שכפול חיצוני.

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

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

לתשומת ליבכם

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

  • שכפול נפח אחסון

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

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

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

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

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

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

דרישות מוקדמות לשכפול חיצוני

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

יצירת שכפול חיצוני

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

המסוף

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

   מעבר אל NetApp Volumes

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

3. לוחצים על שכפול נפח חיצוני.

4. בקטע Prerequisites, בודקים את התנאים המוקדמים ולוחצים על Next.

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

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

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

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

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

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

6. אופציונלי: בקטע Volume style (סגנון נפח), מסמנים את התיבה FlexGroup volume (נפח FlexGroup) כדי ליצור נפח יעד גדול ב-NetApp Volumes.

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

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

הגדרת פרטי עוצמת הקול של היעד

1. בקטע Create destination volume, מבצעים את השלבים הבאים:

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

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

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

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

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

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

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

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

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

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

4. בקטע Capacity configuration (הגדרת קיבולת), מבצעים את הפעולות הבאות:

   1. מסמנים את תיבת הסימון הפעלת נפח אחסון גדול.

      הערה: אפשר להפעיל קיבולת גדולה רק בנפח היעד אם נפח המקור מוגדר כנפח FlexGroup.

   2. מזינים את קיבולת הנפח בשדה קיבולת.

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

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

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

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

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

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

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

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

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

הגדרת לוח זמנים לרפליקציה

1. בקטע Replication schedule (תזמון השכפול), מבצעים את הפעולות הבאות:

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

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

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

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

      • כל 10 דקות

      • יומי

      • שעתי

      ברירת המחדל היא HOURLY. כרכים בקיבולת גדולה לא תומכים באפשרות EVERY_10_MINUTES.

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

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

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

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

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

צריך לאמת את חיבור SnapMirror בין מערכת ONTAP המקורית לבין NetApp Volumes. מריצים את הפקודה cluster peer create באשכול המקור ONTAP. אם לא קיים פירינג קודם, בכרטיסייה Replication (שכפול) מוצג Pending cluster peering (פירינג של אשכול בהמתנה).

אם לוחצים על Configure 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=hybrid-replication-type=ONPREM_REPLICATION,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,replication-schedule=REPLICATION_SCHEDULE,cluster-location=CLUSTER_LOCATION,description=DESCRIPTION,labels=LABELS

הבלוק hybrid-replication-parameters מתחיל תהליך עבודה של שכפול.

מחליפים את המידע הבא:

• ‫VOLUME_NAME: שם אמצעי האחסון. השם הזה צריך להיות ייחודי לכל מיקום.

• ‫LOCATION: המיקום של אמצעי האחסון.

• ‫CAPACITY: הקיבולת של הווליום. הוא מגדיר את הקיבולת שמוצגת ללקוחות NAS.

• ‫PROTOCOLS: פרוטוקולי ה-NAS שבאמצעותם מיוצא נפח האחסון.

• ‫SHARE_NAME: נתיב הייצוא של NFS או שם השיתוף של SMB של אמצעי האחסון.

• ‫STORAGE_POOL: מאגר האחסון שבו ייצור הנפח.

• HYBRID_REPLICATION_TYPE: לשכפול חיצוני, מציינים ONPREM_REPLICATION.

• ‫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 גם כן.

• ‫REPLICATION_SCHEDULE: אופציונלי: אפשר להגדיר את הערך של replication schedule לאחד מהמרווחים הבאים:

  • EVERY_10_MINUTES

  • HOURLY

  • DAILY

  ערך ברירת המחדל הוא HOURLY. לא ניתן לקבל EVERY_10_MINUTES על נפחים גדולים.

• ‫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=hybrid-replication-type=ONPREM_REPLICATION,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,replication-schedule=HOURLY

כדי לעמוד בדרישות הנפח, צריך לציין את כל הפרמטרים האופציונליים הרלוונטיים. לדוגמה, יכול להיות שיהיה צורך במדיניות ייצוא עבור נפח אחסון 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 מדפיס את הפקודות לשיתוף פעולה בין אשכולות שצריך להריץ במערכת המקור. אם המקור הוא מאגר Flex Unified במצב ONTAP, אפשר להריץ את הפקודות באמצעות פרוקסי של Google Cloud CLI ONTAP CLI.

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

דוגמה:

ONTAP> 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 כTransferring.

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

מידע נוסף על דגלים אופציונליים נוספים זמין במאמרי העזרה של Google Cloud SDK בנושא יצירת שכפול חיצוני.

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

ניהול שכפולים חיצוניים.