VPC משותף

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

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

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

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

מושגים

ארגונים, תיקיות ופרויקטים

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

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

פרויקט שמשתתף ב-VPC משותף הוא פרויקט מארח או פרויקט שירות:

  • פרויקט מארח מכיל רשתות VPC משותפות אחת או יותר. אדמין של VPC משותף צריך קודם להפעיל פרויקט כפרויקט מארח. לאחר מכן, אדמין של VPC משותף יכול לצרף אליו פרויקט שירות אחד או יותר.

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

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

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

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

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

רשת VPC עצמאית היא רשת VPC לא משותפת שקיימת בפרויקט עצמאי או בפרויקט שירות.

רשתות

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

כשמפעילים פרויקט מארח, יש שתי אפשרויות לשיתוף רשתות:

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

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

מגבלות שקשורות למדיניות הארגון

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

אם אתם אדמינים של מדיניות הארגון, אתם יכולים לציין את האילוצים הבאים של VPC משותף במדיניות הארגון:

  • אתם יכולים להגביל את קבוצת הפרויקטים המארחים שאליהם אפשר לצרף פרויקט שאינו מארח או פרויקטים שאינם מארחים בתיקייה או בארגון. ההגבלה חלה כשמנהל של VPC משותף מצרף פרויקט שירות לפרויקט מארח. המגבלה לא משפיעה על קבצים מצורפים קיימים. קבצים מצורפים קיימים יישארו ללא שינוי גם אם מדיניות מסוימת תמנע הוספה של קבצים מצורפים חדשים. מידע נוסף מופיע במאמר בנושא האילוץ constraints/compute.restrictSharedVpcHostProjects.

  • אפשר לציין את רשתות המשנה של ה-VPC המשותף שפרויקט שירות יכול לגשת אליהן ברמת הפרויקט, התיקייה או הארגון. האילוץ חל כשיוצרים מכונות וירטואליות ומאזני עומסים חדשים ברשתות המשנה שצוינו, והוא לא משפיע על משאבים קיימים. מכונות ה-VM ומאזני העומסים הקיימים ממשיכים לפעול כרגיל ברשתות המשנה שלהם, גם אם מדיניות מסוימת מונעת הוספה של משאבים חדשים. המגבלה הזו חלה רק על רשתות המשנה, ולא מאפשרת להשתמש בהן למכונות וירטואליות ולמאזני עומסים. ההגבלה הזו לא חלה על כללי העברה שמשמשים לנקודות קצה של Private Service Connect. מידע נוסף זמין במאמר בנושא האילוץ constraints/compute.restrictSharedVpcSubnetworks.

אדמינים ו-IAM

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

תפקידי אדמין נדרשים

אדמין (תפקיד IAM) מטרה
אדמין ארגוני (resourcemanager.organizationAdmin)
  • יש לו הרשאת IAM בארגון		 לאדמינים ארגוניים יש את התפקיד resourcemanager.organizationAdmin בארגון. הם ממנים אדמינים של VPC משותף על ידי הקצאת תפקידים מתאימים ליצירה ולמחיקה של פרויקטים, וגם את התפקיד אדמין של VPC משותף בארגון. אדמינים כאלה יכולים להגדיר מדיניות ברמת הארגון, אבל כדי לבצע פעולות ספציפיות בתיקיות ובפרויקטים הם צריכים תפקידים נוספים ברמת התיקייה והפרויקט.
אדמין של VPC משותף
(compute.xpnAdmin ו-
resourcemanager.projectIamAdmin)
  • IAM principal בארגון, או
  • IAM principal בתיקייה		 לאדמינים של VPC משותף יש את התפקידים אדמין של VPC משותף ב-Compute (compute.xpnAdmin) ו אדמין IAM של פרויקט (resourcemanager.projectIamAdmin) בארגון או בתיקייה אחת או יותר. הם מבצעים משימות שונות שנדרשות כדי להגדיר VPC משותף, כמו הפעלת פרויקטים מארחים, צירוף פרויקטים של שירותים לפרויקטים מארחים והקצאת גישה לחלק מרשתות המשנה ברשתות VPC משותפות או לכולן לאדמינים של פרויקטים של שירותים. אדמין של VPC משותף בפרויקט מארח נתון הוא בדרך כלל גם בעל הפרויקט.
