פתרון בעיות

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

תרחישי שכפול

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

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

ל-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 מספר 6379, וגם את יציאות ה-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 במכונה הווירטואלית.

   • במכונות וירטואליות מבוססות Debian או Ubuntu, מריצים את הפקודה הבאה:

     sudo apt-get install redis-tools
     

   • במכונות וירטואליות שמבוססות על RHEL או CentOS, מריצים את הפקודה הבאה:

     sudo yum install redis
     

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 יכול לעמוד בקצב של עומסי עבודה גבוהים ומתמשכים של כתיבה.