מידע על שירותים שפורסמו (original) (raw)

מידע על שירותים שפורסמו

במאמר הזה מוסבר איך להשתמש ב-Private Service Connect כדי להפוך שירות לזמין לצרכני שירותים.

בתור בעלים של שירות מנוהל, אתם יכולים להשתמש ב-Private Service Connect כדי לפרסם שירותים באמצעות כתובות IP פנימיות ברשת ה-VPC שלכם. צרכני השירותים יכולים לגשת לשירותים שפרסמתם באמצעות כתובות IP פנימיות ברשתות ה-VPC שלהם.

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

סוגים של צרכני שירות

יש שני סוגים של צרכנים שיכולים להתחבר לשירות Private Service Connect:

• נקודות קצה של Private Service Connect
• בק-אנדים של Private Service Connect

נקודות הקצה מבוססות על כלל העברה.

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

הקצה העורפי מבוסס על מאזן עומסים.

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

רשתות משנה של NAT

קובצי שירות מצורפים של Private Service Connect מוגדרים עם רשתות משנה של NAT (שנקראות גם רשתות משנה של Private Service Connect). מנות מרשת ה-VPC של הצרכן מתורגמות באמצעות NAT של המקור (SNAT), כך שכתובות ה-IP המקוריות שלהן מומרות לכתובות IP של המקור מרשת המשנה של ה-NAT ברשת ה-VPC של היצרן.

לחיבורי שירות יכולות להיות כמה רשתות משנה של NAT. אפשר להוסיף לרכיב Service Attachment רשתות משנה נוספות של NAT בכל שלב בלי להפריע לתנועה.

אפשר להגדיר כמה רשתות משנה של NAT לחיבור שירות, אבל אי אפשר להשתמש ברשת משנה של NAT ביותר מחיבור שירות אחד.

אי אפשר להשתמש ברשתות משנה של NAT ב-Private Service Connect למשאבים כמו מכונות וירטואליות (VM) או כללי העברה. תת-הרשתות משמשות רק כדי לספק כתובות IP ל-SNAT של חיבורים נכנסים של צרכנים.

הגדרת גודל של רשת משנה של NAT

גודל רשת המשנה קובע כמה צרכנים יכולים להתחבר לשירות שלכם. אם כל כתובות ה-IP ברשת המשנה של ה-NAT נוצלו, כל חיבור נוסף של Private Service Connect ייכשל. כמה נקודות שכדאי לזכור:

• לכל נקודת קצה או לכל שרת backend שמחוברים ל-Service Attachment, נצרכת כתובת IP אחת מרשת המשנה של NAT.
  מספר החיבורים, הלקוחות או רשתות ה-VPC של הצרכנים ב-TCP או ב-UDP לא משפיע על צריכת כתובות ה-IP מרשת המשנה של ה-NAT.
• אם צרכנים משתמשים בהפצת חיבורים, נצרכת כתובת IP נוספת לכל רכזת VPC שאליה מופצים החיבורים, לכל נקודת קצה.
  כדי לקבוע כמה חיבורים מועברים ייצרו, אתם יכולים להגדיר את מגבלת החיבורים המועברים.
• כשמעריכים כמה כתובות IP צריך לנקודות קצה ולשרתי קצה, צריך לקחת בחשבון שירותים מרובי דיירים או צרכנים שמשתמשים בגישה מרובת נקודות ל-Private Service Connect.

מעקב אחרי רשתות משנה של NAT

כדי לוודא שחיבורים של Private Service Connect לא ייכשלו בגלל כתובות IP לא זמינות ברשת משנה של NAT, מומלץ:

• עוקבים אחרי private_service_connect/producer/used_nat_ip_addresses מדד הצמדת השירות. מוודאים שמספר כתובות ה-IP של NAT שנמצאות בשימוש לא חורג מהקיבולת של רשתות המשנה של NAT בקובץ המצורף של השירות.
• לעקוב אחר סטטוס החיבור של חיבורים של קבצים מצורפים לשירות. אם הסטטוס של החיבור הוא נדרשת התערבות, יכול להיות שלא נותרו כתובות IP ברשתות המשנה של NAT בקובץ המצורף.
• בשירותים מרובי דיירים, אפשר להשתמש במגבלות על חיבורים כדי לוודא שצרכן יחיד לא ינצל את כל הקיבולת של רשתות המשנה של NAT בחיבור שירות.

