הגדרת מעבר כשל אוטומטי בעת תקלה: Patroni, Redis Sentinel

למה בלי failover אוטומטי השירות שוכב שעות

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

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

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

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

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

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

מה משתנה לאחר הטמעת החלפה בלי אדם

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

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

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

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

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

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

מצבי failover אוטומטי: ידני, אוטומטי, היברידי

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

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

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

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

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

1. ביקורת תשתית: מלאי צמתים, טופולוגיית רפליקציה, פיגור רפליקות, פסקי זמן נוכחיים ומי מחליף את התפקיד היום — תורן לפי הנחיה או סקריפט.
2. תכנון עמידות בכשלים: קוורום, מספר רפליקות סינכרוניות, התנהגות בעת אובדן קשר בין האתרים. בנפרד מנתחים פיצול אשכול, כששני הצדדים מחשיבים את עצמם לראשיים.
3. הגדרת שכבת הניהול — Patroni: סדרי עדיפויות להחלפה, מרווחי בדיקות חיים, סף התיישנות, סדר בחירת מנהיג חדש.
4. הגדרת גישת לקוחות: נקודת חיבור אחודה, כדי שהאפליקציה תעבור שינוי מנהיג בלי עריכת קונפיגורציות והפעלה מחדש.
5. בדיקת כשל בסביבת הייצור: מכבים צומת, מודדים זמן החלפה, אובדן רשומות והתנהגות האפליקציה. חזרות חוזרות עד לתוצאה משוחזרת.
6. נוהל תפעול: התראות, תחומי אחריות של התורנים, סדר החזרת צומת לאשכול וכללי נסיגה לתבנית הקודמת.
7. מסירה: תיעוד, תרשימים, הכשרת המשמרת וניתוח האירוע הראשון יחד עם הצוות שלכם.

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

קונפיגורציות, תרשימים ונהלים שנשארים אצלכם

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

• קונפיגורציית אשכול עובדת: פרמטרי Patroni (קוורום, פסקי זמן, מצב סינכרוני) ו-Redis Sentinel (quorum, זמן עד הכרזת צומת כלא זמין) עם הערה מדוע נבחר דווקא הערך הזה.
• תרשים עמידות בכשלים: טופולוגיית צמתים, נקודות כשל, שכבת קונצנזוס, התנהגות בעת פיצול רשת וסדר השחזור לאחר split-brain.
• כללי החלפה: באילו תנאים התפקיד עובר לרפליקה, מי יוזם את המעבר, מה קורה עם רפליקציה אסינכרונית ואובדן אפשרי של הטרנזקציות האחרונות.
• נוהל תורנות: רמות הפעלת התראות, תחום האחריות של התורן, נקודות הסלמה וצ'קליסט פעולות ראשונות לאחר כשל.
• יומן בדיקות: לוח תרגולים עם כיבוי מנהיג, מדידות זמן החלפה, בעיות שנמצאו עם סימון שהן טופלו.
• הנחיות לתורנים: תרחישים "המנהיג נפל", "אין קוורום", "הרפליקה פיגרה" עם פקודות אבחון וסדר נסיגה.
• תרשים ניטור: מדדי מצב האשכול, השהיית רפליקציה, מצב קונצנזוס, ספי התראות ושיוך לתורן.

ניתוח הטמעה: בסיס נתונים בעומס ומטמון לצידו

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

מה שינו

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

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

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

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

במה שונה החלפת תפקידים בבסיס נתונים לעומת מטמון?

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

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

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

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

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

מה שואלים הכי הרבה על עמידות בכשלים

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

מה יקרה בעת פיצול אשכול?

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

איך לבדוק החלפה בלי לעצור את השירות?

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

מי אחראי לתפעול לאחר ההפעלה?

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

נדון בתבנית עמידות הכשלים שלכם

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

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

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

תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית.