次の方法で共有


IIS 7 を使用した共有構成

はじめに

インターネットは、企業の日々のビジネス処理のやり方、市場競争の方法を変えています。 新しい Web テクノロジが登場し、Web を介して利用できるリソースにアクセスする顧客の数が増えるにつれて、アプリケーションのスケーラビリティ、可用性、信頼性、管理性の向上が急務となっています。 アプリケーションは、高いアップタイム、要求スループットの向上、同時ユーザー トランザクションの増加、競合システムよりも優れたサービス品質などの投資収益率の向上を実現する機能を提供するシステムに依存するものです。

Web ファーム (サーバー クラスター) は、負荷を分散することで、高度にスケーラブルで、可用性が高く、管理しやすいアプリケーションを提供するための標準となっています。 具体的には、これらのアプリケーション属性が、Web ファームと負荷分散の主な理由になっています。 Web ファームを使用することで、組織は、スケーラブルな方法を提供し、アプリケーションとそのリソースに同時にアクセスするユーザー ベースの容量を増やすことができます。

サーバー クラスターを使用すると、複数のサーバーに負荷が分散され、可用性が向上します。 またクラスターにより、任意の時点で顧客数が増えても、よりよくスケールできます。 最後に、運用リソースを負担することなく、Web ファーム アーキテクチャのプロビジョニングと管理を簡単に処理できるので、クラスターの管理エクスペリエンスが向上します。

概要

この記事では、共有の一元化されたグローバル構成機能について説明します。 この機能は、サーバーがサーバー グループ間で同じ構成を共有する同種の Web ファームをサポートするのに役立ちます。 UNC 共有を使用することにより、特別なツールやプログラム的な支援がなくても、中央のマスター構成ファイルに対するすべての変更が他のサーバーに伝達されます。

この記事の第 1 パートでは、IIS 7 以降の管理 UI を使用して共有構成を有効にして使用する方法について説明します。 第 2 パートでは、コマンド ラインから共有構成を有効にして使用する方法について説明します。

目標外: この記事で取り上げない内容

正しいサポート可能性、管理容易性、アクセシビリティ、スケーラビリティなど、Web ファーム環境の成功に貢献するさまざまな側面があります。

共有構成は、Web ファームの構成管理の側面にのみ焦点を当て、サーバー間の構成を扱います。 複数のサーバーの管理、コンテンツのコピー、モジュールの配置、アプリケーション バイナリの同期、サードパーティコンポーネントの設定などに役立つツールやその他の機能があります。これらのツール、機能、および側面は、この記事の範囲外です。

この記事では、サーバー間で中央のファイルを使用して構成を維持する方法についてのみ詳しく説明します。

そのため、共有構成を使用すると、サーバーはローカル構成であるかのようにバックエンド UNC 共有内の構成ファイルにアクセスできます。 その結果、フロントエンド Web サーバーを使用して構成を更新すると、他のすべてのサーバーに対して更新が行われます。

サードパーティ モジュールのインストールや構成設定の追加など、その他の状況を考慮し、1 つのサーバーのみが理解でき、バイナリとスキーマを正しく機能させるために使用できるプロパティを含める必要があります。 そうしないと、この種類の使用が他のサーバーを中断する可能性があります。

同種のファームでこの問題を回避するには、クラスターで共有構成を無効にし、ローカル applicationHost ファイルを更新してリモート ファイルをミラー化し、モジュールと構成を 1 台のサーバーに配置して更新してから、そのサーバーで共有構成を再度有効にする必要があります。 その後、共有構成を再度有効にする前に、サーバーの残りの部分にバイナリとモジュールを配置して更新できます。

ドメイン環境と非ドメイン環境

管理者によってはドメイン環境に Web クラスターを配置する人もいれば、ワークグループ (ドメイン以外) にデプロイする管理者もいます。 この記事では、両方のシナリオについて説明し、相違点と注意事項について説明します。 ドメイン コントローラーを使用して Active Directory が提供するヘルプとセキュリティを使用して、ドメイン内のクラスターに IIS を設定することをおすすめします。

