データセンターのモニタリング: 古い BMS を新しい BMS に置き換えた方法。 パート2

最初の部分では、データセンターの古い BMS システムを新しいものに置き換えることにした理由について説明しました。単に変更するだけでなく、要件に合わせてゼロから開発します。パート2では、その方法をお伝えします。

市場分析

上記を考慮すると 最初の部分 お客様のご要望と既存システムの更新を拒否するという決定を受けて、市場でソリューションを見つけるための技術仕様を作成し、産業用 SCADA システムの作成のみを行っている大手企業数社に問い合わせを行いました。 

彼らからの最初の回答では、この分野ではクラウドへの移行プロセスがすでに始まっているものの、監視システム市場のリーダーは主にハードウェア サーバー上で作業を継続していることが示されました。仮想マシンの予約に関しては、このオプションをサポートする人は誰もいませんでした。さらに、市場で目立つ開発者の中には、バックアップの必要性を理解している者もいないようでした。「クラウドはダウンしない」というのが最も一般的な答えでした。実際、データセンター監視を物理的に同じデータセンター内にあるクラウドに配置するという提案を受けました。

ここで、請負業者を選択するプロセスについて少し説明する必要があります。もちろん価格は重要ですが、複雑なプロジェクトの実施のための入札の際、サプライヤーとの対話の段階で、どの候補者がより関心を持ち、実施する能力があるかを感じ始めます。 

これは複雑なプロジェクトでは特に顕著になります。 

技術仕様に対する質問を明確にする性質に基づいて、請負業者は、単に販売することに興味がある人（営業マネージャーの標準的なプレッシャーを感じる）と、製品の開発、顧客の声を聞いて理解すること、最終選択前に技術仕様に建設的な変更を加えることに興味がある人（他の人の技術仕様を改善して入札に負けるという実際のリスクにもかかわらず）、そして最終的には、専門的な挑戦を受け入れて良い製品を作る準備ができている人に分けられます。

こうしたことから、私たちは比較的小規模な地元の開発業者である Sunline グループに注目しました。同社は私たちの要求のほとんどに即座に対応し、新しい BMS に関するあらゆるニーズを実装する準備ができていました。 

リスク

大手企業が私たちの要望を理解しようと努め、販売前スペシャリストの協力を得てゆっくりとやり取りを進めていた一方で、地元の開発業者が自社の技術チームを招いて私たちのオフィスで会議を予定していました。この会議で、請負業者はプロジェクトに参加する意欲を改めて示し、最も重要なこととして、必要なシステムがどのように実装されるかを説明しました。    

会議の前に、私たちは、大規模な国内企業や国際企業のリソースを背景に持たないチームと協力することには 2 つのリスクがあることを認識していました。

1. 専門家は自分の能力を過大評価し、その結果、対処できなくなる可能性があります。たとえば、複雑なソフトウェアを使用したり、実行不可能なバックアップ アルゴリズムを設計したりします。
2. プロジェクトの実施後にプロジェクトチームが解散し、製品のサポートが危険にさらされる可能性があります。

こうしたリスクを最小限に抑えるために、当社独自の開発スペシャリストを会議に招待しました。潜在的な請負業者の従業員は、システムの基盤が何であるか、冗長性を実装する方法が計画されているか、および運用サービスとして私たちが十分に対応できなかったその他の問題について徹底的にインタビューされました。

判定は肯定的でした。既存の BMS プラットフォームのアーキテクチャは最新かつシンプルで信頼性が高く、改善の余地があり、提案されたバックアップおよび同期スキームは論理的かつ効率的です。 

最初のリスクは対処されました。 2 番目は、請負業者からシステムのソース コードとドキュメントを当社に転送する準備ができていることの確認を受け、当社の専門家によく知られている Python プログラミング言語を選択したことで除外されました。これにより、開発会社が市場から撤退した場合でも、困難や従業員への長期間のトレーニングなしで、システムを自社でサポートできることが保証されました。

このプラットフォームのもう 1 つの利点は、Docker コンテナに実装されていることです。カーネル、Web インターフェース、製品データベースはこの環境で動作します。このアプローチには、「従来型」に比べてソリューションの展開速度を最速にするための設定の事前設定や、システムへの新しいデバイスの容易な追加など、多くの利点があります。 「すべてを一緒に」という原則により、システムの実装が可能な限り簡素化されます。システムを解凍するだけで、すぐに操作できます。 