במקרה הצורך, אפשר להוסיף רשתות משנה של NAT לצירוף השירות בכל שלב בלי להפריע לתנועה.

מפרט NAT

כשמתכננים את השירות שמפרסמים, כדאי לקחת בחשבון את המאפיינים הבאים של NAT ב-Private Service Connect:

• הזמן הקצוב לתפוגה של מיפוי UDP בלי פעילות הוא 30 שניות ואי אפשר להגדיר אותו.
• הזמן הקצוב לתפוגה של חיבור TCP במצב סרק הוא 20 דקות, ואי אפשר להגדיר אותו.
  כדי למנוע בעיות שקשורות לחיבורים של לקוחות שתם הזמן הקצוב שלהם לתפוגה, אפשר לנסות אחד מהפתרונות הבאים:
  • מוודאים שכל החיבורים נמשכים פחות מ-20 דקות.
  • מוודאים שחלק מהתנועה נשלח בתדירות גבוהה יותר מפעם ב-20 דקות. אתם יכולים להשתמש ב-heartbeat או ב-keepalive באפליקציה שלכם, או ב-TCP keepalives. לדוגמה, אפשר להגדיר keepalive בשרת proxy ליעד של מאזן עומסים אזורי פנימי של אפליקציות או של מאזן עומסי רשת אזורי פנימי בשרת proxy.
• הזמן הקצוב לתפוגה של חיבור TCP זמני במצב סרק הוא 30 שניות, ואי אפשר להגדיר אותו.
• יש עיכוב של שתי דקות לפני שאפשר לעשות שימוש חוזר ב-5-tuple (כתובת IP של מקור ברשת משנה של NAT ויציאת מקור, בנוסף לפרוטוקול היעד, כתובת ה-IP ויציאת היעד).
• ‫SNAT ל-Private Service Connect לא תומך בפרגמנטים של כתובות IP.

מספר מקסימלי של חיבורים

מכונה וירטואלית אחת של בעלי שירות יכולה לקבל לכל היותר 64,512 חיבורי TCP בו-זמניים ו-64,512 חיבורי UDP בו-זמניים מצרכן אחד של Private Service Connect (נקודת קצה או קצה עורפי). אין הגבלה על המספר הכולל של חיבורי TCP ו-UDP שיכולים להתקבל בנקודת קצה של Private Service Connect (PSC) באופן מצטבר בכל הבק-אנדים של הספק. מכונות וירטואליות של לקוחות יכולות להשתמש בכל 65,536 יציאות המקור כשהן יוזמות חיבורי TCP או UDP לנקודת קצה (endpoint) של Private Service Connect. כל תרגום כתובות הרשת (NAT) מתבצע באופן מקומי במארח של המפיק, ולכן לא נדרש מאגר של יציאות NAT שהוקצו באופן מרכזי.

קבצים מצורפים לשירות

הבעלים של השירות המנוהל חושף את השירות שלו באמצעות קובץ מצורף של שירות. לחיבורי שירות יש את המאפיינים הבאים:

• כדי לחשוף שירות, הבעלים של השירות המנוהל יוצר קובץ מצורף לשירות שמפנה לשירות יעד. שירות היעד יכול להיות אחד מהשירותים הבאים:
  • כלל ההעברה של מאזן עומסים
  • מופע של Secure Web Proxy
• הפורמט של ה-URI של קובץ השירות המצורף הוא:projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME
• לחיבור שירות יכול להיות רק שירות יעד אחד.
• כמה קבצים מצורפים של שירות יכולים לשתף את אותו שירות יעד.
• אפשר לעדכן את שירות היעד של קובץ מצורף לשירות בלי ליצור מחדש את הקובץ המצורף לשירות.
• קבצים מצורפים של שירותים מאפשרים לכם לשלוט בגישה לשירות שפרסמתם, לראות את החיבורים ולהגדיר מגבלות על החיבורים. מידע נוסף זמין במאמר שליטה בגישה לשירותים שפורסמו.

סטטוסים של חיבור

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

הגדרת DNS

מידע על הגדרת DNS לשירותים שפורסמו ולנקודות קצה (endpoints) שמתחברות לשירותים שפורסמו זמין במאמר הגדרת DNS לשירותים.

