שיטות מומלצות לזמינות

בדף הזה מתוארות שיטות מומלצות להבטחת זמינות גבוהה של ההתקנה של Google Distributed Cloud. ב-Distributed Cloud לא מוצע הסכם רמת שירות (SLA), אלא רק היעד למדידת רמת השירות (SLO) שמתואר בדף הזה.

בחירה והטמעה של רמת הזמינות

צריך לבחור את רמת הזמינות של עומסי העבודה ב-Distributed Cloud שהכי מתאימה לדרישות העסקיות שלכם. לדוגמה, לאפליקציה לתשלום עצמי בחנות קמעונאית יש סיכון זמינות נמוך בהרבה מאשר לפריסת RAN בפריפריה של ספק רשת סלולרית.

זמינות היעד פרופורציונלית ישירות לקיבולת המשאבים הרזרביים של Distributed Cloud שאתם שומרים למקרי חירום. הטבלה הבאה מתארת את הקשר הזה. ההערכות האלה לא כוללות את זמן ההשבתה המתוכנן עם חלון זמן לתחזוקה.

התוכנה של Distributed Cloud במודל מחובר צורכת חלק מהמשאבים בכל מכונה פיזית. הסכום משתנה בהתאם להגדרה הספציפית של הפריסה שלכם ב-Distributed Cloud במודל מחובר. ‫Google ממליצה לבצע בדיקת ביצועים (benchmark) של הפריסה שלכם ב-Google Distributed Cloud במודל מחובר כדי למדוד את הכמות הזו ולהביא אותה בחשבון כשמתכננים את חלוקת עומסי העבודה.

הקיבולת שנמצאת בשימוש קיבולת שמורה זמינות של טירגוט
83.33% 16.67% 99.9%
100% 0% 93.5%

יכול להיות שתחוו ירידה פתאומית בקיבולת בגלל כשל בחומרה או בגלל צומת שנדרשת הפעלה מחדש. כדי להתכונן לכך, צריך לתכנן את עומסי העבודה תוך התחשבות במכסות המשאבים, כך שתמיד תהיה קיבולת זמינה בכל צומת של Distributed Cloud שתעמוד ברמת הזמינות שבחרתם.

לדוגמה, כדי להשיג זמינות של 99.9%, צריך להגדיר את עומסי העבודה כך שאחת מתוך שש המכונות הפיזיות בכל אשכול של Distributed Cloud תהיה זמינה כגיבוי.

שימוש במצב זמינות

‫Distributed Cloud מאפשר ליצור אשכולות שמשתמשים במישור בקרה מקומי שפועל בחומרה של Distributed Cloud. אשכולות כאלה מאפשרים להריץ עומסי עבודה גם כשהחיבור ל- Google Cloud נותק. מידע נוסף זמין במאמר בנושא מצב זמינות של Distributed Cloud.

הסבר על עדכוני תוכנה וחלונות זמן לתחזוקה

‫Google מעדכנת באופן קבוע את תוכנת Distributed Cloud. עדכוני התוכנה האלה הם חובה ואי אפשר לבטל את ההסכמה להם. ב-Distributed Cloud אפשר לציין חלונות תחזוקה נפרדים לכל אחד מהאשכולות של Distributed Cloud.

כדי לצמצם שיבושים זמניים פוטנציאליים בעומסי העבודה, חלונות התחזוקה מאפשרים לכם לשלוט במועד שבו יכולים להתבצע שדרוגים אוטומטיים של מישורי בקרה וצמתים. חלונות זמן לתחזוקה שימושיים בין היתר בתרחישים הבאים:

  • שעות שבהן העומס נמוך: כדי לצמצם את הסיכוי להשבתה, כדאי לתזמן שדרוגים אוטומטיים לשעות שבהן העומס נמוך.
  • במהלך שיחה: כדאי לוודא שהשדרוגים יתבצעו במהלך שעות העבודה, כדי שמישהו יוכל לעקוב אחרי השדרוגים ולטפל בבעיות בלתי צפויות.
  • שדרוגים של כמה אשכולות: אתם רוצים לבצע שדרוגים בכמה אשכולות באזורים שונים, אחד בכל פעם במרווחי זמן מוגדרים.

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

אם המשימות ממשיכות לפעול אחרי חלון זמן לתחזוקה, Distributed Cloud מנסה להשהות אותן. לאחר מכן המערכת מנסה להמשיך את המשימות האלה במהלך חלון זמן לתחזוקה הבא.

‫Distributed Cloud שומרת לעצמה את הזכות להשיק שדרוגים לא מתוכננים של מצבי חירום מחוץ לחלונות התחזוקה. בנוסף, שדרוגים חובה מתוכנה שיצאה משימוש או מתוכנה לא עדכנית עשויים להתבצע באופן אוטומטי מחוץ לחלונות התחזוקה.

אפשר גם לשדרג את האשכול באופן ידני בכל שלב. שדרוגים שמתחילים באופן ידני מתחילים מיד ומתעלמים מחלונות תחזוקה.

