בדף הזה מפורטות כמה מההגדרות שמשתמשים יכולים לשלוט בהן, שיכולות לגרום להשבתה של מופע Spanner ולהוביל לכך שההשבתה לא תיכלל בהסכם רמת השירות (SLA) של Spanner. ההסכם לא כולל השבתות שנגרמות כתוצאה מגורמים שאינם בשליטה סבירה של Google. הוא גם מספק הנחיות לגבי הדרכים להימנע מהגדרות כאלה.
Spanner מנהל היבטים רבים של פעולות במסד הנתונים, כמו פיצול ואיזון מחדש של נתונים, רפליקציה, יתירות כשל וכל עדכוני החומרה והתוכנה. אפשר להגדיר הרבה מההתנהגויות האלה באמצעות הגדרות מובנות וממשקי API לניהול. עומסי העבודה תלויים גם ברכיבים אחרים, בנוסף ל-Spanner, כמו האפליקציות והרשת שלכם. הגדרות כאלה בשליטת הלקוח עלולות להגדיל את הסיכון להשבתה של מופע, בהתאם לעומס על מסד הנתונים ולפרמטרים אחרים של ההגדרות.
אם המופע שלכם לא תקין, ו-Google קובעת שהמופע לא עומד במגבלות התפעוליות שמתוארות בדף הזה, יכול להיות שזמן ההשבתה שייגרם לא ייכלל בחישוב של הסכם רמת השירות של Spanner (או לא ינוכה ממנו).
הגדרות שלא נכללות בהסכם רמת השירות של Spanner
ההגדרות הבאות לא כלולות בהסכם רמת השירות של Spanner:
- אם המכונה שלכם מוגדרת ומשמשת באופן שגורם לעומס העבודה להעמיס יתר על המכונה, היא לא מכוסה בהסכם ה-SLA.
- הסכם ה-SLA לא חל על זמן השבתה של מופעים שנובע מפעולות או מחוסר פעולות שלכם
- אם משביתים את Spanner API או ממשקי API אחרים של Google Cloud שנדרשים כדי ליצור חיבור ל-Spanner, אז הוא לא מכוסה בהסכם SLA.
- הסכם ה-SLA לא חל על מצבים שבהם ממשק Spanner API לא זמין בגלל הגדרות הרשת, כמו שרת proxy וכללי חומת אש.
- הסכם ה-SLA לא חל על מצבים שבהם האפליקציה לא זמינה בגלל לקוחות לא מעודכנים או שההגדרה שלהם שגויה. חשוב במיוחד לוודא שאתם משתמשים בגרסאות עדכניות של הלקוח עם תלות נתמכת. לדוגמה, באפליקציות Java צריך להשתמש בBOM של Google (bill of materials, מפרט חומרים) עם מנהל חבילות כמו Gradle או Maven.
מומלץ להגדיר התראות ומעקב באמצעות Cloud Monitoring.
הגדרות שכדאי להימנע מהן
כדי לשמור על כיסוי של הסכם רמת השירות (SLA) של Spanner, צריך להימנע מההגדרות הבאות:
- עומס יתר על ה-CPU: אם השימוש ב-CPU גבוה באופן עקבי, המשמעות היא שהגודל של המופע לא מתאים לעומס העבודה, ויכול להיות שהמופע לא מכוסה על ידי ה-SLA. ההמלצות לניצול CPU ב-Spanner מספקות תקורה לאירוע של מעבר לגיבוי בעת כשל, שבו משאבי המחשוב שנותרו עוזרים להתמודד עם התנועה מחלקים במכונה שלא זמינים. אתם יכולים להשתמש במדדי ניצול המעבד של Spanner כדי לעקוב אחרי ניצול המעבד.
- נפח אחסון מלא: ב-Spanner מחייבים אתכם רק על נפח האחסון שבו אתם משתמשים. עם זאת, לכל צומת, או יחידת מחשוב, יש מגבלה על כמות האחסון שהוא יכול לנהל. אם הגודל של המופע לא מתאים לנפח האחסון שניתן להקצאה לכל צומת, יכול להיות שהמופע לא יכוסה על ידי ה-SLA. אתם יכולים להשתמש במדדי ניצול האחסון של Spanner כדי לעקוב אחרי ניצול האחסון.
- מגבלת מכסה: המשאבים של הצומת מוגבלים על ידי מכסות לכל משתמש. אם לא תבקשו להגדיל את המכסות מראש, יכול להיות שיהיה עומס יתר על משאבי המחשוב, וזה לא יכוסה בהסכם רמת השירות. הטיפול בבקשות להגדלת מכסות שדורשות אישור מ-Google בדרך כלל מסתיים תוך יום אחד.
- סשנים עם הקצאת יתר: לקוחות Spanner משתמשים בערוצי gRPC כדי לתקשר עם נקודות קצה של Google Cloud לשאילתות ולניהול. אם סביבות הלקוח לא מספקות מספיק ערוצים כדי לתמוך בנפח הבקשות של עומס העבודה, יכול להיות שיהיה לאפליקציות זמן אחזור גבוה וקצב העברת נתונים נמוך של בקשות, שלא מכוסים בהסכם רמת השירות.
- עומס יתר על החיבור: אפשר לנסות שוב הרבה ממשקי Spanner API בבטחה במקרה של כשל זמני, כמו קיפאון של טרנזקציה בשאילתה, בעיה ברשת או מגבלות קצב של ממשקי API אדמיניסטרטיביים. ניסיונות חוזרים אגרסיביים מדי עלולים להעמיס על חיבורים קיימים, ולגרום למיצוי משאבים או להגבלת קצב נתונים נוספת. יכול להיות שה-SLA לא יחול על זמן האחזור המוגדל או על התפוקה המופחתת. מידע נוסף זמין במאמר בנושא ניהול פסק זמן וניסיונות חוזרים של לקוחות.
- עומס יתר על כונן קשיח (HDD): אחסון מדורג מאפשר לכם לאחסן את נתוני Spanner על שילוב של כונני SSD וכוננים קשיחים (HDD). אם עומס הדיסק באחסון HDD מגיע ל-100%, זמן האחזור של מופע Spanner עולה באופן משמעותי, ויכול להיות שהוא לא יכוסה על ידי ה-SLA. אתם יכולים להשתמש במדדים של אחסון בשכבות ב-Spanner כדי לעקוב אחרי עומס הדיסק.