מערכות ניהול ובקרה במרכזי נתונים

מה צריך לנטר בזמן אמת במרכז נתונים?

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

מערכות ניהול ובקרה במרכזי נתונים – BMS, ‏DCIM וניטור תשתיות בזמן אמת

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

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

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

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

בעידן ה־AI חשיבותה של שכבת הבקרה גדלה עוד יותר. עומסי מחשוב בצפיפות גבוהה מגדילים את צריכת החשמל ואת קצב פליטת החום, ומחייבים שילוב בין קירור אוויר, קירור נוזלי, מערכות חלוקת חשמל מתקדמות וניהול מדויק של הקיבולת. מסגרת ביצועי האנרגיה למרכזי נתונים מבוססי AI, שפורסמה בשנת 2026 על ידי ASHRAE, ‏NEMA והמעבדה הלאומית PNNL, מדגישה את הצורך בתכנון אינטגרטיבי, בניהול תרמי, במדידה ובתפעול מבוסס נתונים.

מערכת העצבים של מרכז הנתונים

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

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

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

BMS – ניהול מערכות המבנה

מערכת BMS ‏(Building Management System) מיועדת לניטור ולבקרה של מערכות המבנה והמעטפת האלקטרו־מכנית של מרכז הנתונים.

בין היתר, היא עשויה לנהל:

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

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

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

EPMS – ניהול וניטור מערכת החשמל

מערכת EPMS ‏(Electrical Power Monitoring System) מתמקדת בשרשרת החשמל של מרכז הנתונים: החל מנקודת החיבור לרשת, דרך השנאים, לוחות המתח, מערכות ה־UPS והגנרטורים, ועד ל־PDU, ל־Busway ולארון השרתים.

המערכת אוספת נתונים כגון:

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

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

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

DCIM – החיבור בין המתקן לבין מערכות ה־IT

מערכת DCIM ‏(Data Center Infrastructure Management) מחברת בין עולם התשתיות הפיזיות לבין עולם המחשוב.

היא אוספת ומרכזת מידע על:

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

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

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

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

ההבדל המעשי בין מערכות הניהול והבקרה

מערכת	תחום אחריות מרכזי	דוגמאות לנתונים	תפקיד אופייני
BMS	מערכות מכאניות ומערכות המבנה	טמפרטורה, לחות, לחץ, משאבות, שסתומים וצ'ילרים	בקרה תפעולית ואוטומציה
EPMS	תשתיות החשמל	זרם, מתח, הספק, מצב מפסקים ואיכות החשמל	ניטור שרשרת ההספק
DCIM	תשתיות מרכז הנתונים ונכסי ה־IT	קיבולת, עומסי ארונות, נכסים, חשמל, קירור ושטח	ניהול, תכנון וקבלת החלטות

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

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

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

ארכיטקטורת הבקרה – מהחיישן ועד לחדר השליטה

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

שכבה 1: חיישנים ומכשירי מדידה

זוהי שכבת השטח, הכוללת בין היתר:

• חיישני טמפרטורה ולחות.
• מדי לחץ ולחץ דיפרנציאלי.
• מדי ספיקה.
• חיישני טמפרטורת מים.
• חיישני נזילה וכבלי גילוי הצפה.
• מדי חשמל ומוני אנרגיה.
• חיישני רעידות.
• חיישני מצב לדלתות ולמפסקים.
• חיישני עשן וגזים.
• מערכות ניטור מצברים.
• חיישנים בתוך ארונות שרתים.
• חיישנים ביחידות PDU וב־Busway.
• חיישנים במערכות קירור נוזלי וביחידות CDU.

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

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

שכבה 2: בקרי שטח

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

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

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

שכבה 3: רשתות ופרוטוקולי תקשורת

מרכז נתונים כולל בדרך כלל כמה פרוטוקולים במקביל:

