データセンターの監視：古いBMSを新しいBMSに変更した方法。パート4

前のパートで は、新しいデータセンター監視システムをどのように作成して実装したかについて説明しました 。その結果、 リソースの可用性と中断のない運用の指標に影響を与えるすべてのデータセンターパラメータの統計を追跡および維持するための強力なメカニズムがあります。 



システム開発の過程での次のタスクは、その調整の問題でした。新しいシステムでの作業を便利にする方法、そしてそれ自体が可能な限り有益であるかどうか。 



ここでの問題は、システムの機能により、多くの緊急通知と信号を有効にできることです。このような設定では、スタッフは常にそれらに対応し、適切なシナリオを実行する必要があります。 



もう1つのオプションは、そのような通知の数を不十分に設定することです。これにより、出席者が本当に重要なイベントを見逃すリスクが生じます。



このパートでは、データセンター監視システムのセットアップにおける実際の経験を共有します。  「SCADAシステムによって収集された変数は、テレシグナリングとテレメトリに分けられます」



という少しの理論 -彼らは研究所で一度私に教えてくれました。そして実際、何も変わっていません：テレシグナリングは 状態です



たとえば、「アラームなし」、「アラームあり」、「オープン」、「クローズ」などのデバイス。 



テレメトリは、ご 想像のとおり、「220ボルト」などのパラメータのデジタル値です。または「10アンペア」。 



メッセージ（アラーム）が画面に表示されるユーザーによって設定された状態または値は、「セットポイント」と呼ばれます。メッセージが表示されるまでの遅延を設定できます。つまり、アラームはX秒後にのみ画面に表示されます（緊急事態が以前に停止していない場合）。または、画面上のメッセージを「フリーズ」します。この場合、アラームです。はすでに消えていますが、それに関するメッセージはさらにX秒間保存された画面に表示されます。 



優先度別の事故は、通常、「赤」、「黄」、「青」の3つの主要なタイプに分けられます。 「赤」の事故は従業員による即時の対応が必要であり、「黄色」は何かについて警告し、「青」はほとんどの場合、重大ではないイベントを報告します。たとえば、アテンダントが見た要約から「ブルー」事故を推定し、それらを使用してさまざまな商業的パラメータを監視しました（注文された容量を超えています）。これらの事故は管理者にのみ報告され、係員の気を散らすものではありません。



同じタイプの機器を構成するのに便利なように、異なるデバイスの変数は同じ名前（たとえば、「OutputCurrent」）で、システム内のすべてのデバイスで同じ設定になります。一箇所で設定を変えると、どこでも変わります。





デバイスが必要な変数の個別設定を必要とする場合、「このデバイスのみ」という特別なマークを付けます。これで、変数は1つの特定のデバイスに対して個別になり、独自の設定があり、同じ名前の他の変数には影響しません。



さらに、デバイス自体には独自の工場設定があります。たとえば、PDUは、32Aの過電流アラームを認識するように工場で構成されています。トリガーされると、PDUはアラームのタイプ「過負荷アラーム」について通知します。そして、これは完全に異なる変数であり、BMSで構成された「OutputCurrent」変数とは関係ありません。



PDU内の工場出荷時のデフォルト設定の例：





そこで、監視システムを設定するための主な機能をリストアップしました。 



この「ピアノ」を正しく調整するにはどうすればよいですか？タスクを順番に見ていきましょう。



達成したいこと



最も重要なタスク：機器のコントロールパネルの表面にあるアラームメッセージ は、監視システムに表示する必要があります。デバイスの赤いライトが点灯していて、監視に何もない場合は、すべての変数が監視に含まれているわけではないか、それらの設定が正しくありません。



2番目のタスクは、誤ったメッセージや情報のないメッセージを最小限に抑えることです。あなたがどれほど注意深く責任を持っていても、何かが常に点滅し、点滅し、目の前で鳴っている場合、彼らは実際の事故を見逃したり、アラートの海に溺れたり、音を消したりします-そしてその結果、彼らはまた、インシデントアラートを見逃します。



