סקירה כללית על שער NCC

שער NCC הוא מסוג spoke שאפשר לצרף ל-hub של Network Connectivity Center (NCC). זהו מוצר אזורי שמאפשר אבטחה של תנועת נתונים ב-Cross-Cloud Network. שער NCC מאפשר להפעיל פונקציות אבטחה כמו Security Service Edge ‏ (SSE) של צד שלישי, רכיב אבטחה שמסופק בענן של Secure Access Service Edge ‏ (SASE). רשתות ה-spoke של NCC Gateway תומכות בקישוריות ישירה ל-VLAN attachments של Cloud Interconnect.

שער NCC כולל את התכונות הבאות:

  • שילוב יעיל של SSE: אפשר לשלב SSE, כמו Palo Alto Networks Prisma Access ו-Symantec Cloud Secure Web Gateway (גרסת Preview) בצורה חלקה עם ניתוב שקוף כדי לשפר את ההגנה על המשתמשים והביצועים של האפליקציה. שער NCC מאפשר להפעיל פונקציות אבטחה לתנועה בין עננים.
  • זמינות גבוהה: אפשר להשתמש ב-NCC Gateway כדי לקבל הסכם רמת שירות (SLA) עם זמן פעולה תקינה של 99.9% ולמזער שיבושים.
  • פריסה אזורית: אתם יכולים לפרוס את NCC Gateway במגוון אזורים בהתאם לקרבה הפיזית למרכזי נתונים, לספקי SSE של צד שלישי או לספקי ענן אחרים שבהם נמצאים האפליקציות שלכם.
  • אבטחת כוח עבודה מרוחק: אתם יכולים לחבר בצורה מאובטחת כוח עבודה מרוחק – כמו עובדים בסניפים, במרכזי נתונים ובמשרדים מרוחקים – לאפליקציות פרטיות ב- Google Cloud, בפריסה מקומית או אצל ספקי ענן אחרים, ולאפליקציות ציבוריות.

יתרונות

היתרונות של NCC Gateway:

  • חוויית שימוש אופטימלית באפליקציה עם השהיה מופחתת: שימוש ברוחב פס גבוה בשירות SSE בגישת עדיפות לענן עם NCC Gateway וביצועים משופרים באמצעות רשת הליבה הפרטית של Google.

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

  • ניהול פשוט יותר דרך NCC.

מונחי מפתח

כדי להבין את NCC Gateway, כדאי להכיר את המונחים הבאים:

צירוף היברידי: צירופים ל-VLAN שמשויכים ל-NCC Gateway.

פונקציית שירות אבטחה: שירותים שמצורפים ל-NCC Gateway. לדוגמה, כדי להגן על תקשורת בין משתמש לאפליקציה, צריך לצרף שירות SSE ל-NCC Gateway.

רשת של ענן וירטואלי פרטי (VPC) של אפליקציה או עומס עבודה: רשת VPC של עומס עבודה היא בדרך כלל רשת שמשתמשת במכונה וירטואלית (VM) של Compute Engine או בקונטיינרים של Google Kubernetes Engine ‏ (GKE) כעומסי עבודה. רשתות VPC של עומסי עבודה יכולות להיות רשתות VPC רגילות או רשתות VPC משותפות עם פרויקט מארח וכמה פרויקטים של שירותים. צריך להגדיר את רשתות ה-VPC של עומסי העבודה כרשתות משנה (spokes) ברשת המרכזית.

קבוצות של רשתות מסוג Spoke: דרך לקבץ רשתות מסוג Spoke בתוך רכזת NCC. קבוצות של רכזות מאפשרות להפריד בין הרכזות לדומיינים שונים של ניתוב. קבוצת מרכזים יכולה להכיל כמה מרכזים, אבל מרכז יכול להשתייך רק לקבוצה אחת. למידע מפורט על קבוצות של רשתות משנה מסוג Hub and Spoke לטופולוגיות שונות, אפשר לעיין במאמר בנושא טופולוגיות מוגדרות מראש של קישוריות.

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

‫Secure Access Connect: מאפשר לכם לחבר מוצרי SSE של צד שלישי ל-NCC Gateway לעיבוד אבטחה ולגישה מאובטחת לאינטרנט. מידע על Secure Access Connect זמין במאמר סקירה כללית על Secure Access Connect.

מוצרי SSE נתמכים

שער NCC תומך בחיבורים למוצרי SSE הבאים:

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

שער NCC הוא פתרון אידיאלי לארגונים שרוצים לאבטח את הגישה של עובדים היברידיים לאפליקציות. ‫NCC Gateway מספק אבטחה לכוח עבודה היברידי באמצעות מערכת אקולוגית משולבת של שותפים, כדי לאפשר לכם להתחבר לספקי SSE לפי בחירתכם. הגישה הזו מתאימה לפריסות חדשות (greenfield) וקיימות (brownfield) של NCC.

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