• BACnet/IP למערכות המבנה והבקרה.
• Modbus TCP או Modbus RTU למוני חשמל, UPS, ‏PDU וציוד תעשייתי.
• SNMP לציוד IT, מתגים, שרתים ומערכות כוח.
• OPC UA לשילוב מערכות תעשייתיות.
• API לצורך חיבור בין מערכות תוכנה.
• Redfish לניהול ציוד מחשוב ותשתיות IT.

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

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

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

שכבה 4: פלטפורמת האינטגרציה וה־Historian

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

ה־Historian מאפשר לבחון לא רק את המצב ברגע נתון, אלא גם את התפתחותו לאורך זמן.

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

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

בסיס הנתונים ההיסטורי מאפשר:

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

שכבה 5: חדר הבקרה וה־DCIM

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

כאן מתקבלות החלטות תפעוליות:

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

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

מה חייבים לנטר במרכז נתונים?

שרשרת החשמל

מערכת הניטור צריכה לספק תמונה רציפה של כל מסלול ההספק:

רשת החשמל ← שנאים ← לוחות ראשיים ← UPS ← לוחות חלוקה ← Busway או PDU ← ארון השרתים

אין די במדידת הצריכה הכוללת של האתר. נדרשת יכולת לעקוב אחר העומס בכל מסלול, לזהות כמה קיבולת זמינה נשארה ולוודא שהעומס מחולק נכון בין מערכות A ו־B.

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

מערכת טובה אינה מציגה רק את העומס הנוכחי, אלא גם:

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

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

מערכות הקירור

ניטור הקירור צריך לכלול את כל השרשרת התרמית:

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

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

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

קירור נוזלי ו־CDU

בארונות AI בעלי צפיפות גבוהה, ניטור הקירור הנוזלי הופך למערכת קריטית בפני עצמה.

יש לעקוב אחר:

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

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

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

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

ארונות השרתים

ברמת הארון יש לנטר:

• הספק כולל.
• עומס בכל הזנה.
• עומס בכל פאזה.
• טמפרטורת כניסת האוויר.
• טמפרטורת הפליטה.
• מצב הדלתות.
• נוכחות מים או נוזל.
• מצב יחידות ה־PDU.
• זמינות חיבורי A ו־B.
• שינויים בהרכב הציוד.
• צפיפות ההספק.
• קיבולת פנויה.
• חיבורי רשת וסיבים.

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

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

מצברים, UPS וגנרטורים

בנוסף למצב הפעולה הכללי, יש לנטר פרמטרים המצביעים על הידרדרות הדרגתית:

במערכות UPS

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

במערכות מצברים

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

בגנרטורים

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

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

ניהול התראות – לא כל חריגה היא אירוע חירום

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

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

מערכת התראות מקצועית צריכה לכלול כמה עקרונות.

רמות חומרה ברורות

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

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

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

השהיה, היסטרזיס וסינון

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

ניתן להגדיר:

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

ניתוח קצב השינוי

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

לכן יש לעקוב לא רק אחר הסף הקבוע, אלא גם אחר קצב השינוי – Rate of Change.

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

קורלציה בין אירועים

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

המערכת צריכה להציג את כשל המשאבה כאירוע המקור, ואת יתר ההתראות כתוצאות אפשריות שלו.

First-Out Alarm

בשרשרת של עשרות התראות חשוב לשמור ולהציג את האירוע הראשון שהתרחש.

לעיתים קרובות הוא המפתח להבנת התקלה כולה.

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

מסלול הסלמה

לכל התראה צריכה להיות כתובת ברורה:

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

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

PUE – מדד חשוב, אך לא תמונת המצב כולה

PUE ‏(Power Usage Effectiveness) הוא המדד המקובל לבחינת יעילות השימוש באנרגיה במרכז נתונים.

הנוסחה היא:

PUE = סך האנרגיה הנצרכת במתקן ÷ האנרגיה הנצרכת על ידי ציוד ה־IT

לדוגמה, אם המתקן צורך 15 מגה־ואט וציוד ה־IT צורך 10 מגה־ואט, ערך ה־PUE הוא 1.5.

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

