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

איך הייתם מרגישים אם ביום קיץ בהיר אחד מרכז הנתונים עם הציוד שלכם היה נראה כך?

שלום לכולם! שמי דמיטרי סמסונוב, אני עובד כמנהל מערכת מוביל ב"חברי כיתה" התמונה מציגה את אחד מארבעת מרכזי הנתונים שבהם מותקן הציוד המשרת את הפרויקט שלנו. מאחורי הקירות הללו יש כ-4 ציוד: שרתים, מערכות אחסון נתונים, ציוד רשת וכו'. - כמעט ⅓ מכל הציוד שלנו.
רוב השרתים הם לינוקס. ישנם גם כמה עשרות שרתים ב-Windows (MS SQL) - המורשת שלנו, אותה אנו נוטשים באופן שיטתי כבר שנים רבות.
אז, ב-5 ביוני 2019 בשעה 14:35, מהנדסים באחד ממרכזי הנתונים שלנו דיווחו על אזעקת שריפה.

הכחשה

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

כעס

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

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

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

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

14:53. מונה רכז חירום.

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

מיקוח

15:01. אנחנו מתחילים להשבית שרתים שאינם קשורים לייצור.
15:03. אנו מכבים נכון את כל השירותים השמורים.
זה כולל לא רק חזיתות (שבשלב זה משתמשים כבר לא ניגשים אליהם) ושירותי העזר שלהם (לוגיקה עסקית, מטמונים וכו'), אלא גם מסדי נתונים שונים עם פקטור שכפול 2 או יותר (קסנדרה, אחסון נתונים בינאריים, אחסון קר, NewSQL וכו.).
15: 06. התקבל מידע כי שריפה מאיימת על אחד מאולמות הדאטה סנטר. אין לנו ציוד בחדר הזה, אבל העובדה שהאש יכולה להתפשט מהגג לאולמות משנה מאוד את תמונת המתרחש.
(מאוחר יותר התברר שאין איום פיזי על האולם, שכן הוא נסגר הרמטית מהגג. האיום היה רק ​​על מערכת הקירור של אולם זה).
15:07. אנו מאפשרים ביצוע פקודות בשרתים במצב מואץ ללא בדיקות נוספות (בלי המחשבון האהוב עלינו).
15:08. הטמפרטורה באולמות היא בגבולות הרגילים.
15: 12. נרשמה עלייה בטמפרטורה באולמות.
15:13. יותר ממחצית מהשרתים במרכז הנתונים כבויים. בוא נמשיך.
15:16. הוחלט לכבות את כל הציוד.
15:21. אנו מתחילים לכבות את החשמל לשרתים חסרי מצב מבלי לכבות נכון את האפליקציה ומערכת ההפעלה.
15:23. קבוצה של אנשים האחראים על MS SQL מוקצים (יש מעט מהם, התלות של השירותים בהם אינה גדולה, אך הליך שחזור הפונקציונליות אורך זמן רב יותר ומסובך יותר מאשר, למשל, קסנדרה).

דיכאון

15: 25. התקבל מידע על כיבוי חשמל בארבעה אולמות מתוך 16 (מס' 6, 7, 8, 9). הציוד שלנו ממוקם באולמות 7 ו-8. אין מידע על שני האולמות שלנו (מס' 1 ו-3).
בדרך כלל, בזמן שריפות, אספקת החשמל מנותקת מיד, אך במקרה זה, הודות לעבודה המתואמת של הכבאים והצוות הטכני של מרכז הנתונים, הוא לא נכבה בכל מקום ולא מיד, אלא לפי הצורך.
(מאוחר יותר התגלה שהחשמל לא כובה באולמות 8 ו-9.)
15:28. אנחנו מתחילים לפרוס מסדי נתונים של MS SQL מגיבויים במרכזי נתונים אחרים.
כמה זמן זה ייקח? האם יש מספיק קיבולת רשת לכל המסלול?
15: 37. נרשמה כיבוי של חלקים מסוימים ברשת.
ההנהלה ורשת הייצור מבודדים פיזית זה מזה. אם רשת הייצור זמינה, אז אתה יכול ללכת לשרת, לעצור את היישום ולכבות את מערכת ההפעלה. אם זה לא זמין, אז אתה יכול להיכנס דרך IPMI, לעצור את היישום ולכבות את מערכת ההפעלה. אם אין אף אחת מהרשתות, אז אתה לא יכול לעשות כלום. "תודה, קאפ!", תחשוב.
"ובאופן כללי, יש הרבה מהומה", אולי תחשוב גם.
העניין הוא ששרתים, גם בלי שריפה, מייצרים כמות עצומה של חום. ליתר דיוק, כשיש קירור הם מייצרים חום, וכשאין קירור יוצרים תופת גיהנום, שבמקרה הטוב תמיס חלק מהציוד ותכבה חלק אחר, ובמקרה הרע... אש בתוך האולם, שכמעט מובטחת תהרוס הכל.

15:39. אנו מתקנים בעיות במסד הנתונים conf.

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

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

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

אימוץ

15:51. כל השרתים מלבד MS SQL כובו באמצעות IPMI מבלי להיכבה כראוי.
האם אתה מוכן לניהול שרת מאסיבי באמצעות IPMI במידת הצורך?

עצם הרגע שבו מסתיים חילוץ הציוד במרכז הנתונים בשלב זה. כל מה שאפשר לעשות כבר נעשה. חלק מהקולגות יכולים לנוח.
16: 13. התקבל מידע כי צינורות פריאון ממזגנים פרצו על הגג - הדבר יעכב את השקת מרכז הנתונים לאחר ביטול השריפה.
16:19. על פי נתונים שהתקבלו מהצוות הטכני של מרכז הנתונים, עליית הטמפרטורה באולמות נעצרה.
17:10. מסד הנתונים conf שוחזר. כעת נוכל לשנות את הגדרות האפליקציה.
למה זה כל כך חשוב אם הכל סובלני לתקלות ועובד גם בלי דאטה סנטר אחד?
ראשית, לא הכל סובלני לתקלות. ישנם שירותים משניים שונים שעדיין לא שרדו מספיק תקלה במרכז הנתונים, וישנם מסדי נתונים במצב המתנה מאסטר. היכולת לנהל הגדרות מאפשרת לך לעשות כל מה שצריך כדי למזער את השפעת ההשלכות של תאונה על המשתמשים גם בתנאים קשים.
שנית, התברר שפעילות מרכז הנתונים לא תשוחזר במלואה בשעות הקרובות, ולכן היה צורך לנקוט בצעדים על מנת להבטיח שחוסר זמינות העתקים לטווח ארוך לא תוביל לבעיות נוספות כמו דיסקים מלאים ב מרכזי הנתונים הנותרים.
17:29. זמן פיצה! אנחנו מעסיקים אנשים, לא רובוטים.

שיקום

18:02. באולמות מס' 8 (שלנו), 9, 10 ו-11 הטמפרטורה התייצבה. אחד מאלה שנשאר לא מקוון (מס' 7) מכיל את הציוד שלנו, והטמפרטורה שם ממשיכה לעלות.
18:31. נתנו אישור להפעיל את הציוד באולמות מס' 1 ו-3 - אולמות אלו לא נפגעו מהשריפה.

