dataPARCコーポレートアーキテクチャのベストプラクティス

dataPARCは、単一のサイトまたはロケーション内で強力なデータ視覚化および分析機能を提供するだけでなく、複数のプラントサイトや企業オフィスにまたがるデータを接続して、組織全体が最適な意思決定に必要なすべてのデータと情報にすばやくアクセスできるようにします。 システム全体のアーキテクチャは複数の方法で構成でき、顧客固有のさまざまな要因に応じて最適な設計が可能です。 この記事では、次の企業アーキテクチャの種類に関連して、これらの考慮事項について説明します。

• Single Centralized Corporate Server

• Distributed Servers

• Distributed Servers with Dedicated Corporate Server

注:  歴史家の建築に固有の詳細については、この記事を参照してください:  dataPARC Historian Architecture Best Practices

単一の集中型企業サーバー

単一の中央サーバーを中心に構築された企業のdataPARCアーキテクチャは、多くの場合、最もシンプルで経済的な選択肢です。 このスキームでは、dataPARC アプリケーション・サーバーは 1 つの中央ロケーション (多くの場合、本社) に常駐します。 すべてのリモートオペレーションサイトからのデータソースは、企業のワイドエリアネットワーク(WAN)を介してアプリケーションサーバーに接続されます。 すべてのリモート サイトのクライアントも、WAN 経由でアプリケーションサーバーに接続します。

考慮 事項

単一の一元化されたデータPARCアプリケーションサーバーには、実際のハードウェアまたは仮想のハードウェアと保守のためのオーバーヘッドが少なくて済むだけでなく、すべてのサイトのデータを単一のポイントに統合できるという利点があります。 ただし、WAN 経由で生データ ソースに接続する必要があり、物理的な距離が長くなる場合があります。 WAN の速度と転送するデータの量によっては、パフォーマンスの制限が発生する場合があります。

同様に、サーバーサイト以外の場所から中央サーバーに接続するdataPARCクライアントは、WANを介して通信する必要があります。 繰り返しになりますが、必要なデータの視覚化または分析の性質によっては、サーバー接続が物理的にローカルの場合よりもクライアントのパフォーマンスが遅くなる場合があります。

典型的な使用例

小規模で広く分散した運用サイトが多数ある業界は、単一の一元化されたアプリケーション サーバー アーキテクチャから最もメリットを得られる可能性があります。 このような場合、全体的なデータ負荷が高くなる可能性がありますが、通常、個々のサイトが提供するタグの数は比較的少ないです。 同様に、各サイトには少数の dataPARC クライアント ユーザーしかいないが、より多くのユーザーが本社にいる場合があります。 したがって、dataPARC アプリケーション・サーバーの数が多いため、各サイトにデプロイすることは現実的ではなく、各サイトのクライアント負荷が低い可能性があるため、リモート ・クライアントのパフォーマンス 低下 はそれほど深刻ではありません。

分散サーバー

分散サーバー・アーキテクチャーは、dataPARC アプリケーション・サーバーを企業の各事業所に配置します。 データ・ソース接続はローカルで行われ、ローカル・ユーザー・クライアントはローカル・エリア・ネットワーク (LAN) を介してアプリケーション・サーバーと通信します。 各サイトのアプリケーションサーバーは、dataPARCの「場所」設定を介して他の場所に接続するように構成されており、クライアントが他のサイトのデータにアクセスできるようにします。  この アーキテクチャ は 、サーバー の「メッシュ」とも 呼ばれ   ます。 本社などの非運用サイトのユーザークライアントは、WAN経由でアプリケーションサーバーの1つに接続する必要があります。

考慮 事項

分散サーバーアーキテクチャには、各サイトのローカルデータソースへの高速で堅牢な接続という利点があります。 また、オペレーティング・サイトのユーザー・クライアントは、ローカル・データ・ソースに接続されているため、必要なデータのほとんどを含むローカル・アプリケーション・サーバーに接続できます。 これは、データアクセスの大部分が高速で信頼性が高いことを意味します。

ただし、さまざまなサイトのアプリケーションサーバーがWANを介して接続されているため、サイト間データアクセスは、長距離ネットワークの速度制限の影響を受けます。 さらに、企業ユーザー クライアントは、サイト アプリケーション サーバーの 1 つに接続する必要があるため、サイトにローカルなユーザー サーバーよりもパフォーマンスが低下する可能性があります。 接続するアプリケーション・サーバーの選択は、通常、物理的な距離や、サイト間でクライアントの負荷を分散する必要性によって決まります。

典型的な使用例

多数の複雑な運用サイトを持ち、それぞれに大量のデータが含まれている企業は、多くの場合、分散サーバー アーキテクチャを選択します。 このアーキテクチャは、ローカル ユーザー クライアントが特定のサイトのデータに高速で確実にアクセスすることが優先される場合に適しています。 これらの企業では、企業やその他の非運用サイトのユーザー数がはるかに少ないため、これらのクライアントのデータ アクセス速度のペナルティは最小限に抑えられます。 サイト間データ交換は引き続き WAN 経由で提供されますが、これは通常、システムの主な目的ではありません。

専用の企業サーバーを備えた分散サーバー

このアーキテクチャは、上記の分散サーバーと同じですが、企業またはその他の集中的な場所にアプリケーション サーバーが 1 つ追加されます。 各サイトのデータ・ソース接続とクライアント接続はローカルのままですが、企業クライアント・ユーザーは独自のアプリケーション・サーバーに接続できます。 一元化された企業サーバーは、dataPARCの「場所」設定を介して各サイトのアプリケーションサーバーに接続されます。 アプリケーション・サーバーにヒストリアンが含まれている場合は、オプションでヒストリアン・データを中央企業サーバーにミラーリングできます。

考慮 事項

このアーキテクチャー・タイプは、分散アプリケーション・サーバーのすべての利点を提供するだけでなく、ローカル・サーバーにも接続できるため、企業拠点のユーザーのクライアント・パフォーマンスも向上します。 企業クライアントはすべて個別に接続しているわけではなく、ローカル サイト クライアントに加えて企業サーバーへの 1 つの接続のみを維持する必要があるため、サイト アプリケーション サーバーの負荷も軽減されます。 サイト サーバーにヒストリアンが含まれ、ヒストリアン データが中央の企業サーバーにミラーリングされている場合、これにより、パフォーマンスがさらに向上し、常に最新のデータ バックアップが可能になります。

もちろん、この追加のサーバーには、ハードウェア/ソフトウェアとメンテナンスのオーバーヘッドの両方の点でコストがかかり、システムにさらなる複雑さが加わります。

典型的な使用例

集中型企業サーバーを追加するかどうかは、通常、企業ユーザーの数とデータ アクセス ニーズの量によって決まります。 多数の企業クライアントがすべての運用サイトのデータにアクセスする必要がある場合、多くの場合、一元化されたサーバーを追加すると、追加の費用とメンテナンスのオーバーヘッドに見合う価値があります。 場合によっては、主要な 運用 サイト が分散サーバーを持ち、集中型アプリケーションサーバー が、独自のアプリケーションサーバーを保証するほど大きくないいくつかの小規模なリモート運用施設から入ってくる独自のデータソースにも 接続 する「 ハイブリッド」アーキテクチャを選択する場合もあります。