המסמך הזה הוא חלק מסדרת מדריכי תכנון לרשתות חוצות ענן.
הסדרה מורכבת מהחלקים הבאים:
- 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) אחד או יותר. השילוב של ממשקי הרשת צריך להיות מתוכנן, מוקצה ומוגדר לביצועים, גמישות, פרטיות ואבטחה.
כדי להשיג מודולריות, שימוש חוזר ויכולת להוסיף מכשירי NVA לאבטחה, כדאי למקם חיבורים חיצוניים וניתוב ב-VPC מעבר, שמשמש לאחר מכן כשירות קישוריות משותף לרשתות VPC אחרות. אפשר להגדיר מדיניות ניתוב לחוסן, ליתירות כשל ולבחירת נתיב בין דומיינים פעם אחת ב-VPC המרכזי, ולהשתמש בה ברשתות VPC רבות אחרות.
העיצוב של ממשקי ה-NNI והקישוריות החיצונית ישמש בהמשך לקישוריות פנימית ולרשתות VPC.
בתרשים הבא מוצג VPC מעבר שמשמש כשירות קישוריות משותף לרשתות VPC אחרות, שמקושרות באמצעות קישור בין רשתות VPC שכנות (peering), Network Connectivity Center או HA VPN. כדי לפשט את האיור, מוצג בו ענן וירטואלי פרטי (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 יכולות להשיג רמת זמינות שירות של 99.99%. פרטים נוספים זמינים במאמר בנושא טופולוגיות של HA VPN.
חיבורים פרטיים למרכזי נתונים מקומיים
כדי להתחבר למרכזי נתונים פרטיים, אפשר להשתמש באחת מאפשרויות הקישוריות ההיברידיות הבאות:
- Dedicated Interconnect
- Partner Interconnect
- HA VPN
שיקולי הניתוב של החיבורים האלה דומים לאלה של חיבורים פרטיים לספקי ענן אחרים.
בתרשים הבא מוצגים חיבורים לרשתות מקומיות ואיך נתבים מקומיים יכולים להתחבר ל-Cloud Router דרך מדיניות קישור בין רשתות שכנות (peering):
ניתוב בין דומיינים עם רשתות חיצוניות
כדי לשפר את העמידות ואת קצב העברת הנתונים בין הרשתות, כדאי להשתמש בכמה נתיבים לחיבור הרשתות.
כשמעבירים תנועה בין דומיינים ברשת, צריך לבדוק אותה באמצעות מכשירי אבטחה עם שמירת מצב. לכן נדרשת סימטריה של הזרימה בגבול בין הדומיינים.
ברשתות שמעבירות נתונים בין כמה אזורים, יכול להיות הבדל משמעותי בעלות וברמת איכות השירות של כל רשת. יכול להיות שתחליטו להשתמש ברשתות מסוימות ולא באחרות, בהתאם להבדלים האלה.
מגדירים את מדיניות הניתוב בין דומיינים בהתאם לדרישות שלכם לגבי מעבר בין אזורים, סימטריה של תנועת הגולשים, קצב העברת נתונים ועמידות.
ההגדרה של מדיניות הניתוב בין דומיינים תלויה בפונקציות הזמינות בקצה של כל דומיין. ההגדרה תלויה גם במבנה של הדומיינים הסמוכים מנקודת מבט של מערכת אוטונומית ושל הקצאת כתובות IP (חלוקת רשתות משנה) באזורים שונים. כדי לשפר את יכולת ההתאמה לגודל בלי לחרוג ממגבלות הקידומות במכשירי קצה, מומלץ שתוכנית הקצאת כתובות ה-IP תניב פחות קידומות מצטברות לכל שילוב של אזור ודומיין.
כשמתכננים ניתוב בין אזורים, כדאי לקחת בחשבון את הנקודות הבאות:
- Google Cloud רשתות VPC ו-Cloud Router תומכים בניתוב גלובלי בין אזורים. לספקי CSP אחרים עשויים להיות עננים וירטואליים פרטיים (VPC) אזוריים והיקפים של פרוטוקול Border Gateway Protocol (BGP). לפרטים נוספים, אפשר לעיין במסמכי התיעוד של ספק ה-CSP השני.
- Cloud Router מפרסם מסלולים באופן אוטומטי עם העדפות נתיב שנקבעו מראש על סמך קרבה אזורית. התנהגות הניתוב הזו תלויה במצב הניתוב הדינמי שהוגדר ברשת ה-VPC. יכול להיות שתצטרכו לשנות את ההעדפות האלה כדי לקבל את התנהגות הניתוב שאתם רוצים.
- ספקי CSP שונים תומכים בפונקציות שונות של BGP ושל BFD (זיהוי העברה דו-כיוונית), ול-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 חיצונית. אפשר גם להשתמש ב-NVA מרכזי של NGFW, כמו שמתואר במאמר בנושא אבטחת רשת.
הנתיב העיקרי לחיבור לאינטרנט הוא יעד שער האינטרנט שמוגדר כברירת מחדל בטבלת הניתוב של ה-VPC, שלרוב הוא נתיב ברירת המחדל ברשתות VPC של Google. גם כתובות IP חיצוניות וגם Cloud NAT (Google Cloudשירות NAT מנוהל) דורשים נתיב שמצביע על שער האינטרנט שמוגדר כברירת מחדל ב-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 של ה-spoke. העננים הוירטואליים הפרטיים (VPC) מסוג Hub יכולים לארח אפליקציות, שירותים או שילוב של שניהם.
כדי להשיג ביצועים אופטימליים וגמישות בהתאמה לצרכים באמצעות שירותי הרשת המובנים בענן, צריך לקשר בין רשתות VPC באמצעות NCC, כמו שמתואר במאמר קישוריות בין רשתות VPC באמצעות NCC. NCC מספק את השירותים הבאים:
- גישה טרנזיטיבית לנקודות קצה של Private Service Connect L4 ו-L7 ולשירותים שמשויכים אליהן
- גישה טרנזיטיבית לרשתות מקומיות שנלמדו באמצעות BGP
- היקף רשתות VPC של 250 רשתות לכל רכזת
אם רוצים להוסיף מכשירים וירטואליים לרשת (NVA) כדי להשתמש בהם כחומת אש או לפונקציות אחרות ברשת, צריך להשתמש בקישור בין רשתות VPC שכנות (peering). חומות אש היקפיות יכולות להישאר ברשתות חיצוניות. אם אתם צריכים להוסיף NVA, תוכלו להשתמש בתבנית קישוריות בין רשתות VPC באמצעות קישור בין רשתות שכנות (peering) של VPC כדי לקשר בין רשתות ה-VPC.
צריך להגדיר גם העברת DNS וקישור בין רשתות VPC שכנות (peering) ב-VPC המעבר. פרטים נוספים זמינים בקטע תכנון תשתית ה-DNS.
בקטעים הבאים נדון בעיצובים אפשריים לקישוריות היברידית שתומכים בקישוריות IP בסיסית וגם בפריסות של נקודות גישה ל-API.
קישוריות בין רשתות VPC באמצעות NCC
מומלץ לחבר את כל רשתות ה-VPC של האפליקציות, רשתות ה-VPC של המעבר ורשתות ה-VPC של הגישה לשירותים באמצעות רשתות מסוג Hub-and-Spoke של NCC VPC.
נקודות גישה של צרכני שירות נפרסות ב-VPC של services-access כשהן צריכות להיות נגישות מרשתות אחרות (VPC אחרות או רשתות חיצוניות). אפשר לפרוס נקודות גישה של צרכני שירות ב-VPC של האפליקציה אם צריך להגיע לנקודות הגישה האלה רק מתוך ה-VPC של האפליקציה
אם אתם צריכים לספק גישה לשירותים שמאחורי גישה לשירותים פרטיים, אתם יכולים ליצור VPC של גישה לשירותים שמחובר ל-VPC של מעבר באמצעות HA VPN. לאחר מכן, מחברים את ה-VPC של השירותים המנוהלים ל-VPC של הגישה לשירותים. רשת HA VPN מאפשרת ניתוב טרנזיטיבי מרשתות אחרות.
העיצוב הוא שילוב של שני סוגי קישוריות:
- NCC: מספק קישוריות בין רשתות VPC למעבר, רשתות VPC של אפליקציות ורשתות VPC לגישה לשירותים שמארחות נקודות קצה של Private Service Connect.
- חיבורים בין רשתות VPC באמצעות HA VPN: מספקים קישוריות טרנזיטיבית לרשתות משנה של גישה לשירותים פרטיים שמארחות רשתות VPC של גישה לשירותים. אסור להוסיף את ה-VPC האלה עם גישה לשירותים כ-spoke של ה-hub של 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 attachments של Cloud Interconnect ולמופעי HA VPN ב-VPC של התעבורה. הופכים את כל רשתות ה-VPC לרשתות מסוג Spoke של רכזת NCC, ואת חיבורי ה-VLAN ואת ה-HA VPN הופכים לרשתות מסוג Spoke היברידיות של אותה רכזת NCC. משתמשים בטופולוגיית רשת ברירת המחדל של NCC כדי לאפשר תקשורת בין כל ה-spokes (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.
בארכיטקטורה של קישור בין רשתות VPC שכנות, כשצריך ליצור תקשורת בין רשתות VPC של אפליקציות, אפשר לחבר את רשתות ה-VPC של האפליקציות כרשתות מסוג Hub and Spoke למרכז קישוריות לרשת. הגישה הזו מספקת קישוריות בין כל רשתות ה-VPC במרכז לניהול קישוריות לרשת. אפשר ליצור קבוצות משנה של תקשורת באמצעות כמה מרכזי Network Connectivity Center. אפשר להשיג כל הגבלה על תקשורת בין נקודות קצה בתוך רכזת מסוימת באמצעות מדיניות חומת אש.
כדי לאבטח עומסי עבודה בחיבורים בין רשתות VPC של אפליקציות, אפשר להשתמש ב-Cloud Next Generation Firewall.
הוראות מפורטות ותוכניות להגדרת סוגי הקישוריות האלה זמינות במאמר ארכיטקטורת רשת מסוג Hub-and-spoke.
תכנון תשתית DNS
בסביבה היברידית, חיפוש DNS יכול להתבצע באמצעות Cloud DNS או ספק חיצוני (במקום או CSP). שרתי DNS חיצוניים הם סמכותיים לאזורי DNS חיצוניים, ו-Cloud DNS הוא סמכותי לאזוריGoogle Cloud . צריך להפעיל העברת DNS דו-כיוונית ביןGoogle Cloud לבין הרשתות החיצוניות, וחומות האש צריכות להיות מוגדרות כך שיאפשרו תנועה של פענוח DNS.
אם אתם משתמשים ב-VPC משותף ל-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 (לשמות של Google Cloud DNS), צריך להגדיר טירגוט לכתובת ה-IP של העברת ה-DNS הנכנסת, שנוצרת באמצעות ההגדרה של מדיניות שרת נכנס ב-VPC של הרכזת. ההגדרה הזו מאפשרת לרשת המקומית לפתור שמות Cloud DNS של Google. - Transit VPC - DNS Egress Proxy
פרסום טווח DNS egress proxy של Google 35.199.192.0/19ברשת המקומית באמצעות Cloud Routers. בקשות DNS יוצאות מ-Google לשרתים מקומיים מגיעות מטווח כתובות ה-IP הזה. - Transit VPC - Cloud DNS
- מגדירים מדיניות שרת נכנסת לבקשות DNS נכנסות משרתים מקומיים.
- הגדרת אזור העברה ב-Cloud DNS (לשמות DNS מקומיים) שמטרגט שרתי DNS מקומיים.
- VPC עם גישה לשירותים – Cloud DNS
- מגדירים את ההגדרה של אזור הפירינג של שירותי ה-DNS (לשמות DNS מקומיים) ומגדירים את ה-VPC המרכזי כרשת הפירינג. פענוח DNS למשאבים מקומיים ולמשאבי שירות עובר דרך ה-VPC המרכזי.
- מגדירים אזורים פרטיים של DNS של שירותים בפרויקט המארח של השירותים ומצרפים את ה-VPC המשותף של השירותים, ה-VPC המשותף של האפליקציה וה-VPC המרכזי לאזור. כך כל המארחים (בסביבה המקומית ובכל פרויקטי השירות) יכולים לפתור את שמות ה-DNS של השירותים.
- פרויקט מארח האפליקציה – Cloud DNS
- מגדירים אזור DNS של אפליקציה לצורך הגדרת שמות 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
- אריק יו | Customer Engineer מומחה לרשתות
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- מארק שלגנהוף | כותב טכני, רישות
- Marwan Al Shawi | Partner Customer Engineer
- Ammett Williams | Developer Relations Engineer