גילוי שירותים ב-etcd: אשכול עם TLS וניטור

מדוע גילוי שירותים מבוסס etcd מדרדר תחת עומס

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

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

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

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

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

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

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

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

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

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

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

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

מצבי גילוי שירותים: צד לקוח, צד שרת, היברידי

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

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

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

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

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

פריסת האשכול: ביקורת, TLS, בדיקת כשלים

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

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

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

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

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

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

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

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

מקרה בוחן: מרשם ל-40 שירותים בלי תיקונים ידניים

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

שיעור השינויים הידניים בניתוב היה 100%, ולמשמרת התורנות בחודש הגיעו 12–14 קריאות רק בגלל כתובות שגויות.

מה שינינו

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

מדדים לפני ואחרי

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

מה לעשות אם מרשם השירותים כבר פרוס במערכת אחרת?

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

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

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

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

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

שאלות טכניות נפוצות: עמידות לכשלים ותפעול

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

כיצד בנוי השחזור לאחר תקלה?

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

האם יש מרווח להרחבה?

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

מהן הדרישות לסביבה ולהרשאות?

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

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

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

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

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

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