前提条件

次の手順を順番に完了する必要があります:

  1. IIS をサーバーにインストールします。これを、この記事全体を通して Web サーバーと呼びます。
  2. この記事全体を通してファイル サーバーと呼ぶ 2 つ目のサーバーへのアクセスを確認します。 ファイル サーバーには、UNC を使用してアクセスできる構成と基本的なコンテンツの共有が格納されます。
  3. この記事では、各手順において、その前の手順が完了しているということを前提にしています。 すべての手順を順番に実行します。
  4. 一部の手順では、UI を使用して同じ手順を実行できる場合もあります。 特に指定しない限り、1 種類の手順のみを実行します。

集中管理構成

IIS 管理 UI には、構成リダイレクトの設定、構成ファイルと必要な暗号化キーの指定パスへのエクスポートをサポートが含まれます。

UI を使用してファイルをエクスポートし、構成リダイレクトを設定するには

  1. IIS マネージャーを開きます。
  2. ツリー ビューで、構成リダイレクトを設定するサーバー接続を選択します。
  3. [共有構成] をダブルクリックします。
    [共有構成] アイコンが選択されている I I S Manager のスクリーンショット。
  4. [操作] ウィンドウで、[構成のエクスポート...] をクリックして、必要な構成ファイルをローカル サーバーから別の場所 (UNC 共有など) にエクスポートします。
    [構成のエクスポート] ドットドットが強調表示された [共有構成] の [操作] ウィンドウのスクリーンショット。
  5. [構成のエクスポート] ダイアログ ボックスで、ファイルをエクスポートするパスを入力します。 パスワードを入力して、エクスポートされる暗号化キーを保護します。 [OK] をクリックして、構成ファイルとパスワードで保護された暗号化キーをエクスポートします。
    [構成の場所] と [暗号化キー] パスワードのフィールドが表示されている [構成のエクスポート] ダイアログ ボックスのスクリーンショット。
  6. [共有構成を有効にする] チェック ボックスをオンにして、構成リダイレクトを有効にします。
    [共有構成の有効化] が強調表示されている [共有構成] ダイアログ ボックスのスクリーンショット。
  7. 構成キーと暗号化キーが配置されているパスを指定し、そのパスへのアクセスに使用する資格情報を指定します。 [次の権限で接続...] をクリックし、資格情報を入力します。
    ユーザー名とパスワードに資格情報が入力された [共有構成] ダイアログ ボックスのスクリーンショット。
  8. [適用] をクリックして、設定を保存します。 [共有構成] ダイアログ ボックスで、暗号化キーを保護するために指定したパスワードを入力します。
    暗号化キーのパスワードを入力するフィールドが表示されている [共有構成] ダイアログ ボックスのスクリーンショット。
  9. [OK] をクリックして、構成リダイレクトの設定を完了します。

上記の手順では、構成をエクスポートし、一元化された構成を有効にする方法について説明します。 ただし、構成をエクスポートする必要があるのは 1 回だけです。 一元化された構成を使用する後続の各サーバーで、手順 6 から 9 を実行します。

UI の使用に関する注意事項

構成リダイレクトを設定する場合、エクスポートされたファイルは UI を使用してエクスポートされている必要があります。 これは、UI が独自のカスタム形式を使用して、パスワードで保護された暗号化キーなどの項目をエクスポートおよびインポートするためです。

たとえば、administration.config ファイルと applicationHost.config ファイルを手動で共有にコピーし、暗号化キーを手動でエクスポートしていた場合、UI を使用してそれらのファイルを指す構成リダイレクトを設定することはできません。 これは、エクスポートされた暗号化キーが UI で要求される形式ではないためです。

コマンド プロンプト

この記事の残りの部分では、コマンド プロンプトを使用して特定のコマンドを実行する必要があります。 通常のコマンド プロンプトを実行すると特定のコマンドが機能しないため、昇格されたユーザー権利でコマンド プロンプトを使用することをおすすめします。

