העיקרון הזה בעמוד התווך של האמינות ב-Google Cloud Well-Architected Framework מספק המלצות לתכנון, לבנייה ולניהול של יתירות משאבים, שיכולה לעזור לכם להימנע מכשלים.
העיקרון הזה רלוונטי לתחום המיקוד של היקף האמינות.
סקירה כללית של העיקרון
אחרי שתחליטו מהי רמת האמינות שאתם צריכים, תצטרכו לתכנן את המערכות כך שלא יהיו בהן נקודות כשל בודדות. כל רכיב קריטי במערכת צריך להיות משוכפל בכמה מכונות, אזורים ואזורים גיאוגרפיים. לדוגמה, מסד נתונים קריטי לא יכול להיות ממוקם באזור אחד בלבד, ואי אפשר לפרוס שרת מטא-נתונים באזור אחד בלבד. בדוגמאות האלה, אם יש הפסקה זמנית בשירות באזור היחיד, יש הפסקה זמנית בשירות בכל המערכת.
המלצות
כדי לבנות מערכות יתירות, כדאי להביא בחשבון את ההמלצות בסעיפי המשנה הבאים.
זיהוי דומיינים של כשל ושכפול שירותים
ממפים את דומייני הכשל של המערכת, ממכונות וירטואליות נפרדות ועד לאזורים, ומתכננים יתירות בדומייני הכשל.
כדי להבטיח זמינות גבוהה, כדאי להפיץ ולשכפל את השירותים והאפליקציות בכמה אזורים ותחומים. כדי לוודא שהשירותים והאפליקציות ימשיכו להיות זמינים במקרה של הפסקות זמניות בשירות באזור או במחוז, הגדירו את המערכת ליתירות כשל אוטומטית.
במאמר תכנון תשתית אמינה לעומסי העבודה ב- Google Cloud תוכלו למצוא דוגמאות לארכיטקטורות במספר אזורים ובמספר אזורים גיאוגרפיים.
זיהוי בעיות וטיפול בהן במהירות
עוקבים באופן קבוע אחרי הסטטוס של דומייני הכשל כדי לזהות בעיות ולטפל בהן במהירות.
בלוח הבקרה שלGoogle Cloud Service Health אפשר לעקוב אחרי הסטטוס הנוכחי של שירותי Google Cloud בכל האזורים. אתם יכולים גם להשתמש ב-Service Health בהתאמה אישית כדי לראות אירועים שרלוונטיים לפרויקט שלכם. אתם יכולים להשתמש במאזני עומסים כדי לזהות את תקינות המשאבים ולהעביר את התנועה באופן אוטומטי לקצוות עורפיים תקינים. למידע נוסף, ראו סקירה כללית על בדיקות תקינות.
תרחישים לבדיקת יתירות כשל
כמו בתרגיל כיבוי אש, כדאי לדמות כשלים באופן קבוע כדי לוודא שהאסטרטגיות של הרפליקציה ויתירות הכשל יעילות.
מידע נוסף זמין במאמרים הדמיה של הפסקת חשמל באזור מסוים ב-MIG אזורי והדמיה של כשל באזור מסוים באשכולות אזוריים של GKE.