פריסת מודל של רכזת ונקודות הסתעפות

במאמר הזה מוסבר איך להטמיע ולנהל את מודל ה-hub and spoke כשמשתמשים בשירות מנוהל ל-Microsoft AD.

Hub and spoke on Google Cloud

מודל רכזת וחישורים הוא עיצוב רשת שבו המכשיר המרכזי, או הרכזת, מחובר למכשירים אחרים רבים, או חישורים. כדי להטמיע את העיצוב הזה ב- Google Cloud, יוצרים ענן וירטואלי פרטי (VPC) שמחובר לרשת המקומית באמצעות Cloud Interconnect או VPN. ה-VPC משמש כרכזת. באמצעות קישור (peering) בין רשתות VPC שכנות, אפשר ליצור חיבורים לפרויקטים אחרים ולמשאבים מקומיים או לרשתות מסוג Hub and Spoke.

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

ההשפעה על שירות מנוהל ל-Microsoft AD

כדי לספק קישוריות לרשתות מורשות שמתארחות בפרויקטים של משתמשים, Managed Microsoft AD משתמש בקישור בין רשתות שכנות (peering) של VPC עם החלפת מסלולים שמופעלת כברירת מחדל. כך מתאפשרת קישוריות בין הרשתות המורשות לבין פרויקטי הדיירים שמארח ה-VPC. אפשר גם להגדיר Cloud Interconnect או VPN ישירות עם רשת מורשית.

עם זאת, אם הרשת המורשית היא רשת מסוג Spoke או שהיא מקושרת לרשת שמחוברת לרשת המקומית, למשאבים של שירות מנוהל ל-Microsoft AD לא תהיה גישה למשאבים מקומיים, ולהפך. יש שני פתרונות עקיפים אפשריים שיאפשרו קישוריות.

שימוש ב-VPC משותף

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

שימוש ב-VPN

אפשר גם להשתמש ב-VPN בין הרכזת לבין הרשתות המקומיות במקום בחיבור VPC כדי לעקוף את המגבלה על החלפת מסלולים.

פתרון עקיף ל-VPN

איור 1. שימוש ב-VPN כדי לעקוף את ההגבלה על החלפת מסלולים.

הפתרון העקיף הזה פחות אידיאלי כי הוא מחייב תכנון רשת מורכב יותר וגורר עלות נוספת של מנהרות VPN. כשיוצרים VPN בין Hub ל-spoke, שירות מנוהל ל-Microsoft AD נחשב לרשת עמיתה ישירה של הרשת המורשית, והמסלולים לרשת המרכזית ייוצאו. כשמשתמשים בגישה הזו, מומלץ להשתמש ב-DNS peering בין הרשת המורשית לבין רשת ה-hub וה-spokes, כדי שאפשר יהיה להעביר בקשות DNS לרשת שירות מנוהל ל-Microsoft AD דרך הגדרת הרשת המורשית.