סנכרון זמן מדויק: הגדרת NTP/Chrony בשרתים

הגדרת NTP: מדוע השעונים בשרתים מתפצלים

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

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

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

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

מה נותנת סקאלת זמן אחידה בתשתית

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

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

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

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

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

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

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

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

הגדרת NTP: שלבי העבודה מהביקורת ועד למסירה

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

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

מסמכים וארטיפקטים שנשארים אצלכם

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

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

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

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

מה היה

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

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

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

מה שינו ומה נהיה

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

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

מה לעשות אם ברשת כבר פועל שרת זמן עצמאי

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

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

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

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

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

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

ספקות טכניים נפוצים בנוגע לסנכרון זמן

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

מה יקרה אם מקור הזמן יפסיק להשיב?

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

האם מותר להישען על פולים ציבוריים?

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

כמה זמן לוקח מעבר של צי שרתים?

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

נדון במשימת סנכרון הזמן שלכם

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

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

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