私は所有して運営しています visualwebsiteoptimizer.com /。このアプリは、顧客が特定の指標を追跡するためにWebサイトに挿入するコードスニペットを提供します。コードスニペットは外部JavaScript(サイトコードの上部)であるため、顧客のWebサイトを表示する前に、訪問者のブラウザーがアプリサーバーに接続します。アプリサーバーがダウンした場合、ブラウザはタイムアウトする前に接続の確立を試み続けます(通常は60秒)。ご想像のとおり、どのようなシナリオでもアプリサーバーを停止する余裕はありません。これは、ウェブサイトの訪問者だけでなく、お客様のウェブサイトの訪問者のエクスペリエンスにも悪影響を与えるためです。
現在、別のデータセンター(実際には別の大陸)にある1つのバックアップサーバーでDNSフェイルオーバーメカニズムを使用しています。つまり、3つの別々の場所からアプリサーバーを監視し、ダウンが検出されるとすぐに、バックアップサーバーのIPを指すようにAレコードを変更します。これはほとんどのブラウザで正常に機能しますが(TTLは2分))、IEはDNSを30分間キャッシュするため、取引が殺される可能性があります。最近の記事を参照してください。私たちの投稿 visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/
では、アプリのデータセンターが大規模な停止に見舞われた場合に、ほぼ瞬時にフェイルオーバーを実現するには、どのような設定を使用できますか?私はここを読みました www.tenereillo.com/GSLBPageOfShame.htm 複数のAレコードを持つことは解決策ですが、セッションの同期を行う余裕はありません(まだ)。私たちが検討しているもう1つの戦略は、2つのAレコードを用意することです。1つはアプリサーバーを指し、もう1つはリバースプロキシ(別のデータセンターにあります)を指します。リバースプロキシは、稼働中の場合はメインアプリサーバーに、稼働中の場合はバックアップサーバーに解決されます。この戦略は合理的だと思いますか?
優先順位を確認するために、独自のWebサイトまたはアプリを停止する余裕はありますが、ダウンタイムのために顧客のWebサイトの速度を低下させることはできません。そのため、アプリサーバーがダウンした場合、デフォルトのアプリケーション応答で応答するつもりはありません。空白の応答でも十分ですが、ブラウザがそのHTTP接続を完了する必要があります(他には何もありません)。
参照:私は有用だったこのスレッドを読みました serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure
あなたの状況は私たちの状況とかなり似ています。分割データセンターとネットワーク層タイプのフェイルオーバーが必要です。
それを行うための予算がある場合、必要なのは、2つのデータセンター、それぞれへの複数のIPトランジット、トランジットプロバイダーへのBGPセッションを実行し、IPアドレスをグローバルインターネットにアドバタイズするエッジルーターのペアです。
これが真のフェイルオーバーを行う唯一の方法です。サーバーへのルートが無効になったことをルーターが認識すると(さまざまな方法で実行できます)、ルーターはそのルートのアドバタイズを停止し、トラフィックは他のサイトに移動します。
問題は、エッジルーターのペアの場合、これを設定するために最初はかなり高いコストを検討していることです。
次に、これらすべての背後にあるネットワークを設定する必要があります。トラフィックをルーティングできるように、サイト間のある種のレイヤー2接続をポイントツーポイントリンクと見なすことができます。プライマリサイトに部分的な障害が発生した場合は、一方のデータセンターに直接着信します。
BGPマルチホーム/マルチロケーションのベストプラクティス および 復元力を向上させるための最良の方法? は、同様の問題について私が尋ねた質問です。
恥のGSLBページはいくつかの重要なポイントを提起します。そのため、個人的には、BGPルーティングの仕事をするためにGSLBを積極的に選択することは決してありません。
また、ネットワーク内の他の障害点も確認する必要があります。すべてのサーバーに2つのNIC(2つの別々のスイッチに接続)と2つのPSUがあり、サービスが冗長ペアまたは負荷分散クラスターとして複数のバックエンドサーバーで構成されていることを確認してください。
基本的に、DNSサーバーには各サーバーにかかる負荷の概念がないため、複数のAレコードを介したDNSの「負荷分散」は単なる「負荷分散」です。これは安い(無料)。
GSLBサービスには、サーバーの負荷とその可用性に関する概念があり、障害に対する耐性が高くなっていますが、DNSキャッシングとペギングに関連する問題に悩まされています。これはそれほど安くはありませんが、少し良くなります。
強固なインフラストラクチャに裏打ちされたBGPルーティングネットワークはIMHOであり、良好な稼働時間を真に保証する唯一の方法です。 Cisco/Juniper/etcルーターの代わりにルートサーバーを使用することでいくらかのお金を節約できますが、結局のところ、これらのサーバーを非常に注意深く管理する必要があります。これは決して安価なオプションではなく、簡単に実行できるものでもありませんが、非常にやりがいのあるソリューションであり、単なる消費者ではなく、プロバイダーとしてインターネットにアクセスできます。
OK、これは少し前に尋ねられましたが、私は今それを最初に見ています。
コードスニペットは外部JavaScript(サイトコードの上部)であり、顧客のWebサイトを表示する前に、訪問者のブラウザーがアプリサーバーに接続します。
あなたがすべき:
他のことをするのは本当に無責任です。私はあなたがすでにこれを実施していると思います。
ノウハウを持っているか取得していない限り、BGPルーティングのトリックに基づいてサービスをしないでください。複雑なBGPルーティングシナリオを実装するのは明らかに簡単ではありません。ドメイン固有の知識がない場合は、自分でこれを行わないでください。
あなたの質問自体は少し混乱しています。高可用性サービスを作成する方法の分析は、アプリケーションデータから始まります。これが「状態」だからです。ステートレスパーツは高可用性を実現するのは簡単ですが、ステートフルパーツはそうではありません。したがって、サーバーとDNSに焦点を合わせる代わりに、アプリケーションが状態を維持する場所を調べてください。そこで最適化することから始め、場合によってはStackOverflowに関するアルゴリズムのアドバイスを求めます。トランザクションとスマートサーバーの再試行の概念をJavascriptファイルfxに実装できますか?
実際、geodnsとdnsフェイルオーバーを組み合わせると、分割テストアクティビティにも役立つようにアップグレードすることができます。
グループAをip1に、グループBをip 2に送信すると、それらが同じサーバー上にある場合でも、テストグループを分離できます。グループAとグループBは異なる地理的地域から来ています。公平を期すために、次の日/週/月に、グループを反転して、地理的な違いを考慮に入れていることを確認します。方法論を厳密にするためだけに。
http://edgedirector.com のgeodns/failoverdnsサービスでこれを実行できます
開示:私は上記のリンクに関連付けられており、ここで愚かなDNSトリックを分割テストに適用することに関する記事を調査していることに遭遇しました。