データセンターのエンジニアリングシステムとその監視、パート2

継続出版、 ここが最初の部分です







この最後の部分では、監視システムのソフトウェアコンポーネントについて説明します。



4.トレースモードとその使用目的

5.クールな指標とすべてすべて

6.要約する

トレースモードとその使用方法

繰り返しますが、最初は最初のデータセンターでは目立った監視はありませんでしたが、その必要性がありました。 そして、彼らは最初にすでに建設中のMiran-2に基づいてこの必要性を具体化することを決定しました。 設計者とインテグレーターは、国​​内のトレースモードをSCADAとして使用することを提案しました。 当時のこの製品は、監視という点ですべてのウィッシュリストを満たすことができ、さらなる開発が比較的簡単で（そのようなニーズが生じた場合は...）、あまりお金をかけないように思えました。 一般に、単純なシステムに適したオプションです。





勤務センター「Miran-2」のAWP。 クリック可能



トレースモードは、完全に古典的なSCADAの例です。ネットワーク上のすべての必要な鉄片と勤務中のクライアントコンソールをポーリングするコアサーバーがあり、サーバーからのすべての重要な情報をさまざまな模倣の形で表示します。 この実施形態は、Miran-2全体を監視するために使用された。 内部のモジュラーデータセンターの場合（これまで2つあります）-シンクライアントのオプションが使用されました（ブラウザーのJavaアプレット）。





ブラウザにシンクライアントが表示されたパネルと、クライアントコンソールが表示されたパネルの写真。 クリック可能



プロジェクトの内部構造について簡単に説明します。 条件付きで2つのレベルがあります。

• 下位レベルのデバイスポーリング。 「ソース/レシーバー」によって実装されます-さまざまなプロトコル、テクノロジー、インターフェース（Modbus RTU / TCP-IP、SNMP、DDE、OPCなど）を定義するいくつかの構造パターンには、通信設定が含まれます。 一般に、それらは周辺のソフトウェア反射です。
• トップレベルのタグ。 トレースモードでは、「チャネル」と呼ばれます。 これらのテンプレートは、「ソース」（離散/アナログ）から受信したパラメータのタイプをすでに決定し、そのスケーリングを設定し、アラーム/プリエマージェンシー制限（アナログ信号の場合）、アラームメッセージ辞書にバインドを割り当て、最後に「チャンネル」がこれを設定しますアーカイブするかどうかのオプション。 したがって、これらの「チャネル」は、運用監視のためにニーモニック図のさまざまなグラフィック要素に割り当てることができます。

トレースモードIDE。 ソース/レシーバー。 クリック可能





トレースモードIDE。 「チャンネル」。 クリック可能



これがSCADAの中核です。

もちろん、トレースモードには、一般に受け入れられている工業用言語（ST、LD、FBD）でルーチンを記述し、レポートを作成し、SMSおよび電子メールを送信する機能もあります。

メモへ。

トレースモードファミリのすべての製品は、HASPキーで保護されています。 IDEで作業するには、プロジェクト内のデータソースの数を制限する独自のキーが必要です（128、256、512 ... Nデバイスのライセンスなど）。 RTMの操作には、独自のキーが必要です。 コンパイルされたプロジェクトの「チャネル」の最大数を制限します。 チャネル自体に加えて、チャネルのサブセットには、プログラムの呼び出し、画面テンプレートも含まれます。 また、キーはいくつかのテクノロジーの可用性を決定します。特に、トレースモードOPCサーバーを実行する機能があります。 ワークステーションで使用されるクライアントコンソールの場合、キーは画面の数を制限します（プロジェクトでは、1ダースの模倣、10のキーですか？2つの画面は呼び出されなくなります）。 シンクライアント？ さて、あなたは同時接続の数、ドキュメントテンプレートの制限を理解しています...

当初、インテグレーターからの監視は非常に簡単でした。 少なくとも：入力および補助機械の状態に関するデータ、エネルギー消費に関するデータ、温度センサーおよび湿度センサーの測定値、エアコンおよびUPSの状態、および（最も重要なパラメーターの1つ）-エネルギー消費のポストプロダクション計算。



なぜなら もちろん、システムは不完全であり、あらゆる種類の欠陥に悩まされていたため、保守と改善が必要でした。 ステージには、謙虚な僕が現れます。 私の主なタスクは、システム内のエラーの数を最小限に抑え、将来、データセンターのエンジニアリングインフラストラクチャ全体の運用を促進する新しい機能の不具合を追加することでした。



何よりもまず、監視システムは「くしでなめられ」、つまり、あらゆる種類の「傷」が修正され、番号の順序が調整され（冷たい廊下の摂氏200度が20.0に変わりました）、コンセンサスが見つかりました。ラック単位-kWまたはkVA単位。 ネタバレ！



2番目の層は戦略的な修正でした。 たとえば、最初のモジュラーデータセンターのドラフトの初期バージョンでは、UPSの状態、正常か、故障のために緊急状態で既に切断されているかは示されていませんでした。 多くのデータセンターノードに関する緊急事態とメッセージのリストが拡張されました。 ニーモニック図は、さまざまなアイコン、インジケータ、および追加のパラメータに囲まれています。一般的には、データセンターが正常かどうかを理解するのに役立つすべてのものです。





