こんにちは。Windows プラットフォーム サポートの戸田です。

日々のサポート業務の中で、よくお問い合わせを頂く内容についてご紹介します。

メンテナンス等で DC (Domain Controller) を停止する場合、クラスターはどうなるの? というお問い合わせを頂くことがあります。

フェールオーバー クラスターの動作要件の 1 つとして AD (Active Directory) ドメインへの参加があります。

フェールオーバー クラスターの要件について
http://technet.microsoft.com/ja-jp/library/cc771404.aspx

Windows Server 2003 以前ではクラスター サービスの起動アカウントはドメイン アカウントとして構成されており、Windows Server 2008 以降のクラスターではクラスターのコンピュータ オブジェクト (CNO = Cluster Name Objectと呼ばれます) が作成されるなど、その認証は AD 環境に依存しています。そのため、DC が不在となる場合、(当然のことながら) ドメイン認証が失敗することとなります。

クラスタ サービス アカウントを手動で再作成する方法
http://support.microsoft.com/kb/269229/ja

Windows Server 2008 フェールオーバー クラスターのセキュリティ モデルの説明
http://support.microsoft.com/kb/947049/ja

フェールオーバー クラスター ステップ バイ ステップ ガイド: Active Directory のアカウントの構成
http://technet.microsoft.com/ja-jp/library/cc731002(v=ws.10).aspx

クラスター上における認証発生のタイミングはクラスター サービスの起動既存のクラスターに参加する場合や、ノード間の同期処理などがあります。
また DC への認証はクラスター自身の動作だけでは無く、クライアントからの仮想サーバーへのアクセスや、クラスター上で動作するサービス、アプリケーションによって行われることもあるため一概にどのタイミングで、とは言えません (ライブ マイグレーション環境の CSV はノード間で SMB による共有を行っており、その 共有のための認証として DC への問い合わせが発生します)。

弊社に頂くお問い合わせでは、クラスター上の操作、動作が無い場合として「(数時間の停止では)問題が無かった」、「DC を再起動したところ、フェールオーバーが発生した」などの事象が報告されており、実際には環境やタイミングによってその影響の有無があるようです。具体的なところではドメイン コントローラー停止中のフェールオーバー動作にてイベント 1207 が記録され、ネットワーク名リソースのオンラインに失敗するとの報告もありました。

Event ID 1207 - Active Directory Permissions for Cluster Accounts
http://technet.microsoft.com/en-us/library/cc773451(v=ws.10).aspx

いくつかの例を挙げましたが、結論としては動作要件を満たさない状況での正常動作については保証されないことになります。もしメンテナンス等で AD 内の DC が不在となるような場合には、安全策として事前にクラスターを停止することについてご検討をお願いします。

# 2012/12/7  Windows Server 2008 R2 環境の KB2525380 の情報を追記しました。

こんにちは。Windows プラットフォーム サポートの戸田です。

今回は Windows Server 2008 以降の WSFC のクラスター ログについて補足します。

以下の記事のとおり Windows Server 2008 以降の WSFC では、Windows Server 2003 MSCS とはクラスター ログ記録の仕組みが変わっています。

WSFC: クラスタ ログはどこ？
http://blogs.technet.com/b/askcorejp/archive/2009/04/20/windows-server-2008-failover-clustering.aspx

Windows Server 2003 MSCS までは各ノード上のクラスター サービスが %SystemRoot%\Cluster\Cluster.log (規定値) へ直接テキスト ファイルで出力していましたが、Windows Server 2008 以降のクラスター ログの記録は Event Tracing for Windows (ETW) を使用するようになり、全てのクラスター 関連 ログは "Microsoft-Windows-FailoverClustering" という名前のプロバイダを介して行われています。

 Microsoft Cluster Server のクラスタ ログ機能を有効にする方法
 http://support.microsoft.com/kb/168801/ja

 [MSDN] Event Tracing
 http://msdn.microsoft.com/en-us/library/bb968803(VS.85).aspx

ここで出力されるログ ファイルは etl 形式のバイナリ ログ ファイルとなり、%SystemRoot%\System32\winevt\logs 以下に 3 世代分が保存されています。 以下の説明では .etl ファイルと記述します。 (以下は Windows Server 2008 R2 の表示例です。拡張子は .001 などの数字になっています)。

