כשמעצבים את אזור הנחיתה, צריך לבחור עיצוב רשת שמתאים לארגון. במסמך הזה מתוארים ארבעה עיצובים נפוצים של רשתות, והוא עוזר לכם לבחור את האפשרות שהכי מתאימה לדרישות של הארגון שלכם, ולהעדפה של הארגון שלכם לשליטה מרכזית או לשליטה מבוזרת. המאמר מיועד למהנדסי רשת, לארכיטקטים ולמומחים טכניים שמעורבים ביצירת עיצוב הרשת לאזור הנחיתה של הארגון.
המאמר הזה הוא חלק מסדרה בנושא אזורי נחיתה.
בחירת עיצוב הרשת
עיצוב הרשת שתבחרו תלוי בעיקר בגורמים הבאים:
- שליטה מרכזית או מבוזרת: בהתאם להעדפות של הארגון, צריך לבחור אחת מהאפשרויות הבאות:
- שליטה מרכזית ברשת, כולל הקצאת כתובות IP, ניתוב וחומת אש בין עומסי עבודה שונים.
- להעניק לצוותים אוטונומיה רבה יותר בהפעלת הסביבות שלהם ובבניית רכיבי רשת בתוך הסביבות שלהם בעצמם.
- אפשרויות קישוריות לענן היברידי או לרשתות מקומיות: כל תכנוני הרשת שמוסברים במסמך הזה מספקים גישה מסביבות מקומיות לסביבות ענן באמצעות Cloud VPN או Cloud Interconnect. עם זאת, בחלק מהעיצובים צריך להגדיר כמה חיבורים במקביל, ובאחרים משתמשים באותו חיבור לכל עומסי העבודה.
- דרישות אבטחה: יכול להיות שהארגון שלכם ידרוש שהתנועה בין עומסי עבודה שונים ב- Google Cloud תעבור דרך מכשירי רשת מרכזיים כמו חומות אש מהדור הבא (NGFW). המגבלה הזו משפיעה על התכנון של רשת הענן הווירטואלי הפרטי (VPC).
- יכולת הרחבה: יכול להיות שעיצובים מסוימים יתאימו לארגון שלכם יותר מאחרים, בהתאם למספר עומסי העבודה שאתם רוצים לפרוס, ולמספר המכונות הווירטואליות (VM), מאזני העומסים הפנימיים ומשאבים אחרים שהם יצרכו.
נקודות להחלטה בתכנון רשת
בתרשים הזרימה הבא מוצגות ההחלטות שצריך לקבל כדי לבחור את עיצוב הרשת הטוב ביותר לארגון.
התרשים שלמעלה יעזור לכם לענות על השאלות הבאות:
- האם נדרשת בדיקה של שכבה 7 באמצעות מכשירי רשת בין עומסי עבודה שונים ב-Google Cloud?
- אם כן, כדאי לעיין במאמר בנושא טופולוגיית Hub-and-spoke עם מכשירים מרכזיים.
- אם לא, ממשיכים לשאלה הבאה.
- האם הרבה מעומסי העבודה שלכם דורשים קישוריות מקומית?
- אם כן, עוברים לנקודת ההחלטה 4.
- אם לא, ממשיכים לשאלה הבאה.
- האם עומסי העבודה שלכם יכולים לתקשר באמצעות נקודות קצה פרטיות במודל של בעלים של שירות מנוהל וצרכן?
- אם כן, כדאי לעיין במאמר חשיפת שירותים במודל צרכן-ספק באמצעות Private Service Connect.
- אם לא, ממשיכים לשאלה הבאה.
- רוצה לנהל את חומת האש והניתוב באופן מרכזי?
- אם כן, כדאי לעיין במאמר בנושא רשת VPC משותפת לכל סביבה.
- אם לא, אפשר לעיין במאמר בנושא טופולוגיית Hub-and-spoke ללא מכשירים.
התרשים הזה נועד לעזור לכם לקבל החלטה, אבל לעיתים קרובות יכול להיות שכמה עיצובים יתאימו לארגון שלכם. במקרים כאלה, מומלץ לבחור את העיצוב שהכי מתאים לתרחיש השימוש שלכם.
אפשרויות לעיצוב הרשת
בקטעים הבאים מתוארות ארבע אפשרויות עיצוב נפוצות. אנחנו ממליצים להשתמש באפשרות 1 ברוב תרחישי השימוש. העיצובים האחרים שמוזכרים בסעיף הזה הם חלופות שמתאימות לדרישות ספציפיות של ארגונים במקרים חריגים.
יכול להיות שהרשת שהכי מתאימה לתרחיש השימוש שלכם היא רשת שמשלבת אלמנטים מכמה אפשרויות עיצוב שמוסברות בקטע הזה. לדוגמה, אפשר להשתמש ברשתות VPC משותפות בטופולוגיות של רשתות מרכזיות עם רשתות משנה כדי לשפר את שיתוף הפעולה, את השליטה המרכזית ולהגביל את מספר רשתות המשנה של ה-VPC. לחלופין, אפשר לתכנן את רוב עומסי העבודה בטופולוגיה של VPC משותף, אבל לבודד מספר קטן של עומסי עבודה ברשתות VPC נפרדות שחושפות שירותים רק דרך כמה נקודות קצה מוגדרות באמצעות Private Service Connect.
אפשרות 1: רשת VPC משותפת לכל סביבה
אנחנו ממליצים על עיצוב הרשת הזה לרוב תרחישי השימוש. בארכיטקטורה הזו נעשה שימוש ברשתות VPC משותפות נפרדות לכל סביבת פריסה שיש לכם ב-Google Cloud (פיתוח, בדיקה וייצור). העיצוב הזה מאפשר לכם לנהל באופן מרכזי משאבי רשת ברשת משותפת, ומספק בידוד רשת בין הסביבות השונות.
כדאי להשתמש בעיצוב הזה אם מתקיים אחד מהתנאים הבאים:
- אתם רוצים שליטה מרכזית על חומת האש ועל כללי הניתוב.
- אתם צריכים תשתית פשוטה וניתנת להרחבה.
- אתם צריכים ניהול מרכזי של מרחב כתובות ה-IP.
לא מומלץ להשתמש בעיצוב הזה אם מתקיים אחד מהתנאים הבאים:
- אתם רוצים שצוותי הפיתוח ייהנו מאוטונומיה מלאה, כולל היכולת לנהל את כללי חומת האש, הניתוב והפירינג שלהם לרשתות של צוותים אחרים.
- אתם צריכים בדיקה של Layer 7 באמצעות מכשירי NGFW.
התרשים הבא מציג הטמעה לדוגמה של העיצוב הזה.
בתרשים שלמעלה מוצגים:
- הרשת המקומית מפוזרת בשני מיקומים גיאוגרפיים.
- הרשת המקומית מתחברת דרך מופעים מיותרים של Cloud Interconnect לשתי רשתות VPC משותפות נפרדות, אחת לסביבת הייצור ואחת לסביבת הפיתוח.
- סביבות הייצור והפיתוח מחוברות לשני מופעי Cloud Interconnect עם קבצים מצורפים שונים של VLAN.
- לכל VPC משותף יש פרויקטים של שירותים שמארחים את עומסי העבודה.
- כללי חומת האש מנוהלים באופן מרכזי בפרויקט המארח.
- לסביבת הפיתוח יש את אותו מבנה VPC כמו לסביבת הייצור.
כברירת מחדל, תנועה מסביבה אחת לא יכולה להגיע לסביבה אחרת. עם זאת, אם עומסי עבודה ספציפיים צריכים לתקשר זה עם זה, אפשר לאפשר העברת נתונים דרך ערוצים מבוקרים בפריסה מקומית, או לשתף נתונים בין אפליקציות באמצעות Google Cloud שירותים כמו Cloud Storage או Pub/Sub. אנחנו ממליצים להימנע מחיבור ישיר של סביבות נפרדות באמצעות VPC Network Peering, כי זה מגדיל את הסיכון לערבוב נתונים בין הסביבות בטעות. שימוש בקישור בין רשתות VPC שכנות (peering) בין סביבות גדולות גם מגדיל את הסיכון להגעה למכסות של VPC בנוגע לקישור בין רשתות שכנות ולקבוצות של קישור בין רשתות שכנות.
למידע נוסף, קראו את המאמרים הבאים:
- סקירה כללית של VPC משותף
- ארכיטקטורת VPC משותף במדריך לשימוש ב-Enterprise Foundations
- דוגמאות לארכיטקטורות בשיטות מומלצות לתכנון VPC
- שלב הרשת בדוגמה של Terraform Foundation באמצעות Cloud Foundation Toolkit
כדי להטמיע את אפשרות התכנון הזו, אפשר לעיין במאמר יצירת אפשרות 1: רשת VPC משותפת לכל סביבה.
אפשרות 2: טופולוגיית Hub-and-spoke עם מכשירים מרכזיים
העיצוב של הרשת הזו מבוסס על טופולוגיית רכזת וחישורים. רשת VPC מרכזית מכילה קבוצה של מכונות וירטואליות של מכשירים, כמו NGFW, שמחוברות לרשתות VPC מסוג Spoke שמכילות את עומסי העבודה. התעבורה בין עומסי העבודה, רשתות מקומיות או האינטרנט מנותבת דרך מכונות וירטואליות של מכשירים לבדיקה ולסינון.
כדאי להשתמש בעיצוב הזה אם מתקיים אחד מהתנאים הבאים:
- אתם צריכים בדיקה בשכבה 7 בין עומסי עבודה או אפליקציות שונים.
- יש לכם הנחיה ארגונית שמציינת את ספק מכשיר האבטחה לכל התנועה.
לא מומלץ להשתמש בעיצוב הזה אם מתקיים אחד מהתנאים הבאים:
- ברוב עומסי העבודה לא נדרש פיקוח על שכבה 7.
- אתם רוצים שעומסי העבודה ב- Google Cloud לא יתקשרו בכלל אחד עם השני.
- בדיקה בשכבה 7 נדרשת רק לתעבורה שיוצאת לרשתות מקומיות.
בתרשים הבא מוצגת הטמעה לדוגמה של התבנית הזו.
בתרשים שלמעלה מוצגים:
- סביבת ייצור שכוללת רשת VPC מרכזית וכמה רשתות VPC מסוג spoke שמכילות את עומסי העבודה.
- רשתות ה-VPC מסוג spoke מקושרות לרשת ה-VPC מסוג hub באמצעות קישור בין רשתות VPC שכנות (peering).
- ברשת ה-VPC של ה-Hub יש כמה מופעים של מכשיר וירטואלי בקבוצת מופעי מכונה מנוהלים. תעבורה לקבוצת מופעי מכונה מנוהלים עוברת דרך מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
- רשתות ה-VPC מסוג Spoke מתקשרות זו עם זו באמצעות מכשירים וירטואליים, באמצעות מסלולים סטטיים עם מאזן העומסים הפנימי בתור הצעד הבא.
- Cloud Interconnect מחבר את רשתות ה-VPC של התעבורה למיקומים מקומיים.
- רשתות מקומיות מחוברות דרך אותם חיבורי Cloud Interconnect באמצעות קבצים מצורפים נפרדים של VLAN.
- רשתות ה-VPC של המעבר מחוברות לממשק רשת נפרד במכשירים הווירטואליים, וכך אפשר לבדוק ולסנן את כל התנועה אל הרשתות האלה וממנה באמצעות המכשיר.
- לסביבת הפיתוח יש את אותו מבנה VPC כמו לסביבת הייצור.
- ההגדרה הזו לא משתמשת בתרגום כתובות רשת של המקור (SNAT). לא נדרש SNAT כי Google Cloud משתמש בגיבוב סימטרי. מידע נוסף זמין במאמר בנושא גיבוב סימטרי.
כברירת מחדל, תנועה מרשת spoke אחת לא יכולה להגיע לרשת spoke אחרת. עם זאת, אם עומסי עבודה ספציפיים צריכים לתקשר זה עם זה, אפשר להגדיר קישור ישיר בין רשתות ה-spoke באמצעות קישור בין רשתות VPC שכנות (peering), או לשתף נתונים בין אפליקציות באמצעות שירותים כמו Cloud Storage או Pub/Sub. Google Cloud
כדי לשמור על זמן אחזור נמוך כשהמכשיר מתקשר בין עומסי עבודה, המכשיר צריך להיות באותו אזור כמו עומסי העבודה. אם אתם משתמשים בכמה אזורים בפריסת הענן, יכול להיות שיהיה לכם סט אחד של מכשירים ו-VPC אחד של רכזת לכל סביבה בכל אזור. אפשר גם להשתמש בתגי רשת עם מסלולים כדי שכל המופעים יתקשרו עם המכשיר הקרוב ביותר.
כללי חומת אש יכולים להגביל את הקישוריות ברשתות VPC מסוג Spoke שמכילות עומסי עבודה. לרוב, הצוותים שמנהלים את עומסי העבודה מנהלים גם את כללי חומת האש האלה. לגבי מדיניות מרכזית, אפשר להשתמש בכללי מדיניות היררכיים של חומת אש. אם אתם רוצים שלצוות רשת מרכזי יהיה שליטה מלאה בכללי חומת האש, כדאי לפרוס את הכללים האלה באופן מרכזי בכל רשתות ה-VPC באמצעות גישת GitOps. במקרה כזה, כדאי להגביל את הרשאות ה-IAM רק לאדמינים שיכולים לשנות את כללי חומת האש. רשתות VPC מסוג Spoke יכולות להיות גם רשתות VPC משותפות אם כמה צוותים מבצעים פריסה ברשתות ה-Spoke.
בארכיטקטורה הזו, מומלץ להשתמש בקישור בין רשתות שכנות (peering) של VPC כדי לקשר בין רשת ה-VPC המרכזית לבין רשתות ה-VPC המשניות, כי כך מתווספת מורכבות מינימלית. עם זאת, המספר המקסימלי של רכזות מוגבל על ידי הגורמים הבאים:
- המגבלה על חיבורי VPC Network Peering מרשת VPC אחת.
- מגבלות של קבוצות שירותי Peering, כמו המספר המקסימלי של כללי העברה לאיזון עומסים פנימי של TCP/UDP לכל קבוצת שירותי Peering.
אם אתם צופים שתגיעו למגבלות האלה, אתם יכולים לחבר את רשתות ה-spoke באמצעות Cloud VPN. השימוש ב-Cloud VPN מוסיף עלות ומורכבות, ולכל מנהרת Cloud VPN יש מגבלת רוחב פס.
למידע נוסף, קראו את המאמרים הבאים:
- ארכיטקטורת Hub and Spoke של מעברות ב-Enterprise Foundations Guide
- Hub and spoke with Network Virtual Appliance (NVA) as part of the Fabric FAST framework
- מודול של Terraform לטרנזיטיביות של רשתות מסוג hub-and-spoke כחלק מהבסיס לדוגמה
כדי ליישם את אפשרות העיצוב הזו, אפשר לעיין במאמר יצירת אפשרות 2: טופולוגיית Hub-and-spoke עם מכשירים מרכזיים.
אפשרות 3: טופולוגיית Hub-and-spoke ללא מכשירים
העיצוב הזה של הרשת משתמש גם בטופולוגיה של רכזת וחישורים, עם רשת VPC של רכזת שמתחברת לרשתות מקומיות ורשתות VPC של חישורים שמכילות את עומסי העבודה. מאחר שקישור בין רשתות VPC שכנות הוא לא טרנזיטיבי, רשתות מסוג spoke לא יכולות לתקשר ביניהן ישירות.
כדאי להשתמש בעיצוב הזה אם מתקיים אחד מהתנאים הבאים:
- אתם רוצים שעומסי עבודה או סביבות ב- Google Cloud לא יתקשרו זה עם זה בכלל באמצעות כתובות IP פנימיות, אבל כן רוצים שהם ישתפו קישוריות מקומית.
- אתם רוצים לתת לצוותים אוטונומיה בניהול חומת האש והכללים שלהם לניתוב תנועה.
לא מומלץ להשתמש בעיצוב הזה אם מתקיים אחד מהתנאים הבאים:
- אתם דורשים בדיקה בשכבה 7 בין עומסי עבודה.
- אתם רוצים לנהל באופן מרכזי את כללי הניתוב וחומת האש.
- אתם צריכים תקשורת משירותים מקומיים לשירותים מנוהלים שמחוברים לרשתות המשנה דרך קישור בין רשתות VPC שכנות אחרות, כי קישור בין רשתות VPC שכנות הוא לא טרנזיטיבי.
התרשים הבא מציג הטמעה לדוגמה של העיצוב הזה.
בתרשים שלמעלה מוצגים:
- סביבת ייצור שכוללת רשת VPC מרכזית וכמה רשתות VPC מסוג spoke שמכילות את עומסי העבודה.
- רשתות ה-VPC מסוג spoke מקושרות לרשת ה-VPC מסוג hub באמצעות קישור בין רשתות VPC שכנות (peering).
- הקישוריות למיקומים מקומיים עוברת דרך חיבורי Cloud Interconnect ברשת ה-VPC של הרכזת.
- רשתות מקומיות מחוברות דרך מופעי Cloud Interconnect באמצעות קבצים מצורפים נפרדים של VLAN.
- לסביבת הפיתוח יש את אותו מבנה VPC כמו לסביבת הייצור.
כברירת מחדל, תנועה מרשת spoke אחת לא יכולה להגיע לרשת spoke אחרת. עם זאת, אם עומסי עבודה ספציפיים צריכים לתקשר זה עם זה, אפשר להגדיר קישור ישיר בין רשתות ההסתעפות באמצעות קישור בין רשתות VPC שכנות (peering), או לשתף נתונים בין אפליקציות באמצעות Google Cloud שירותים כמו Cloud Storage או Pub/Sub.
עיצוב הרשת הזה משמש לעיתים קרובות בסביבות שבהן צוותים פועלים באופן אוטונומי ואין שליטה מרכזית על חומת האש ועל כללי הניתוב. עם זאת, היקף העיצוב הזה מוגבל בגלל הסיבות הבאות:
המגבלה על חיבורי VPC Network Peering מרשת VPC אחת
מגבלות של קבוצות peering, כמו המספר המקסימלי של כללי העברה למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי לכל קבוצת peering
לכן, בדרך כלל לא משתמשים בעיצוב הזה בארגונים גדולים שיש להם הרבה עומסי עבודה נפרדים ב- Google Cloud.
כחלופה לעיצוב, אפשר להשתמש ב-Cloud VPN במקום בקישור (peering) בין רשתות VPC שכנות. ב-Cloud VPN אפשר להגדיל את מספר ה-spokes, אבל יש מגבלת רוחב פס לכל מנהרה, והמורכבות והעלויות גדלות. כשמשתמשים במסלולים מותאמים אישית לפרסום, Cloud VPN מאפשר גם מעבר בין הרשתות המקומיות בלי שיהיה צורך לחבר ישירות את כל הרשתות המקומיות.
למידע נוסף, קראו את המאמרים הבאים:
- ארכיטקטורת רשת מסוג Hub-and-spoke
- ארכיטקטורת Hub-and-spoke במדריך בנושא יסודות ארגוניים
- Hub and spoke עם VPC Peerings כחלק מ-framework של Fabric FAST
- NCC Hub and spoke כחלק מ- Fabric FAST framework
כדי ליישם את אפשרות העיצוב הזו, אפשר לעיין בקטע יצירת אפשרות 3: טופולוגיה של רכזת וחישורים ללא מכשירים.
אפשרות 4: חשיפת שירותים במודל צרכן-בעלים באמצעות Private Service Connect
בתכנון הרשת הזה, כל צוות או עומס עבודה מקבלים רשת VPC משלהם, שיכולה להיות גם רשת VPC משותפת. כל רשת VPC מנוהלת באופן עצמאי ומשתמשת ב-Private Service Connect כדי לחשוף את כל השירותים שצריך לגשת אליהם מחוץ לרשת ה-VPC.
כדאי להשתמש בעיצוב הזה אם מתקיים אחד מהתנאים הבאים:
- עומסי העבודה מתקשרים זה עם זה ועם הסביבה המקומית רק דרך נקודות קצה מוגדרות.
- אתם רוצים שהצוותים יהיו עצמאיים זה מזה, ויוכלו לנהל את מרחב כתובות ה-IP, חומות האש וכללי הניתוב שלהם.
לא מומלץ להשתמש בעיצוב הזה אם מתקיים אחד מהתנאים הבאים:
- התקשורת בין שירותים ואפליקציות מתבצעת דרך הרבה יציאות או ערוצים שונים, או שהיציאות והערוצים משתנים לעיתים קרובות.
- התקשורת בין עומסי העבודה מתבצעת באמצעות פרוטוקולים שאינם TCP או UDP.
- אתם דורשים בדיקה בשכבה 7 בין עומסי עבודה.
בתרשים הבא מוצגת הטמעה לדוגמה של התבנית הזו.
בתרשים שלמעלה מוצגים:
- עומסי עבודה נפרדים נמצאים בפרויקטים נפרדים וברשתות VPC נפרדות.
- מכונה וירטואלית של לקוח ברשת VPC אחת יכולה להתחבר לעומס עבודה ברשת VPC אחרת דרך נקודת קצה של Private Service Connect.
- נקודת הקצה מצורפת ל-Service Attachment ברשת ה-VPC שבה נמצא השירות. צירוף השירות יכול להיות באזור אחר מנקודת הקצה אם נקודת הקצה מוגדרת לגישה גלובלית.
- קובץ מצורף של שירות מתחבר לעומס העבודה באמצעות Cloud Load Balancing.
- לקוחות ב-VPC של עומס העבודה יכולים להגיע לעומסי עבודה שנמצאים במקום, באופן הבא:
- נקודת הקצה מחוברת לצירוף שירות ברשת VPC למעבר.
- קובץ מצורף של שירות מחובר לרשת המקומית באמצעות Cloud Interconnect.
- מאזן עומסים של אפליקציות (ALB) פנימי מצורף לצירוף השירות ומשתמש בקבוצה של נקודות קצה (endpoint) ברשת היברידית כדי לאזן את עומס התנועה בין נקודות הקצה שנמצאות בפריסה מקומית.
- לקוחות מקומיים יכולים גם לגשת לנקודות קצה ברשת ה-VPC של התנועה החולפת, שמתחברות לצירופי שירות ברשתות ה-VPC של עומס העבודה.
למידע נוסף, קראו את המאמרים הבאים:
כדי להטמיע את אפשרות התכנון הזו, אפשר לעיין במאמר יצירת אפשרות 4: חשיפת שירותים במודל צרכן-יצרן באמצעות Private Service Connect.
שיטות מומלצות לפריסת רשת
אחרי שבוחרים את עיצוב הרשת שהכי מתאים לתרחיש השימוש, מומלץ ליישם את השיטות המומלצות הבאות:
- שימוש ברשתות VPC בהתאמה אישית ומחיקת רשת ברירת המחדל כדי לקבל שליטה טובה יותר בכתובות ה-IP של הרשת.
הגבלת גישה חיצונית באמצעות Cloud NAT למשאבים שזקוקים לגישה לאינטרנט, וצמצום השימוש בכתובות IP ציבוריות למשאבים שאפשר לגשת אליהם באמצעות Cloud Load Balancing. מידע נוסף זמין במאמר בנושא חלופות לשימוש בכתובת IP חיצונית.
אם אתם משתמשים ב-Cloud Interconnect, חשוב לוודא שאתם פועלים לפי הטופולוגיות המומלצות עבור אפליקציות לא קריטיות או אפליקציות ברמת הייצור. להשתמש בחיבורים מיותרים כדי לעמוד בהסכם רמת השירות (SLA) של השירות. לחלופין, אפשר לחבר את Google Cloud לרשתות מקומיות באמצעות Cloud VPN.
אפשר לאכוף את המדיניות שמוצגת במאמר בנושא הגבלת גישה חיצונית באמצעות מדיניות ארגונית כדי להגביל גישה ישירה לאינטרנט מ-VPC.
אפשר להשתמש במדיניות חומת אש היררכית כדי להחיל מדיניות חומת אש באופן עקבי על הארגון או על תיקיות.
כדאי לפעול לפי השיטות המומלצות ל-DNS כדי להגדיר DNS היברידי בין הרשת המקומית לבין Google Cloud.
מידע נוסף זמין במאמר שיטות מומלצות ודוגמאות לארכיטקטורות לתכנון VPC.
המאמרים הבאים
- הטמעה של תכנון הרשת באזור הנחיתה ב-Google Cloud
- בחירת אבטחה ל Google Cloud אזור הנחיתה (המסמך הבא בסדרה).
- שיטות מומלצות לתכנון רשתות VPC
- מידע נוסף על Private Service Connect