סקירה כללית על רשתות ב-Dataproc Metastore

במסמך הזה מובא סקירה כללית של הגדרות הרשת שאפשר להשתמש בהן כדי להגדיר שירות Dataproc Metastore.

.

הסבר מהיר על נושאים שקשורים לרשת

הגדרות רשת הערות
הגדרות הרשת שמוגדרות כברירת מחדל
VPC subnetworks כברירת מחדל, שירותי Dataproc Metastore שמשתמשים בפרוטוקול נקודת הקצה של Thrift משתמשים ברשת משנה של VPC עם Private Service Connect.
רשתות של ענן וירטואלי פרטי (VPC) אפשר גם לבחור להשתמש ברשתות VPC לשירותי Dataproc Metastore שמשתמשים בפרוטוקול נקודת הקצה של Thrift. זוהי חלופה לשימוש בתת-רשתות של VPC עם Private Service Connect.

אחרי שרשת ה-VPC נוצרת, Dataproc Metastore גם מגדיר אוטומטית קישור בין רשתות VPC שכנות בשביל השירות.
הגדרות רשת נוספות
רשתות VPC משותפות אפשר גם ליצור שירותי Dataproc Metastore ברשת VPC משותפת.
רשתות מקומיות אפשר להתחבר לשירות Dataproc Metastore באמצעות Cloud VPN או Cloud Interconnect בסביבה מקומית.
VPC Service Controls אפשר גם ליצור שירותי Dataproc Metastore עם VPC Service Controls.
כללי חומת אש בסביבות פרטיות או בסביבות שאינן ברירת המחדל עם טביעת רגל אבטחתית מבוססת, יכול להיות שתצטרכו ליצור כללים משלכם לחומת האש.

הגדרות ברירת מחדל של רשתות

בקטע הבא מתוארות הגדרות הרשת שמוגדרות כברירת מחדל ב-Dataproc Metastore עבור פרוטוקול נקודת הקצה של Thrift – רשתות משנה של VPC עם Private Service Connect.

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

‫Private Service Connect ‏ (PSC) היא אפשרות ברירת המחדל לחיבור לרשת בשירותי Dataproc Metastore שמשתמשים בפרוטוקול של נקודת הקצה Thrift. ‫PSC מאפשר לכם להגדיר חיבור פרטי למטא-נתונים של Dataproc Metastore ברשתות VPC. בעזרת PSC, אפשר ליצור שירות בלי VPC peering. כך תוכלו להשתמש בכתובות IP פנימיות משלכם כדי לגשת ל-Dataproc Metastore, בלי לצאת מרשתות ה-VPC או להשתמש בכתובות IP חיצוניות.

כדי להגדיר Private Service Connect כשיוצרים שירות, אפשר לעיין במאמר בנושא Private Service Connect עם Dataproc Metastore.

רשתות VPC

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

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

‫Dataproc Metastore דורש את ההרשאות הבאות לכל אזור עבור כל רשת VPC:

קישור בין רשתות VPC שכנות (peering)

אחרי שרשת ה-VPC נוצרת, Dataproc Metastore גם מגדיר אוטומטית קישור בין רשתות VPC שכנות בשביל השירות. ‫VPC מספק לשירות שלכם גישה לפרוטוקולי נקודות הקצה של Dataproc Metastore. אחרי שיוצרים את השירות, אפשר לראות את הקישור בין רשתות ה-VPC שכנות (peering) שמתחתיו בדף VPC Network Peering במסוף Google Cloud.

קישור בין רשתות VPC שכנות (peering) הוא לא טרנזיטיבי. כלומר, רק רשתות שכנות שיש ביניהן קישור ישיר (direct peering) יכולות לתקשר ביניהן. לדוגמה, נניח את התרחיש הבא:

יש לכם את הרשתות הבאות: רשת VPC ששמה N1, רשת VPC ששמה N2 ורשת VPC ששמה N3.

  • רשת ה-VPC ששמה N1 מקושרת לרשתות השכנות N2 ו-N3.
  • רשתות ה-VPC ששמותיהן N2 ו-N3 לא מקושרות בקישור ישיר.

מה זה אומר?

כלומר, רשת ה-VPC ששמה N2 לא יכולה לתקשר עם רשת ה-VPC ששמה N3 באמצעות קישור בין רשתות VPC שכנות. השינוי הזה משפיע על החיבורים ל-Dataproc Metastore בדרכים הבאות:

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

