בקטע הזה של המדריך Google Cloud ארכיטיפים של פריסות מתואר הארכיטיפ של פריסה אזורית.
בארכיטקטורת ענן שמשתמשת באב-טיפוס של פריסה אזורית, מופעים של האפליקציה פועלים בשני אזורים או יותר בתוך Google Cloudאזור אחד. כל המופעים של האפליקציה משתמשים במאגר משותף של קובצי תצורה שמנוהל באופן מרכזי. נתוני האפליקציה משוכפלים באופן סינכרוני בכל האזורים בארכיטקטורה.
בתרשים הבא מוצגת טופולוגיית הענן של אפליקציה עם זמינות גבוהה שפועלת באופן עצמאי בשלושה אזורים בתוךGoogle Cloud אזור יחיד:
בדיאגרמה הקודמת מוצגת אפליקציה עם רכיבי קצה קדמי ורכיבי בק-אנד שפועלים באופן עצמאי בשלושה תחומים באזור Google Cloud . מאזן עומסים חיצוני מעביר בקשות של משתמשים לאחד מממשקי הקצה. מאזן עומסים פנימי מעביר תנועה מהחלקים הקדמיים לחלקים האחוריים. האפליקציה משתמשת במסד נתונים שמשוכפל באזורים שונים. אם מתרחשת הפסקה זמנית בשירות באזור מסוים, מסד הנתונים עובר אוטומטית לשימוש בעותק משוכפל באזור אחר.
הטופולוגיה בתרשים הקודם חסינה מפני הפסקות זמניות באזורים, אבל לא מפני הפסקות זמניות באזורים. כדי שתוכלו להתאושש מהפסקות באזור מסוים, אתם צריכים לפרוס רפליקה פסיבית של האפליקציה באזור שני (יתירות כשל), כמו שמוצג בדיאגרמה הבאה:
כשמתרחש שיבוש באזור הראשי, צריך לקדם את מסד הנתונים באזור הגיבוי ליתירות כשל ולהשתמש במדיניות ניתוב של DNS כדי לנתב את התנועה למאזן העומסים באזור הגיבוי ליתירות כשל.
כדי לבצע אופטימיזציה של העלות של תשתית יתירות כשל, אפשר להפעיל את אזור יתירות הכשל בקיבולת נמוכה יותר על ידי פריסת פחות משאבים.
תרחישים לדוגמה
בקטעים הבאים מופיעות דוגמאות לתרחישי שימוש שבהם ארכיטיפ הפריסה האזורי הוא בחירה מתאימה.
אפליקציה עם זמינות גבוהה למשתמשים באזור גיאוגרפי מסוים
אנחנו ממליצים על ארכיטיפ פריסה אזורי לאפליקציות שצריכות להיות חסינות מפני הפסקות חשמל באזורים, אבל יכולות לסבול השבתה מסוימת שנגרמת כתוצאה מהפסקות חשמל באזורים. אם חלק כלשהו במערך האפליקציה נכשל, האפליקציה ממשיכה לפעול אם קיים לפחות רכיב אחד מתפקד עם קיבולת מספקת בכל רמה. אם מתרחש הפסקת חשמל באזור מסוים, חבילת האפליקציות ממשיכה לפעול באזורים האחרים.
זמן טעינה קצר למשתמשי האפליקציה
אם המשתמשים באפליקציה נמצאים באזור גיאוגרפי מסוים, כמו מדינה אחת, ארכיטיפ הפריסה האזורית יכול לעזור לשפר את הביצועים של האפליקציה מנקודת המבט של המשתמשים. כדי לבצע אופטימיזציה של זמן האחזור ברשת לבקשות של משתמשים, כדאי לפרוס את האפליקציה באזור Google Cloud שקרוב ביותר למשתמשים.
רשת עם זמן אחזור נמוך בין רכיבי האפליקציה
ארכיטקטורה של אזור יחיד יכולה להתאים לאפליקציות כמו עיבוד באצווה שדורשות חיבורי רשת עם זמן אחזור נמוך ורוחב פס גבוה בין צמתי החישוב. כל המשאבים נמצאים באותו אזור Google Cloud , כך שתעבורת הנתונים ברשת בין המשאבים נשארת באזור. החביון ברשת בין המשאבים נמוך, ולא תחויבו בעלויות על העברת נתונים בין אזורים. עדיין יחולו עלויות רשת בתוך האזור.
עמידה בדרישות לגבי מיקום אחסון הנתונים וריבונות הנתונים
ארכיטיפ הפריסה האזורי יכול לעזור לכם לעמוד בדרישות הרגולטוריות בנוגע למיקום אחסון הנתונים ולריבונות תפעולית. לדוגמה, יכול להיות שבמדינה באירופה יש דרישה שכל נתוני המשתמשים יאוחסנו ויהיו נגישים במרכזי נתונים שנמצאים פיזית בתוך המדינה. כדי לעמוד בדרישה הזו, אפשר לפרוס את האפליקציה באזורGoogle Cloud באירופה.
שיקולים בתכנון
כשיוצרים ארכיטקטורה שמבוססת על ארכיטיפ של פריסה אזורית, כדאי לקחת בחשבון את גורמי העיצוב הבאים.
השבתה במהלך הפסקות חשמל באזור
כשמתרחש הפסקת חשמל באזור, האפליקציה לא פועלת. כדי לצמצם את זמן ההשבתה שנגרם כתוצאה מהפסקות חשמל באזור מסוים, אפשר לשמור עותק משוכפל פסיבי (למעבר לגיבוי) של מחסנית התשתית באזור אחר. Google Cloud אם מתרחש שיבוש בשירות באזור הראשי, אפשר להפעיל את מחסנית הנתונים באזור היתירות כשל ולהשתמש במדיניות הניתוב של DNS כדי לנתב את התעבורה למאזן העומסים באזור היתירות כשל.
העלות של משאבים מיותרים
בדרך כלל בארכיטקטורה מרובת אזורים יש יותר משאבי ענן מאשר בפריסה של אזור יחיד. כשבונים את הארכיטקטורה, צריך לקחת בחשבון את העלות של משאבי הענן האלה. באפליקציות שצריכות להיות עמידות בפני הפסקות חשמל באזורים, היתרון של זמינות גבוהה בארכיטקטורה של כמה אזורים עשוי להצדיק את העלות הגבוהה יותר.
תרשים עזר לארכיטקטורה
לעיון בארכיטקטורת הפניה שבה אפשר להשתמש כדי לתכנן פריסה אזורית במכונות וירטואליות ב-Compute Engine, אפשר לעיין במאמר בנושא פריסה אזורית ב-Compute Engine.