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

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

מידע על שכפול עוצמת הקול

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

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

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

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

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

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

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

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

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

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

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

• תוויות ותיאור נפח: צריך להגדיר את ההגדרות האלה בנפרד במאגרי המקור והיעד.

• מדיניות Active Directory: המדיניות הזו מוגדרת גם במאגרי המקור וגם במאגרי היעד, ואי אפשר לשנות אותה.

• מדיניות CMEK: המדיניות הזו מוגדרת גם במאגרי המקור וגם במאגרי היעד, ואי אפשר לשנות אותה.

• מדיניות הגיבוי: צריך להגדיר את ההגדרה הזו בנפרד גם בכרכי המקור וגם בכרכי היעד.

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

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

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

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

• הרשאות Unix: פרמטר ה-API הזה מגדיר את הרשאות ה-UNIX הראשוניות של צומת ה-inode הבסיסי, שמשוכפל לנפח היעד במהלך תהליך השכפול.

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

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

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

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

שיקולים לגבי שכפול נפח

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

• ברמות השירות 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-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 במסוף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 של שכפול נפח, אפשר לבדוק את זמני ההשהיה או את תמונות המצב של השכפול. למרות שזמן ההשהיה מספק דרך מהירה להערכת RPO, תמונות מצב של שכפול הן מדד מדויק יותר.

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

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

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

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

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

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

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

• חייב להצביע על אותו Active Directory

• צריכות להיות להן אותן הגדרות LDAP

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

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

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

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

יצירת שכפול של נפח אחסון