AppFabric 環境の障害回復に関する考慮事項
Windows Server AppFabric をインストールしても、障害回復の計画方法に変わりはありません。 AppFabric インストールの計画と復元は主に、これから説明する Windows、インターネット インフォメーション サービス (IIS)、および SQL Server の通常の障害回復に基づいています。 これら 3 つの製品を使用して、以下の AppFabric 項目をバックアップする必要があります。
構成設定と構成ファイル
イベント コレクション、ワークフロー管理、キャッシュ サービスなどの Windows サービス設定
AppFabric 固有ユーザー グループへの変更に関する Windows のセキュリティ設定
レジストリ設定
Web アプリケーション ファイル
AppFabric で使用されるデータベース
SQL Server データベース
監視データベースと永続化データベース、および (AppFabric キャッシュを使用している場合は) キャッシュ構成データベースのバックアップと復元には通常の SQL プロシージャを使用します。 SQL Server バックアップを作成する目的は、破損したデータベースを復旧できるようにすることです。 ただし、データのバックアップと復元は、特定の環境向けにカスタマイズし、使用可能なリソースと連動させる必要があります。 したがって、信頼性が確保された状態でバックアップと復元を使用して復旧するには、バックアップと復元のストラテジが必要です。 バックアップと復元のストラテジ設計が適切であれば、特定のビジネス要件を考慮しながら、データの可用性を最大にし、データ損失を最小限に抑えることができます。
Windows Server AppFabric はアプリケーションの状態データを生成します。 ワークフロー永続化はワークフロー サービス インスタンスの状態を格納します。 ワークフローを実行しているコンピューターがクラッシュした場合は、サービスを実行している別のコンピューターが最後の永続化ポイントからワークフロー インスタンスを再開できます。 永続化データはワークフロー アプリケーションに不可欠であり、リアルタイムで利用できることを保証する必要があります。 ワークフローの永続化に SQL Server インスタンス ストア プロバイダーを使用するときは、SQL Server の高可用性機能のいずれかを使用する必要があります。 このような機能としては、フェールオーバー クラスタリング、データベース ミラーリング、トランザクション レプリケーション、ログ配布などがあります。 ワークフロー サービスが別のアプリケーション データベースに書き込む場合は、別の永続化データベースの代わりに、既存のデータベースに永続化スキーマを追加できます。 これにより、障害の後でデータを復元するときに、データ整合性を簡単に強制できます。
場合によっては、分散キャッシュを設定するデータが、データベースなどのバックアップできるソースから取得されることがあります。 または、たとえば ASP.NET セッション状態の格納にキャッシュを使用するようなときは、データは恒久的な記憶域に書き込まれません。 キャッシュには、キャッシュされるデータの各部分が少なくとも 2 つのホストに書き込まれることを保証する高可用性モードが用意されています。 1 台のコンピューターがクラッシュした場合、アプリケーションは他のコンピューター上のキャッシュからのデータを引き続き使用できます。
Windows Server AppFabric 監視データベースには、ある期間に WCF および WF ランタイムによって生成されたイベントが格納されます。 このデータを使用すると、サービスの負荷を計測し、アプリケーション エラーのトラブルシューティングを行うことができます。このデータは、たとえば AppFabric ダッシュボードを設定します。 ビジネス関連データをワークフローから抽出できますが、Windows Server AppFabric では監視データの信頼性は保証されず、監視データがワークフローの状態と整合していることも保証されません。 イベントは、ビジネスの決定ではなく運用を目的として収集されます。 その結果、監視データと他のアプリケーション データの同期は重要ではありません。 通常、監視データは、永続化データや他のアプリケーション データとは別の、専用のデータベースに保持する必要があります。
AppFabric インストールの障害回復計画の一環として、Windows Server AppFabric データベースを別のサーバーに移動することが必要になる場合があります。 データベースを移動する前に、データベースのバックアップと復元が正常に実行されることを確認してください。 その後、移行後のデータベースの場所を参照するように接続文字列を変更する必要があります。 新しいデータベースの場所を参照するように接続文字列を変更するには、[ホスティング サービスの構成] ページを使用します。 AppFabric データベースの移動の詳細については、「ユーザー データベースの移動」を参照してください。
SQL Server の障害回復の詳細については、「SQL Server のバックアップと復元のストラテジの概要」、「SQL Server のバックアップと復元を行う方法に関するトピック」、「SQL Server の障害復旧オプション」、および「災害時の復旧の計画」を参照してください。
ヒント
このドキュメントでは、SQL Server データベースについて説明します。 ただし、他のベンダーによって実装された Windows Server AppFabric データベースについても同じことを実行する必要があります。
Windows の構成
サーバーのバックアップを実行するときは、AppFabricに関連する以下の構成データが含まれることを確認する必要があります。 Microsoft System Center Data Production Manager などの Windows ボリューム シャドウ コピー サービス (VSS) を利用するバックアップ エージェントは、以下のファイルを自動的に含めます。 システム ライターでは、ルート web.config ファイルおよび %SystemRoot%\System32 の下のファイルが対象になります。 IIS 構成ライターには MWA スキーマ ファイルが含まれます。 キャッシュ構成を自動的にカバーする VSS ライターはありません。
イベント コレクション サービスの構成、名前なしサービス ビヘイビアーの構成 (ビヘイビアー名 = "")、および監視プロバイダーと永続化プロバイダーは、ルート web.config ファイル (%SystemRoot%\Microsoft.NET\Framework {Framework64}\v4.x\Config\web.config) に格納されます。
ワークフロー管理サービスの構成は、%SystemRoot%\System32\AppFabric の Workflowmanagementservice.exe.config ファイルに格納されます。
カスタム MWA スキーマ (たとえば、カスタム ビヘイビアーのツール化を可能にするなど) は、%SystemRoot%\System32\inetsrv\config\schema に格納されます。
Windows Server AppFabric には、分散キャッシュ構成を格納するための 2 つのプロバイダーが用意されています。 XML プロバイダーは、キャッシュの構成を、ユーザーが構成の間に指定した共有ディレクトリに XML ファイルとして格納します。 SQL Server プロバイダーは、キャッシュの構成を SQL Server データベースに格納します。 この構成をバックアップする必要があります。
代わりに、Web サーバー全体の内容とリモート コンピューターに格納されているパッケージを同期する定期的な Web 配置ツール ("MSDeploy") コマンドのスケジュールを設定できます。 このパッケージは、既定で、前記の項目 1 をカバーし、Web サーバーに展開されているすべてのアプリケーション (構成とバイナリ) を含めます。 前述の構成ファイルを明示的に含めるようパッケージをカスタマイズすることもできます。 障害時には、基本サーバー イメージを復元し、Web 配置ツール パッケージをサーバーに簡単に展開できます。 通常は、基本サーバーの構成を作成した後、それを他のコンピューターにコピーします。 基本サーバーには、Windows オペレーティング システム、Windows サーバーの役割、Windows 更新プログラム、およびカスタマイズしたユーザー アカウントが含まれます。 管理者は Windows Server AppFabric を基本サーバーにインストールする必要がありますが、通常は、基本サーバーのイメージでは AppFabric を構成せず、AppFabric のサービス用のデータベースとユーザー アカウントを、新しいコンピューターにイメージを適用した後で設定できるようにする必要があります。 この基本サーバーのイメージは、Sysprep または Windows Server バックアップを使用してバックアップできます。
インターネット インフォメーション サービス (IIS)
WebDeploy を使用して、IIS マネージャー コンソールからアプリケーションをエクスポートしてバックアップを作成します。 アプリケーションに関するファイル システムの内容をすべてエクスポートすることもできます。 AppFabric の展開機能の [詳細設定] ダイアログを使用すると、ACL をエクスポートして特定のカスタム パラメーターを追加することができます。 エクスポートが完了したら、エクスポート結果の zip ファイルを安全な場所に保存します。 後日、障害後にシステムを復元するときに、IIS マネージャーを使用してアプリケーションを AppFabric にインポートして、アプリケーションとその関連の構成設定やレジストリ設定を再構築することができます。 AppFabric アプリケーションを適切にエクスポートおよびインポートして必要なすべての構成設定を確実に保存する方法の詳細については、「Windows Server AppFabric でのアプリケーションのインポートおよびエクスポート」を参照してください。
純粋な IIS 側の視点では、AppCmd ユーティリティを使用して IIS メタベースのバックアップを作成することをお勧めします。 AppCmd では共有上のデータがバックアップされないので、共通の UNC 共有上の IIS 共有構成を使用している場合は、共有構成ファイルを手動でバックアップする必要があります。 IIS7 構成データを Windows ファイル システム レベルで保護するのは簡単で、\windows\system32\inetsrv\config ディレクトリ (およびサブディレクトリ) をバックアップ ディレクトリにコピーします。 このディレクトリを現在の Windows OS バックアップ計画に含めるか (BACKUP ユーティリティなどを使用する場合)、カスタム スクリプトを作成して Windows OS をバックアップするだけです。 AppCmd ユーティリティを使用して IIS をバックアップする方法の詳細については、「インターネット インフォメーション サービス 7 で構成バックアップを作成して管理する方法」および「IIS 7 構成をバックアップする方法」を参照してください。
まとめ
障害回復の準備は、運用環境における重要な作業です。 これは SQL Server、Windows、および IIS の各レベルで行います。 一部のデータ (コンピューターやソフトウェアの構成など) は、あまり変化せず、定期的なスケジュールでのバックアップによって安全に保護できます。 ワークフロー永続化などの他のデータは、アプリケーションにとって重要であり、書き込まれたら保護する必要があります。 Windows Server AppFabric の構成データは、定期的なバックアップに含める必要があります。 また、管理者は、永続化の高可用性、および状況によってはキャッシュ データの高可用性も、保証する必要があります。
2011-12-05