ステージ1。各デバイスに必要な変数と不要な変数の決定



通常、各デバイスにはいわゆる「変数マップ」が付属しており、これに基づいて「ドライバー」が試運転エンジニアによって作成されます。そのタスクは、受信データのレジスタが必要な変数が配置されている監視システムに「示す」ことです。たとえば、デバイスポーリングプロトコルのレジスタ1には、エンジン動作モード「System_on_fun」に関する情報が含まれ、レジスタ2-には、コンプレッサ動作モード「Compressor_1」に関する情報が含まれています。



多くの場合、1つのデバイスの変数の数は100を超えます。最初にシステムを構成する従業員（通常はITエンジニア）は、ここで何が重要で何が重要でないかを自分で決めることはできません。原則として、すべての変数は、「便利になった場合はどうなるか」という原則に基づいて監視に追加されます。



最初は、これは許容されます-運用スタッフは、利用可能なすべての変数の実際の値を見て、実際に何が必要かを理解できます。ただし、システムをこの状態のままにしておくと、次のような悪影響があります。

• 余分な変数は、監視システムの運用タスクをロードし、アーカイブのサイズを増やします。システムは、不要なデータを処理して保存することを余儀なくされます。 

• ポーリングされる変数が多いほど、ポーリングが失敗する可能性が高くなります。これは、ループを介して（たとえば、MODBUSプロトコルを使用するゲートウェイを介して）接続されたデバイスに特に当てはまります。これにより、「データなし（N / A）」または「通信障害」の状態が受信されます。つまり、実際には、デバイスは定期的に監視を停止します。 

• 一部の変数は「デフォルト」で不要です。たとえば、ご使用のバージョンの機器にはコンプレッサーや圧力センサーがありませんが、機器のモデル範囲全体のユニバーサルドライバーに登録され、ポーリングされ、アーカイブに追加され、ネットワークが読み込まれ、処理されます。 

スクリーンショットは、ドライバーコードの一部を示しています。//記号は、ポーリングから隠された変数を示します。また、BMS自体に設定値を設定するときにユーザーに表示される変数のリストも表示されます。







私たちの経験によると、初期段階ではデバイス内部の工場設定に触れない方が良いでしょう（もちろん、彼らがまだ事故についてあなたに知らせていない場合）。ただし、特定の機器に関する各トレーニングセッションでは、デバイス自体とBMSの両方に設定が存在することを従業員に通知する必要があります。将来的には、これは、アテンダントがアラームメッセージの原因を正確に理解するのに役立ちます。



ドライバーの余分な変数は徐々に明らかにしてポーリングから隠し、残りの変数は設定を割り当てる変数と、その後の分析と統計のためだけに設定なしで保存する変数に分割する必要があります。 



これは、システムアジャスターではなく、監視システムによって制御されるシステムの操作を理解している従業員（できればチーフエンジニアまたはチーフパワーエンジニア）が行う必要があります。



ステージ2。誤報や情報のないメッセージの最小化誤



検知は、デバイスのポーリングの失敗が原因で発生することがよくあります。デバイスのネットワークカードに電源が供給されていない場合、ポーリングの失敗と実際の停電の両方が、「通信障害」という1つのタイプの障害として表示されます。 



この場合、機器をクリティカル（たとえば、PDU）と通常（たとえば、「SHCHUV」換気パネル）に分割する必要があります。従来の機器では、信号の「切断」に遅延を設定できます（たとえば、300秒）。そうすると、誤った切断のほとんどが無視されます。 



このような遅延を重要な機器に適用できないことは明らかです。したがって、常に誤った障害が発生する場合は、物理ネットワーク、つまりポーリングされた変数の数に対処する必要があります。多くのデバイスが1つのゲートウェイに「ハング」している可能性があり、新しいゲートウェイを追加してネットワークをセグメント化する必要があります。