הגדרה של מספר אזורים למעבר אוטומטי לגיבוי

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

הגדרת המפיק:

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

הגדרות לצרכנים:

• יוצרים בק-אנד של Private Service Connect כדי לגשת לשירותים שפורסמו. הקצה העורפי צריך להתבסס על מאזן עומסים שתומך במעבר לגיבוי בעת כשל בין אזורים ולכלול את ההגדרה הבאה:
  • ‫ Private Service Connect NEG בכל אזור שמצביע על קובץ מצורף עם השירות של אותו אזור
  • שירות גלובלי לקצה עורפי שמכיל את הקצוות העורפיים של Private Service Connect NEG

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

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

מידע נוסף על מעבר לגיבוי בעקבות כשל באזורים שונים:

• מידע על Composite Health
• מעבר אוטומטי לגיבוי באזור אחר לצרכנים

תרגום של גרסת ה-IP

בנקודות קצה של Private Service Connect שמחוברות לשירותים שפורסמו (קבצים מצורפים של שירותים), גרסת ה-IP של כתובת ה-IP של כלל ההעברה של הצרכן קובעת את גרסת ה-IP של נקודת הקצה והתנועה שיוצאת מנקודת הקצה. כתובת ה-IP יכולה להגיע מרשת משנה עם IPv4 בלבד, IPv6 בלבד או עם שניהם. גרסת ה-IP של נקודת הקצה יכולה להיות IPv4 או IPv6, אבל לא שתיהן.

בשירותים שפורסמו, גרסת ה-IP של קובץ ה-Service Attachment נקבעת לפי כתובת ה-IP של כלל ההעברה המשויך או של מופע Secure Web Proxy. כתובת ה-IP הזו צריכה להיות תואמת לסוג הערימה של רשת המשנה של NAT של קובץ השירות. רשת המשנה של NAT יכולה להיות רשת משנה של IPv4 בלבד, של IPv6 בלבד או של dual-stack. אם רשת המשנה של ה-NAT היא רשת משנה עם תמיכה כפולה, נעשה שימוש בטווח כתובות IPv4 או IPv6, אבל לא בשניהם.

‫Private Service Connect לא תומך בחיבור של נקודת קצה IPv4 לקובץ מצורף של שירות IPv6. במקרה כזה, יצירת נקודת הקצה נכשלת ומוצגת הודעת השגיאה הבאה:

Private Service Connect forwarding rule with an IPv4 address cannot target an IPv6 service attachment.

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

• נקודת קצה של IPv4 לחיבור שירות של IPv4
• נקודת קצה של IPv6 לצירוף שירות IPv6
• נקודת קצה של IPv6 לצירוף שירות של IPv4
  בהגדרה הזו, ‏Private Service Connect מתרגם באופן אוטומטי בין שתי גרסאות ה-IP.

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

תכונות ותאימות

בטבלאות הבאות, הסימן מציין שיש תמיכה בתכונה, והסימן מציין שאין תמיכה בתכונה.

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

תמיכה בנקודות קצה

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

הגדרות צרכן

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

הגדרות של Producer

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

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

תמיכה בשרתי קצה עורפיים

בק-אנד של Private Service Connect לשירותים שפורסמו דורש שני מאזני עומסים – מאזן עומסים של צרכן ומאזן עומסים של בעלים. בקטע הזה מפורטות אפשרויות ההגדרה שזמינות לצרכנים ולספקים כשמשתמשים בשרתי קצה עורפיים כדי לגשת לשירותים שפורסמו.

הגדרות צרכן

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

הגדרות של Producer

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

הגדרות יציאה של כלי להפקת חדשות

כשמפרסמים מאזן עומסים פנימי מסוג Network Load Balancer באמצעות Private Service Connect, צרכנים שמשתמשים בבק-אנדים של Private Service Connect כדי לגשת לשירות צריכים לדעת באיזו יציאה להשתמש כדי לתקשר עם השירות. כשיוצרים את כלל ההעברה למאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי של הפקת הנתונים, כדאי לשים לב לנקודות הבאות:

• מומלץ להודיע לצרכנים באיזה יציאה משתמשים בכלל להעברת נתונים מהיצרן, כדי שהם יוכלו לציין את היציאה כשהם יוצרים NEG.
• אם הצרכנים לא מציינים יציאת יצרן כשהם יוצרים קבוצות NEG, יציאת היצרן נקבעת על סמך ההגדרה של כלל העברת התנועה של היצרן:
  • אם כלל העברת התנועה של היצרן משתמש ביציאה אחת, קצה העורפי של הצרכן משתמש באותה יציאה.
  • אם כלל ההעברה של המפיק משתמש בכמה יציאות, התנאים הבאים חלים:
    * אם כוללים את היציאה 443, העורף של הצרכן משתמש ביציאה 443.
    * אם היציאה 443 לא נכללת, ה-backend של הצרכן משתמש ביציאה הראשונה ברשימה, אחרי שהרשימה ממוינת לפי סדר אלפביתי. לדוגמה, אם מציינים את יציאה 80 ואת יציאה 1111, ה-backend של הצרכן משתמש ביציאה 1111.
    * שינוי היציאות שמשמשות את ה-backend של השירות המנוהל עלול לגרום להפסקת שירות עבור הצרכנים.
    לדוגמה, נניח שאתם יוצרים שירות שפורסם עם כלל העברה שמשתמש ביציאות 443 ו-8443, ומכונות וירטואליות בעורף השרת שמגיבות ביציאות 443 ו-8443. כשמערכת קצה של צרכן מתחברת לשירות הזה, היא משתמשת ביציאה 443 לתקשורת.
    אם תשנו את מכונות ה-VM של ה-Backend כך שיגיבו רק ביציאה 8443, ה-Backend של הצרכן לא יוכל יותר להגיע לשירות שפורסם.
• אם כלל ההעברה של הבעלים של השירות המנוהל משתמש בכל היציאות, צרכן השירות חייב לציין יציאה של הבעלים של השירות המנוהל כשהוא יוצר את ה-NEG. אם לא מציינים יציאה, ה-backend של הלקוח משתמש ביציאה 1, שלא פועלת.

שינוי שירות

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

חיבורים של צרכנים לא נמחקים ולא נוצרים מחדש במהלך העדכון הזה, וכל חיבור שומר על מזהה החיבור שלו ב-Private Service Connect‏ (pscConnectionId). עם זאת, במהלך העדכון, התנועה מופרעת לזמן קצר. אחרי שהעדכון מסתיים, זרימת התנועה מתחדשת בלי שנדרשת פעולה נוספת מהיצרן או מהצרכן.

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

• צריך לשייך את קובץ ה-Service Attachment לשירות יעד.
• לשירות היעד החדש צריכות להיות אותה רשת VPC, אותו אזור ואותה גרסת IP כמו לשירות הקודם.
• אי אפשר לעדכן שירות יעד של מיפוי יציאות אם לחיבור השירות יש חיבורים מצרכנים שמשתמשים בבק-אנדים של Private Service Connect.
• ההגדרות של הגישה הגלובלית (allow-psc-global-access) בשירותי היעד החדשים והקיימים צריכות להיות זהות. אם צריך לשנות את הגישה הגלובלית, קודם מעדכנים את קובץ ה-ServiceAttachment כך שיפנה לשירות היעד החדש, ואז מעדכנים את מאפיין הגישה הגלובלית של השירות בפעולה נפרדת.
• כדי לעדכן שירות יעד להעברת פרוטוקול פנימי, אתם צריכים להשתמש ב-CLI של gcloud או לשלוח בקשת API.

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

אדמינים של פרויקטים של שירותים יכולים ליצור קבצים מצורפים לשירותים בפרויקטים של שירותים ב-VPC משותף, שמתחברים למשאבים ברשתות VPC משותפות.

ההגדרה זהה לזו של קובץ מצורף רגיל לשירות, למעט ההבדלים הבאים:

• כלל ההעברה של מאזן העומסים של היצרן משויך לכתובת IP מרשת ה-VPC המשותפת. רשת המשנה של כלל ההעברה צריכה להיות משותפת עם פרויקט השירות.
• קובץ מצורף של שירות משתמש ברשת משנה של Private Service Connect מרשת ה-VPC המשותפת. צריך לשתף את רשת המשנה הזו עם פרויקט השירות.

רישום ביומן

אפשר להפעיל יומני זרימה של VPC ברשתות המשנה שמכילות את מכונות ה-VM של ה-Backend. היומנים מציגים זרימות בין המכונות הווירטואליות של הקצה העורפי לבין כתובות IP ברשת המשנה של Private Service Connect.