משתמש שהוקצה לו התפקיד Compute Shared VPC Admin בארגון מקבל את התפקיד הזה בכל התיקיות בארגון. משתמש שהוקצה לו תפקיד בתיקייה מסוימת מקבל את התפקיד הזה גם בתיקייה הזו וגם בכל התיקיות שמוכלות בה. אדמין של VPC משותף יכול לקשר פרויקטים בשתי תיקיות שונות רק אם יש לו את התפקיד בשתי התיקיות.
אדמין של פרויקט שירות
(compute.networkUser)
  • IAM principal בארגון, או
  • IAM principal בפרויקט מארח, או
  • IAM principal בחלק מרשתות המשנה בפרויקט המארח		 אדמין של VPC משותף מגדיר אדמין של פרויקט שירות על ידי הענקת ההרשאה Network User (compute.networkUser) למשתמש ראשי ב-IAM בפרויקט המארח כולו או ברשתות משנה נבחרות של רשתות ה-VPC המשותפות שלו. אדמינים של פרויקטים של שירותים גם שומרים על הבעלות והשליטה במשאבים שמוגדרים בפרויקטים של השירותים, ולכן צריך להקצות להם את התפקיד Instance Admin (compute.instanceAdmin) בפרויקטים המתאימים של השירותים. יכול להיות שיהיו להם תפקידי IAM נוספים בפרויקטים של השירות, כמו בעלים של הפרויקט.

אדמינים של פרויקט שירות

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

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

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

אדמינים של רשתות ואבטחה

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

מנהל מערכת מטרה
אדמין רשת
  • חשבון ראשי ב-IAM בפרויקט המארח, או
  • חשבון ראשי ב-IAM בארגון		 אדמין של VPC משותף מגדיר אדמין רשתות על ידי הקצאת התפקיד אדמין רשתות (compute.networkAdmin) לחשבון ראשי ב-IAM בפרויקט המארח. לאדמינים של הרשת יש שליטה מלאה בכל משאבי הרשת, למעט כללי חומת אש ואישורי SSL.
אדמין לענייני אבטחה
  • IAM principal בפרויקט המארח, או
  • IAM principal בארגון		 אדמין של VPC משותף יכול להגדיר אדמין לענייני אבטחה על ידי הקצאת התפקיד אדמין לענייני אבטחה (compute.securityAdmin) לחשבון ראשי ב-IAM בפרויקט המארח. אדמינים של אבטחה מנהלים כללי חומת אש ואישורי SSL.

מפרטים

מכסות ומגבלות

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

חיוב

החיוב על משאבים שמשתתפים ברשת VPC משותפת משויך לפרויקט השירות שבו נמצא המשאב, גם אם המשאב משתמש ברשת ה-VPC המשותפת בפרויקט המארח.

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

משאבים

מקורות מידע שעומדים בדרישות

אתם יכולים להשתמש ברוב Google Cloud המוצרים והתכונות בפרויקטים של שירות VPC משותף.

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

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

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

כתובות IP

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

מופעים בפרויקטי שירות שמצורפים לפרויקט מארח שמשתמש באותה רשת VPC משותפת יכולים לתקשר ביניהם באופן פנימי באמצעות כתובות IPv4 פנימיות או כתובות IPv6 פנימיות או חיצוניות, בכפוף לכללי חומת האש הרלוונטיים.

אדמינים בפרויקט שירות יכולים להקצות למשאבים בפרויקט שירות כל אחד מסוגי כתובות ה-IP הבאים:

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

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

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

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

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

DNS פנימי

מכונות וירטואליות באותו פרויקט שירות יכולות להגיע זו לזו באמצעות שמות DNS פנימיים ש- Google Cloud יוצר באופן אוטומטי. שמות ה-DNS האלה משתמשים במזהה הפרויקט של פרויקט השירות שבו נוצרו מכונות ה-VM, למרות שהשמות מצביעים על כתובות IP פנימיות בפרויקט המארח. הסבר מלא זמין במאמר שמות DNS פנימיים ו-VPC משותף במסמכי DNS פנימי.

תחומים פרטיים ב-Cloud DNS

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

איזון עומסים

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

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

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

דוגמאות ותרחישי שימוש

מושגים בסיסיים

