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

Last reviewed 2025-01-13 UTC

המסמך הזה הוא חלק מסדרה שמתארת ארכיטקטורות של רשתות ואבטחה לארגונים שמעבירים עומסי עבודה של מרכזי נתונים אל Google Cloud.

הסדרה כוללת את המסמכים הבאים:

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

ארכיטקטורה של שיטת Lift-and-shift (העברה בלי שינויים)

התרחיש הראשון לגישה לעומסי עבודה היברידיים הוא ארכיטקטורת שיטת Lift-and-shift (העברה בלי שינויים).

יצירת קישוריות פרטית

אתם יכולים ליצור קישוריות לרשתות מקומיות באמצעות Dedicated Interconnect או Partner Interconnect. הטופולוגיה שמוצגת באיור 1 מראה איך אפשר להשתמש בארבעה חיבורים של Dedicated Interconnect בשני אזורים מטרופוליטניים שונים ובדומיינים שונים של זמינות קצה כדי להשיג זמינות של 99.99%. (אפשר גם להשיג זמינות של 99.99% באמצעות Partner Interconnect).

כדי ליצור קישוריות בין הרשתות שלכם Google Cloud לרשתות שמתארחות אצל ספק שירותי ענן אחר, משתמשים ב-Cross-Cloud Interconnect.

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

הגדרה של חיבורי Cloud Interconnect מיותרים לזמינות של 99.99%.

איור 1. הגדרה של חיבורים מיותרים של Dedicated Interconnect לזמינות של 99.99%.

‫NCC מאפשר לכם להשתמש ברשת של Google להעברת נתונים בין כמה אתרים מקומיים או אתרים שמתארחים בענן. הגישה הזו מאפשרת לכם ליהנות מההיקף והאמינות של הרשת של Google כשאתם צריכים להעביר נתונים. אתם יכולים להשתמש ב-Cloud VPN, ב-Cloud Interconnect, במכשירי נתב SD-WAN וברשתות VPC קיימים כרכזות ב-NCC כדי לתמוך בהעברת נתונים בין הרשתות המקומיות, אתרי הסניפים, ספקי ענן אחרים וGoogle Cloud רשתות VPC, כמו שמוצג באיור 2.

הגדרת NCC לחיבור רשתות ארגוניות שונות מקומיות מחוץ ל- Google Cloud באמצעות רשת בשדרה מרכזית של Google.

איור 2. הגדרת NCC לחיבור בין רשתות שונות בארגון מקומי ורשתות ענן אחרות מחוץ ל- Google Cloud באמצעות רשת בשדרה מרכזית של Google.

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

מכשירי SD-WAN

‫NCC מאפשר לכם להשתמש בנתב וירטואלי של צד שלישי כרכזת של NCC כדי ליצור קישוריות בין אתר חיצוני לבין משאבי רשת ה-VPC שלכם. נתב וירטואלי יכול להיות נתב SD-WAN של צד שלישי שנתמך על ידי אחד מהשותפים שלנו או מכשיר וירטואלי אחר שמאפשר לכם להחליף מסלולים עם מופע Cloud Router. הפתרונות האלה מבוססי-התקנים הם בנוסף לאפשרויות הקישוריות הקיימות בין אתרים לבין הענן, שזמינות עם Cloud VPN ו-Cloud Interconnect כרכזות. איור 3 מציג טופולוגיה שמשתמשת במכשירי SD-WAN.

הגדרת NCC באמצעות מכשיר נתב לשילוב ההטמעה של SD-WAN עם הרשת של Google.

איור 3. הגדרת NCC באמצעות מכשיר נתב לשילוב ההטמעה של SD-WAN עם הרשת של Google.

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

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

ארכיטקטורה של שירותים היברידיים

כמו בתרחיש השימוש בענן שנדון במאמר Networking for secure intra-cloud access: Reference architectures,‏ NCC מאפשר קישוריות מהסניפים ומהרשתות המקומיות אל Google Cloud. ‫Private Service Connect מספק גישה פרטית לשירותים בניהול Google או מאפשר לכם להשתמש בשירותים אחרים שנוצרו ונפרסו בענן.

אפשר גם להטמיע אבטחת רשת באמצעות שילוב של Google Cloud חומות אש, מכשירי רשת וירטואליים ו-VPC Service Controls, כמו שמוצג באיור 4.

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

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

ארכיטקטורה מבוזרת עם מודל אבטחה של אפס אמון

