一般的な展開

  • [アーティクル]

Windows Server AppFabric サーバーの展開トポロジの要件は、ビジネス ニーズと、ホスティングするアプリケーションの要件に、大きく依存します。典型的な展開を 1 つだけ考えて、それに対する規範的なガイドラインを示すことは困難ですが、ここでは、環境に AppFabric を展開するためのガイダンスと推奨事項について説明します。

展開に関するトピックは次のとおりです。

  • 単一サーバーへの AppFabric の展開

  • サーバー ファームへの AppFabric の展開

  • AppFabric キャッシュ機能の展開のセキュリティに関する考慮事項

  • AppFabric キャッシュ機能の展開シナリオ

単一サーバーへの AppFabric の展開

単一サーバーの展開は、単一のコンピューターに AppFabric をインストールするときに使用します。この展開がよく使用されるのは、すべてのアプリケーション開発作業を 1 台のコンピューターで行う開発環境です。

SQL Server

開発環境ではスケールアウトを考える必要はないので、AppFabric のこの展開は、監視および永続化データベース用の SQL Server Express のローカル インストールを使用するように構成できます。

アプリケーション展開

アプリケーション展開は、アプリケーションをパッケージ化し、MSDeploy を使用して AppFabric に展開することで実現できますが、それよりも可能性が高いのは、開発者が、アプリケーションをホスティングする手段として、IIS を実行するローカル サーバーを直接使用するようにプロジェクトを構成する方法です。この方法では、テスト環境でアプリケーションをホスティングするための手順が最も少なくて済みます。ただし、ステージング環境または運用環境に移行する前に、開発者はアプリケーションのパッケージングと展開をテストし、パッケージ化したアプリケーションを正常に展開できることを確認することをお勧めします。

アプリケーションの展開の詳細については、「アプリケーションを展開する」を参照してください。

サーバー ファームへの AppFabric の展開

開発環境の場合は AppFabric と SQL Server の両方を 1 台のコンピューターにインストールしても十分ですが、運用環境は、通常、サーバー ファームの複数のコンピューターと、1 台または複数の SQL Server 専用サーバーで構成されます。このような環境では、ロード バランサーとキューを使用してアプリケーション宛ての着信メッセージを管理し、高可用性のために SQL Server のクラスタリングを使用することもあります。

AppFabric の小規模の展開は単一のコンピューターにインストールした AppFabric で開始できますが、アプリケーションが複数のサーバーに展開されて高度に分散化したアプリケーションを構成するサーバー ファームに拡大する可能性があります。スケールアウトを使用すると、負荷分散ソリューションを実装でき、着信メッセージの処理を複数のサーバーに分散させたり、永続化を使用するワークフローのために強化されたフォールト トレランスを提供したりできます。

SQL Server のクラスタリング

