הגדרת קישור בין רשתות VPC שכנות (peering)

אתם יכולים להגדיר את Gemini Enterprise Agent Platform כך שתתבצע בה פעולת Peering עם ענן וירטואלי פרטי (VPC) כדי להתחבר ישירות למשאבים מסוימים ב-Agent Platform, כולל:

במדריך הזה מוסבר איך להגדיר קישור בין רשתות VPC כדי לקשר את הרשת שלכם למשאבים של Agent Platform. המדריך הזה מיועד לאדמינים של רשתות שכבר מכירים את Google Cloudהמושגים שקשורים לרשתות.

סקירה כללית

במדריך הזה מוסבר איך לבצע את הפעולות הבאות:

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

לפני שמתחילים

  • בוחרים את ה-VPC שאליו רוצים לבצע שיוך של משאבי Agent Platform. בכל אזור, אפשר לבצע peering של Agent Platform רק עם רשת אחת בכל פעם.
  • בוחרים או יוצרים Google Cloud פרויקט לשימוש ב-Agent Platform.

  • מוודאים שהחיוב מופעל בפרויקט Google Cloud .

  • מפעילים את Compute Engine API,‏ Agent Platform API ואת ממשקי Service Networking API.

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    הפעלת ממשקי ה-API

  • אפשר גם להשתמש ב-VPC משותף. אם אתם משתמשים ב-VPC משותף, בדרך כלל אתם משתמשים ב-Agent Platform בפרויקטGoogle Cloudנפרד מהפרויקט המארח של ה-VPC. מפעילים את Compute Engine API ואת Service Networking API בשני הפרויקטים. איך מקצים VPC משותף
  • אם רוצים להריץ את הדוגמאות של gcloud במדריך הזה, צריך להתקין את ה-CLI של gcloud.

התפקידים הנדרשים

אם אתם לא בעלים או עורכים של הפרויקט, ודאו שיש לכם את התפקיד 'אדמין של רשת Compute' (roles/compute.networkAdmin), שכולל את התפקידים הנדרשים לניהול משאבי רשת.

קישור בין רשתות שכנות לרשת מקומית

כדי להשתמש ב-VPC Network Peering עם רשת מקומית, צריך לבצע שלבים נוספים:

  1. חיבור הרשת המקומית ל-VPC. אפשר להשתמש במנהרת VPN או ב-Interconnect.
  2. מגדירים מסלולים בהתאמה אישית מ-VPC לרשת המקומית.
  3. מייצאים את הנתיבים המותאמים אישית כדי ש-Agent Platform תוכל לייבא אותם.

הגדרת גישה לשירותים פרטיים עבור ה-VPC

כשמגדירים גישה לשירותים פרטיים, יוצרים חיבור פרטי בין הרשת שלכם לבין רשת בבעלות Google או שירות של צד שלישי (ספקי שירותים). במקרה הזה, Agent Platform הוא בעלים של שירות מנוהל. כדי להגדיר גישה לשירותים פרטיים, משריינים טווח כתובות IP לבעלים של שירות מנוהל, ואז יוצרים חיבור קישור בין רשתות שכנות עם Agent Platform.

אם כבר יש לכם VPC עם גישה לשירותים פרטיים, אפשר לעבור אל ייצוא של מסלולים מותאמים אישית.

  1. מגדירים משתני סביבה למזהה הפרויקט, לשם הטווח השמור ולשם הרשת. אם אתם משתמשים ב-VPC משותף, צריך להשתמש במזהה הפרויקט של פרויקט המארח של ה-VPC. אחרת, משתמשים במזהה הפרויקט של פרויקט Google Cloud שבו משתמשים ב-Agent Platform.
  2. מפעילים את ממשקי ה-API הנדרשים. אם אתם משתמשים ב-VPC משותף, כדאי לעיין במאמר שימוש ב-VPC משותף עם Agent Platform.
  3. הגדרת טווח שמור באמצעות gcloud compute addresses create.

  4. יוצרים קישור בין פרויקט מארח VPC לבין Service Networking של Google באמצעות gcloud services vpc-peerings connect.

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

    רשת המשנה 172.16.0.0/16 שמורה ל-Vertex AI Training. צריך לציין רשת משנה שלא חופפת לטווח ה-CIDR הזה.

    PROJECT_ID=YOUR_PROJECT_ID