このようなソリューションを使用すると、システムのコピーを簡単に作成でき、ソリューション全体の運用を停止することなく、別の環境でシステムを改善およびアップグレードできます。  

両方のリスクが軽減された後、請負業者は見積書を提出しました。これには、私たちにとって最も重要な BMS システムのパラメータがすべて含まれていました。

予約

新しい BMS システムは、クラウド内の仮想マシンに配置する必要がありました。 

ハードウェアもサーバーも必要なく、この展開モデルに伴うあらゆる不便やリスクも、クラウド ソリューションによって永久に解消できました。システムは、サンクトペテルブルクとモスクワの 2 つのデータセンター サイトにある当社のクラウドで運用されることが決定されました。これらは、すべての承認された専門家がアクセスできるアクティブ スタンバイ モードで動作する 2 つの完全に機能するシステムです。 

2 つのシステムは相互にバックアップし、計算能力とデータ転送チャネルの両方の面で完全なバックアップを提供します。データとチャネル、システム、仮想マシン全般のバックアップ、および月に 1 回のデータベースの個別のバックアップ (管理と分析の点で最も価値のあるリソース) など、追加のセキュリティ対策も構成されています。 

BMS ソリューションの予約オプションは、当社のリクエストに合わせて特別に開発されたものであることにご注意ください。予約スキーム自体は次のようになります。

サポート

BMS ソリューションを効果的に運用するために最も重要なポイントは、技術サポートです。 

ここではすべてが単純です。この指標によると、新しいシステムの費用は 35 ルーブルになります。 SLA「000時間以内の応答」の場合、月額、つまり8 x 35/000 = 年間12ドル。最初の80年間は無料です。 

比較すると、ベンダーの古い BMS のサポートには年間 18 ドルかかり、新しいデバイスが追加されるたびに金額が増加します。同時に、同社には専任のマネージャーが配置されていませんでした。すべてのやり取りは、私たちを潜在的な購入者として興味を持ち、リクエストの処理に重点を置いていた営業マネージャーを通じて行われました。 

より少ない費用で、製品開発に参加するアカウントマネージャーや単一のエントリーポイントなどによる完全な製品サポートを受けることができました。システムの操作のあらゆる側面、API 経由の統合などについて開発者に直接アクセスして迅速に調整できるため、サポートははるかに柔軟になりました。

アップデート

提案された CP によれば、新しい BMS のすべての更新はサポート費用に含まれているため、追加の支払いは必要ありません。例外は、技術仕様で指定された機能を超える追加機能の開発です。 

以前のシステムでは、組み込みの無料ソフトウェア (Java など) のアップデートとバグ修正の両方に料金が必要でした。これを拒否する方法はありませんでした。アップデートがない場合、内部コンポーネントのバージョンが古いためにシステム全体が「遅くなった」のです。

そして、もちろん、サポート パッケージを購入せずにソフトウェアを更新することは不可能でした。

柔軟なアプローチ

もう一つの基本的な要件はインターフェースに関するものでした。私たちは、データセンターの敷地内にエンジニアを常駐させることなく、どこからでも Web ブラウザ経由でアクセスできるようにしたいと考えていました。さらに、インフラストラクチャの機能のダイナミクスが勤務中のエンジニアにとってよりわかりやすくなるように、アニメーション化されたインターフェースを作成することを目指しました。 

新しいシステムでは、エンジニアリング システム内の仮想センサーの動作を計算するための数式もサポートする必要がありました。たとえば、機器ラック全体にわたる電力の最適な配分などです。これを行うには、センサーの読み取りに適用できる通常の数学演算をすべて利用できる必要があります。 

次に、SQL データベースにアクセスして、そこから機器の動作に関する必要なデータ (つまり、約 20 万個の変数を生成する XNUMX 個のデバイスと XNUMX 個の仮想センサーの監視のすべての記録) を取得する機能が必要でした。 

また、各ユニット内のデバイスの位置をグラフィカルに表示し、ハードウェアの総重量を計算し、デバイスのライブラリを維持し、各要素に関する詳細な情報を提供する、ラックマウント型のハードウェア会計モジュールも必要でした。 

技術仕様の調整と契約の締結

