ניטור במרכז הנתונים: איך שינינו את ה-BMS הישן לחדש. חלק 2

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

ניתוח שוק

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

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

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

זה בולט במיוחד בפרויקטים מורכבים. 

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

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

סיכונים

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

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

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

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

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

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

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

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

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

הזמנה

מערכת ה-BMS החדשה הייתה צריכה להיות ממוקמת בענן, במכונה וירטואלית. 

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

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

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

תמיכה

הנקודה החשובה ביותר לתפעול יעיל של פתרון BMS היא תמיכה טכנית. 

הכל פשוט כאן: מערכת חדשה תעלה לנו 35 רובל לפי אינדיקטור זה. לחודש עבור SLA "תגובה תוך 000 שעות", כלומר 8 x 35/000 = 12 $ לשנה. השנה הראשונה חינם. 

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

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

עדכונים

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

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

וכמובן, אי אפשר היה לעדכן את התוכנה מבלי לרכוש חבילת תמיכה.

גישה גמישה

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

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

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

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

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

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

הבחירה נעשתה.

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

אתן שתי דוגמאות לרמת הפירוט של הדרישות במפרט הטכני:

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

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

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

פעולה מקבילה של שתי מערכות

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

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

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

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

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

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

נספר לכם מה קרה בסופו של דבר בחלק השלישי של המאמר שלנו.

מקור: www.habr.com