מידע על שכפול נפח אחסון

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

מידע על רפליקציה של נפח אחסון

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

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

תהליך העבודה של שכפול נפח האחסון

במהלך שכפול של נפח, תהליך שנקרא העברה ראשונית משכפל את כל התוכן של נפח המקור לנפח היעד. בתהליך ההעברה הראשוני, המערכת יוצרת תמונת מצב במערכת המקור ומעבירה את התוכן שלה לנפח האחסון ביעד. אחרי שההעברה הראשונית מסתיימת, הסטטוס של הרפליקציה משתנה ל-Mirrored. כתוצאה מכך, אמצעי האחסון של היעד הופך ל"לקריאה בלבד" ומשקף את התוכן של תמונות המצב של אמצעי האחסון של המקור, כולל כל תמונות המצב שנוצרו לפני תמונת המצב הראשונית.

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

1. התהליך יוצר קובץ snapshot חדש בנפח המקור.

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

3. התהליך מעביר את השינויים האלה לאמצעי האחסון ביעד. סטטוס ההעברה במשאב הרפליקציה משתנה ל-Transferring.

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

שינויים בהגדרות

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

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

הגדרות משוכפלות

בזמן שהרפליקציה במצב Mirrored, ‏NetApp Volumes מסנכרן את ההגדרות הבאות בין נפח המקור לנפח היעד:

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

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

• הגדרות פרוטוקול: החלת השינויים על פרוטוקולים שכבר מופעלים בשני אמצעי האחסון. בנפחים של פרוטוקול SMB ‏ (SMB), ההגדרות האלה כוללות הצפנת SMB, הרשאות גישה לשיתוף וספירה מבוססת-גישה. אי אפשר לשנות את סוג הפרוטוקול אחרי שיוצרים את הנפח.

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

• הרשאות UNIX: העתקת הרשאות ה-UNIX של ספריית הבסיס של המקור אל נפח האחסון של היעד. ההרשאות האלה הופכות להרשאות הראשוניות של תיקיית השורש ביעד.

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

הגדרות לכל עוצמת קול

מגדירים את ההגדרות הבאות בנפרד בנפח המקור ובנפח היעד:

• תיאור של תוויות ונפח: מציינים תוויות ותיאור לכל נפח.

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

• כספת גיבוי: מקצים כספת גיבוי לכל נפח אחסון.

• חלוקה אוטומטית לרמות: הפעלה או השבתה של חלוקה אוטומטית לרמות לכל נפח אחסון.

• Make snapshot directory visible: מגדירים את ההגדרה הזו רק בנפח המקור. אי אפשר לשנות את ההגדרה הזו בנפח היעד.

• חסימת מחיקת אמצעי אחסון: הפעלה או השבתה של ההגדרה הזו לכל אמצעי אחסון.

• קצב העברת נתונים: מגדירים את קצב העברת הנתונים בנפרד בנפחי המקור והיעד במאגר ידני של איכות השירות (QoS). במאגר QoS אוטומטי, גודל הנפח ורמת השירות קובעים את קצב העברת הנתונים.

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

ברמות השירות Standard,‏ Premium ו-Extreme, אם מעבירים את נפח המקור למאגר עם רמת שירות אחרת, רק נפח המקור משתנה. נפח האחסון של היעד נשאר במאגר הנוכחי שלו.

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

שיקולים לגבי שכפול של אמצעי אחסון

לפני שאתם משכפלים את הנפח, חשוב לשים לב לנקודות הבאות:

• ברמות השירות Standard,‏ Premium ו-Extreme,‏ NetApp Volumes תומך בשכפול נפחים בין זוגות האזורים הספציפיים הבאים:

  • asia-southeast1 וגם australia-southeast1

  • europe-west2 וגם europe-west3

  • europe-west2 וגם europe-west4

  • europe-west3 וגם europe-west4

  • europe-west3 וגם europe-west6

  • europe-west4 וגם europe-west6

  • europe-southwest1 וגם europe-west3

  • northamerica-northeast1 וגם northamerica-northeast2

  • northamerica-northeast1 וגם us-central1

  • australia-southeast1 וגם asia-southeast1

  • us-central1 וגם us-east4

  • us-central1 וגם us-west2

  • us-central1 וגם us-west3

  • us-central1 וגם us-west4

  • us-east4 וגם us-west2

  • us-east4 וגם us-west4

  • us-west2 וגם us-west4

  • us-west3 וגם us-west4