gcloud config set project $PROJECT_ID

# This is for display only; you can name the range anything.
PEERING_RANGE_NAME=google-reserved-range

NETWORK=YOUR_NETWORK_NAME

# NOTE: `prefix-length=16` means a CIDR block with mask /16 will be
# reserved for use by Google services, such as Agent Platform.
gcloud compute addresses create $PEERING_RANGE_NAME \
  --global \
  --prefix-length=16 \
  --description="peering range for Google service" \
  --network=$NETWORK \
  --purpose=VPC_PEERING

# Create the VPC connection.
gcloud services vpc-peerings connect \
  --service=servicenetworking.googleapis.com \
  --network=$NETWORK \
  --ranges=$PEERING_RANGE_NAME \
  --project=$PROJECT_ID

מידע נוסף על גישה לשירותים פרטיים

כדי להגדיר קבוצת משנה של המכסה שתישמר לשימוש במשימות אימון.

שימוש ב-VPC משותף עם Agent Platform

אם אתם משתמשים ב-VPC משותף בפרויקט, כדאי לעיין במאמר בנושא הקצאת VPC משותף ולוודא שאתם מבצעים את השלבים הבאים:

  1. מפעילים את Compute Engine API ואת Service Networking API בפרויקט המארח ובפרויקט השירות. צריך להפעיל את Agent Platform API בפרויקט השירות.

  2. יוצרים את הקישור בין רשת ה-VPC לבין שירותי Google בפרויקט המארח.

  3. במהלך יצירת Agent Platform, צריך לציין את שם הרשת שרוצים של-Agent Platform תהיה גישה ל-VPC משותף.

  4. מוודאים שלחשבון השירות או לחשבון המשתמש שבהם נעשה שימוש יש את התפקיד Compute Network User ‏(roles/compute.networkUser).

שמירת טווחי כתובות IP ל-Agent Platform

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

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

אם מפעילים עבודה עם הפרמטר --network, היא תופעל ברשת שמנוהלת על ידי Google ומקושרת ל-VPC שלכם:

--network = "projects/${host_project}/global/networks/${network}"

אפשר להפעיל משימות שלא צריכות גישה לרשתות שלכם בלי ההצהרה הזו, וכך לשמור על הקצאות ה-IP שלכם.

אם אתם לא מצליחים להזמין טווח IP רחב מספיק, כדאי לשקול מעבר מ-Gemini Enterprise Agent Platform עם גישה לשירותים פרטיים אל Gemini Enterprise Agent Platform עם Private Service Connect.

ייצוא של נתיבים מותאמים אישית

אם אתם משתמשים בנתיבים מותאמים אישית, אתם צריכים לייצא אותם כדי ש-Agent Platform תוכל לייבא אותם. אם אתם לא משתמשים במסלולים מותאמים אישית, אתם יכולים לדלג על הקטע הזה.

כדי לייצא נתיבים מותאמים אישית, צריך לעדכן את חיבור ה-Peering ב-VPC. כשמייצאים מסלולים מותאמים אישית, כל המסלולים הסטטיים והדינמיים שעומדים בדרישות שנמצאים ברשת ה-VPC, כמו מסלולים לרשת המקומית, מיוצאים לרשתות של ספקי שירותים (Agent Platform במקרה הזה). הפעולה הזו יוצרת את החיבורים הדרושים ומאפשרת לעבודות אימון לשלוח תנועה בחזרה לרשת המקומית.

צריך לוודא שיש ברשת המקומית מסלולים חזרה לטווחים של כתובות ה-IP שהוקצו ל-Agent Platform, כדי שהתשובות ינותבו חזרה ל-Agent Platform בצורה נכונה. לדוגמה, אפשר להשתמש בפרסומים של מסלולי ניתוב בהתאמה אישית ב-Cloud Router שכוללים את טווחי כתובות ה-IP של Agent Platform.

מידע נוסף על חיבורים פרטיים לרשתות מקומיות