この .etl ファイルは循環ログと定義されており、ログ記録量があらかじめ設定された上限を超えると、過去のログを上書きして記録を継続します。そのため、クラスター上で問題が発生した場合は可能な限り、速やかにクラスター ログを保存いただくことで問題解決に有効な情報を残すことができる可能性が高くなる点は MSCS と同様です。また 3 つの .etl ファイルは OS の再起動のタイミングで世代が切り替わり、4 回の OS の再起動が行われると一巡して再利用されます。

クラスター ログ サイズを大きく設定するには

クラスター ログのサイズは既定値で 100 MB ですが、これは ETW によって生成される .etl ファイル のサイズですので、Cluster.exe log /g コマンドにてダンプされたテキスト ファイル (Cluster.log) はこれとは異なるファイル サイズとなります。また、保存可能な記録量 (何日分のログか保存されているか) は、クラスターの動作状況 (障害発生時には記録量が多くなります) や構成によって異なる (ノード数やリソース数が多いほど、記録されるログの量は多くなる傾向にあります) 為、実際の環境でご確認を頂く必要があります。現在、ご利用を頂いているクラスター環境で Cluster.log を出力頂き、普段どれくらいの記録が保存されているかについてご確認されることをおすすめいたします (Cluster.log の記録はGMT 時刻で出力されています。 +9 時間することで JST 時刻に読み替えることが出来ます)。

クラスター ログのサイズ変更はコマンド プロンプトから管理者権限で以下のコマンドを実行することで、ログ サイズを拡張することができます。

cluster /prop ClusterLogSize=<設定サイズ(MB)>

例：300 MB にする場合
cluster /prop ClusterLogSize=300

このコマンドは 1 台のノードで実行することにより、クラスター全体に反映されます。また、現在の値は「cluster /prop」のコマンドで ClusterLogSize の値を確認出来ます。

クラスター ログの記録が抜ける?

Cluster.exe log /g コマンドでテキスト形式にダンプされた Cluster.log はこれら 3 世代の .etl ファイルをマージして出力したものとなります。このとき .etl ファイル内で循環によって上書きされてしまったログ記録は既に存在しないため、出力された (3世代分の) Cluster.log には空白の期間がある様に見えます。

具体例としては、以下のようなイメージになります。
ここでは説明をシンプルにするために、1 月から 12 月までの間に OS 再起動を 3 回 ( 1 月、3 月末、7 月末) 行った場合の例として、各 .etl ファイルの世代が切り替わる状況と長期間のログが保存される .etl ファイルでは循環が行われた状況を考えます。

•  1 世代目の .etl ファイル : 1 月～ 3 月まで使用されています｡
• この間、ログの循環は発生しなかったものとします。
• 1 月 ～ 3 月 までの記録が残されています｡
•  2 世代目の .etl ファイル : 4 月～ 7 月まで使用されています｡
• この間、ログが循環し 4 月分のログは上書きされて消えてしまいました。
• 5 月 ～ 7 月 までの記録が残されています｡
•  3 世代目の .etl ファイル : 8 月～ 12 月まで使用されています。
• この間、ログが循環し 8 月分のログは上書きされて消えてしまいました。
•  9 月 ～ 12 月 までの記録が残されています｡

これらの .etl データをマージして、テキスト形式のクラスター ログをダンプすると、 1 月～ 3 月、 5 月～ 7 月、 9 月～ 12 月の記録が残され、4 月、8 月の記録のない Cluster.log が出力されることになります。

クラスター ログに関する不具合について

クラスター ログはデバッグ ログとしての色合いが強く、その記録に対する解説や解析方法について公開情報は殆ど無いため、通��あまりログを目にされることはないかもしれませんが、クラスター ログ内の日本語文字列が表示されない問題が報告されています。Windows Server 2008 SP1、SP2 環境では 977432 で、Windows Server 2008 R2 環境では SP1 適用によって改善されます。

Double-byte character set (DBCS) characters are not written to the cluster log on a computer that is running a localized version of Windows Server 2008
http://support.microsoft.com/kb/977432/en-us

また、ログ時刻がずれて記録される問題が報告されています。

The time stamps in the Cluster log are less accurate compared to the system time that is used for events on a failover cluster node that is running a non-English version of Windows Server 2008
http://support.microsoft.com/kb/975665/en-us