Miran-2データセンターの主な模倣





Miran-1データセンターの主な模倣





Miran-2通信センターのUPSの状態の模倣





DGU-1 Miran-2のニーモニック図









モジュラーデータセンター「モジュール2」のポップアップニーモニック図



まばたきの模式図が点滅する巨大なパネルは非常にクールで優れていますが、勤務中の人はまだ疲れ、忘れ、気づかない傾向がある人です。 残念ながら、モバイルデータセンターシステムにはアラームログがないため、チーフエンジニアのサービスとテクニカルサポートのチケットシステムの両方に緊急の手紙を送ることにしました。 後に、警告サイレンがこれに追加されました。

クールな指標とすべてすべて

トレースモードプロジェクトを1年かけて磨き上げた後、「美しくモダンでクールにしたい」と「どうすれば実現できるかを理解した」という消化の良い妥協点に達しました。 一般に、システムは現在の状態による監視と警告に対処しましたが、気候とエネルギー消費の最も単純な分析の可能性も望んでいました。



なぜなら モジュラーデータセンターシステムには「シン」クライアントのみが搭載され、グラフとトレンドをサポートしていません（再度）。ただし、少なくとも一部の分析は、チーフエンジニアのサービスの電子メール（単純な鉱山/温度センサーの最大値とラックのエネルギー消費量）。 しかし、可視性にはまだ多くのことが望まれていました。 さらに、このデータが抽出された独自のトレースモードアーカイブの不安定な動作は、別の障害になりました。



このすべての不名誉を解決するためのいくつかのオプションを経た後、さらなる処理のためにトレースモードから外部データベースにデータを送信するオプションについて詳しく調べることにしました。



すでに上記のオプションの実装を開始したいと考えていたときに、チーフエンジニアがgrafana Webサイトでインターネットを偶然見つけました。 グラフの美しさに深くため息をついて、現在のプラットフォームで私たちのニーズに合わせてこれを実装することは難しいことに同意しました。 それでも、grafanaは私の頭にしっかりとはまっており、彼女の参加を得て、実装されたソリューションの説明が記載されたガイドを探し始めました。 Habréに関するいくつかの記事が重要になりました： 1と2 （Habrは刺激を与えます！） collectdデーモンとそのプラグインについて言及しました。



今、私たちのニーズに合わせてこれらすべてを実現する方法のアイデアは完全に成熟しました。











このすべてのために、低負荷から退屈したブレードサーバーが割り当てられ、テストUbuntuが必要なすべてのソフトウェアと共に展開されました。 その後、彼に何をどのように質問するかについて、収集された設定を記入する番でした。 以下は、構成からの抜粋です。 特別なことは何もありません。すべてがデーモンとプラグインのドキュメントに厳密に従っています：









メインASU「Miran-2」のダッシュボード。 クリック可能





最も重要なパラメーター「Module-2」を持つダッシュボード。 クリック可能





気候の傾向を示すダッシュボード「モジュール2」。 クリック可能





ラックの消費量の傾向を示すダッシュボード「モジュール-1」。 クリック可能

まとめると

そのため、 トレースモードと比較した収集+グラファイト+グラフィナのソリューションの現在の利点：

1. 無料（ファインダーは平均的な男性の幸せの涙を拭く）。
2. オープンソース 理論的には、不足している機能を自分で記述して追加できます。
3. 在庫状況 実際、これはエンドユーザー向けのブラウザ内のページであるため、誰もがポケットにガジェットを持っています。 トレースモードでは、ガジェットは実際にはサポートされていません。
4. 拡張のシンプルさと利便性。 収集された+グラファイトの初期セットアップ中に必要なデータを「フィード」するだけで十分です。結果として得られるメトリクスは、直接編集してグラファナに直接変換できます。 トレースモードでRTMとクライアントコンソールをコンパイルするには、「いいえ！」
5. すぐにグラフを表示および分析するための非常に良い機会。 この点で、トレースモードは非常に保守的です。
6. すべての新しい絡み合ったチャットの緊急事態に関するアラートや通知がメールなどであります。 トレースモードでは、別のお金でSMSを送信できます-SMS（必要なハードウェアがある場合）。

短所：

1. 本格的なSCADAは、このような靭帯に置き換えることはできません。 プロセス制御なし。 もちろん、管理が必要な場合。
2. オープンソース あなたの謙虚な使用人は、ウィッシュリストを追加するための適切な資格を持っていないため、謙虚に待機し、そして/またはgitコミュニティでより賢い仲間を求めます。
3. パネルのセットは小さいです（ただし、プラグインのために拡張されます）。
4. アラートエンジンは依然として非常にシンプルであり、トリッキーな条件を設定することはできません。 開発者は、機能を拡張することを約束します。

これまでのところ、監視システムを従来のSCADAトレースモードの一種のハイブリッドのままにし、クライアントアプリケーションとサーバーを、ACSおよびAFMを使用する無関係なカーネルや、企業ネットワーク内のすべてのユーザーが利用できる美しく便利なメトリックを備えたgrafana外部ラッパーから隠すようにすることを決定しました。 最終的に私たちがやろうとしていることは、時間が経てばわかると思いますが、いまだにさまざまな工学上の問題があります。



私は質問に喜んでいるでしょう。 ご清聴ありがとうございました！