המסוף

  1. נכנסים לדף VPC Network Peering במסוף Google Cloud .
    מעבר ל-VPC Network Peering
  2. בוחרים את חיבור ה-Peering שרוצים לעדכן.
  3. לוחצים על Edit.
  4. בוחרים באפשרות ייצוא של נתיבים מותאמים אישית.

gcloud

  1. מוצאים את השם של חיבור ה-peering שרוצים לעדכן. אם יש לכם כמה חיבורי peering, אל תכללו את הדגל --format.

    gcloud services vpc-peerings list \
  --network=$NETWORK \
  --service=servicenetworking.googleapis.com \
  --project=$PROJECT_ID \
  --format "value(peering)"

  2. מעדכנים את חיבור ה-Peering כדי לייצא נתיבים מותאמים אישית.

    gcloud compute networks peerings update PEERING-NAME \
    --network=$NETWORK \
    --export-custom-routes \
    --project=$PROJECT_ID

בדיקת הסטטוס של חיבורי ה-Peering

כדי לראות שחיבורי ה-Peering פעילים, אפשר להשתמש בפקודה הבאה כדי לפרט אותם:

gcloud compute networks peerings list --network $NETWORK

הסטטוס של ה-Peering שיצרתם אמור להיות ACTIVE. מידע נוסף על חיבורי Peering פעילים

פתרון בעיות

בקטע הזה מפורטות כמה בעיות נפוצות בהגדרת VPC Network Peering עם Agent Platform.

  • כשמגדירים את Agent Platform לשימוש ברשת VPC משותפת, מציינים את ה-URI של הרשת באופן הבא.

    "projects/YOUR_SHARED_VPC_HOST_PROJECT/global/networks/YOUR_SHARED_VPC_NETWORK"

  • אם מציינים רשת VPC משותפת לשימוש ב-Agent Platform, צריך לוודא שלכל משתמש או חשבון שירות שפועלים ב-Agent Platform בפרויקט השירות יש הרשאת תפקיד compute.networkUser בפרויקט המארח.

  • מוודאים שהקציתם טווח IP מספיק לכל ספקי השירותים שהרשת שלכם מתחברת אליהם, כולל Agent Platform.

  • אם מוצגות הודעות השגיאה IP_SPACE_EXHAUSTED, RANGES_EXHAUSTED או PEERING_RANGE_EXHAUSTED, צריך להגדיל את מספר כתובות ה-IP הזמינות לservicenetworking שמירת כתובות ברשת. אתם יכולים להוסיף טווח חדש להגדרת ה-VPC Network Peering הקיימת, או למחוק חלק מהמשאבים של Agent Platform כדי לפנות כתובות IP שהוקצו.

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

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

  • שגיאות DNS מסוג Host Unreachable: אם אתם צריכים ש-Gemini Enterprise Agent Platform יפענח שמות מארחים ב-VPC, ודאו שהשלמתם את ההגדרה של שיתוף אזורי DNS פרטיים עם ספקי שירותים.

  • אם יצירת עבודת הצינור נכשלת עם השגיאה 'שגיאה פנימית' שמופיעה בכלי Logs Explorer, צריך לוודא שרשת VPC נפרסה בנוסף לרשת המשנה של הגישה לשירותים פרטיים.

  • אתם יכולים לבדוק באילו כתובות IP משתמשים השירותים השונים, כדי לראות למשל באילו שירותים נעשה שימוש בבלוקים גדולים של כתובות IP, וכך להימנע ממיצוי של כתובות ה-IP.

  • אם מופיעה השגיאה Unable to create an instance within a Shared VPC network, אפשר להיעזר במאמר בנושא פתרון בעיות ב-Agent Platform Workbench.

  • אם מוצגת הודעת השגיאה For the peered network $network_name, couldn't find a free blocks in allocated IP ranges. This is needed to create the cluster., צריך להגדיל את מספר הטווחים המוקצים הזמינים לשירות. אפשר לעשות את זה בדרכים הבאות:

מידע נוסף על פתרון בעיות זמין במדריך לפתרון בעיות ב-VPC Network Peering.

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