אוטומציה של החלפת דיסק עם Ansible

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

מאמר זה הוא סוג של תעתיק הופעות ב- HighLoad+ 2018

בניית תהליך החלפת דיסק

קודם כמה מספרים

OK הוא שירות ענק המשמש מיליוני אנשים. משרתים אותו על ידי כ-7 שרתים, הממוקמים ב-4 מרכזי נתונים שונים. השרתים מכילים יותר מ-70 אלף דיסקים. אם עורמים אותם זה על גבי זה, מקבלים מגדל בגובה של יותר מקילומטר אחד.

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

תקריות

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

התקני אחסון אינם יוצאי דופן. מצבם מפוקח על ידי Zabbix. אנו עוקבים אחר הודעות ב-Syslog לאיתור שגיאות כתיבה/קריאה, מנתחים את המצב של פשיטות HW/SW, עוקבים אחר SMART ומחשבים בלאי עבור כונני SSD.

כיצד הוחלפו דיסקים לפני כן

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

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

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

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

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

נוהל החלפה חדש

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

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

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

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

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

בעבר זה היה ככה:

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

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

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

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

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

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

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

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

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

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

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

• בעת בניית הליך, עליך לאסוף מידע ממקורות שונים.
  חלק מהמנהלים שלנו לא ידעו שהמהנדס משנה את הדיסקים בעצמו. חלק מהאנשים חשבו שסנכרון MD RAID מטופל על ידי מהנדסים, למרות שלחלקם אפילו לא הייתה גישה לעשות זאת. כמה מהנדסים מובילים עשו זאת, אבל לא תמיד כי התהליך לא תואר בשום מקום.
• ההליך צריך להיות פשוט ומובן.
  קשה לאדם לזכור שלבים רבים. יש למקם את הסטטוסים השכנים החשובים ביותר בג'ירה במסך הראשי. אתה יכול לשנות את שמם, לדוגמה, אנו קוראים לבעיה מוכנה לשינוי. וניתן להסתיר סטטוסים אחרים בתפריט נפתח כך שהם לא יפגעו בעין. אבל עדיף לא להגביל אנשים, לתת להם את ההזדמנות לעשות את המעבר.
  הסבר את הערך של חדשנות. כשאנשים מבינים, הם מקבלים יותר את הנוהל החדש. היה לנו מאוד חשוב שאנשים לא ילחצו על כל התהליך, אלא יעקבו אחריו. ואז בנינו על זה אוטומציה.
• חכה, נתח, תבין.
  לקח לנו כחודש לבנות את הנוהל, היישום הטכני, הפגישות והדיונים. והיישום לוקח יותר משלושה חודשים. ראיתי איך אנשים מתחילים לאט לאט להשתמש בחדשנות. הייתה הרבה שליליות בשלבים הראשונים. אבל זה היה בלתי תלוי לחלוטין בהליך עצמו וביישום הטכני שלו. לדוגמה, מנהל אחד לא השתמש ב-Jira, אלא בתוסף Jira ב-Confluence, וחלק מהדברים לא היו זמינים לו. הראינו לו את Jira, והפרודוקטיביות של המנהל גדלה הן עבור משימות כלליות והן עבור החלפת דיסקים.

אוטומציה של החלפת דיסקים

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

מכיוון שכעת תהליך ההחלפה שלנו מחולק לשלבים שלכל אחד מהם יש מבצע ספציפי ורשימת פעולות, נוכל לאפשר אוטומציה בשלבים, ולא בבת אחת. לדוגמה, את השלב הפשוט ביותר - Ready (בדיקת סנכרון RAID/נתונים) ניתן להאציל בקלות לבוט. כשהבוט למד קצת, אפשר לתת לו משימה חשובה יותר - הכנסת הדיסק לסיבוב וכו'.

הגדרות גן החיות

לפני שנדבר על הבוט, בואו נצא לסיור קצר אל גן החיות של המתקנים שלנו. קודם כל, זה נובע מהגודל העצום של התשתית שלנו. שנית, אנו מנסים לבחור את תצורת החומרה האופטימלית עבור כל שירות. יש לנו כ-20 דגמי חומרה RAID, בעיקר LSI ו-Adaptec, אבל יש גם HP ו-DELL של גרסאות שונות. לכל בקר RAID יש כלי ניהול משלו. ערכת הפקודות והנפקתן עשויות להיות שונות מגרסה לגרסה עבור כל בקר RAID. היכן שלא נעשה שימוש ב-HW-RAID, ניתן להשתמש ב-mdraid.

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

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

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

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

תכנית כללית

בואו נסתכל על סכימת האוטומציה הכללית תוך שימוש באירוע אחד כדוגמה. Zabbix מזהה שדיסק ה-sdb כשל, ההדק נדלק, ונוצר כרטיס בג'ירה. המנהל הסתכל על זה, הבין שלא מדובר בשכפול ולא ב-false positive, כלומר צריך לשנות את הדיסק, והעביר את הכרטיס ל-In progress.

אפליקציית DiskoBot, שנכתבה ב- Python, בודקת מדי פעם את Jira בחיפוש אחר כרטיסים חדשים. הוא מבחין שהופיע כרטיס In progress חדש, השרשור המתאים מופעל, מה שמפעיל את ספר המשחקים ב-Ansible (זה נעשה עבור כל סטטוס ב-Jira). במקרה זה, Prepare2change מופעל.

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

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

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

עכשיו בואו נדבר על כמה מרכיבים של המערכת.

דיסקובוט

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

מרווחי JQL ומרווחי סקר מוגדרים בקובץ התצורה של היישום.

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

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

ובין כרטיסים עם סטטוס מוכן, כרטיסים עם התווית dbot_ignore מסוננים. אגב, אנו משתמשים בתוויות Jira הן עבור סינון כזה והן עבור סימון כרטיסים כפולים ואיסוף נתונים סטטיסטיים.

אם ספר הפעלה נכשל, Jira מקצה את התווית dbot_failed כך שניתן יהיה למיין אותה מאוחר יותר.

יכולת פעולה הדדית עם Ansible

האפליקציה מתקשרת עם Ansible באמצעות Ansible Python API. ל-playbook_executor נעביר את שם הקובץ וקבוצת משתנים. זה מאפשר לך לשמור על פרויקט Ansible בצורה של קבצי yml רגילים, במקום לתאר אותו בקוד Python.

גם ב-Ansible, דרך *extra_vars*, שם מכשיר החסימה, סטטוס הכרטיס, וכן ה-callback_url שמכיל את מפתח issue - הוא משמש להתקשרות חוזרת ב-HTTP.

עבור כל השקה, נוצר מלאי זמני, המורכב ממארח ​​אחד והקבוצה שאליה מארח זה שייך, כך ש-group_vars מוחלים.

הנה דוגמה למשימה המיישמת HTTP callback.

אנו מקבלים את התוצאה של ביצוע ספרי משחק באמצעות Callaback(ים). הם משני סוגים:

• תוסף התקשרות חוזר, הוא מספק נתונים על תוצאות הביצוע של ספרי משחק. הוא מתאר את המשימות שהושקו, הושלמו בהצלחה או שלא בהצלחה. התקשרות חוזרת זו נקראת כאשר ספר ההשמעה סיים לשחק.
• התקשרות חוזרת של HTTP לקבלת מידע בזמן הפעלת ספר הפעלה. במשימה Ansible אנו מבצעים בקשת POST/GET לאפליקציה שלנו.

משתנים מועברים דרך HTTP callback(ים) שהוגדרו במהלך ביצוע ה-Playbook ושאנחנו רוצים לשמור ולהשתמש בריצות עוקבות. אנו כותבים את הנתונים האלה ב-sqlite.

אנו גם משאירים הערות ומשנים את סטטוס הכרטיס באמצעות HTTP callback.

התקשרות חוזרת של HTTP

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

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

והנה דוגמה מתוך ספר המשחקים, שבו אנו מוציאים דיסק מהתקן MD:

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

משימה זו מעבירה את כרטיס Jira למצב "מוכן לשינוי" ומוסיפה הערה. כמו כן, המשתנה mdam_data מאחסן רשימה של התקני md שמהם הוסר הדיסק, ו-parted_info מאחסן dump מחיצה מ-parted.

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

מצב בדיקה אפשרי

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

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

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

כשעברנו את האימות והבנו שאפשר להריץ את Ansible לא רק במצב ריצה יבשה, יצרנו כפתור Run Diskobot ב-Jira כדי להפעיל את אותו פלייבוק עם אותם משתנים על אותו מארח, אבל במצב רגיל.

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

מבנה ספרי משחק

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

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

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

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

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

חקירה.yml

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

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

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

prepare2change.yml

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

במקרה הפשוט ביותר, אנחנו מדברים על הסרת דיסק מ-HW/MD RAID.

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

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

change.yml

לאחר החלפת דיסק, אנו בודקים תחילה את זמינותו.

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

על אילו תכונות אנחנו מסתכלים?ספירת מגזרים שהוקצו מחדש (5) < 100
ספירת סקטור ממתינה נוכחית (107) == 0

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

ready.yml

המקרה הפשוט ביותר: בדיקת סנכרון פשיטה של ​​HW/SW או סיום סנכרון נתונים באפליקציה.

API של יישומים

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

• סטָטוּס. סטטוס של אשכול או דיסק כדי להבין אם ניתן לעבוד איתו;
• התחל הפסק. הפעלה/כיבוי של דיסק;
• העבר/שחזר. העברת נתונים ושחזור נתונים במהלך ואחרי החלפה.

לקחים מ-Ansible

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

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

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

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

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

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

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

אם אתה רוצה לחזור על הניסיון שלנו עם Ansible API, זכור שני דברים:

• לא ניתן לתת פסק זמן ל-Playbook_executor ול-Playbooks באופן כללי. יש פסק זמן בהפעלה של ssh, אבל אין פסק זמן בספר המשחקים. אם ננסה לבטל דיסק שכבר לא קיים במערכת, ה-Playbook ירוץ בלי סוף, אז היינו צריכים לעטוף את ההשקה שלו בעטיפה נפרדת ולהרוג אותו עם פסק זמן.
• Ansible פועל על תהליכים מפוצלים, כך שה-API שלו אינו בטוח בשרשור. אנחנו מפעילים את כל ספרי המשחקים שלנו עם חוט אחד.

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

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

מקור: www.habr.com