שיקולי אבטחה בנושא קישור בין רשתות VPC שכנות (peering)

  • תעבורת הנתונים בקישור בין רשתות VPC שכנות (peering) מוצפנת ברמה מסוימת. למידע נוסף, ראו Google Cloud הצפנה ואימות של רשת וירטואלית.

  • יצירת רשת VPC אחת לכל שירות עם כתובת IP פנימית מספקת בידוד טוב יותר של הרשת מאשר הצבת כל השירותים ברשת ה-VPC‏ default.

כתובות IP

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

כשמשתמשים בכתובת IP פנימית, Dataproc Metastore יכול להתחבר רק למכונות וירטואליות (VM) שקיימות ברשתות VPC שצוינו או בסביבה מקומית.

חיבורים לשירות Dataproc Metastore באמצעות כתובת IP פנימית משתמשים בטווח כתובות RFC 1918. השימוש בטווחים האלה אומר שהחיבורים לשירות Dataproc Metastore באמצעות כתובת IP פנימית משתמשים בטווחים של כתובות RFC 1918. השימוש בטווחים האלה אומר ש-Dataproc Metastore מקצה טווח של /17 וטווח של /20 ממרחב הכתובות לכל אזור. לדוגמה, אם רוצים למקם שירותי Dataproc Metastore בשני אזורים, טווח כתובות ה-IP שהוקצה צריך לכלול את הנתונים הבאים:

  • לפחות שני בלוקים של כתובות לא בשימוש בגודל /17.
  • לפחות שני בלוקים של כתובות לא בשימוש בגודל /20.

אם לא נמצאים בלוקים של כתובות RFC 1918, ‏ Dataproc Metastore מוצא בלוקים מתאימים של כתובות שאינן RFC 1918 במקום זאת. שימו לב שההקצאה של בלוקים שאינם RFC 1918 לא מתחשבת בשאלה אם הכתובות האלה נמצאות בשימוש ברשת ה-VPC או בפריסה המקומית.

הגדרות נוספות של רשת

אם אתם צריכים הגדרת רשת שונה, אתם יכולים להשתמש באפשרויות הבאות עם שירות Dataproc Metastore.

רשת VPC משותפת

אפשר ליצור שירותי Dataproc Metastore ב רשת VPC משותפת. VPC משותף מאפשר לכם לחבר משאבי Dataproc Metastore מכמה פרויקטים לרשת VPC משותפת.

כדי להגדיר VPC משותף כשיוצרים שירות, ראו יצירת שירות Dataproc Metastore.

רישות מקומי

אתם יכולים להתחבר לשירות Dataproc Metastore עם סביבה מקומית באמצעות Cloud VPN או Cloud Interconnect

VPC Service Controls

VPC Service Controls משפר את היכולת לצמצם את הסיכון לזליגת נתונים. בעזרת VPC Service Controls, אתם יוצרים גבולות גזרה מסביב לשירות Dataproc Metastore. VPC Service Controls מגביל את הגישה למשאבים בתוך גבולות גזרה מבחוץ. רק לקוחות ומשאבים בתוך גבולות הגזרה יכולים ליצור אינטראקציה זה עם זה.

כדי להשתמש ב-VPC Service Controls עם Dataproc Metastore, אפשר לעיין במאמר בנושא VPC Service Controls עם Dataproc Metastore. כדאי גם לעיין ב מגבלות של Dataproc Metastore כשמשתמשים ב-VPC Service Controls.

כללי חומת אש ל-Dataproc Metastore

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

כשיוצרים שירות Dataproc Metastore, אפשר לאשר את רשת ברירת המחדל של השירות. רשת ברירת המחדל מבטיחה גישה מלאה לרשתות IP פנימיות למכונות הווירטואליות שלכם.

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

יצירת כלל לחומת האש עבור רשת בהתאמה אישית

כשמשתמשים ברשת בהתאמה אישית, צריך לוודא שכלל חומת האש מאפשר תעבורת נתונים שמגיעה מנקודת הקצה של Dataproc Metastore ושיוצאת ממנה. כדי לאפשר במפורש תנועה של Dataproc Metastore, מריצים את הפקודות הבאות:gcloud

gcloud compute firewall-rules create dpms-allow-egress-DPMS_NETWORK-REGION --allow tcp --destination-ranges DPMS_NET_PREFIX/17 --network DPMS_NETWORK --direction OUT