• ברמת השירות Flex Unified, אפשר ליצור רפליקה של נפח בין אזורים באותה קבוצת אזורים. יש גם תמיכה ברפליקציה לאזור אחר באותו אזור. בטבלה הבאה מפורטות קבוצות האזורים במיקומים שונים:

  	מיקומים
  	אמריקה	אסיה-פסיפיק	אירופה, המזרח התיכון ואפריקה
  קבוצת אזורים	southamerica-east1 us-central1 us-east1 us-east4 us-east5 us-south1 us-west1 us-west2 us-west3 us-west4	asia-east1 asia-northeast1 asia-northeast2 asia-south1 asia-southeast1 australia-southeast1 australia-southeast2	europe-southwest1 europe-west1 europe-west2 europe-west3 europe-west4 europe-west8 europe-west9 me-west1

• ברמת השירות Flex File, אפשר לשכפל נפחים בין אזורים ששייכים לאותה קבוצת אזורים. בטבלה הבאה מפורטות קבוצות האזורים במיקומים השונים:

  	מיקומים
  	אמריקה	אסיה-פסיפיק	אירופה, המזרח התיכון ואפריקה
  קבוצת אזורים	southamerica-east1 southamerica-west1 northamerica-northeast1 northamerica-northeast2 us-central1 us-east1 us-east4 us-east5 us-south1 us-west1 us-west2 us-west3 us-west4	asia-east1 asia-east2 asia-northeast1 asia-northeast2 asia-northeast3 asia-south1 asia-south2 asia-southeast1 asia-southeast2 australia-southeast1 australia-southeast2	africa-south1 europe-central2 europe-north1 europe-southwest1 europe-west1 europe-west2 europe-west3 europe-west4 europe-west6 europe-west8 europe-west9 europe-west10 europe-west12 me-central1 me-central2 me-west1

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

• תמיכה טופולוגית: שכפול נפח לא תומך בטופולוגיות מדורגות, בטופולוגיות של ריבוי כניסות (fan-in) ובטופולוגיות של ריבוי יציאות (fan-out). לדוגמה, אמצעי אחסון לא יכול להיות גם אמצעי האחסון של המקור וגם אמצעי האחסון של היעד.

• מיקום של נפח המקור והיעד:

  • לרמת השירות Flex Unified Default-mode: השיקולים הבאים רלוונטיים.

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

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

    • אתם יכולים לשכפל ווליומים באותו פרויקט.

    • שכפול נפח בין פרויקטים, בין נפחי מקור ויעד, הוא תכונה שזמינה לפי בקשה. כדי לבקש גישה לתכונה הזו, פנו לצוות המכירות. אפשר ליצור רפליקציות באמצעות ה-API,‏ Google Cloud CLI או Terraform, אבל אפשר לנהל אותן במסוף Google Cloud . כדי ליצור רפליקה בפרויקט אחר, צריך הרשאות netapp.replications.create בשני הפרויקטים. בניגוד לרפליקציות רגילות של נפחים, ברפליקציות בין פרויקטים כללי הייצוא לא משוכפלים בין נפח המקור לנפח היעד. אם אתם משתמשים ב-VPC Service Controls, קראו את המאמר המגבלות של VPC Service Controls ב-NetApp Volumes כדי להבין איך פועלת רפליקציה של נפחים בין פרויקטים.

  • ברמת השירות Flex File: גם נפח המקור וגם נפח היעד צריכים להיות באותו פרויקט ובאותה קבוצת אזורים. אי אפשר לשכפל לאזור אחר באותו מחוז.

  • לרמות השירות Standard,‏ Premium ו-Extreme: השיקולים הבאים רלוונטיים.

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

    • שכפול נפח בין פרויקטים, בין נפחי מקור ויעד, הוא תכונה שזמינה לפי בקשה. כדי לבקש גישה לתכונה הזו, פנו לצוות המכירות. אפשר ליצור את הרפליקות האלה רק באמצעות API,‏ Google Cloud CLI או Terraform, אבל אפשר לנהל אותן בהמשך באמצעות מסוף Google Cloud . כדי ליצור רפליקה בפרויקטים שונים, צריך את ההרשאות netapp.replications.create בשני הפרויקטים. בניגוד לרפליקציות כלליות של נפחים, רפליקציות בין פרויקטים לא משכפלות את כללי הייצוא בין נפחי המקור והיעד. אם אתם משתמשים ב-VPC Service Controls, קראו את המאמר המגבלות של VPC Service Controls ב-NetApp Volumes כדי להבין איך משכפלים נפחים בין פרויקטים.

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

