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

前編では、データセンター内の古い BMS システムを新しいものに置き換えることにした理由について説明しました。 そして、ただ変更するだけではなく、要件に合わせて一から開発します。 後半では、それをどのように行ったかを説明します。

市場分析

で説明されている内容を考慮すると、 最初の部分 という要望と、既存のシステムの更新を拒否する決定を下したため、私たちは市場での解決策を見つけるために技術仕様を作成し、産業用 SCADA システムの作成のみに従事するいくつかの大企業に問い合わせました。 

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

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

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

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

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

リスク

大手企業が私たちの要望を理解しようとしており、販売前レベルの専門家を巻き込んで私たちとゆっくりとやり取りを続けている間、地元の開発者は技術チームの参加を得て私たちのオフィスでの会議を予定していました。 この会議で、請負業者はプロジェクトに参加する意欲を改めて表明し、最も重要なことに、必要なシステムがどのように実装されるかを説明しました。    

会議の前に、国内または国際的な大企業のリソースを持たないチームと協力することには XNUMX つのリスクがあることがわかりました。

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

これらのリスクを最小限に抑えるために、私たちは自社の開発専門家を会議に招待しました。 潜在的な請負業者の従業員に対して、システムがどのような基盤に基づいているのか、冗長性がどのように実装される予定なのか、運用サービスとしての私たちが十分な能力を備えていないその他の問題について徹底的にインタビューされました。

評決は肯定的でした。既存の BMS プラットフォームのアーキテクチャは最新でシンプルかつ信頼性が高く、改善の可能性があり、提案された冗長性と同期スキームは論理的で実行可能です。 

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

このプラットフォームのさらなる利点は、Docker コンテナー (この環境ではカーネル、Web インターフェイス、製品データベース機能) に実装されていることです。 このアプローチには、「クラシック」と比較してソリューションの展開を最速にするためのプリセット設定や、システムへの新しいデバイスの簡単な追加など、多くの利点があります。 「すべて一緒に」の原則により、システムの実装が可能な限り簡素化され、システムを開梱するだけですぐに使用できます。 

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

両方のリスクが最小限に抑えられると、請負業者は CP を提供します。 これには、BMS システムの最も重要なパラメータがすべて含まれていました。

予約

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

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

XNUMX つのシステムは相互に保証し、コンピューティング能力とデータ伝送チャネルの両方を完全に確保します。 データとチャネル、システム、仮想マシン全般のバックアップ、月に XNUMX 回の個別のデータベース バックアップ (管理と分析の点で最も貴重なリソース) など、追加のセキュリティ対策も構成されています。 

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

サポート

BMS ソリューションを効果的に運用するために最も重要なポイントはテクニカル サポートです。 

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

比較のために、ベンダーからの古い BMS の維持には年間 18 ドルの費用がかかり、新しいデバイスが追加されるたびに金額が増加します。 同時に、同社は専任のマネージャーを用意しておらず、すべてのやり取りは、潜在的な購入者として当社に関心を持ち、リクエストの処理に対応して重点を置いている営業マネージャーを通じて行われました。 

より少ない金額で、製品開発に参加するアカウントマネージャーによる完全な製品サポート、単一のエントリポイントなどを受けられました。 開発者に直接アクセスして、システムのあらゆる側面への迅速な調整、API による統合などのおかげで、サポートはさらに柔軟になりました。

アップデート

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

古いシステムでは、ファームウェアのアップデート (Java など) とバグ修正の両方に支払いが必要でした。 これを拒否することは不可能で、アップデートがない場合、内部コンポーネントの古いバージョンが原因でシステム全体が「速度が低下」しました。

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

柔軟なアプローチ

もう XNUMX つの基本的な要件はインターフェイスに関するものでした。 私たちは、データセンターの領域にエンジニアが常駐する必要がなく、どこからでも Web ブラウザーを介してアクセスできるようにしたいと考えていました。 さらに、勤務中のエンジニアにとってインフラストラクチャのダイナミクスがより明確になるように、アニメーション インターフェイスの作成にも努めました。 