בסביבה היברידית, מיקרו-שירותים פועלים ברשתות שירותים שנפרסות אצל ספקי ענן שונים ובסביבות מקומיות. כדי לאבטח את התקשורת בין המיקרו-שירותים, אפשר להשתמש ב-Transport Layer Security (‏mTLS) הדדית ובמדיניות הרשאות. בארגונים נהוג לבנות רשתות של שירותים בענן ולהרחיב את הרשתות גם לשרתים מקומיים. איור 5 מציג דוגמה שבה שירותים שנפרסו במקום ניגשים לשירותים בענן. ה-mTLS מקצה לקצה בין השירותים מופעל באמצעות שער מזרח-מערב וניתוב מבוסס-SNI (אינדיקציה של שם השרת). Cloud Service Mesh עוזר לאבטח תקשורת בין שירותים, ומאפשר להגדיר מדיניות הרשאות לשירותים ולפרוס אישורים ומפתחות שסופקו על ידי רשות אישורים מנוהלת.

בסביבות היברידיות יש בדרך כלל כמה פריסות של רשתות, כמו כמה אשכולות GKE. רכיב חשוב בתהליך הזה הוא ניתוב SNI, שמשמש בשער east-west של GKE לכל אשכול. ההגדרה הזו מאפשרת לנתב mTLS ישירות לעומס העבודה דרך שער הכניסה, תוך שמירה על קישוריות mTLS מקצה לקצה.

רשת Service mesh של אפס אמון שנפרסה בסביבה מקומית וב- Google Cloud.

איור 5. רשת Service mesh עם אפס אמון שפרוסה בסביבה מקומית וב- Google Cloud.

חברות יכולות להשתמש ב-Cloud Service Mesh כדי לבצע פריסה בעננים שונים. כדי להתמודד עם אתגרים בניהול זהויות ואישורים אצל ספקי ענן שונים, Cloud Service Mesh מספק Workload Identity ורשות אישורים (CA) ביניים בתוך האשכול, באמצעות CA Service. אפשר לשרשר את רשות האישורים (CA) הביניים לרשות אישורים (CA) חיצונית או לארח אותה ב-Google. אתם יכולים להתאים אישית מאפיינים של CA כמו אזור ואלגוריתם החתימה, באמצעות HSMs בבעלות הארגון וגם באמצעות Cloud HSM.

Workload Identity מאפשר להקצות זהויות והרשאות שונות ומפורטות לכל מיקרו-שירות באשכול. ‫Cloud Service Mesh מנהל את תהליך הנפקת האישורים ואת הרוטציה האוטומטית של המפתחות והאישורים, בלי לשבש את התקשורת. בנוסף, הוא מספק שורש יחיד של אמון בכל אשכולות GKE.

איור 6 מציג ארכיטקטורה שמשתמשת ב-Cloud Service Mesh כדי לנהל את הזהות וההרשאה.

שירותים ברשת יכולים לגשת לשירותים Google Cloud באמצעות איחוד שירותי אימות הזהות של עומסי עבודה. התכונה הזו מאפשרת לשירותים לפעול עם הסמכות של חשבון שירות ב-Google כשהם מפעילים Google Cloud ממשקי API. איחוד זהויות של עומסי עבודה מאפשר גם ל-Service mesh שמותקן אצל ספקי שירותי ענן אחרים לגשת ל-Cloud APIs של Google Cloud.

פריסת רשת שירותים (service mesh) במודל אפס אמון בעננים שונים.

איור 6. פריסת רשת שירותים (service mesh) במודל אפס אמון בעננים שונים.

אפשר להשתמש ב-Cloud Service Mesh כדי לנתב תעבורה מהרשת אל שרתים מקומיים או אל כל ענן אחר.

לדוגמה, אפשר ליצור שירותים ב-Cloud Service Mesh בשם on-prem-service,‏ other-cloud-service ולהוסיף קבוצות של נקודות קצה ברשת (NEGs) עם קישוריות היברידית שיש להן נקודות קצה 10.1.0.1:80 ו-10.2.0.1:80. לאחר מכן, Cloud Service Mesh שולח את התנועה ללקוחות שלו, שהם פרוקסי מסוג sidecar של רשת Mesh שפועלים לצד האפליקציות שלכם. לכן, כשהאפליקציה שולחת בקשה לשירות on-prem-service, הלקוח של Cloud Service Mesh בודק את הבקשה ומפנה אותה לנקודת הקצה 10.2.0.1:80. איור 7 ממחיש את ההגדרה הזו.

תעבורת נתונים שמופנית מ-Service Mesh באמצעות Cloud Service Mesh.

איור 7. תעבורת נתונים שמופנית מ-Service Mesh באמצעות Cloud Service Mesh.

אפשר גם לשלב פונקציונליות מתקדמת כמו ניהול תנועה לפי משקל, כפי שמוצג באיור 8. היכולת הזו מאפשרת לכם להפעיל צרכים קריטיים של ארגונים, כמו העברה לענן. Cloud Service Mesh משמש כמישור בקרה גלובלי מנוהל ורב-תכליתי לרשתות Service mesh.

תעבורת נתונים משוקללת שמנותבת באמצעות Cloud Service Mesh.

איור 8. תעבורת נתונים משוקללת שמנותבת באמצעות Cloud Service Mesh.

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