昇格されたユーザー権利でコマンド プロンプトを開くには

  1. [開始] をクリックします。
  2. [すべてのプログラム] をクリックします。
  3. [アクセサリ] をクリックします。
  4. [コマンド プロンプト] を右クリックし、 [管理者として実行] を選択します。
  5. 表示されるダイアログ ボックスの指示に従います。

現在の applicationHost.config ファイルのバックアップ

新しい機能を試したり、複数の構成設定を変更したりする場合は、現在の applicationHost.config ファイルをバックアップすることをおすすめします。

applicationHost.config ファイルをバックするには

  1. コマンド プロンプトを開きます。

  2. 既定で %WINDIR%\System32\InetSrv 配置されている IIS ディレクトリに移動します。 構成ファイルは InetSrv\Config ディレクトリに格納されます。 AppCmd ツールを使用してバックアップ オブジェクトを作成し、次のコマンドを実行して applicationHost.config ファイルをバックアップします:

    cd /d %windir%\system32\inetsrv
    appcmd add backup centralConfigBackup
    

    Note

    AppCmd ツールは InetSrv ディレクトリにあります。 ツールのパスがシステムの環境変数に追加されていない限り、このディレクトリからツールにアクセスする必要があります。

  3. 次のコマンドを実行して、applicationHost.config ファイルと SMTP およびその他の Web 以外のサーバー設定のレガシ メタベース ファイルを含むバックアップ オブジェクトが存在することを確認します:

    appcmd list backup
    

現在の構成ファイルをバックアップ ファイルに置き換えるには

  1. コマンド プロンプトを開きます。

  2. 既定で InetSrv ディレクトリにある IIS ディレクトリに移動します。 次のコマンドを実行して、AppCmd バックアップ ファイル オブジェクトを復元します:

    cd /d %windir%\system32\inetsrv\
    appcmd restore backup centralConfigBackup
    

構成用の UNC 共有にアクセスするユーザーの作成

ドメイン環境では、管理者は Active Directory で使用するアカウントをドメインに指定または作成する必要があります。 このアカウントは、UNC 共有にアクセスするための適切なユーザー権限で設定する必要があります。

ドメイン以外の環境では、管理者は両方のサーバーで、コンテンツにアクセスするユーザー権限を持つローカル ユーザーを作成する必要があります。 このセットアップで動作するには、サーバー間でユーザー名とパスワードが同じである必要があります。 次の手順は、共有構成が存在する共有を読み取るユーザーの作成に役立ちます。

共有構成が存在する共有 (ドメイン以外) を読み取ることができるユーザーを作成するには

  1. コマンド プロンプトを開きます。

  2. Web サーバー (IIS がインストールされているフロントエンド サーバー) で、次のコマンドを実行して、ConfigUser1 という名前のユーザーをパスワード ConfigPass1 で作成します:

    net user ConfigUser1 ConfigPass1 /add
    
  3. ファイル サーバー (中央構成が存在するバックエンド サーバー) で、次のコマンドを実行して、ConfigUser1 という名前のユーザーをパスワード ConfigPass1 で作成します:

net user ConfigUser1 ConfigPass1 /add

中央構成とコンテンツの UNC 共有の作成

構成用の UNC 共有は、この一元化された場所から構成データを取得するすべてのサーバーの applicationHost.config ファイルをホストします。