נכון לעכשיו, שרתים מושקים באולמות מס' 1, 3, 8, החל מהקריטיים שבהם. נבדקת הפעולה הנכונה של כל השירותים הפועלים. עדיין יש בעיות באולם מס' 7.

18:44. הצוות הטכני של מרכז הנתונים גילה כי בחדר מס' 7 (שבו נמצא רק הציוד שלנו) שרתים רבים אינם כבויים. לפי הנתונים שלנו, נותרו שם 26 שרתים מקוונים. לאחר בדיקה שנייה, אנו מוצאים 58 שרתים.
20:18. טכנאי מרכזי נתונים מפריחים אוויר דרך חדר לא ממוזג דרך תעלות ניידות העוברות במסדרונות.
23:08. המנהל הראשון נשלח הביתה. מישהו צריך לישון בלילה כדי להמשיך לעבוד מחר. בשלב הבא נשחרר עוד כמה מנהלי מערכת ומפתחים.
02:56. השקנו את כל מה שאפשר להשיק. אנחנו עושים הרבה בדיקות של כל השירותים באמצעות בדיקות אוטומטיות.

03:02. מיזוג האוויר באולם ה-7 האחרון שוחזר.
03:36. הבאנו את החזיתות במרכז הנתונים לרוטציה ב-DNS. מרגע זה מתחילה להגיע תנועת משתמשים.
אנחנו שולחים את רוב הצוות האדמיניסטרטיבי הביתה. אבל אנחנו משאירים כמה אנשים מאחור.

שאלות נפוצות קטנות:
ש: מה קרה מ-18:31 עד 02:56?
ת: בעקבות "תוכנית הפעולה לאסון", אנו משיקים את כל השירותים, החל מהחשובים שבהם. במקרה זה, הרכז בצ'אט מנפיק את השירות למנהל חינמי, שבודק האם מערכת ההפעלה והאפליקציה התחילו, האם יש שגיאות והאם האינדיקטורים תקינים. לאחר השלמת ההשקה הוא מדווח לצ'אט שהוא פנוי ומקבל שירות חדש מהרכז.
התהליך מואט עוד יותר על ידי חומרה כושלת. גם אם הפסקת מערכת ההפעלה וכיבוי השרתים עברה כהלכה, חלק מהשרתים לא חוזרים עקב כשל פתאומי של דיסקים, זיכרון ושלדה. כאשר החשמל אובד, שיעור הכשלים עולה.
ש: למה אתה לא יכול פשוט להריץ הכל בבת אחת, ואז לתקן את מה שעולה בניטור?
ת: הכל חייב להיעשות בהדרגה, כי יש תלות בין שירותים. והכל צריך להיבדק מיד, בלי לחכות למעקב - כי עדיף לטפל בבעיות מיד, בלי לחכות שהן יחמירו.

