תכנון ההעברה

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

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

משך ההעברה של נפח האחסון מושפע מכמה גורמים:

  • המהירות של נפח המקור: לתנועת הנתונים של SnapMirror יש עדיפות נמוכה יותר מאשר לתנועת הנתונים של NFS ו-SMB. עומסי עבודה גבוהים בנפח המקור יכולים להפחית את הביצועים של התנועה היוצאת ב-SnapMirror.

  • קצב העברת הנתונים של NetApp Volumes: מוגדר לפי רמת השירות ויכולת קצב העברת הנתונים הספציפית של הווליום. תנועת NFS או SMB בנפח האחסון עשויה גם להפחית את הביצועים של SnapMirror.

  • תפוקת חיבור הרשת: ‏ SnapMirror מנסה להשיג מהירות מקסימלית ועשוי לצרוך רוחב פס שמשותף עם משתמשים אחרים בחיבור הרשת בין מערכת המקור ONTAP לבין NetApp Volumes.

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

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

אפשר לחשב הערכה גסה של משך ההעברה באמצעות כלל אצבע.

דוגמה

לצורך המחשה, נבחן את התרחיש הבא לחישוב משך ההעברה:

  • נפח המקור: קיבולת של 15TiB עם נתונים בנפח 12TiB.

    • הנתונים שיועברו: 12TiB.

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

    • הניחו שהיכולות של הביצועים לא מהוות גורם מגביל.

  • שיעור השינוי: 10% ביום.

    • שיעור השינוי היומי בנתונים: 1.2TiB.

    • השיעור 10% הוא הנחה לצורך הדוגמה הזו. שיעורי השינוי הטיפוסיים בדרך כלל נמוכים בהרבה.

  • חיבור לרשת: תשתית מקומית מחוברת ל-Google באמצעות חיבור של 10Gbps.

    • רוחב פס אפקטיבי של TCP: בערך 1,000 מיביבייט לשנייה, שאפשר להשתמש בו באופן בלעדי.

  • נפח היעד: נפח של 12TiB עם רמת שירות Premium.

    • מגבלת התפוקה: ‎12 × 64 MiBps = 768 MiBps.

חישוב

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

העברת נתונים בסיסיים

  • הנתונים להעברה: 12TiB

  • מכסת תפוקה: 768 MiBps

  • חישוב הזמן: (‎12 TiB x 1024^2 MiB/TiB) / 768 MiBps = 16384 seconds

  • הזמן הכולל להעברת נתוני הבסיס: 4.6 שעות

ההעברה המצטברת הראשונה

  • הזמן שחלף מאז העברת הבסיס: 5 שעות

  • שינוי נתונים: (‎12 TiB x 1024 GiB/TiB) * 10% * (5h/24h) = 256 GiB

  • חישוב הזמן:(‎256 GiB x 1024 MiB/GiB) / 768 MiBps = 341 seconds

  • הזמן הכולל להעברה המצטברת הראשונה: כ-6 דקות

העברה מצטברת שנייה

  • הזמן שחלף מאז ההעברה המצטברת הראשונה: שעה

  • שינוי נתונים: (‎12 TiB x 1024 GiB/TiB) * 10% * (1h/24h) = 51.2 GiB

  • חישוב הזמן: (‎51.2 GiB x 1024 MiB/GiB) / 768 MiBps = 68 seconds

  • הזמן הכולל להעברה השנייה: כ-70 שניות

העברות מצטברות נוספות

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

תהליך המעבר

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

זמן ההעברה הכולל: כ-4.7 שעות.

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

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

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

  • netapp.googleapis.com/standard_hybrid_replicated_volumes_per_region

  • netapp.googleapis.com/hybrid_replicated_volumes_per_region

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

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

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

דרישות מוקדמות ל-ONTAP ול-NetApp Volumes