0

100,000 以上のノードをサポートするように OpenSplice DDS を構成するために使用する正しいアプローチは何ですか?

「headquarters.city.location_guid_xxx」ではパケットが場所から離れないようにし、「company.city*」ではサンプルを都市全体に並べることができるように、パーティション名に階層的な命名スキームを使用できますか? それとも、すべてのノードは、公開したい場合に備えて、これらすべてのパーティションについて知っていますか?

耐久性サービスは、起動時にマスターを選択します。1 つの耐久性サービスが 3G リンクを介して実行されているリモート ロケーションの Raspberry Pi で実行されている場合、「本社」のマスターになってクラッシュするのを防ぐにはどうすればよいでしょうか?

location_guid_xxx を使用するようにリモート ノードで耐久性設定を試していますが、「本社」クラウド サーバーには本社を使用します。

リモート クライアントでは、次のようにします。

<Merge scope="Headquarters" type="Ignore"/>
<Merge scope="location_guid_xxx" type="Merge"/>

場所はユニバースのマスターにはなりませんが、場所内の耐久性サービスはその場所のマスターになることができますか?

100,000 の場所がある場合、本社にある ospl.xml ファイルの「マージ スコープ」にすべての場所をリストする必要がありますか? これだけで、処理できるネットワークのサイズが制限される可能性があると思います。

この製品は、この種のモノのインターネットのシナリオを処理すると想定しています。他の誰かがそれを試しましたか？

4

1 に答える 1

1

システムの規模を考えると、Vortex-Cloud の使用を真剣に検討する必要があると思います (これらのスライドhttp://slidesha.re/1qMVPrqを参照してください)。Vortex Cloud を使用すると、システムをより適切にスケーリングできるだけでなく、NAT/ファイアウォールに対処することもできます。それに加えて、TCP/IP を使用して Raspberry Pi からクラウド インスタンスに通信できるため、NAT/ファイアウォールに関連する問題を回避できます。

耐久性の質問に入る前に、指摘したいことが他にあります。100K ノードのフラット システムを構築しようとすると、かなりの量の発見情報が生成されます。いくらかのトラフィックを生成するだけでなく、エンド アプリケーションでメモリを消費します。代わりに、Vortex-Cloud を使用する場合は、発見情報を制限するためのトリックを行います。例を挙げると、データ書き込みが一致する 100K データ リーダーがある場合、Vortex-Cloud を使用すると、データ書き込みはエンドポイントでのみ一致するため、検出情報が 100K 倍削減されます!!!

最後に、耐久性の質問に関しては、一部の耐久性サービスを alignee のみとして構成できます。その場合、マスターになることはありません。

HTH。

A+

于 2014-07-31T11:43:54.460 に答える