UNC 共有を作成するには

  1. ファイル サーバーで、コマンド プロンプトを開きます。

  2. ドライブのルートに移動します。 次のコマンドを実行して、構成用のディレクトリを作成し、このディレクトリを共有します。このディレクトリに対する読み取りと書き込みの権限をユーザーに付与します:

    md %SystemDrive%\centralconfig
    net share centralconfig$=%SystemDrive%\centralconfig /grant:Users,Change
    

    Note

    このコマンドは、この共有に対するユーザー グループに対するユーザー権限を自動的に付与します。 ドメイン以外のシナリオ用に作成されたユーザーには変更権限が自動的に付与され、必要に応じてさらに制限することができます。 ドメイン シナリオでは、ユーザーは共有にアクセスするために明示的にユーザー権限を設定するか、システム内のユーザー グループに追加する必要があります。

  3. ドメイン以外のシナリオ: 共有のセキュリティを高めるには、/grant スイッチの Users,Change 部分を ConfigUser1,Change パラメータに置き換えることができます。 指定したユーザーのみが共有にアクセスできます。

  4. ドメイン シナリオ: 共有のセキュリティを高めるには、ユーザー、/grant スイッチの User,Change 部分を domain\user,Change パラメータに置き換えることができます。 共有へのリモート アクセス権を持つのは、指定されたユーザーだけです。

    Note

    共有に対するユーザー権限は、リモート ファイル システムとローカル ファイル システムのユーザー権限の和集合です。 構成共有を正常に読み取ることができるように、ドメイン アカウントのディレクトリに適切なユーザー権限を設定する必要があります。

中央構成とコンテンツをホストする UNC 共有のアカウントにユーザー権限を付与する

構成へのアクセスに使用されるアカウントに適切なユーザー権限があることを確認する必要があります。 このアカウントは、仮想ディレクトリが UNC 共有にマップされるときにコンテンツにアクセスするのと同じ方法で IIS が UNC 共有にアクセスするのに使用します。 このアカウントの読み取りユーザー権限は、共有にのみアクセスする場合に便利です。 その後、IIS は構成ファイルを読み取るたびに、呼び出し元が持っている ID (API、使用されている管理ツール、またはその時点でログインしているユーザー) に戻ります。

Note

構成の読み取りに使用される ConfigUser1 アカウントまたは同等のドメイン アカウントは、構成の記述に使用されるアカウントと同じではありません。 これらのアカウントは、共有または構成ファイルに対する書き込みユーザー権限を持っている必要はありません。

UNC 共有 (ドメイン) のアカウントにユーザー権限を付与するには

  1. ドメイン アカウントがローカル ユーザー グループの一部であり、共有の作成時にユーザーにアクセス権が付与されている場合は、ドメインセットアップの次の手順をスキップできます。 ただし、ローカル ファイル共有にアクセスするドメイン アカウントがローカル ユーザー グループに含まれていない場合は、コマンドを実行してユーザー権限を付与する必要があります。
  2. ファイル サーバーで、コマンド プロンプトを開きます。
  3. 次のコマンドを実行して、構成が格納されているディレクトリを読み取るユーザー権限をドメイン アカウントに提供します:
icacls %SystemDrive%\centralconfig\ /grant domain\user:R

UNC ユーザー (ドメインとドメイン以外) を追加するには

ドメインとドメイン以外のシナリオでは、ユーザー名にログオン バッチ ジョブの構成を含める必要があります。 これは Windows Server® 2008 の既定の設定ではなく、Web サーバーに手動で追加する必要があります。

  1. [開始] をクリックします。 [管理ツール] をクリックし、[ローカル セキュリティ ポリシー] を選択します。
  2. [ローカル ポリシー] で、[ユーザー権利の割り当て] を選択します。
  3. [バッチ ジョブとしてログオン] をダブルクリックし、作成した UNC ユーザーを追加します。

構成のリダイレクト

はじめに

前の手順を完了したので、Web サーバーは機能し、フロントエンド Web サーバーは localhost ループ バック アドレスを使用して既定の Web サイトを提供します。

これで、構成を中央の場所に移動できるようになりました。 これにより、ファイルをマスター ファイルとして宣言し、複数のサーバーの構成のために UNC 共有に保存できます。 このファイルを 1 回変更すると、すべてのサーバー構成が一度にプロビジョニングおよび更新されます。

