シナリオ: Team Foundation Server ファームのインストール (高可用性)
.png "Team Foundation Server の追加")
次のいずれかの理由で、Visual Studio Team Foundation Server の既存の配置にアプリケーション層サーバーを追加する場合があります。
Team Foundation Server の配置に冗長性を持たせるため。
Team Foundation Server の配置によって実行速度を向上するため。
障害が発生したアプリケーション層サーバーを復元するため。
アプリケーション層を異なるサーバーに移動するため。
冗長性とパフォーマンス
Team Foundation Server の旧バージョンでは、SQL Server クラスター上で実行できるのはデータ層だけでした。 この制限のために、Team Foundation Server の配置のうち、データ層の部分しかスケーラビリティを強化できませんでした。 アプリケーション層のみウィザードを使用すると、アプリケーション層についても、可用性、スケーラビリティ、およびパフォーマンスを強化できるようになります。
複数のアプリケーション層サーバーの利点を活用するには、Team Foundation Server の初期配置が次の特性を備えていることを確認する必要があります。
アプリケーション層と構成データベースが、別々のサーバーにインストールされている。
Team Foundation Server サービス アカウント (TFSSERVICE) にドメイン アカウントを使用している。
ネットワーク負荷分散 (NLB) が配置されている。
NLB は、単一の論理 Web サービスとして表される Web サーバーのクラスターを作成するために使用します。 これは、アプリケーション層のみウィザードとは別の手順です。 NLB のセットアップ方法の詳細については、Microsoft Web サイトの「ネットワーク負荷分散」を参照してください。
注意
クラスター内のアプリケーション層サーバーのいずれかで実行しているクライアントから NLB クラスターに接続する場合は、サーバーの名前として負荷分散機能の DNS (Domain Name System) の名前ではなく、ローカルホストを使用して接続する必要があります。 既定では、クラスターの名前としてローカルホストを使用しない限り、インターネット インフォメーション サービス (IIS) によって、クラスター内の任意のサーバーから NLB クラスターへの接続が阻止されます。
NLB クラスターを作成する場合、構成データベースやチーム プロジェクト コレクションのために SQL Server クラスターを使用する必要はありません。 パフォーマンス、スケーラビリティ、および可用性の目的から、配置する SQL Server クラスターは、NLB クラスターに依存しません。
障害回復とハードウェア アップグレード
構成データベースのバックアップがあり、アプリケーション層にハードウェア障害が発生した場合は、アプリケーション層のみウィザードを使用してアプリケーション層を復元できます。
アプリケーション層のみウィザードでは、アプリケーション層を移動することもできます。 アプリケーション層の移動に特定のアーキテクチャが必要となることはありませんが、配置のためには構成データベースへのアクセス許可が必要です。