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

מה זה BMS

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

מערכות ניטור BMS (Building Monitoring System) מוצעות על ידי ספקים גלובליים רבים של ציוד למרכזי נתונים. במהלך עבודתו של Linxdatacenter ברוסיה, הייתה לנו הזדמנות להכיר מערכות שונות ולהיתקל בגישות מנוגדות בתכלית של ספקים לתפעול מערכות אלו. 

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

שורש הבעיה

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

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

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

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

שוק ה-IT הארגוני חווה השפעה רצינית ממגזר ה-B2C. הפתרונות הדיגיטליים כיום חייבים לספק חוויה נוחה למשתמש הקצה – זו המטרה שהמפתחים מציבים לעצמם. הדבר ניכר בשיפורים בממשקי המשתמש (UI) ובחוויית המשתמש (UX) של יישומים ארגוניים רבים. 

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

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

חסרונות של מערכת BMS הישנה 

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

בואו נוסיף עוד כמה "דברים קטנים" לא נעימים כאן:

1. תשלום עבור חיבור מכשירים חדשים על פי העיקרון של "כתובת IP אחת - רישיון אחד בתשלום"; 
2. חוסר יכולת לעדכן תוכנה ללא רכישת חבילת תמיכה (משמעות הדבר היא עדכון רכיבים חינמיים וביטול שגיאות בתוכנת BMS עצמה);
3. עלות גבוהה של תמיכה; 
4. מיקום בשרת "ברזל", שעלול להיכשל ויש לו משאבי מחשוב מוגבלים;
5. "יתירות" על ידי התקנת שרת חומרה שני עם חבילת רישיון כפול. יחד עם זאת, אין סנכרון של מסדי נתונים בין השרת הראשי לגיבוי - מה שאומר העברה ידנית של מסדי נתונים וזמן ארוך של מעבר לגיבוי;
6. לקוח משתמש "עבה", בלתי נגיש מבחוץ, ללא הרחבה למכשיר נייד ואפשרות גישה מרחוק;
7. ממשק אינטרנט מופשט ללא כרטיסים גרפיים והודעות סאונד, נגיש מבחוץ, אך למעשה אינו בשימוש העובדים בשל חוסר המידע שלו;
8. חוסר אנימציה בממשק - כל הגרפיקה מורכבת רק מתמונת "רקע" ואייקונים סטטיים. התוצאה היא רמת ראות נמוכה באופן כללי;

   הכל נראה בערך כך:

   
   
   

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

דרישות למערכת BMS חדשה

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

1. שתי מכונות עצמאיות מיותרות הדדיות עם סנכרון אוטומטי, הפועלות על שתי פלטפורמות ענן שונות במרכזי נתונים שונים (במקרה שלנו, מרכזי נתונים Linxdatacenter סנט פטרסבורג ומוסקבה);
2. תוספת חינם של מכשירים חדשים;
3. עדכוני תוכנה חינמיים ומרכיביה (למעט שיפורים פונקציונליים);
4. קוד מקור פתוח, המאפשר לנו לתמוך באופן עצמאי במערכת במקרה של בעיות בצד המפתח;
5. היכולת לקבל ולהשתמש בנתונים מה-BMS, למשל, באתר אינטרנט או בחשבון האישי שלך;
6. גישה דרך דפדפן אינטרנט ללא לקוח עבה;
7. שימוש בחשבונות עובדים בדומיין כדי לגשת ל-BMS;
8. זמינות של אנימציה ועוד הרבה משאלות קטנות ולא קטנות שהתממשו למפרט טכני מפורט.

הקש ששבר את גב הגמל

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

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

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

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

ה"דובדבן" בגרסה החדשה של BMS היה הצורך לרכוש רישיונות נוספים "לכל המכשירים" - אפילו עבור השרת הראשי. כאן יש צורך להבהיר כי ישנם מכשירים המחוברים ל-BMS דרך שערים. לשער יש כתובת IP אחת, אך שולט במספר מכשירים (10 בממוצע). ב-BMS הישן, זה הצריך רישיון אחד לכל כתובת IP של שער, הסטטיסטיקה נראתה בערך כך: "1000 כתובות IP/רישיונות, 1200 התקנים." ה-BMS המעודכן עבד על עיקרון שונה והסטטיסטיקה תיראה כך: "1000 כתובות IP, 1200 מכשירים/רישיונות." כלומר, הספק בגרסה החדשה שינה את עיקרון הקצאת הרישיונות, והיינו צריכים לקנות כ-200 רישיונות נוספים. 

תקציב ה"עדכון" כלל בסופו של דבר מארבע נקודות: 

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

העלות הכוללת של הפרויקט הייתה יותר מ-100$! וזה בלי לדבר על הצורך ברכישת רישיונות למכשירים חדשים בעתיד.

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

מקור: www.habr.com