データベース可用性グループの管理
適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3
トピックの最終更新日: 2016-11-28
データベース可用性グループ (DAG) とは、データベース障害、サーバー障害、またはネットワーク障害からの自動的なデータベースレベルの回復を提供する、最大 16 の Microsoft Exchange Server 2010 メールボックス サーバーのセットのことです。DAG は連続レプリケーションおよび Windows フェールオーバー クラスター化テクノロジを使用して、高可用性およびサイト復元を提供します。DAG 内のメールボックス サーバーは、障害を相互に監視します。メールボックス サーバーは DAG に追加されると、DAG の他のサーバーと連携して、データベース障害からの自動的なデータベース レベルの回復を実施します。
DAG を作成すると、最初は空であり、DAG を表す Active Directory にディレクトリ オブジェクトが作成されます。ディレクトリ オブジェクトは、サーバー メンバーシップ情報などの DAG に関連する情報を格納するために使用されます。最初のサーバーを DAG に追加すると、フェールオーバー クラスターが DAG 用に自動作成されます。さらに、ネットワーク障害またはサーバー障害がないかサーバーを監視するインフラストラクチャが開始します。フェールオーバー クラスターのハートビート機構とクラスター データベースは、データベース マウント状態、レプリケーション状態、および最終マウント位置など、急速に変化する DAG 関連情報を追跡および管理するために使用されます。
目次
DAG の作成
DAG メンバーシップ
DAG プロパティの構成
DAG ネットワーク
DAG メンバーの構成
DAG メンバーに対するメンテナンスの実行
DAG メンバーのシャットダウン
DAG メンバーに対する更新プログラムのロールアップのインストール
DAG の作成
DAG を作成するには、Exchange 管理コンソール (EMC) でデータベース可用性グループの新規作成ウィザードを使用するか、Exchange 管理シェルで New-DatabaseAvailabilityGroup コマンドレットを実行します。DAG を作成する場合、DAG の名前と、オプションのミラーリング監視サーバーおよびミラーリング監視ディレクトリの設定を指定します。さらに、静的 IP アドレスを使用するか、動的ホスト構成プロトコル (DHCP) によって DAG に必要な IP アドレスを自動的に割り当てることにより、1 つまたは複数の IP アドレスが DAG に割り当てられます。DatabaseAvailabilityGroupIpAddresses パラメーターを使用して、手動で IP アドレスを DAG に割り当てることができます。このパラメーターを省略すると、DAG がネットワーク上の DHCP サーバーを使用することによって IP アドレスの取得を試みます。
DAG を作成する方法の詳細な手順については、「データベース可用性グループの作成」を参照してください。
DAG を作成する場合、指定した名前の DAG を表す空のオブジェクトと、msExchMDBAvailabilityGroup のオブジェクト クラスが Active Directory に作成されます。
DAG は、クラスター ハートビート、クラスター ネットワーク、およびクラスター データベースなどの、Windows フェールオーバー クラスタリング テクノロジの一部を使用します。クラスター データベースは、アクティブとパッシブ、マウントとマウント解除の切り替えなど、データベース状態を (迅速に) 変更するデータの格納に使用されます。DAG は Windows フェールオーバー クラスタリングに依存しているため、これらは Windows Server 2008 Enterprise オペレーティング システムまたは Windows Server 2008 R2 Enterprise オペレーティング システムを実行している Exchange 2010 メールボックス サーバー上にのみ作成できます。
注意
DAG によって作成および使用されるフェールオーバー クラスターは、DAG 専用である必要があります。このクラスターは、他の高可用性ソリューションや別の目的のために使用することはできません。たとえば、フェールオーバー クラスターは、他のアプリケーションやサービスをクラスター化するためには使用できません。DAG 以外の目的で DAG の基になるフェールオーバー クラスターを使用することは、サポートされません。
DAG ミラーリング監視サーバーおよび監視ディレクトリ
DAG を作成する場合、Active Directory フォレスト内で一意の 15 文字以内の DAG 名を指定する必要があります。さらに、各 DAG はミラーリング監視サーバーとミラーリング監視ディレクトリで構成されます。ミラーリング監視サーバーとそのディレクトリは、DAG 内のメンバーが偶数の場合にクォーラムの目的でのみ使用されます。監視ディレクトリを事前に作成する必要はありません。Exchange は、ミラーリング監視サーバー上に必要なディレクトリを作成してセキュリティで保護します。ディレクトリは、DAG ミラーリング監視サーバー以外の目的で使用しないでください。
ミラーリング監視サーバーの要件は、以下のとおりです。
DAG のメンバーでないミラーリング監視サーバーを指定する必要があります。
監視サーバーを DAG と同じ Active Directory フォレスト内に配置する必要があります。
監視サーバーは、Windows Server 2003 以降を実行している必要があります。
1 台のサーバーが、複数の DAG のミラーリング監視サーバーとして動作できます。ただし、各 DAG には独自の監視ディレクトリが必要です。
DAG が含まれる Exchange 2010 サイトでは、Active Directory ハブ トランスポート サーバーを使用することをお勧めします。これにより、ミラーリング監視サーバーおよびディレクトリが Exchange 管理者の管理下に置かれます。どのサーバーをミラーリング監視サーバーとして使用する場合でも、Windows ファイアウォールを目的のミラーリング監視サーバーで有効にする際は、ファイルとプリンターの共有を Windows ファイアウォールの例外に設定する必要があります。
重要
指定するミラーリング監視サーバーが Exchange 2010 サーバーではない場合、DAG を作成する前に Exchange Trusted Subsystem ユニバーサル セキュリティ グループ (USG) をミラーリング監視サーバー上のローカルの Administrators グループに追加する必要があります。必要に応じて、Exchange がディレクトリを作成し、ミラーリング監視サーバーで共有できることを確認するには、これらのセキュリティ アクセス許可が必要です。
ミラーリング監視サーバーおよびミラーリング監視ディレクトリは、フォールト トレラントである必要はなく、冗長性または高可用性の形式を使用する必要がありません。クラスター化されたファイル サーバーをミラーリング監視サーバー用に使用する必要はなく、ミラーリング監視サーバーのその他の復元形式を採用する必要もありません。これには、さまざまな理由があります。DAG の規模が大きい場合は (例: 6 メンバー以上)、数か所で障害が発生しない限り、ミラーリング監視サーバーは必要になりません。6 メンバーの DAG は、2 つまでの投票者障害ではクォーラムを失わないため、3 つの投票者に障害が発生して初めて、クォーラムを維持するためにミラーリング監視サーバーが必要になります。また、現在のミラーリング監視サーバーに影響を与える障害がある場合 (例: ハードウェア障害のためにミラーリング監視サーバーを失う場合)、クォーラムがあることを前提として、Set-DatabaseAvailabilityGroup コマンドレットを使用して新しいミラーリング監視サーバーと監視ディレクトリを構成できます。
注意
ミラーリング監視サーバーでそのストレージが失われたか、監視ディレクトリまたは共有アクセス許可が変更された場合は、Set-DatabaseAvailabilityGroup コマンドレットを使用して、元の場所のミラーリング監視サーバーおよび監視ディレクトリを構成することもできます。
ベスト プラクティスとして、DAG が複数のデータセンター (および Active Directory サイト) にわたってサイト復元用に構成されている環境では、プライマリ データセンター (ユーザー人口の大多数を含むデータセンター) のミラーリング監視サーバーを使用することをお勧めします。各データセンターのユーザー数がほぼ同じ場合は、ミラーリング監視サーバーのホスト用に選択するデータセンターがソリューションの観点からプライマリ データセンターと見なされます。ミラーリング監視サーバーがクライアント人口の大多数を含むデータセンター内にある場合、クライアントの大多数は障害後にアクセスが保持されます。
データセンターが多数のユーザー人口から離れている場合、決定に影響を与えることがあります。他の 2 つのデータセンターへのワイド エリア ネットワーク (WAN) 接続が失われたときに正常でアクティブな状態を保つというプライマリ データセンターの要件があるかどうかを判断する必要があります。その場合、ミラーリング監視サーバーもプライマリ データセンター内になくてはなりません。
3 番目のデータセンター内でミラーリング監視サーバーを使用することがサポートされていますが、このシナリオは推奨しません。Exchange の観点から、この構成では可用性が向上しません。3 番目のデータセンター内でミラーリング監視サーバーを使用する場合は、クリティカル パス要素を検討することが重要です。たとえば、プライマリ データセンターと 2 番目および 3 番目のデータセンター間の WAN 接続が失敗した場合、プライマリ データセンター内のソリューションが使用できなくなります。
DAG 作成時のミラーリング監視サーバーおよびミラーリング監視ディレクトリの指定
DAG を作成するときに、その DAG の名前を入力する必要があります。必要に応じて、ミラーリング監視サーバーと監視ディレクトリも指定できます。ミラーリング監視サーバーを指定する場合は、ハブ トランスポート サーバーを使用することをお勧めします。理由は、これにより、Exchange 管理者がミラーリング監視サーバーの可用性を把握できるからです。
DAG を作成する場合、以下のオプションと動作の組み合わせを使用できます。
DAG の名前のみを指定して、[監視サーバー] と [監視ディレクトリ] フィールドを空白のまま残すことができます。このシナリオの場合、ウィザードは、メールボックス サーバーの役割がインストールされていないハブ トランスポート サーバーを検索し、自動的にそのサーバー上に既定のディレクトリ (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) と既定の共有 (<DAGFQDN>) を作成して、ハブ トランスポート サーバーをミラーリング監視サーバーとして使用します。たとえば、EXMBX3 という名前のミラーリング監視サーバーで、オペレーティング システムが C ドライブ上にインストールされているとします。contoso.com というドメイン内の DAG1 という名前の DAG は、既定の監視ディレクトリである C:\DAGFileShareWitnesses\DAG1.contoso.com を使用し、これは \\EXMBX3\DAG1.contoso.com として共有されます。
DAG の名前、使用するミラーリング監視サーバー、およびミラーリング監視サーバーで作成して共有するディレクトリを指定できます。
DAG の名前および使用するミラーリング監視サーバーを指定して、[監視ディレクトリ] フィールドを空白のまま残すことができます。この場合、ウィザードでは、指定のミラーリング監視サーバーに既定のディレクトリを作成します。
DAG の名前を指定し、[監視サーバー] フィールドを空白のまま残して、ミラーリング監視サーバーで作成して共有するディレクトリを指定できます。この場合、ウィザードでは、メールボックス サーバーの役割がインストールされていないハブ トランスポート サーバーを検出し、指定の DAG をそのサーバーに自動的に作成してディレクトリを共有し、ハブ トランスポート サーバーをミラーリング監視サーバーとして使用します。
DAG が作成される場合、最初にノード マジョリティ クォーラム モデルを使用します。2 番目のメールボックス サーバーが DAG に追加される場合、クォーラムが自動的にノードとファイル共有マジョリティ クォーラム モデルに変更されます。この変更が行われると、DAG はクォーラムを保持するためにミラーリング監視サーバーの使用を開始します。監視ディレクトリが存在しない場合、Exchange は自動で作成および共有し、DAG のクラスター名オブジェクト (CNO) コンピューター アカウント用のフル コントロール アクセス許可で共有を準備します。
注意
ファイル共有を分散ファイル システム (DFS) 名前空間の一部として使用する機能は、サポートされていません。
DAG が作成される前にミラーリング監視サーバー上で Windows ファイアウォールが有効になると、Windows ファイアウォールが DAG の作成をブロックすることがあります。Exchange は Windows Management Instrumentation (WMI) を使用して、ミラーリング監視サーバー上にディレクトリとファイル共有を作成します。ミラーリング監視サーバー上で Windows ファイアウォールが有効であり、WMI 向けのファイアウォールの例外が構成されていない場合、New-DatabaseAvailabilityGroup コマンドレットは失敗し、エラーが発生します。ミラーリング監視サーバーを指定して監視ディレクトリを指定しないと、以下のエラー メッセージが表示されます。
タスクが、サーバー <サーバー名> 上に既定の監視ディレクトリを作成できませんでした。監視ディレクトリを手動で指定してください。 |
ミラーリング監視サーバーと監視ディレクトリを指定すると、以下の警告メッセージが表示されます。
監視サーバー 'サーバー名' 上のネットワーク ファイル共有にアクセスできません。この問題を修正するまで、データベース可用性グループは、障害に対する脆弱性が増す可能性があります。Set-DatabaseAvailabilityGroup を使用して操作を再試行してください。エラー:ネットワーク パスが見つかりませんでした。 |
DAG が作成された後で、サーバーが追加される前に Windows ファイアウォールがミラーリング監視サーバー上で有効になると、Windows ファイアウォールは DAG メンバーの追加や削除をブロックすることがあります。ミラーリング監視サーバー上で Windows ファイアウォールが有効であり、WMI 向けのファイアウォールの例外が構成されていない場合、Add-DatabaseAvailabilityGroupServer コマンドレットでは以下の警告メッセージが表示されます。
監視サーバー 'サーバー名' 上にファイル共有監視ディレクトリ 'C:\DAGFileShareWitnesses\DAG_FQDN' を作成できませんでした。この問題を修正するまで、データベース可用性グループは、障害に対する脆弱性が増す可能性があります。Set-DatabaseAvailabilityGroup を使用して操作を再試行してください。エラー:サーバー 'サーバー名' 上で WMI 例外が発生しました:RPC サーバーを利用できません(HRESULT からの例外:0x800706BA)。 |
このようなエラーと警告を解決するには、次のいずれかを実行します。
手動でミラーリング監視サーバー上に監視ディレクトリと共有を作成し、そのディレクトリと共有に対して DAG フル コントロールの CNO を割り当てます。
Windows ファイアウォールで WMI の例外を有効にします。
Windows ファイアウォールを無効にします。
ページのトップへ
DAG メンバーシップ
DAG が作成された後に、EMC 内のデータベース可用性グループの管理ウィザードを使用するか、シェル内の Add-DatabaseAvailabilityGroupServer または Remove-DatabaseAvailabilityGroupServer コマンドレットを使用することによって、DAG にサーバーを追加するか DAG からサーバーを削除することができます。DAG メンバーシップを管理する方法の詳細な手順については、「データベース可用性グループのメンバーシップの管理」を参照してください。
注意
DAG のメンバーである各メールボックス サーバーは、DAG で使用する基になるクラスター内のノードでもあります。この結果、メールボックス サーバーは一度に 1 つの DAG のみのメンバーにすることができます。
DAG に追加しているメールボックス サーバーにフェールオーバー クラスタリング コンポーネントがインストールされていない場合は、サーバーを追加するために使用する方式 (例: Add-DatabaseAvailabilityGroupServer コマンドレットまたはデータベース可用性グループの管理ウィザード) によってフェールオーバー クラスタリング機能がインストールされます。
最初のメールボックス サーバーが DAG に追加されると、以下の処理が行われます。
まだインストールされていない場合は、Windows フェールオーバー クラスタリング コンポーネントがインストールされます。
フェールオーバー クラスターが DAG 名を使用して作成されます。このフェールオーバー クラスターは、DAG によって排他的に使用されます。このクラスターは、DAG 専用である必要があります。他の目的でクラスターを使用することは、サポートされません。
CNO が既定のコンピューター コンテナーに作成されます。
DAG の名前および IP アドレスがドメイン ネーム システム (DNS) 内のホスト (A) レコードとして登録されます。
サーバーは Active Directory の DAG オブジェクトに追加されます。
追加サーバーにマウントされたデータベースの情報で、クラスター データベースが更新されます。
大規模、または複数サイト環境、特に DAG が複数の Active Directory サイトに拡張されている環境では、最初の DAG メンバーを含む DAG オブジェクトの Active Directory レプリケーションが完了するのを待機する必要があります。この Active Directory オブジェクトが環境全体でレプリケートされていない場合に 2 番目のサーバーを追加すると、DAG の新しいクラスター (および新しい CNO) が作成される場合があります。これは、2 番目のメンバーが追加されるときに DAG オブジェクトが空と見なされるため、DAG のクラスターと CNO が既に存在しているにもかかわらず、Add-DatabaseAvailabilityGroupServer コマンドレットがこれらのオブジェクトを作成してしまうためです。最初の DAG サーバーを含む DAG オブジェクトがレプリケートされたことを確認するには、追加する 2 番目のサーバー上で Get-DatabaseAvailabilityGroup コマンドレットを使用して、追加した最初のサーバーが DAG のメンバーとして一覧されていることを確認します。
2 番目とそれ以降のメールボックス サーバーが DAG に追加されると、次のようになります。
サーバーが DAG の Windows フェールオーバー クラスターに参加します。
クォーラム モデルが次のように自動調整されます。
ノード マジョリティ クォーラム モデルは、奇数のメンバーを持つ DAG に使用されます。
ノードおよびファイル共有マジョリティ クォーラム モデルは、偶数のメンバーを持つ DAG に使用されます。
ミラーリング監視ディレクトリと共有は、必要に応じて Exchange によって自動作成されます。
サーバーは Active Directory の DAG オブジェクトに追加されます。
マウントされたデータベースに関する情報で、クラスター データベースが更新されます。
注意
クォーラム モデル変更は、自動的に実行されます。ただし、クォーラム モデルが自動的に適切なモデルに変わらない場合は、DAG 用のクォーラム設定を修正する Identity パラメーターのみを指定して Set-DatabaseAvailabilityGroup コマンドレットを実行します。
DAG のクラスタ名オブジェクトの事前設定
CNO とは、Active Directory で作成され、クラスターの Name リソースと関連付けられているコンピューター アカウントのことです。クラスターの Name リソースは、クラスターの ID として振る舞い、クラスターのセキュリティ コンテキストを供給する Kerberos 対応オブジェクトである CNO に関連付けられます。Exchange 2007 では、この Kerberos 対応マシン アカウントは、ユーザーがタスクを実行するセキュリティ コンテキストを使用してドメイン内で作成されました。これには、ユーザーのアカウントにドメイン内でマシン アカウントを作成して有効にするアクセス許可があるか、コンピューター アカウントが適切に事前設定および準備されている必要がありました。
DAG に最初のメンバーが追加されると、DAG の基本クラスターとそのクラスターの CNO の作成が実行されます。DAG に最初のサーバーが追加されると、Powershell は追加されるメールボックス サーバー上の Microsoft Exchange レプリケーション サービスと通信します。Microsoft Exchange レプリケーション サービスは、フェールオーバー クラスタリング機能をインストールし (まだインストールされていない場合)、クラスター作成処理を開始します。Microsoft Exchange レプリケーション サービスは LOCAL SYSTEM セキュリティ コンテキストのもとで実行されます。このコンテキストのもとでクラスター作成が実行されます。
警告
DAG メンバーが Windows Server 2012 を実行している場合は、最初のサーバーを DAG に追加する前に CNO を事前に設定する必要があります。
コンピューター アカウントの作成が制限されているか、コンピューター アカウントが既定のコンピューター コンテナーではないコンテナーに作成される環境では、CNO の事前設定と準備が可能です。CNO のコンピューター アカウントを作成して無効にし、以下の作業のいずれかを実行します。
DAG に追加している最初のメールボックス サーバーのコンピューター アカウントに対して、コンピューター アカウントのフル コントロールを割り当てます。
Exchange Trusted Subsystem USG にコンピューター アカウントのフル コントロールを割り当てます。
DAG に追加する最初のメールボックス サーバーのコンピューター アカウントにコンピューター アカウントのフル コントロールを割り当てることで、LOCAL SYSTEM セキュリティ コンテキストが事前設定されたコンピューター アカウントを管理できるようになります。代わりに、Exchange Trusted Subsystem USG にコンピューター アカウントのフル コントロールを割り当てることもできます。Exchange Trusted Subsystem USG には、ドメイン内のすべての Exchange サーバーのマシン アカウントが含まれるためです。
DAG の CNO の事前設定と準備の詳細な手順については、「データベース可用性グループ用のクラスター名オブジェクトの事前設定」を参照してください。
DAG からのサーバーの削除
メールボックス サーバーを DAG から削除するには、EMC 内のデータベース可用性グループの管理ウィザードを使用するか、シェル内の Remove-DatabaseAvailabilityGroupServer コマンドレットを使用します。メールボックス サーバーを DAG から削除するためには、レプリケートされたすべてのメールボックス データベースを最初にサーバーから削除する必要があります。レプリケートされたメールボックス データベースと共にメールボックス サーバーを DAG から削除しようとすると、タスクが失敗します。
特定の操作を実行する前にメールボックス サーバーを DAG から削除しなくてはならないシナリオがあります。これらのシナリオには、次のものがあります。
サーバーの回復操作の実行 DAG のメンバーであるメールボックス サーバーが失われたか障害になって回復不能であり、交換を必要とする場合は、Setup /m:RecoverServer スイッチを使用してサーバー回復操作を実行できます。ただし、回復操作を実行するためには、まず ConfigurationOnly パラメーターを指定して Remove-DatabaseAvailabilityGroupServer コマンドレットを使用することによって DAG からサーバーを削除する必要があります。
データベース可用性の削除 DAG を削除しなければならない場合があります (例: サードパーティ レプリケーション モードを無効化する場合)。DAG を削除しなければならない場合、まず DAG からすべてのサーバーを削除する必要があります。1 つまたは複数のメンバーを含む DAG を削除しようとすると、タスクが失敗します。
ページのトップへ
DAG プロパティの構成
サーバーを DAG に追加した後に、EMC またはシェルを使用することによって、DAG で使用されるミラーリング監視サーバーおよび監視ディレクトリ、DAG に割り当てられる IP アドレスなどの DAG プロパティを構成できます。
構成可能なプロパティは、次のとおりです。
監視サーバー ファイル共有監視のファイル共有をホストするサーバーの名前です。DAG 外部にあるハブ トランスポート サーバーをミラーリング監視サーバーとして指定することをお勧めします。これにより、必要に応じて共有を自動的に構成、セキュリティ保護、および使用することができます。
監視ディレクトリ ファイル共有監視データを格納するのに使用するディレクトリの名前です。このディレクトリは、指定されたミラーリング監視サーバー上で自動的に作成されます。
データベース可用性グループ IP アドレス DAG に割り当てられた 1 つまたは複数の IP アドレスです。これらのアドレスは、手動で割り当てられた静的 IP アドレスを使用して構成することも、組織内の DHCP サーバーを使用して DAG に自動で割り当てることも可能です。
シェルを使用すると、DAG IP アドレス、ネットワークの暗号化と圧縮の設定、ネットワーク検出、レプリケーションに使用する TCP ポート、および代替ミラーリング監視サーバーとミラーリング監視ディレクトリの設定など、EMC 内で使用できない DAG プロパティを構成して、データセンター ライセンス認証調整モードを有効にすることができます。
DAG プロパティを構成する方法の詳細な手順については、「データベース可用性グループのプロパティの構成」を参照してください。
DAG ネットワーク暗号化
DAG は、Windows Server オペレーティング システムの暗号化機能を活用することによって、暗号化の使用をサポートします。DAG は Exchange サーバー間に Kerberos 認証を使用します。Microsoft Kerberos セキュリティ サポート プロバイダー (SSP) EncryptMessage および DecryptMessage API は、DAG ネットワーク トラフィックの暗号化を処理します。Microsoft Kerberos SSP は、複数の暗号化アルゴリズムをサポートします (完全な一覧については、「Kerberos プロトコル拡張機能」のセクション 3.1.5.2「暗号化タイプ」を参照してください)。Kerberos 認証ハンドシェイクは、リスト内でサポートされている最も強力な暗号化プロトコルを選択します。通常は、Advanced Encryption Standard (AES) 256 ビットであり、場合によってはデータの整合性を保持するために SHA ハッシュ ベースのメッセージ認証コード (HMAC) を使用します。詳細については、「HMAC」を参照してください。
ネットワーク暗号化は、DAG ネットワークではなく DAG のプロパティです。DAG ネットワーク暗号化を構成するには、シェル内の Set-DatabaseAvailabilityGroup コマンドレットを使用します。DAG ネットワーク通信に使用可能な暗号化設定を次の表に示します。
DAG ネットワーク通信暗号化の設定
| 設定 | 説明 |
|---|---|
無効 |
ネットワーク暗号化が使用されません。 |
有効 |
ネットワーク暗号化がすべての DAG ネットワーク上でレプリケーションおよびシード処理に使用されます。 |
InterSubnetOnly |
ネットワーク暗号化が別々のサブネット間でレプリケートするときに DAG ネットワーク上で使用されます。これは既定の設定です。 |
SeedOnly |
ネットワーク暗号化がシード処理専用ですべての DAG ネットワーク上で使用されます。 |
DAG ネットワーク圧縮
DAG は組み込みの圧縮をサポートします。圧縮が有効な場合、DAG ネットワーク通信では XPRESS が使用されます。これは、LZ77 アルゴリズムの Microsoft 実装です。詳細については、「デフレート アルゴリズムの説明」および「ワイヤー形式プロトコル仕様」のセクション 3.1.7.2「圧縮アルゴリズム」を参照してください。これは、多数の Microsoft プロトコルで使用される圧縮 (特に Microsoft Outlook と Exchange 間の MAPI RPC 圧縮) と同じタイプです。
ネットワーク暗号化と同様に、ネットワーク圧縮も DAG ネットワークではなく DAG のプロパティです。シェル内で Set-DatabaseAvailabilityGroup コマンドレットを使用することによって、DAG ネットワーク圧縮を構成します。DAG ネットワーク通信に使用可能な圧縮設定を次の表に示します。
DAG ネットワーク通信圧縮設定
| 設定 | 説明 |
|---|---|
無効 |
ネットワーク圧縮が使用されません。 |
有効 |
ネットワーク圧縮がすべての DAG ネットワーク上でレプリケーションおよびシード処理に使用されます。 |
InterSubnetOnly |
ネットワーク圧縮が別々のサブネット間でレプリケートするときに DAG ネットワーク上で使用されます。これは既定の設定です。 |
SeedOnly |
ネットワーク圧縮がシード処理専用ですべての DAG ネットワーク上で使用されます。 |
ページのトップへ
DAG ネットワーク
DAG ネットワークは、レプリケーション トラフィックまたは MAPI トラフィックのいずれかに使用する 1 つまたは複数のサブネットの集合です。DAG ごとに、最大 1 つの MAPI ネットワークと 0 または 1 つ以上のレプリケーション ネットワークが含まれます。単一ネットワーク アダプター構成の場合、そのネットワークは MAPI とレプリケーション トラフィックの両方で使用されます。単一ネットワーク アダプターおよびパスがサポートされていますが、各 DAG は最小 2 つの DAG ネットワークを持つことを推奨します。2 つのネットワーク構成で、1 つのネットワークは通常、レプリケーション トラフィック専用であり、その他のネットワークは主に MAPI トラフィック用に使用されます。各 DAG メンバーにネットワーク アダプターを追加して、追加の DAG ネットワークをレプリケーション ネットワークとして構成することも可能です。
注意
複数のレプリケーション ネットワークを使用する場合、ネットワーク使用の優先順位を指定する方法はありません。Exchange はログ配布に使用するレプリケーション ネットワークのグループからレプリケーション ネットワークをランダムに選択します。
DAG ネットワークを作成するには、EMC 内でデータベース可用性グループ ネットワークの新規作成ウィザードを使用するか、シェル内でNew-DatabaseAvailabilityGroupNetwork コマンドレットを使用します。DAG ネットワークを作成する方法の詳細については、「データベース可用性グループのネットワークの作成」を参照してください。
DAG ネットワーク プロパティを構成するには、EMC 内で DAG ネットワークの [プロパティ] ダイアログ ボックスを使用するか、シェル内で Set-DatabaseAvailabilityGroupNetwork コマンドレットを使用します。DAG ネットワーク プロパティを構成する方法の詳細な手順については、「データベース可用性グループ ネットワークのプロパティの構成」を参照してください。各 DAG ネットワークには、次に示す構成対象の必須および省略可能のパラメーターがあります。
ネットワーク名 128 文字以内の DAG ネットワークの固有の名前です。
ネットワークの説明 256 文字以内の DAG ネットワークの省略可能な説明です。
ネットワーク サブネット IP アドレス/ビットマスクの形式 (Internet Protocol version 4 (IPv4) サブネットでは 192.168.1.0/24、Internet Protocol version 6 (IPv6) サブネットでは 2001:DB8:0:C000::/64 など) を使用して入力された 1 つまたは複数のサブネットです。
レプリケーションを有効にする EMC でチェック ボックスを選択し、DAG ネットワークをレプリケーション トラフィック専用にして、MAPI トラフィックをブロックします。レプリケーションで DAG ネットワークを使用できないようにし、MAPI トラフィックを有効にするために、このチェック ボックスをオフにします。シェル内で、Set-DatabaseAvailabilityGroupNetwork コマンドレットの ReplicationEnabled パラメーターを使用して、レプリケーションを有効化または無効化します。
注意
MAPI ネットワーク上でレプリケーションを無効にしても、その MAPI ネットワークをレプリケーション用に使用しないことは保証されません。構成されたすべてのレプリケーション ネットワークがオフラインになるか、それらに障害が発生した場合 (または他の原因で使用不可能になった場合)、レプリケーションが無効に設定されている MAPI ネットワークのみが残っていると、システムではその MAPI ネットワークがレプリケーションに使用されます。
システムによって作成される最初の DAG ネットワーク (DAGNetwork01 や DAGNetwork02 など) は、クラスター サービスによって列挙されるサブネットに基づきます。各 DAG メンバーは、同じ数のネットワーク アダプターを保持する必要があり、各ネットワーク アダプターは、一意のサブネット上で IPv4 アドレス (およびオプションで IPv6 アドレス) を保持する必要があります。複数の DAG メンバーに同じサブネット上の複数の IPv4 アドレスを割り当てることが可能ですが、特定の DAG メンバーにおけるネットワーク アダプターと IP アドレスの各ペアは、一意のサブネット上に存在する必要があります。また、MAPI ネットワークに使用されるアダプターのみをデフォルト ゲートウェイで構成する必要があります。レプリケーション ネットワークは、デフォルト ゲートウェイで構成しないでください。
たとえば、各メンバーが 2 つのネットワーク アダプター (1 つが MAPI ネットワーク専用で、もう 1 つがレプリケーション ネットワーク専用) を保持する 2 メンバーの DAG である、DAG1 があるとします。次の表に、IP アドレス構成設定の例を示します。
ネットワーク アダプター設定の例
| サーバー-ネットワーク アダプター | IP アドレス/サブネット マスク | デフォルト ゲートウェイ |
|---|---|---|
EX1-MAPI |
192.168.1.15/24 |
192.168.1.1 |
EX1-レプリケーション |
10.0.0.15/24 |
該当なし |
EX2-MAPI |
192.168.1.16 |
192.168.1.1 |
EX2-レプリケーション |
10.0.0.16 |
該当なし |
以下の構成では、DAG で構成された 2 つのサブネットが存在します。つまり、192.168.1.0 と 10.0.0.0 です。EX1 と EX2 が DAG に追加されると、2 つのサブネットが列挙され、2 つの DAG ネットワークが作成されます。つまり、DAGNetwork01 (192.168.1.0) と DAGNetwork02 (10.0.0.0) です。これらのネットワークは、次の表のように構成されます。
単一サブネットの DAG で列挙される DAG ネットワーク設定
| 名前 | サブネット | インターフェイス | MAPI アクセスが有効 | レプリケーションが有効 |
|---|---|---|---|---|
DAGNetwork01 |
192.168.1.0/24 |
EX1 (192.168.1.15) EX2 (192.168.1.16) |
True |
True |
DAGNetwork02 |
10.0.0.0/24 |
EX1 (10.0.0.15) EX2 (10.0.0.16) |
False |
True |
専用レプリケーション ネットワークとして DAGNetwork02 を構成するには、次のコマンドを実行して DAGNetwork01 のレプリケーションを無効にします。
Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\DAGNetwork01 -ReplicationEnabled:$false
DAGNetwork01 のレプリケーションが無効になると、Microsoft Exchange レプリケーション サービスでは、連続レプリケーション用に DAGNetwork02 が使用されます。DAGNetwork02 に障害が発生した場合、Microsoft Exchange レプリケーション サービスでは、連続レプリケーション用に再度 DAGNetwork01 が使用されます。この動作は、高可用性を維持するためにシステムによって意図的に行われます。
DAG ネットワークおよび複数サブネット展開
前の例では、異なる 2 つのサブネット (192.168.1.0 と 10.0.0.0) が DAG によって使用されていましたが、各メンバーでは同じサブネットを使用して MAPI ネットワークを構成するため、DAG は単一サブネットの DAG と見なされます。DAG メンバーが MAPI ネットワークで異なるサブネットを使用する場合、その DAG は複数サブネットの DAG と呼ばれます。複数サブネットの DAG では、適切なサブネットを各 DAG ネットワークに関連付けるために、DAG ネットワークの追加構成を実行する必要があります。
たとえば、各メンバーが 2 つのネットワーク アダプター (1 つが MAPI ネットワーク専用で、もう 1 つがレプリケーション ネットワーク専用) を保持する 2 メンバーの DAG である、DAG2 があるとします。ここで、各 DAG メンバーは、その MAPI ネットワークが異なるサブネット上にある別個の Active Directory サイトに存在します。次の表に、IP アドレス構成設定の例を示します。
複数サブネットの DAG のネットワーク アダプター設定の例
| サーバー-ネットワーク アダプター | IP アドレス/サブネット マスク | デフォルト ゲートウェイ |
|---|---|---|
EX1-MAPI |
192.168.0.15/24 |
192.168.0.1 |
EX1-レプリケーション |
10.0.0.15/24 |
該当なし |
EX2-MAPI |
192.168.1.15 |
192.168.1.1 |
EX2-レプリケーション |
10.0.1.15 |
該当なし |
以下の構成では、DAG で構成された 4 つのサブネットが存在します。つまり、192.168.0.0、192.168.1.0、10.0.0.0、および 10.0.1.0 です。EX1 と EX2 が DAG に追加されると、4 つのサブネットが列挙され、2 つの DAG ネットワークが作成されます。つまり、DAGNetwork01 (192.168.0.0)、DAGNetwork02 (10.0.0.0)、DAGNetwork03 (192.168.1.0)、および DAGNetwork04 (10.0.1.0) です。これらのネットワークは、次の表のように構成されます。
複数サブネットの DAG で列挙される DAG ネットワーク設定
| 名前 | サブネット | インターフェイス | MAPI アクセスが有効 | レプリケーションが有効 |
|---|---|---|---|---|
DAGNetwork01 |
192.168.0.0/24 |
EX1 (192.168.0.15) |
True |
True |
DAGNetwork02 |
10.0.0.0/24 |
EX1 (10.0.0.15) |
False |
True |
DAGNetwork03 |
192.168.1.0/24 |
EX2 (192.168.1.15) |
True |
True |
DAGNetwork04 |
10.0.1.0/24 |
EX2 (10.0.1.15) |
False |
True |
必要な構成を完了するには、DAGNetwork03 と DAGNetwork04 をそれぞれ DAGNetwork01 と DAGNetwork02 に組み入れる必要があります。これを行うには、DAGNetwork03 に現在関連付けられているサブネットを DAGNetwork01 に追加し、DAGNetwork04 に現在関連付けられているサブネットを DAGNetwork02 に追加します。この操作によって、DAGNetwork03 と DAGNetwork04 からサブネットの関連付けが削除され、それらは削除可能な空の DAG ネットワークとして残されます。サブネットを 2 つの DAG ネットワークに組み入れ、MAPI ネットワークのレプリケーションを無効にするには、次のコマンドを実行します。
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork01 -Subnets 192.168.0.0,192.168.1.0 -ReplicationEnabled:$false
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -Subnets 10.0.0.0,10.0.1.0
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork03
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork04
DAG ネットワークおよび iSCSI ネットワーク
既定では、DAG はその基になるクラスターによって使用するために検出および構成されるすべてのネットワークの探索を実行します。これには、1 つまたは複数の DAG メンバーに iSCSI ストレージを使用する結果として使用されているインターネット SCSI (iSCSI) ネットワークが含まれます。ベスト プラクティスとして、iSCSI ストレージが専用ネットワークおよびネットワーク アダプターを使用する必要があります。これらのネットワークは、DAG またはそのクラスターによって管理することも、DAG ネットワーク (MAPI またはレプリケーション) として使用することもできません。その代わりに、これらのネットワークでは DAG による使用を手動で無効化する必要があります。そのため、iSCSI ストレージ トラフィック専用にすることができます。iSCSI ネットワークの検出を無効化にして、DAG ネットワークとして使用できないようにするには、次の例のように Set-DatabaseAvailabilityGroupNetwork コマンドレットを使用して、現在検出されている iSCSI ネットワークを無視するように DAG を構成します。
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true
また、このコマンドは、ネットワークがクラスターに使用されないようにします。iSCSI ネットワークは引き続き DAG ネットワークとして表示されますが、上記のコマンドを実行した後は、MAPI またはレプリケーション トラフィックに使用されません。
ページのトップへ
DAG メンバーの構成
DAG のメンバーであるメールボックス サーバーには、以下の説明どおりに構成する必要のある高可用性に固有のいくつかのプロパティがあります。
自動データベース マウント ダイヤル
データベース コピーの自動アクティブ化ポリシー
最大アクティブ データベース
自動データベース マウント ダイヤル
AutoDatabaseMountDial パラメーターには、データベース フェールオーバー後の自動データベース マウント動作を指定します。Set-MailboxServer コマンドレットを使用して、次の任意の値で AutoDatabaseMountDial パラメーターを構成できます。
BestAvailabilityこの値を指定する場合、コピー キューの長さが 12 以下ならばデータベースはフェールオーバー後直ちに自動的にマウントされます。コピー キューの長さは、パッシブ コピーによって認識されるレプリケートが必要なログの数です。コピー キューの長さが 12 を超える場合、データベースは自動的にマウントされません。コピー キューの長さが 12 以下の場合、Exchange は残りのログのパッシブ コピーへのレプリケートを試みてデータベースをマウントします。GoodAvailabilityこの値を指定すると、コピー キューの長さが 6 以下ならばフェールオーバーの直後にデータベースが自動的にマウントされます。コピー キューの長さは、パッシブ コピーによって認識されるレプリケートが必要なログの数です。コピー キューの長さが 6 を超える場合、データベースは自動的にマウントされません。コピー キューの長さが 6 以下の場合、Exchange は残りのログのパッシブ コピーへのレプリケートを試みてデータベースをマウントします。Losslessこの値を指定すると、アクティブ コピーに生成されたすべてのログがパッシブ コピーにコピーされるまで、データベースは自動的にマウントされません。また、この設定によって、アクティブ マネージャーの最適なコピーの選択アルゴリズムでは、コピー キューの長さではなく、データベース コピーのアクティブ化優先順位の値に基づいてアクティブ化の対象候補が並べ替えられます。
既定値は GoodAvailability です。BestAvailability または GoodAvailability を指定したときに、アクティブ コピーのすべてのログを、アクティブ化されたパッシブ コピーにコピーできない場合、一部のメールボックス データが失われる可能性があります。ただし、(既定で有効になっている) トランスポート収集機能を利用すると、トランスポート収集キューにあるメッセージを再送信することで、ほとんどのデータ損失を防止することができます。
前の値に加え、カスタム値で AutoDatabaseMountDial パラメーターを構成するために、ADSI Edit または Ldp.exe を使用して Active Directory の属性を直接変更することもできます。AutoDatabaseMountDial パラメーターは、メールボックス サーバー オブジェクトの msExchDataLossForAutoDatabaseMount 属性によって表されます。この属性の整数値は、手動操作なしでデータベースをマウントするために失ってもかまわないトランザクション ログ ファイルの最大数を表します。12 を超えるカスタム値で AutoDatabaseMountDial パラメーターを構成する場合、より多くのログが失われた場合の保護を強化するために、トランスポート収集のサイズも増やすことをお勧めします。
例: 自動データベース マウント ダイヤルの構成
次の例では、GoodAvailability の AutoDatabaseMountDial 設定でメールボックス サーバーを構成します。
Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability
データベース コピーの自動アクティブ化ポリシー
DatabaseCopyAutoActivationPolicy パラメーターには、選択されているメールボックス サーバー上のメールボックス データベース コピーに対して可能な自動アクティブ化の種類を指定します。Set-MailboxServer コマンドレットを使用して、次の任意の値で DatabaseCopyAutoActivationPolicy パラメーターを構成できます。
Blockedこの値を指定すると、データベースは、選択されたメールボックス サーバーで自動的にアクティブ化されません。IntrasiteOnlyこの値を指定すると、データベース コピーは、同じ Active Directory サイト内のサーバー上でアクティブ化できます。これは、クロスサイト フェールオーバーまたはアクティブ化を防ぎます。このプロパティは受信メールボックス データベース コピーが対象です (たとえば、パッシブ コピーのアクティブ コピー化)。別の Active Directory サイトでアクティブなデータベース コピーについては、このメールボックス サーバーではデータベースをアクティブ化できません。Unrestrictedこの値を指定すると、選択されているメールボックス サーバーでのメールボックス データベース コピーのアクティブ化に特別な制限がなくなります。
例: データベース コピーの自動アクティブ化ポリシーの構成
次の例では、Blocked の DatabaseCopyAutoActivationPolicy 設定でメールボックス サーバーを構成します。
Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked
最大アクティブ データベース
MaximumActiveDatabases パラメーター (これも Set-MailboxServer コマンドレットで使用される) には、メールボックス サーバーにマウントできるデータベースの数を指定します。個々のメールボックス サーバーに過剰な負荷がかからないようにして、展開に関する要件を満たすようにメールボックス サーバーを構成できます。
MaximumActiveDatabases パラメーターは、整数値で構成します。最大数に達したとき、フェールオーバーまたは切り替え操作が発生した場合はサーバー上のデータベース コピーはアクティブ化されません。コピーがサーバー上で既にアクティブな場合は、サーバーはデータベースのマウントを許可しません。
例: 最大アクティブ データベースの構成
次の例では、最大 20 のアクティブ データベースをサポートするようにメールボックス サーバーを構成します。
Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20
ページのトップへ
DAG メンバーに対するメンテナンスの実行
DAG メンバーに対して任意の種類のソフトウェアまたはハードウェアのメンテナンスを実行する前に、まず StartDagServerMaintenance.ps1 スクリプトを使用してサービスから DAG メンバーを削除する必要があります。このスクリプトによって、すべてのアクティブなデータベースがサーバーから移動されると同時に、そのサーバーへのアクティブなデータベースの移動がブロックされます。また、このスクリプトによって、サーバー上に存在する重要なすべての DAG サポート機能 (たとえば、プライマリ アクティブ マネージャー (PAM) の役割) が別のサーバーに移動され、それらの機能のサーバーへの復帰がブロックされます。StartDagServerMaintenance.ps1 スクリプトは、具体的には以下の作業を実行します。
ActivationOnly パラメーターを指定して Suspend-MailboxDatabaseCopy を実行し、DAG メンバー上でホストされている各データベース コピーのアクティブ化を中断します。
クラスターのノードを一時停止して、ノードの PAM を抑止し、再度 PAM になることを防ぎます。
DAG メンバーの DatabaseCopyAutoActivationPolicy パラメーターの値を
Blockedに設定します。DAG メンバーで現在ホストされているすべてのアクティブなデータベースを他の DAG メンバーに移動します。
DAG メンバーが既定のクラスター グループを現在所有している場合、その既定のクラスター グループ (および PAM の役割) は、スクリプトによって別の DAG メンバーに移動されます。
前の作業のいずれかが失敗すると、成功したデータベース移動操作を除くすべての操作が元に戻されます。
メンテナンスが完了し、DAG メンバーをサービスに戻す準備が整ったら、StopDagServerMaintenance.ps1 スクリプトを使用してその DAG メンバーのメンテナンス モードを解除し、運用を再開できます。StopDagServerMaintenance.ps1 スクリプトは、具体的には以下の作業を実行します。
DAG メンバーでホストされているデータベース コピーごとに Resume-MailboxDatabaseCopy コマンドレットを実行します。
クラスターのノードを再開し、DAG メンバーのすべてのクラスター機能を有効にします。
DAG メンバーの DatabaseCopyAutoActivationPolicy パラメーターの値を
Unrestrictedに設定します。
どちらのスクリプトでも、-ServerName パラメーター (DAG メンバーのホスト名または完全修飾ドメイン名 (FQDN) のいずれかを指定可能) および -WhatIf パラメーターを使用できます。どちらのスクリプトもローカルまたはリモートで実行できます。スクリプトを実行するサーバーには、Windows フェールオーバー クラスター管理ツール (RSAT-Clustering) がインストールされている必要があります。
ページのトップへ
DAG メンバーのシャットダウン
Exchange 2010 高可用性ソリューションは、Windows シャットダウン プロセスに統合されます。1 つまたは複数の DAG メンバーにレプリケートされたマウント済みデータベースがある DAG 内で Windows サーバーのシャットダウンを管理者またはアプリケーションが開始すると、システムではシャットダウン プロセスの完了を許可する前に、マウント済みデータベースの別のコピーをアクティブ化しようとします。
ただし、この新しい動作はシャットダウンされているサーバー上のすべてのデータベースで lossless アクティブ化が発生することを保証するものではありません。そのため、サーバー切り替えを実行してから、DAG のメンバーであるサーバーをシャットダウンすることをお勧めします。サーバー切り替えを実行する方法の詳細な手順については、「サーバー切り替えを実行する」を参照してください。
ページのトップへ
DAG メンバーに対する更新プログラムのロールアップのインストール
データベース可用性グループ (DAG) のメンバーであるサーバー上に Microsoft Exchange Server 2010 更新プログラムのロールアップをインストールすることは、比較的単純な手順です。DAG のメンバーであるサーバー上に更新プログラムのロールアップをインストールすると、すべての Exchange サービスとクラスター サービスなどいくつかのサービスがインストール時に停止します。DAG メンバーに更新プログラムのロールアップを適用する一般的な手順は、次のとおりです。
StartDagServerMaintenance.ps1 スクリプトを使用して DAG メンバーをメンテナンス モードに移行します。
更新プログラムのロールアップをインストールします。
StopDagServerMaintenance.ps1 スクリプトを使用して DAG メンバーのメンテナンス モードを解除し、運用状態に戻します。
RedistributeActiveDatabases.ps1 スクリプトを使用して DAG 間でアクティブなデータベース コピーを再バランス調整します。
「Microsoft Download Center」から Exchange 2010 の最新更新プログラムのロールアップをダウンロードできます。DAG メンバーに更新プログラムのロールアップをインストールする方法の詳細な手順については、「データベース可用性グループ メンバーに更新プログラムのロールアップをインストールする」を参照してください。
ページのトップへ
© 2010 Microsoft Corporation.All rights reserved.