הגדרת ניטור אל-פסק (UPS) לשרתים (NUT / apcupsd)

מדוע ניטור UPS לא פועל ברגע הפסקת החשמל

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

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

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

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

מה נותנת בקרה מנוהלת של אספקת החשמל לשרתים

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

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

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

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

אפשרויות חיבור UPS למערכת הניטור

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

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

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

סדר היישום: מסקר ועד מסירה

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

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

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

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

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

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

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

מקרה בוחן: הסרנו כיבויים שגויים ב-40 שרתים

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

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

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

מה שינינו

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

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

מה השתנה

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

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

במה שונה תשאול רשתי מסוכן מקומי על השרת?

ההבדל הוא היכן חי הדרייבר של ה-UPS. בתשאול רשתי המצב נדלה מכרטיס מנוהל דרך SNMP או HTTP: המלקט כל כמה שניות לוקח טעינה, עומס ומתח. סוכן מקומי — למשל דרייבר מתוך Network UPS Tools — פועל על השרת עצמו ומחזיק את ההתקן דרך USB-HID או יציאה טורית.

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

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

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

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

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

ספקות בנוגע לבקרת אספקת חשמל הם בדרך כלל הנדסיים, לא ארגוניים: צי המקורות הטרוגני, מארח נפרד לשירות לא הוקצה, ואין מי שמוכן לבדוק את מדיניות הכיבוי על מתלים חיים. להלן מה ששואלים הכי часто לפני תחילת העבודה.

אין מארח נפרד — אפשר למקם את השירות לצד קיים?

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

אירועים אובדים בעת ניתוק קשר — מה עושים עם זה?

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

איך לבדוק תרחישים בלי לכבות מתלים באמת?

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

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

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

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

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