הגדרה של רשתות

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

לתשומת ליבכם

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

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

• VPC משותף: כשמחברים NetApp Volumes ל-VPC משותף, צריך לבצע קישור בין רשתות שכנות (peering) של גישה לשירותים פרטיים בפרויקט המארח שבבעלותו ה-VPC המשותף. צריך לפנות לאדמין של הרשת כדי להגדיר את ה-peering ל-VPC המשותף באמצעות ההוראות שבמאמר הגדרת גישה לשירותים פרטיים.

• הקצאת טווח CIDR: טווחי Classless Inter-Domain Routing‏ (CIDR) מאפשרים לייצג כתובות IP ואת הרשתות התואמות שלהן לשימוש בשירות. השירות משתמש בכתובות IP מטווח ה-CIDR שהוקצה כדי להקצות נפחים לסוג הפרוטוקול הנכון, כמו Network File System‏ (NFS) או פרוטוקול SMB‏ (SMB).

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

• בחירת טווח CIDR שלא חופף לטווחים של רשתות מקומיות: אם אתם מתכננים להשתמש ב-NetApp Volumes מרשתות מקומיות דרך VPN או Cloud Interconnect, מומלץ לבחור טווח CIDR שלא חופף לטווחים של CIDR שמשמשים ברשת המקומית. אם לא תעשו זאת, עלולות להתרחש התנגשויות של כתובות IP ובעיות ניתוב.

• תעבורת הנתונים של NetApp Volumes נשארת בתוך ה-VPC המחובר: הגישה ל-NetApp Volumes מתבצעת באמצעות גישה לשירותים פרטיים, שמסתמכת על קישור בין רשתות VPC שכנות (peering). התנועה לא יכולה לעבור דרך שני חיבורי VPC Peering עוקבים, ולכן התנועה מלקוחות לנפח או מ-NetApp Volumes לשרתי Active Directory לא יכולה לצאת מה-VPC המצורף. כדי להפעיל את הקישוריות לרשת, אפשר לקשר רשתות נוספות.

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

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

  1. מחיקת כל הכרכים הקיימים.

  2. מסירים את חיבור ה-Peering.

  3. צריך להמתין לפחות שש שעות עד לניקוי הרשת.

  4. יוצרים חיבור חדש של שירותי רשת וירטואלית באמצעות טווח ה-CIDR המעודכן.

• אי אפשר לשנות את כתובת ה-IP שמוקצית לנפח אחסון: נפחי אחסון של NetApp מקצים כתובת IP מטווח ה-CIDR של הגישה הפרטית לשירות שהוקצה לנפחי אחסון. אי אפשר לקבוע איזו כתובת IP מקבל נפח אחסון או לשנות את כתובת ה-IP של נפח אחסון קיים.

הגדרת גישה לשירותים פרטיים

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

1. בחירת טווח CIDR: NetApp Volumes משתמש בטווחים של כתובות IP ציבוריות (PUPI) שמשמשות לשימוש פרטי או בטווחים של כתובות RFC 1918. רמות השירות Standard,‏ Premium,‏ Extreme ו-Flex File תומכות ב-PUPI עבור נפחי אחסון של NFS או SMB ולקוחות NFS או SMB שניגשים לנפחי האחסון. רמת השירות Flex File לא תומכת בטווחי הכתובות של 6.0.0.0/8 ו-7.0.0.0/8 PUPI. כשמשתמשים בכתובות PUPI, צריך להשתמש בפקודות Google Cloud CLI במקום במסוף Google Cloud כדי להגדיר את הרשת. מידע נוסף על הסיבות לכך שרמת השירות Flex Unified לא נתמכת זמין במאמר מגבלות ידועות.

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

   בוחרים טווח CIDR שגדול מספיק כדי להכיל את הנפחים והמאגרים. טווח ה-CIDR המינימלי שאפשר להשתמש בו הוא /24. ‫NetApp Volumes צורך טווחי משנה מתוך ה-CIDR שהוקצה בהתאם לסט הכללים הבא:

   • נפחים ברמות השירות Standard,‏ Premium ו-Extreme יכולים לחלוק כתובת IP אחת, גם אם הם נמצאים במאגרי אחסון שונים. לכן, מספר גדול של נפחים ומאגרי נפחים יכולים לחלוק טווח משנה יחיד של /28. בהתאם לפרמטרים של מאגר האחסון, כמו CMEK, ‏ LDAP, מדיניות Active Directory ועוד, נפחי האחסון יצרכו יותר כתובות IP.

   • כדי להשתמש בכרכים בקיבולת גדולה ברמת השירות Premium או Extreme, צריך להגדיר טווח משנה של /27 כדי לתמוך בכמה נקודות קצה של אחסון.

   • כל נפח אחסון רגיל ב-Flex Unified צריך לכלול /28תת-טווח שמשותף לכל הנפחים שלו.

   • כל מאגר אחסון בקיבולת גדולה ב-Flex Unified דורש /27טווח משנה, שמשותף בין כל אמצעי האחסון שלו.

   • לכל מאגר אחסון ברמת השירות Flex File נדרשת כתובת IP משלו, וכל אמצעי האחסון משתמשים באותה כתובת IP. לכן, אפשר ליצור 12 מאגרי אחסון בטווח משנה של /28, כי לכל תת-רשת יש ארבע כתובות IP שלא ניתן להשתמש בהן.

   • נפחים באזורים שונים באותו פרויקט דורשים טווחי /28 או /27 נוספים, בהתאם לסוג הנפחים שפורסים.

   • לנפחים בפרויקטים שונים של שירותים באותו VPC משותף נדרשים טווחי /28 או /27 נפרדים. לכן, טווח ה-CIDR בגודל המינימלי של /24 יכול להכיל עד 16 שילובים של פרויקטים של שירותים אזוריים.

   • לפעולות הבאות מוקצה טווח של /27 כתובות IP: תקשורת בין אשכולות, העברת נפח, שכפול חיצוני ו-FlexCache.

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

2. מפעילים את Service Networking API: מוודאים שהפעלתם את servicenetworking.googleapis.com API.

   הפעלה של ה-API

3. הגדרת גישה לשירותים פרטיים: כדי להגדיר גישה לשירותים פרטיים באמצעות Google Cloud CLI, פועלים לפי ההוראות הבאות:

   1. שומרים טווח כתובות IP פנימיות סטטיות ל-CIDR:

      gcloud compute addresses create netapp-addresses-production-vpc1 \
       --project=PROJECT_ID \
       --global \
       --purpose=VPC_PEERING \
       --prefix-length=24 \
       --network=VPC \
       --no-user-output-enabled

      מחליפים את PROJECT_ID בשם הפרויקט שבו רוצים להגדיר גישה לשירותים פרטיים.

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

        --addresses=192.168.0.0 \

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

   2. מריצים את הפקודה הבאה כדי ליצור קישור בין הרשתות:

        gcloud services vpc-peerings connect \
         --project=PROJECT_ID \
         --service=netapp.servicenetworking.goog \
         --ranges=netapp-addresses-production-vpc1,ADDITIONAL_IP_RANGES \
         --network=VPC

      מחליפים את PROJECT_ID בשם הפרויקט שבו רוצים להגדיר גישה לשירותים פרטיים.

      אפשר לציין כמה טווחי כתובות של מחשוב כרשימה שמופרדת בפסיקים בדגל ‎--ranges. NetApp Volumes משתמשים בטווחים משניים של /28 או /27 מתוך טווחי כתובות המחשוב בסדר לא מוגדר.

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

      חשוב: אם הפירינג נכשל ומופיעה שגיאהConstraint constraints/compute.restrictVpcPeering violated for project, המשמעות היא שהמדיניות של ה Google Cloud ארגון מגבילה את הפירינג. כדי לפתור את הבעיה, צריך לפנות לאדמין בארגון כדי לקבל חריגה.

   3. הפעלת העברה של מסלולים בהתאמה אישית. הערה: כשמגדירים את החיבור הפרטי, NetApp Volumes יוצרת sn-netapp-prod peering.

        gcloud compute networks peerings update sn-netapp-prod \
          --project=PROJECT_ID \
          --network=VPC  \
          --import-custom-routes \
          --export-custom-routes

      מחליפים את PROJECT_ID בשם הפרויקט שבו רוצים להגדיר גישה לשירותים פרטיים. אם אתם משתמשים ב-PUPI, השתמשו בפרמטרים import-subnet-routes-with-public-ip ו-export-subnet-routes-with-public-ip במקום זאת.

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

מגדירים הרשאות IAM.