情報を提供しない事故は、ほとんどの場合、一時的なプロセス中に発生します。それらは偽とは言えません-実際には存在しますが、機器の特定の動作モードでは「正常」です。最も明白な例は、ディーゼル発電機セットへの移行です。 



この場合、UPSなしで電力が供給されている機器の一部が「正常に」オフになり、「切断」というエラーが発生し、UPS自体が大量のメッセージ（「入力に電力がない」、「電力がない」）を発行します。バイパス時」、「バッテリーからの電源供給」など、スタッフはすぐに数十通のメッセージを受信します。 



DGSに切り替えるときにメッセージの数を最適化するには、次のことを行う必要があります。 

• 移行中に「通常」に表示されるアラームに設定すると、発電機セットからの電源が表示される時間よりも長い時間遅延が発生します。たとえば、ディーゼル発電機セットへの切り替えの標準時間が200秒の場合、換気パネルの信号「切断」の遅延を300秒に設定します。 

その後、SCHUへの電源が設定値の遅延の前に表示され、状況は緊急事態として認識されません。同時に、UPSから電力が供給され、常に接続する必要のある重要なデバイス（PDUなど）があります。それらの「切断」に関するメッセージは遅滞なく表示されます。

• ディーゼル発電機セットに切り替えるときにUPSからのメッセージを分析し、「黄色」タイプ（たとえば、「入力に電力がない」という事実のステートメント）と「異常」を割り当てて「正常」メッセージに分割します。 「」（「バッテリーブレーカーの切断」、これは動作モードであってはなりません）、「赤」タイプに割り当てられます。

同時に、ディーゼル発電機セットに移行した場合、「黄色」の事故が観察され、確認されない可能性があることを 担当官への指示に個別に記載します （通常の移行が完了すると消えます） ）、および「赤い」事故はすぐに排除できます（そうすべきではありません）。 



理論のみに依存しているため、この「一時的な」プロセスの設定値を一度に調整することは非常に困難です。チューニングを成功させるには、DGSへの移行をリアルタイムで数回観察する必要があります。 



たとえば、新しいBMSの許容可能なセットアップのために、4〜5の遷移を観察する必要がありました。予定外の移行プロセスを分析するために、監視システムの画面を記録しました。これは、イベントアーカイブではなく、操作の概要のダイナミクスでアラームの発生を分析することが重要であるためです。 



ステップ3.私たちの経験からの追加のヒント



1.デューティシフトの画面では、アラームメッセージの色で不要な表示がないはずです。 



実際の例。あるデータセンターは、サーバールームの温度フローマップを注文しました。これは、センサーからの大量の温度データを使用した気流の3Dモデルです。その結果、空気の流れのある北の空気のビューが得られました-どこかで空気が緑で強調表示され、どこかで-黄色と赤（最も寒いものから最も暑いものまで）。同時に、気温はどこでも通常の範囲内であり、色はさまざまなポイントでの温度差を明確に表示するためにのみ使用されます。 



さらに、この「雑多な」ビューは、「勤務室」のモニターの1つに表示されました。その結果、プロセス分析用に作成されたツールが、赤く見えると機器に向かって走り、黄色に見えると緊張するように「鋭く」された当直の人々の目の前に現れたことが判明しました。 



おそらく、彼らは、左側の画面では「赤/黄色」が正常であり、右側の画面では同じ色が行動の合図であると出席者に説明しました。ただし、この方法によってヒューマンエラーのリスクが非常に深刻になることは明らかです。  



そのようなシステムを当直室のモニターから削除することは論理的です。たとえば、サーバールームの空気環境のパラメーターの変更後や試運転後など、傾向を分析する目的で機関長が監視する必要があります。新しい機器の。



2.SMS通知は注意して使用してください。 