המהדורה העדכנית, ISO/IEC 30134-2:2026, מגדירה את PUE כמדד מרכזי לכימות יעילות השימוש באנרגיה במרכזי נתונים, ומעדכנת בין היתר את דרישות המדידה, ההתייחסות למבנים בשימוש מעורב, לייצור אנרגיה באתר ולאנרגיה שאינה נמדדת ישירות.

עם זאת, PUE עלול להטעות אם אינו נמדד ומוצג נכון.

PUE רגעי אינו PUE שנתי

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

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

יש להגדיר את גבולות המדידה

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

יש להגדיר בבירור:

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

עומס נמוך עלול להגדיל את ה־PUE

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

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

PUE אינו מודד תפוקת מחשוב

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

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

אין לייעל על חשבון השרידות

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

היעילות חייבת להישקל מול:

• זמינות.
• יתירות.
• תנאי הסביבה המותרים.
• הוראות יצרני הציוד.
• עומסי שיא.
• מצבי כשל.
• דרישות SLA.

לכן רצוי להציג לצד PUE גם מדדים משלימים.

WUE – יעילות השימוש במים

WUE ‏(Water Usage Effectiveness) מודד את צריכת המים של מרכז הנתונים ביחס לפעילות ה־IT.

תקן ISO/IEC 30134-9:2022 מגדיר את WUE כמדד לכימות צריכת המים של מרכז נתונים בתקופת ההפעלה.

CUE – יעילות השימוש בפחמן

CUE ‏(Carbon Usage Effectiveness) מתייחס לפליטות הפחמן הנוצרות כתוצאה מהפעלת מרכז הנתונים.

תקן ISO/IEC 30134-8:2022 מגדיר את CUE כמדד לכימות פליטות הפחמן הדו־חמצני של מרכז הנתונים בשלב השימוש.

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

ניהול קיבולת – לאתר את המשאב שבאמת מגביל את הצמיחה

במרכז נתונים קיימות כמה קיבולות שונות:

• קיבולת חשמלית.
• קיבולת קירור.
• שטח רצפה.
• מספר יחידות Rack.
• עומס מבני ומשקל.
• קיבולת תקשורת וסיבים.
• קיבולת יציאות PDU.
• קיבולת גיבוי.
• קיבולת מים.
• קיבולת קירור נוזלי.
• קיבולת תפעולית ותחזוקתית.

המשאב המגביל אינו תמיד זה שנראה לעין.

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

מצב זה מכונה לעיתים Stranded Capacity – קיבולת קיימת שאינה ניתנת לניצול משום שמשאב אחר מגביל אותה.

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

1. מהו ההספק המתוכנן של הארון?
2. האם קיימת קיבולת בשני מסלולי ההזנה?
3. האם מערכת הקירור יכולה לפנות את החום?
4. האם קיימת ספיקה מספקת של אוויר או נוזל?
5. האם הרצפה והמבנה יכולים לשאת את המשקל?
6. האם קיימים חיבורי רשת וסיבים?
7. האם יש מספיק מקום פיזי לכבלים ולצנרת?
8. כיצד תשפיע ההתקנה על היתירות בעת כשל?
9. האם ניתן לתחזק את הציוד בלי להשבית מערכות שכנות?
10. מה יקרה אם יחידת כוח או קירור תצא משירות?

קיבולת שאינה נבחנת במצב כשל אינה קיבולת אמיתית.

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

Digital Twin – המתקן הפיזי מקבל העתק דיגיטלי

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

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

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

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

כך ניתן לדעת לא רק היכן נמצא כל רכיב, אלא גם:

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

ביישום מתקדם ניתן להשתמש במודל לצורך:

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

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

לכן כל שינוי במתקן חייב לעבור תהליך Management of Change ולעדכן הן את התשתית הפיזית והן את המודל הדיגיטלי.

אנליטיקה חזויה ובינה מלאכותית

מערכות בקרה מסורתיות מגיבות לאחר חציית סף.

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

לדוגמה:

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

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

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

המערכת צריכה להסביר ככל האפשר:

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

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

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

תרחיש תפעולי – כיצד ניטור חזוי מונע השבתה?

