מידע על חיבורי Peering

בדף הזה מובאת סקירה כללית על ניהול קישורים בין רשתות VPC שכנות (peering).

חיבורי Peering

חיבור Peering מקשר בין שתי רשתות של ענן וירטואלי פרטי (VPC). כדי ליצור חיבור קישור בין רשתות שכנות (peering), כל צד יוצר בנפרד הגדרת קישור בין רשתות שכנות (peering) שמפנה לרשת השנייה.

כדי ליצור בקשה להתחברות לרשת VPC אחרת, יוצרים הגדרת Peering. אחרי שברשת השנייה תהיה הגדרה תואמת ליצירת קשר עם הרשת שלכם, ייווצר חיבור הקישור בין רשתות שכנות (peering) ומצב הקישור בין רשתות שכנות (peering) ישתנה ל-ACTIVE בשתי הרשתות. סטטוס ה-peering נשאר INACTIVE אם לרשת השנייה אין הגדרת peering תואמת, מה שמצביע על כך שהרשת שלכם לא מחוברת לרשת השנייה.

יצירת חיבור בין רשתות שכנות לא מעניקה לכם תפקידים בניהול הזהויות והרשאות הגישה (IAM) ברשת ה-VPC השנייה. לדוגמה, אם יש לכם את התפקיד 'אדמין רשת של Compute'‏ (roles/compute.networkAdmin) או 'אדמין לענייני אבטחה של Compute'‏ (roles/compute.securityAdmin) ברשת אחת, אתם לא הופכים למנהלי רשת או לאדמינים לענייני אבטחה ברשת אחרת.

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

אמצעי תחבורה

מצב החיבור קובע איך מנהלים חיבורי Peering. קישור בין רשתות VPC שכנות (peering) תומך בשני מצבי חיבור:

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

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

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

מצב עצמאי

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

סטטוס הסכמה

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

מגבלות

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

הגדרת מצב קונצנזוס לחיבור

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

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

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

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

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

    הרשת שלכם רשת עמיתים
    import_custom_route export_custom_route
    export_custom_route import_custom_route
    import_subnet_routes_with_public_ip export_subnet_routes_with_public_ip
    export_subnet_routes_with_public_ip import_subnet_routes_with_public_ip
    stack_type stack_type
  • בקשות בהמתנה לעדכון מצב החיבור לא גורמות להשבתה, והחיבור נשאר פעיל בזמן שהבקשה נמצאת בתהליך.

מידע נוסף זמין במאמרים יצירת חיבור קישור בין רשתות שכנות (peering) במצב קונצנזוס ועדכון חיבור למצב קונצנזוס
.

מחיקת חיבור במצב קונצנזוס

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

מידע נוסף מופיע במאמר מחיקת חיבור (מצב קונצנזוס).

סטטוס החיבור

הפקודה gcloud compute networks describe מציגה את הסטטוס האפקטיבי של חיבור ה-Peering ואת הגדרת ה-Peering המקומי.

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

שדה מצב עצמאי סטטוס הסכמה תיאור
trafficConfiguration מוצגות אפשרויות יעילות להחלפת מסלולים של חיבור ה-Peering.
updateStrategy מציג את מצב החיבור: INDEPENDENT או CONSENSUS.
consensusState.deleteStatus
  • ‫UNSPECIFIED: אין בקשות בהמתנה לחיבור הקישור בין רשתות שכנות (peering) הזה.requestRemovePeering
  • ‫LOCAL_DELETE_REQUESTED: הבעלים של ה-peering הזה ביקש למחוק את חיבור ה-peering.
  • ‫PEER_DELETE_REQUESTED: הבעלים של ה-peering התואם ביקש למחוק את חיבור ה-peering.
  • ‫DELETE_ACKNOWLEDGED: שני הבעלים של ה-peering הזה ביקשו למחוק את חיבור ה-peering. בקשות removePeering עוקבות יצליחו עבור כל אחד מהפירינגים.
consensusState.updateStatus
  • IN_SYNC: לאף אחד מבעלי הקישור בין רשתות שכנות (peering) אין עדכונים בהמתנה.
  • ‫PENDING_PEER_ACK: הבעלים של ה-peering המקומי ביצע שינוי, אבל הבעלים של ה-peering התואם לא החיל את השינויים המתאימים על ה-peering שלו.
  • ‫PENDING_LOCAL_ACK: הבעלים של ה-peering התואם ביצע שינוי, אבל הבעלים של ה-peering המקומי לא החיל את השינויים התואמים ב-peering הזה.

כדי לראות את רשימת כל הגדרות ה-peering בפרויקט Google Cloud , אפשר לעיין במאמר בנושא הצגת רשימה של חיבורי peering.

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