ניהול Tarantool: אשכול בזיכרון עמיד לתקלות

ניהול Tarantool: היכן הקלאסטר מאבד יציבות

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

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

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

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

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

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

מה נותן ניהול Tarantool: האפקט במספרים

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

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

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

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

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

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

מצבי עמידות לתקלות: השוואת אפשרויות

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

האפשרויות והמגבלות שלהן

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

סדר העבודות: מהאודיט ועד למסירה לתפעול

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

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

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

3. הגדרת הצמתים והתפקידים. פורסים קונפיגורציות, מגדירים תפקידים, מפעילים רפליקציה, ניטור וגיבוי עם בדיקת שחזור.

4. בדיקת ההחלפות. מוציאים צמתים מכלל פעולה בזה אחר זה ומודדים תוך כמה זמן נבחר צומת ראשי חדש וחוזרת הכתיבה. כל תרחיש — עם תוצאה מתועדת.

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

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

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

סכמות, מדיניות גישה ונהלי החלפה

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

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

מקרה בוחן: קלאסטר של חנות מקוונת תחת עומס מבצע מכירות

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

כבר פרץ התעבורה הראשון עם פתיחת המבצע הפיל את הצומת — השחזור נמשך כמה שעות, וכל אותו זמן לא בוצעו הזמנות.

מה שינינו

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

תוצאות היישום

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

במה שונה שרדינג מרפליקציה בפועל

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

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

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

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

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

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

ספקות טכניים לפני תחילת העבודות על הקלאסטר

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

האם אפשר להוסיף צומת ולעדכן את הקלאסטר בלי לעצור את הכתיבה?

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

מה עושים אם אין תיעוד לקלאסטר?

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

כיצד נשלטת צריכת הזיכרון?

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

מי אחראי לתמיכה לאחר היישום?

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

נדבר על המשימה: מה נדרש להערכת הקלאסטר שלכם

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

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

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