私たちの製品の次世代のために、フェイルオーバー機能（複数のノードがあり、ノードの1つがクラッシュした場合、データ損失は最小限/無くなります）とロード・バランシング（したがって、各ノードはデータの一部のみを処理する）。私が非常にうまくいかないのは、どうやって両方できるのかです。ノードがすべてのデータを持ち、合意されたサブセットのみを処理すると仮定します。要素8を変更します。他のすべてのノードは間違った要素を持っています。8.したがって、同期する必要があります。完全性を維持するために、他のすべてのノードに要素8が変更されたことを伝えます。しかし、確かにそれはちょうどロードバランシングの嘲笑を作るのですか？フェールオーバーと負荷分散 - 相互に排他的ですか？
短い答えは、アプリケーションのアーキテクチャに大きく依存しているということです。
これは、同じレイヤーで同時にスケールアウト処理と惨事復旧を解決しようとすると、悪いデザインのアンチパターンを使用して考えているようです。各ノードがデータの一部のみを処理する場合、他のノードのフェールオーバーにはなりません。スケールアウトとDRの両方をフェデレーションのタイプを使用して実装できるので、多くの人がこのトラップに該当しますが、メカニズムを目的と混同しないでください。私は丁重にこの問題について少しずつ異なった考えをする必要があります。 - アプリ
レイヤ1：
この問題にアプローチする方法は2つの全く別個の層です。あたかもDRの必要がないかのように、あなたのアプリケーションのためのハイレベルなデザインを作ってください。他にDRで使用されるこのアプリの別のインスタンスがあるかもしれないという事実を無視してください。機能的な&あなたのアプリケーションのパフォーマンス面に焦点を当てる - 異なるサブシステムがあれば、ワークロード上の理由でスケールアウトする必要があるかどうか。このアプリは全体として100％のデータを処理します。アプリケーション自体に必要なスケールアウト/フェデレーションアプローチがあるかどうかは、DR要件には関係しません。
レイヤ2 - DR。今あなたのアプリをブラックボックスと考えてください。可用性要件を満たすために必要なブラックボックスのインスタンス数と、それらのインスタンス間で必要な同期度をどのように維持しますか？ &の復旧のパフォーマンス要件は何ですか（可用性までの時間、許容されるデータ損失がある場合、次のフェイルオーバーの前にどれくらいの時間がかかりますか？&）。
レイヤ1に戻る - レイヤ2で特定したリカバリ手法とツールを使用するハイレベルデザインの実装方法を選択します。たとえば、データ同期にマスタースレーブDBアプローチを使用する場合DRノードでは、フェイルオーバー時にDBノードに保存する必要があるすべての情報を格納します。アプリケーションノードローカルファイルやメモリには格納しません。これらの選択肢は、選択したDRフレームワークによって異なります。
アプリ層とDR層のデザインは関連していますが、適切なツール&を選択すると強く結合する必要はありません。例えば。 Amazon Web Servicesでは、IPロード・バランシングを使用してリクエストをフェイルオーバー・アプリケーション・インスタンスに転送できます。また、関連するすべてのデータ（セッションおよびその他の一時的なものを含む）をデータベースに格納し、DBMSのネイティブ・レプリケーション機能を使用すると、
ボトムライン：
幸運