נניח שמסנן ביחידת קירור מתחיל להיסתם בהדרגה.

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

1. זיהוי אנומליה ראשונית – המערכת עדיין פועלת

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

עם זאת, המערכת מזהה כי מהירות המאוורר עולה בהדרגה כדי לשמור על אותה כמות אוויר.

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

2. הצטברות נתונים – ההתנגדות עולה

מד הלחץ הדיפרנציאלי מציג עלייה בהתנגדות האוויר על פני המסנן.

במקביל:

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

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

3. התרעה חזויה – לפני חציית הסף

מערכת האנליטיקה מחברת בין ארבעה נתונים:

עלייה במהירות המאוורר
עלייה בלחץ הדיפרנציאלי
עלייה בצריכת האנרגיה
ירידה הדרגתית בספיקת האוויר

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

4. פעולת מניעה – טיפול ללא השבתה

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

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

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

אבטחת סייבר במערכות BMS ו־DCIM

מערכות ניהול ובקרה הן חלק מסביבת ה־OT ‏(Operational Technology).

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

NIST SP 800-82 Rev. 3 מספק הנחיות להגנת מערכות OT תוך התחשבות בדרישות הייחודיות שלהן: ביצועים, אמינות, זמינות ובטיחות. הוא כולל בין הדוגמאות למערכות OT גם מערכות אוטומציה של מבנים, בקרת גישה ומערכות לניטור התנאים הפיזיים.

הפרדה בין IT ל־OT

אין לחבר את רשת ה־BMS ישירות לרשת הארגונית או לאינטרנט.

יש להשתמש ב:

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

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

Zero Trust – אין אמון אוטומטי

ההגנה על מערכות BMS ו־DCIM אינה מסתיימת בהתקנת חומת אש.

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

NIST SP 800-207 מגדיר Zero Trust כתפיסה המעבירה את מוקד ההגנה מהיקף רשת סטטי אל המשתמשים, הנכסים והמשאבים, ואינה מעניקה אמון מובנה על בסיס מיקום פיזי או מיקום ברשת.

כל בקשת גישה צריכה להיבחן לפי:

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

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

Data Diodes – הוצאת מידע ללא ערוץ פקודות נכנס

באתרים בעלי רגישות גבוהה ניתן לשלב Data Diode, המכונה גם Unidirectional Gateway.

זהו רכיב חומרה האוכף מעבר נתונים בכיוון אחד בלבד.

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

מסלול המידע:

רשת BMS/OT מוגנת ← Data Diode ← מערכת ארגונית או סביבת ענן

ללא מסלול חזרה:

מערכת ארגונית או ענן ✕ פקודות לרשת ה־OT

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

עם זאת, הוא אינו מבטל את כלל סיכוני הסייבר ואינו מחליף:

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

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

הרשאות לפי תפקיד

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

יש להחיל את עקרון Least Privilege ולהגדיר:

• הרשאות צפייה.
• הרשאות אישור.
• הרשאות שינוי.
• הרשאות הפעלה.
• הרשאות מנהל.
• הרשאות ספקים.
• הרשאות זמניות.

פעולות קריטיות עשויות לדרוש אישור של שני בעלי תפקידים או אימות נוסף.

גישה מרחוק מבוקרת

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

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

אין להשאיר חשבונות ספקים פעילים באופן קבוע ללא צורך.

הצפנת התקשורת

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

ביישומי BACnet חדשים ניתן לשקול BACnet/SC, המשתמש ב־TLS וב־WebSockets לצורך אימות בין התקנים, הצפנת מסרים ותקשורת אמינה.

ניהול עדכונים מבוקר

אי אפשר לעדכן בקר קריטי כפי שמעדכנים מחשב משרדי.

כל עדכון צריך:

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

גיבוי ושחזור

יש לגבות:

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

הגיבוי צריך להיות מופרד מהמערכת הפעילה ולהיבדק בתרגילי שחזור.

גיבוי שלא נבדק אינו מבטיח יכולת שחזור.

