問題タブ [fault-tolerance]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
database - 分散マルチマスター データベースが必要な場合、どのような代替手段がありますか?
単一障害点を減らしたいシステムを構築し、データベースが必要です。マルチマスター設定を適切に処理できる (無料の) リレーショナル データベース システムはありますか (つまり、ノードの追加と削除が簡単な場合)、または NoSQL データベースを使用する方が良いですか?
私が理解しているように、キー値ストアはこれをより適切に処理します。マルチマスター (クラスター) セットアップに推奨するデータベース システムはどれですか?
testing - フォールトトレラントコードのテスト
私は現在サーバーアプリケーションに取り組んでおり、一定レベルのサービスを維持することに同意しています。保証したいサービスのレベルは次のとおりです。サーバーがリクエストを受け入れ、サーバーがクライアントに確認応答を送信した場合、サーバーがクラッシュした場合でも、リクエストが発生することを保証します。リクエストは長時間実行される可能性があり、確認応答時間は短くする必要があるため、リクエストを永続化し、クライアントに確認応答を送信してから、リクエストを実行するためのさまざまなアクションを実行することで、これを実装します。アクションが実行されると、それらも永続化されるため、サーバーは起動時にリクエストの状態を認識します。また、ログの正確性をチェックするための外部システムとのさまざまな調整メカニズムもあります。
これはすべてかなりうまく機能しているように見えますが、フォールトトレラントコードをテストするのは非常に難しいため、確信を持ってこれを言うのは困難です。これまでに2つの戦略を考え出しましたが、どちらも完全に満足のいくものではありません。
- 外部プロセスにサーバーコードを監視させ、外部プロセスがテストの適切なポイントであると判断した時点でサーバーコードを強制終了します。
- 特定の既知の重要なポイントをクラッシュさせるアプリケーションのコードを追加します
最初の戦略に関する私の問題は、外部プロセスがアプリケーションの正確な状態を知ることができないため、コード内で最も問題のあるポイントに到達していることを確認できないことです。2番目の戦略に関する私の問題は、フォールトテイクをより細かく制御できますが、オプションのコンパイルなどを使用しても、アプリケーション内にフォールトを挿入するコードが好きではないことです。フォールトを見落とすのは簡単すぎるのではないかと心配しています。注入ポイントとそれを本番環境に滑り込ませます。
php - Web サーバーでのエラーの監視と処理
多数のアプリケーションを起動しようとしている Web サーバーがあります。それらはすべてデータベースと memcached サーバーを共有しますが、各アプリケーションには独自の mySQL データベースがあり、アプリケーションごとにすべての memcached キーがプレフィックスされます。
考えられるシナリオ:
クラスター内の memcached サーバーがブームになった場合、電子メール/iPhone プッシュ通知またはその他の適切な方法で、誰か (運用システム管理者) に自動的に連絡する必要があります。
顧客向けに 150 個の同一のアプリケーションをサーバーにインストールしようとしていて、memcached サーバーが停止した場合、150 個のアプリケーションすべてが個別にこれを見つけて、システム管理者に連絡します。システム管理者は、新しい仕事を得ることを考えるでしょう。朝の 4 時 15 分に 150 件のメッセージが送信されて目が覚めることはありません。
考えられる解決策:
1 つのアイデアは、送信された $_POST または cURL 要求を取得し、実際のエラー メッセージの深刻度に応じてエラー メッセージの保存を処理するエラー処理用の外部サーバーをセットアップすることです。もちろん、エラー コールの受信時にチェックします。同じ memcached サーバーが既にオフラインとして報告されている場合は、システム管理者に追加のリマインダーを送信する必要はありません...
質問:
- エラーを処理する方法についての良いアプローチは何ですか?
- 業界の大物はこれをどのように処理しますか?
ありがとう!
c# - スケジュールされたタスクまたはサービスの耐障害性と信頼性のベスト プラクティス
私は、Windows サービスまたはスケジュールされたタスクとして実行される多くのアプリケーションに取り組んできました。
今、私はこれらのアプリケーションがフォールト トレラントで信頼できるものであることを確認したいと考えています。例えば; 私は毎時間実行するサービスを持っています。動作中または実行中にサービスがクラッシュした場合、データの損失を避けるために、同じ期間にアプリケーションを再度実行する必要があります (これには、データ処理のトランザクションを含むいくつかの事柄が関係しています)。さらに、プログラムがエラーを詳細に報告するようにします。私の目標は、データの損失を回避し、プログラムの実行に遅れをとらないようにすることです。
ユーザーがプロジェクトにインポートできるクラス ライブラリを作成しました。ライブラリは、プログラムの実行中のインスタンスの情報を保持することになっています。プログラムは、実行間隔、実行ステータスなどの情報を読み書きします。このデータはデータベースに保存されます。
スケジュールされたタスク/ Windows サービスを耐障害性と信頼性を高めるためのベスト プラクティスがあるかどうか、私は興味がありました。
編集:異なるサーバー上にある独立したタスクまたはサービスについて話しています。私の目標は、サービスが実行され続け、障害があれば報告し、それらから回復できるようにすることです。
transactions - Erlang/OTP メッセージは信頼できますか? メッセージは複製できますか?
長いバージョン:
私は erlang を初めて使用し、スケーラブルなアーキテクチャに使用することを検討しています。私は、プラットフォームの信頼性とフォールト トレランスを売り込んでいる多くの支持者を見つけました。
ただし、メッセージが一時メモリにキューイングされるこのシステムでフォールト トレランスがどのように達成されるかを正確に理解するのに苦労しています。スーパーバイザーの階層を調整して、死亡したプロセスを再起動できることは理解していますが、進行中の作業での再起動の意味についての議論を見つけることができませんでした。進行中のメッセージと、瀕死のノードで失われた部分的に完了した作業のアーティファクトはどうなりますか?
すべてのプロデューサは、コンシューマ プロセスが終了したときに確認応答されなかったメッセージを自動的に再送信しますか? そうでない場合、これはどのように耐障害性があると見なすことができますか? もしそうなら、処理されたが完全に承認されていないメッセージが再送信され、不適切に再処理されるのを防ぐものは何ですか?
(これらの懸念は erlang に固有のものではないことは認識しています。同様の懸念は、どの分散処理システムでも発生します。しかし、erlang 愛好家は、このプラットフォームによってこれがすべて「簡単」になると主張しているようです..?)
メッセージが再送信されると仮定すると、複雑なメッセージング チェーンのダウンストリームへの影響が障害後に非常に混乱するシナリオが容易に想像できます。ある種の重い分散トランザクション システムがなければ、すべてのプロセスで重複に対処せずに一貫性と正確性を維持する方法がわかりません。トランザクションが複数回実行されるのを防ぐために、アプリケーション コードは常に制約を適用する必要がありますか?
短縮版:
分散された erlang プロセスは重複メッセージの影響を受けますか? もしそうなら、重複保護 (つまり、冪等性) はアプリケーションの責任ですか、それとも erlang/OTP は何らかの形でこれを助けてくれますか?
sql-server - リアルタイムの SQL サーバー駆動型システムでの例外処理
.NET Winforms でレポート ビューアーを開発しました (クエリを実行して結果を表示するだけです)。
これは、レポート データベースに対して機能します。ただし、上記は、別のデータベースからデータを取得する、はるかに大きなアプリケーションの小さなサブセットです。次のようになります。
監視対象システムの状態が変化します (例: レイテンシーの増加) => イベントが SQL Server データベース (このデータベース A と呼びます) にトランザクションとして記録されます => これによりトリガーが起動され、同じイベントがレポート データベースに書き込まれます。
2 つのデータベースの違いについてはよくわかりません。異なる目標に合わせて調整されているか、2 つのデータベースには経済的または政治的な理由がある可能性があります。
とにかく、レポートデータベースはメインデータベースに「トランザクション的に依存」しているという用語が言及されました。これは正確にはどういう意味ですか?レポート データベースは、データベース A のトランザクションに完全に依存していますか? これは私にいくつかの質問を考えさせました:
1) レポート データベースにディスク領域がないのに、データベース A がまだレポート データベースに対してトリガーを起動しているという状況にどのように対処できますか? 2)キューに入れるのは良いでしょうか 2)上記にリンクされていますが、トリガーとそのデータをレポートデータベースに送信できない場合(方法はわかりませんが、概念的に...)キューに入れるとうまくいきますか?それでも、これによりシステムはリアルタイムではなくなります。
このようなセットアップでの例外処理に関する他の危険/問題はありますか?
ありがとう
scala - Scala + Akka: マルチマシンの高可用性クラスターを開発する方法
Android、iPhone、Second Life のクライアントにサービスを提供するゲーム用のサーバー システムを Scala + Akka で開発しています。このサーバーには、複数のマシンで実行する高可用性が必要な部分があります。これらのサーバーの 1 つが (ハードウェア障害などで) 停止した場合でも、システムは稼働し続ける必要があります。私は、Cassandra の仕組みと同様に、クライアントが接続しようとするマシンのリストを持っていることを望んでいると思います。
これまで Akka で見たマルチノードの例は、高可用性 (少なくともハードウェアに関して) ではなく、スケーラビリティの考え方に重点を置いているように思えます。マルチノードの例には、常に単一障害点があるようです。たとえば、ロード バランサーがありますが、ロード バランサーを備えたマシンの 1 つを再起動する必要がある場合、システムにダウンタイムが発生します。
Akka のこのタイプのハードウェア フォールト トレランスを示す例はありますか? または、これを実現するための良い方法について何か考えはありますか?
これまでのところ、私が思いついた最善の答えは、Erlang OTP のドキュメントを調べて熟考し、Akka で利用可能なビルディング ブロックを使用してシステムを組み立てる方法を見つけようとすることです。
しかし、リソース、例、または複数のマシン間で状態を共有して、そのうちの 1 つがダウンしても実行を継続する方法に関するアイデアがあれば、それらを高く評価します。ここの車輪。複数のノード間で共有状態を自動的に同期するマルチノード STM コンテナーがあるのではないでしょうか? あるいは、これは非常に簡単に作成できるため、ドキュメントではその方法の例をわざわざ示していないのかもしれません。あるいは、私の研究と実験がまだ十分に徹底されていないのかもしれません。どんな考えやアイデアでも大歓迎です。
erlang - Erlangのフォールトトレラントはどのようになっていますか、またはその点で役立ちますか?
Erlangのフォールトトレラントはどのようになっていますか、またはその点で役立ちますか?
design-patterns - チェックポイントとリカバリを備えたトランザクションサービスのデザインパターン
各ステップでネットワークIO(Webサービス呼び出し)を実行してからデータを永続化するマルチステッププロセスがあります。システムクラッシュまたはいずれかのステップの失敗が原因でサービスが失敗した場合に、最後のエラーのないステップから回復して再開できるように、フォールトトレラントな方法で設計したいと思います。
これが私がこれに対処することをどのように考えているかです(これはかなり高いレベルです):
- 各ステップの状態(NOT_STARTED、IN_PROGRESS、FAILED)をデータベーステーブルに保存しました
- ステップが失敗した場合は、そのステップとその依存ステップを「失敗」としてマークし、次の非依存ステップに移動します
- このテーブルを読んで回復します(たとえば、アプリケーションのブートストラップ部分で)
この問題に対処するデザインパターン、フレームワーク、アルゴリズムがあるかどうか疑問に思いました。
scalability - 定期的なタスクの負荷分散に適したNServiceBus
NServiceBusまたは同等のESBは、さまざまな種類のバックグラウンドメンテナンスタイプのタスクが多数あるアプリケーションに適していますか?例えば:
- ユーザー生成コンテンツでの特定の単語の出現についてデータベースをスキャンする
- 比較的高価なクエリの結果を格納するデータベーステーブルの更新
- コンテンツの外部インデックスの作成/維持
- スケジュールされたイベントのイベント通知メールを送信します。
私の考えは、ある種のタスクスケジューラ(Windows組み込みのもの、Quartz.NET、または私自身のデータベースベースのソリューション)を使用して、さまざまな種類のメッセージをバスに定期的に公開することです。期間は、最短で1分、最長で1日です。バスを使用したい理由は、システムが大きくなり、忙しくなり、タスクがより頻繁になるか、より多くのリソースを消費するようになるにつれて、サブスクライバーの数をスケールアウトできるようにするためです。また、少なくとも2人のサブスクライバーを常に実行している限り、冗長性も提供されます。
これに代わる明らかな方法は、スケジューラーによってトリガーされて作業を実行する独自のWindowsサービスを作成することですが、ESBを配管として使用するよりも、単一のマシンを超えてそのスケールを作成し、フォールトトレランスを提供する方が難しいと感じています。 。
これは合理的なアプローチのように聞こえますか?別の提案?
TIA