新しいシステムの開発を始める必要があった当時、「大企業」とのやり取りは、提案のコストを議論するところまではまだ至っていなかったため、受け取ったCPと古いBMSの更新コストを比較しました（ 最初の部分）、そして結果的に価格的にも魅力的で、私たちの要件に合致していることがわかりました。

選択は完了しました。

請負業者を選択した後、弁護士が契約書の草案を作成し始め、双方の技術チームが技術仕様の磨き上げを始めました。ご存知のとおり、詳細かつ適切な技術仕様は、あらゆる作業の成功の基盤となります。技術仕様が具体的であればあるほど、「でもそれは私たちが望んでいたものとは違う」というような失望は少なくなります。

技術仕様における要件の詳細レベルについて、2 つの例を挙げます。

1. データ センターの当番担当者は、BMS に新しいデバイスを追加する権限を持ちます。ほとんどの場合、これらは PDU です。旧 BMS では、これは「管理者」レベルであり、すべてのデバイスの変数設定を変更することなどが可能であり、機能を分離することは不可能でした。私たちはそれに満足していませんでした。新しいプラットフォームの既存の基本バージョンでも、スキームは同様でした。私たちはすぐに、これらの役割を分離したい旨を技術仕様に示しました。設定は許可された従業員のみが変更できるようにし、当直担当者は引き続きデバイスを追加する権限を持つようにする必要がありました。この計画は実施のために承認されました。
2.  標準的な BMS には、一般的な通知カテゴリが 3 つあります。赤 – 即時の対応が必要、黄 – 観察可能、青 – 「情報」。当社では従来、顧客のラック電力制限の超過など、商用パラメータの超過を監視するために青色のアラートを使用してきました。私たちの場合、このタイプの通知は管理者向けであり、運用部門には関係ないものでしたが、古い BMS では、アクティブなインシデントのリストが乱雑になり、運用作業に支障をきたすことが頻繁にありました。通知パンツのロジックと色の差別化は成功したと判断し、そのまま採用しましたが、技術仕様では、「青」の通知は勤務員の邪魔をすることなく、別のセクションに静かに「流れ込み」、そこで商業専門家が処理するように明確に指示しました。

グラフを構築してレポートを生成するためのフォーマット、インターフェースの概要、監視する必要があるデバイスのリストなど、さまざまなことが同様のレベルの詳細で説明されていました。 

これはまさに、要件と条件を指示するカスタマー サービスと、これらの条件を技術文書に変換する任務を負った双方の技術専門家。開発された技術文書に従って顧客の要件を実装した請負業者プログラマーのチーム...その結果、私たちは既存のプラットフォームの機能にいくつかの基本的ではない要件を適応させ、請負業者は私たちに代わっていくつかを追加する義務がありました。 

2つのシステムの並列動作

いよいよ実装の時です。実際には、これは請負業者にプロトタイプの BMS を当社の仮想クラウドに展開する機能を提供し、監視を必要とするすべてのデバイスへのネットワーク アクセスを提供することを意味しました。

しかし、新しいシステムはまだ運用できる状態ではありませんでした。この段階では、古いシステムでの監視を維持しながら、同時に新しいシステムにデバイスへのアクセスを提供することが重要でした。システムを通常の方法で構築するには、システム内のデバイスを確認する必要がありますが、その場合、古いシステムによる監視から切断することはできません。 

これらの装置が2つのシステムによる同時尋問に耐えられるかどうかは、実際のテストを行わなければ不明である。二重同時ポーリングにより、デバイスからの応答が頻繁に拒否され、デバイスが利用できないというエラーが多数発生し、古い監視システムの動作がブロックされる可能性がありました。

ネットワーク部門は、クラウドに展開された新しい BMS プロトタイプからデバイスまでの仮想ルートを実行し、次のような結果を得ました。 

• SNMPプロトコル経由で接続されたデバイスは、同時リクエストによる切断をほとんど経験しませんでした。 
• modbas-TCP プロトコルを使用してゲートウェイ経由で接続されたデバイスには問題がありましたが、ポーリングの頻度を適切に減らすことで解決されました。  

そして、私たちの目の前で新しいシステムが構築されていく様子を観察し始めました。そこには、私たちにとってすでに馴染みのあるデバイスが登場しますが、インターフェースは異なり、便利で高速、携帯電話からもアクセスできます。

最終結果については、この記事の第 3 部でお知らせします。

出所： habr.com