רישום פעולות

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

הרישום צריך לכלול:

• מי ביצע את הפעולה.
• מתי היא בוצעה.
• מאיזו תחנה.
• מה היה הערך הקודם.
• מהו הערך החדש.
• האם התקבל אישור.
• האם הפעולה הצליחה.
• האם בוצעה חזרה לאחור.

שרידות מערכת הניטור עצמה

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

אין לקבל מצב שבו תקלה בשרת BMS יחיד משאירה את חדר הבקרה ללא תמונת מצב.

הארכיטקטורה צריכה לבחון:

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

חשוב במיוחד לבדוק מה קורה בזמן כשל חלקי:

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

נתון ישן המוצג כאילו הוא עדכני מסוכן יותר מהיעדר נתון.

Commissioning של מערכות BMS ו־DCIM

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

יש לבצע בדיקות מסודרות מקצה לקצה.

בדיקת Point-to-Point

כל נקודה נבדקת מהציוד הפיזי ועד למסך:

חיישן או מגע ← בקר מקומי ← רשת תקשורת ← BMS או DCIM ← התראה ← תיעוד

יש לוודא:

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

בדיקת פקודות

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

פקודת "הפעל משאבה" אינה מספיקה.

נדרש גם חיווי שמראה:

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

בדיקת אובדן תקשורת

יש לנתק באופן מבוקר קישור, בקר או שרת ולבדוק:

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

בדיקת התראות והסלמה

יש ליצור חריגה מבוקרת ולוודא שהיא:

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

בדיקת תרחיש משולב

לדוגמה:

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

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

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

טעויות שעולות מיליוני שקלים

התקנת DCIM לפני סידור הנתונים

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

הגדרת כל ההתראות כקריטיות

הצפה של מאות התראות יוצרת Alarm Fatigue, שוחקת את תשומת הלב של המפעילים ועלולה להסתיר את אירוע המקור.

הסתמכות על טמפרטורת החדר בלבד

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

מדידת PUE בלבד

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

מערכת ענן ללא עצמאות מקומית

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

חיבור שטוח בין רשתות IT ו־OT

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

שליטה מרחוק ללא מגבלות

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

אי־בדיקת חותמות הזמן

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

ויתור על בדיקות Point-to-Point

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

אי־עדכון המודל לאחר שינויים

מערכת DCIM שאינה משקפת את מצבו האמיתי של המתקן עלולה לאשר הוספת עומס באזור שבו אין קיבולת חשמלית או תרמית מספקת.

התעלמות מאובדן יתירות

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

תצוגה יפה ללא נוהל תגובה

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

הטיפ ההנדסי – להתחיל בהחלטות, לא במסכים

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

לדוגמה:

• כיצד נדע שנותרה קיבולת לארון חדש?
• כיצד נזהה הידרדרות במשאבה?
• כיצד נבדיל בין אירוע מקור להתראות משנה?
• כיצד נוודא שמערכות A ו־B אינן תלויות ברכיב משותף?
• כיצד נזהה אובדן יתירות?
• מי מקבל התראה ומי מוסמך להגיב?
• כיצד נבדוק שהנתונים אמינים?
• כיצד נשחזר את המערכת לאחר תקלה?
• כיצד נדע שמידע המוצג במסך עדיין עדכני?
• כיצד נבדוק את השפעתו של שינוי לפני ביצועו?
• כיצד נשלב מערכות של יצרנים שונים?
• אילו פעולות חייבות להישאר מקומיות ואוטונומיות?

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

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

מבט קדימה

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

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

מערכות הניהול יוכלו לחבר בין:

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

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

מערכת הניהול אינה שכבת תוכנה המתווספת בסוף הפרויקט.

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

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

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

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

היעד האמיתי של מערכות BMS, ‏EPMS ו־DCIM הוא לא רק לראות את המתקן – אלא להבין אותו, לחזות את התנהגותו ולמנוע מהחריגה הקטנה להפוך להשבתה מערכתית.

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

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

© כל הזכויות שמורות לקבוצת פורטל נט.