問題タブ [fault-tolerance]

質問が不明確になる可能性があることは承知しています。説明してみます。

シーケンスを生成するシステムがあまり正確ではないことだけを確認する必要があるシナリオがあります。5,10,15,20....,値を見逃すか、いくつかの値を繰り返すことがあります5, 10,10,20,25,30,40.

ご覧のとおり、 の許容誤差があり5-10ます。

これは大丈夫です。シーケンスが次のように逆行しないことを確認する必要があります5,10,15,10.. or 5,10,9,....

時折のミスまたは繰り返しで単調に増加するシーケンスが見られる場合は合格し、値が逆行するか、値が 100 を超えて異なる場合は失敗するロジックを使用してPASS FAIL条件を記述する必要があります。10 (like 5, 20, 15...)

誰かがこれの正しいロジックを特定するのを手伝ってくれますか

XYZ.com がダウンする前に、リクエストが IP アドレス 192.33.31.xxx にルーティングされていることに気付きました。それがアップすると、リクエストが IP 50.17.196.xxx にルーティングされていることに気付きました。これは何らかのサーバー スイッチングですか? 障害時の動的なサーバー切り替えは、フォールト トレラント システムを実現するための方法ではないでしょうか。

巨大なインスタンスを作成する以外に、インスタンスを別々の物理マシンで強制的に実行するか、アマゾン ウェブ サービス (AWS) で同じイメージの複数のインスタンスによって使用されている物理マシンの数を検出する方法はありますか?

ここで信頼性を考えています。3 つの異なるインスタンスが実行されているため、フォールト トレランスのために 3 つの独立したサーバー (Paxos、Quicksilver、ZooKeeper など) があると思い込んでいるのに、3 つすべてが同じ物理マシン上で実行されることになる場合、非常に、非常に失礼な驚きです。

別のリージョンを使用することで問題が発生する可能性があることは認識していますが、AWS が実際に提供するのを見たことがないので、リージョン内またはアベイラビリティ ゾーン内のソリューションがあるかどうかを知っておくとよいでしょう。インスタンスを作成するときに、おそらく複数選択のプルダウン メニューで複数のアベイラビリティー ゾーンを選択します。

