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