הגדרת אשכול etcd עבור קונפיגורציות של יישומים

מדוע אשכול etcd מאבד קוורום ומפיל שירותים

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

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

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

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

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

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

מה נותן אשכול etcd עמיד לתקלות: השפעה לפי מדדים

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

זמן שחזור לאחר כשל צומת

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

סוג כשל שנמנע: פער תצורה בין שירותים

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

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

מצבי פריסה של מאגר התצורה: השוואה

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

מרכז נתונים אחד

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

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

מספר אזורי זמינות

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

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

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

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

ביקורת המצב הנוכחי

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

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

בדיקת עמידות לתקלות בעומס

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

ערכת מסירה: תצורות, סכימות, מדיניות גישה

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

מדיניות גישה ותפקידי IAM

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

נוהלי תחזוקה ושחזור

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

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

מקרה בוחן: שחזור המאגר בלי לאבד תצורות

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

מה היה קודם: עריכות ידניות ופער בהגדרות

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

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

מה נהיה אחר כך: סכימה מנוהלת והחלפת צמתים

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

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

מה עושים אם המאגר כבר פרוס במרכז אחד?

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

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

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

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

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

ספקות טכניים של לקוחות: כשלי צמתים ועדכונים

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

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

איך משנים הרכב בלי השבתה?

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

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

איך משתכנעים שהגיבוי תקין?

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

נדבר על המשימה: נחזור עם הערכה ותוכנית עבודה

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

מה אנחנו מבקשים לצורך החישוב:

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

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