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

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

לתשומת ליבכם

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

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

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

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

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

• בחירת טווח CIDR שלא חופף לטווחים של רשתות מקומיות: אם אתם מתכננים להשתמש ב-NetApp Volumes מרשתות מקומיות דרך VPN או Cloud Interconnect, מומלץ לבחור טווח 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. יוצרים חיבור חדש של שותפות (peering) באמצעות טווח ה-CIDR המעודכן.

• אי אפשר לשנות את כתובת ה-IP שמוקצית לנפח אחסון: ב-NetApp Volumes מוקצית לנפחי אחסון כתובת 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. יכול להיות שנפחי האחסון יצרכו כתובות IP נוספות, בהתאם לפרמטרים של מאגר האחסון, כמו CMEK, ‏ LDAP ומדיניות Active Directory.

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

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

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

   • רמת שירות מאוחדת של Flex:

     • כל מאגר אחסון רגיל משתמש בטווח משנה של /28, שמשותף בין כל אמצעי האחסון שלו.

     • כל מאגר אחסון גדול משתמש ב/26 טווח משנה, שמשותף לכל הנפחים שלו.

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

     • יצירת מאגר אחסון Flex File ראשון צורכת טווח משנה של /28. כל מאגר משתמש בכתובת IP אחת לגישה לנפח אחסון ובכתובת IP אחת לגישה ל-Active Directory.

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

   רמות שירות שונות לא יכולות לחלוק את אותה הקצאת טווח משנה, למעט רמות השירות Standard,‏ Premium ו-Extreme, שיכולות לחלוק הקצאת טווח משנה יחידה. אם יש לכם נפחים ומאגרים באזורים שונים, תצטרכו להקצות טווחי משנה נפרדים. גודל טווח המשנה הנדרש תלוי בסוג המאגר או הנפח. כל פרויקט שירות ב-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 ברשימה מופרדת בפסיקים של טווחי כתובות נוספים ליצירת קישור בין רשתות שכנות (peering), או משאירים את השדה ריק כדי ליצור קישור בין הרשתות רק עם טווח הכתובות שנוצר בשלב הקודם.

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

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

        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.