7:40. המנהל האחרון (הרכז) הלך לישון. העבודה של היום הראשון הסתיימה.
8:09. המפתחים הראשונים, מהנדסי מרכז הנתונים והמנהלים (כולל הרכז החדש) החלו בעבודות שיקום.
09:37. התחלנו להעלות את אולם מס' 7 (האחרון).
במקביל, אנו ממשיכים לשחזר את מה שלא תוקן בחדרים אחרים: החלפת דיסקים/זיכרון/שרתים, תיקון כל מה ש"צורב" בניטור, החלפת תפקידים בחזרה בסכימות מאסטר-המתנה ועוד דברים קטנים, מהם יש. למרות זאת די הרבה.
17:08. אנו מאפשרים כל עבודה קבועה עם ייצור.
21:45. מלאכת היום השני הושלמה.
09:45. היום יום שישי. יש עדיין לא מעט בעיות קטנות בניטור. סוף השבוע בפתח, כולם רוצים להירגע. אנחנו ממשיכים לתקן באופן מאסיבי את כל מה שאנחנו יכולים. משימות ניהול רגילות שהיו יכולות להידחות נדחו. הרכז חדש.
15:40. לפתע מחצית מערימת ציוד רשת Core במרכז נתונים אחר הופעלה מחדש. חזיתות הוצאו מסיבוב כדי למזער סיכונים. אין השפעה למשתמשים. מאוחר יותר התברר כי מדובר בשלדה פגומה. הרכז עובד על תיקון שתי תאונות בו זמנית.
17:17. פעולת הרשת במרכז נתונים אחר שוחזרה, הכל נבדק. מרכז הנתונים מועבר לסיבוב.
18:29. הסתיימה עבודת היום השלישי ובכלל השיקום לאחר התאונה.

אחרית דבר

04.04.2013/XNUMX/XNUMX, ביום של שגיאת 404, "חברים לכיתה" שרד את התאונה הגדולה ביותר במשך שלושה ימים הפורטל לא היה זמין לחלוטין או חלקי. לאורך כל הזמן הזה, יותר מ-100 אנשים מערים שונות, מחברות שונות (שוב תודה רבה!), מרחוק וישיר במרכזי נתונים, באופן ידני ואוטומטי, תיקנו אלפי שרתים.
הסקנו מסקנות. כדי שזה לא יקרה שוב, ביצענו וממשיכים לבצע עבודות נרחבות עד היום.

מהם ההבדלים העיקריים בין התאונה הנוכחית ל-404?

• יש לנו "תוכנית פעולה לתאונות". אחת לרבעון, אנו עורכים תרגילים - אנו משחקים במצב חירום, שקבוצת מנהלים (כולם בתורם) חייבת לבטל באמצעות "תוכנית חירום". מנהלי מערכת מובילים ממלאים בתורו את תפקיד הרכז.
• מדי רבעון, במצב בדיקה, אנו מבודדים מרכזי נתונים (כולם בתורם) באמצעות רשתות LAN ו-WAN, מה שמאפשר לנו לזהות מיידית צווארי בקבוק.
• פחות דיסקים שבורים, כי החמרנו את הסטנדרטים: פחות שעות פעילות, סף מחמיר ל-SMART,
• נטשנו לחלוטין את BerkeleyDB, מסד נתונים ישן ולא יציב שדרש הרבה זמן להתאושש לאחר הפעלה מחדש של השרת.
• צמצמנו את מספר השרתים עם MS SQL וצמצמנו את התלות בשאר השרתים.
• יש לנו משלנו ענן - ענן אחד, שבו אנו מעבירים באופן פעיל את כל השירותים כבר שנתיים. הענן מפשט מאוד את כל מחזור העבודה עם האפליקציה, ובמקרה של תאונה הוא מספק כלים ייחודיים כמו:
  • עצירה נכונה של כל היישומים בלחיצה אחת;
  • העברה קלה של יישומים משרתים כושלים;
  • השקה אוטומטית מדורגת (לפי סדר עדיפות השירותים) של מרכז נתונים שלם.

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

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

איך מתרחשות התאונות שלך?

מקור: www.habr.com