תרחישי שימוש Google Cloud למשתמשים כוללים תמיכה במצבי החיבור הבאים:

  • הפניית משתמשים לאינטרנט
  • הפניית משתמשים בארגון לאפליקציות פרטיות
  • אפליקציות פרטיות לאינטרנט

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

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

תנועות תנועה

בקטע הזה מתוארים נתיבי זרימת התנועה ב-NCC Gateway בהתאם לכל תרחיש שימוש.

תנועת הנתונים בתרחישי השימוש של משתמשי Google Cloud

הפניית משתמשים לאינטרנט

בתרשים הבא, תנועת הגולשים זורמת ממשתמש בסניף מקומי דרך שער NCC ומערך SSE של צד שלישי אל האינטרנט.

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

הפניית משתמשים בארגון לאפליקציות פרטיות

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

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

אפליקציות פרטיות לאינטרנט

בתרשים הבא, תעבורת הנתונים זורמת מ- Google Cloudדרך שער ה-NCC, עוברת דרך ה-SSE של צד שלישי לאינטרנט, ואז חוזרת לשער ה-NCC למכונה הווירטואלית.

אפליקציות פרטיות לזרימת תנועת האינטרנט.
זרימת תנועה מאינטרנט לאפליקציות פרטיות (לחצו כדי להגדיל).

זרימת התנועה בתרחישי השימוש של שותפים נתמכים

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

בתרשים הבא, התנועה זורמת ממשתמשים בנייד דרך SSE של צד שלישי לאינטרנט. במקרה כזה, התנועה לא עוברת דרך NCC Gateway.

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

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

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

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

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

בתרשים הבא, התנועה זורמת מהמשתמש בסניף המקומי דרך שער ה-NCC, עוברת דרך ה-SSE של צד שלישי ואז חוזרת דרך שער ה-NCC לסניף המקומי.

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

משתמשים בנייד לאפליקציות פרטיות בסניף

בתרשים הבא, התנועה זורמת ממשתמשים בנייד לאפליקציות פרטיות בסניף דרך NCC Gateway.

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

יכולת עיבוד

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

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

דוגמה: העברת משתמשים לאינטרנט

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

דוגמה: העברת משתמשים לאפליקציות פרטיות

נניח שהרשת המקומית של סניף מחוברת ל-Google Cloud , כמו שמוצג בתרחיש לדוגמה משתמשים בסניף ניגשים לאפליקציות פרטיות, ושבסניף ובאפליקציות הפרטיות נדרש רוחב פס של 1 Gbps דו-כיווני: 1 Gbps לתנועה מהסניף לאפליקציות ו-1 Gbps לתנועה מהאפליקציות לסניף. בדוגמה הזו גם יוצאים מנקודת הנחה ששותף ה-SSE לא משמיט אף חבילת נתונים. אם שותף ה-SSE שבחרתם ממליץ על רוחב פס גבוה יותר ממה שחושב בדוגמה הזו, צריך לפעול לפי ההמלצה של השותף.

כדי לעמוד בדרישות של הסכם רמת השירות (SLA) של Cloud Interconnect, רכזת ה-NCC שאליה מחוברות הרשתות המקומיות של הסניפים צריכה לכלול שני קבצים מצורפים של VLAN ברוחב פס של 1 Gbps. כך, יכול להיות שצירוף ל-VLAN אחד יספק רוחב פס של 1 Gbps בשידור דו-כיווני בין הסניף לבין האפליקציות הפרטיות, גם אם צירוף ל-VLAN אחד לא מקוון (לדוגמה, בגלל תחזוקה של חיבור Interconnect).

קיבולת העיבוד הנדרשת של רכזת השער היא 4 Gbps מהסיבות הבאות:

  • תעבורת הנתונים מהרשת המקומית של הסניף למרכז ה-NCC דורשת רוחב פס של ‎1 Gbps. התנועה הזו דורשת רוחב פס של 2 Gbps בשער כי היא מעובדת בשער בשני המקומות הבאים:

    • ‫1 Gbps כמנות מהצירופים ל-VLAN שמתחברים ל-gateway spoke כשהן נכנסות
    • ‫1 Gbps כשהחבילות יוצאות מ-spoke של שער ומוזנות ל-hub

  • תנועה ממרכז ה-NCC לרשת המקומית של הסניף דורשת גם רוחב פס של ‎1 Gbps. התנועה הזו דורשת רוחב פס נוסף של 2 Gbps בשער, כי היא מעובדת בשער בשני המקומות הבאים:

    • ‫1 Gbps כשהחבילות יוצאות מהרכזת ונכנסות ל-gateway spoke
    • ‫1 Gbps כשהמנות יוצאות ממרכז השליטה של השער ונשלחות לקבצים המצורפים של ה-VLAN שמקשרים לסניף

מומלץ להשתמש באסטרטגיה הבאה כדי להגדיר את יכולת העיבוד של השער ואת רוחב הפס של חיבור ה-VLAN:

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

לתשומת ליבכם