במאמר הגדרת חלון זמן לתחזוקה מוסבר איך להגדיר חלון זמן לתחזוקה לאשכול חדש או קיים.

הגבלות

ההגבלות הבאות חלות על חלונות זמן לתחזוקה:

  • חלון זמן אחד לתחזוקה לכל אשכול. אפשר להגדיר רק חלון זמן לתחזוקה אחד לכל אשכול. הגדרת חלון זמן חדש לתחזוקה מחליפה את חלון הזמן הקודם.

  • אזורי זמן לחלונות זמן לתחזוקה. כשמגדירים חלונות לתחזוקה וצופים בהם, השעות מוצגות בצורה שונה בהתאם לכלי שבו משתמשים, כמו שמפורט בקטעים הבאים.

כשמגדירים חלונות לתחזוקה

כשמשתמשים בדגל --maintenance-window הכללי יותר כדי להגדיר חלון זמן לתחזוקה, אי אפשר לציין אזור זמן. כשמשתמשים ב-Google Cloud CLI או ב-API, השעות מוצגות לפי UTC. השעות במסוףGoogle Cloud מוצגות לפי אזור הזמן המקומי.

כשמשתמשים בדגלים מפורטים יותר, כמו --maintenance-window-start, אפשר לציין את אזור הזמן כחלק מהערך. אם לא מציינים את אזור הזמן, נעשה שימוש באזור הזמן המקומי. השעות תמיד נשמרות לפי שעון UTC.

כשצופים בחלונות זמן לתחזוקה

כשמציגים מידע על האשכול, חותמות הזמן של חלונות התחזוקה יכולות להיות מוצגות לפי שעון UTC או לפי אזור הזמן המקומי, בהתאם לאופן הצגת המידע:

  • כשמשתמשים במסוף Google Cloud כדי לראות מידע על האשכול, השעות תמיד מוצגות לפי אזור הזמן המקומי.
  • כשמשתמשים ב-CLI של gcloud כדי להציג מידע על האשכול, השעות תמיד מוצגות ב-UTC.

בשני המקרים, RRULE תמיד יהיה לפי שעון UTC. כלומר, אם מציינים, לדוגמה, ימים בשבוע, אז הימים האלה הם לפי שעון UTC.

הגדרת חלונות תחזוקה של אשכול

ב-Distributed Cloud אפשר לציין חלון זמן לתחזוקה לכל אחד מהאשכולות שלכם ב-Distributed Cloud. בחלון הזה מציינים ל-Google לעדכן את תוכנת Distributed Cloud רק בזמן ובתדירות שאתם מציינים.

הכללים הבאים חלים על חלונות תחזוקה של אשכולות Distributed Cloud:

  • אם מציינים חלון זמן לתחזוקה של אשכול Distributed Cloud, ‏ Google מעדכנת את תוכנת Distributed Cloud 48 שעות אחרי שהעדכון הוכרז בהערות הגרסה של Distributed Cloud. בדף הערות המוצר, אפשר להירשם לפיד RSS של הערות המוצר של Distributed Cloud כדי לקבל עדכונים על עדכוני תוכנה כשהם מתפרסמים.
  • משך הזמן המינימלי של חלון זמן לתחזוקה הוא שש שעות. אפשר לציין חלון זמן ארוך יותר בהתאם למורכבות של ההתקנה של Distributed Cloud ולדרישות העסקיות.
  • התדירות המינימלית של עדכוני תוכנה היא פעם בשבוע. אפשר לציין חלונות תחזוקה שבועיים או יומיים. אפשר לכלול ולהחריג ימים ספציפיים.
  • אפשר לשנות את לוח הזמנים של חלון הזמן לתחזוקה של אשכול בכל שלב, אלא אם חלון הזמן לתחזוקה כבר תוכנן או אם חלון הזמן לתחזוקה נמצא בעיצומו.
  • אם עדכון התוכנה לא הושלם במהלך חלון הזמן שצוין, הוא מושהה ואז ממשיך במהלך חלון זמן לתחזוקה הבא שנקבע.

הוראות מפורטות זמינות במאמר בנושא הגדרת חלון זמן לתחזוקה לאשכול.

תיקון של חומרה שנכשלה

כש-Google מזהה כשל בחומרה של Distributed Cloud, ‏ Google מנסה לתאם ביקור באתר תוך שלושה ימי עסקים. כדי שטכנאי מורשה של Google יוכל לבצע את האבחון והתיקונים הנדרשים, אתם צריכים להעניק לו גישה לחומרה של Distributed Cloud.

אם מתרחשת תקלה בחומרה של Distributed Cloud ו-Google מבצעת תיקונים באתר, כל אמצעי האחסון מוסרים ממכונת Distributed Cloud שמטופלת ומועברים לחזקתכם למשך התיקון.

נקודות כשל אחרות

אתם אחראים לתחזוקה של ההיבטים הבאים בהתקנה של Distributed Cloud, שלא נמצאים בשליטה של Google ויכולים להשפיע על הזמינות של Distributed Cloud:

המאמרים הבאים