アプリケーションの24時間365日の可用性を実現するにはどうすればよいですか？
私はインタビューでこの質問をされました：
私はSQLサーバーとasp.netアプリケーションを持っています。サーバーがクラッシュした場合でも、アプリケーションを24時間年中無休で利用できるようにしたい。
コードレベルとより高いレベル（コードレベルではないことを意味します）でそれを達成するためのさまざまな方法は何ですか？
最終的にそれはお金に要約されます。神話上の「ファイブナイン」の「ナイン」ごとにコストがかかり（99.999％の可用性、年間5分のダウンタイム）、そのコストはかなり高い。 99.999％の可用性システムのコストは数百万ドルであり、ハードウェア、ソフトウェアライセンス、高度なトレーニングを受けた専任のスペシャリスト担当者、トレーニング、手順などをカバーする必要があります。システムの更新（OSとベンダーのパッチ）、アプリケーションのアップグレード、データベースのインデックスの再作成などのさまざまなメンテナンス手順などを考慮する必要があります。
しかし、非常に大まかな答えについては、 高可用性ソリューションの概要 ：に向けて指摘します。
フェールオーバークラスタリングは、SQLServerのインスタンス全体に高可用性サポートを提供します。フェールオーバークラスターは、1つ以上のノードまたはサーバーと2つ以上の共有ディスクの組み合わせです。アプリケーションはそれぞれ、リソースグループと呼ばれるMicrosoft Cluster Service（MSCS）クラスターグループにインストールされます。いつでも、各リソースグループは、クラスター内の1つのノードのみが所有します。アプリケーションサービスには、ノード名から独立した仮想名があり、フェールオーバークラスターインスタンス名と呼ばれます。アプリケーションは、フェールオーバークラスターインスタンス名を参照することにより、フェールオーバークラスターインスタンスに接続できます。アプリケーションは、どのノードがフェールオーバークラスターインスタンスをホストしているかを知る必要はありません。
データベースミラーリングは、主に、ほぼ瞬時のフェイルオーバーをサポートすることでデータベースの可用性を向上させるソフトウェアソリューションです。データベースミラーリングを使用して、プリンシパルデータベースと呼ばれる対応する本番データベースの単一のスタンバイデータベースまたはミラーデータベースを維持できます。
データベースミラーリングと同様に、ログ配布はデータベースレベルで動作します。ログ配布を使用して、プライマリデータベースと呼ばれる対応する本番データベースの1つ以上のウォームスタンバイデータベースを維持できます。スタンバイデータベースは、セカンダリデータベースとも呼ばれます。各セカンダリデータベースは、プライマリデータベースのデータベースバックアップをリカバリなしまたはスタンバイで復元することによって作成されます。スタンバイを使用して復元すると、結果のセカンダリデータベースを使用して限定的なレポートを作成できます。
レプリケーションはパブリッシュ/サブスクライブモデルを使用します。これにより、パブリッシャーと呼ばれるプライマリサーバーが1つ以上のセカンダリサーバーまたはサブスクライバーにデータを配布できます。レプリケーションにより、これらのサーバー間でリアルタイムの可用性とスケーラビリティが実現します。サブスクライバーでデータのサブセットを提供するためのフィルタリングをサポートし、パーティション化された更新も可能にします。サブスクライバーはオンラインであり、クエリを回復することなく、レポートやその他の機能を利用できます。 SQL Serverは、スナップショット、トランザクション、およびマージの3種類のレプリケーションを提供します。トランザクションレプリケーションは最小のレイテンシーを提供し、通常は高可用性のために使用されます。
ここにいる多くの人が面接の質問に答えて、それをブラフするのに役立つとは思いません。それはあなたが意図したことではないと確信しているので、ここに2つの学習オプションがあります。
Googleの「高可用性asp.net」。 （「高可用性」はあなたが探している用語です）
コードレベルでは、できることはあまりありません。サーバーがクラッシュすると、サーバーがクラッシュします。ハードウェアに関しては、おそらく フェイルオーバークラスタリング のようなフレーズを探していました。
複数のサーバーが必要ですが、これは一部の人にとっては実現不可能であり、必要ない場合もあります。ただし、ほぼ100％の稼働時間を達成することが重要な場合は、サーバーレベルで フェールオーバークラスタリング と呼ばれるものがあります。これは、サーバーがさまざまな理由でクラッシュすると、他のサーバーの1つが「ステップイン」して引き継ぎます。
フォールトトレランス（FT）または他の仮想化製品と同等のVMwarevSphere。このソリューションは2台のサーバーに限定されません（1台は失敗し、もう1台は負荷をかけます）が、多くのサーバーに分散させることができます。それはあなたがいくら使いたいかという問題だけです。
これは完全にOSに依存しません。つまり、アプリケーションをWindows Serverで実行し、データベースをLinuxRedHatで実行することができます。その逆も可能です。
Asp.netアプリケーションとデータベースを2つの別々のサーバーでホストし、両方のサーバーにホットフォールオーバーオプションを使用すると、復元力が向上します。上記で提案したフォールオーバーclustringがこれを提供します。ただし、データベースサーバーがダウンした場合、トランザクションがキューに入れられ、データベースが復元されたときに、トランザクションがFIFOの方法でコミットされるかどうかについても考慮する必要があります。
一般的にそれを拡張することは私がその質問に答える方法ですが、コードレベルでそれを完全に行うことは不可能であるという@CXFXに同意します。
実際のビジネスでは、私は次のことを検討します。
- ここにSQLServerのログとデータファイルを置きます
- 仮想化オプション
しかし、Stackoverflowの場合はそうではありません。
データセンター、プラットフォーム、およびアプリケーションレベルで高可用性を実際に習得するには、実際の学習が多く必要になるため、簡単な答えではありません。大まかに言えば、ここで考慮すべきことがいくつかあります。
サーバーのクラッシュとパッチ適用に耐えるには、サイトレベルでの負荷分散、ある種のSQL HAソリューション、および単一のサーバーにロックされていないアプリケーションが必要です。
サイトレベルでは、それ自体が冗長なサードパーティのロードバランサーが多数あります。または、MicrosoftのApplication Request Routing（ARR）ソリューションも優れたオプションです。
SQL Serverの場合、組み込みのクラスタリング、ミラーリング、またはログ配布オプションが適切であることが多く、DoubleTakeなどの製品はこのニーズを満たすのに最適です。
アプリケーションレベルでは、単一のノードに依存するものがないことを確認する必要があります。セッション状態は最も一般的な依存関係です。使用する場合は、冗長ソリューションにオフロードする必要があります。 SQLServerセッション状態、ScaleOutSoftware、そして現在はAppFabricがすべて考慮すべきオプションです。
真の冗長性は、データセンター全体で地理的に冗長である必要があります。データセンターは、大規模な自然災害の影響を受けないように十分に離れている必要があります。
また、予期しない状況を可能な限りスムーズに処理する方法を知り、システムのさまざまな冗長部分を定期的にテストするには、多くのテストと優れたプロセスと手順がなければ、テクノロジーは十分ではありません。