כדי להשתמש ב-NCC Gateway, צריך לעמוד במגבלות הבאות:

  • אפשר לצרף קובצי VLAN של Cloud Interconnect רק ל-NCC Gateway spokes. אין תמיכה במנהרות Cloud VPN ובמכשירי נתב.
  • כל ה-spokes של שער NCC בכל האזורים צריכים להיות באותה קבוצת spokes של שערים. בהטמעה חדשה של NCC Gateway, רכזות NCC צריכות להשתמש בטופולוגיית הבדיקה ההיברידית שהוגדרה מראש. בפריסת brownfield, אפשר להשתמש בטופולוגיה קיימת של כוכב או של רשת מלאה.
  • אפשר לצרף לשער NCC רק שירות אחד בכל פעם.
  • צריך לקשר Cloud Router ל-NCC Gateway באותו אזור.
  • רק צירופי VLAN של Cloud Interconnect שנוצרו עם Cloud Router שמקושר לשער NCC מצורפים לשער.
  • אפשר להשתמש רק ב-NCC Gateway spoke אחד לכל אזור לכל רכזת.
  • ה-spokes וה-hub של NCC Gateway צריכים להיות באותו פרויקט.
  • צריך לציין את יכולת העיבוד בזמן יצירת רכזת שער. במקרה הצורך, אפשר לשנות את קיבולת העיבוד בהמשך.
  • אי אפשר לשנות את טווחי כתובות ה-IP שהוקצו. חלק מטווח כתובות ה-IP שמור לשותפי SSE.
  • אין מדיניות לניתוב תנועה לעקיפת קבוצת משנה של תנועה משער NCC.
  • אם מגדירים נתיב שמוכרז על ידי שער ב-gateway spoke, צריך ליצור שער SSE פעיל כדי להפיץ את הנתיב הזה אל טבלת הנתיבים של NCC hub.
  • אפשר לראות את המסלולים שפורסמו בשער בטבלת המסלולים של רשת ה-VPC או בטבלת המסלולים של רכזת הקבוצה המקושרת שרשת ה-VPC שייכת לה.

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

    במאמר שינוי ערכי ה-MED של כל המסלולים המותאמים אישית שנלמדו בסשן BGP מוסבר איך משנים את ערכי ה-MED.

  • המסלולים שמפורסמים בשער מתוכנתים באמצעות מצב בחירת הנתיב הטוב ביותר הרגיל:

    • העדיפות של מסלולי שער שפורסמו בטבלת המסלולים של הרכזת משקפת את העדיפות האפקטיבית של מסלול Andromeda, למשל 65536 או 65537. העדיפות שבה נוצר המסלול שפורסם על ידי השער נלקחת בחשבון כשמחשבים את העדיפות האפקטיבית של המסלול ב-Andromeda.
    • למסלולים סטטיים תמיד יש עדיפות בין 0-65535, ולכן הם קודמים למסלולים שפורסמו בשער לאותו קידומת יעד. לכן, אם רוצים להפנות תנועת אינטרנט לשער באמצעות נתיב שפורסם בשער עם יעד 0/0, יכול להיות שיהיה צורך להסיר את נתיב ברירת המחדל שנוצר על ידי המערכת. אם מסירים את נתיב ברירת המחדל עם קפיצת ברירת המחדל של שער האינטרנט, צריך ליצור נתיבים מיוחדים ל-Google APIs ולשירותים של Google, או להשתמש בנקודות קצה של Private Service Connect ל-Google APIs גלובליים.

מגבלות לפי קיבולת

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

  • יכול להיות שחלק מהשותפים לא תומכים ב-100Gbps.
  • יכול להיות שבאזורים מסוימים יש תמיכה רק ב-1 Gbps וב-10 Gbps, אבל לא ב-100 Gbps.

מגבלות MTU

קובצי VLAN מצורפים של Cloud Interconnect שמשויכים ל-NCC Gateway spoke צריכים להשתמש ב-MTU של 1,500 בייט.

אין תמיכה בעדכונים של טווח כתובות IP

אחרי שיוצרים את ה-spoke, אי אפשר לשנות את כתובות ה-IP שהוקצו לו. חלק מטווח כתובות ה-IP שמור לשותפי SSE.

בדיקות תקינות

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

סטטוס התקינות של NCC Gateway זמין כמדד מעקב עם התווית healthy או unhealthy.

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

אפשר להגדיר התראות על סמך מדד הסטטוס של שער ה-NCC.

תצוגת מסלולים יעילה לשערי כניסה ולטבלאות מסלולים של מרכזים

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

ל-Gateway spokes יש טבלאות ניתוב משלהם, שבהן צריך לבחור ממשק של שער וכיוון תנועה. מידע נוסף מופיע במאמר בנושא הצגת מסלולי gateway spoke.

דוגמה לתהליך שעובר המשתמש

משתמשים חדשים שלא הגדירו קישוריות מראש יכולים לעיין במאמר הגדרת NCC Gateway למשתמשים חדשים.

חיוב

למידע על המחירים של NCC Gateway, אפשר לעיין במאמר בנושא תמחור של NCC Gateway.

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