OK、最初の 2 人からの質問への回答に感謝しますが、1 つの地域に 3 台のマシンを配置することで、小説を書かずに問題を単純化しようとしていました。もう一度試してみましょう。架空のアプリ スタックを上方向または外方向にスケールするときに、インスタンスを静的および動的 (「弾性的」) に追加します。もちろん、あらゆる種類の障害/災害が発生する可能性があります (たとえば、電子レンジ、CD、および 2 人の馬鹿が関与した不幸な休憩室の事故により、データ センター全体が全焼する可能性があります。 !") ですが、なんらかのハード マシン障害である可能性がはるかに高く、その後すぐにデッド ポートが続きます。仮想化されたハードウェアの 1 つの部分で同じ型 T の複数のインスタンスを実行すると、計算能力が向上しますが、フォールト トレランスは向上しません。明らかに、もし私が' スケールアップ/スケールアウトする場合、「より大きな」インスタンスを使用する可能性が最も高いです。明らかに、AWS の最大のマシンのメモリ サイズが M でプロセッサの数が C の場合、m > (M/2) となるメモリ サイズ m または c > (となる CPU サイズ c のインスタンスを選択するとします。 C/2) の場合、インスタンスが別のマシンで実行されることを保証します。しかし、私はMが何であるかを知りません_maxと C _maxは今日です。Amazon が Bigger Better Faster を買収するので、1 年後、2 年後など、彼らがどうなるかは確かにわかりません。これは要点をくつがえしたり、詳しく説明したりするように聞こえますが、インスタンスがどのように分散されるか、またはインスタンスの分散を制御するメカニズムがあるかどうかを知らないということは、現在の値を使用して効果のある F+1 または 2F+1 を計算する際に、仮定で真の間違いを犯す可能性があることを意味します。分散コンピューティング アルゴリズムまたは新しいアプリケーションで使用するための新しいアルゴリズムの評価、シャーディングとローカリティの決定、アプリスタックのトラフィックが少ない部分の最小予約インスタンス数とエラスティック インスタンス数など。

次のコードがあります。

self ! KillアクターのインスタンスでA「アクターが殺されました」というメッセージが表示されず、その後のアクターへの呼び出しで「Aデッド レター」メッセージが生成されるため、再起動されませんでした。OneForOneStrategyが呼び出されない のはなぜですか?

オーバーライド全体を削除するだけOneForOneStrategyで、プログラムの動作にまったく変更がないという点で奇妙です。

特定のサービスについて、単一のEC2 インスタンスをフォールト トレラントな方法で実行する必要があります。

エラーが発生した場合にのみ、「プライマリ」マシンを終了し、トラフィックを「セカンダリ」マシンに数秒以内に自動的にリダイレクトする必要があります。これは、プライマリ サーバーがクラッシュしない限りセカンダリ サーバーが動作してはならないという制約があるプライマリ サーバーとセカンダリ サーバーの典型的なケースです。

私はこの世界ではまったく新しいものですが、理解している限り、Elastic IP では、プライマリ マシンがハングした場合にバインディングを手動で変更する必要があります。代わりに、Auto Scaling、ELB、および CloudWatch を使用すると、次のことができます。

• 2 台のマシンで Auto Scaling パークをセットアップしますが、トラフィックは負荷分散されます (スティッキー セッションが機能する場合、プライマリ マシンのすべてのトラフィックが必要になるため、スティッキー セッションは必要ありません)。
• 1 台のマシンだけで Auto Scaling をセットアップして、プライマリ マシンが自動的にハングした場合、新しいマシンがオンラインになるようにします。ただし、私の知る限り、起動プロセスには数分かかります。

この目標を達成するために AWS のサービスを組み合わせる方法について何かアドバイスはありますか?

低レイテンシが優先度の高いソケットを介して相互にデータをやり取りする 20 以上のノードからなる内部システムがあるとします。ランダムなサーバーがダウンした場合、ダウンしたサーバーによって処理されずに送信済みのデータを復元/再送信できるようにするにはどうすればよいですか?

たとえば、A が B にデータをストリーミングしていたが、ある時点で B が一部のデータを処理せずにダウンしたとします。A が B がダウンしたことを検出し、データを C に再ルーティングできると仮定すると、どのデータが B に送信され、C に再ルーティングされるべきかを知るにはどうすればよいでしょうか?

さまざまなメッセージ キュー ソフトウェアに依存する必要があると思いますが、これを行う簡単な方法が他にもあるのではないかと考えています。

SimpleActorメッセージを自分自身に送信することで定期的なタスクを実行するActor ( ) がある非常に単純な例があります。メッセージは、アクターのコンストラクターでスケジュールされます。通常の場合 (つまり、障害がない場合)、すべて正常に動作します。

しかし、アクターが障害に対処しなければならない場合はどうでしょう。別のアクター ( SimpleActorWithFault) がいます。このアクターには欠点がある可能性があります。この場合、例外をスローして自分で生成しています。障害が発生すると (つまり、SimpleActorWithFault例外がスローされると)、自動的に再起動されます。ただし、この再起動により、アクタ内のスケジューラが台無しになり、例外として機能しなくなります。また、障害が急速に発生すると、予期しない動作がさらに発生します。

私の質問は、そのような場合に障害に対処するための好ましい方法は何ですか? Tryブロックを使用して例外を処理できることを知っています。しかし、Try をスーパー クラスに配置できない別のアクターを拡張している場合や、例外的な障害がアクターで発生した場合はどうなるでしょうか。

リモート マシンの突然のクラッシュを検出するプログラムを作成しています。マネージャー プロセスはマシン 1 で実行され、ワー​​カー プロセスはマシン 2 で実行されます。マネージャー サーバーは、 を呼び出してメッセージをワーカー プロセスに送信しますMPI_Isend。リモート ワーカーは、 を呼び出してメッセージを取得しますMPI_Irecv。各呼び出しの後、私は常に彼らの戻りコードをチェックして、に問題があるかどうかを確認しMPI_COMM_WORLDます. MPI_Testまた、send および recv 呼び出しの後に実行される戻りコードも確認します。

どういうわけか、マシン 2 を突然再起動しても、リターン コードは常に 0 です。戻り値はMPI_Isend常に 0 です。リモート マシンの障害を検出する方法についてアドバイスをお願いします。

ところで、私は次のステートメントを使用しました：

Tibco EMS は、サーバー側のホット バックアップ構成でフォールト トレランスを提供することを認識しています。詳しくは、ユーザー ガイド、この回答、およびこちらを参照してください。

しかし、クライアント側では、Tibco EMS はフォールト トレラントなクライアントにすぐに使用できるソリューションを提供しますか? 例: トピックでは、Sports.F1.PitStop2 つのクライアント (server1、server2) がパブリッシャーとして登録されます。server1 で何か問題が発生した場合 (つまり、server1 のパブリッシャーがダウンした場合)、server2 はトピックでシームレスにパブリッシュを続行するという考えです。問題は、Tibco EMS がそのようなクライアント側のフォールト トレランス機能を提供するかどうかです。