איור 1 מציג תרחיש פשוט של VPC משותף:

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

  • אדמין של VPC משותף בארגון יצר פרויקט מארח וצירף אליו שני פרויקטים של שירותים:

    • אפשר להגדיר לאדמינים של פרויקט שירות ב-Service project A גישה לכל תת-הרשתות ברשת ה-VPC המשותפת או לחלק מהן. אדמין של פרויקט שירות עם הרשאות ברמת רשת המשנה לפחות ל-10.0.1.0/24 subnet יצר Instance A באזור של אזור us-west1. המופע הזה מקבל את כתובת ה-IP הפנימית שלו, 10.0.1.3, מבלוק ה-CIDR‏ 10.0.1.0/24.

    • אפשר להגדיר לאדמינים של פרויקט שירות ב-Service project B גישה לכל תת-הרשתות ברשת ה-VPC המשותפת או לחלק מהן. אדמין של פרויקט שירות עם הרשאות ברמת רשת המשנה לפחות ל-10.15.2.0/24 subnet יצר Instance B באזור של אזור us-east1. המופע הזה מקבל את כתובת ה-IP הפנימית שלו, 10.15.2.4, מבלוק ה-CIDR‏ 10.15.2.0/24.

  • פרויקט עצמאי לא משתתף ב-VPC המשותף בכלל, והוא לא פרויקט מארח ולא פרויקט שירות. יצירת מופעים עצמאיים מתבצעת על ידי חשבונות משתמשים ב-IAM שיש להם לפחות את התפקיד compute.InstanceAdmin בפרויקט.

פרויקטים עם כמה מארחים

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

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

  • אדמין של VPC משותף בארגון יצר שני פרויקטים מארחים וצירף אליהם שני פרויקטים של שירותים באופן הבא:

    • פרויקטי השירות Apps testing ו-Mobile testing מצורפים לפרויקט המארח Test environment. אפשר להגדיר לאדמינים של פרויקט שירות בכל פרויקט גישה לכל תת-הרשתות ב-Testing network או לחלק מהן.

    • פרויקטי השירות Apps production ו-Mobile production מצורפים לפרויקט המארח Production environment. אפשר להגדיר אדמינים של פרויקט שירות בכל פרויקט כך שתהיה להם גישה לכל רשתות המשנה ב-Production network או לחלק מהן.

  • לשני הפרויקטים המארחים יש רשת VPC משותפת אחת עם תת-רשתות שהוגדרו לשימוש באותם טווחי CIDR. בשני המקרים, Testing network ו-Production network, שתי רשתות המשנה הן:

    • 10.0.1.0/24 subnet באזור us-west1

    • 10.15.2.0/24 subnet באזור us-east1

  • כדאי לשקול את Instance AT בפרויקט השירות Apps testing ואת Instance AP בפרויקט השירות Apps production:

    • אדמינים של פרויקט שירות יכולים ליצור מופעים כמו אלה, בתנאי שיש להם הרשאות ברמת רשת המשנה לפחות ל-10.0.1.0/24 subnet.

    • שימו לב ששתי המכונות משתמשות בכתובת ה-IP‏ 10.0.1.3. זה מקובל כי כל מופע קיים בפרויקט שירות שמצורף לפרויקט מארח ייחודי שמכיל רשת VPC משותפת משלו. רשתות הבדיקה והייצור הוגדרו בכוונה באותו אופן.

    • מכונות שמשתמשות ב-10.0.1.0/24 subnet חייבות להיות ממוקמות באזור באותו אזור כמו תת-הרשת, גם אם תת-הרשת והמכונות מוגדרות בפרויקטים נפרדים. מכיוון שרשת המשנה 10.0.1.0/24 subnet נמצאת באזור us-west1, אדמינים של פרויקט שירות שיוצרים מופעים באמצעות רשת המשנה הזו צריכים לבחור תחום באותו אזור, כמו us-west1-a.

תרחיש של ענן היברידי

באיור 3 מוצג אופן השימוש ב-VPC משותף בסביבה היברידית.

איור 3. רשת VPC משותפת שמחוברת לרשת מקומית ולשלושה פרויקטים של שירותים (אפשר ללחוץ כדי להגדיל).