• תמיכה מבוססת רמת שירות: לנפחי המקור והיעד צריכה להיות אותה רמת שירות, חוץ מנפחים ברמות השירות Premium ו-Extreme, שאפשר לשלב ברפליקציה. כדי לשכפל אל או מ-Flex Unified במצב ONTAP, ראו שכפול באמצעות ONTAP, כאשר המאגר במצב ONTAP הוא מערכת ONTAP. שכפול בין מערכות במצב ONTAP או מערכות שמבוססות על ONTAP לבין מצב ONTAP הוא שכפול רגיל של ONTAP SnapMirror, שצריך לנהל בהתאם. מידע נוסף זמין במאמר מידע על התאוששות מאסון אסינכרונית של ONTAP SnapMirror.

המחיר של רפליקציית נפח

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

יעד להתאוששות מאסון (RPO)

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

כדי לקבוע את ה-RPO של רפליקציית הנפח, אפשר לבדוק את זמני ההשהיה או את קובצי ה-Snapshot של הרפליקציה. למרות שזמן ההשהיה מספק דרך מהירה להעריך את ה-RPO, תמונות המצב של הרפליקציה הן מדד מדויק יותר.

• זמן השהיה: הזמן שחלף מאז יצירת קובץ ה-snapshot בנפח המקור ששוכפל לאחרונה לנפח היעד. זמן ההשהיה מייצג את ההבדל בגיל של נתוני נפח היעד ביחס לנתוני נפח המקור. הוא מתעדכן כל חמש דקות ומספק סקירה כללית של ה-RPO. אם הרפליקציה מדלגת על מרווחי זמן, סמל אזהרה מופיע ליד זמן הפיגור במסוף Google Cloud . אם הבעיה נמשכת, קצב שינוי הנתונים בנפח המקור גבוה מדי להעברה במרווח זמן של שכפול. מומלץ לבחור מרווח זמן ארוך יותר לשכפול, או להתעלם מהאזהרה במצבים חד-פעמיים כמו פעילות כבדה של שינוי נתונים במקור.

• תמונות מצב של שכפול: תמונות מצב של שכפול הן תיעוד של הנתונים בדיוק כפי שהם מופיעים בנקודת זמן מסוימת. תמונות מצב של רפליקציה מספקות את המבט המדויק ביותר על RPO. שכפול של אמצעי אחסון משתמש בשני קובצי snapshot מתגלגלים לצורך שכפול. חותמת הזמן של תמונת המצב האחרונה של הרפליקציה בנפח היעד מציינת את נקודת הזמן (UTC) של הנתונים האחרונים בנפח היעד.

  אפשר להפיק את חותמת הזמן (replication-<timestamp>) משם קובץ ה-snapshot של הרפליקציה, שמופיע בפורמט UTC‏ (YYYY-MM-DD-HHMMSS).

הדרישות למאגרי אחסון

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

• חייב להיות חלק מצמד מיקומים או מקבוצת אזורים חוקיים, בהתאם לרמת השירות

• חייבת להיות אותה הגדרת מדיניות של Active Directory

• חייב להפנות לאותו Active Directory

• הגדרות ה-LDAP חייבות להיות זהות

לוח זמנים לשכפול

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

תדירות התזמון של השכפול	שעת הפעולה המתוזמנת
כל 10 דקות	:00, :10, :20, :30, :40, :50
מדי שעה	‫:05 אחרי תחילת כל שעה
יומי	:10 אחרי חצות בכל יום

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

יוצרים רפליקציה של נפח האחסון.