こんにちは。
Windows プラットフォーム サポートの丸山です。
さて、弊社では最近、Windows 7 および Windows Server 2008 R2 などの環境から、ネットワーク共有プリンターに接続したときの問題に関するお問い合わせを非常にたくさんいただきます。
もちろん、弊社サポートサービスにお問い合わせいただくことで、問題解決のお手伝いをさせていただくことが私の仕事なのですが、今回は、弊社の報告事例をもとに、いくつか実績のある対処策についてご紹介させていただきます。
ネットワーク共有プリンターに接続できない問題が発生した場合の初期対応として、少しでもお力になれれば幸いです。
※2013年12月5日、最新の事例報告などを踏まえ、対処策を加筆、修正しました。
最初の対応策は、弊社で確認された既知の複数の問題における更新プログラムのご案内です。
Windows 7 環境、および Windows Server 2008 R2 環境の印刷機能では、リリース以降、複数の問題が報告され、修正されておりますが、その中でも下記の 3 つの更新プログラムでは、特にお問い合わせの多い問題について、様々な修正が行われております。
このため、まずはこれら 3 つの更新プログラムを問題の発生するクライアント端末、およびプリント サーバーに適用していただき、状況に変化があるかどうかをご確認ください。
マイクロソフト セキュリティ情報 MS13-050 - 重要Windows 印刷スプーラー コンポーネントの脆弱性により、特権が昇格される (2839894)http://technet.microsoft.com/ja-jp/security/bulletin/ms13-050
マイクロソフト セキュリティ情報 MS13-062 - 重要リモート プロシージャ コールの脆弱性により、特権が昇格される (2849470)https://technet.microsoft.com/ja-jp/security/bulletin/ms13-062
Windows 7 および Windows Server 2008 R2 のコア コンポーネントの印刷に関するロールアップ更新プログラムについてhttp://support.microsoft.com/kb/2647753
なお、KB2647753 の更新プログラムは、Windows 7 および Windows Server 2008 R2 専用となります。Windows XP、Windows Server 2003、Windows Vista、Windows Server 2008 環境には適用できませんので、ご注意ください。
ふたつ目は、ネットワーク共有プリンターへの接続時に作成されるキャッシュ情報が影響してしまうという問題への対応策です。
Windows では、ネットワーク共有プリンターへの接続が行われる場合、標準的な印刷設定や、プリンター固有のパラメーターなどを取得するためにプリント サーバーと印刷設定の同期処理が実行され、キャッシュとして保持します。
弊社では、ここで保持されているキャッシュ情報が影響し、ネットワーク共有プリンターが正常に動作しないというお問い合わせをいただくことがございます。
ネットワーク共有プリンターへの接続ができない、印刷ができないといった問題が発生した場合には、以下の手順にてキャッシュ情報の削除をお試しください。
Windows Vista、Windows Server 2008、Windows 7、および Windows Server 2008 R2 環境では、以下の手順にてレジストリ情報の削除を行います。
1. 管理者権限のコマンド プロンプトを起動します。
2. 以下のコマンドを実行して、スプーラー サービスを停止します。
net stop spooler
3. 以下のレジストリ キーを丸ごと削除します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider
※レジストリ キーの削除にて、システムが不安定になることはございませんが、念のため、事前のバックアップを推奨します。
4. 以下のコマンドを実行して、スプーラー サービスを開始します。
net start spooler
5. ネットワーク プリンターへの接続を再度お試しいただき、状況に変化があるかどうかをご確認ください。
なお、およそ200を超えるネットワーク共有プリンターへの接続情報がキャッシュされているような環境では、レジストリーを削除すると、スプーラー サービス再起動後、キャッシュの同期処理のためにスレッド プールを使い切ってしまい、スプーラー サービスが応答しなくなってしまうという問題が確認されています。
多数のネットワーク共有プリンターが登録されているユーザーがログオンする場合には、キャッシュの削除を行う前に、下記サポート技術情報に記載されている、修正プログラムの適用をご検討ください。
The Spoolsv.exe process stops responding when you connect to more than 200 network printers from a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/kb/2697865/en
Windows XP および Windows Server 2003 環境では、以下の手順にてレジストリ情報の削除を行います。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\LanMan Print Services
※レジストリ キーの削除にて���システムが不安定になることはございませんが、念のため、事前のバックアップを推奨します。
みっつ目の対応策は、Windows Vista 以降で導入された、新しい通信プロトコルを使用する場合における問題への対応策でございます。
Windows 7 や Windows Server 2008 R2 を含む、Windows Vista 以降の Windows では、印刷機能において、新たに非同期 RPC を使用した通信を行うように機能追加が行われました。
しかしながら、弊社では非同期 RPC を使用した場合にのみ問題が発生する、というお問い合わせが複数ございますため、お問い合わせの環境で非同期 RPC を無効化することで現象が回避されるかをご確認ください。
非同期 RPC の無効化は、ネットワーク共有プリンターに接続するクライアント端末の設定を変更します。
1. 現象の発生するクライアント コンピューターにログオンします。
2. 管理者権限でレジストリ エディターを起動します。
3. 以下のレジストリ値を設定します。
キー : HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers
名前 : EnabledProtocols
種類 : REG_DWORD
値 : 6
※キーが存在しない場合には作成してください。
※すでに値が存在する場合には、上書きしてください。
4. レジストリ エディターを終了します。
5. コンピューターを再起動します。
このレジストリ設定は、Windows 7 および Windows Server 2008 R2 環境のみで有効な設定ですのでご注意ください。
最後の対応策は、コンピューター起動時にネットワークへの接続が行われていないことにより発生する問題への対応策です。
クライアント端末となる Windows XP、Window Vista および Windows 7 環境では、ログオン時にネットワーク接続が完了していない場合にも、コンピューターに保存されているキャッシュ資格情報をもとに、ドメイン アカウントでのログオンが可能となります。
本設定では、キャッシュ情報を使用してログオンが行われた場合に発生する問題を回避するために、ログオン時に常にネットワークの接続を待ってからログオンが行われるよう、コンピューターの動作を変更いたします。
※ Windows Server 2008 以降を実行するサーバーでは、このポリシー設定は無視され、コンピューターの起動、およびログオン時に常にネットワークを待ちます。
1. コンピューターに管理者権限でログオンし、ローカル グループ ポリシー エディターを起動します。
2. 左側のツリーより、以下の順番で、ツリーを開きます。
[コンピューターの構成] -> [管理用テンプレート] -> [システム] -> [ログオン]
3. 右側のペインより、[コンピューターの起動およびログオンで常にネットワークを待つ] をダブル クリックします。
4. [設定] タブより、[有効] のラジオ ボタンをクリックします。
5. [OK] をクリックし、ウィンドウを閉じます。
6. [ローカル グループ ポリシー エディター] を終了します。
7. コンピューターを再起動します。
これらの対応策を実施しても、すべての問題を解決できるとは限りませんが、自信を持ってお送りできる対応策が並んでおりますので、まずはお試しいただけますと幸いです。
調布では、今年もちらほら雪が降る日を見かけます。まだまだ寒さが続きそうです。
みなさまも、体調管理には十分にお気をつけください。ではまた。
こんにちは。 Windows テクノロジー サポートの江田です。
今回は、 Windows Server 2008 R2 を NFS サーバーとして使用している環境において、公開されているフォルダやファイルの所有者情報やグループ情報を NFS サーバーである Windows 側から変更する方法について紹介したいと思います。
通常、 Windows 側から所有者情報を変更するには、該当のファイルもしくはフォルダのプロパティより、[セキュリティ] -[詳細設定]-[所有者] より変更することが可能です。また、プライマリ グループについては、 NFS クライアントの UNIX (Linux) 側より、 chown コマンドや chgrp コマンドなどで変更することになります。 しかしながら、nfsfile.exe コマンドを使用することで、 Windows 側からプライマリ グループの確認や変更をおこなうことができます！
nfsfile.exe はNFS サーバーを構築すると自動で使用が可能になります。また、 所有者情報も確認や変更をすることができます。
なお、変更するユーザーやグループは、 UID / GID にマッピングしていなくても変更自体は実施できますが、 NFS クライアント側で識別できないユーザーやグループとなりますのでマッピングされている Windows ユーザーをご指定ください。
実際に変更してみましょう。
1) NFS 公開しているディレクトリに移動し現在のファイルの設定を確認します。
c:\>cd c:\nfs-share
c:\nfs-share>nfsfile * '*' の処理を開始します...
W -rwxrwxrwx <0777> W2K8R2SP1-1\Administrator W2K8R2SP1-1\None c:\nfs-share\1
W -rw-r--r-- <0644> W2K8R2SP1-1\Administrator W2K8R2SP1-1\None c:\nfs-share\2
W -rw-r--r-- <0644> W2K8R2SP1-1\Administrator W2K8R2SP1-1\None c:\nfs-share\3
3 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした
2) ファイル 1 の所有者をユーザー test に変更してみましょう。
c:\nfs-share>nfsfile /r wu=test /cw 1 '1' の処理を開始します...
1 個のファイルが正常に処理されました。0 個のファイルを処理できませんでした
3) 変更を確認します。
W -rwxrwxrwx <0777> W2K8R2SP1-1\test W2K8R2SP1-1\None c:\nfs-share\1 W -rw-r--r-- <0644> W2K8R2SP1-1\Administrator W2K8R2SP1-1\None c:\nfs-share\2 W -rw-r--r-- <0644> W2K8R2SP1-1\Administrator W2K8R2SP1-1\None c:\nfs-share\3
4) 次にファイル 1 のプライマリ グループを administrators に変更してみましょう。
c:\nfs-share>nfsfile /r wg=administrators /cw 1 '1' の処理を開始します...
5) 変更を確認します。
W -rwxrwxrwx <0777> W2K8R2SP1-1\test BUILTIN\Administrators c:\nfs-share\1 W -rw-r--r-- <0644> W2K8R2SP1-1\Administrator W2K8R2SP1-1\None c:\nfs-share\2 W -rw-r--r-- <0644> W2K8R2SP1-1\Administrator W2K8R2SP1-1\None c:\nfs-share\3
いかがでしたでしょうか。
今後、 NFS サーバー側での設定や確認が必要な場合にご使用していただければ幸いです。
- nfsfile コマンドの詳細については以下を参照ください。
NFS Account Mapping in Windows Server 2008 R2http://www.microsoft.com/en-us/download/details.aspx?id=14205
- 特定の操作を行うことにより、 nfsfile.exe がクラッシュすることがございますので、あらかじめ以下を適用することを推奨します。
The command prompt crashes in Windows Server 2008 R2 or in Windows Storage Server 2008 R2 when Nfsfile.exe tries to set the GID of a folderhttp://support.microsoft.com/kb/2626968
こんにちは。Windows プラットフォーム サポートの奥原です。
今回は、CD / DVD メディアの書き込み方式の違いと書き込み速度について記載します。
CD / DVD メディアにデータを書き込む方法としては、「ライブ ファイル システム形式」と「マスタ形式」があります。それぞれの特徴は、以下の通りです。
ライブ ファイル システム形式
フロッピー ディスクや USB フラッシュ ドライブと同じように、選択したファイルを即座にコピーできます。書き込んだ��と、新たにファイルをコピーすることも可能です。
マスタ形式
書き込み対象のファイルは、一度、ローカル ディスクの一時領域へコピーされます。すべての書き込み対象ファイルの準備ができた時点で、書き込みを実施しますが、選択されたファイルは、一度に書き込みます。このため、書き込み後、ファイルを追加することはできません。
各形式については、以下の公開情報もございますので、参考にして頂ければと思います。
CD/DVD 形式の選択
http://windows.microsoft.com/ja-JP/windows-vista/Which-CD-or-DVD-format-should-I-use
ディスクの書き込み : よく寄せられる質問
http://windows.microsoft.com/ja-JP/windows-vista/Disc-burning-frequently-asked-questions
各形式には、このような特徴がありますが、書き込み時の処理内容も異なります。
ライブ ファイル システム形式では、ファイルの追記が行えるため、ファイル書き込みの際にファイルの情報を管理している領域を更新しながら書き込みを行います。つまり、1 ファイル追加するごとに、ファイルのデータと管理領域の 2 つに対する書き込みが発生します。
一方、マスタ形式では、ファイルの追記ができないため、ファイルの管理情報を一度構成すれば、更新する必要がありません。このため、複数のファイルを書き込む場合でも管理領域の書き込みは 1 度だけとなります。
このような書き込み処理の違いがあることから、両書き込み方式においてデータの書き込みにかかる所要時間が異なる結果となります。
例えば、ライブ ファイル システム形式とマスタ形式で、同じファイル数のデータを一度に書き込む場合、上記の書き込み処理の違いから、マスタ形式で書き込む方が早くなります。大量のファイルをライブ ファイル システム形式で書き込む場合、書き込みの所要時間が極端に長くなりますので、ご使用状況によって適切な形式を選択して頂ければと思います。
こんにちは。日本マイクロソフトの永野です。
弊社クラスター製品には、リソースの操作時にそのリソースの応答を待ち続けることで、
クラスターの動作が停止することを防ぐため、設定されたタイムアウト期間で応答が
得られなかった場合には、デッドロックのような状態が発生したと判断し、リソースを
再起動する機能が備えられています。
タイムアウト期間は、各リソースの以下のプロパティに格納されています。
DeadlockTimeout : IsAlive や LooksAlive など一般的な操作のタイムアウトに利用
PendingTimeout : オンラインやオフライン時の Pending 状態のタイムアウトに利用
このタイムアウトによるリソース再起動に伴って、Windows Server 2003 では resrcmon.exe が、
Windows Server 2008, Windows Server 2008 R2 では rhs.exe が再起動し、
Windows Server 2008 の場合には、イベント ログに
Microsoft-Windows-FailoverClustering ID:1230 のエラーが記録されます。
Event ID 1230 — Cluster Service Startup
http://technet.microsoft.com/en-us/library/cc773436%28v=ws.10%29.aspx
その際、どういった処理で止まっていたのか確認するため、プロセス ダンプから
調査することが有効ですが、Windows Server 2008 にはプロセス ダンプを出力する
機能がありませんでした。
※ Windows Server 2003 と Windows Server 2008 R2 にはプロセス ダンプを出力する機能があります
2013 年 1 月に Windows Server 2008 でもデッドロック発生時にプロセス ダンプを
出力する機能が実装された rhs.exe が以下の技術情報で公開されました。
Hotfix enables a dump file to be generated when the Rhs.exe process detects a deadlock condition in Windows Server 2008
http://support.microsoft.com/kb/2782761/en-us
こちらを適用していただくことで、Windows Server 2008 R2 と同様に
Windows Error Reporting (WER) の機能を利用して以下のパスに
プロセス ダンプが作成されます。
%LOCALAPPDATA%\Microsoft\Windows\WER\ReportQueue
もし、Microsoft-Windows-FailoverClustering ID:1230 が記録される問題が
発生しているようであれば、前述の技術情報で公開されているモジュールを
適用していただき、プロセス ダンプを採取することをご検討ください。
こんにちは。Windows プラットフォーム サポートの加藤です。本日は Server サービス異常終了時に、クラスターサービスに与える影響と回避策についてお伝えします。
・現象
CSV を使用したHyper-V クラスター環境で、突然 CSV のコーディネーター ノード以外のノードから CSV にアクセスできなくなり、仮想マシンが停止してしまうお問い合わせを多くいただいています。
また、ファイルサーバーをクラスター化している環境では、ファイル サーバー リソースが障害となりフェールオーバーするお問い合わせもいただいております。
これらの現象が発生した際、以下の Server サービスの予期せぬ停止イベントが記録されていることがあります。
システム ログ------------------エラー,Service Control Manager,7031,,Server サービスは予期せぬ原因により終了しました。このサービスの終了は 1 回目です。次の修正操作が 60000 ミリ秒以内に実行されます: サービスの再開。------------------
また、上記の Server サービスの予期せぬ停止イベント以外にも多数のサービスが停止したイベントが記録されます。同時間帯には、アプリケーション ログに以下のようなエラーも記録されます。
アプリケーション ログ例:------------------エラー,Application Error,1000,(100),"障害が発生しているアプリケーション名: svchost.exe_ProfSvc、バージョン: 6.1.7600.16385、タイム スタンプ: 0x4a5bc3c1障害が発生しているモジュール名: wmiprvsd.dll、バージョン: 6.1.7601.17514、タイム スタンプ: 0x4ce7ca79------------------
上記のアプリケーション エラーは、svchost.exe が、何らかの原因でクラッシュしたことを示しています。svchost.exe は、OS内の各種サービスをホストする汎用的なプロセスで、ひとつの svchost.exe で複数のサービスを管理しています。あるサービスの処理において異常が発生すると、svchost.exe 自体がクラッシュし、当該 svchost.exe によって起動されたサービスはすべて停止します。そのため、このクラッシュが Server サービス以外のサービスの問題により発生しても、Server サービスも影響を受けてしまいます。
Server サービスが停止した場合には、CSV を正常に利用することができません。その理由は、CSV のコーディネーターノード以外のノードから、CSV にアクセスする際には、コーディネーターノードとの SMB による通信が必要なためです。Server サービスは、SMB 通信を提供するサービスであり、このサービスが停止すると、非コーディネーターノードから、CSV へのアクセスが一切できなくなります。
また、同様にファイルサーバー リソースも、Server サービスが停止するとアクセスができなくなり、クラスターの正常性チェックで異常が検出され、フェールオーバーが発生します。
根本原因を解決するには、svchost.exe がクラッシュした原因を追究する必要がありますが、原因が特定できるまでの間に現象が再発してしまうと、再び仮想マシンが停止し業務に影響が発生します。そこで、他のサービスの問題で svchost.exe がクラッシュした際に CSV への影響を抑えるために、プロセスを分離する回避策があります。
・ホストプロセスの分離前述のように、svchost.exe は複数のサービスを管理しています。Server サービス以外のサービスの問題が、Server サービスに影響を与えないようにするには、ひとつの svchost.exe で Server サービスを管理するように構成を変更します。これにより、Server サービスは、他のサービスの svchost.exe とは独立するため、他のサービスの問題に起因する svchost.exe のクラッシュの影響を受けなくなります。なお、分離を実施することで svchost.exe プロセスがひとつ増えますが、もともと OS には複数の svchost.exe が存在しており、増えることでシステムに影響を与えることはありません。
- 手順Server (LanmanServer) サービスにおけるホストプロセスの分離について
---------------------------------------------------------(1) コマンド プロンプトから "Tasklist /svc" を実行し、Server (LanmanServer) サービスが含まれている svchost.exe を確認します。
実行例：C:\>Tasklist /svc
イメージ名 PID サービス========================= ======== ============================================System Idle Process 0 N/ASystem 4 N/A：：svchost.exe 1020 AeLookupSvc, Appinfo, AppMgmt, BDESVC, BITS, CertPropSvc, EapHost, gpsvc, hkmsvc, IKEEXT, iphlpsvc, LanmanServer, MMCSS, ProfSvc, Schedule, SENS, ShellHWDetection, Themes, wuauserv：：
(2) コマンドプロンプトから "sc config LanmanServer type= own" を実行します。
実行例：C:\>sc config LanmanServer type= own[SC] ChangeServiceConfig SUCCESS
(3) OS をリブートします。
(4) コマンドプロンプトから "Tasklist /svc" を実行し、LanmanServer サービスが他多数のサービスと分離して、単独のホストプロセスにロードされたことを確認します。
実行例：Tasklist /svc
イメージ名 PID サービス========================= ======== ============================================System Idle Process 0 N/ASystem 4 N/A：：svchost.exe 3136 LanmanServer：：：
以上で分離作業は完了です。
こんにちは。Windows プラット フォーム サポートの高山です。
今回は、Windows 8 / Windows Server 2012 の新機能のひとつ、自動メモリ ダンプについてご紹介いたします。
自動メモリ ダンプは、ページング ファイルのサイズを自動で割り当てる機能と連動します。普段はページング ファイルを小さめに設定し、STOP エラーなどの障害発生時にページング ファイルを物理メモリとほぼ同等のサイズに割り当てなおすことで、次回にSTOP エラーが再発した場合に、正常なダンプ ファイルが出力されるようにするという機能です。出力されるダンプ ファイルの種類はカーネル メモリ ダンプです。
自動メモリ ダンプの機能を発揮するためには、仮想メモリを [すべてのドライブのページング ファイルのサイズを自動的に管理する] や [システム管理サイズ] に設定している必要があります。つまり、[カスタム サイズ] で任意のサイズに設定している場合は、”自動メモリ ダンプ” に設定していても、従来の ”カーネル メモリ ダンプ” に設定している場合と、あまり差異はないということになります。
従来の OS では、仮想メモリの設定を [システム管理サイズ] に設定している場合、搭載している物理メモリと同程度のページング ファイルを作るようにしていましたが、物理メモリの大容量化、SSD の普及により、ページング ファイルの省サイズ化もニーズとして求められています。そこで Windows 8 / Windows Server 2012 では、物理メモリよりもページング ファイルのサイズを小さくするように動作が変更されています。
しかし、STOP エラーなどの障害発生時に正常なメモリ ダンプを出力するためには、STOP エラー発生時のメモリの使用状況にもよりますが、ページング ファイルのサイズが小さいと、ダンプ ファイルは完全な形では出力されない場合があります。自動メモリ ダンプは、STOP エラーなどによる障害が発生した際、自動的にページング ファイルのサイズを調整し、物理メモリと同程度まで拡張させることで、次回 STOP エラーが発生すると正常なカーネル メモリ ダンプ ファイルが出力されるように備えます。
4GB (4096MB) の物理メモリを搭載している環境で、ちょっとした検証をしてみましょう。
自動メモリ ダンプを有効にし、仮想メモリはシステム管理サイズに設定します。
1) [現在の割り当て] を確認するとページング ファイルのサイズは 704 MB となっています。
2) STOP エラーを発生させます。
3) STOP エラー発生後のページング ファイルを確認すると、4096 MB に拡張されました。
STOP エラーによって再起動された場合、レジストリ キーに “LastCrashTime” という項目を追加し、障害発生時のタイム スタンプを記録します。LastCrashTime が記録されたタイム スタンプから 4 週間、STOP エラーが発生しなければ、ページ ファイルのサイズは自動的に元の拡張前のサイズに縮小させます。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
名前: LastCrashTime
種類: REG_DWORD
なお、直ちに、ページ ファイルのサイズを拡張前のサイズに戻す必要がある場合は、レジストリから “LastCrashTime” を手動で削除し、システムの再起動を行うと拡張前のサイズに戻すことも可能です。
現在使っているシステムでは、どの種類のメモリ ダンプを選べば良いのかという疑問も出てくるかと思いますが、その点については仮想メモリのサイズをどうしたいのか、という部分と密接に関係しているので、また別の機会に改めてご紹介したいと思います。
今回は、 ドメインコントローラーに Windows Server 2012 が存在しない環境において Windows Server 2012 のドメインに参加するサーバー上にてファイル サーバー リソース マネージャーの機能を導入している際に、以下のイベント (ソース:SRMSVC,イベント ID:12339,12344) が 15分程度の間隔で記録される場合の対処方法についてご紹介いたします。
本メッセージ自体は、ドメイン コントローラーと同期した際に Windows Server 2012 に対応したスキーマ定義がないことが原因で記録されます。
対応策としては、以下のいずれかとなります。なお、イベントについては、 ドメイン コントローラーに Windows Server 2012 より追加された機能を保有しているかの確認をし、保有していない旨のイベントになりますので無視していただいても構いません。
なお、スキーマのバージョン アップの手順については、以下の資料をご参照ください。
Adprep.exe の実行 http://technet.microsoft.com/ja-jp/library/dd464018(v=ws.10).aspx -> adprep.exe /forestprep -> adprep.exe /domainprep
運用や環境に合わせて対策を選択していただければと思います。
こんにちは。Windows プラットフォーム サポートの戸田です。
日々のサポート業務の中で、よくお問い合わせを頂く内容についてご紹介します。
複数の Windows が連携して動作するフェールオーバー クラスター環境では、ノード間の相互接続が正常であることが、クラスターの安定動作のために重要です。
フェールオーバー クラスターを構築する場合、冗長化のために少なくとも各ノード毎に 2 つの物理 NIC を用意いただくことを推奨していますが、環境によってさらに物理 NIC が必要となります。
構成により様々な用途でネットワークが使用されるため、結局いくつの NIC が必要になるのかが分からないといった声もいただきます。この記事では、フェールオーバー クラスター環境を計画、構築いただく際に考慮いただきたいネットワーク構成についてお伝えします。
まずは表で簡単にまとめ、それぞれについては以下に説明します。
まずクラスターで使用されるネットワークは以下の 2 種類の役割(a)(b)を持っています。
(a) クラスターノードのみで使用するネットワーク
プライベート ネットワークとも呼ばれ、ノード間の同期、クラスター通信に利用されます。「フェールオーバー クラスター マネージャー」のネットワークのプロパティで「このネットワークでのクラスター ネットワーク通信を許可する 」が選択されたネットワークです。
(b) クライアント アクセス ポイントで使用するネットワーク
パブリック ネットワークとも呼ばれます。上記に加えクラスター外のホストとの通信を行います。デフォルト ゲートウェイの設定を持ち、ドメイン コントローラーとの通信や、DNS サーバーとの通信で使用されます。「フェールオーバー クラスター マネージャー」のネットワークのプロパティで「このネットワークでのクラスター ネットワーク通信を許可する 」と「クライアントにこのネットワーク経由の接続を許可する」が選択されたネットワークです。このネットワークのみでもクラスターを構成することは可能ですが、クラスター相互接続の冗長化のため、複数のネットワーク経路を用意いただくことを推奨しています。
- 参考資料 フェールオーバー クラスターのネットワーク設定を変更する http://technet.microsoft.com/ja-jp/library/cc725775.aspx
CSV を使用するライブ マイグレーション環境ではさらに以下の用途(c)(d)(e) のネットワークを考慮していただく必要があります。
(c) CSV (Cluster Shared Volumes) へのアクセス (リダイレクト I/O ) のためのネットワーク。
通常 (a) のネットワークが使用されるので、個別に用意する必要はありません。
(d) ライブ マイグレーション用のネットワーク
仮想マシンのライブ マイグレーション処理では、仮想マシンのメモリー情報をこのネットワークを使って転送します。定常的ではないにしろ、相当量のトラフィックが流れることが予想されるため独立したネットワークを用意します。このネットワークの選択は 「フェールオーバー クラスター マネージャー」 から仮想マシンのプロパティを開き、[マイグレーション用ネットワーク] タブで、指定と優先順位の設定ができます。
(e) Hyper-V 仮想マシン(ゲスト OS) 用のネットワーク
ホスト マシン、ゲスト マシンのトラフィックを分けるため 「Hyper-V マネージャー」の「仮想ネットワークマネージャー」 にて 「管理オペレーティングシステムにこのネットワーク アダプターの共有を許可する」 のチェックを外し、仮想マシン専用の 物理 NIC として使用されることを推奨します。
ライブ マイグレーション環境では上記 (a) ～ (d) ( a と c は併用) のネットワーク として、また仮想マシン専用(e)の NIC を加えて 4 つの物理 NIC を用意いただくことを推奨します。
(f) iSCSI ストレージ用のネットワーク
iSCSI のストレージをご利用いただく場合には、さらに専用の NIC が必要となります。この 物理 NIC はクラスターでは使用せずネットワークのプロパティで 「このネットワークでのクラスター ネットワーク通信を許可しない」を選択しておきます。
フェールオーバー クラスターは障害検出を以って高可用性を実現するプロダクトです。一時あるいは定常的に流れる大量のトラフィックによってクラスター通信の遅延などが発生しないように考慮いただくことがネットワーク分離の考え方の基となっています。 (f) は iSCSI ストレージ用とご案内していますが、クラスター用途とは直接の関係のない、バックアップやデータ転送などの用途で使用するネットワークも同様の扱いとなります。
なお、この記事でご案内したネットワーク (NIC) の数については、クラスター環境で必ずこうしなければいけないというものではなく、一つの指針としてご理解ください。もし現在運用されているクラスター環境でネットワーク障害が検出されることが多いという場合にはこれら、用途別のネットワークの分離について一度ご確認をいただけると幸いです。
詳細については以下の公開資料がありますので、ご一読いただければと思います。
- 参考資料 Hyper-V: Live Migration Network Configuration Guide公開 http://technet.microsoft.com/en-us/library/ff428137(WS.10).aspx
こんにちは。Windows プラットフォーム サポートの加藤です。本日は、Windows Server 2008 R2 のクラスター共有ボリューム (CSV) の最大数についてお伝えします。
クラスター共有ボリューム (CSV) の最大数自体には制限がないため、登録できるボリュームの数は、OS で認識可能な LUN の数と同じです。
Windows Server 2008 R2 のサポートする LUN の最大数は、以下の通りです。
SCSI、FC 接続- 各 HBA アダプターにつき 8 個のバス- ひとつのバスにつき 128 個のターゲット ID- ひとつのターゲット ID につき 255 個の LUN
iSCSI 接続- Windows Server 2008 R2 標準の iSCSI イニシエーターの最大ターゲット数は 255 個- ひとつのターゲット ID につき 255 個の LUN
なお、OS 側の制限に達する前に、ストレージの仕様により、最大数の制限を受ける可能性があります。例えば、Microsoft iSCSI Software Target 3.3 では、ひとつのターゲットにマッピングできる LUN 数は 128 個までという制限があります。ストレージ側の仕様については、ハードウェアベンダーにお問い合わせください。
[参考資料]文書番号 : 310072- Adding support for more than eight LUNs in Windows Server 2003 and in Windows 2000http://support.microsoft.com/kb/310072/en-us※ Windows Server 2003 までの情報となっておりますが、Windows Server 2008 R2 についても同様です。
文書番号 : 2821904 Windows Server 2008 R2 における iSCSI イニシエーターの最大接続数についてhttp://support.microsoft.com/kb/2821904