ピアトポロジを使用すると、サーバー障害のリスクが軽減されますか？
私のクライアントは、特定のサンプルのさまざまな測定を行い、その結果をデータベースに書き込む医療機器を製造しています。生成されるデータの量は比較的少ないです。
現在の構成では、各デバイスに独自のコンピューターがあり、そのコンピューターはデータベースサーバーのインスタンスを実行します。デバイスはネットワーク化されていません。
クライアントは、デバイスの約50個をローカルエリアネットワークに接続できるようにデバイスを変更したいと考えています。
デバイスは、ロット番号が付けられたさまざまな消耗品を使用しており、一度使用すると再び使用することはできません。これらのロット番号は、サンプルの測定時にデータベースに書き込まれます。現在の構成では、消耗品が別のデバイスによって使用されているかどうかをデバイスが知る方法がないため、この要件は注目に値します。提案されたネットワーク構成では、各デバイスが他のデバイスによって使用される消耗品に関する情報に即座にアクセスできることが期待されています。
デバイスは、テストプロセスで使用されるさまざまな化学物質の量も追跡する必要があります。化学薬品の各ボトルにはロット番号とバーコードが付いています。ボトルがマシンに挿入されると、マシンはデータベースを読み取って、ボトルから消費された液体の量を判別します。ロット番号の付いたボトルはどのマシンにも挿入でき、マシンはボトル内の液体の量を正確に評価できることが期待されています。
クライアントは、2つのアーキテクチャのどちらを使用するかについての推奨事項を求めています。
1.）各デバイスは、現在と同様に、独自のローカルデータベースにデータを書き込みます。同期ソフトウェアが各デバイスにインストールされ、同期がリアルタイムで実行されます。各デバイスは定期的にハートビートをブロードキャストし（1〜5分間隔が提案されています）、このハートビートにはCRCチェックサムが含まれます。ネットワーク上のすべてのデバイスがハートビートをリッスンします。ハートビートCRCがデバイスと異なる場合、デバイスは同期を開始します。同期ソフトウェアは、テストを実行するソフトウェアの外部にあり、独立しています。したがって、理論的には、デバイスがネットワークから切断されている間、または同期ソフトウェアが実行されていないときに実行される可能性はありますが、可能性はありません。
2.）各デバイスのデータベースサーバーが削除され、代わりにデータベースサーバーが使用されます。
クライアントは、データベースサーバーが使用されている場合、サーバーに障害が発生した場合にネットワーク上のすべてのデバイスが使用できなくなることを懸念しています。ピアトポロジを使用すると、このリスクが効果的に軽減されますか？言い換えると、ネットワーク上の1つのピアに障害が発生した場合、それは他のすべてのピアにとって通常どおりのビジネスですか？どちらのアプローチにも関連するデータ整合性の危険性または利点はありますか？
iagとMikeyBからの回答に応じて編集：
私の質問がどのように曖昧さの余地を残しているのかがわかるので、ここでも、うまくいけばもっと意味のある方法で表現されています。
クライアント/サーバー環境では、サーバーに障害が発生するとすべてのクライアントがシャットダウンされるため、サーバーの障害は壊滅的です。その設計機能を考えると、なぜいくつかの非常に重要な情報、在庫、財務、および医療システムが、ピアツーピアではなくクライアントサーバーアーキテクチャを実装するのでしょうか。
「リスクサーバーの障害を軽減するにはどうすればよいですか？」と質問していないことに注意してください。 「ピアツーピアアーキテクチャは、サーバー障害のリスクを軽減する効果的な方法ですか？」と質問しています。なぜまたはなぜそうではないのですか？ネットワークのトポロジーはアプリケーションの設計に影響を与えますか？ピアツーピアは、データの破損やあいまいな結果の可能性をもたらしますか？
次の例は、ピアツーピアネットワークトポロジで発生する可能性のある現実的な例ですか？
DeviceA、DeviceB、およびDeviceCは、エージェントRと呼ばれる共通のエージェントを共有するピアネットワーク上のコンピューターです。ピアが使用可能なRの量を確認する必要がある場合は常に、他のピアと同期して可用性を計算します。ある日の午後1時頃、ラボの技術者はRのボトルをDeviceBに挿入します。 DeviceBはすぐにDeviceCと同期し、DeviceCがそのボトルからRを消費したことがないことを確認します。ただし、DeviceAは正午からpingに応答していません。 DeviceBはボトルで利用可能なRの量を確実に計算できますか？
私はソフトウェアエンジニアであり、これらのデバイスがネットワークを介してデータを共有できるようにするアプリケーションを作成します。正直なところ、私は私が尋ねている質問について意見を持っていますが、私のクライアントは私の経験を信頼していません。仲間の経験を知りたいので、ここに投稿します。私は誰の口にも言葉を入れたくないので、できるだけ一般的ではなく、それでも問題を説明しようとしています。
ピアツーピアソフトウェアアーキテクチャは、基盤となるネットワークにすでに冗長性があることを前提として、ノード間で情報を配布するための効率的でフォールトトレラントな方法です。
ピアツーピアアーキテクチャは、複数のノードがデータを保持している場合、データ損失からユーザーを保護することもできます。通常のピアツーピアシステムでは、ノードは自身の関心のためにデータを保持します。個人の利益ではなくポリシーを順守するためにデータを保持してほしいので、必要なものは異なります。
データの量が制限されている限り、これまでに見たすべてのものを格納する各ノードは単純です。ただし、ストレージスペースが原因で（または法的要件のためにシナリオによっては）、すべてを保存することは実用的でない場合があります。次に、何を削除し、何を保持するかについて注意する必要があります。これは大きな落とし穴の1つです。
しかし、これはすべて、データの整合性とデータの整合性の問題に対処するためのものではありません。データの正確性を考慮せずに単にピアツーピアアーキテクチャに切り替えると、その点でのシステムの堅牢性が低下します。汚職が導入される場所は他にもたくさんあります。
このようなソリューションを実装するには、データの整合性を検証する方法を理解する必要があります。
システム内の特定の1つのノードでしか更新できなかったデータは、最も扱いやすいものです。ただし、そのノードが誤動作し始めた場合、システムの許容可能な動作について質問する必要があります。ノードに各更新に暗号で署名させるだけでは不十分です。署名された更新を誤って送信して、以前に書き込んだすべてを削除したり、データの新しい値が何であるかについて意見が一致しない複数の署名された更新を送信したりする可能性がある場合です。ここでも簡単なアプローチは、すべてを保存し、競合する更新が表示された場合は手動で介入する必要があることです。しかし、データに基づいて何らかの自動決定を行う必要がある場合は、それだけでは不十分です。
1つのノードのみがデータを更新できるが、他のすべてのノードがどの更新を実行するかについて合意するという厳格な要件がある場合、問題は少し難しくなります。
この問題の解決策はまだそれほど複雑ではなく、そのようなデータ整合性の問題を解決するために使用される方法の種類についての良いアイデアを提供します。
- 更新ノードは更新されたデータに署名し、それをピアツーピアネットワークを介して配布します
- 受信ノードは、受信した最初のバージョンに署名し、それを更新ノードに送り返します
- 更新ノードがすべてのノード（それ自体を含む）の2/3以上からの署名を取得すると、署名のコレクションを使用して、ピアツーピアネットワークを介してデータを再度配布します。
- 2/3からの署名によって検証されたこのバージョンを受信するすべてのノードは、データの最終バージョンを永続的に保存したことをまだ確認していないすべてのノードに（指数バックオフで）再送信し続けます。
そもそも更新の送信を許可されたノードは、データが二度と更新されないように失敗する可能性があります。ただし、一貫性のある更新を送信する限り、ピアツーピアネットワーク全体で一貫して保存されることになります。
すべてのデータに必要な多数の署名には、大量のストレージスペースが必要になるように聞こえるかもしれません。幸いなことに、これはしきい値署名と呼ばれる方法で回避できます。
ただし、データベースを置き換える場合は、1つのノードでデータを更新するだけでは不十分です。同じデータを更新できる複数のノードがありますが、ネットワーク全体で誰が最初であるかについて合意する必要があります。ここでビザンチン合意が浮かび上がります。
これに対する解決策は、私が上で説明したものよりも桁違いに複雑です。しかし、私は知っておくべきいくつかの重要な結果に言及することができます。
2つの障害モデルから選択する必要があります。障害が発生したノードは単に通信を停止し、破損したメッセージを1つも送信しないと想定できます。このモデルは必要なハードウェアが少なくて済みますが、システムをダウンさせるのに必要なビットは1つだけです。
または、ビザンチン障害モデルを選択することもできます。これにより、障害が発生したノードは何でも実行でき、システムは引き続き存続します。このモデルでtの失敗を許容するには、合計で3t+1ノードが必要です。つまり、単一の障害ノードを許容するには、4つのノードが必要です。合計10ノードの場合、3ノードの障害に耐えることができます。
また、同期または非同期の通信モデルを選択する必要があります。同期通信とは、通信のタイミングについて推測することを意味します。パケットが宛先に到達するのに想定よりも長い時間がかかる場合、システムは故障します。さらに、ノードがクラッシュした場合、システムを続行する前に、最大許容遅延を待つ必要があります。
非同期モデルはソフトウェア設計をより複雑にしますが、いくつかの明らかな利点があります。タイムアウトを待つ必要はありません。続行するには、ノードの2/3以上からの連絡が来るまで待つ必要があります。これは、大きなタイムアウトが必要な同期モデルよりもはるかに高速です。
非同期モデルのもう1つの欠点は、ランダム化する必要があることです。アルゴリズムの実行時間は、最悪の場合の限界のない確率変数になります。更新には無限の時間がかかるという理論上の可能性がありますが、その可能性はゼロであることが示されます。実際、通信のラウンドトリップの平均数は一定であることが示されています。私には、これは、通信が遅れた場合に故障する可能性がある同期モデルと比較して、はるかに有利に見えます。
ご想像のとおり、このようなシステムを正しく構築することは簡単な作業ではありません。これを実装するには、専用の開発努力が必要です。さらに、ソフトウェアのバグによってシステムがダウンする可能性があります。ノードの3分の1未満に障害が発生した場合、システムは存続します。ただし、ソフトウェアにバグが存在する場合は、そのバグのあるソフトウェアをノードの3分の1以上にインストールすることをお勧めします。
ここで考えられる問題がたくさんあります。
まず、提示されたとおりに管理するのが難しく、障害に耐えられない、検討のための2つの中途半端なソリューションが提供されました。
第二に、データサービスの構築方法について混乱しているようです。これはもっと心配です。
説明されている環境でのエンゲージメントの状況はわかりませんが、バックアップなしで（ライブまたはその他の方法で）多数のデータベースを実行するランダムボックスよりも、何もせず、より適切な要件を定義し、それらを達成するためのより良い計画を立てることをお勧めします。
あなたの懸念がラボの在庫である場合、これに対処するソフトウェアがそこにありますたくさん。ベンダー独自の奇妙な作業をしている場合は、ベンダーの環境要件を確立し、ある程度の保証を付けてこのデータにアクセスして保持する方法を見つけてください。私はそれが以前に行われたことを保証します。
このフォーラムに漠然とした質問を投稿するだけでは、これは起こりません。あなたが自分の深さから外れていると感じたら、あなたはあなたを助けるためにコンサルタントの時間を数時間得るべきです。
特定の環境では、データの単一の情報源が存在することが不可欠であるように思われます。本当？わかりません。
常に障害点があります-許容できるものを中心に設計する必要があります。
システムに関する制約を考え出す必要があります。単一のデータソースが必要ですか？デバイスはオフライン中にインベントリを使用できますか？単一サーバーの障害は許容できますか？システムは、しばらくの間、読み取り専用モードでの動作に耐えることができますか？
これらの制約があると、システム設計のhowが制約から生じることがわかります。