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

בדף הזה מובאת סקירה כללית על ניהול חיבורים של שירותי Peering ברשת VPC.

חיבור Peering

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

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

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

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

אמצעי תחבורה

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

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

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

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

מצב עצמאי

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

מצב הסכמה

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

הגדרת מצב הסכמה לחיבור

אפשר להגדיר חיבור חדש או קיים של שותפות לצורך שימוש בסטטוס הסכמה על ידי הגדרת הפרמטר update_strategy:

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

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

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

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

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

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

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

עדכון חיבור במצב קונצנזוס

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

כדי לעדכן חיבור peering שהוגדר עם מצב קונצנזוס, מנהל הרשת המקומית צריך קודם לעדכן את ההגדרה המקומית. לאחר מכן, מנהל רשת העמיתים צריך לבצע עדכון משלים בהגדרת העמיתים. לדוגמה, אם מעדכנים את הדגל --export-custom-routes ל-true, הרשת העמיתה צריכה להגדיר את הדגל --import-custom-routes ל-true. המצב בפועל של חיבור ה-Peering לא משתנה עד שהרשת המקבילה מעדכנת את ההגדרה המתאימה.

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

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

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

בתרשים שלמעלה, אחרי שרשת א' שולחת את בקשת העדכון, סטטוס העדכון של החיבור משתנה מ-IN_SYNC ל-PENDING_PEER_ACKNOWLEDGMENT בהגדרה המקומית ול-PENDING_LOCAL_ACKNOWLEDGMENT בהגדרת ה-peer.

כדי לחזור לסטטוס IN_SYNC, רשת ב' צריכה לבצע את השינוי המשני או שרשת א' צריכה לבטל את הבקשה שלה. מידע נוסף על סטטוסי החיבור האלה

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

מחיקת חיבור במצב הסכמה

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

התנאים הבאים חלים על בקשות מחיקה:

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

מידע נוסף על מחיקת קישור (מצב קונצנזוס)

סטטוס החיבור

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

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

שדה מצב עצמאי מצב הסכמה תיאור
trafficConfiguration מוצגות אפשרויות החלפת המסלולים של חיבור ה-Peering.
updateStrategy בעמודה הזו מוצג מצב החיבור בפועל: INDEPENDENT או CONSENSUS.
consensusState.deleteStatus
  • ‫UNSPECIFIED: no requestRemovePeering requests are pending for this peering connection. השדה deleteStatus לא מופיע בפלט כשהסטטוס הוא UNSPECIFIED.
  • ‫LOCAL_DELETE_REQUESTED: הבעלים של ה-peering הזה ביקש למחוק את חיבור ה-peering.
  • ‫PEER_DELETE_REQUESTED: הבעלים של ה-peering התואם ביקש למחוק את חיבור ה-peering.
  • ‫DELETE_ACKNOWLEDGED: שני הבעלים של ה-peering בחיבור הזה ביקשו למחוק את חיבור ה-peering. בקשות removePeering הבאות יצליחו עבור כל אחת מההתקשרויות.
  • ‫LOCAL_CANCEL_REQUESTED: חיבור ה-Peering היה במצב DELETE_ACKNOWLEDGED, אבל הרשת המקומית ביטלה את המחיקה.
  • ‫PEER_CANCEL_REQUESTED: חיבור ה-Peering היה במצב DELETE_ACKNOWLEDGED, אבל הרשת של ה-Peer ביטלה את המחיקה.
consensusState.updateStatus
  • ‫IN_SYNC: לאף אחד מבעלי הפירינג אין עדכונים בהמתנה.
  • ‫PENDING_PEER_ACKNOWLEDGMENT: הבעלים של ה-peering המקומי ביצע שינוי, אבל הבעלים של ה-peering התואם לא החיל את השינויים המתאימים על ה-peering שלו.
  • ‫PENDING_LOCAL_ACKNOWLEDGMENT: הבעלים של ה-peering התואם ביצע שינוי, אבל הבעלים של ה-peering המקומי לא החיל את השינויים התואמים על ה-peering הזה.

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

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