SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Windows Server 2016 のワークグループクラスターの構築時の考慮点

leave a comment

Tech Summit のフォローアップに近いものですが。

Windows Server 2016 では、ワークグループ環境やマルチドメインサーバーの環境を使用してクラスターが構築できるようになっています。

公式な情報については、What’s new in Failover Clustering in Windows Server 2016 に書かれているのですが、この中には詳細は記載されておらず、 Workgroup and Multi-domain clusters in Windows Server 2016 が TP 段階のものですが、詳細になるかと思います。

今回の Tech Summit のデモでは、ワークグループクラスターの環境を使用していたのですが、実運用でワークグループクラスターを使用する場合、いくつかの考慮点が出てくるかと思いますので、現状把握できている考慮点を軽くまとめてみたいと思います。


クォーラムの構成


セッション内でもお話しさせていただいたのですが、これが一番重要となってくるかと思います。
ワークグループやマルチドメインクラスターで、現状サポートされていると言われているクォーラムの構成は、
  • クラウド監視
  • ディスク監視

の 2 種類となっており、ファイル共有やノードについてはサポートされていると明記されているドキュメントが存在していません。

冒頭で紹介した詳細情報のブログでは、以下のように記載されています。

Quorum Configuration

The witness type recommended for Workgroup clusters and Multi-domain clusters is a Cloud Witness or Disk Witness.  File Share Witness (FSW) is not supported with a Workgroup or Multi-domain cluster.

ノードに関しては記載されていないのですが、ファイル共有監視についてはサポートがされていないと記載されています。

デモ環境は Azure 上に構築していたため、クラウド監視を使用していたのですが、Azure にアクセスができない環境では、ディスク監視を使う必要が出てくるかと思います。
DB サーバーの場合、セグメントとしてインターネットに接続できないケースが多いですので。

これについては、iSCSI ターゲットをどこかに構築し、そこからディスクを切り出してディスク監視を設定する必要がありますが、ワークグループクラスターを構築するたびに、新しい iSCSI のターゲットのサーバーを構築するのは非効率です。

そのため、「ワークグループクラスターを構築する際の共有設備としての iSCSI ターゲット」の構築を最初に考慮する必要があると考えています。

クォーラムの構成については、ワークグループクラスターを構築するたびに設定が発生するものになりますので、構築の都度どうするかを考えるのはもったいないですので。

非サポートとなり、今後もサポートされないと思いますが、一応ワークグループクラスターでもファイル共有監視自体は設定することはできます。
Windows Server 2008 以降の「Cluster Service」は「Local System」で動作するようになっています。
そのため、「Local System」でアクセスができる共有フォルダーであれば、ファイル共有監視の共有として使用することができます。

この設定を実施するための仕掛けですが、「Local System」の資格情報として、ファイル共有監視で使用する共有フォルダーへの接続情報を設定しています。

設定の方法はいろいろとあるかと思いますが、私の場合は以下を組み合わせています。

PSExec は Sysinternals のツールとなりますが、Local System アカウントでコマンドを実行することができますので、このツール経由で資格情報マネージャーを操作して登録を行っています。

今回は、10.140.0.11 の IP のサーバーに共有フォルダーを作っているのですが、その場合は以下のようなコマンドになるかと。

# 資格情報の登録
C:\Scripts\PsExec.exe -accepteula -s cmd.exe "/c PowerShell.exe C:\Scripts\CredMan.ps1 -AddCred -Target 10.140.0.11 -User '<接続ユーザー>' -Pass '<パスワード>' -CredType DOMAIN_PASSWORD -CredPersist ENTERPRISE"
# 資格情報の表示
C:\Scripts\PsExec.exe -accepteula -s cmd.exe "/c PowerShell.exe C:\Scripts\CredMan.ps1 -ShoCred  -CredType DOMAIN_PASSWORD -CredPersist ENTERPRISE"
# 資格情報の削除
C:\Scripts\PsExec.exe -accepteula -s cmd.exe "/c PowerShell.exe C:\Scripts\CredMan.ps1 -DelCred -Target 10.140.0.11 -CredType DOMAIN_PASSWORD -CredPersist ENTERPRISE"

これで、Local System に共有フォルダーへの資格情報が登録されるため、ワークグループクラスターでもファイル共有監視を設定することができるようになります。

サポートされる構成ではないので、検証用途での利用となりますが。

 

名前解決の構成


クォーラムの構成のほかには名前解決の構成を考慮する必要があります。

クラスター間の名前解決を実施する方法として、DNS / hosts があるかと思います。

hosts による名前解決によるワークグループクラスターの構築については、実施することは可能なのですが、サポートされるかが微妙なので、DNS を用意することを前提とした方がよいかと思います。

今までのクラスターでは、AD の DNS を使用するケースが大半だったかと思いますが、ワークグループクラスターの場合、AD は不要となりますので、どの DNS を使用するかを検討する必要があります。

既存の AD の DNS を使用することもできますが、DNS レコードの動的更新の許可については意識しておく必要があります。

AD の DNS のデフォルトの設定では、動的更新は「セキュリティ保護のみ」が設定されているため、ワークグループクラスターの環境から動的更新でレコードを登録することができません。

そのため、動的更新可能なゾーンを作成する / 事前に静的なレコードとして登録しておく等の考慮が必要となってきます。

FailoverClustering のイベント 1579 と 1196 について は一度確認しておいた方がよいかと思いますが、静的な登録のみが可能な DNS を使用している場合は、クラスターのコンピューター名リソースの「DNS 状態」のチェックについて、考慮する必要があります。

NIC の 「この接続のアドレスを DNS に登録する」の設定によって、DNS の動的登録のチェックの制御が行われていたはずですので、静的な登録の場合には、この設定の有効 / 無効については気を付けておく必要があります。

また、Azure の場合、この設定を変更すると、ネットワークが切断されたはずですので、Azure で構築する場合は、動的更新が可能な DNS の準備を検討しておく必要があるかと思います。

imageimage

Tech Summit のデモ環境では、動的更新が可能な DNS を別に構築し、その環境を各インスタンスが参照するように設定していました。

DNS の設定についてはワークグループクラスター共通の話になると思いますので、こちらについてもクォーラムと同様に今後のことも考えて構築をしておいた方がよいかと思います。

ワークグループクラスターは AD が不要でクラスターが構築をすることが可能ですが、いくつかの考慮事項があります。

そのため、一度の構築ではなく、今後ワークグループクラスターを構築することも考えて、最初の構築時には全体的なデザインについても考慮をしておいた方がよいかと思います。

Written by masayuki.ozawa

11月 6th, 2016 at 3:28 pm

Posted in Windows Server

Tagged with

Leave a Reply

*