המסמך הזה הוא חלק מסדרת מדריכי עיצוב לרשתות חוצות-ענן.
הסדרה מורכבת מהחלקים הבאים:
- Cross-Cloud Network לאפליקציות מבוזרות
- פילוח רשת וקישוריות לאפליקציות מבוזרות ב-Cross-Cloud Network (המסמך הזה)
- רשת שירותים לאפליקציות מבוזרות ב-Cross-Cloud Network
- אבטחת רשת לאפליקציות מבוזרות ב-Cross-Cloud Network
בחלק הזה נסביר על המבנה של פילוח הרשת ועל הקישוריות שלה, שהם הבסיס של העיצוב. במסמך הזה מוסבר על השלבים שבהם מבצעים את הבחירות הבאות:
- פילוח הרשת הכולל ומבנה הפרויקט.
- איפה אתם ממקמים את עומס העבודה.
- איך הפרויקטים שלכם מחוברים לרשתות חיצוניות מקומיות ולרשתות של ספקי ענן אחרים, כולל העיצוב של הקישוריות, הניתוב וההצפנה.
- איך רשתות ה-VPC מחוברות פנימית זו לזו.
- איך תת-הרשתות של ה-VPC שלכם מחוברות זו לזו ולרשתות אחרות, כולל איך מגדירים את הגישה לשירות ואת ה-DNS. Google Cloud
סגמנטציה של רשת ומבנה פרויקט
בשלב התכנון, צריך לבחור אחת משתי אפשרויות למבנה הפרויקט:
- פרויקט מארח מאוחד של תשתיות, שבו משתמשים בפרויקט מארח יחיד של תשתיות כדי לנהל את כל משאבי הרשת לכל האפליקציות
- פרויקטים של מארחים מפולחים, שבהם משתמשים בפרויקט מארח של תשתית בשילוב עם פרויקט מארח אחר לכל אפליקציה
בשלב התכנון, מומלץ גם להחליט על דומיינים אדמיניסטרטיביים לסביבות העבודה של העומס. הגדירו את היקף ההרשאות של מנהלי התשתית והמפתחים בהתאם לעיקרון של מתן ההרשאה המינימלית הנדרשת, והגדירו את היקף המשאבים של האפליקציה בפרויקטים שונים של אפליקציות. מנהלי תשתית צריכים להגדיר קישוריות כדי לשתף משאבים, ולכן אפשר לטפל במשאבי תשתית במסגרת פרויקט תשתית. לדוגמה, כדי להגדיר קישוריות למשאבי תשתית משותפים, אדמינים של תשתית יכולים להשתמש בפרויקט תשתית כדי לטפל במשאבים המשותפים האלה. במקביל, צוות הפיתוח יכול לנהל את עומסי העבודה שלו בפרויקט אחד, וצוות הייצור יכול לנהל את עומסי העבודה שלו בפרויקט נפרד. לאחר מכן, המפתחים משתמשים במשאבי התשתית בפרויקט התשתית כדי ליצור ולנהל משאבים, שירותים, איזון עומסים ומדיניות ניתוב DNS עבור עומסי העבודה שלהם.
בנוסף, צריך להחליט כמה רשתות VPC תטמיעו בהתחלה ואיך הן יאורגנו בהיררכיית המשאבים. פרטים על בחירת היררכיית משאבים מופיעים במאמר החלטה על היררכיית משאבים לאזור הנחיתה של Google Cloud . פרטים על בחירת מספר רשתות ה-VPC זמינים במאמר האם כדאי ליצור כמה רשתות VPC.
לרשת Cross-Cloud, מומלץ להשתמש ב-VPC הבאים:
- רשת VPC אחת או יותר של אפליקציות לאירוח המשאבים של האפליקציות השונות.
- רשת VPC אחת או יותר למעבר, שבהן מטופל כל הקישור החיצוני.
- רשת VPC אחת או יותר לגישה לשירותים, שאפשר להשתמש בהן כדי לאחד את הפריסה של גישה פרטית לשירותים שפורסמו.
בתרשים הבא מוצג ייצוג חזותי של מבנה ה-VPC המומלץ שתיארנו. אפשר להשתמש במבנה ה-VPC שמוצג בתרשים עם מבנה פרויקט מאוחד או עם מבנה פרויקט מחולק, כמו שמתואר בקטעים הבאים. בתרשים הזה לא מוצגת קישוריות בין רשתות ה-VPC.
פרויקט מארח של תשתית מאוחדת
אתם יכולים להשתמש בפרויקט מארח של תשתית מאוחדת כדי לנהל את כל משאבי הרשת, כמו רשתות VPC ותת-רשתות, מרכזים של Network Connectivity Center, קישור (peering) בין רשתות VPC ומאזני עומסים.
אפשר ליצור כמה רשתות VPC משותפות של אפליקציות עם פרויקטים תואמים של שירותי אפליקציות בפרויקט המארח של התשתית, כדי להתאים למבנה הארגון. אפשר להשתמש בכמה פרויקטים של שירותי אפליקציות כדי להקצות ניהול של משאבים. כל הפעילות ברשת בכל רשתות ה-VPC של האפליקציות מחויבת בפרויקט המארח של התשתית המאוחדת.
במבנה הפרויקט הזה, הרבה פרויקטים של שירותי אפליקציות יכולים לחלוק מספר קטן יותר של רשתות VPC של אפליקציות.
בתרשים הבא מוצגת תשתית מאוחדת של פרויקט מארח ומספר פרויקטים של שירותי אפליקציות שתוארו קודם. התרשים לא מציג קישוריות בין כל הפרויקטים.
פרויקטים של מארחים עם פילוח
בדפוס הזה, לכל קבוצת אפליקציות יש פרויקט מארח משלה לאפליקציות ורשתות VPC משלה. אפשר לצרף לפרויקט המארח כמה פרויקטים של שירותי אפליקציות. החיוב על שירותי רשת מתחלק בין פרויקט המארח של התשתית לבין פרויקטים של מארחי אפליקציות. חיובים על תשתית מחויבים לפרויקט המארח של התשתית, וחיובים על רשת, כמו חיובים על העברת נתונים לאפליקציות, מחויבים לכל פרויקט מארח של אפליקציה.
הדיאגרמה הבאה מספקת ייצוג חזותי של פרויקטים מרובים של מארחים ופרויקטים מרובים של שירותי אפליקציות שתוארו זה עתה. בתרשים לא מוצגת הקישוריות בין כל הפרויקטים.
מיקום עומס העבודה
אפשרויות רבות לקישוריות תלויות במיקומים האזוריים של עומסי העבודה. לקבלת הדרכה בנושא מיקום עומסי עבודה, ראו שיטות מומלצות לבחירת אזורים ב-Compute Engine. לפני שבוחרים את מיקומי הקישוריות, צריך להחליט איפה יהיו עומסי העבודה.
קישוריות חיצונית והיברידית
בקטע הזה מפורטות הדרישות וההמלצות לגבי נתיבי הקישוריות הבאים:
- חיבורים פרטיים לספקי ענן אחרים
- חיבורים פרטיים למרכזי נתונים מקומיים
- קישוריות לאינטרנט לעומסי עבודה, במיוחד קישוריות יוצאת
רשתות חוצות ענן כוללות חיבורים בין כמה רשתות ענן או רשתות מקומיות. רשתות חיצוניות יכולות להיות בבעלות של ארגונים שונים ולנוהל על ידם. הרשתות האלה מחוברות פיזית זו לזו בממשקי רשת לרשת (NNI) אחד או יותר. השילוב של ממשקי NN צריך להיות מתוכנן, מוקצה ומוגדר לביצועים, גמישות, פרטיות ואבטחה.
כדי להשיג מודולריות, שימוש חוזר ויכולת להוסיף מכשירי NVA לאבטחה, כדאי למקם את החיבורים החיצוניים ואת הניתוב ב-VPC מעבר, שמשמש לאחר מכן כשירות קישוריות משותף לרשתות VPC אחרות. אפשר להגדיר מדיניות ניתוב לחוסן, ליתירות כשל ולבחירת נתיב בין דומיינים פעם אחת ב-VPC המעברי, ולהשתמש בה ברשתות VPC רבות אחרות.
העיצוב של ממשקי ה-NNI והקישוריות החיצונית ישמשו בהמשך לקישוריות פנימית ולרשתות VPC.
בתרשים הבא מוצג VPC מרכזי שמשמש כשירות קישוריות משותף לרשתות VPC אחרות, שמקושרות באמצעות קישור בין רשתות VPC שכנות (peering), Network Connectivity Center או HA VPN. כדי שהתרשים יהיה פשוט וברור, מוצג בו VPC מרכזי יחיד, אבל אפשר להשתמש בכמה רשתות VPC מרכזיות לקישוריות באזורים שונים.
חיבורים פרטיים לספקי ענן אחרים
אם יש לכם שירותים שפועלים ברשתות של ספק אחר של שירותי ענן (CSP) שאתם רוצים להתחבר אליהם לרשת Google Cloud שלכם, אתם יכולים להתחבר אליהם דרך האינטרנט או באמצעות חיבורים פרטיים. אנחנו ממליצים על חיבורים פרטיים.
כשבוחרים אפשרויות, חשוב לקחת בחשבון את התפוקה, הפרטיות, העלות והכדאיות התפעולית.
כדי למקסם את קצב העברת הנתונים ולשפר את הפרטיות, מומלץ להשתמש בחיבור ישיר ומהיר בין רשתות ענן. חיבורים ישירים מבטלים את הצורך בציוד רשת פיזי ביניים. מומלץ להשתמש ב-Cross-Cloud Interconnect, שמספק חיבורים ישירים כאלה, וגם הצפנת MACsec וקצב העברת נתונים של עד 100Gbps לכל קישור.
אם אי אפשר להשתמש ב-Cross-Cloud Interconnect, אפשר להשתמש ב-Dedicated Interconnect או ב-Partner Interconnect דרך מתקן לאחסון ואירוח שרתים (colocation facility).
בוחרים את המיקומים שבהם מתחברים לספקי CSP אחרים על סמך הקרבה של המיקום לאזורי היעד. כשבוחרים מיקומים, כדאי להביא בחשבון את הנקודות הבאות:
- בודקים את רשימת המיקומים:
- ב-Cross-Cloud Interconnect, צריך לעיין ברשימת המיקומים שזמינים גם ל- Google Cloud וגם לספקי שירותי ענן (הזמינות משתנה בהתאם לספק הענן).
- אם משתמשים ב-Dedicated Interconnect או ב-Partner Interconnect, בוחרים מיקום עם זמן אחזור נמוך למתקן לאחסון ואירוח שרתים (colocation facility).
- הערכת זמן האחזור בין נקודת הנוכחות (POP) בקצה הרשת לבין האזור הרלוונטי בכל ספק CSP.
כדי למקסם את המהימנות של החיבורים בין העננים, מומלץ להשתמש בהגדרה שתומכת בהסכם רמת שירות (SLA) עם זמן פעולה תקינה של 99.99% לעומסי עבודה של ייצור. לפרטים נוספים, אפשר לעיין במאמרים בנושא זמינות גבוהה של Cross-Cloud Interconnect, השגת זמינות של 99.99% ל-Dedicated Interconnect והשגת זמינות של 99.99% ל-Partner Interconnect.
אם אתם לא צריכים רוחב פס גבוה בין ספקי CSP שונים, אתם יכולים להשתמש במנהרות VPN. הגישה הזו יכולה לעזור לכם להתחיל, ותוכלו לשדרג ל-Cross-Cloud Interconnect כשהאפליקציות המבוזרות שלכם יצטרכו רוחב פס גדול יותר. מנהרות VPN יכולות גם להשיג הסכם SLA של 99.99%. לפרטים נוספים, אפשר לעיין בטופולוגיות של HA VPN.
חיבורים פרטיים למרכזי נתונים מקומיים
כדי להתחבר למרכזי נתונים פרטיים, אפשר להשתמש באחת מהאפשרויות הבאות לקישור היברידי:
- Dedicated Interconnect
- Partner Interconnect
- HA VPN
שיקולי הניתוב של החיבורים האלה דומים לאלה של חיבורים פרטיים לספקי ענן אחרים.
בתרשים הבא מוצגים חיבורים לרשתות מקומיות ואיך נתבים מקומיים יכולים להתחבר ל-Cloud Router באמצעות מדיניות שיתוף פעולה:
ניתוב בין דומיינים עם רשתות חיצוניות
כדי לשפר את העמידות ואת קצב העברת הנתונים בין הרשתות, כדאי להשתמש בכמה נתיבים לחיבור הרשתות.
כשמעבירים תעבורה בין דומיינים ברשת, צריך לבדוק אותה באמצעות מכשירי אבטחה עם שמירת מצב. לכן, נדרשת סימטריה של זרימת הנתונים בגבול בין הדומיינים.
ברשתות שמעבירות נתונים בין כמה אזורים, יכול להיות שהעלות ורמת איכות השירות של כל רשת יהיו שונות באופן משמעותי. יכול להיות שתחליטו להשתמש ברשתות מסוימות ולא באחרות, בהתאם להבדלים האלה.
מגדירים את מדיניות הניתוב בין דומיינים בהתאם לדרישות שלכם לגבי מעבר בין אזורים, סימטריה של תנועת הגולשים, קצב העברת נתונים ועמידות.
ההגדרה של מדיניות הניתוב בין דומיינים תלויה בפונקציות הזמינות בקצה של כל דומיין. ההגדרה תלויה גם במבנה של הדומיינים הסמוכים מנקודת מבט של מערכת אוטונומית ושל הקצאת כתובות IP (חלוקת רשתות משנה) באזורים שונים. כדי לשפר את יכולת ההתאמה לגודל בלי לחרוג ממגבלות הקידומות במכשירי קצה, מומלץ שתוכנית הקצאת כתובות ה-IP תניב פחות קידומות מצטברות לכל שילוב של אזור ודומיין.
כשמתכננים ניתוב בין אזורים, כדאי לקחת בחשבון את הנקודות הבאות:
- Google Cloud רשתות VPC ו-Cloud Router תומכים בניתוב גלובלי בין אזורים. יכול להיות שלספקי CSP אחרים יש עננים וירטואליים פרטיים (VPC) אזוריים והיקפים של פרוטוקול Border Gateway Protocol (BGP). פרטים נוספים זמינים במסמכי התיעוד של ספק ה-CSP השני.
- Cloud Router מפרסם מסלולים באופן אוטומטי עם העדפות נתיב שנקבעו מראש על סמך קרבה אזורית. התנהגות הניתוב הזו תלויה במצב הניתוב הדינמי שהוגדר ברשת ה-VPC. יכול להיות שתצטרכו לבטל את ההעדפות האלה כדי לקבל את התנהגות הניתוב הרצויה.
- ספקי CSP שונים תומכים בפונקציות שונות של BGP ושל BFD (Bidirectional Forwarding Detection), ול-Cloud Router של Google יש גם יכולות ספציפיות של מדיניות ניתוב, כפי שמתואר במאמר הקמת סשנים של BGP.
- ספקי CSP שונים עשויים להשתמש בתכונות שונות של BGP כדי להכריע בין מסלולים ולתת עדיפות למסלולים מסוימים. פרטים נוספים מופיעים במסמכי התיעוד של ספק ה-CSP שלכם.
ניתוב בין דומיינים באזור יחיד
מומלץ להתחיל עם ניתוב בין-דומייני באזור יחיד, ואז להשתמש בו כבסיס ליצירת חיבורים בין-דומייניים בכמה אזורים.
בארכיטקטורות שמשתמשות ב-Cloud Interconnect, נדרשים לפחות שני מיקומי חיבור שנמצאים באותו אזור אבל בתחומי זמינות שונים של קצה הרשת.
מחליטים אם להגדיר את החיבורים הכפולים האלה בעיצוב פעיל/פעיל או בעיצוב פעיל/סביל:
- בשיטת Active/active נעשה שימוש בניתוב Equal Cost Multi-Path (ECMP) כדי לצבור את רוחב הפס של שני הנתיבים ולהשתמש בהם בו-זמנית לתעבורה בין דומיינים. בנוסף, Cloud Interconnect תומך בשימוש בקישורים מצטברים של LACP כדי להשיג רוחב פס מצטבר של עד 200 Gbps לכל נתיב.
- במצב פעיל/סביל, קישור אחד נמצא במצב המתנה, והוא יקבל תנועה רק אם הקישור הפעיל ייקטע.
מומלץ להשתמש בעיצוב פעיל/פעיל לקישורים בתוך האזור. עם זאת, טופולוגיות מסוימות של רשתות מקומיות בשילוב עם שימוש בפונקציות אבטחה עם שמירת מצב, עשויות לחייב עיצוב פעיל/סביל.
Cloud Router מופעל בכמה אזורים, ולכן הוא מספק עמידות גבוהה יותר מאשר רכיב יחיד. בתרשים הבא מוצג האופן שבו כל החיבורים העמידים מתכנסים ב-Cloud Router יחיד באזור מסוים. העיצוב הזה יכול לתמוך בהסכם רמת שירות (SLA) של זמינות של 99.9% באזור מטרופוליטני יחיד, אם פועלים לפי ההנחיות להשגת זמינות של 99.9% בשביל Dedicated Interconnect.
בתרשים הבא מוצגים שני נתבים מקומיים שמחוברים בצורה יתירה לשירות Cloud Router המנוהל באזור יחיד:
ניתוב בין דומיינים בכמה אזורים
כדי לספק קישוריות לגיבוי, רשתות יכולות לבצע פירינג במספר אזורים גיאוגרפיים. על ידי חיבור הרשתות במספר אזורים, רמת הזמינות של ה-SLA יכולה לעלות ל-99.99%.
התרשים הבא מציג את הארכיטקטורות של הסכם רמת השירות (SLA) של 99.99%. הוא מציג נתבים מקומיים בשני מיקומים שונים שמחוברים בצורה יתירה לשירותים המנוהלים של Cloud Router בשני אזורים שונים.
בנוסף לעמידות, תכנון הניתוב במספר אזורים צריך להשיג סימטריה של זרימת הנתונים. בנוסף, העיצוב צריך לציין את הרשת המועדפת לתקשורת בין אזורים, שאפשר לעשות באמצעות ניתוב חם וניתוב קר. לשלב ניתוב קר בדומיין אחד עם ניתוב חם בדומיין עמית. לדומיין cold-potato, מומלץ להשתמש בדומייןGoogle Cloud network, שמספק פונקציונליות של ניתוב VPC גלובלי.
סימטריה של התנועה לא תמיד נדרשת, אבל אסימטריה של התנועה עלולה לגרום לבעיות בפונקציות אבטחה עם שמירת מצב.
הדיאגרמה הבאה מראה איך אפשר להשתמש בניתוב hot-potato ו-cold-potato כדי לציין את רשת התעבורה המועדפת בין אזורים. במקרה כזה, התנועה מהקידומות X ו-Y נשארת ברשת המקורית עד שהיא מגיעה לאזור הקרוב ביותר ליעד (ניתוב cold-potato). התנועה מקידומות A ו-B עוברת לרשת השנייה באזור המקורי, ואז עוברת דרך הרשת השנייה ליעד (ניתוב hot-potato).
הצפנה של תנועה בין דומיינים
אלא אם צוין אחרת, התנועה לא מוצפנת בחיבורי Cloud Interconnect בין ספקי CSP שונים או בין מרכזי נתונים של Google Cloud לבין מרכזי נתונים מקומיים. אם הארגון שלכם דורש הצפנה של התנועה הזו, אתם יכולים להשתמש ביכולות הבאות:
- MACsec ל-Cloud Interconnect: מצפין את התעבורה בחיבורי Cloud Interconnect בין הנתבים שלכם לבין נתבי הקצה של Google. לפרטים נוספים, ראו סקירה כללית על MACsec ל-Cloud Interconnect.
- HA VPN over Cloud Interconnect: משתמש בכמה מנהרות HA VPN כדי לספק את רוחב הפס המלא של חיבורי Cloud Interconnect הבסיסיים. מנהרות HA VPN מוצפנים באמצעות IPsec ונפרסים על חיבורי Cloud Interconnect, שיכולים להיות מוצפנים גם באמצעות MACsec. בהגדרה הזו, חיבורי Cloud Interconnect מוגדרים כך שרק תנועה של HA VPN מותרת. פרטים נוספים זמינים במאמר סקירה כללית על HA VPN over Cloud Interconnect.
קישוריות לאינטרנט לעומסי עבודה
גם לקישוריות לאינטרנט לדואר נכנס וגם לקישוריות לאינטרנט לדואר יוצא, תעבורת הנתונים בתגובה מניחה שהכיוון שלה הפוך לכיוון של הבקשה המקורית.
בדרך כלל, תכונות שמספקות קישוריות נכנסת לאינטרנט נפרדות מתכונות שמספקות קישוריות יוצאת לאינטרנט, למעט כתובות IP חיצוניות שמספקות קישוריות בשני הכיוונים בו-זמנית.
קישוריות לאינטרנט נכנסת
קישוריות אינטרנט נכנסת קשורה בעיקר לאספקת נקודות קצה ציבוריות לשירותים שמתארחים בענן. דוגמאות לכך כוללות קישוריות אינטרנט לשרתי אפליקציות אינטרנט ולשרתי משחקים שמתארחים ב-Google Cloud.
התכונות העיקריות שמספקות קישוריות נכנסת לאינטרנט הן מוצרי Cloud Load Balancing של Google. העיצוב של רשת VPC לא תלוי ביכולת שלה לספק קישוריות נכנסת לאינטרנט:
- נתיבי הניתוב למאזנים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי מספקים קישוריות בין לקוחות למכונות וירטואליות בעורף.
- נתיבי הניתוב בין ממשקי הקצה של Google (GFE) לבין שרתי קצה עורפיים מספקים קישוריות בין שרתי proxy של GFE למאזני עומסים חיצוניים גלובליים של אפליקציות או למאזני עומסי רשת גלובליים חיצוניים של שרתי proxy ולמכונות וירטואליות של שרת קצה עורפי.
- רשת משנה לשרתי proxy בלבד מספקת קישוריות בין שרתי proxy של Envoy למאזני עומסים אזוריים חיצוניים של אפליקציות (ALB) או למאזני עומסים אזוריים חיצוניים של רשתות בשרתי proxy, ולמכונות וירטואליות של בק-אנד.
קישוריות לאינטרנט יוצא
דוגמאות לקישוריות לאינטרנט יוצאת (כשהבקשה הראשונית מגיעה מעומס העבודה ליעד באינטרנט) כוללות עומסי עבודה שגולשים לממשקי API של צד שלישי, מורידים חבילות תוכנה ועדכונים ושולחים התראות פוש לנקודות קצה של webhook באינטרנט.
לגבי קישוריות יוצאת, אפשר להשתמש Google Cloud באפשרויות מובנות, כפי שמתואר במאמר חלופות לשימוש בכתובת IP חיצונית. לחלופין, אפשר להשתמש במכונות וירטואליות של NGFW מרכזי, כפי שמתואר במאמר אבטחת רשת.
הנתיב העיקרי לקישוריות יוצאת לאינטרנט הוא יעד שער האינטרנט שמוגדר כברירת מחדל בטבלת הניתוב של ה-VPC, שהוא לרוב הנתיב שמוגדר כברירת מחדל ברשתות VPC של Google. גם כתובות IP חיצוניות וגם Cloud NAT (שירות NAT מנוהל שלGoogle Cloud) דורשים נתיב שמפנה לשער האינטרנט שמוגדר כברירת מחדל ב-VPC. לכן, עיצובים של ניתוב ב-VPC שמבטלים את הנתיב שמוגדר כברירת מחדל חייבים לספק קישוריות יוצאת באמצעים אחרים. לפרטים נוספים, אפשר לעיין במאמר סקירה כללית על Cloud Router.
כדי לאבטח את הקישוריות היוצאת, Google Cloud מציע גם אכיפה של Cloud Next Generation Firewall וגם Secure Web Proxy כדי לספק סינון מעמיק יותר של כתובות URL של HTTP ו-HTTPS. עם זאת, בכל המקרים, התעבורה פועלת לפי נתיב ברירת המחדל אל שער האינטרנט שמוגדר כברירת מחדל או דרך נתיב ברירת מחדל מותאם אישית בטבלת הניתוב של ה-VPC.
שימוש בכתובות IP משלכם
אתם יכולים להשתמש בכתובות IPv4 בבעלות Google כדי להתחבר לאינטרנט, או להשתמש בהעברת כתובות IP משלכם (BYOIP) כדי להשתמש במרחב IPv4 שבבעלות הארגון שלכם. ברוב מוצרי Google Cloud Google Cloud שנדרשת בהם כתובת IP שניתן לנתב באינטרנט, יש תמיכה בשימוש בטווחים של BYOIP במקום זאת.
אפשר גם לשלוט במוניטין של מרחב כתובות ה-IP באמצעות שימוש בלעדי בו. השימוש ב-BYOIP עוזר בניידות של הקישוריות, ויכול לחסוך בעלויות של כתובות IP.
קישוריות פנימית ורשתות VPC
אחרי שמגדירים את שירות הקישוריות החיצונית וההיברידית, משאבים ב-VPC של התעבורה יכולים להגיע לרשתות החיצוניות. השלב הבא הוא להפוך את הקישוריות הזו לזמינה למשאבים שמארחים ברשתות VPC אחרות.
בתרשים הבא מוצגת המבנה הכללי של VPC, בלי קשר לאופן שבו הפעלתם קישוריות חיצונית. מוצג VPC למעבר נתונים שמסיים חיבורים חיצוניים ומארח Cloud Router בכל אזור. כל Cloud Router מקבל מסלולים מהרשתות החיצוניות השכנות שלו דרך ממשקי הרשת לרשת (NNI) בכל אזור. רשתות VPC של אפליקציות מחוברות ל-VPC למעבר נתונים כדי שיוכלו לשתף קישוריות חיצונית. בנוסף, ה-VPC למעבר נתונים פועל כמרכז לרשתות ה-VPC המשניות. ברשתות ה-VPC המשניות אפשר לארח אפליקציות, שירותים או שילוב של שניהם.
כדי להשיג ביצועים אופטימליים ומדרגיות עם שירותי הרשת המובנים בענן, צריך לקשר בין רשתות VPC באמצעות NCC, כמו שמתואר במאמר קישוריות בין רשתות VPC באמצעות NCC. NCC מספקת את השירותים הבאים:
- גישה טרנזיטיבית לנקודות קצה של Private Service Connect L4 ו-L7 ולשירותים המשויכים שלהן
- גישה טרנזיטיבית לרשתות מקומיות שנלמדות באמצעות BGP
- היקף רשתות VPC של 250 רשתות לכל רכזת
אם רוצים להוסיף מכשירים וירטואליים לרשת (NVA) לצורך חומת אש או פונקציות אחרות ברשת, צריך להשתמש בקישור בין רשתות VPC שכנות (peering). חומות אש היקפיות יכולות להישאר ברשתות חיצוניות. אם אתם צריכים להוסיף NVA, תוכלו להשתמש בתבנית קישוריות בין רשתות VPC באמצעות שיתוף רשתות VPC כדי לקשר בין רשתות ה-VPC.
צריך להגדיר גם העברת DNS וקישור בין רשתות VPC שכנות (peering) ב-VPC המעבר. פרטים נוספים זמינים בקטע תכנון תשתית ה-DNS.
בקטעים הבאים נדון בעיצובים אפשריים לקישוריות היברידית שתומכים בקישוריות IP בסיסית וגם בפריסות של נקודות גישה ל-API.
קישוריות בין רשתות VPC באמצעות NCC
מומלץ לחבר את כל ה-VPC של האפליקציות, ה-VPC של התעבורה וה-VPC של הגישה לשירותים באמצעות רכיבי VPC של NCC.
נקודות גישה לצרכני שירות נפרסות ברשתות VPC של גישה לשירותים כשהן צריכות להיות נגישות מרשתות אחרות (רשתות VPC אחרות או רשתות חיצוניות). אתם יכולים לפרוס נקודות גישה לצרכני שירות ברשתות VPC של אפליקציות אם נקודות הגישה האלה צריכות להיות נגישות רק מתוך רשת ה-VPC של האפליקציה.
אם אתם צריכים לספק גישה לשירותים שמאחורי גישה לשירותים פרטיים, אתם יכולים ליצור VPC של גישה לשירותים שמחובר ל-VPC של מעבר באמצעות HA VPN. לאחר מכן, מחברים את ה-VPC של השירותים המנוהלים ל-VPC של גישת השירותים. רשת HA VPN מאפשרת ניתוב טרנזיטיבי מרשתות אחרות.
העיצוב הוא שילוב של שני סוגי קישוריות:
- NCC: מספק קישוריות בין רשתות VPC למעבר, רשתות VPC של אפליקציות ורשתות VPC לגישה לשירותים שמארחות נקודות קצה של Private Service Connect.
- חיבורים בין רשתות VPC באמצעות HA VPN: מספקים קישוריות מעבר לרשתות משנה של גישה לשירותים פרטיים שמתארחות ברשתות VPC של גישה לשירותים. אין להוסיף את רשתות ה-VPC האלה של הגישה לשירותים כרשתות מסוג spoke של רכזת NCC.
כשמשלבים בין סוגי הקישוריות האלה, חשוב לקחת בחשבון את הנקודות הבאות:
- הפצה מחדש של קישור בין רשתות VPC שכנות ורשתות משנה של עמיתי NCC לניתוב דינמי (ל-VPC של גישה לשירותים דרך HA VPN ולרשתות חיצוניות דרך חיבורים היברידיים)
- שיקולים לגבי ניתוב במספר אזורים
- הפצה של מסלולים דינמיים לקישור בין רשתות VPC שכנות ולקישוריות NCC (מרשת ה-VPC של גישת השירותים דרך HA VPN ומחיבורים חיצוניים דרך חיבורים היברידיים)
בתרשים הבא מוצגת רשת VPC עם גישה לשירותים שמארחת תת-רשתות עם גישה פרטית לשירותים שמחוברות לרשת ה-VPC המרכזית באמצעות HA VPN. בתרשים מוצגות גם רשתות ה-VPC של האפליקציה, רשתות ה-VPC המרכזיות ורשתות ה-VPC עם גישה לשירותים שמארחות נקודות קצה של צרכני Private Service Connect שמחוברות באמצעות NCC:
המבנה שמוצג בתרשים הקודם מכיל את הרכיבים הבאים:
- רשת חיצונית: מרכז נתונים או משרד מרוחק שבו יש ציוד רשת. בדוגמה הזו אנחנו מניחים שהמיקומים מחוברים זה לזה באמצעות רשת חיצונית.
- רשת VPC להעברת נתונים: רשת VPC בפרויקט המרכזי שמקבלת חיבורים מרשתות מקומיות ומספקי ענן אחרים, ומשמשת כנתיב להעברת נתונים מרשתות VPC אחרות לרשתות מקומיות ולרשתות של ספקי ענן.
- רשתות VPC של אפליקציות: פרויקטים ורשתות VPC שמארחים אפליקציות שונות.
- VPC של צרכן לגישה לשירותים פרטיים: רשת VPC שמארחת גישה מרכזית דרך גישה לשירותים פרטיים לשירותים שנדרשים לאפליקציות ברשתות אחרות.
- VPC של שירותים מנוהלים: שירותים שסופקו ומנוהלים על ידי ישויות אחרות, אבל הגישה אליהם אפשרית לאפליקציות שפועלות ברשתות VPC.
- VPC של צרכן ל-Private Service Connect: רשת VPC שמארחת נקודות גישה ל-Private Service Connect לשירותים שמארחים ברשתות אחרות.
משתמשים ב-NCC כדי לחבר את רשתות ה-VPC של האפליקציות לחיבורי ה-VLAN של Cloud Interconnect ולמופעי HA VPN ברשתות ה-VPC של התנועה. הופכים את כל רשתות ה-VPC לרשתות משנה של רכזת ה-NCC, ואת חיבורי ה-VLAN ואת רשתות ה-HA VPN לרשתות משנה היברידיות של אותה רכזת NCC. משתמשים בטופולוגיית הרשת של NCC שמוגדרת כברירת מחדל כדי לאפשר תקשורת בין כל רשתות המשנה (VPC והיברידיות). הטופולוגיה הזו מאפשרת גם תקשורת בין רשתות ה-VPC של האפליקציות שחלות עליהן מדיניות Cloud NGFW. רשתות VPC של שירותים לצרכנים שמחוברות באמצעות HA VPN לא יכולות להיות רשתות משנה של רכזת ה-NCC. אפשר לפרוס נקודות קצה של Private Service Connect ברשתות משנה של VPC ב-NCC, ולא צריך חיבור HA VPN כדי לאפשר מעבר בין רשתות VPC כשמשתמשים ב-NCC.
קישוריות בין רשתות VPC באמצעות קישור בין רשתות VPC שכנות (peering)
כשנקודות גישה לצרכני שירות שפורסמו נפרסות ב-VPC לגישה לשירותים, מומלץ לחבר את ה-VPC של האפליקציה ל-VPC המעבר באמצעות קישור בין רשתות VPC שכנות (peering), ולחבר את ה-VPC לגישה לשירותים ל-VPC המעבר באמצעות HA VPN.
בתכנון הזה, ה-VPC המעברי הוא הרכזת, ואתם פורסים את נקודות הגישה של הצרכן לנקודות קצה פרטיות של שירות ב-VPC של גישה לשירותים.
העיצוב הוא שילוב של שני סוגי קישוריות:
- קישור בין רשתות VPC שכנות (peering): מספק קישוריות בין רשת ה-VPC המרכזית לבין רשתות ה-VPC של האפליקציות.
- חיבורי HA VPN בין רשתות VPC: מספקים קישוריות טרנזיטיבית בין רשתות ה-VPC של הגישה לשירותים לבין רשת ה-VPC של הטרנזיט.
כשמשלבים בין הארכיטקטורות האלה, צריך להתייחס לשיקולים הבאים:
- הפצה מחדש של תת-רשתות של VPC מקושר לניתוב דינמי (ל-VPC של גישה לשירותים דרך HA VPN ולרשתות חיצוניות דרך חיבורים היברידיים)
- שיקולים לגבי ניתוב במספר אזורים
- הפצה של מסלולים דינמיים לקישור בין רשתות VPC שכנות (מרשת ה-VPC של גישת השירותים דרך HA VPN ומחיבורים היברידיים מרשתות חיצוניות)
בתרשים הבא מוצגת רשת VPC עם גישה לשירותים, שמחוברת לרשת ה-VPC המרכזית באמצעות HA VPN, ורשתות ה-VPC של האפליקציות, שמחוברות לרשת ה-VPC המרכזית באמצעות קישור בין רשתות VPC שכנות (peering):
המבנה שמוצג בתרשים הקודם מכיל את הרכיבים הבאים:
- מיקום הלקוח: מרכז נתונים או משרד מרוחק שבו יש לכם ציוד רשת. בדוגמה הזו מניחים שהמיקומים מחוברים זה לזה באמצעות רשת חיצונית.
- אזור מטרופולין: אזור מטרופולין שמכיל אזורי זמינות של קצה אחד או יותר של Cloud Interconnect. Cloud Interconnect מתחבר לרשתות אחרות באזורים מטרופוליטניים כאלה.
- פרויקט מרכז: פרויקט שמארח לפחות רשת VPC אחת שמשמשת כמרכז לרשתות VPC אחרות.
- רשת VPC מרכזית: רשת VPC בפרויקט המרכזי שמקבלת חיבורים מרשתות מקומיות ומספקי ענן אחרים, ומשמשת כנתיב מעבר מרשתות VPC אחרות לרשתות מקומיות ולרשתות של ספקי ענן.
- פרויקטים של מארחי אפליקציות ורשתות VPC: פרויקטים ורשתות VPC שמארחים אפליקציות שונות.
- VPC עם גישה לשירותים: רשת VPC שמארחת גישה מרכזית לשירותים שנדרשים לאפליקציות ברשתות ה-VPC של האפליקציה.
- VPC של שירותים מנוהלים: שירותים שסופקו ומנוהלים על ידי גורמים אחרים, אבל הגישה אליהם אפשרית לאפליקציות שפועלות ברשתות VPC.
בארכיטקטורה של קישור בין רשתות שכנות (peering) של VPC, כשצריך שתהיה תקשורת בין רשתות VPC של אפליקציות, אפשר לחבר את רשתות ה-VPC של האפליקציות כרשתות מסוג Hub & Spoke למרכז קישוריות לרשת. הגישה הזו מספקת קישוריות בין כל רשתות ה-VPC במרכז קישוריות לרשת. אפשר ליצור קבוצות משנה של תקשורת באמצעות שימוש בכמה מרכזי קישוריות לרשת. אפשר להגדיר הגבלות על תקשורת בין נקודות קצה במרכז מסוים באמצעות מדיניות חומת אש.
כדי לאבטח עומסי עבודה בחיבורים בין רשתות VPC של אפליקציות, אפשר להשתמש ב-Cloud Next Generation Firewall.
הוראות מפורטות ותוכניות להגדרת סוגי הקישוריות האלה זמינות במאמר ארכיטקטורת רשת מסוג Hub-and-spoke.
תכנון תשתית DNS
בסביבה היברידית, אפשר להשתמש ב-Cloud DNS או בספק חיצוני (במקום או בספק CSP) כדי לטפל בחיפוש DNS. שרתי DNS חיצוניים הם סמכותיים לאזורי DNS חיצוניים, ו-Cloud DNS הוא סמכותי לאזוריGoogle Cloud . צריך להפעיל העברת DNS דו-כיוונית ביןGoogle Cloud לבין הרשתות החיצוניות, ולהגדיר את חומות האש כך שיאפשרו את התנועה של פענוח ה-DNS.
אם אתם משתמשים ב-VPC משותף לגישה לשירותים, שבו אדמינים של פרויקטים שונים של שירותי אפליקציות יכולים ליצור מופעים של השירותים שלהם, אתם צריכים להשתמש בקישור בין פרויקטים של אזורי DNS. קישור בין פרויקטים מאפשר פילוח והקצאה של מרחב שמות DNS לאדמינים של פרויקטים של שירותים.
במקרה של מעבר, שבו רשתות חיצוניות מתקשרות עם רשתות חיצוניות אחרות דרך Google Cloud, צריך להגדיר את אזורי ה-DNS החיצוניים כך שיעבירו בקשות ישירות אחת לשנייה. רשת Google Cross-Cloud Network תספק קישוריות כדי להשלים את בקשות ה-DNS והתשובות, אבל Google Cloud DNS מעורב בהעברת תנועת פענוח ה-DNS בין אזורים ברשתות חיצוניות. כל כללי חומת האש שנאכפים ברשת Cross-Cloud Network חייבים לאפשר את תעבורת הנתונים של פענוח ה-DNS בין הרשתות החיצוניות.
בתרשים הבא מוצג עיצוב DNS שאפשר להשתמש בו עם כל אחת מהתצורות של קישוריות VPC מסוג Hub-and-Spoke שמוצעות במדריך העיצוב הזה:
בתרשים שלמעלה מוצגים השלבים הבאים בתהליך העיצוב:
- DNS מקומי
מגדירים את שרתי ה-DNS המקומיים כסמכותיים לאזורי DNS מקומיים. מגדירים העברת DNS (לשמות DNS של Google Cloud) על ידי טירגוט כתובת ה-IP של העברת ה-DNS הנכנסת, שנוצרת באמצעות ההגדרה מדיניות שרת נכנסת ב-VPC של הרכזת. ההגדרה הזו מאפשרת לרשת המקומית לפתור שמות Cloud DNS של Google. - VPC מעבר – שרת proxy של DNS לתעבורת נתונים יוצאת
פרסום טווח שרתי ה-proxy של DNS לתעבורת נתונים יוצאת ב-Google [35.199.192.0/19] ברשת המקומית באמצעות Cloud Routers. בקשות DNS יוצאות מ-Google לרשת המקומית מגיעות מטווח כתובות ה-IP הזה. - Transit VPC - Cloud DNS
- מגדירים מדיניות שרת לבקשות נכנסות לבקשות DNS נכנסות משרתים מקומיים.
- הגדרת אזור העברה של Cloud DNS (לשמות DNS מקומיים) שמטרגט שרתי DNS מקומיים.
- VPC עם גישה לשירותים – Cloud DNS
- מגדירים את שירותי ה-DNS peering zone (לשמות DNS מקומיים) ומגדירים את ה-VPC של ה-hub כרשת ה-peer. פענוח ה-DNS של משאבים מקומיים ומשאבי שירות עובר דרך רשת ה-VPC המרכזית.
- מגדירים אזורים פרטיים של DNS של שירותים בפרויקט המארח של השירותים ומצרפים את ה-VPC המשותף של השירותים, ה-VPC המשותף של האפליקציה וה-VPC של הרכזת לאזור. כך כל המארחים (במקום ובכל פרויקטי השירותים) יכולים לפתור את שמות ה-DNS של השירותים.
- פרויקט מארח האפליקציה – Cloud DNS
- מגדירים אזור DNS של אפליקציה בחיבור VPC לצורך הגדרת שמות DNS מקומיים, ומגדירים את ה-VPC של הרכזת כרשת הפירינג. פענוח DNS עבור מארחים מקומיים עובר דרך ה-VPC של רכזת.
- מגדירים אזורים פרטיים של DNS לאפליקציות בפרויקט המארח של האפליקציה ומצרפים את ה-VPC של האפליקציה, את ה-VPC המשותף של השירותים ואת ה-VPC של הרכזת לאזור. ההגדרה הזו מאפשרת לכל המארחים (במקום ובכל פרויקטי השירות) לפתור את שמות ה-DNS של האפליקציה.
מידע נוסף זמין במאמר ארכיטקטורה היברידית באמצעות רשת VPC מרכזית שמחוברת לרשתות VPC מסוג Spoke.
המאמרים הבאים
- תכנון רשת השירותים לאפליקציות של Cross-Cloud Network.
- פריסת קישוריות בין רשתות VPC בענן באמצעות Network Connectivity Center.
- פריסת קישוריות בין רשתות VPC באמצעות קישור בין רשתות שכנות (peering) של VPC.
- מידע נוסף על Google Cloud המוצרים שבהם נעשה שימוש במדריך העיצוב הזה:
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- Victor Moreno | Product Manager, Cloud Networking
- Ghaleb Al-habian | Network Specialist
- Deepak Michael | Networking Specialist Customer Engineer
- Osvaldo Costa | Networking Specialist Customer Engineer
- Jonathan Almaleh | Staff Technical Solutions Consultant
תורמי תוכן אחרים:
- Zach Seils | מומחה לרשתות
- Christopher Abraham | Networking Specialist Customer Engineer
- Emanuele Mazza | מומחה למוצרי רישות
- Aurélien Legrand | Strategic Cloud Engineer
- אריק יו (Eric Yu) | מהנדס לקוחות מומחה לרשתות
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- מארק שלגנהוף | כותב טכני, רשתות
- Marwan Al Shawi | Partner Customer Engineer
- Ammett Williams | Developer Relations Engineer