כשל של הצומת הראשי של בסיס הנתונים מפיל את השירות: Stolon ב-Kubernetes
תצורה קלאסית עם צומת ראשי יחיד של PostgreSQL נשענת על הנחה אחת — שהצומת הזה חי. כל עוד הוא מגיב, הכתיבה מתבצעת והרפליקות מדביקות את הזרם.
כשל של הצומת הראשי של בסיס הנתונים עוצר לא רק את הכתיבה: גם חלק מהקריאה נתלה, האפליקציה ממתינה לתשובה, הפסקות הזמן מצטברות, החיבורים נערמים ונתקלים במגבלת ה-pool. זמן ההשבתה בגלל בסיס הנתונים נמדד במקרה הזה לא בזמן נפילת הצומת, אלא בזמן שיעבור עד שמישהו יספיק להגיב.
מכאן נכנסת לפעולה התאוששות ידנית של אשכול ה-DBMS. התורן מרים את הצומת, מברר איזו מהרפליקות היא העדכנית ביותר, מחליף תפקידים, מתקן את נקודת הכניסה ואת מחרוזת החיבור, ומחזיר את הרפליקה שפיגרה לפעילות.
כל צעד הוא החלטה של אדם תחת לחץ, ובחלון אי-הזמינות הזה טעות עולה יותר מהתקלה עצמה. אם האפליקציה הספיקה לכתוב נתונים, והראשי החדש עלה מרפליקה אחרת, את הפער סוגרים ידנית, תוך השוואת יומנים.
כאן בדיוק נמצאת נקודת הכשל של PostgreSQL בתצורה בעלת צומת יחיד: השאלה אינה אם הצומת ייפול, אלא כמה זמן ניקח לנו לעלות בחזרה ומה נאבד בדרך.
כל עוד המעבר מבוצע בידי אדם, חלון אי-הזמינות נמתח באופן צפוי, והיקף הרשומות האבודות תלוי בכמה מהר התורן הגיב וכמה עדכנית הייתה הרפליקה שנבחרה.
Stolon ב-Kubernetes מסיר את העבודה הזו מעל בני האדם: הוא מחזיק כמה צמתים של בסיס הנתונים, עוקב אחר מצב הראשי, בוחר ראשי חדש לפי עדכניות הנתונים ומעביר את התעבורה דרך נקודת גישה נפרדת. האפליקציה מתחברת מחדש לאותה כתובת, בלי להמתין שמהנדס יחזיר ידנית את האשכול לפעילות. בהמשך נפרט איך זה נסגר ומה נשאר מחוץ לאוטומציה.
מה נותן אשכול עמיד לתקלות: אפקט מדיד
עמידות לתקלות מתחילה במדידה כנה של מה שקורה עכשיו. מופע יחיד של בסיס הנתונים עם הרמה ידנית של רפליקה נותן חלון אי-זמינות של עשרות דקות: המהנדס מבחין בתקלה, מאשר שהבעיה אינה ברשת, מרים את הצומת מגיבוי, ומעביר את התעבורה.
כל מעבר כזה הוא פעולה תחת לחץ, ובדיוק בה נשברת לרוב שלמות הנתונים: שני צמתים מחשיבים את עצמם לראשיים, וחלק מהכתיבה עובר לעותק מיושן.
Stolon מסיר את הצעד הידני מהתרחיש הזה. האשכול מחזיק קוורום של רכיבי ניהול, מצב התפקידים נשמר במאגר תצורה מבוזר, ושכבת הניתוב מפנה חיבורים רק אל הצומת הראשי המאושר.
אובדן הצומת המוביל מפעיל החלפת תפקידים אוטומטית: הרפליקה עולה בדרגה, הניתוב נבנה מחדש, והאפליקציה מתחברת מחדש לאותה כתובת.
בערכים מדידים האפקט נראה כך: חלון אי-הזמינות של בסיס הנתונים מתקצר מעשרות דקות לשניות בודדות, שיעור המעברים האוטומטיים שואף למאה אחוזים — גם בתחזוקה מתוכננת וגם בתקלה פתאומית, ומספר ההתערבויות הידניות של המהנדס יורד לאפס בתרחישים הטיפוסיים.
בד בבד נעלם סוג שלם של כשלים: פערי רפליקות וכתיבה לצומת שפיגר כבר אינם תלויים בשאלה אם מישהו הספיק ללחוץ על הכפתור הנכון בלילה.
זמינות השירות מפסיקה להיות הבטחה והופכת לכמות ניתנת לבדיקה. אנחנו מכניסים לתקנון תרגילי בקרה — כיבוי מבוקר של צומת בשעות העבודה — כדי למדוד את זמן ההתאוששות על מערכת חיה, ולא להאמין לאומדן תיאורטי.
מצבי פריסה של האשכול: השוואת גישות
עמידות בסיס הנתונים לתקלות אינה בחירה בינארית בין «אשכול או לא אשכול», אלא ספקטרום של תצורות עם מחיר הטמעה שונה והתנהגות שונה בזמן תקלה. להלן האפשרויות שממש בוחרים ביניהן בתחילת הפרויקט, והמגבלות שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| גיבוי קר: דאמפים תקופתיים ושחזור על צומת נפרד | עומס קטן, השבתה של כמה שעות מקובלת | השחזור נמדד בשעות, העסקאות האחרונות אובדות ללא אפשרות שחזור |
| רפליקציה בזרם עם מעבר ידני | עומס צפוי, יש מהנדס תורן | המעבר תלוי באדם, חלון ההשבתה נמתח לזמן התגובה של התורן |
| אשכול בניהול Stolon ב-Kubernetes | נדרשים כשל אוטומטי והתאוששות עצמית של תפקידים | דורש קוורום תקין ומשמעת בעדכונים, ניפוי שגיאות מורכב יותר מאשר בצומת בודד |
| אשכול DBMS מנוהל אצל ספק | אין צוות תפעול פנימי | פחות שליטה על גרסאות, הרחבות ופרמטרי הליבה, תלות באתר הספק |
ההבדל המרכזי הוא מי מקבל את ההחלטה על המעבר. בשתי התצורות הראשונות זה אדם, ובאשכול בניהול אוטומטי — השירות עצמו: הוא עוקב אחר מצב הצמתים ומחליף תפקידים בלי מעורבות מפעיל.
מגבלות הרפליקציה נפוצות לכל האפשרויות: העברה בזרם היא כברירת מחדל אסינכרונית, ולכן חלק מהרשומות המאושרות האחרונות עשוי שלא להגיע לגיבוי, וזמן ההשהיה של הגיבוי משפיע ישירות על זמן ההתאוששות.
הבחירה מצטמצמת לשתי שאלות: כמה השבתה אתם מוכנים לסבול וכמה רשומות אחרונות מותר לאבד. התשובות לשאלות האלה הן שקובעות אם בכלל נדרש כשל אוטומטי או שמספיק גיבוי קר עם תקנון התאוששות ברור.
הטמעת Stolon ב-Kubernetes: שלבי העבודה ההנדסית
אי אפשר להוסיף עמידות לתקלות של אשכול DBMS ב-Kubernetes לאחר ההרצה — היא מתוכננת יחד עם הטופולוגיה, האחסון ותבנית החיבור של האפליקציות. להלן רצף העבודות להטמעת Stolon ב-Kubernetes: מביקורת התצורה הנוכחית ועד מסירת האשכול לתפעול עם פרוטוקול בדיקות.
- ביקורת התצורה והעומס. מפרקים כיצד האפליקציה מתחברת לבסיס הנתונים — דרך פרוקסי, מאגר חיבורים או ישירות, מהו פרופיל השאילתות והנפחים, והיכן נמצאת כיום נקודת הכשל היחידה.
- תכנון תצורה עמידה לתקלות. קובעים את מספר הרפליקות, פריסה לפי אזורי זמינות, קוורום לבחירת מנהיג, מצב רפליקציה סינכרונית וזמן מעבר יעד.
- הרכבת התצורה. פורסים צמתי keeper כמערכת עם כרכים קבועים, sentinel לבקרת מצב ולבחירה מחדש של המנהיג, וכתובות נפרדות לכתיבה ולקריאה.
- אחסון וגיבויים. בוחרים מחלקות דיסקים, מגדירים עותקים תקופתיים לאחסון אובייקטים ובודקים שחזור על סביבה נפרדת.
- בדיקה באמצעות תקלות. הורגים את המנהיג, מנתקים אזור זמינות, קוטעים את הקשר עם מאגר מצב האשכול — מתעדים את זמן המעבר ומוודאים שהאפליקציות מתחברות מחדש בלי פעולות ידניות.
- מסירה לתפעול. תקנון תורנויות, התראות על היעדר מנהיג ועל פיגור רפליקות, תרחישי תחזוקה מתוכננת, והדרכת צוות הלקוח.
בתוצאה — זמן התאוששות צפוי לאחר כשל של צומת או אזור, היעדר מעברים ידניים, וסט פעולות ברור למשמרת התורנית.
מה אנחנו מוסרים לידיים: תצורות, תרשימים, תקנונים
אשכול שעובד אבל מובן רק למי שהרכיב אותו הוא השבתה נדחית. לכן המסירה לידיים אינה ארכיון קבצים, אלא ערכה שלפיה המהנדס שלכם ירִים בעצמו רפליקה, יבצע מעבר מתוכנן ויחזור למצב הקודם בלי העזרה שלנו.
- תרשים עמידות לתקלות — טופולוגיה ותפקידי צמתים, נקודות כשל, התנהגות האשכול בעת אובדן המאסטר או אזור, וסדר בחירת המנהיג החדש.
- תצורות האשכול — מניפסטים ופרמטרים של סביבות במאגר הקוד, משאבים ומגבלות, כללי הצבת פודים, ופרופילים נפרדים לסביבת הייצור ולסביבת הבדיקות.
- מדיניות גישה לבסיס הנתונים — תפקידי אפליקציות, מנהלים ושירותי מערכת, בעלות על סכימות, סדר הענקה ושלילה של הרשאות, סבב פרטי התחברות, ואחסון סודות.
- תקנון גיבוי — לוח זמנים של עותקים מלאים ואינקרמנטליים, עומק שמירה, הוצאה מחוץ לאשכול, ובדיקת שחזור לפי לוח זמנים.
- תיעוד לאשכול DBMS — תרחישים צעד-אחר-צעד לפעולות מתוכננות ולמצבי חירום, סדר התערבות ידנית, וגבולות אחריות.
- ניטור והתראות — אילו מדדים אנחנו בודקים, באילו ספים עולה התראה, ומה עושים בדקות הראשונות לכל אות.
מוסרים לא כקישור למאגר קוד, אלא בהדגמה על סביבת בדיקות: מציגים כשל של צומת, מעבר ושחזור מעותק, ואז המהנדסים שלכם חוזרים על זה בעצמם. לאחר מכן נשאר לצוות מקור אמת אחד לגבי האשכול, ולפנות אלינו יש רק בשינוי ארכיטקטורה או בהרחבה.
מקרה בוחן: איך האשכול שרד כשל של צומת בלי פעולות ידניות
לפני ההטמעה האשכול נשען על צומת מאסטר אחד: כשזה כשל, האפליקציה קיבלה שגיאות חיבור, ואת הרפליקה הרימו ידנית — המהנדס התחבר, בדק את הפיגור והעביר את התעבורה. זה ארך בין עשרים דקות לחצי שעה, ובכל פעם נותר סיכון להעלות כמאסטר רפליקה עם פיגור שלא נסגר ולאבד את העסקאות האחרונות.
פרסנו Stolon מעל Kubernetes: בכל צומת פועל שומר מצב, משגיחים נפרדים עוקבים אחר בריאות המאסטר, ונקודת הכניסה לאפליקציות מפנה את התעבורה לפי החלטת הקוורום. הקידום מופעל מעצמו ברגע שהמאסטר מפסיק להגיב — האדם כבר אינו משתתף בתצורה.
מה מאשרים המדדים
המעבר מתבצע בתוך עשרות שניות, מספר ההתערבויות הידניות ברבעון — אפס, והפיגור של הרפליקות נשמר בגבולות שבהם עסקאות מאושרות אינן אובדות. זמן ההשבתה בכשל צומת התקצר מחצי שעה לזמן שהאפליקציה עוברת בשלום על חזרות של בקשות.
לפני העלייה לסביבת הייצור הרצנו את התרחישים בסביבת עומס: כיבינו צומת עם המאסטר, צומת עם המשגיחים, קטענו את הקשר עם מאגר המצב, ומדדנו כמה זמן נמשכת ההשבתה. כל הרצה נתנה גבול ברור של עמידות לתקלות — כמה צמתים האשכול שורד בלי אובדן נתונים ובאיזה תרחיש בכל זאת נדרשת התערבות.
מה עושים אם בסיס הנתונים כבר פרוס על צומת אחד?
אין צורך להרוס צומת בודד פרוס ולהקים אשכול מאפס — המעבר מתבצע על שירות חי. תחילה מרימים לצידו רפליקה שמדביקה את הצומת הראשי לפי זרם השינויים, ורק לאחר מכן מחליפים תפקידים. עצירה נדרשת רק ברגע החלפת נקודת הכניסה, ולא לכל אורך ההגירה: החלון נמדד בדקות, ולא בשעות השבתה.
סדר המעבר הוא כזה: ליצור תמונת מצב עקבית ולתעד את הפרמטרים הנוכחיים, לפרוס רפליקה ולהמתין לפיגור אפס, להעביר אותה למצב של צומת ראשי, ולוודא שהצומת הקודם נשאר קריא וסינכרוני. הצעד האחרון — העברת האפליקציה לשם השירות במקום לכתובת ישירה של פוד מסוים. תוכנית מעבר כזו מתועדת לפני תחילת העבודה, כך שכל צעד ניתן לבדיקה ולעצירה.
התנאי המרכזי למעבר חלק הוא שהאפליקציה כבר פונה לבסיס הנתונים לפי שם השירות ולא לפי קישור ישיר לצומת. אז החלפת תפקיד ב-Stolon ב-Kubernetes היא מעבר לעותק אחר בתוך שניות, בלי עריכות בתצורת השירות ובלי הפעלה מחדש שלו. אם האפליקציה עדיין מחזיקה כתובת ישירה, סוגרים את הנקודה הזו ראשונה — לפני שאנחנו נוגעים בתפקידים.
החזרה לאחור מתוכננת מראש: הצומת הקודם נשאר בפעילות כגיבוי, תמונת המצב נשמרת עד סוף תקופת התצפית, וכללי החזרה מתוארים צעד-אחר-צעד עבור התורן. אם לאחר המעבר מתגלים פערים, השירות חוזר לצומת הקודם באותה שיטה — בהחלפת תפקיד וכתובת. אנחנו מנתחים את התצורה הספציפית ומציעים תוכנית מעבר המתאימה לאופן העבודה שלכם.
ספקות הנדסיים שאנחנו מסירים לפני ההתחלה
לפני ההתחלה עולה אותו סט שאלות: מה יקרה לכתיבה בזמן פיצול האשכול, איזו רפליקציה נדרשת לבסיס הנתונים הזה, איך לעדכן אותו בלי השבתה, האם הפתרון ישתלב בסביבה הקיימת ומי אחראי על האירוע. אנחנו עונים ישירות, לפני תחילת העבודה.
איך Stolon מגן מפני פיצול האשכול?
המאסטר נבחר דרך מאגר קונצנזוס, ולא לפי «מי הגיב ראשון». צומת שאיבד את הקשר איתו מפסיק להיות מאסטר וסוגר את קליטת הכתיבה — שני מאסטרים מתחרים לא נוצרים.
רפליקציה סינכרונית או אסינכרונית?
סינכרונית שוללת אובדן של עסקאות מאושרות, אבל קושרת את הכתיבה למספר הרפליקות החיות. אסינכרונית סובלת טוב יותר אובדן צמתים, אך במעבר אובדים האישורים האחרונים. את הבחירה קובעים לפי פרופיל העומס וחלון האובדן המותר.
מה עם התאמה לסביבה הקיימת?
משווים את גרסת בסיס הנתונים וההרחבות, מחלקת האחסון, הרשאות הרשת, הניטור והגיבוי. אם משהו בסביבה לא שורד החלפת תפקיד של המאסטר — אומרים זאת מיד, ולא ברגע העלייה.
איך לתחזק אשכול DBMS בלי עצירה?
מעבר מתוכנן, עדכון גרסה ראשית והחלת פרמטרים מתבצעים בגלים: תחילה הרפליקות, אחר כך המאסטר. בסיס הנתונים מקבל כתיבה לאורך כל התהליך.
מי אחראי על התמיכה לאחר ההרצה?
מצדנו — התצורה, האוטומציה של המעברים ותבנית הגיבוי; מצד הלקוח — הרשאות גישה, משאבי הפלטפורמה ושינויים באפליקציות. את הגבול מתעדים בכתב לפני ההתחלה.
נדון במשימה: מה נדרש מכם ומה אנחנו עושים
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם ניסוחים כלליים, אנחנו צריכים פרוסה של התשתית שלכם. לפיה אנחנו מחשבים את הרכב האשכול, נקודות הכשל ולוחות הזמנים של ההטמעה — ומוסרים זאת במסמך אחד שאפשר להציג בפני הצוות.
- התצורה הנוכחית: צומת אחד או רפליקציה ידנית, היכן יושב המאסטר, ואיך האפליקציות עוברות בזמן תקלה;
- הרכב האשכול: מספר מופעי בסיס הנתונים, נפח הנתונים, הגידול היומי ויחס הקריאה לכתיבה;
- פלטפורמה: גרסת Kubernetes, קיום של כמה אזורי זמינות, ואיך מוקצים כרכים קבועים;
- רשת והרשאות: איך האפליקציות מוצאות את המאסטר המעודכן, האם יש שכבת פרוקסי, ואילו מדיניות רשת חלות;
- דרישות לעמידות בתקלות: זמן אי-זמינות מותר לכתיבה ולקריאה, והאם נדרשת חזרה אוטומטית לאחור;
- חלונות עבודה: מתי מותר להעביר את סביבת הייצור, האם יש סביבת בדיקות וסט נתונים קרוב למציאות;
- יכולת תצפית: לאן נאספים מדדים ולוגים, ואילו התראות כבר מוגדרות.
זה מספיק כדי להציע תצורה קונקרטית: כמה מופעי בסיס נתונים, היכן למקם את המאסטר ואת הרפליקות, ואיך האפליקציות מוצאות את המאסטר החדש לאחר המעבר. בהמשך פורסים את Stolon ומתארים את סדר העברת הנתונים בלי עצירה ממושכת של הכתיבה.
תוכנית העבודה מחולקת לשלבים: הכנת הסביבות, פריסה, העברה, תרגול המעבר והעלייה לתפעול הייצור. לכל שלב מתעדים מה אנחנו עושים ומה נדרש מהצוות שלכם — ורק לאחר מכן נוקבים בלוחות הזמנים של ההטמעה. תארו את המשימה — נחזור עם הערכה ותוכנית.