4 מהנדסים, 7000 שרתים ומגיפה עולמית אחת

היי הבר! אני מציג לתשומת לבך את התרגום של המאמר "4 מהנדסים, 7000 שרתים ומגיפה עולמית אחת" מאת Adib Daw.

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

מי אנחנו

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

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

בעיות בקנה מידה

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

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

לשלוט בדומיינים שלך

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

אימוץ גישה זו אפשרה לנו לפתור בעיות רבות בצורה נכונה – על ידי יצירת כלים ואוטומציה.

צריך דומיין

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

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

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

לוח Kanban בג'ירה

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

תחום מחזור חיים של ציוד

נסו לדמיין את המורכבות של ניהול החומרה המשמשת בכל מדף שרת. מה שגרוע עוד יותר הוא שניתן להעביר חלקי חומרה רבים (RAM, ROM) מהמחסן לחדר השרתים ובחזרה. הם גם נכשלים או נמחקים ומוחלפים ומוחזרים לספק להחלפה/תיקון. כל זה חייב להיות מועבר לעובדי שירות ה-colocation המעורבים בתחזוקה הפיזית של הציוד. כדי לפתור את הבעיות הללו, יצרנו כלי פנימי בשם Floppy. המשימה שלו היא:

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

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

לוח פיקוד ציוד מחסן בגרפנה

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

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

לאחר קבלת התביעה שלנו (בדרך כלל תוך שעות העבודה), חלק החילוף נשלח למרכז הנתונים המתאים ומתקבל על ידי הצוות.

פלט קונסולת ג'נקינס

תחום תקשורת

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

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

• פַּשְׁטוּת;
• אוטונומיה;
• יְעִילוּת;
• מהימנות.

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

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

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

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

iPad באחד ממרכזי הנתונים שלנו

תחום החומרה

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

• זיהוי כשל בחומרה
• מצבי שרת (פעיל, מתארח, זומבי וכו')
• צריכת חשמל
• גרסת קושחה
• אנליטיקה לכל העסק הזה

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

לוח מחוונים לאנרגיה בגרפאנה

ואז הופיע COVID-19...

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

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

אבל, כפי שאמרנו, המודל שלנו כבר מניח ש:

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

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

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

מקורי: טייטס

מקור: www.habr.com