תוכן העניינים

סקירה כללית #

Redis הוא מאגר מבני נתונים בקוד פתוח בזיכרון (in-memory) שניתן להשתמש בו כמתווך הודעות, מטמון (cache) ומסד נתונים של ערכי מפתח (key-value). הוא תומך במספר מבני נתונים: גיבוב (hashes), רשימות (lists), קבוצות (sets), קבוצות ממוינות (matches), מפות סיביות (bitmaps), אינדקסים גיאו-מרחביים (geospatial indexes), היפרלוגלוגים (hyperlogloglogs) וכו'.

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

בין היתר, Redis מספקת זמינות גבוהה, דרך Redis Sentinel , וחלוקה אוטומטית, דרך Redis Cluster . בנוסף, ל-Redis יש מנגנון שכפול המאפשר ל-Slave instances להיות עותקים מדויקים של master instances. ה-Slave יתחבר מחדש אוטומטית ל-master בכל פעם שהקישור מתנתק, ומטרתו היא להיות עותק מדויק שלו.

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

אבל, מה קורה כאשר Sentinel מזהה שרת Redis ככבוי? במאמר זה נגלה כיצד ליצור שירות וירטואלי שלם בעל זמינות גבוהה עבור Redis.

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

הפוך מחדש את סביבת איזון העומסים #

התרחיש שאנו רוצים להשיג במאמר זה מוצג בתרשים שלהלן.

Redis Sentinel בודק את המצב של כל צמתי ה- Redis ומשנה את תפקיד שרת ה- Redis ברגע שמתגלה שגיאה.

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

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

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

חזור לתצורת איזון עומס #

לפני הגדרת החווה, עלינו לקבל כתובת IP וירטואלית. לשם כך, עבור אל רשת > ממשקים וירטואליים . לאחר מכן לחץ על פעולה > צור ממשק וירטואלי . לאחר מכן, בחר ממשק אב , שם ממשק וירטואלי ואת כתובת ה-IP שלו :

לאחר מכן, עבור שרת וירטואלי של Redis עלינו ליצור חוות L4xNAT. לשם כך, עבור אל LSLB > חוות , ולאחר מכן לחץ על פעולה וצור חוות.

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

לאחר מכן, עבור אל שירותים . כאן יוגדרו Backends ו-Farm Guardian לבדיקת תקינות מתקדמת. ראשית, מצא את הקטע Backends ולחץ על פעולות > הוסף backend כפי שמוצג למטה:

ביצוע שליטה מחדש ובדיקת בריאות מתקדמת #

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

check_tcp -E -H HOST -p PORT -s 'שכפול מידע\r\n' -e תפקיד:master -t 3

כאשר HOST ו- PORT יוחלפו בכתובת ה-IP והפורט של שרת Redis של כל backend. שכפול מידע הפקודה יקבל את המידע משרת Redis על מנת לוודא איזה מאסטר פעיל, חיבורים ינותבו לשרת רק אם מוצג מאסטר התפקיד. ברגע ש-Sentinel ישנה את התפקיד, מאזן העומסים יזהה את השינוי ושרת Redis יסומן כלא פעיל. הדגל -t הוא מספר השניות ש-Farm Guardian ימתין לתגובת שרת Redis, ואם מגיע הזמן הקצוב ללא תגובה, שרת Redis יסומן כלא פעיל. מצד שני, לאחר ששרת Redis ישוחזר, הוא יחזור להיות פעיל.

אבל לפני שינוי Farm Guardian עבור חווה ספציפית זו, עבור אל ניטור > Farmguardian ולאחר מכן לחץ על פעולה > צור Farmguardian.

בחר שם תיאורי עבור בודק הבריאות החדש שלך ב- Redis Sentinel, לדוגמה, check_redis_master כמו בדוגמה, כעת בחר check_tcp ב- Farmguardian שהוגש כדי להעתיק ולחץ על צור כפי שמוצג להלן.

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

לחץ על שלח.

כעת, בחר את בדיקת הבריאות המתקדמת החדשה של Farm Guardian בשירות הווירטואלי של Redis. חזור אל LSLB > Farms , לחווה שנוצרה בשם RedisFarm , בכרטיסייה Services . לבסוף, בחר את הפקודה check_redis_master שזה עתה נוצרה תחת Health Checks for backend.