UNC 共有に構成を格納するには

  1. フロントエンド Web サーバー上の %windir%\system32\inetsrv\config ディレクトリから applicationHost.config ファイルと administration.config ファイルをコピーし、バックエンド ファイル サーバー上で共有します。 現在ログインしているユーザー アカウントにバックエンド共有への書き込みアクセス権がある場合は、ディレクトリにファイルをドロップすることができます。 そうでない場合は、バックエンドに対してユーザー アカウントを認証して、この手順を完了する必要があります。

  2. フロントエンド サーバーの構成ディレクトリにある既存の redirection.config XML ファイルにアクセスします:

    • Windows エクスプローラーを使用して %windir%\system32\inetsrv\config に移動します。
    • redirection.config ファイルを開きます。 このファイルとその内容は、Web サーバーの設定時に作成されます。 ツールと API は、このファイルにアクセスして、この機能が有効になっているかどうかを判断できます。
  3. redirection.config ファイルを開きます。 お使いの環境に適したサーバー名、ユーザー名、パスワードを使用して、次の構成を設定します。

    <configuration> 
        <configSections> 
            <section name="configurationRedirection" /> 
        </configSections> 
        <configurationRedirection enabled="true" path="\\machinename\centralconfig$\" userName="ConfigUser1 or domain\user" password="ConfigPass1 or domainPassword" /> 
    </configuration>
    
  4. redirection.config ファイルを保存します。 サイトに再度アクセスできますが、構成は UNC 共有に格納されるようになりました。

構成のテスト

構成はバックエンドから参照されるため、この機能が設計された主なシナリオは 2 つあります。 フロントエンド Web サーバーの構成は、次の 2 つの方法で更新できます:

  1. applicationHost.config ファイルは、ファイル共有内で直接編集できます。 これが完了すると、変更通知が行われ、Web サーバーによってファイル内の変更が取得されます。
  2. バックエンド ファイル共有に 2 つ目の applicationHost.config ファイルを追加し、Web サーバーの redirection.config ファイルを新しいバージョンのファイルを指すように変更できます。 これは、ロールバックの目的やステージング展開に役立ちます。

まとめ

この記事では、新しい一元化された構成機能について説明しました。 この機能を使用すると、Web ファーム環境に同種のクラスターを持つ管理者は、すべてのサーバーにシームレスな方法で構成を設定して配置できます。

この機能がセットアップされると、UNC 共有のファイルに変更が加えられたか、サーバーが別の場所にリダイレクトされるかに関係なく、変更は Web サーバーによってすぐに取得されます。 複数のサイトとアプリケーションに影響を与えるグローバル変更のみがリサイクルされることになりますが、ローカライズされたスコープで変更が行われた場合、残りのサイトとアプリケーションは再起動されません。

付録 1: 値を読み取るためにプログラムで Redirection.config ファイルにアクセスする

この手順では、新しい COM AHADMIN API を利用して、プログラムで redirection.config ファイルにアクセスする方法のサンプルを提供します。 AHADMIN COM API を使用して、ネイティブ コードまたはスクリプトとマネージド コードからこの API を実装します。

プログラムで値を読み取るために

  1. テキスト ファイルを作成し、.js拡張子を付けて保存します。 次のスクリプトは、お使いの環境の有効な属性、サーバー名、ユーザー名、パスワードを読み取る方法のサンプルを提供します:

    try
    {
      var config = WScript.CreateObject( "Microsoft.ApplicationHost.AdminManager" );
      var section = config.GetAdminSection( "configurationRedirection", "MACHINE/REDIRECTION" );
    
      WScript.Echo( "Current redirection:" );
      WScript.Echo( "enabled = " + section.Properties.Item( "enabled" ).Value );
      WScript.Echo( "path = " + section.Properties.Item( "path" ).Value );
      WScript.Echo( "user = " + section.Properties.Item( "userName" ).Value );
      WScript.Echo( "pass = " + section.Properties.Item( "password" ).Value );
    }
    catch(e)
    {
      WScript.Echo(e.number);
      WScript.Echo(e.description);
    }
    
  2. redirection.js ファイルを保存します。 Windows スクリプト ホスト (WSH) のおかげで、コマンド プロンプトからこのファイルを実行できるようになりました。

付録 2: プログラムで redirection.config ファイルにアクセスして値を書き込む

