分散アプリケーション用の軽量クラスターアーキテクチャを実装する方法
現在、複数の組み込みPCで実行される分散アプリケーションがあります。アプリケーション全体は、1つのマスターサーバーと複数のノードで構成されています。各ノードは、Windows 7 Embeddedを実行する組み込みPCであり、2GBのRAMを備えたデュアルコアCPUを備えています。
アプリケーションは（定義上）マスターが稼働中で、すべてのノードを制御している場合にのみ機能します。マスターサーバーにはSQL Expressデータベースがあり、制御するすべてのノードとそれらの構成方法に関する情報を保持しています。ノードには永続的な状態がありません。
マスターとノードが起動して実行されると、それらは操作されて特定の状態になり、この時点でのみメモリに保持されます。マスターは、それに接続し、その状態を読み取り、その状態を変更するコマンドを送信できるWinFormクライアントUIによって制御できます（基本的には、.NET WCFを使用して公開される一連のWebサービスです）。
マスター内（メモリ内）に保持される状態が重要です。たとえばノードが再起動した場合、各ノード内の状態を再生成できます。マスターを再起動すると、現在の状態が失われます（結果としてノードの状態も失われます）。これは、マスターサーバーの再起動後、構成が再ロードされ、「新しい」状態が設定されることを意味します。
通常、このアプリケーションのセットアップは、1つのマスターと9つのノードで構成されます（これは3x3セットアップです）。いつでもノードに障害が発生する可能性があり、（マスターが起動している限り）アプリケーションはノードなしで続行されます。障害が発生したノードが戻ると、マスターがそれを検出して、目的の状態に戻します。
マスターサーバーがいずれかのノード内で実行できるように、このアプリケーションのアーキテクチャを改善するように依頼されました。したがって、9 + 1セットアップの代わりに、9台の組み込みPCだけがマスターとして選択されます。私たちのテストによると、ノードのハードウェアには、ノードとマスターピースの両方をサポートするのに十分なパワーがあります。ただし、組み込みPCは信頼できず、これまでマスターをホストするために使用していた通常のサーバーよりも頻繁に失敗します。
そのため、私は冗長ソリューションを考え出すように求められました。適切な解決策はクラスターで実行されている2つ以上の埋め込みを配置することですので、マスターピースを実行しているノードに障害が発生した場合、別のノードがその場所を想定します。
さて、問題は、これらの条件で実行できる軽量クラスターを実装する方法ですか？
解決しなければならない2つの主な懸念事項があります。
- データの永続性：構成を保存するだけでなく、マスターの状態も保存する必要があります。このようにして、マスターノードがダウンしたときに、アプリケーションの状態全体をリセットすることなく、別のノードがマスターと見なすことができます。
- WCFクラスタリング：マスターノードで障害が発生した場合はいつでも、別のマスターノードが想定し、接続されているすべてのクライアント（WinFormクライアントUI）が、新しく再選されたマスターノードに自動的に再接続できる必要があります。これはユーザーに対して本当に透過的である必要はありませんが、クライアントは自動的に再接続できなければなりません（新しいIPアドレスが同じかどうかは関係ありません）。
考えられるソリューションにはいくつかの制限要因があります。
- ノード間でデータストレージを共有する方法はありません（各ノードには独自のHDとノード間のプライベートギガビットネットワークがあります）
- ハードウェアのアップグレードは問題外です
- ソリューションは、組み込みPCで実行できるように十分に軽量でなければなりません。したがって、クラウドサーバーまたはクラスター化されたDBのインストールはおそらく十分高速ではありません（MySQLクラスター化がデータレイヤーを解決するために機能すると思われる場合、私はあなたの考えを聞きたいと思います）
- ソリューションでは、高価なソフトウェアを購入する必要はありません
- このアプリケーションの全体的なプラットフォームはWindowsベースである必要があります
これまで考えた最良の解決策は、マスターの状態を維持するために Prevayler のようなものを使用して、マスターが他のノードに受け取ったすべてのコマンドの同期を実装することでした。これにより、すべてのノードにわたる永続性の問題が解決します（おそらくmemcacheを使用して同様のものが実装できると思います）。 WCFサービスの問題を解決するための解決策はまだありません。
これには膨大な量の開発と適切なテストが含まれるため、何かを実装する前に皆さんから連絡があると思います。
問題の一部を解決するフレームワークまたはある種のオープンソースソフトウェアを使用することで、ソリューションを組み立てることができると思います。
この質問のテキストを改善してわかりやすくするため、何でもお気軽にご質問ください。
（適切な）単一のマスターノードから離れるので、いくつか変更する必要があります。 Quorum を設定する必要があります。すでに9つのノードがあるので、状態は良好です。クォーラムが機能するためには、2n + 1個のノードが必要です。ここで、（n）はダウン可能なノードの数であり、システムは引き続き機能します。クォーラム内では、リーダーが誰で、どのトランザクションが成功したかについて投票が行われます。これを使用して、構成情報を渡し、データベースなしで全員が同期されるようにすることができます。
これを助けることができる既存の技術があります。これの1つは ZooKeeper です。これは、分散調整用のオープンソースのApache v2製品です。これらの線に沿って何かが必要になります。 ZooKeeperを使用する場合でも、独自のホワイトペーパーを作成する場合でも、非常に貴重です。また、各ノードの構成情報を維持するためにも使用できます。
ZooKeeperはJavaで記述されていますが、IKVMを使用して.NETアプリケーション内に埋め込むことができるプロジェクト（ ZooKeeperNet を作成しました。これが受け入れられない場合は、 リーダー選挙 を読んで、誰が現在のマスターノードになるかを決定する必要があります。Wikiページとレシピをすべて読んで、適切な配布で説明する必要があることについて理解することをお勧めしますシステム。
ちょうどあなたはよく理解しています。 ZooKeeperは、HadoopとHBaseのバッキング調整システムです。 Hadoopは分散Map/Reduceフレームワークです。
まだ使用していない場合は、システムで現在のマスターノードを検索するときに、WCFアドホックまたはレジストリ検出情報を使用できます。マスターノードが1つだけ生きている場合は、それがIMaster機能をサポートする唯一の登録ノードになります。次に、スレーブノードは互いのznodeでお互いがリッスンするのをリッスンし、ほぼすぐにマスターになります。
高い効率を実現するには、各ノードが処理する必要のあるデータがノードに近い（つまり、ノード自体にある）必要があることに注意してください。 1つのノードがデータの仲介役として機能する場合、ノードが分散型の方法でデータをプルできる場合ほど効率的ではありません。
[〜＃〜] amqp [〜＃〜]
[〜＃〜] amqp [〜＃〜] 実装を使用して、ノードの更新がallマスターに移動することを保証します。これにより、すべてのマスターのデータが同期されます。無料のAMPQ実装があります（無料ではありません）。おそらく、適切な許容範囲などを把握するためにテストを実行する必要があります。更新率が極端に高くなく、平均的な更新がそれほど大きくないと仮定すると、ギガビット相互接続はかなりの量のキュー通信をサポートします。 YYMV、それであなたは間違いなくいくつかの数値を実行して、それをバックアップするためにいくつかのテストをしたいでしょう。
クラスターIPを使用したネットワーク負荷分散
負荷分散を処理する一般的な方法の1つは、単一のクラスターIPをアドレス指定することです。このソリューションについては、Windowsでよく見られること以外はあまり知りません。 （私の仕事でかなり使用されています）