また、新しいシステムでは、エンジニアリング システムにおける仮想センサーの動作を計算するための公式をサポートする必要がありました。たとえば、機器ラック全体に電力を最適に分配するためです。 これを行うには、センサーインジケーターに適用できる通常の数学的演算をすべて自由に使えるようにする必要があります。 

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

ラック機器会計モジュールも必要でした。これにより、各ユニット内のデバイスの配置をグラフィック表示してハードウェアの総重量を計算し、デバイスのライブラリと各要素の詳細情報を維持することができました。 

技術仕様の承認と契約の締結

新しいシステムの作業を開始する必要があった時点では、「大手」企業とのやり取りでは、提案のコストについて話し合うにはまだ程遠い状況でした。そのため、受け取った CP と古い BMS の更新コストを比較しました (「大企業」を参照)。 最初の部分）その結果、価格的にもより魅力的であり、私たちの要件を満たしていることがわかりました。

選択は完了しました。

請負業者を選択した後、弁護士は契約書の作成を開始し、双方の技術チームが技術仕様を磨き始めました。 ご存知のとおり、詳細かつ有能な技術仕様は、あらゆる作業の成功の基礎です。 技術仕様に詳細が記載されていればいるほど、「でもこれは望んでいたものではない」といった失望は少なくなります。

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

1. 勤務中のデータ センターには、BMS に新しいデバイス (ほとんどの場合、PDU) を追加する権限が与えられています。 旧BMSでは、これは「管理者」レベルであり、すべてのデバイスの変数設定を変更することもでき、機能を分離することはできませんでした。 これは私たちには合わなかったのです。 新しいプラットフォームの既存の基本バージョンでも、スキームは同様でした。 私たちはすぐに、これらの役割を分離したいことを付託条件に示しました。許可された従業員のみが設定を変更する必要がありますが、勤務中の従業員は引き続きデバイスを追加できるようにする必要があります。 このスキームは実装が承認されました。
2.  標準的な BMS には、通知の XNUMX つの典型的なカテゴリがあります。赤 - すぐに応答する必要がある、黄 - 観察可能、青 - 「情報」です。 当社では従来、顧客のラックの容量制限の超過など、ビジネス パラメーターを超過した場合を監視するためにブルー アラートを使用してきました。 私たちの場合、このタイプの通知は管理者向けであり、運用サービスには関係ありませんでしたが、古い BMS では定期的にアクティブなインシデントのリストが詰まり、運用作業が妨げられていました。 私たちは、通知パンツのロジックと色の差別化自体が成功していると考え、それを維持しましたが、技術仕様では、「青色」の通知は当直職員の気を散らすことなく、別のセクションに静かに「注ぐ」必要があると具体的に示していました。商業専門家が対応いたします。

グラフの構築やレポートの生成のためのフォーマット、インターフェースの概要、監視が必要なデバイスのリストなども同様に詳細に規定されました。 

これは XNUMX つの作業グループによる真に創造的な作業でした。要件と条件を決定した顧客サービスです。 双方の技術専門家。その任務はこれらの状況を技術文書に変換することでした。 開発された技術文書に従って顧客の要件を実装する請負業者のプログラマーのチーム...その結果、私たちは原則に従わない要件の一部を既存のプラットフォームの機能に適合させ、請負業者は私たちのために何かを追加することを約束しました。 

XNUMX系統の並列運転

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

しかし、新しいシステムはまだ運用準備が整っていませんでした。 この段階では、古いシステムで監視を維持し、同時に新しいシステムにデバイスへのアクセスを許可することが重要でした。 システム内のデバイスを確認せずにシステムを適切に構築することは不可能であり、古いシステムによる監視を無効にすることもできません。 

デバイスが XNUMX つのシステムによる同時問い合わせに耐えられるかどうかは、実際にテストしないと明らかではありませんでした。 二重同時ポーリングにより、デバイスからの応答が頻繁に拒否され、デバイスが利用できないというエラーが多数発生し、古い監視システムの動作が妨げられる可能性がありました。

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

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

そして、私たちは新しいシステムが目の前でどのように構築されているかを観察し始めました。すでに私たちに馴染みのあるデバイスがその中に現れましたが、別のインターフェイスで、便利で、高速で、電話からでもアクセスできました。

最終的に何が起こったのかについては、記事の第 XNUMX 部で説明します。

出所： habr.com