פתרון בעיות

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

תרחישי שכפול

בקטע הזה מוסברות בעיות שכפול שעלולות להתרחש באשכול.

איך עוקבים אחרי השהיות בשכפול?

ל-Memorystore for Redis Cluster יש את המדד /cluster/replication/maximum_offset_diff. המדד הזה עוקב אחרי ההפרש המקסימלי של היסטוריית השכפול (בבייטים) של צומת באשכול ראשי.

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

מומלץ להגדיר ערך סף למדד maximum_offset_diff. אם הסף יעבור, מערכת Memorystore for Redis Cluster תוכל לשלוח לכם התראה.

על סמך סוג הצומת של האשכול, מומלץ להגדיר את הסף באופן הבא:

• אם סוג הצומת הוא redis-shared-core-nano,‏ redis-standard-small,‏ redis-highmem-medium,‏ redis-highcpu-medium או redis-standard-large, צריך להגדיר את ערך הסף כך שיהיה קטן מ-64MB.

• אם סוג הצומת הוא redis-highmem-xlarge או redis-highmem-2xlarge, צריך להגדיר את סף הזיכרון כך שיהיה קטן מ-1GB.

זהירות: מומלץ להשתמש בסוג הצומת redis-shared-core-nano רק למטרות פיתוח או בדיקה, כי לסוג הצומת הזה אין הסכם רמת שירות (SLA). אם אתם מפעילים את Memorystore for Redis Cluster בסביבת ייצור, מומלץ להשתמש בסוג צומת אחר. מידע נוסף על סוגי הצמתים האלה זמין במאמר בחירת סוג הצומת.

תרחישים של שגיאות בקישוריות

בקטע הזה מוסברות בעיות קישוריות שעלולות להתרחש באשכול.

שגיאת חיבור שנגרמת בגלל כללים של חומת אש

כללים בחומת האש עלולים לגרום לשגיאות בחיבור על ידי חסימת היציאות שבהן נעשה שימוש ב-Memorystore for Redis Cluster. לשתי נקודות הקצה של Private Service Connect באשכול, צריך לאפשר יציאות TCP בטווח 11000 עד 13047. מידע נוסף על נקודות הקצה האלה זמין במאמר כתובות רשת שמורות.

שגיאת חיבור שנגרמת בגלל מדיניות הארגון

יכול להיות שיש לכם מדיניות ארגונית שחוסמת את החיבורים של Private Service Connect לאשכול.

אם במדיניות הארגון שלכם נעשה שימוש במדיניות .restrictPrivateServiceConnectProducer, צריך לאפשר את התיקייה 961333125034, שהיא תיקייה שנועדה במיוחד ל-Memorystore for Redis Cluster. לדוגמה:

name: organizations/Consumer-org-1/policies/compute.restrictPrivateServiceConnectProducer
spec:
    rules:
      - values:
          allowedValues:
          - under:folders/961333125034

אם במדיניות הארגון נעשה שימוש במדיניות .disablePrivateServiceConnectCreationForConsumers, צריך לאפשר את SERVICE_PRODUCERS. לדוגמה:

name: organizations/Consumer-org-1/policies/compute.disablePrivateServiceConnectCreationForConsumers
spec:
    rules:
      - values:
          allowedValues:
          - SERVICE_PRODUCERS

שגיאת חיבור שנגרמת בגלל חיבורים שלא מגיבים

מומלץ מאוד להגדיר את אפליקציית הלקוח כך שתזהה חיבורים לא מגיבים ל-Memorystore for Redis Cluster. כשמזוהה חיבור שלא מגיב, הלקוח צריך לאפס אותו. כדי לבנות אפליקציה עמידה, מומלץ להשתמש בהגדרות הלקוח הבאות:

