במסמך הזה מפורטת ארכיטקטורת עזר שבה אפשר להשתמש כדי לפרוס טופולוגיה של רשתות VPC מקושרות ב Google Cloudבאמצעות רשת חוצת ענן. תכנון הרשת הזה מאפשר פריסה של שירותי תוכנה ברשתות פנימיות Google Cloud וחיצוניות, כמו מרכזי נתונים בארגון או ספקי שירותי ענן (CSPs) אחרים.
קהל היעד של המסמך הזה כולל מנהלי רשתות, אדריכלי ענן ואדריכלים ארגוניים שיבנו את קישוריות הרשת. הוא כולל גם אדריכלי ענן שמתכננים איך לפרוס עומסי עבודה. ההנחה במסמך הזה היא שיש לכם הבנה בסיסית של ניתוב וקישוריות לאינטרנט.
העיצוב הזה תומך בכמה חיבורים חיצוניים, בכמה רשתות של ענן וירטואלי פרטי (VPC) עם גישה לשירותים שמכילות שירותים ונקודות גישה לשירותים, ובכמה רשתות VPC של עומסי עבודה.
במסמך הזה, המונח נקודות גישה לשירותים מתייחס לנקודות גישה לשירותים שזמינים באמצעות Google Cloud גישה לשירותים פרטיים ו-Private Service Connect. NCC הוא מודל של מישור בקרה מסוג Hub-and-Spoke לניהול קישוריות לרשת ב-Google Cloud. משאב ה-Hub מספק ניהול ריכוזי של קישוריות ל-VPC spokes ב-NCC.
מרכז NCC הוא מישור בקרה גלובלי שלומד ומפיץ מסלולים בין הסוגים השונים של רשתות spoke שמחוברות אליו. בדרך כלל, רשתות VPC מסוג Spokes מזריקות נתיבי תת-רשת לטבלת הנתיבים המרכזית של ה-Hub. בדרך כלל, רשתות מסוג Hub-and-Spoke היברידיות מוסיפות מסלולים דינמיים לטבלת המסלולים של ה-Hub המרכזי. באמצעות מידע ממישור הבקרה של מרכז NCC, Google Cloud נוצרת באופן אוטומטי קישוריות של מישור הנתונים בין רכיבי NCC מסוג spoke.
NCC היא הגישה המומלצת לחיבור בין רשתות VPC לצורך צמיחה ניתנת להרחבה ב- Google Cloud. אם אתם חייבים להוסיף מכשירים וירטואליים לרשת (NVAs) לנתיב התעבורה, אתם יכולים להשתמש בפונקציונליות של נתב וירטואלי כדי ליצור מסלולים דינמיים, או להשתמש במסלולים סטטיים או ניתוב על סמך מדיניות יחד עם VPC Network Peering כדי ליצור קישור בין רשתות VPC. מידע נוסף זמין במאמר קישור בין רשתות VPC שכנות (peering) ברשתות שונות בענן.
ארכיטקטורה
הדיאגרמה הבאה מציגה תצוגה כללית של ארכיטקטורת הרשתות ושל זרימות החבילות השונות שהארכיטקטורה הזו תומכת בהן.
הארכיטקטורה מכילה את הרכיבים הבאים ברמה גבוהה:
| רכיב | מטרה | אינטראקציות |
|---|---|---|
| רשתות חיצוניות (רשת מקומית או רשת של ספק שירותי ענן אחר) | מארח את הלקוחות של עומסי עבודה שפועלים ברשתות ה-VPC של עומסי העבודה וברשתות ה-VPC של גישת השירותים. רשתות חיצוניות יכולות גם לארח שירותים. | החלפת נתונים עם רשתות ה-VPC של Google Cloudדרך רשת המעבר. מתחברים לרשת המעבר באמצעות Cloud Interconnect או HA VPN. מפסיק את אחד הקצוות של הרצפים הבאים:
|
| רשת VPC למעבר (נקראת גם רשת VPC לניתוב ב-NCC) | משמש כמרכז לרשת החיצונית, לרשת ה-VPC של גישת השירותים ולרשתות ה-VPC של עומסי העבודה. | חיבור של הרשת החיצונית, רשת ה-VPC של הגישה לשירותים, רשת הצרכן של Private Service Connect ורשתות ה-VPC של עומסי העבודה באמצעות שילוב של Cloud Interconnect, HA VPN ו-NCC. |
| רשת VPC עם גישה לשירותים | התפקיד הזה מספק גישה לשירותים שנדרשים לעומסי עבודה שפועלים ברשתות VPC של עומסי עבודה או ברשתות חיצוניות. השירות גם מספק נקודות גישה לשירותים מנוהלים שמארחים ברשתות אחרות. | העברת נתונים עם רשתות חיצוניות, עומסי עבודה וצרכנים של Private Service Connect דרך רשת המעבר. מתחבר ל-VPC של התנועה באמצעות HA VPN. ניתוב טרנזיטיבי שמוצע על ידי HA VPN מאפשר לתעבורה חיצונית להגיע לרשתות VPC של שירותים מנוהלים דרך רשת ה-VPC של גישת השירותים. מפסיק את אחד הקצוות של הרצפים הבאים:
|
| רשת VPC של שירותים מנוהלים | מארחים שירותים מנוהלים שנדרשים ללקוחות ברשתות אחרות. | הוא מחליף נתונים עם רשתות חיצוניות, רשתות של גישה לשירותים, רשתות של צרכני Private Service Connect ורשתות של עומסי עבודה. מתחבר לרשת ה-VPC של גישה לשירותים באמצעות גישה לשירותים פרטיים, שמשתמשת בקישור בין רשתות VPC שכנות (peering). רשת ה-VPC של השירותים המנוהלים יכולה גם להתחבר לרשת ה-VPC של הצרכן ב-Private Service Connect באמצעות Private Service Connect או גישה לשירותים פרטיים. מפסיק את אחד מקצוות הזרימות מכל הרשתות האחרות. |
| רשת VPC של צרכן Private Service Connect | מארחים נקודות קצה של Private Service Connect שאפשר לגשת אליהן מרשתות אחרות. יכול להיות ש-VPC כזה הוא גם VPC של עומס עבודה. | העברת נתונים עם רשתות ה-VPC החיצוניות ורשתות ה-VPC עם גישה לשירותים דרך רשת ה-VPC למעבר. מתחבר לרשת המעבר ולרשתות VPC אחרות של עומסי עבודה באמצעות מרכזי VPC של NCC. |
| רשתות VPC של עומסי עבודה | מארח עומסי עבודה שנדרשים על ידי לקוחות ברשתות אחרות. הארכיטקטורה הזו מאפשרת להשתמש בכמה רשתות VPC של עומסי עבודה. | העברת נתונים עם רשתות ה-VPC החיצוניות ורשתות ה-VPC עם גישה לשירותים דרך רשת ה-VPC למעבר. מתחבר לרשת התעבורה, לרשתות צרכנים של Private Service Connect ולרשתות VPC אחרות של עומסי עבודה באמצעות מרכזי VPC של NCC. מפסיק את אחד הקצוות של הרצפים הבאים:
|
| NCC | ה-NCC hub כולל מסד נתונים גלובלי של ניתוב, שמשמש כמישור בקרה של רשת עבור נתיבי רשתות משנה של VPC וחיבורים היברידיים בכל Google Cloud אזור. | השירות מחבר בין כמה רשתות VPC ורשתות היברידיות בטופולוגיה של כל-אחד-לכל-אחד, על ידי בניית נתיב נתונים שמשתמש בטבלת הניתוב של מישור הבקרה. |
בתרשים הבא מוצגת תצוגה מפורטת של הארכיטקטורה, שבה מודגשים ארבעת החיבורים בין הרכיבים:
תיאורים של חיבורים
בקטע הזה מתוארים ארבעת החיבורים שמוצגים בתרשים שלמעלה. במסמכי NCC, רשת ה-VPC של התעבורה נקראת רשת ה-VPC של הניתוב. לרשתות האלה יש שמות שונים, אבל הן משרתות את אותה מטרה.
חיבור 1: בין רשתות חיצוניות לבין רשתות VPC למעבר נתונים
החיבור בין הרשתות החיצוניות לרשתות ה-VPC של התנועה עובר דרך Cloud Interconnect או HA VPN. המסלולים מועברים באמצעות BGP בין נתבי Cloud ברשת ה-VPC של העברה ובין נתבים חיצוניים ברשת החיצונית.
- נתבים ברשתות החיצוניות מכריזים על המסלולים של תת-הרשתות החיצוניות ל-Cloud Routers של ה-VPC המעבר. באופן כללי, נתבים חיצוניים במיקום מסוים מכריזים על מסלולים מאותו מיקום חיצוני כעל מסלולים מועדפים יותר מאשר מסלולים למיקומים חיצוניים אחרים. אפשר להגדיר את העדפת המסלולים באמצעות מדדים ומאפיינים של BGP.
- נתבי Cloud Router ברשת ה-VPC של המעבר מפרסמים מסלולים לקידומות ברשתות ה-VPC של Google Cloudלרשתות החיצוניות. צריך להודיע על המסלולים האלה באמצעות הודעות על מסלולים בהתאמה אישית ב-Cloud Router.
- בעזרת NCC אפשר להעביר נתונים בין רשתות מקומיות שונות באמצעות רשת הליבה של Google. כשמגדירים את חיבורי ה-VLAN של ה-interconnect כ-spokes היברידיים של NCC, צריך להפעיל העברת נתונים בין אתרים.
- צירופי VLAN של Cloud Interconnect שמקורם באותם קידומות של רשת חיצונית מוגדרים כרכזת אחת של NCC.
חיבור 2: בין רשתות VPC של מעבר לרשתות VPC של גישה לשירותים
החיבור בין רשתות VPC למעבר נתונים לבין רשתות VPC לגישה לשירותים מתבצע באמצעות HA VPN עם מנהרות נפרדות לכל אזור. המסלולים מוחלפים באמצעות BGP בין נתבי Cloud אזוריים ברשתות VPC של מעבר וברשתות VPC של גישה לשירותים.
- Cloud Routers של HA VPN ב-Transit VPC מכריזים על מסלולים לקידומות של רשתות חיצוניות, רשתות VPC של עומסי עבודה ורשתות VPC אחרות של גישה לשירותים, אל Cloud Router של ה-VPC של הגישה לשירותים. צריך לפרסם את המסלולים האלה באמצעות פרסום מסלולים מותאם אישית ב-Cloud Router.
- רשת ה-VPC של הגישה לשירותים מכריזה על רשתות המשנה שלה ועל רשתות המשנה של כל רשתות ה-VPC של השירותים המנוהלים שמצורפות אליה לרשת ה-VPC של התנועה. צריך להודיע על מסלולים של VPC של שירותים מנוהלים ועל מסלולים של רשתות משנה של VPC לגישה לשירותים באמצעות הודעות מותאמות אישית על מסלולים של Cloud Router.
חיבור 3: בין רשת ה-VPC של התעבורה, רשתות ה-VPC של עומסי העבודה ורשתות ה-VPC של הגישה לשירותים של Private Service Connect
החיבור בין רשת ה-VPC המרכזית, רשתות ה-VPC של עומסי העבודה ורשתות ה-VPC של הצרכנים ב-Private Service Connect מתבצע כשמתבצעת החלפה של רשתות משנה ושל מסלולי קידומת באמצעות NCC. החיבור הזה מאפשר תקשורת בין רשתות ה-VPC של עומסי העבודה, רשתות ה-VPC של גישת השירותים שמחוברות כרשתות מסוג Hub-and-Spoke של NCC, ורשתות אחרות שמחוברות כרשתות מסוג Hub-and-Spoke היברידיות של NCC. הרשתות האחרות האלה כוללות את הרשתות החיצוניות ואת רשתות ה-VPC לגישה לשירותים שמשתמשות בחיבור 1 ובחיבור 2, בהתאמה.
- החיבורים של Cloud Interconnect או HA VPN ברשת ה-VPC של התעבורה משתמשים ב-NCC כדי לייצא מסלולים דינמיים לרשתות ה-VPC של עומס העבודה.
- כשמגדירים את רשת ה-VPC של עומס העבודה כרשת Spoke של רשת ה-Hub ב-NCC, רשת ה-VPC של עומס העבודה מייצאת באופן אוטומטי את רשתות המשנה שלה לרשת ה-VPC של התעבורה. אפשר גם להגדיר את רשת ה-VPC המרכזית כרשת VPC מסוג Spoke. לא מיוצאים נתיבים סטטיים מרשת ה-VPC של עומס העבודה לרשת ה-VPC של המעבר. לא מיוצאים מסלולים סטטיים מרשת ה-VPC של ההעברה לרשת ה-VPC של עומס העבודה.
חיבור 4: רשת VPC של צרכן Private Service Connect עם הפצה של NCC
- נקודות הקצה של Private Service Connect מאורגנות ב-VPC משותף שמאפשר לצרכנים גישה לשירותים מנוהלים של צד ראשון וצד שלישי.
- רשת ה-VPC של הצרכן ב-Private Service Connect מוגדרת כרשת מסוג spoke ב-NCC. ה-spoke הזה מאפשר הפצה של Private Service Connect במרכז של NCC. הפצת Private Service Connect מכריזה על קידומת המארח של נקודת הקצה של Private Service Connect כנתיב לטבלת הניתוב של רכזת NCC.
- רשתות VPC של צרכנים עם גישה לשירותים של Private Service Connect מתחברות לרשתות VPC של עומסי עבודה ולרשתות VPC של מעבר. החיבורים האלה מאפשרים קישוריות טרנזיטיבית לנקודות קצה של Private Service Connect. במרכז ה-NCC צריך להפעיל את הפצת החיבור של Private Service Connect.
- NCC יוצר באופן אוטומטי נתיב נתונים מכל הרכזות אל נקודת הקצה של Private Service Connect.
תנועות תנועה
בתרשים הבא מוצגים התהליכים שמופעלים על ידי ארכיטקטורת ההפניה הזו.
בטבלה הבאה מתוארים התהליכים בתרשים:
| מקור | יעד | תיאור |
|---|---|---|
| רשת חיצונית | רשת VPC עם גישה לשירותים |
|
| רשת VPC עם גישה לשירותים | רשת חיצונית |
|
| רשת חיצונית | רשת VPC של עומס עבודה או רשת VPC של צרכן Private Service Connect |
|
| רשת VPC של עומס עבודה או רשת VPC של צרכן Private Service Connect | רשת חיצונית |
|
| רשת VPC של עומס העבודה | רשת VPC עם גישה לשירותים |
|
| רשת VPC עם גישה לשירותים | רשת VPC של עומס העבודה |
|
| רשת VPC של עומס העבודה | רשת VPC של עומס העבודה | תעבורה שיוצאת מרשת VPC של עומס עבודה אחת עוברת במסלול הספציפי יותר לרשת ה-VPC של עומס העבודה השני דרך NCC. תנועת החזרה הופכת את הנתיב הזה. |
המוצרים שהשתמשו בהם
- ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . VPC כולל קישור בין רשתות VPC שכנות (peering), Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
- Network Connectivity Center: מסגרת תזמור שמפשטת את קישוריות הרשת בין משאבי spoke שמחוברים למשאב ניהול מרכזי שנקרא hub.
- Cloud Interconnect: שירות שמרחיב את הרשת החיצונית שלכם לרשת של Google באמצעות חיבור עם זמינות גבוהה וזמן אחזור קצר.
- Cloud VPN: שירות שמרחיב באופן מאובטח את הרשת השכנה לרשת של Google באמצעות מנהרת IPsec VPN.
- Cloud Router: שירות מבוזר ומנוהל במלואו שמספק יכולות של רמקול ומשיב של פרוטוקול Border Gateway Protocol (BGP). Cloud Router פועל עם Cloud Interconnect, Cloud VPN ומכשירי נתב כדי ליצור מסלולים דינמיים ברשתות VPC על סמך מסלולים שהתקבלו מ-BGP ומסלולים מותאמים אישית שנלמדו.
- Cloud Next Generation Firewall: שירות חומת אש מבוזר באופן מלא עם יכולות הגנה מתקדמות, מיקרו-פילוח וניהול פשוט, שעוזר להגן על עומסי העבודה שלכם ב- Google Cloud מפני התקפות פנימיות וחיצוניות.
שיקולים בתכנון
בקטע הזה מתוארים גורמים שמשפיעים על התכנון, שיטות מומלצות והמלצות לתכנון שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לפתח טופולוגיה שעונה על הדרישות הספציפיות שלכם בנוגע לאבטחה, לאמינות ולביצועים.
אבטחה ותאימות
ברשימה הבאה מתוארים שיקולי האבטחה והתאימות לארכיטקטורת ההפניה הזו:
- מסיבות שקשורות לתאימות, יכול להיות שתרצו לפרוס עומסי עבודה רק באזור אחד. אם רוצים לשמור את כל התנועה באזור יחיד, אפשר להשתמש בטופולוגיה של 99.9%.
- משתמשים ב-Cloud Next Generation Firewall (Cloud NGFW) כדי לאבטח את התעבורה שנכנסת לרשתות ה-VPC של services-access ועומסי העבודה ויוצאת מהן. כדי לבדוק את התנועה שעוברת בין רשתות היברידיות דרך רשת ההעברה או בין רשתות חיצוניות לבין שירותים מנוהלים של Google, צריך להשתמש בחומות אש חיצוניות או בחומות אש של NVA.
- אם אתם צריכים בדיקת תעבורה ברמה 7, אתם יכולים להפעיל את שירות הזיהוי והמניעה של פריצות (אופציונלית עם תמיכה בבדיקת TLS) כדי לחסום פעילות זדונית ולהגן על עומסי העבודה מפני איומים, עם תמיכה בפגיעות, אנטי-ספייוור ואנטי-וירוס. השירות פועל על ידי יצירת נקודות קצה של חומת אש אזורית שמנוהלות על ידי Google. נקודות הקצה האלה משתמשות בטכנולוגיית יירוט מנות כדי לבדוק את עומסי העבודה באופן שקוף, בלי לדרוש שינוי בארכיטקטורת המסלול. ב-Cloud Next Generation Firewall Enterprise יש חיובים על נקודת קצה של חומת אש אזורית ועל עיבוד נתונים.
- אם רוצים להתיר או לחסום תנועה על סמך נתונים של Google Threat Intelligence, צריך להשתמש ב-Google Threat Intelligence. יחולו עליכם חיובים על עיבוד נתונים ב-Cloud Next Generation Firewall Standard.
- מפעילים את הרישום ביומן של כללי חומת האש ומשתמשים בFirewall Insights כדי לבדוק את כללי חומת האש, להבין את ההשפעה שלהם ולשפר אותם. הפעלת הרישום ביומן של ניהול כללי חומת אש עלולה לגרום לעלויות, ולכן כדאי להשתמש בה באופן סלקטיבי.
- כדי לוודא שהתנועה מתנהגת כמו שצריך, מפעילים את בדיקות הקישוריות.
- הפעלת רישום ביומן ומעקב לפי הצורך בהתאם לתנועת הגולשים ולדרישות התאימות. כדי לקבל תובנות לגבי דפוסי התנועה, אפשר להשתמש ב-VPC Flow Logs יחד עם Flow Analyzer.
- כדי לקבל תובנות נוספות לגבי תעבורת הנתונים, אפשר להשתמש ב-Cloud IDS או בשירות למניעת חדירות של Cloud NGFW Enterprise במצב התראה.
אמינות
הרשימה הבאה מתארת את שיקולי המהימנות של ארכיטקטורת ההפניה הזו:
- כדי להשיג זמינות של 99.99% ל-Cloud Interconnect, צריך להתחבר לשני אזורים שונים Google Cloud ממטרופולינים שונים בשני אזורים נפרדים.
- כדי לשפר את האמינות ולצמצם את הסיכון לכשלים אזוריים, אפשר לפזר את עומסי העבודה ומשאבי ענן אחרים בין אזורים שונים.
- כדי לטפל בתנועת הגולשים הצפויה, צריך ליצור מספר מספיק של מנהרות VPN. למנהרות VPN ספציפיות יש מגבלות רוחב פס.
אופטימיזציה של הביצועים
הרשימה הבאה מתארת את שיקולי הביצועים של ארכיטקטורת ההפניה הזו:
- יכול להיות שאפשר לשפר את ביצועי הרשת על ידי הגדלת יחידת השידור המקסימלית (MTU) של הרשתות והחיבורים. מידע נוסף זמין במאמר בנושא יחידת שידור מקסימלית.
- התקשורת בין רשת ה-VPC המרכזית לבין משאבי עומס העבודה מתבצעת באמצעות חיבור NCC. החיבור הזה מספק תפוקה מלאה של קצב העברת נתונים לכל המכונות הווירטואליות ברשת, ללא עלות נוספת. יש כמה אפשרויות לחיבור הרשת החיצונית לרשת המעבר. למידע נוסף על איזון בין שיקולי עלות וביצועים, אפשר לקרוא את המאמר בחירת מוצרים של Network Connectivity.
פריסה
בקטע הזה מוסבר איך לפרוס את הקישוריות בין רשתות VPC של Cross-Cloud Network באמצעות ארכיטקטורת NCC שמתוארת במסמך הזה.
הארכיטקטורה שמתוארת במסמך הזה יוצרת שלושה סוגים של חיבורים ל-VPC מרכזי למעבר נתונים, בנוסף לחיבור בין רשתות VPC של עומסי עבודה. אחרי ש-NCC מוגדר באופן מלא, הוא יוצר תקשורת בין כל הרשתות.
בפריסה הזו מניחים שאתם יוצרים חיבורים בין הרשתות החיצוניות והרשתות המעבריות בשני אזורים, למרות שרשתות המשנה של עומסי העבודה יכולות להיות באזורים אחרים. אם עומסי העבודה ממוקמים באזור אחד בלבד, צריך ליצור רשתות משנה רק באזור הזה.
כדי לפרוס את ארכיטקטורת ההפניה הזו, מבצעים את המשימות הבאות:
- יצירת פילוח רשת באמצעות NCC
- זיהוי אזורים למיקום קישוריות ועומסי עבודה
- יצירת רשתות VPC ורשתות משנה
- יצירת חיבורים בין רשתות חיצוניות לבין רשת ה-VPC המרכזית
- יצירת חיבורים בין רשת ה-VPC המרכזית לבין רשתות ה-VPC עם גישה לשירותים
- יצירת קישוריות בין רשת ה-VPC המרכזית לבין רשתות ה-VPC של עומסי העבודה
- הגדרת מדיניות Cloud NGFW
- בדיקת הקישוריות לעומסי עבודה
יצירת פילוח רשת באמצעות NCC
לפני שיוצרים רכזת NCC בפעם הראשונה, צריך להחליט אם רוצים להשתמש בטופולוגיית רשת מלאה או בטופולוגיית כוכב. ההחלטה אם להשתמש בטופולוגיה של רשתות VPC שמקושרות זו לזו באופן מלא או בטופולוגיה של רשתות VPC שמקושרות זו לזו בצורת כוכב היא בלתי הפיכה. כדי לקבל את ההחלטה הבלתי הפיכה הזו, אפשר להיעזר בהנחיות הכלליות הבאות:
- אם הארכיטקטורה העסקית של הארגון מאפשרת תעבורה בין כל רשתות ה-VPC, כדאי להשתמש ב-NCC mesh.
- אם התנועה בין מרכזי VPC מסוימים לא מורשית, אבל מרכזי ה-VPC האלה יכולים להתחבר לקבוצת ליבה של מרכזי VPC, צריך להשתמש בטופולוגיית כוכב של NCC.
זיהוי אזורים למיקום של קישוריות ועומסי עבודה
באופן כללי, מומלץ למקם את הקישוריות ואת Google Cloud עומסי העבודה קרוב לרשתות המקומיות או ללקוחות ענן אחרים. מידע נוסף על מיקום עומסי עבודה זמין במאמרים Google Cloud Region Picker ושיטות מומלצות לבחירת אזורים ב-Compute Engine.
יצירת רשתות VPC ורשתות משנה
כדי ליצור את רשתות ה-VPC ואת רשתות המשנה, צריך לבצע את המשימות הבאות:
יוצרים או מזהים את הפרויקטים שבהם ייצרו את רשתות ה-VPC. הנחיות מפורטות זמינות במאמר פילוח לפי רשתות ומבנה הפרויקט. אם אתם מתכוונים להשתמש ברשתות VPC משותף, הקצו את הפרויקטים שלכם כפרויקטים מארחים של VPC משותף.
תכננו את הקצאות כתובות ה-IP לרשתות שלכם. אתם יכולים להקצות מראש ולשריין את הטווחים על ידי יצירת טווחים פנימיים. כך קל יותר לבצע הגדרות ופעולות בהמשך.
יוצרים רשת VPC למעבר נתונים עם ניתוב גלובלי מופעל.
יצירת רשתות VPC עם גישה לשירותים. אם אתם מתכננים להפעיל עומסי עבודה בכמה אזורים, כדאי להפעיל ניתוב גלובלי.
יוצרים רשתות VPC של עומסי עבודה. אם יהיו לכם עומסי עבודה בכמה אזורים, תצטרכו להפעיל ניתוב גלובלי.
יצירת חיבורים בין רשתות חיצוניות לבין רשת ה-VPC המרכזית
בקטע הזה מניחים שיש קישוריות בשני אזורים, ושהמיקומים החיצוניים מחוברים ויכולים לבצע מעבר לגיבוי הדדי. בנוסף, המערכת מניחה שיש העדפה ללקוחות במיקום חיצוני לגשת לשירותים באזור שבו המיקום החיצוני נמצא.
- הגדרת הקישוריות בין רשתות חיצוניות לרשת המעבר. מידע נוסף מופיע במאמר בנושא קישוריות חיצונית והיברידית. לקבלת הנחיות לבחירת מוצר קישוריות, אפשר לעיין במאמר בחירת מוצר של Network Connectivity.
מגדירים BGP בכל אזור מחובר באופן הבא:
- מגדירים את הנתב במיקום החיצוני שצוין באופן הבא:
- מפרסמים את כל רשתות המשנה של המיקום החיצוני באמצעות אותו BGP MED בשני הממשקים, למשל 100. אם שני הממשקים מכריזים על אותה עדיפות MED, Google Cloud יכול להשתמש ב-ECMP כדי לבצע איזון עומסים של התנועה בשני החיבורים.
- מפרסמים את כל רשתות המשנה מהמיקום החיצוני השני באמצעות ערך MED בעדיפות נמוכה יותר מזה של האזור הראשון, למשל 200. לפרסם את אותו ערך MED משני הממשקים.
- מגדירים את Cloud Router שפונה החוצה ב-VPC המעבר של האזור המחובר באופן הבא:
- הגדרת Cloud Router עם מספר מערכת אוטונומית (ASN) פרטי.
- כדאי להשתמש בפרסום של מסלולים בהתאמה אישית כדי להודיע על כל טווחי רשתות המשנה מכל האזורים בכל הממשקים של Cloud Router שפונים החוצה. אם אפשר, כדאי לצבור אותם. משתמשים באותו ערך MED בשני הממשקים, למשל 100.
- מגדירים את הנתב במיקום החיצוני שצוין באופן הבא:
עבודה עם רכזת NCC ועם רשתות היברידיות מסוג Spoke, שימוש בפרמטרים שמוגדרים כברירת מחדל.
- ליצור מרכז NCC. אם הארגון שלכם מאפשר תנועה בין כל רשתות ה-VPC, צריך להשתמש בהגדרת ברירת המחדל של רשת מלאה.
- אם אתם משתמשים ב-Partner Interconnect, ב-Dedicated Interconnect, ב-HA-VPN או ב-Router appliance כדי להגיע לקידומות מקומיות, אתם צריכים להגדיר את הרכיבים האלה כרכזות היברידיות שונות של NCC.
- כדי להודיע על תת-הרשתות של טבלת הניתוב של מרכז ה-NCC לשכנים מרוחקים של BGP, צריך להגדיר מסנן שיכלול את כל טווחי כתובות ה-IPv4.
- אם הקישוריות ההיברידית מסתיימת ב-Cloud Router באזור שתומך בהעברת נתונים, צריך להגדיר את ה-spoke ההיברידי עם העברת נתונים מאתר לאתר. הפעולה הזו תומכת בהעברת נתונים מאתר לאתר באמצעות רשת הליבה של Google.
יצירת חיבורים בין רשת ה-VPC המרכזית לבין רשתות VPC עם גישה לשירותים
כדי לספק ניתוב טרנזיטיבי בין רשתות חיצוניות לבין ה-VPC של הגישה לשירותים, ובין ה-VPC של עומסי העבודה לבין ה-VPC של הגישה לשירותים, ה-VPC של הגישה לשירותים משתמש ב-HA VPN לקישוריות.
- הערכה של נפח התעבורה שצריך לעבור בין רשתות ה-VPC של התחבורה הציבורית ושל הגישה לשירותים בכל אזור. צריך לשנות את המספר הצפוי של המנהרות בהתאם.
מגדירים HA VPN בין רשת ה-VPC של התנועה העוברת לבין רשת ה-VPC של גישת השירותים באזור א' באמצעות ההוראות במאמר יצירת שערי HA VPN לחיבור רשתות VPC. יוצרים Cloud Router ייעודי של HA VPN ברשת ה-VPC של התעבורה. להשאיר את הנתב שפונה לרשת החיצונית לחיבורים לרשת חיצונית.
- הגדרת Cloud Router ב-Transit VPC:
- כדי להודיע על רשתות משנה של VPC של עומסי עבודה ורשתות חיצוניות ל-VPC של גישה לשירותים, משתמשים בפרסום מסלולים בהתאמה אישית ב-Cloud Router ב-VPC המעבר.
- הגדרת Cloud Router ב-VPC של גישה לשירותים:
- כדי לפרסם תת-רשתות של רשת VPC עם גישה לשירותים ב-VPC המרכזי, משתמשים בפרסום מסלולים בהתאמה אישית ב-Cloud Router של רשת ה-VPC עם גישה לשירותים.
- אם אתם משתמשים בגישה לשירותים פרטיים כדי לחבר רשת VPC של שירותים מנוהלים ל-VPC של גישה לשירותים, אתם צריכים להשתמש במסלולים מותאמים אישית כדי להודיע גם על תת-הרשתות האלה.
- בצד של ה-VPC המרכזי של מנהרת ה-HA VPN, מגדירים את צמד המנהרות כ-Spoke היברידי של NCC:
- כדי לתמוך בהעברת נתונים בין אזורים, צריך להגדיר את ה-spoke ההיברידי עם העברת נתונים מאתר לאתר.
- כדי להודיע על תת-הרשתות של טבלת הניתוב של מרכז NCC לשכני BGP מרוחקים, מגדירים מסנן שיכלול את כל טווחי כתובות ה-IPv4. הפעולה הזו מכריזה על כל מסלולי המשנה של IPv4
לשכנים.
- כדי להתקין מסלולים דינמיים כשהקיבולת מוגבלת בנתב החיצוני, צריך להגדיר את Cloud Router כך שיפרסם מסלול סיכום עם פרסום מסלול בהתאמה אישית. עדיף להשתמש בגישה הזו במקום להודיע על טבלת הניתוב המלאה של מרכז ה-NCC.
- הגדרת Cloud Router ב-Transit VPC:
אם מחברים VPC של שירותים מנוהלים ל-VPC של גישה לשירותים באמצעות גישה פרטית לשירותים אחרי שנוצר חיבור של קישור בין רשתות VPC שכנות (peering), צריך גם לעדכן את הצד של ה-VPC של גישה לשירותים בחיבור של הקישור בין רשתות VPC שכנות כדי לייצא מסלולים מותאמים אישית.
יצירת קישוריות בין רשת ה-VPC המרכזית לבין רשתות ה-VPC של עומסי העבודה
כדי ליצור קישוריות בין רשתות VPC בהיקף גדול, משתמשים ב-NCC עם רשתות VPC מסוג Hub and Spoke. NCC תומך בשני סוגים שונים של מודלים של מישור הנתונים – מודל מישור הנתונים של רשת מלאה או מודל מישור הנתונים של טופולוגיית כוכב.
- אם אפשר לאפשר לכל הרשתות לתקשר ביניהן, צריך ליצור קישוריות מלאה.
- אם הארכיטקטורה העסקית שלכם דורשת טופולוגיה של נקודה לכמה נקודות, צריך להגדיר קישוריות של טופולוגיית כוכב.
יצירת קישוריות מלאה בין כל המכשירים
המרכזים של ה-NCC כוללים את רשתות ה-VPC של התנועה, את רשתות ה-VPC של הצרכנים ב-Private Service Connect ואת כל רשתות ה-VPC של עומסי העבודה.
- למרות ש-NCC יוצרת רשת משולבת מלאה של רשתות VPC מסוג Hub and Spoke, מפעילי הרשת חייבים לאפשר זרימת תנועה בין רשתות המקור לרשתות היעד באמצעות כללי חומת אש או מדיניות חומת אש.
- מגדירים את כל עומסי העבודה, את התנועה ואת רשתות ה-VPC של הצרכנים ב-Private Service Connect כרשתות משנה של VPC ב-NCC. לא יכול להיות חפיפה בין רשתות משנה ברשתות VPC מסוג Hub and Spoke.
- כשמגדירים את ה-spoke של ה-VPC, צריך להודיע על טווחי כתובות IP של רשתות משנה שלא חופפים לטבלת הניתוב של ה-hub של NCC:
- כולל טווחי תת-רשת לייצוא.
- החרגת טווחי תת-רשת לייצוא.
- כשמגדירים את ה-spoke של ה-VPC, צריך להודיע על טווחי כתובות IP של רשתות משנה שלא חופפים לטבלת הניתוב של ה-hub של NCC:
- אם רשתות ה-VPC מסוג Spoke נמצאות בפרויקטים שונים ומנהלים אותן אדמינים שאינם אדמינים של ה-Hub ב-NCC, האדמינים של רשתות ה-VPC מסוג Spoke צריכים לשלוח בקשה להצטרפות ל-Hub ב-NCC בפרויקטים האחרים.
- משתמשים בהרשאות של ניהול הזהויות והרשאות הגישה (IAM) בפרויקט ה-NCC hub כדי להקצות למשתמש את התפקיד
roles/networkconnectivity.groupUser.
- משתמשים בהרשאות של ניהול הזהויות והרשאות הגישה (IAM) בפרויקט ה-NCC hub כדי להקצות למשתמש את התפקיד
- כדי לאפשר גישה לשירותים פרטיים באופן טרנזיטיבי וגלובלי מ-spokes אחרים ב-NCC, צריך להפעיל את ההפצה של חיבורי Private Service Connect במרכז ה-NCC.
אם לא מאפשרים תקשורת מלאה בין רשתות VPC של עומסי עבודה, כדאי להשתמש בטופולוגיה של NCC star.
יצירת קישוריות בטופולוגיית כוכב
בארכיטקטורות עסקיות מרכזיות שדורשות טופולוגיה של נקודה לכמה נקודות, אפשר להשתמש בטופולוגיית כוכב של NCC.
כדי להשתמש בטופולוגיית כוכב של NCC, צריך לבצע את המשימות הבאות:
- ב-NCC, יוצרים רכזת NCC ומציינים טופולוגיה של כוכב.
- כדי לאפשר גישה פרטית לחיבורים לשירותים באופן טרנזיטיבי וגלובלי מ-spokes אחרים של NCC, צריך להפעיל את ההפצה של חיבורי Private Service Connect ב-hub של NCC.
- כשמגדירים את מרכז ה-NCC לטופולוגיית כוכב, אפשר לקבץ רשתות VPC באחת משתי קבוצות שנקבעו מראש: קבוצות מרכזיות או קבוצות קצה.
כדי לקבץ רשתות VPC בקבוצה המרכזית, צריך להגדיר את רשת ה-VPC המעבר ואת רשתות ה-VPC של צרכן Private Service Connect כרשתות VPC משניות של NCC כחלק מהקבוצה המרכזית.
NCC יוצרת רשת עם קישוריות מלאה בין רשתות VPC מסוג Hub and Spoke שנמצאות בקבוצה המרכזית.
כדי לקבץ רשתות VPC של עומסי עבודה בקבוצת הקצה, צריך להגדיר כל אחת מהרשתות האלה כרשתות Spoke של NCC VPC בתוך הקבוצה.
NCC יוצר נתיב נתונים מנקודה לנקודה מכל רשת VPC מסוג spoke ב-NCC לכל רשתות ה-VPC בקבוצה המרכזית.
הגדרת כללי מדיניות של Cloud NGFW
בנוסף להנחיות שבקטע אבטחה ותאימות, כדאי לעיין בשיטות מומלצות לכללי חומת אש.
עוד דברים שכדאי לבדוק:
- אם עומסי העבודה שלכם פועלים במכונות וירטואליות של Compute Engine, מומלץ להשתמש במדיניות של חומת אש ברשת במקום בכללים של חומת אש ב-VPC. לכללי מדיניות של חומת אש ברשת יש יתרונות כמו אבטחה מפורטת ובקרת גישה באמצעות תגים, ניהול פשוט של כללים, קלות התפעול, מערך תכונות עשיר וגמישות במיקום אחסון הנתונים. אם כבר יש לכם כללים לחומת אש ב-VPC, אתם יכולים להשתמש בכלי להעברת כללים לחומת אש ב-VPC כדי לעבור למדיניות גלובלית של חומת אש ברשת.
- מערכת Google Kubernetes Engine יוצרת ומנהלת באופן אוטומטי כללי חומת אש מסוימים של VPC כדי לאפשר תנועה חיונית, ולכן מומלץ לא לשנות או למחוק את הכללים האלה. עם זאת, אפשר להשתמש במדיניות חומת אש ברשת יחד עם כללי חומת אש ב-VPC, ואפשר גם לשנות את סדר האכיפה של המדיניות.
- מומלץ להשתמש בתגים במקום בתגי רשת עם כללי חומת אש בגלל אמצעי הבקרה של IAM, השיפורים בהתאמת הגודל והתמיכה במדיניות של חומת אש ברשת. עם זאת, אין תמיכה בתגים במדיניות חומת אש היררכית או ברשתות שנוצרו באמצעות Network Connectivity Center, ולכן במקרים כאלה צריך ליצור כללים שמבוססים על טווחי CIDR.
- אם רוצים להפעיל בדיקה ברמה 7 ב-Cloud NGFW, צריך להגדיר את שירות מניעת הפריצות, כולל פרופילי אבטחה, נקודת קצה של חומת אש ושיוך ל-VPC.
- יוצרים מדיניות חומת אש בין רשתות גלובלית וכללים נדרשים לחומת האש. צריך לקחת בחשבון את הכללים המשתמעים הקיימים שמאפשרים תעבורת נתונים יוצאת ומונעים תעבורת נתונים נכנסת בכל רשת VPC.
- משייכים את המדיניות לרשתות ה-VPC.
- אם אתם כבר משתמשים בכללי חומת אש של VPC ברשתות שלכם, יכול להיות שתרצו לשנות את סדר ההערכה של המדיניות והכללים כדי שהכללים החדשים שלכם יוערכו לפני כללי חומת האש של VPC.
- אופציונלי: מפעילים ניהול כללי חומת אש.
בדיקת הקישוריות לעומסי עבודה
אם יש לכם עומסי עבודה שכבר נפרסו ברשתות ה-VPC, כדאי לבדוק עכשיו את הגישה אליהם. אם קישרתם את הרשתות לפני פריסת עומסי העבודה, אתם יכולים לפרוס את עומסי העבודה עכשיו ולבדוק.
המאמרים הבאים
- מידע נוסף על Google Cloud המוצרים שבהם נעשה שימוש במדריך העיצוב הזה:
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- אריק יו (Eric Yu) | מהנדס לקוחות מומחה לרשתות
- Deepak Michael | Networking Specialist Customer Engineer
- Victor Moreno | Product Manager, Cloud Networking
- Osvaldo Costa | Networking Specialist Customer Engineer
תורמי תוכן אחרים:
- מארק שלגנהוף | כותב טכני, רשתות
- אמט וויליאמס | מהנדס קשרי מפתחים
- Ghaleb Al-habian | Network Specialist
- טוני סארתצ'נדרה | מנהל מוצר בכיר