ここでは詳しく説明しませんが、フェールオーバー保護のためにデータベースをクラスター化することを強くお勧めします。SQL Server フェールオーバー クラスタリングの詳細については、「災害時の復旧計画」 (https://go.microsoft.com/fwlink/?LinkId=131016) を参照してください。

永続アプリケーション スケールアウト

長時間実行されるプロセスを扱うときは、システムの再起動、ハードウェア障害、またはその他の予期しないサーバー停止などが発生してもアプリケーションが動作し続けられるようにすることが不可欠です。AppFabric では、ワークフロー アプリケーションが利用できる既定の永続化プロバイダーが用意されており、長時間実行されるアプリケーションを永続化できます。

単一サーバーの展開では、ワークフロー インスタンスは永続化を利用することで、ホスティングされているサーバーが正常な状態に戻ったときに、実行を再開できます。一方、サーバー ファームの展開では、アプリケーションはサーバー ファーム内の使用可能な任意のコンピューターで再開できます。さらに、ワークフロー インスタンスが 1 つのサーバーで実行していて、そのインスタンス宛てのメッセージが別のサーバーに到着した場合、永続化は、保留されているメッセージのあるコンピューターに既存のインスタンスを移動して、ワークフローがメッセージを処理できるようにします。

詳細については、「ワークフロー永続化を構成する」を参照してください。

データの分離

AppFabric の既定の構成では、永続化情報と監視情報の両方が 1 つのデータベースに格納されます。開発環境の場合はこれで十分ですが、運用環境では、通常、データ ストレージ用にさらに堅牢なリソースのセットが必要です。AppFabric では、複数の異なる永続化および監視データベースを作成し、SQL Server を実行する複数のコンピューターへのデータの分離をサポートできます。

AppFabric では複数のデータベースを作成できるので、機能別 (永続化と監視) だけでなくアプリケーション別にもデータを分けることができます。堅牢なデータ ストレージの要件を持つアプリケーションがある場合は、このアプリケーションまたはサービスのみに特に関連付けられた永続化データベースおよび監視データベースを作成できます。

追加データベースの作成の詳細については、「データベース管理」を参照してください。

アプリケーション展開

複数のコンピューターにアプリケーションを展開するときは、展開を一貫性のある再現可能な方法で実現できることが重要です。そのために、AppFabric は、MSDeploy を使用して、Web アプリケーション、Web サイト、または Web サーバーの内容と構成をパッケージ化して展開します。また、MSDeploy を使用すると、Web サイトまたは Web サーバーと、サーバー ファーム内のローカル コンピューターまたはリモート コンピューターの間でデータを同期できます。

アプリケーションの展開の詳細については、「アプリケーションを展開する」を参照してください。MSDeploy の詳細については、「Web 配置ツール」 (https://go.microsoft.com/fwlink/?LinkId=151481) を参照してください。

AppFabric キャッシュ機能の展開のセキュリティに関する考慮事項

AppFabric の分散キャッシュ システムは、ファイアウォールの境界の内部にあるデータセンターで動作するように設計されています。ここで説明するサーバーは、キャッシュ構成の保存場所、キャッシュ サーバー、キャッシュが有効なアプリケーション サーバー、開発サーバー、およびプライマリ データ ソース サーバーを、ホスティングしているサーバーです。すべてのサーバーは、同じドメインに併置されている必要があります。

キャッシュされるデータおよびキャッシュ サーバー間の TCP/IP 通信は暗号化されないので、分散キャッシュ システムは、ネットワーク トラフィックを記録または変更する悪意ある攻撃者の攻撃を受けやすくなります。

ヒント

AppFabric キャッシュ クライアントは、アプリケーション エコシステムのアプリケーション層に存在するようになっています。組織のドメインの内部または外部にいるエンド ユーザーが、キャッシュ サーバーに直接ネットワーク アクセスできてはなりません。

キャッシュ サーバーを廃棄するとき、AppFabric インストール プログラムはすべてのファイアウォール ポート例外を削除できません。AppFabric をアンインストールした後、標準のファイアウォール構成を再適用することをお勧めします。

AppFabric キャッシュ機能の展開シナリオ

展開オプションの説明を簡素化するため、ここでは 3 つの異なる例に注目します。

  • 開発者展開。 キャッシュが有効なアプリケーションを開発するために使用される単一コンピューターの展開。

  • 中規模展開。 リード ホストがクラスター管理の役割を実行する、SQL Server を使用しない複数コンピューターのインストール。

  • エンタープライズ展開。 クラスター構成設定の格納とクラスター管理の役割の実行に SQL Server を使用する、複数コンピューターのインストール。

次の表は、AppFabric キャッシュ機能がインストールされる場所と、クラスター管理の役割の実行方法をまとめたものです。

AppFabric のキャッシュ機能 開発者展開 中規模展開 エンタープライズ展開

キャッシュ クラスター構成の保存場所

開発者ワークステーション上のローカルな共有フォルダー

ファイル サーバー上の共有ネットワーク フォルダー

SQL Server データベース

キャッシュ サーバーのインストール (キャッシュ ホスト Windows サービスと Windows PowerShell 管理ツール)

開発者のワークステーション

1 台以上のキャッシュ サーバー (フォルダーの最大同時接続によって制限されます)

1 台以上のキャッシュ サーバー

キャッシュ クライアント アセンブリ

開発者のワークステーション

1 台以上のアプリケーション サーバー

1 台以上のアプリケーション サーバー

キャッシュ クラスターの構成設定は、共有ネットワーク フォルダーまたは SQL Server データベースに格納できます。これらの各オプションの詳細については、「クラスター構成の保存オプション (Windows Server AppFabric キャッシュ)」を参照してください。

クラスター管理の役割は、リード ホストまたは SQL Server で実行できます。キャッシュ クラスターの可用性の観点からは、SQL Server を使用するのが最善のオプションです。詳細については、「リード ホストとクラスター管理 (Windows Server AppFabric キャッシュ)」を参照してください。

開発者展開

開発者展開では、キャッシュ クラスター自体を含むキャッシュが有効なアプリケーションを作成するために必要なすべてのコンポーネントが、開発者のワークステーションに格納されます。AppFabric のキャッシュ機能を初めて使うときは、この展開が最も便利なオプションです。

中規模展開

中規模展開では、アプリケーションは分散キャッシュ クラスターのメリットを提供できます。アプリケーション層の増大する要求を満たすために、アプリケーションを簡単に拡張できます。

この展開シナリオではクラスター構成設定の格納に SQL Server を使用しないため、いくつかの欠点があります。一部のオペレーティング システムでは、サポートできる共有フォルダーへの同時接続の数に制限があるため、分散キャッシュ クラスター内に作成できるキャッシュ ホストの最大数に直接影響します。Windows XP、Windows Server 2003、および 32 ビット版の Windows Vista では、共有ネットワーク フォルダーに対して可能な同時接続は 10 以下です。大規模なクラスターのキャッシュ構成設定の格納には、これらのオペレーティング システムを使用しないことをお勧めします。

キャッシュ サーバーの並列インストールの実行を自動化したり、それ以外で試みたりすると、クラスター構成ファイルで競合が発生する可能性があります。このシナリオで最も信頼性の高いキャッシュ サーバー インストール方法は、一度に 1 つのキャッシュ サーバーのインストールを実行することです。

このシナリオでは SQL Server を使用しないので、SQL Server を入手してインストールし、アプリケーション用のクラスター構成データベースを作成する必要はありません。時間と費用に関しては、既にアプリケーションで使用できるものにより、コストの節約になる場合と、ならない場合があります。共有フォルダーのクラスター構成ストレージ オプションを使用するときは、キャッシュ クラスター内のすべてのキャッシュ サーバーが共有ネットワーク フォルダーに常にネットワーク接続している必要があります。

SQL Server がない場合は、リード ホストのみがクラスター管理の役割を実行できます。キャッシュ クラスターが使用できるためには、大部分のリード ホストが常に動作している必要があるので、このシナリオのキャッシュ クラスターはサーバーの障害に対して他より脆弱です。また、このシナリオでは、アプリケーションの可用性に関してサーバーの保守が複雑になります。詳細については、「リード ホストとクラスター管理 (Windows Server AppFabric キャッシュ)」を参照してください。

エンタープライズ展開

他の展開シナリオと比較して、エンタープライズ展開は最善の可用性とサポート性を提供します。SQL Server データベースが必要であり、これは一部のアプリケーションではオプションでない場合があります。

SQL Server がクラスター管理の役割を実行するとき、クラスター内の 1 つを除くすべてのキャッシュ サーバーが失われてもクラスターに影響はなく、動作し続けます。共有フォルダーのクラスター構成ストレージ オプションを使用するときと同様に、キャッシュ サーバーは SQL Server データベースに常にネットワーク接続している必要があります。

ヒント

キャッシュ サーバーを停止すると常に、そのサーバーがクラスター管理の役割を実行していたかどうかに関係なく、そのサーバーのメモリに格納されていたデータは失われます。高可用性機能が有効になっている名前付きキャッシュの場合、失われたデータのコピーがクラスター内の他のサーバーに残っており、セカンダリ サーバーにすばやくコピーされます。詳細については、「高可用性 (Windows Server AppFabric キャッシング)」を参照してください。

このシナリオのキャッシュ サーバーはいずれもクラスター管理の役割を実行していないので、高可用性アプリケーションのサーバー保守は格段に簡素化されます。サーバーを再起動するときの複雑な順序設定は必要ありません。詳細については、「リード ホストとクラスター管理 (Windows Server AppFabric キャッシュ)」を参照してください。

SQL Server の使用は、同時接続が必要な状況で好都合です。これにより、キャッシュ サーバーの自動化された並列インストールは、中規模展開の場合のようなクラスター サイズの制限なしで円滑に行われます。詳細については、「.NET 4 向け Application Server Extensions のインストール」 (https://go.microsoft.com/fwlink/?LinkId=169172) を参照してください。

関連項目

概念

アーキテクチャの概要
クラスター構成の保存オプション (Windows Server AppFabric キャッシュ)
共有フォルダー ベースのクラスター構成 (Windows Server AppFabric キャッシュ)
SQL Server ベースのクラスター構成 (Windows Server AppFabric キャッシュ)
Windows PowerShell を使用した Windows Server AppFabric キャッシュ機能の管理
リード ホストとクラスター管理 (Windows Server AppFabric キャッシュ)

  2011-12-05