この手順では、新しい COM AHADMIN API を利用して、プログラムで redirection.config ファイルにアクセスする方法のサンプルを提供します。 この API は、ネイティブ コードから、または COM オブジェクトのスクリプトとマネージド コードから使用します。

プログラムで値を書き込むには

  1. テキスト ファイルを作成し、.js拡張子を付けて保存します。 次のスクリプトは、お使い環境の有効な属性、サーバー名、ユーザー名、パスワードを書き込む方法のサンプルを提供します:

    try
    {
        var config = WScript.CreateObject( "Microsoft.ApplicationHost.WritableAdminManager" );
      config.CommitPath = "MACHINE/REDIRECTION";
        var section = config.GetAdminSection( "configurationRedirection","MACHINE/REDIRECTION" );
      section.Properties.Item( "enabled" ).Value = true;
      section.Properties.Item( "path" ).Value = "\\\\somemachine\\sharefile://folder/";
      section.Properties.Item( "userName" ).Value = "testuser";
      section.Properties.Item( "password" ).Value = "testuser";
      config.CommitChanges();
    }
    catch(e)
    {
      WScript.Echo(e.number);
      WScript.Echo(e.description);
    }
    
  2. redirection.js ファイルを保存します。

  3. Windows スクリプト ホスト (WSH) のおかげで、コマンド プロンプトからこのファイルを実行できるようになりました。

付録 3: コンピューター固有の暗号化されたプロパティの処理

既定では、IIS には、プロパティをセキュリティで保護するための 2 つの主要なプロバイダーが含まれています。 これらのプロバイダーは、applicationHost.config ファイルの <configProtectedData> 構成セクションにあり、<providers> 要素で定義されています。

AesProvider は、system.webServer セクションにあるプロパティの暗号化と暗号化解除の処理に固有です。

IISWASOnlyRsaProvider は、system.applicationHost セクションにあるプロパティの暗号化と暗号化解除の処理専用です。

これらのキーは iisConfigurationKey および iisWasKey キー コンテナーにあり、マシン固有です。 Web ファームのシナリオでは、暗号化が必要な場合、セキュリティで保護されたプロパティを暗号化解除して Web サーバーで使用できるように、あるマシン (通常は applicationHost.config ファイルを作成したマシン) のキーがエクスポートされ、他のマシンに取り込まれます。

手順

  1. コマンド プロンプトを開きます。 既定で %windir%\Microsoft.NET\Framework\v2.0.50727\ 配置されている Framework ディレクトリに移動します。

    Note

    参考までに、システムのマシン キーは %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys\ にあります

  2. aspnet_regiis ツールを使用してキーをエクスポートします。 構成キーを転送するコマンドを以下に示します。 px スイッチは、RSA キー ペアをエクスポートすることを識別します。 pri スイッチは、秘密キーと公開キーの両方も含める必要があることを示します。

    このスイッチの識別は、暗号化と復号化の両方を行うために必要です。それ以外の場合は、エクスポートされたキーを使用してのみデータを暗号化できます。 -px から後のパラメーターは、エクスポートするキー コンテナーの名前です。 この場合は、"iisConfigurationKey" キー コンテナーです。 IIS で使用されるもう 1 つのキー コンテナーは、"iisWasKey" キー コンテナーです。

    aspnet_regiis -px "iisConfigurationKey" "D:\iisConfigurationKey.xml" -pri
    
  3. エクスポートが正常に完了したら、XML ファイルをクラスター内の他のマシンにコピーして、インポートの準備をします。

  4. Framework ディレクトリに移動し、aspnet_regiis ツールを使用して XML ファイルからキーをインポートします。 キーの転送を完了するコマンドを以下に示します。

    -pi から後のパラメーターは、インポートするキー コンテナーの名前です。 この場合は、"iisConfigurationKey" キー コンテナーです。 IIS で使用されるもう 1 つのキー コンテナーは、"iisWasKey" キー コンテナーです。

    aspnet_regiis -pi "iisConfigurationKey" "D:\iisConfigurationKey.xml"