• הגדרת פרמטרים של TCP keep-alive: מגדירים את הפרמטרים TCP keepalive time,‏ TCP keepalive interval ו-TCP keepalive probes כך שהלקוחות יזהו וינתקו באופן יזום חיבורים שלא מגיבים, גם כשהחיבורים לא פעילים. לדוגמה, אם מגדירים את הפרמטר TCP keepalive time ל-30 שניות, את הפרמטר TCP keepalive interval ל-10 שניות ואת הפרמטר TCP keepalive probes ל-3, הלקוחות יאפסו חיבורים לא פעילים שלא מגיבים תוך דקה.
• הגדרה של פסק זמן למשתמשים ב-TCP: מגדירים את פסק הזמן הזה בלקוחות כדי לאפס חיבורים שיש להם בקשות ממתינות ולא מגיבים. לדוגמה, אם מגדירים את הזמן הקצוב לתפוגה ל-15 שניות, הלקוחות מאפסים חיבורים שלא מגיבים שיש להם בקשות בהמתנה אחרי 15 שניות.

תרחישי שימוש במעבד

בקטע הזה מוסברות בעיות בשימוש במעבד שעלולות להתרחש באשכול.

נגמר המקום במאגר הפלט של האשכול

אם נגמר המקום במאגר הפלט של האשכול, צריך לבצע את הפעולות הבאות:

• מגדירים ערך קטן יותר לפרמטר maxmemory.
• משתמשים במדיניות allkeys-lru maxmemory.

כשהזיכרון של האשכול מלא ומגיעה פעולת כתיבה חדשה, Memorystore for Redis Cluster מפנה מקום לכתיבה על ידי הוצאת מפתחות, בהתאם למדיניות maxmemory של האשכול. המדיניות allkeys-lru מסירה את המפתחות שהשימוש בהם היה הכי מזמן (LRU) מכל קבוצת המפתחות.

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

למה יכול להיות שמדדים חיצוניים חסרים באשכול?

אם יש ניצול גבוה של CPU באשכול או שהמשאבים של האשכול מוצו (לדוגמה, בגלל שיש יותר מדי חיבורים), יכול להיות שהאשכול יתנהג בצורה לא תקינה ושהמדדים החיצוניים לא יופיעו.

בידוד המקור של זמן האחזור של האשכול

כדי לקבוע אם זמן האחזור שאתם חווים נובע מהאשכול או מהאפליקציה של הלקוח ומסביבת הרשת, אתם יכולים להשתמש בכלי redis-cli כדי להריץ בדיקה רציפה של זמן האחזור.

כדי לבודד את מקור ההשהיה של האשכול:

1. מתחברים למכונה וירטואלית של Compute Engine שנמצאת באותו אזור ובאותה רשת VPC כמו האשכול.

2. אופציונלי: מריצים את הפקודה הבאה כדי להתקין את הכלי redis-cli ב-VM:

   sudo apt-get install redis-tools
   

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

   redis-cli --latency -h DISCOVERY_ENDPOINT_ADDRESS -p PORT
   

   אם באשכול שלכם נעשה שימוש בהצפנה בזמן העברה, צריך להוסיף את הדגל --tls ולציין את רשויות האישורים (CA) כדי להתחבר.

   מחליפים את הפרטים הבאים:

   • ‫DISCOVERY_ENDPOINT_ADDRESS: כתובת ה-IP של נקודת הקצה של הגילוי של האשכול.
   • ‫PORT: מספר היציאה ששמור לנקודת הגילוי של האשכול. בדרך כלל מספר היציאה הזה הוא 6379.

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

5. אופציונלי: כדי להפסיק את הפעלת הפקודה, לוחצים על Ctrl+C.

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

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

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

תרחישים של התמדה

בקטע הזה מוסברות בעיות של התמדה שעלולות להתרחש באשכול.

נפח התנועה של פעולות הכתיבה חורג מהיכולת של Memorystore for Redis Cluster לבצע דחיסה ולפנות מקום באמצעות שכתוב של AOF

אם זה קורה, קובץ ה-Append-Only File (AOF) גדל מהר יותר מהמהירות שבה תהליך השכתוב יכול להתמודד. כתוצאה מכך, הדיסק מתמלא, פעולות הכתיבה נכשלות והפעולות שדורשות יצירת עותק משוכפל וסנכרון מלא נחסמות.

ב-Memorystore for Redis Cluster הוטמעו אמצעי בקרה כדי לווסת את קצב העברת הנתונים לכתיבה. כך אפשר לוודא ששכתוב קובץ ה-AOF יכול לעמוד בקצב של עומסי עבודה גבוהים ומתמשכים של כתיבה.