Windows Server 2008 と Windows Server 2008 R2 環境ではクラスター ログの出力時にメモリ不足のエラーが出力されることがあります。これは ETW ログをテキストに変換する際に使用する作業用バッファを必要以上に確保しようとするため、メモリ不足が発生しログの生成が失敗する問題となります。
クラスター ログ サイズの拡張を行っており、大量のメモリを確保するミドルウェアが動作する環境で発生しやすいとの報告があります。

Windows Server 2008 環境の問題
You receive the "out of memory" error message when you try to export to circular files in Windows Server 2008 or in Windows Vista 
http://support.microsoft.com/kb/2257986/en-us

Windows Server 2008 R2 環境の問題
"Out of memory" error when you export to circular files in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2525380/en-us

状況や必要に応じて上記修正についての適用をご検討いただければと思います。

こんにちは。 Windows テクノロジー サポートの松田です。
 
Windows サーバーに配置しているバッチ ファイルなどを UNIX 系のシステムから起動したいというご要望をいただく場合があります。そのため、今回の記事では、UNIX 系のシステムから RSH コマンドを利用して Windows に接続する方法について紹介しようと思います。

Windows Server 2003 R2 より前には、RSH コマンドを利用した接続には Services for UNIX (SFU) に含まれるリモート シェル サービスが使用されていましたが、Windows Server 2003 R2 以降のオペレーティング システム上では、SFU は利用できないため、RSH コマンドによる接続に、Subsystem for UNIX-based Application (SUA) に含まれているリモート シェル デーモンを使用する必要があります。

以下の Technet の記事にて Windows Server 2003 R2 や、Windows Server 2008 でのリモート シェル デーモンを利用した RSH サーバーの設定方法についての詳細な手順が記載されています。

Subsystem for UNIX-based Application (SUA) を利用した、rsh サーバーの設定について (2003 R2)
http://technet.microsoft.com/ja-jp/windowsserver/ff576026

Subsystem for UNIX-based Application (SUA) を利用した、rsh サーバーの設定について (2008)
http://technet.microsoft.com/ja-jp/windowsserver/ff706484

[注意]
上記の記事に記載されている regpwd コマンドは、Administrator 以外で実行すると、"Operation not permitted" のエラーが発生する場合があります。
その場合には、以下の手順にて regpwd コマンドのアクセス権を再設定して再度試してみてください。

1. コマンドプロンプト上で、%systemroot%\SUA\common\setup にて以下のコマンドを実行し、setuid を有効にしてからコンピュータを再起動します。
   > regini enablesetuid.ini
※ 本手順はすでに setuid が有効な場合には飛ばしてください。
2. 再起動後、Administrator でログオンします。
3. SUA のシェルから、以下のコマンドにより regpwd のアクセス権を変更します。
   % chmod 4775 /bin/regpwd
4. 手順 3 を実行後、regpwd のアクセス権が "-rwsrwxr-x" となることを確認します。
   % ls -l /bin/regpwd
   -rwsrwxr-x 1 Administrator +Administrators 99328 1月 6 2006 /bin/regpwd
5. su コマンドを利用し、パスワード情報を保存するユーザーに切り替わります。
   % su <targetUser>
6. regpwd コマンドを実行し、該当ユーザーのパスワード情報を更新します。
   $ regpwd
   This program will save a password for user <targetUser>
   For use by privileged deamons and services like rlogind and cron.
   Enter your current password:
7. setuid を無効化する場合には、コマンドプロンプト上で %systemroot%\SUA\common\setup
   にて以下のコマンドを実行し、システムの再起動を行ないます。
   > regini disablesetuid.ini

Windows Server 2008 R2 や Windows 7 では、Windows Server 2008 と同様の手順で設定が可能ですが、スタート メニューに表示されるダウンロード先は、既定で Windows Server 2008 / Windows Vista 用のユーティリティのダウンロードページに誘導されます。

Windows Server 2008 R2 / Windows 7 用のユーティリティは以下のページからダウンロードできますので、インストール時にはこちらをご利用ください。

Utilities and SDK for Subsystem for UNIX-based Applications in Microsoft Windows 7 and Windows Server 2008 R2
http://www.microsoft.com/en-us/download/details.aspx?id=2391

また、Windows を RSH クライアントとして利用する場合にはいくつかの既知の問題が報告されています。以下の Technet の記事に RSH クライアントして利用する際の既知の問題が記載されてます。

Subsystem for UNIX-based Application (SUA) を利用した、rsh コマンドの実行について
http://technet.microsoft.com/ja-jp/windowsserver/gg486885