אשכול Redis הוא תכונה מובנית ב־Redis שתומכת בשיבוץ אוטומטי, שיכפול וזמינות גבוהה שכבר נממשו בעבר באמצעות Sentinels. הוא מיועד לשני מטרות עיקריות: לפצל את סט הנתונים שלך בין מספר רב של מופעים ולספק מעלה של זמינות במהלך מחיצות, כדי להמשיך בפעולות כאשר חלק מהמופעים (במיוחד מאסטרים) נכשלים או אינם מסוגלים לתקשר עם רוב הצמתים באשכול.
עם זאת, האשכול מפסיק לפעול במקרה של כשלים גדולים (למשל כאשר רוב המופעים הראשיים אינם זמינים). גם אם מאסטר ועבד נכשלים בו זמנית, האשכול לא יכול להמשיך בפעולות רגילות (למרות שהדרך הפתרונית היא להוסיף צמתים נוספים או ליצור אסימטריה באשכול, לשינוי אוטומטי של מבנה האשכול).
לפי תיעוד האשכול של Redis, ה"אשכול המינימלי" המתפקד כמצופה דורש לכל הפחות 3 מופעי מאסטר. אך ההגדרה המתאימה ביותר לזמינות גבוהה צריכה להכיל לפחות 6 צמתים עם שלושה מאסטרים ושלושה עבדים, כל מאסטר כולל עבד.
חשוב: לאשכול Redis יש גם מגבלות כגון חוסר תמיכה בסביבות NATted וגם אלה שבהן כתובות ה־IP או יציאות ה־TCP מוחלפות, לדוגמה תחת Docker. בנוסף, לא כל ספריית לקוח תומכת בו.
מאמר זה מראה כיצד להגדיר את אשף Redis Cluster (עם מצב אשף לא מופעל) ב- CentOS 8. הוא כולל איך להתקין את Redis, להגדיר את צומתי האשף, ליצור אשף ולבדוק את הכשלון של האשף.
הערה: עבור מדריך זה, נשתמש במופעים ריקים/רעננים של Redis כדי להפעיל את מצב האשף. מצב האשף לא יעבוד עם כמה הגדרות שנעשו במדריכי הראשונים שלנו בסדרה על Redis, במיוחד כאשר משתמשים בפרמטר של השכפול.
תנאים מראש:
הגדרת סביבת בדיקה
Redis Master1: 10.42.0.247 Redis Master2: 10.42.0.197 Redis Master3: 10.42.0.132 Redis Slave1: 10.42.0.200 Redis Slave2: 10.42.0.21 Redis Slave3: 10.42.0.34
הסביבה שלנו כוללת 3 צמתים של מאסטר קריאה/כתיבה ו-3 צמתים של רפליקה קריאה בלבד, כאשר לכל מאסטר יש רק רפליקה אחת. לכן, שלוש השרדים מכילים את כל הנתונים של האשף בכל צומת. אפליקציה API או CLI יכולה לכתוב רק לצמתים המאסטר ולקרוא מכל צומת באשף.
שלב 1: התקנת Redis על כל הצמתים
1. התחברות לכל המיניסטים דרך SSH, ואז בואו על ידי רצף הפעולות הבא כדי להתקין את המודל Redis בעזרת המנהל החבילות DNF כפי שנראה באיור.
# dnf module install redis
2. בהמשך, התחל את השירות Redis, הפעל אותו באופן אוטומטי בהתחלה של המערכת ובדגימה את מצבו כדי לוודא שהוא מופעל (בדוגמה לשירות על כל 6 המיניסטים).
# systemctl start redis # systemctl enable redis # systemctl status redis
שלב 2: הגדרת המיקומים של Redis על כל הכורים
3. החלק הזה מתאר איך להגדיר נודעי קבוצת Redis. שימו לב שצריך לבצע את ההגדרות פה על כל הכורים.
השתמשו בקובץ ההגדרות /etc/redis.conf כדי להגדיר את השרת Redis. כמות מומלצת, יצירו שיוך של הקובץ המקורי לפני שינויו בעזרת מערך על הקומאנד-ליין שלך.
# cp /etc/redis.conf /etc/redis.conf.orig # vi /etc/redis.conf
4. בהמשך, מצאו את האפשרויות הבאות וערכו את הערכים המוצגים. הפרמטר bind מגדיר את הממשק של השרת Redis יהיה מוקדש להאזנה, הגדר את הערכו לתודעת המיניסט הלאומית. הסרו את 127.0.0.1 מפני שגילינו שבעיקרון השארה שם מאטה את תהליך היצירת הקבוצה, במיוחד בשלב ההצטרפות לקבוצה.
bind 10.42.0.247
אז יש להגדיר את ה־protected-mode ל־no כדי לאפשר חיבורים ממופעים אחרים באשכול.
protected-mode no
הפרמטר port מגדיר את הפורט שבו שרת ה־Redis יקשיב לחיבורים, ברירת המחדל היא 6379. זהו פורט הנתונים לתקשורת עם לקוחות.
port 6379
5. הסט הבא של הפרמטרים יאפשר את מצב האשכול ויקבע כמה מתכונות השימושיות שלו. הפרמטר cluster-enabled, כאשר מוגדר ל־yes, מפעיל את מצב האשכול.
cluster-enabled yes
לאחר מכן, הפרמטר cluster-config-file מגדיר את שם קובץ תצורת האשכול של צומת באשכול (לדוגמה nodes-6379.conf). הקובץ נוצר בתיקיית העבודה (ברירת המחדל היא /var/lib/redis הוגדר באמצעות הפרמטר dir) ואינו ניתן לעריכה על ידי המשתמש.
cluster-config-file nodes-6379.conf
אפשרות האשכול השימושית הבאה היא cluster-node-timeout, היא משמשת להגדיר את הזמן המרבי במילישניות שבו ניתן לפסול את המופע כשהוא לא זמין כדי לתת אותו למצב כשל. ערך של 15000 שווה ל־15 שניות.
cluster-node-timeout 15000
6. יש גם להפעיל החזקה ביציבות של Redis על הדיסק. אפשר להשתמש באחד ממצבי ההחזקה, שהם ה־Append Only File (AOF): הוא מקליט (בקובץ appendonly.aof שנוצר מתחת לתיקיית העבודה) כל פעולת כתיבה שהשרת מקבל בהצלחה. הנתונים ישוחקו במהלך ההתנהגות השרת כדי לשחזר את ערך הנתונים המקורי.
כדי להפעיל את זה, יש להגדיר את הפרמטר appendonly ל־yes.
appendonly yes
7. לאחר ביצוע כל השינויים, אנא אתחל את שירות Redis בכל הצמתים כדי ליישם את השינויים האחרונים.
# systemctl restart redis
8. בנקודה זו, כל צומת בקבוצה צריכה להכיל כעת ID. ניתן לבדוק זאת בקובץ הלוג שנמצא ב- /var/log/redis/redis.log.
# cat /var/log/redis/redis.log
9. לאחר מכן, פתח את הפורט 6397 ואת 16379 בכל המופעים. הפורט האחרון משמש לתעבורת ה- cluster (ערוץ תקשורת צומת-לצומת באמצעות פרוטוקול בינארי). זהו דרישה בסיסית עבור חיבורי ה- TCP של ה- Redis cluster.
# firewall-cmd --zone=public --permanent --add-port=6379/tcp # firewall-cmd --zone=public --permanent --add-port=16379/tcp # firewall-cmd --reload
שלב 3: יצירת ה- Redis Cluster
10. כדי ליצור את הקבוצה, השתמש בלקוח שורת הפקודה redis-cli כדלקמן. ה- --cluster create מאפשר יצירת קבוצה וה- --cluster-replicas 1 אומר ליצור רפליקה אחת לכל מאסטר.
להגדרת המערכת שלנו שכוללת 6 צמתים, יהיו לנו 3 מאסטרים ו- 3 עבדים.
שים לב שהצמתים הראשונים 6 יתפקדו כ- מאסטרים (M) והשלושה הבאים יתפקדו כ- עבדים (S). העבד הראשון, כלומר 10.42.0.200:6379, ישקף את המאסטר הראשון, כלומר 10.42.0.247:6379, העבד השני ישקף את המאסטר השני, וכן הלאה.
הפקודה הבאה מעוצבת בצורה שהתוצאה תייצג את ההגדרה הלוגית שלנו למעלה.
# redis-cli --cluster create 10.42.0.247:6379 10.42.0.197:6379 10.42.0.132:6379 10.42.0.200:6379 10.42.0.21:6379 10.42.0.34:6379 --cluster-replicas 1
11. לאחר שיצרת את האשכול בהצלחה, הרץ את הפקודה הבאה על כל מארח (ציין את כתובת ה-IP שלו באמצעות הדגל -h) כדי לרשום את כל צמתי האשכול.
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes
תוכל לראות את כל צמתי האשכול, עם העבדים מציינים את המאסטרים שלהם, כפי שמוצג בתמונת המסך הבאה.
השדות השונים בסדר הבא: מזהה צומת, כתובת IP: פורט, דגלים, הפינג האחרון שנשלח, הפונג האחרון שהתקבל, אפוך תצורה, מצב קישור, חריצים (למאסטרים).
שלב 4: בדיקת כישלון העברת האשכול של Redis
12. בסעיף זה, נדגים איך לבדוק כישלון באשכול. תחילה, נשמור על המאסטרים.
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep master
גם, נשמור על העבדים של Redis.
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep slave
13. לאחר מכן, נעצור את שירות ה-Redis על אחד מצמתי המאסטר למשל 10.42.0.197 ונבדוק את כל צמתי המאסטר באשכול.
# systemctl stop redis # redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep master
מהתמונת המסך הבאה, תוכל לראות שהצומת 10.42.0.197:6367 נמצאת במצב כישלון והעבד שלה 10.42.0.21:6379 הוקם למאסטר.
14. כעת נפעיל שוב את שירות ה-Redis על הצומת שנכשלה ונבדוק את כל המאסטרים באשכול.
# systemctl start redis # redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep master
גם, נבדוק את העבדים באשכול כדי לאשר שהמאסטר שנכשל כעת הוא עבד.
# redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep slave
שלב 5: בדיקת שיבוץ הנתונים באשכול של Redis
15. מדובר בחלק האחרון שמסביר כיצד לאמת שיבוט נתוני האשף. נצור מפתח וערך באחד מהמאסטרים, ואז ננסה לקרוא אותו מכל צומת באשף כפי שמופיע להלן. נשתמש בקפיצים התכובים בין התגיות -c כדי לאפשר תמיכת אשף תחת הכלי redis-cli ולגשת לנתונים במצב אשף.
# redis-cli -c -h 10.42.0.247 -p 6379 set name 'TecMint.com' # redis-cli -c -h 10.42.0.247 -p 6379 get name # redis-cli -c -h 10.42.0.21 -p 6379 get name # redis-cli -c -h 10.42.0.132 -p 6379 get name # redis-cli -c -h 10.42.0.200 -p 6379 get name # redis-cli -c -h 10.42.0.197 -p 6379 get name # redis-cli -c -h 10.42.0.34 -p 6379 get name
אפשר לסכם ולומר כי אשף Redis היא הדרך המועדפת לקבל שיבוט אוטומטי, שיבוט וזמינות גבוהה. קיימים עוד מספר פרמטרים תצורה היטב עם תיעוד בקובץ /etc/redis.conf שמכיל מידע נוסף, ניתן למצוא עוד מידע במסמכים הרשמיים: הדרכה לאשף Redis ומפרט האשף Redis.
כלול זה מסיים את סדרת ההדרכים המפורטים השלושה על Redis. ניתן להשתמש בטופס משוב למטה כדי לפרסם שאלות או הערות.
Source:
https://www.tecmint.com/setup-redis-cluster-in-centos-8/