המסמך הזה הוא חלק מסדרת מדריכי עיצוב לרשתות חוצות-ענן.
הסדרה מורכבת מהחלקים הבאים:
- Cross-Cloud Network לאפליקציות מבוזרות
- פילוח רשת וקישוריות לאפליקציות מבוזרות ב-Cross-Cloud Network
- רשת שירותים לאפליקציות מבוזרות ב-Cross-Cloud Network (המסמך הזה)
- אבטחת רשת לאפליקציות מבוזרות ב-Cross-Cloud Network
במאמר הזה מוסבר איך להרכיב אפליקציה מתוך קבוצה של שירותי רכיבים שנבחרו או נוצרו. מומלץ לקרוא את כל המסמך לפני שמבצעים את השלבים.
במסמך הזה מפורטות ההחלטות הבאות:
- אם אתם יוצרים את השירות בעצמכם או משתמשים בשירות של צד שלישי
- האם השירות זמין ברמה הגלובלית או האזורית
- אם נעשה שימוש בשירות משרתים מקומיים, מעננים אחרים או מאף אחד מהם
- האם אתם ניגשים לנקודת הקצה של השירות דרך VPC של שירותים משותפים או מפזרים את נקודות הקצה דרך כל רשתות ה-VPC הרלוונטיות של האפליקציה
במסמך הזה מפורטים השלבים הבאים:
- החלטה אם האפליקציה היא גלובלית או אזורית
- בחירה בשירותים מנוהלים של צד שלישי או יצירה ופרסום של שירותים משלכם
- הגדרת גישה פרטית לנקודות הקצה של השירות באמצעות מצב משותף או ייעודי
- הרכבת השירותים באפליקציות כך שיתאימו לאב-טיפוס גלובלי או אזורי
מפתחים מגדירים את שכבת הרשת של השירות עבור Cross-Cloud Network. בשלב הזה, האדמינים כבר תכננו שכבת קישוריות לרשת חוצת-ענן, שמאפשרת גמישות באפשרויות של רשת השירותים שמתוארות במסמך הזה. במקרים מסוימים, יש אילוצים שנובעים ממעבר מוגבל בין רשתות VPC. אנחנו מתארים את המגבלות האלה כשהן יכולות להשפיע על החלטות עיצוביות.
החלטה אם האפליקציה היא אזורית או גלובלית
קובעים אם הלקוחות של האפליקציה שאתם יוצרים צריכים ארכיטיפ פריסה אזורי או גלובלי. כדי להשיג חוסן אזורי, אפשר לפזר עומסים בין האזורים של אזור מסוים. כדי להשיג חוסן גלובלי, אפשר לפזר את העומסים בין האזורים.
כשבוחרים ארכיטיפ, כדאי להביא בחשבון את הגורמים הבאים:
- דרישות הזמינות של האפליקציה
- המיקום שבו נעשה שימוש באפליקציה
- עלות
פרטים נוספים מופיעים במאמר בנושא Google Cloud ארכיטיפים של פריסה.
במדריך הזה מוסבר איך לתמוך בארכיטיפים הבאים של פריסות:
באפליקציה מבוזרת חוצת-עננים, שירותים שונים של האפליקציה יכולים להיות מסופקים מספקי שירותי ענן (CSP) שונים או ממרכזי נתונים פרטיים. כדי להבטיח מבנה עקבי של עמידות, כדאי להציב שירותים שמתארחים אצל ספקי CSP שונים במרכזי נתונים של ספקי CSP שנמצאים קרוב זה לזה מבחינה גיאוגרפית.
בתרשים הבא מוצג מחסנית יישומים גלובלית שמפוזרת בעננים, ושירותי יישומים שונים נפרסים אצל ספקי CSP שונים. לכל שירות אפליקציה גלובלי יש מופעי עומס עבודה באזורים שונים של אותו ספק CSP.
הגדרה של שירותי אפליקציות וגישה אליהם
כדי להרכיב את האפליקציה, אפשר להשתמש בשירותים מנוהלים קיימים של צד שלישי, ליצור ולארח שירותי אפליקציה משלכם או להשתמש בשילוב של שתי האפשרויות.
שימוש בשירותים מנוהלים קיימים של צד שלישי
קובעים באילו שירותים מנוהלים של צד שלישי אפשר להשתמש באפליקציה. קובעים אילו מהם בנויים כשירותים אזוריים או כשירותים גלובליים. בנוסף, צריך לבדוק אילו אפשרויות גישה פרטית נתמכות בכל שירות.
אחרי שתדעו באילו שירותים מנוהלים אתם יכולים להשתמש, תוכלו לקבוע אילו שירותים אתם צריכים ליצור.
יצירה וגישה לשירותי אפליקציות
כל שירות מתארח על ידי מופע עומס עבודה אחד או יותר שאפשר לגשת אליו כנקודת קצה אחת או כקבוצה של נקודות קצה.
בתרשים הבא מוצג הדפוס הכללי של שירות אפליקציה. שירות האפליקציה נפרס על פני אוסף של מופעי עומס עבודה. (במקרה הזה, מופע של עומס עבודה יכול להיות מכונה וירטואלית של Compute Engine, אשכול של Google Kubernetes Engine (GKE) או קצה עורפי אחר שמריץ קוד). מופעי עומס העבודה מאורגנים כקבוצה של שרתי בק-אנד שמשויכים למאזן עומסים.
התרשים הבא מציג מאזן עומסים גנרי עם קבוצה של קצוות עורפיים.
כדי להשיג את חלוקת העומס שנבחרה וכדי להפוך את המעבר לגיבוי אוטומטי, קבוצות נקודות הקצה האלה משתמשות במאזן עומסים של חזית האתר. באמצעות קבוצות מנוהלות של מופעי מכונה (MIG), אתם יכולים להגדיל או להקטין את הקיבולת של השירות באופן גמיש על ידי שינוי אוטומטי של קנה המידה של נקודות הקצה שמרכיבות את ה-backend של מאזן העומסים. בנוסף, בהתאם לדרישות של שירות האפליקציה, מאזן העומסים יכול לספק גם אימות, סיום TLS ושירותים אחרים שספציפיים לחיבור.
קביעת היקף השירות – אזורי או גלובלי
מחליטים אם השירות שלכם צריך תמיכה בחוסן אזורי או גלובלי, ואם הוא יכול לתמוך בהם. אפשר לתכנן שירות תוכנה אזורי לסנכרון במסגרת תקציב השהיה אזורי. שירות אפליקציה גלובלי יכול לתמוך במעבר גיבוי אוטומטי סינכרוני בין צמתים שמפוזרים בין אזורים. אם האפליקציה שלכם היא גלובלית, יכול להיות שתרצו שהשירותים שתומכים בה יהיו גלובליים גם כן. אבל אם השירות שלכם דורש סנכרון בין המופעים שלו כדי לתמוך במעבר לגיבוי בעת כשל, אתם צריכים לקחת בחשבון את זמן האחזור בין האזורים. במצב שלכם, יכול להיות שתצטרכו להסתמך על שירותים אזוריים עם יתירות באותו אזור או באזורים סמוכים, וכך לתמוך בסנכרון עם זמן אחזור נמוך למעבר לגיבוי בעת כשל.
Cloud Load Balancing תומך בנקודות קצה שמארחות בתוך אזור יחיד או שמפוזרות בין אזורים. לכן, אתם יכולים ליצור שכבה גלובלית שפונה ללקוחות, שמדברת עם שכבות שירות גלובליות, אזוריות או היברידיות. חשוב לבחור את פריסות השירות כדי לוודא שמעבר הגיבוי האוטומטי של הרשת הדינמית (או איזון העומסים בין אזורים) תואם למצב החוסן וליכולות של הלוגיקה של האפליקציה.
בתרשים הבא אפשר לראות איך שירות גלובלי שנבנה ממאזני עומסים אזוריים יכול להגיע לשרתי קצה בעורף באזורים אחרים, וכך לספק מעבר אוטומטי לגיבוי (failover) בין אזורים. בדוגמה הזו, הלוגיקה של האפליקציה היא גלובלית והקצה העורפי שנבחר תומך בסנכרון בין אזורים. כל מאזן עומסים שולח בקשות בעיקר לאזור המקומי, אבל יכול לבצע מעבר לגיבוי חלופי לאזורים מרוחקים.
- בק-אנד גלובלי הוא אוסף של בק-אנדים אזוריים שאפשר לגשת אליהם באמצעות מאזן עומסים אחד או יותר.
- למרות שהבק-אנדים הם גלובליים, הקצה הקדמי של כל מאזן עומסים (LB) הוא אזורי.
- בדפוס הארכיטקטורה הזה, מאזני העומסים מפזרים את תעבורת הנתונים בעיקר רק בתוך האזור שלהם, אבל יכולים גם לאזן את תעבורת הנתונים לאזורים אחרים כשהמשאבים באזור המקומי לא זמינים.
- קבוצה של חזיתות של מאזני עומסים אזוריים, שכל אחת מהן נגישה מאזורים אחרים ויכולה להגיע לשרתי בק-אנד באזורים אחרים, יוצרת שירות גלובלי מצטבר.
- כדי להרכיב מחסנית אפליקציות גלובלית, כמו שמתואר במאמר תכנון מחסניות אפליקציות גלובליות, אפשר להשתמש בניתוב DNS ובבדיקות תקינות כדי להשיג יתירות כשל בין אזורים של ממשקי הקצה.
- לממשקי הקצה של מאזן העומסים יש גישה מאזורים אחרים באמצעות גישה גלובלית (לא מוצג בתרשים).
אפשר להשתמש באותו דפוס כדי לכלול שירותים שפורסמו עם מעבר גלובלי לגיבוי. בתרשים הבא מוצג שירות שפורסם ומשתמש בשרתי קצה עורפיים גלובליים.
בתרשים, שימו לב שהשירות שפורסם כולל מעבר גלובלי לגיבוי שהוטמע בסביבת היצרן. הוספת מעבר גלובלי לגיבוי בסביבת הצרכנים מאפשרת עמידות לכשלים אזוריים בתשתית איזון העומסים של הצרכנים. צריך להטמיע יתירות כשל בין אזורים שונים של השירות גם בלוגיקה של אפליקציית השירות וגם בתכנון איזון העומסים של בעלים של שירות מנוהל. יצרני השירותים יכולים להטמיע מנגנונים אחרים.
כדי להחליט באיזה מוצר של Cloud Load Balancing להשתמש, קודם צריך לקבוע באיזה סוג תנועה מאזני העומסים צריכים לטפל. חשוב להקפיד על כללי האצבע הבאים:
- שימוש במאזן עומסים של אפליקציות לתעבורת HTTP(S).
- משתמשים במאזן עומסי רשת מסוג proxy לתנועת TCP שאינה HTTP(S). מאזן העומסים של ה-proxy הזה תומך גם בהעברת עומס של TLS.
- משתמשים במאזן עומסי רשת להעברת סיגנל ללא שינוי כדי לשמור את כתובת ה-IP של מקור הלקוח בכותרת, או כדי לתמוך בפרוטוקולים נוספים כמו UDP, ESP ו-ICMP.
לקבלת הנחיות מפורטות לבחירת מאזן העומסים הטוב ביותר לתרחיש השימוש שלכם, אפשר לעיין במאמר בחירת מאזן עומסים.
שירותים עם קצה עורפי בלי שרת (serverless)
אפשר להגדיר שירות באמצעות קצה עורפי ללא שרת. אפשר לארגן את הקצה העורפי בסביבת הייצור בקצה עורפי של מאזן עומסים בתור NEG ללא שרת. אפשר לפרסם את השירות הזה באמצעות Private Service Connect על ידי יצירת קובץ מצורף לשירות שמשויך לקצה הקדמי של מאזן העומסים של שירות ההפקה. אפשר לצרוך את השירות שפורסם דרך נקודות קצה של Private Service Connect או דרך בק-אנדים של Private Service Connect. אם השירות דורש חיבורים שיוזמו על ידי הספק, אפשר להשתמש במחבר Serverless VPC Access כדי לאפשר לסביבות של Cloud Run, App Engine standard ו-Cloud Run Functions לשלוח חבילות לכתובות IPv4 פנימיות של משאבים ברשת VPC. החיבור לרשת (VPC) מאפליקציית serverless תומך גם בשליחת מנות לרשתות אחרות שמחוברות לרשת ה-VPC שנבחרה.
שיטות לגישה פרטית לשירותים
האפליקציה יכולה לכלול שירותים מנוהלים שסופקו על ידי Google, שירותי צד שלישי שסופקו על ידי ספקים חיצוניים או קבוצות עמיתים בארגון, ושירותים שהצוות שלכם פיתח. יכול להיות שאפשר לגשת לחלק מהשירותים האלה דרך האינטרנט באמצעות כתובות IP ציבוריות. בקטע הזה מתוארות השיטות שבהן אפשר לגשת לשירותים האלה באמצעות הרשת הפרטית. אלה סוגי השירותים שקיימים:
- ממשקי API ציבוריים של Google
- ממשקי API של Google ללא שרת
- שירותים מנוהלים שפורסמו על ידי Google
- שירותים מנוהלים שפורסמו על ידי ספקים ועמיתים
- השירותים שפרסמתם
חשוב לזכור את האפשרויות האלה כשקוראים את הקטעים הבאים. בהתאם לאופן ההקצאה של השירותים, אפשר להשתמש באחת או יותר מהאפשרויות של גישה פרטית שמתוארות כאן.
הארגון (או קבוצה בתוך ארגון) שמפיק, מפרסם ומנהל שירות נקרא בעלים של שירות מנוהל. אתם והאפליקציה שלכם נקראים צרכני השירות.
חלק מהשירותים המנוהלים מתפרסמים באופן בלעדי באמצעות גישה לשירותים פרטיים. העיצובים המומלצים של הרשתות שמפורטים במאמר קישוריות פנימית ורשתות VPC מתאימים לשירותים שמתפרסמים באמצעות גישה לשירותים פרטיים ו-Private Service Connect.
במאמר אפשרויות גישה פרטיות לשירותים מופיעה סקירה כללית של האפשרויות לגישה פרטית לשירותים.
מומלץ להשתמש ב-Private Service Connect כדי להתחבר לשירותים מנוהלים, כשאפשר. מידע נוסף על דפוסי פריסה של Private Service Connect זמין במאמר דפוסי פריסה של Private Service Connect.
יש שני סוגים של Private Service Connect, ואפשר לפרסם את השירותים השונים בכל אחד מהסוגים:
עומסי עבודה אחרים יכולים לצרוך ישירות שירותים שפורסמו כנקודות קצה של Private Service Connect. השירותים מסתמכים על האימות ועל יכולת ההתאוששות שסופקו על ידי ספק השירות. אם רוצים שליטה נוספת באימות השירות ובחוסן שלו, אפשר להשתמש בשרתי קצה עורפיים של Private Service Connect כדי להוסיף שכבת איזון עומסים לאימות ולחוסן ברשת הצרכן.
בתרשים הבא מוצגים שירותים שאפשר לגשת אליהם דרך נקודות קצה של Private Service Connect:
התרשים מציג את התבנית הבאה:
- נקודת קצה של Private Service Connect נפרסת ב-VPC של הצרכן, וכך השירות המנוהל זמין למכונות וירטואליות ולצמתים של GKE.
- צריך לפרוס את רשת הצרכן ואת רשת היצרן באותו אזור.
בתרשים הקודם מוצגות נקודות קצה כמשאבים אזוריים. אפשר להגיע לנקודות הקצה מאזורים אחרים בגלל גישה גלובלית.
מידע נוסף על תבניות פריסה זמין במאמר תבניות פריסה של Private Service Connect.
בק-אנדים של Private Service Connect משתמשים במאזן עומסים שהוגדר עם בק-אנדים של קבוצת נקודות קצה ברשת (NEG) מסוג Private Service Connect. רשימה של מאזני עומסים נתמכים מופיעה במאמר מידע על קצה עורפי מסוג Private Service Connect.
בק-אנדים של Private Service Connect מאפשרים ליצור את תצורות הבק-אנד הבאות:
- דומיינים ואישורים בבעלות הלקוח לפני שירותים מנוהלים
- מעבר לגיבוי בשליטת הצרכן בין שירותים מנוהלים באזורים שונים
- הגדרת אבטחה מרכזית ובקרת גישה לשירותים מנוהלים
בתרשים הבא, מאזן העומסים הגלובלי משתמש ב-NEG מסוג Private Service Connect כקצה עורפי שיוצר תקשורת עם ספק השירות. לא נדרשת הגדרה נוספת של הרשת, והנתונים מועברים דרך רשת ה-SDN של Google.
רוב השירותים מיועדים לחיבורים שהצרכן יוזם. כששירותים צריכים ליזום חיבורים מהיצרן, משתמשים בממשקי Private Service Connect.
שיקול חשוב כשפורסים גישה לשירותים פרטיים או Private Service Connect הוא טרנזיטיביות. אפשר להגיע לנקודות גישה לצרכן ב-Private Service Connect דרך Network Connectivity Center. אי אפשר להגיע לשירותים שפורסמו דרך חיבור VPC Network Peering לנקודות גישה של צרכנים של Private Service Connect או של גישה לשירותים פרטיים. אם אין מעבר בין רשתות VPC לכל נקודות הגישה של צרכני השירות, המיקום של תת-הרשת או נקודות הקצה של הגישה לשירות בטופולוגיית ה-VPC יקבע אם תכננו את הרשת לפריסת שירות משותפת או ייעודית.
אפשרויות כמו HA VPN ושרתי proxy בניהול הלקוח מספקות שיטות לאפשר תקשורת טרנזיטיבית בין רשתות VPC.
אי אפשר להגיע לנקודות קצה של Private Service Connect דרך קישור בין רשתות VPC שכנות (peering). אם אתם צריכים קישוריות מהסוג הזה, אתם יכולים לפרוס מאזן עומסים פנימי ו-NEG מסוג Private Service Connect כקצה עורפי, כמו שמוצג בתרשים הבא:
אפשר לגשת לממשקי Google APIs באופן פרטי באמצעות נקודות קצה (endpoints) ובק-אנדים של Private Service Connect. באופן כללי, מומלץ להשתמש בנקודות קצה כי יצרן Google API מספק עמידות ואימות מבוסס-אישורים.
יוצרים נקודת קצה של Private Service Connect בכל VPC שצריך לגשת לשירות. מכיוון שכתובת ה-IP של הצרכן היא כתובת IP פרטית גלובלית, נדרשת מיפוי DNS יחיד לכל שירות, גם אם יש מופעים של נקודות קצה בכמה רשתות VPC, כמו שמוצג בתרשים הבא:
הגדרת דפוסי צריכה לשירותים שפורסמו
שירותים שפורסמו יכולים לפעול במגוון מיקומים: ברשת ה-VPC שלכם, ברשת VPC אחרת, במרכז נתונים מקומי או בענן. לא משנה איפה עומס העבודה של השירות פועל, האפליקציה שלכם צורכת את השירותים האלה באמצעות נקודת גישה, כמו אחת מהאפשרויות הבאות:
- כתובת IP ברשת משנה של גישה לשירותים פרטיים
- נקודת קצה של Private Service Connect
- כתובת VIP למאזן עומסים באמצעות קבוצות של נקודות קצה ברשת (NEG) מסוג Private Service Connect
אפשר לשתף את נקודות הגישה לצרכנים בין רשתות שונות, או להקדיש אותן לרשת אחת. מחליטים אם ליצור נקודות גישה משותפות או ייעודיות לצרכנים, בהתאם לשאלה אם הארגון שלכם מאציל את המשימה של יצירת נקודות גישה לשירותים לצרכנים לכל קבוצת אפליקציות, או מנהל את הגישה לשירותים באופן מאוחד.
ניהול הגישה לשירותים כולל את הפעולות הבאות:
- יצירת נקודות הגישה
- פריסת נקודות הגישה ב-VPC של גישת שירותים, שהוא VPC עם סוג הנגישות המתאים
- רישום כתובות ה-IP וכתובות ה-URL של נקודות הגישה של הצרכנים ב-DNS
- ניהול אישורי אבטחה ועמידות של השירות במרחב הצרכני, כשמוסיפים איזון עומסים לפני נקודות הגישה של הצרכן
בארגונים מסוימים, יכול להיות שיהיה כדאי להקצות את ניהול הגישה לשירותים לצוות מרכזי, ובארגונים אחרים, יכול להיות שיהיה מבנה שבו כל צוות של צרכנים או אפליקציות יקבל יותר עצמאות. תוצר לוואי של הפעלה במצב הייעודי הוא שחלק מהאלמנטים משוכפלים. לדוגמה, שירות נרשם עם כמה שמות DNS על ידי כל קבוצת אפליקציות, ומנהל כמה סטים של אישורי TLS.
העיצוב של ה-VPC שמתואר במאמר Network segmentation and connectivity for distributed applications in Cross-Cloud Network מאפשר להגיע לנקודות גישה לשירותים כדי לפרוס אותן במצב משותף או במצב ייעודי. נקודות גישה משותפות לצרכנים נפרסות ב-VPC של גישה לשירות, שאפשר לגשת אליהן מכל VPC אחר או מרשת חיצונית. נקודות גישה ייעודיות לצרכנים נפרסות ב-VPC של האפליקציה, וניתן לגשת אליהן רק ממשאבים בתוך ה-VPC של האפליקציה.
ההבדל העיקרי בין VPC עם גישה לשירות לבין VPC של אפליקציה הוא הקישוריות הטרנזיטיבית של נקודת הגישה לשירות, ש-VPC עם גישה לשירות מאפשר. השימוש ב-VPC לגישה לשירותים לא מוגבל לאירוח נקודות גישה לצרכנים. רשת VPC יכולה לארח משאבי אפליקציות ונקודות גישה משותפות לצרכנים. במקרה כזה, צריך להגדיר את ה-VPC ולטפל בו כ-VPC של שירות.
גישה משותפת לשירותים מנוהלים
לכל שיטות הצריכה של שירותים, כולל Private Service Connect, צריך לבצע את המשימות הבאות:
- פריסת נקודות הגישה של צרכן השירות ב-VPC של השירותים. לרשתות VPC של שירותים יש נגישות טרנזיטיבית לרשתות VPC אחרות.
- אם ה-VPC של גישת השירות מחובר ל-HA VPN, צריך לפרסם את רשת המשנה של נקודת הגישה של הצרכן כפרסום של מסלול מותאם אישית מ-Cloud Router שמבצע Peering לרשתות אחרות דרך HA VPN. במקרה של Google APIs, צריך לפרסם את כתובת ה-IP של המארח של ה-API.
- מעדכנים את הכללים של חומת האש בענן מרובה כדי לאפשר את רשת המשנה של הגישה לשירותים פרטיים.
בנוגע לגישה לשירותים פרטיים, חשוב לוודא שאתם יכולים לעמוד בדרישות הנוספות הבאות:
- ייצוא של נתיבים מותאמים אישית לרשת של הבעלים של השירות המנוהל. למידע נוסף, אפשר לעיין במאמר מארחים מקומיים לא יכולים לתקשר עם הרשת של ספק השירות
- יוצרים כללי חומת אש לתעבורת נתונים נכנסת (ingress) כדי לאפשר לתת-הרשת של הגישה לשירותים פרטיים להיכנס לרשתות ה-VPC של האפליקציה
- יוצרים כללי חומת אש לתעבורת נתונים נכנסת (ingress) כדי לאפשר לתת-הרשת של הגישה לשירותים פרטיים להיכנס לרשת ה-VPC של השירותים
כדי לקבל גישה לשירותים בלי שרת (serverless), צריך לוודא שאתם עומדים בדרישות הבאות:
- מחבר הגישה דורש תת-רשת רגילה ייעודית מסוג /28
- כברירת מחדל, Cloud Router מפרסם תת-רשתות רגילות
- יוצרים כללי חומת אש לתעבורת נתונים נכנסת(ingress) כדי לאפשר גישה לתת-רשת של VPC בתוך רשתות ה-VPC
- עדכון כללי חומת האש בענן מרובה כדי לאפשר את תת-הרשת של מחבר הגישה ל-VPC
- יוצרים כללי חומת אש כדי לאפשר גישה לשירותים פרטיים ברשת המשנה בענן הווירטואלי הפרטי (VPC) של האפליקציה
גישה לשירותים מנוהלים ייעודיים
חשוב לוודא שביצעתם את המשימות הבאות:
- בכל VPC של אפליקציה שנדרשת אליו גישה, פורסים כלל העברה לשירות כדי ליצור נקודת גישה.
- כדי להגדיר גישה לשירותים פרטיים, צריך ליצור כללים של חומת אש לכניסה כדי לאפשר לתת-הרשת של הגישה לשירותים פרטיים להיכנס לרשתות ה-VPC של האפליקציה.
כדי לקבל גישה לשירותים בלי שרת (serverless), צריך לוודא שאתם עומדים בדרישות הבאות:
- מחבר הגישה דורש תת-רשת רגילה ייעודית מסוג /28
- יוצרים כללי חומת אש לתעבורת נתונים נכנסת כדי לאפשר את תת-הרשת של מחבר הגישה ל-VPC בתוך רשתות ה-VPC של האפליקציה
הרכבת מחסנית האפליקציות
בקטע הזה מתואר איך מרכיבים מחסנית אפליקציות אזורית או גלובלית.
תכנון מחסניות אפליקציות אזוריות
כשמיישמים ארכיטיפים של פריסה אזורית או פריסה במספר אזורים, צריך להשתמש במערכות אזוריות של אפליקציות. אפשר לחשוב על סטאקים של אפליקציות אזוריות כעל שרשור של שכבות שירות של אפליקציות אזוריות. לדוגמה, שכבת שירות אינטרנט אזורית שמתקשרת עם שכבת אפליקציה באותו אזור, שבתורה מתקשרת עם שכבת מסד נתונים באותו אזור, היא מחסנית אפליקציות אזורית.
כל שכבת שירות אזורית של אפליקציה משתמשת במאזני עומסים כדי לחלק את התעבורה בין נקודות הקצה של השכבה באותו אזור. המהימנות מושגת על ידי חלוקת משאבי ה-Backend בין שלושה אזורים או יותר באזור.
שכבות של שירותי אפליקציות בספקי CSP אחרים או במרכזי נתונים מקומיים צריכות להיות פרוסות באזורים מקבילים ברשתות החיצוניות. בנוסף, צריך לוודא שהשירותים שפורסמו זמינים באזור של ה-stack. כדי ליישר את סטאק האפליקציות באזור מסוים, כתובות ה-URL של שכבת שירות האפליקציות צריכות להפנות לכתובת ה-IP האזורית הספציפית של הקצה הקדמי של מאזן העומסים. מיפויי ה-DNS האלה רשומים בתחום ה-DNS הרלוונטי לכל שירות אפליקציה.
התרשים הבא מציג מחסנית אזורית עם חוסן פעיל-המתנה:
מופע מלא של מחסנית האפליקציות נפרס בכל אזור במרכזי הנתונים השונים בענן. כשמתרחשת תקלה אזורית באחת משכבות שירות האפליקציה, המערך באזור השני משתלט על המסירה של האפליקציה כולה. המעבר לגיבוי מתבצע בתגובה לניטור מחוץ לפס של שכבות שירות האפליקציה השונות.
כשמדווח על כשל באחת משכבות השירות, הקצה הקדמי של האפליקציה מעוגן מחדש למקבץ הגיבוי. האפליקציה כתובה כך שהיא מפנה לקבוצה של רשומות שמות אזוריות שמשקפות את מחסנית כתובות ה-IP האזורית ב-DNS, כדי שכל שכבה של האפליקציה תשמור על החיבורים שלה באותו אזור.
עיצוב של מחסניות אפליקציות גלובליות
כשמיישמים ארכיטיפ של פריסת אפליקציה גלובלית, כל שכבת שירות של האפליקציה כוללת קצה עורפי בכמה אזורים. הכללת שרתי קצה עורפיים בכמה אזורים מרחיבה את מאגר החוסן של שכבת שירותי האפליקציה מעבר לאזור יחיד, ומאפשרת זיהוי אוטומטי של מעבר לגיבוי (failover) והתכנסות מחדש.
התרשים הבא מציג את מחסנית האפליקציות הגלובלית:
בתרשים הקודם מוצגת אפליקציה גלובלית שמורכבת מהרכיבים הבאים:
- שירותים שפועלים במרכזי נתונים מקומיים עם חזיתות של מאזני עומסים. אפשר להגיע לנקודות הגישה של מאזן העומסים דרך Cloud Interconnect מ-VPC המעבר.
- רשת VPC למעבר מארחת חיבורים היברידיים בין מרכז הנתונים החיצוני לבין רשת ה-VPC של האפליקציה.
- VPC של אפליקציה שמארח את אפליקציית הליבה שפועלת על מופעי עומס עבודה. המופעים של עומסי העבודה האלה נמצאים מאחורי מאזני עומסים. אפשר להגיע למאזני העומסים מכל אזור ברשת, והם יכולים להגיע לשרתי בק-אנד בכל אזור ברשת.
- רשת VPC של שירותים שמארחת נקודות גישה לשירותים שפועלים במיקומים אחרים, כמו רשתות VPC של צד שלישי. אפשר להגיע לנקודות הגישה לשירותים האלה דרך חיבור HA VPN בין ה-VPC של השירות לבין ה-VPC של התעבורה.
- רשתות VPC של בעלים של שירותים מנוהלים שמארחים ארגונים אחרים או את הארגון הראשי, ויישומים שפועלים במיקומים אחרים. השירותים הרלוונטיים נגישים באמצעות בק-אנדים של Private Service Connect שנפרסים כבק-אנדים גלובליים למאזני עומסים אזוריים שמארחים ב-VPC של השירותים. אפשר להגיע למאזני העומסים האזוריים מכל אזור אחר.
אם רוצים שהאפליקציה שנוצרה תהיה נגישה מהאינטרנט, אפשר להוסיף מאזן עומסים חיצוני גלובלי של אפליקציות שמפנה לעומסי העבודה של האפליקציה ב-VPC של האפליקציה (לא מוצג בתרשים).
כדי לתמוך במערך גלובלי של אפליקציות, השתמשנו בקצה עורפי גלובלי לכל שכבת אפליקציה. כך אפשר להתאושש מכשל בכל נקודות הקצה של הבק-אנד באזור אחד. לכל אזור יש חזית אזורית של מאזן עומסים לכל שכבת שירות של אפליקציה. כשמתרחשת יתירות כשל אזורית, אפשר להגיע לחזיתות של מאזן עומסים אזורי פנימי בין אזורים, כי הן משתמשות בגישה גלובלית. מכיוון שערימת האפליקציות היא גלובלית, נעשה שימוש במדיניות ניתוב לפי מיקום גיאוגרפי של DNS כדי לבחור את ממשק הקצה האזורי המתאים ביותר לבקשה או לזרימה מסוימת. במקרה של כשל בחלק הקדמי של האתר, אפשר להשתמש בבדיקות תקינות של DNS כדי להפוך את המעבר מאחד לחלק הקדמי של האתר לאוטומטי.
שירותים שמפורסמים באמצעות בק-אנדים של Private Service Connect נהנים מגישה גלובלית של Private Service Connect. התכונה הזו מאפשרת להגיע לעורף של Private Service Connect מכל אזור, ומפחיתה את השיבושים שנגרמים מכשלים בשכבת שירות האפליקציה. המשמעות היא שאפשר להשתמש בשרתי הקצה של Private Service Connect כשרתי קצה גלובליים, כפי שמתואר במאמר קביעת ההיקף של השירות – אזורי או גלובלי.
מתן גישה פרטית לשירותים שמתארחים ברשתות חיצוניות
יכול להיות שתרצו לפרסם נקודת גישה מקומית לשירות שמארח ברשת אחרת. במקרים כאלה, אפשר להשתמש במאזן עומסים פנימי אזורי בשרתי TCP Proxy באמצעות קבוצות היברידיות של נקודות קצה ברשת (NEG). אפשר ליצור ספק שירותים שמתארח באופן מקומי או בסביבות ענן אחרות שזמינות לצרכני שירותים (לקוחות) ברשת ה-VPC שלכם, כמו שמוצג בתרשים הבא:
אם רוצים להפוך את השירות ההיברידי לזמין ברשת VPC שונה מזו שמארחת את מאזן העומסים, אפשר להשתמש ב-Private Service Connect כדי לפרסם את השירות. אם מציבים שירות מצורף לפני מאזן העומסים הפנימי האזורי של פרוקסי TCP, אפשר לאפשר ללקוחות ברשתות VPC אחרות להגיע לשירותים ההיברידיים שפועלים בארגון או בסביבות ענן אחרות.
בסביבה חוצת-ענן, השימוש ב-NEG היברידי מאפשר תקשורת מאובטחת בין אפליקציות.
כשארגון אחר מפרסם שירות אפליקציה, משתמשים ב-NEG היברידי כדי להרחיב את ההפשטות של הגישה הפרטית לשירות הזה. התרשים הבא ממחיש את התרחיש הזה:
בתרשים שלמעלה, שכבת שירותי האפליקציות מורכבת במלואה ב-CSP הסמוך, שמודגש בחלקים של התרשים שלא מוצגים באפור. מאזני העומסים ההיברידיים משמשים בשילוב עם קבצים מצורפים של שירות Private Service Connect כמנגנון לפרסום שירות האפליקציה החיצונית לשימוש פרטי בתוךGoogle Cloud. מאזני העומסים ההיברידיים עם Hybrid NEG וקבצים מצורפים של שירות Private Service Connect נמצאים ב-VPC שהוא חלק מפרויקט לשירות מנוהל. פרויקט השירות המנוהל בדרך כלל יהיה VPC שונה מ-VPC המעבר, כי הוא נמצא בהיקף הניהולי של הארגון או הפרויקט של הספק, ולכן הוא נפרד משירותי המעבר המשותפים. רשת ה-VPC של היצרן לא צריכה להיות מקושרת באמצעות קישור בין רשתות שכנות (peering) או HA VPN לרשת ה-VPC של הצרכן (שהיא ה-VPC המשותף של השירותים בדיאגרמה).
ריכוז הגישה לשירותים
אפשר לרכז את הגישה לשירות ברשת VPC ולגשת אליו מרשתות אפליקציות אחרות. הדיאגרמה הבאה מציגה את התבנית הנפוצה שמאפשרת ריכוז של נקודות הגישה:
בתרשים הבא מוצגים כל השירותים שאליהם יש גישה מ-VPC ייעודי של שירותים:
כששירותים מופעלים בחזית עם מאזני עומסים של אפליקציות, אפשר לצמצם את מספר מאזני העומסים באמצעות מיפוי כתובות URL כדי לנתב תנועה עבור קצה עורפי שונה של שירותים, במקום להשתמש במאזני עומסים שונים לכל שירות. באופן עקרוני, אפשר ליצור את כל סטאק האפליקציה באמצעות מאזן עומסים של אפליקציות (ALB) אחד, בתוספת קצוות עורפיים של שירותים ומיפויים מתאימים של כתובות URL.
ביישום הזה, צריך להשתמש ב-NEGs היברידיים ברשתות VPC עבור רוב סוגי ה-backend. החריג הוא קצה עורפי או NEG מסוג Private Service Connect, כמו שמתואר במאמר שרשור מפורש של מאזני עומסים Google Cloud שכבה 7 עם Private Service Connect.
השימוש בקבוצות היברידיות של נקודות קצה ברשתות VPC מגיע על חשבון ויתור על תיקון אוטומטי והתאמה אוטומטית של עומס (autoscaling) לשרתי הקצה העורפיים. לשירותים שפורסמו כבר יש מאזן עומסים בדייר של היצרן, שמספק קנה מידה אוטומטי. לכן, תיתקלו במגבלות של קבוצות ה-NEG ההיברידיות רק אם תרכזו את פונקציית איזון העומסים בשכבות שירות שנוצרות באופן מקורי ולא נצרכות מפרסום.
כשמשתמשים בדפוס הזה של רשת שירותים, חשוב לזכור שהשירותים נצרכים דרך שכבה נוספת של איזון עומסים.
אפשר להגיע לנקודות קצה של שירותים ב-Private Service Connect בכל רשתות ה-VPC מסוג spoke ב-NCC.
במצב המרכזי, נוספת שכבה של איזון עומסים בצד הצרכן של השירות. כשמשתמשים במצב הזה, צריך גם לנהל אישורים, חוסן ומיפויי DNS נוספים בפרויקט הצרכן.
שיקולים נוספים
בקטע הזה מפורטים שיקולים לגבי מוצרים ושירותים נפוצים שלא נכללים במפורש במסמך הזה.
שיקולים לגבי מישור הבקרה של GKE
מישור הבקרה של GKE נפרס בפרויקט דייר שמנוהל על ידי Google ומחובר ל-VPC של הלקוח באמצעות קישור בין רשתות VPC שכנות. מכיוון שקישור בין רשתות VPC שכנות הוא לא טרנזיטיבי, אי אפשר ליצור תקשורת ישירה למישור הבקרה באמצעות טופולוגיה של רשתות VPC שכנות מסוג Hub and Spoke.
כשבוחנים אפשרויות עיצוב של GKE, כמו ריכוז או ביזור, גישה ישירה למישור הבקרה ממקורות מרובי עננים היא שיקול חשוב. אם GKE נפרס ב-VPC מרכזי, הגישה למישור הבקרה זמינה בענן ובתוךGoogle Cloud. עם זאת, אם GKE נפרס ברשתות VPC מבוזרות, אי אפשר לתקשר ישירות עם מישור הבקרה. אם הדרישות של ארגון מחייבות גישה למישור הבקרה של GKE בנוסף לאימוץ דפוס העיצוב המבוזר, מנהלי רשת יכולים לפרוס סוכן חיבור שפועל כ-proxy, וכך להתגבר על מגבלת ה-peering הלא טרנזיטיבית למישור הבקרה של GKE.
אבטחה – VPC Service Controls
עבור עומסי עבודה שכוללים מידע אישי רגיש, מומלץ להשתמש ב-VPC Service Controls כדי להגדיר גבולות גזרה לשירות מסביב למשאבי ה-VPC ולשירותים שמנוהלים על ידי Google, ולשלוט בתנועת הנתונים מעבר לגבולות הגזרה. בעזרת VPC Service Controls, אתם יכולים לקבץ פרויקטים ואת הרשת המקומית שלכם למתחם היקפי יחיד שמונע גישה לנתונים דרך שירותים שמנוהלים על ידי Google. אפשר להשתמש בכללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) של VPC Service Controls כדי לאפשר לפרויקטים ולשירותים בגבולות גזרה שונים של שירות לתקשר ביניהם (כולל רשתות VPC שלא נמצאות בתוך גבולות הגזרה).
במאמר שיטות מומלצות לשימוש ב-VPC Service Controls בארגונים ובמאמר Security Foundations Blueprint מפורטות המלצות לארכיטקטורות פריסה, תהליך מקיף לתחילת השימוש ושיטות מומלצות לתפעול.
DNS for APIs/Services
בעלי שירותים יכולים לפרסם שירותים באמצעות Private Service Connect. בעלים של שירות מנוהל יכול להגדיר שם דומיין DNS כדי לשייך אותו לשירות. אם מוגדר שם דומיין וצרכן שירות יוצר נקודת קצה שמכוונת לשירות הזה, Private Service Connect ו-Service Directory יוצרים באופן אוטומטי רשומות DNS לשירות באזור DNS פרטי ברשת ה-VPC של צרכן השירות.
המאמרים הבאים
- עיצוב אבטחת הרשת עבור אפליקציות של Cross-Cloud Network.
- מידע נוסף על 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
- אמט וויליאמס | מהנדס קשרי מפתחים