gcloud compute firewall-rules create dpms-allow-ingress-DPMS_NETWORK-REGION --allow tcp,udp --source-ranges DPMS_NET_PREFIX/17 --network DPMS_NETWORK

בשביל DPMS_NET_PREFIX, צריך להחיל מסכה של רשת משנה /17 על כתובת ה-IP של שירות Dataproc Metastore. אפשר למצוא את פרטי כתובת ה-IP של Dataproc Metastore בהגדרה endpointUri בדף פרטי השירות.

לתשומת ליבכם

לרשתות יש כלל תעבורת נתונים יוצאת (egress) שמוגדר כברירת מחדל, שבדרך כלל מאפשר גישה מהרשת שלכם ל-Dataproc Metastore. אם יוצרים כללי דחייה של תעבורת יציאה שמבטלים את כלל ההרשאה המשתמע של תעבורת יציאה, צריך ליצור כלל הרשאה של תעבורת יציאה עם עדיפות גבוהה יותר כדי לאפשר תעבורת יציאה לכתובת ה-IP של Dataproc Metastore.

חלק מהתכונות, כמו Kerberos, דורשות ש-Dataproc Metastore יפעיל חיבורים למארחים ברשת הפרויקט. לכל הרשתות יש כלל ברירת מחדל של דחיית תעבורה נכנסת שחוסם את החיבורים האלה ומונע את הפעלת התכונות האלה. כלל ברירת מחדל של דחיית תעבורה נכנסת שחוסם את החיבורים האלה ומונע את הפעלת התכונות האלה. צריך ליצור כלל חומת אש שמאפשר תעבורת נתונים נכנסת (ingress) מסוג TCP ו-UDP בכל היציאות מבלוק כתובות ה-IP‏ /17 שמכיל את כתובת ה-IP של Dataproc Metastore.

ניתוב בהתאמה אישית

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

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

מידע נוסף על ניתוב בהתאמה אישית זמין במאמר בנושא הגדרת רשת.

דוגמה לרשת Dataproc Metastore

בדוגמה הבאה, Google מקצה את טווחי הכתובות 10.100.0.0/17 ו-10.200.0.0/20 ברשת ה-VPC של הלקוח לשירותי Google, ומשתמשת בטווחי הכתובות ברשת VPC מקושרת.

INSERT ALT TEXT HERE
איור 1. הגדרת רשת VPC של Dataproc Metastore
alt = "Diagram showing Dataproc Metastore VPC network configuration with Google services and customer VPC network, illustrating IP address allocation and peering.">
איור 1. הגדרת רשת VPC ב-Dataproc Metastore

תיאור של דוגמה לרשת:

  • בצד של שירותי Google בקישור בין רשתות שכנות (peering) של ה-VPC, ‏ Google יוצרת פרויקט בשביל הלקוח. הפרויקט מבודד, כלומר אין לקוחות אחרים שמשתפים אותו, והלקוח מחויב רק על המשאבים שהוא מקצה.
  • כשיוצרים את שירות Dataproc Metastore הראשון באזור מסוים, המערכת מקצה טווח /17 וטווח /20 ברשת של הלקוח לכל השימוש העתידי בשירותי Dataproc Metastore באותו אזור וברשת. ‫Dataproc Metastore מחלק עוד יותר את הטווחים האלה כדי ליצור תת-רשתות וטווחים של כתובות בפרויקט לשירות מנוהל.
  • שירותי מכונות וירטואליות ברשת של הלקוח יכולים לגשת למשאבי שירות של Dataproc Metastore בכל אזור אםGoogle Cloud השירות תומך בכך. יכול להיות שחלק Google Cloud מהשירותים לא יתמכו בתקשורת בין אזורים.
  • עלויות יציאה לתנועה חוצת-אזורים, שבה מופע של מכונה וירטואלית מתקשר עם משאבים באזור אחר, עדיין חלות.
  • ‫Google מקצה לשירות Dataproc Metastore את כתובת ה-IP‏ 10.100.0.100. ברשת ה-VPC של הלקוח, בקשות עם יעד 10.100.0.100 מנותבות דרך הקישור בין רשתות שכנות (peering) לרשת של בעלים של שירות מנוהל. אחרי שהבקשה מגיעה לרשת השירות, רשת השירות מכילה מסלולים שמפנים את הבקשה למשאב הנכון.
  • תעבורת הנתונים בין רשתות VPC עוברת באופן פנימי ברשת של Google, ולא דרך האינטרנט הציבורי.

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