どのくらいのフェイルオーバー冗長性で十分ですか？
私は現在、すべてのクライアントが基本的に単一の西海岸のIPアドレスにトランザクションを送信して、いわゆる「ゲートウェイ」アプリケーションに到達するクライアントサーバーシステムに取り組んでいます。ゲートウェイはいくつかのアカウンティングを実行し、最終処理のために各トランザクションを複数のデータベースサーバーのいずれかにディスパッチします。サーバーは結果をクライアントに直接返します（ゲートウェイを介してバックアウトすることはありません）。
計画は、冗長性とフェイルオーバーのために、東海岸に2番目のゲートウェイを追加することです。通常はスタンバイ状態でのみ動作し、動作中のゲートウェイに障害が発生した場合に引き継いで実際のゲートウェイになるように設計されています。基本的には従来の構成です ここに示されています 。
一部の参加者は、スタンバイゲートウェイが1つしかないだけでは不十分であり、たとえば中西部に2つ目のスタンバイゲートウェイも実装する必要があると主張しています。他の人は、2つのスタンバイの追加コスト、複雑さ、および管理は不要であり、両方の海岸でゲートウェイが同時に利用できないことは問題にならない可能性が非常に低いと主張しています。
ベストプラクティスと見なされるものは何ですか？通常、（クライアントが利用できる物理的に分離されたアクセスポイントに関して）どの程度の冗長性が公称値と見なされますか？デュアル障害は、スタンバイが1つしかないことを後悔するほど一般的ですか？
編集：必要または必要な冗長性の量に対するコストと利益の「計算」に関して、質問を次のように言い換えた方がよいと思います。
地理的に離れたIPアドレスのコレクションに同時に到達できない頻度を示す統計はどこにありますか？
言い換えれば、次のようなテーブル
On average, 1 west coast IP + 1 east cost IP
are simultaneously unreachable 1 day/year.
On average, 1 west IP + 1 east IP + 1 southern IP
are simultaneously unreachable 1 hr/year.
On average, 1 west IP + 1 east IP + 1 southern IP + 1 northern IP
are simultaneously unreachable 1 minute/year.
etc.
コストとパフォーマンスを計算する実際の基準があるため、必要な冗長性の量を選択するのはかなり簡単です。 （「同時に到達不能」とは、「全国にランダムに散在するかなりの数のクライアントに対して」を意味する必要があると思います。これは、ローカルネットワークの障害が原因で、サーバーの数に関係なく、単一のクライアントがサーバーに到達できない可能性があるためです。）
ただし、このようなテーブルがないと、冗長性とパフォーマンスの計算は推測にすぎません。したがって：そのような計算の基礎となる実際の可用性データのソースはありますか？または、誰もが必要なものを推測して拡張しますか？必要に応じて、彼らが低いと推測したことがわかったら、または高いと推測した場合は削減しますか？
フォールトトレラント製品を提供している企業は、そのようなデータを収集して宣伝したいと思うようです。一方、データは、フォールトトレラントな顧客の99.99％が実際にはそれほど冗長性を必要としないことを示している可能性があります。たとえば、1年間行くことができ、東と西のIPアドレスに同時に到達できない場合は、中西部のIPを追加することを検討するつもりはありません。
また、サイトの外部の力が原因でIPアドレスに到達できないことと、サイトが内部で障害が発生したためにIPアドレスがダウンしていることには違いがあることも認識しています。 （IPアドレスの私の側の）内部障害は比較的簡単に対処できます。外部障害（地震のためにカリフォルニアがオフラインになったり、ハリケーン中にニューヨークがオフラインになったりするなど、IPアドレスのクライアント側で）他の地理的な場所に追加のIPアドレスを設定することによってのみ対処できます。 それは私が定量化したいと思っている確率です。今のところ、私は東と西のIPアドレスが同時に到達できない可能性が小さすぎて心配できないと主張するキャンプに傾いています。
最初のWebサーバーは1995年にCentrex接続でX市で始まり、1998年にISDNに変換され、2001年にDSLに変換され、バックアップのために数マイル離れたY市で2番目の静的アドレスも開始されました。 2つの異なるISPを使用していましたが、基盤となるネットワークはすべてPacBellでしたが、現在はATTです。私たちの都市X施設は2003年に空になり、都市Yだけがサーバーを実行していました。2009年に都市Zで別の静的アドレスを開始し、再び都市Yからわずか数マイルで、YとZの両方が同じISPを使用しています。
それらすべての年において、私たちのIPアドレスは、私たちが知る限り、（あなたが言うように）「外部的に」到達不能になることは決してありませんでした。どうやらPacBell/ATTと私たちのISPは常に十分な冗長性を持っていたので、少なくとも私たちのパケットを常に配信することができました。 「内部的に」私たちが抱えていた唯一の問題は、マシンの障害ではなく、電源障害でした。このようなインシデントの際に、2つの場所間でDNSポインターを一時的に切り替えるだけで（数日間、おそらく2年に1回）、私たちの目的。
西海岸のIPと東海岸のIPを取得した場合、クライアント（グループとして）がこれらのアドレスに同時に到達できないことはおそらくないだろうと私は予測しています。両方の場所に到達できない場合（つまり、パケットをそこに送信することさえできない場合）、Armageddonが到着した可能性があり、とにかく大きな問題が発生します。いずれかのサイトで内部障害が発生した場合に、できるだけ早くバックアップするためのポリシーと手順が整っている（そしてテストされている）ことを確認してください。状況によって本当に必要であることが証明されるまで、3番目の中西部IPを取得することを心配しないでください。
@ HopelessN00bが言ったこと。生のコスト VS メリットを自分で比較検討する必要があります。
- 一部のお客様は、ダウンタイム中にトラフィックがまったく発生しないため、コストを節約するために、文字通り特定の期間コンピューターの電源をオフにします。
- 一部のお客様は、別のデータセンターにフェイルオーバーインスタンスを備えた負荷分散クラスターに加えて、監視として機能する別のデータセンターに3番目のネットワークを備え、例外なく24時間365日稼働する100％のプロバイダーからの保証が必要になります。
あなたは計算する必要があります：
- 1日のうち何時間オンラインである必要がありますか？
- X時間/分オフラインの場合、どのくらいの$$$が失われますか？
- 1時間あたり250ドルしか失っておらず、1か月あたり5時間のダウンタイムしかないと予想される場合、DRにさらに1か月あたり5000ドルを費やす価値はありますか？ （99.9926％の可用性）
- など
これに関するベストプラクティスはありません。
地理的に離れたIPアドレスのコレクションに同時に到達できない頻度を示す統計はどこにありますか？
これも状況によります。たとえば、[〜＃〜] ups [〜＃〜]を持たない顧客、または独自のGeneratorを持たない顧客の統計について話しているのでしょうか。または別々の変電所から来る2つの独立した電力線でさえ？
それも方程式に含まれます。完全な停電が長すぎてUPSのジュースがなくなったため、当社は停電に見舞われました。
データセンター全体でX時間持続する発電機の購入を進めました。これは、緊急時に燃料のドロップオフを介して再充電できるため、ローカルサブシステムが完全にノックアウトされた場合でも、ほぼ継続できます。無期限に。
おそらくデータは、フォールトトレラントな顧客の99.99％が実際には多くの冗長性をまったく必要としないことを示しています。
完全に。
重要な（$$$）システムを単一のサーバー、単一の場所で実行している顧客がいますが、サーバーは1つの機能を実行するだけなので、堅固です。合併症が少ないほど良いです。
これは、DRソリューションを追加した後、これまで以上に多くの停止が発生するという古い皮肉な状況です。
すでに述べたように、ここでは技術レベルでの一般的なベストプラクティスはありませんが、実行しないの明白なリストを除きます。
クライアントと明示的に持っている、または業界で想定されている可能性のあるSLAから多くの情報が得られます。最も例外的な状況を除いて、それをサポートできることを確認し、必要な報酬を支払う必要があります。最も例外的な状況が発生した場合に作成します。たとえば、一部のクライアントでは、24時間の損失が「許容可能」である4時間の回復ウィンドウがあります（これは非常に簡単に保証できます）。はるかにリアルタイムな別のプロジェクトの場合、これらのタイミングは10分と30分です。そして私はそれよりもはるかに厳しい期待を持っているミッションクリティカルおよび/または安全サービスを想像することができます。
私が考えることができる唯一の一般的なアドバイスは、特定のポイントに時間とお金を費やす前に、すべての基本を特定のレベルまでカバーしていることを確認することです。地球上で最も冗長なフェイルセーフデータベースレイヤーを使用しても、Webファームへの1つのパブリックリンクが機能しなくなっても役に立ちません。したがって、他の当事者を犠牲にして、システムの一方の当事者を過度に保護しないようにしてください。