בדוגמה הזו, ארגון יצר פרויקט מארח יחיד עם רשת VPC משותפת אחת. רשת ה-VPC המשותפת מחוברת לרשת מקומית באמצעות Cloud VPN. חלק מהשירותים והאפליקציות מתארחים ב- Google Cloud , וחלקם נשמרים במקום:

  • אדמין של VPC משותף הפעיל את פרויקט המארח וקישר אליו שלושה פרויקטים של שירותים: Service project A,‏ Service project B ו-Service project C.

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

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

      • אדמין בפרויקט שירות של Service project A שיש לו הרשאות ברמת רשת המשנה ל-10.0.1.0/24 subnet יכול ליצור בו Instance A. האדמין של פרויקט השירות צריך לבחור אזור בתוך us-west1האזור של המופע, כי זה האזור שמכיל את 10.0.1.0/24 subnet. ‫Instance A מקבלת את כתובת ה-IP שלה, ‫10.0.1.3, מתוך טווח כתובות ה-IP החופשיות ב-10.0.1.0/24 subnet.

      • אדמין בפרויקט שירות Service project B עם הרשאות ברמת רשת המשנה ל-10.15.2.0/24 subnet יכול ליצור Instance B בתוכו. האדמין של פרויקט השירות צריך לבחור אזור בתוך us-east1האזור של המופע, כי זה האזור שמכיל את 10.15.2.0/24 subnet. ‫Instance B מקבלת את כתובת ה-IP שלה, ‫10.15.2.4, מתוך טווח כתובות ה-IP החופשיות ב-10.15.2.0/24 subnet.

      • אדמין של פרויקט שירות Service project C שיש לו הרשאות ברמת הפרויקט לכל הפרויקט המארח יכול ליצור מכונות וירטואליות בכל אחת מרשתות המשנה בכל אחת מרשתות ה-VPC בפרויקט המארח. לדוגמה, אדמין בפרויקט השירות יכול ליצור Instance C ב-10.7.1.0/24 subnet, ולבחור אזור ב-us-east1 שיתאים לאזור של רשת המשנה. ‫Instance C מקבלת את כתובת ה-IP שלה, ‫10.7.1.50, מתוך טווח כתובות ה-IP החופשיות ב-10.7.1.0/24 Subnet.

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

  • אדמין של VPC משותף הקצה משימות ניהול רשת לגורמים אחרים ב-IAM שהם אדמינים של רשתות ואבטחה ברשת ה-VPC המשותפת.

    • אדמין רשת יצר שער Cloud VPN והגדיר מנהרת VPN דרך האינטרנט לשער מקומי. רשת Cloud VPN מחליפה נתיבים עם הרשת המקבילה המקומית, כי הוגדר Cloud Router תואם באותו אזור us-east1.

    • אם מצב הניתוב הדינמי של ה-VPC הוא גלובלי, Cloud Router מחיל את המסלולים שנלמדו על הרשת המקומית בכל תת-הרשתות ברשת ה-VPC, ומשתף מסלולים עם כל תת-הרשתות של ה-VPC עם המקבילה המקומית שלו.

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

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

שירות אינטרנט דו-שכבתי

באיור 4 מוצג איך אפשר להשתמש ב-VPC משותף כדי להקצות אחריות אדמיניסטרטיבית ולשמור על העיקרון של הרשאות מינימליות. במקרה הזה, לארגון יש שירות אינטרנט שמחולק לשתי רמות, וצוותים שונים מנהלים כל רמה. רמה 1 מייצגת את הרכיב שפונה כלפי חוץ, מאחורי מאזן עומסים מסוג HTTP(S). רמה 2 מייצגת שירות פנימי שרמה 1 מסתמכת עליו, והאיזון מתבצע באמצעות מאזן עומסים פנימי של TCP/UDP.

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

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

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

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

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

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

  • בקרת הגישה לרשת מוגדרת באופן הבא:

    • למשתמשי IAM שפועלים רק ברמה 1 יש הרשאות אדמין בפרויקט השירות של Tier 1 service project, והם מקבלים הרשאות ברמת רשת המשנה רק עבור 10.0.1.0/24 subnet. בדוגמה הזו, אדמין אחד של פרויקט שירות יצר שלוש מכונות Tier 1 instances בתת-הרשת הזו.

    • גורמים ב-IAM שעובדים רק ברמה 2 הם אדמינים של פרויקט השירות Tier 2 service project ומקבלים הרשאות ברמת רשת המשנה רק עבור 10.0.2.0/24 subnet. בדוגמה הזו, אדמין אחר של פרויקט שירות יצר שלוש מכונות וירטואליות ברשת המשנה הזו, יחד עם מאזן עומסים פנימי שכלל ההעברה שלו משתמש בכתובת IP מהטווח שזמין ברשת המשנה הזו.Tier 2 instances

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

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

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