VPC Service Controls

‫VPC Service Controls ו-Private Service Connect תואמים זה לזה. אם רשת ה-VPC שבה נקודת הקצה של Private Service Connect פרוסה נמצאת בגבולות גזרה של VPC Service Controls, נקודת הקצה היא חלק מאותם גבולות גזרה. כל השירותים שנתמכים על ידי VPC Service Controls שאליהם ניגשים דרך נקודת הקצה כפופים למדיניות של גבולות הגזרה של VPC Service Controls.

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

הצגת פרטי החיבור של הצרכן

כברירת מחדל, Private Service Connect מתרגם את כתובת ה-IP של המקור של הצרכן לכתובת באחת מתת-הרשתות של Private Service Connect ברשת ה-VPC של ספק השירות. אם רוצים לראות את כתובת ה-IP המקורית של הצרכן, אפשר להפעיל את פרוטוקול PROXY כשמפרסמים שירות. ‫Private Service Connect תומך בפרוטוקול PROXY בגרסה 2.

לא כל השירותים תומכים בפרוטוקול PROXY. מידע נוסף זמין במאמר בנושא תכונות ותאימות.

אם פרוטוקול PROXY מופעל, אפשר לקבל את כתובת ה-IP של הצרכן ואת מזהה החיבור של PSC ‏ (pscConnectionId) מכותרת פרוטוקול PROXY.

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

בתעבורת נתונים של צרכנים שעוברת דרך חיבור שהועבר, כתובת ה-IP של הצרכן ומזהה החיבור של PSC מתייחסים לנקודת הקצה של Private Service Connect שהועברה.

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

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

מזהה החיבור של Private Service Connect‏ (pscConnectionId) מקודד בכותרת של פרוטוקול PROXY בפורמט Type-Length-Value (TLV).

אפשר לראות את הערך pscConnectionId באורך 8 בייט מכלל העברת הנתונים של הצרכן או מהקובץ המצורף של שירות היצרן.

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

• ברשת VPC נתונה, אם מוחקים נקודת קצה (כלל העברה) ויוצרים נקודת קצה חדשה באמצעות אותה כתובת IP, יכול להיות שייעשה שימוש באותו ערך pscConnectionId.
• אם מוחקים רשת VPC שמכילה נקודות קצה (כללי העברה), אחרי תקופת המתנה של שבעה ימים, יכול להיות שהערך pscConnectionId ששימש את נקודות הקצה האלה ישמש נקודת קצה אחרת ברשת VPC אחרת.

אפשר להשתמש בערכי pscConnectionId לצורך ניפוי באגים ולמעקב אחרי מקורות החבילות.

מזהה נפרד של קובץ מצורף עם שירות Private Service Connect בגודל 16 בייט (pscServiceAttachmentId) זמין מקובץ מצורף עם שירות ההפקה. הערך pscServiceAttachmentId הוא מזהה ייחודי וגלובלי שמזהה קובץ מצורף עם השירות Private Service Connect. אפשר להשתמש בערךpscServiceAttachmentId לצורך שקיפות וניפוי באגים. הערך הזה לא נכלל בכותרת של פרוטוקול ה-PROXY.

תמחור

המחירים של Private Service Connect מפורטים בדף המחירים של VPC.

מכסות

מספר נקודות הקצה של Private Service Connect והחיבורים המועברים הכולל מכל צרכן שיכולים לגשת לרשת ה-VPC של הספק מוגבל על ידי מכסת PSC ILB consumer forwarding rules per producer VPC network.

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

גישה מקומית

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

מגבלות

יש מגבלות על שירותים שפורסמו:

• מאזני עומסים שמוגדרים עם כמה פרוטוקולים – הפרוטוקול מוגדר כ-L3_DEFAULT – לא נתמכים.
• אי אפשר לבצע רפליקציה של חבילות נתונים עבור תעבורת נתונים של שירותים שפורסמו ב-Private Service Connect.
• כדי ליצור קובץ מצורף לשירות שמפנה לכלל העברה שמשמש להעברת פרוטוקול פנימית, צריך להשתמש ב-Google Cloud CLI או ב-API.

לרשימת הבעיות והפתרונות העקיפים, אפשר לעיין בבעיות מוכרות.