כמה פרויקטים ב-Google Cloud, VPN היברידי אחד? החליטו קודם
VPC משותף, עמיתות ורכז קישוריות עונים על שאלות בעלות שונות. בחרו את גבול הרשת לפני שפורסים VPN אחד לכל פרויקט.
כשכמה פרויקטים ב-Google Cloud זקוקים לגישה היברידית, האינסטינקט הוא VPN אחד לכל פרויקט, וזו כמעט תמיד הצורה השגויה. בעלות על הפרויקט וניתוב מנות קשורים אך שונים, והארכיטקטורה השימושית שומרת על הגבולות הניהוליים שאתם צריכים ובמקביל נותנת לקידומות המיועדות נתיב מכוון אחד למשרד או למרכז הנתונים. הבדיקות האלה קובעות איזה מודל רשת אתם באמת רוצים, בסדר שמונע עבודה מחדש. כל אחת מהן יכולה לסיים את הדיון מוקדם, וזו הנקודה.
גבול פרויקט לא מחייב אוטומטית מנהרה משלו.
בדקו אם האובייקט המשותף הוא הרשת
התחילו בשאלה על בעלות, לא על קישוריות: האם בעלות רשת מרכזית יכולה לתמוך בעומסי העבודה האלה? אם התשובה היא כן ולארגון יש תצורה מתאימה, פרויקט מארח מחזיק ב-VPC, בתת-הרשתות ובקישוריות, בעוד פרויקטי שירות מחזיקים במשאבי היישום שלהם. חיבור Cloud VPN אחד באותה רשת משותפת יכול אז לשרת את קידומות עומס העבודה המיועדות, בכפוף למדיניות ניתוב ואבטחה .
היו מדויקים לגבי מה שהשיוך עושה. צירוף פרויקט שירות אינו ממזג את ה-VPC העצמאי הקיים שלו לרשת המארחת, ואינו מעביר כל משאב אוטומטית. צירוף עומס עבודה, הרשאות, מרחב כתובות ו-DNS הם כולם חלק מהארכיטקטורה, לא תוצאה של ההגדרה. קראו את השיוך קודם כשינוי הרשאות ורק אחר כך כשינוי ניתוב, כי צוותים בדרך כלל מגלים את ההבדל במהלך המעבר.
אם בעלות מרכזית אינה מקובלת על הצוותים המעורבים, עצרו כאן והתייחסו לשאר כאל תכנון עמיתות או רכז. כפיית Shared VPC על קבוצה שזקוקה למחזורי חיים עצמאיים של רשת יוצרת בעיה פוליטית עם שם טכני.
בדקו אם VPC עצמאיים יכולים להישאר עצמאיים
העמיתות שומרת על VPC נפרדים, וזו בדיוק הסיבה שהיא מושכת צוותים שרוצים תוכניות כתובות משלהם ובקרת שינויים משלהם. המלכוד הוא שהעמיתות אינה טרנזיטיבית: עמיתות מ-A ל-B ומ-B ל-C אינה יוצרת מעצמה ניתוב מ-A ל-C דרך B. אם שלושה פרויקטים צריכים להגיע ליעד היברידי אחד, אתם צריכים תוכנית חילוף מכוונת ולא שרשרת של עמיתויות.
שיתוף נגישות היברידית תלוי גם בחילוף המתועד של מסלולים מותאמים אישית ובמודעות Cloud Router המיועדות. סטטוס עמיתות פעיל מוכיח שהעמיתות קיימת, לא שהקידומות שכל צד חשובות לו יוצאו אי פעם. בדקו את הטווחים המיוצאים משני צדי העמית, בתצורה שמבצעת את הייצוא, והשוו אותם לכתובות שעומסי העבודה שלכם באמת משתמשים בהן. חוסר התאמה שם הוא הסיבה הנפוצה ביותר לכך שעמיתות נראית תקינה בעוד קידומת נשארת בלתי נגישה.
כתבו את תוכנית הכתובות לפני כל דבר אחר. טווחים לא חופפים, המסלולים אל כל יעד מיועד והמודעות החוזרות הם שלושת החפצים שהמודל הזה חי או מת עליהם.
בדקו אם מודל רכז מתאים לטופולוגיה
לתכנון גדול יותר או מחולק אחרת, סקירת Google Network Connectivity Center מתארת את מודלי הרכז והחישורים. קראו אותה למה שהמהדורה הנוכחית תומכת בו ולא למה שהתרשים מרמז: אילו שילובי VPC והיברידיים, אילו משפחות מסלולים ואילו מדיניות כל סוג חישור מאפשר.
בדקו את משפחת הכתובות במפורש. דוגמאות תכנון ברוב המדריכים, כולל זה, עוסקות ב-IPv4, ותכונה שקיימת לסוג חישור אחד אינה חלה אוטומטית ללא שינוי על אחר. אם הסביבה שלכם היא דו-ערימית, השאלה הזו שייכת לבחירת המודל, לא להגירה מאוחרת.
הטבלה שלמטה היא התמצית של שלושת המודלים והשאלה שמכריעה כל אחד.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
בדקו מה הניתוב לא מעניק
חילוף מסלולים אינו מתן אמון גורפת. פתרון DNS, הרשאת חומת אש והרשאת יישום נשארים באחריותם שלהם, וכל אחד מהם מוגדר בידי בעלים אחרים ברוב הארגונים. תכנון שמניח שנגישות מרמזת על הרשאה יעבור את מבחן הקישוריות שלו וייפול בסקירת האבטחה.
אשרו גם את סיפור ה-DNS לכל מודל, כי סידורי האזור וההעברה נבדלים בין רשת משותפת לרשתות עם עמיתות. שמות פרטיים שנפתרים בפרויקט אחד אינם עוקבים אחר מסלול לאחר.
תעדו את ההחלטה ואת הבעלים שלה
רכזו היכן שהארגון רוצה בעלים משותף לרשת; שמרו VPC נפרדים היכן שמחזור החיים או המדיניות דורשים זאת. אחר כך בחרו בקשר קישוריות נתמך ורשמו איזה בחרתם, מי מחזיק ברשת המשותפת ומה כל פרויקט רשאי לפרסם.
ספירת פרויקטים וקניית VPN אחד לכל אחד אינה תחליף לאותה החלטת בעלות. זו אותה החלטה, שנעשתה מאוחר יותר, בידי מי שיורש את החשבון ואת טבלת הניתוב.