数年前、私たちはまだ悪いモバイルインターネットを恐れていて、インスタントメッセンジャーの代わりにSMSを使用していました。誤って間違った設定を設定すると、100台のデバイスで同じ名前のすべてのデバイスに適用され、メーリングリストに登録している同僚はそれぞれ100件のSMSメッセージを受信しました。それ以来、SMSメールは使用していません。



3.メッセンジャーを介してトラブルに関するメッセージの複製を設定します。 



これは、たとえば、MicrosoftTeamsまたはTelegramを介して実行できます。あなたと当直者の両方が事故についてのメッセージを受け取り、電話は音を立てて振動します（ブラウザを介してシステムを操作している場合はそうではありません）。 



そして、たくさんのメッセージがあることを恐れないでください。私たちの経験では、データセンターの運用の平均的な日には、数十のメッセージしか受信されず、従業員の電話にロードされません。つまり、データセンターとBMSシステムの機器は、何百もの通知を受信しないと同時に、重要なものを見逃さないように構成できます。



メッセージの数を減らすには、「赤」と「黄色」のアラームの発生に関する通知のみをメーリングリストに含め ます。これは、イベントのパルスに指を置いておくことができるようにするために必要な最小値です。 



4.メッセージをメッセンジャーにグループ化します。 



ディーゼル発電機セットへの移行中または複雑な事故により、数十の緊急事態が発生し、電話はメッセンジャーへの着信メッセージから絶えず振動し、重要な電話をかけたり、監視システムのウィンドウを開いたりすることができなくなります。



メッセンジャーが直前に発生した事故の一般的なリストを含む1つの一般的なメッセージを受信するように配布を構成できます。この設定は、BMSシステムサマリーのアラームの表示には影響しません（アラームは遅滞なくサマリーに表示されます）。電話でのメッセージの受信が1分間遅れても、何も見逃すことはありませんが、お使いの携帯電話上の何倍も少ないメッセージ。



5.インターフェイスでサーバーとの接続が失われたことに関するメッセージを強調表示します。 



たとえば、アテンダントの敷地内でインターネットが失われました。ユーザーインターフェイスはサーバーと接続されていないため、概要にアラームは表示されません。「サーバーは利用できません」という薄暗い碑文が担当者に気付かれない場合があります。従業員は数値パラメータを使用して「緑色」のBMSパネルを見ることができます。長い間、それがオフラインにあることに気づいていませんでした。  



スクリーンショットは、BMSサーバーとの通信が失われたことを示す例を示していますが、機器の無関係なパラメーターが表示されています。





6.できるだけ多くのシステムをモニタリングに接続します。 



たとえば、従来、火災警報システムは自律的に動作し、そのパネルはセキュリティポストにぶら下がっています。 



はい、「FIRE」信号で、システムの自動アルゴリズムがトリガーされ、警告システムが起動しますが、警備員は、当直の声で「障害」または「注意」信号の出現について通知します。 



このようなシステムを監視に完全に接続することは非常に困難ですが、このようなシステムでは、「障害」、「注意」、「火災」の3つのリレー信号を構成し、それらを「ドライ接点」でBMSに接続するのは簡単です。システムモジュール。



これにより、悪名高い人的要因のリスクが軽減されます。 「ドライ接点」を介して接続された、データセンターのBMSシステムのテスト信号「FIRE」の例。





4シリーズの歴史をまとめる 



データセンターの監視システムは、データセンターのエンジニアリングシステムを監視するための単なる「目と耳」ではありません。その正しい操作は、サイトの継続性を通じて最高レベルの信頼性を達成することを可能にし、したがって、会社に追加の競争上の優位性を提供します。 



かなり困難で長い道のりを経て、次のことがわかりました。

• 現在2,500を超えるデバイスを監視し、約10,000の仮想センサーを計算する高速で安定した監視システム。
• サンクトペテルブルクとモスクワのLindatacenterクラウドソリューションプラットフォームに基づくシステム予約。
• -, , 1 ; 
• , , ;
• , , – .