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

  • כתובות 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. האדמין של פרויקט השירות צריך לבחור אזור עבור המופע, כי זה האזור שמכיל את 10.0.1.0/24 subnet.us-west1 ‫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 משותף יכול להקצות משימות ניהול רשת לאדמינים של רשתות ואבטחה.

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