Windows Server 2008 R2: フェールオーバー クラスターのトラブルシューティング
障害を許容できない場合、Windows Server でフェールオーバー クラスターを構成すると、100% に近い可用性を実現するのに役立ちます。
John Marlin
Windows Server は、長い年月をかけ、いくつものバージョンを経て、さまざまなレベルのサポートやトラブルシューティングの戦術により変化してきました。現在のサポート ポリシーでは、Windows Server 2008 または Windows Server 2008 R2 のフェールオーバー クラスタリング ソリューションが、マイクロソフト カスタマー サポート サービス (CSS) で正式にサポートされているソリューションだと見なされるためには、次の条件を満たしている必要があります。
- すべてのハードウェア コンポーネントおよびソフトウェア コンポーネントが、"Certified for Windows Server 2008 R2" ロゴを取得するための条件を満たしている必要があります。
- 構成された完全なソリューションは、フェールオーバー クラスター管理スナップインの検証ウィザードで、すべてのテストに合格する必要があります。
公式にサポートされているバージョンを使用すると、すべてのものが問題なく動作する可能性が最も高くなります。ハードウェア ベンダーに関して問題が発生することはあり、マイクロソフトが構成についてサポートを提供しなければならないことはありますが、少なくともソリューションの運用を開始することはできます。この記事では、Windows Server 2008 R2 のフェールオーバー クラスタリングに関する一般的な問題を取り上げて、問題の的確なトラブルシューティングを行う方法を紹介します。
変化するクラスター
Windows Server 2008 R2 では、構成の検証ウィザードの導入により、クラスターの検証方法が大きく変化しました。このウィザードは、フェールオーバー クラスター管理に統合されています。構成の検証ウィザードを使用すると、クラスターでノードとして使用する予定のサーバー群に対して集中テストを実行できます。
この検証プロセスでは、基盤となる個々のハードウェアとソフトウェアを直接テストし、特定の構成でフェールオーバー クラスタリングがどの程度サポートされるのかを正確に評価できます。このウィザードを運用中のクラスターで実行すると、ベスト プラクティスに従っているかどうかを調べられます。このウィザードは、新しいハードウェアやドライバーをクラスターに追加したときに実行することをお勧めします。
スクリプトがお好きな方に朗報です。フェールオーバー クラスタリングでは、Windows PowerShell がサポートされるようになりました。今後、CLUSTER.EXE は更新されないので、Windows PowerShell を学習する必要があります。コマンドレットについてご存じない場合は、「Get-Help *Cluster*」というコマンドを実行してみてください。このコマンドを実行すると、次のようなコマンドについての説明が表示されます。
Name Synopsis
---- --------
New-Cluster Create a new failover cluster.Before you can create a
cluster, you must... (新しいフェールオーバー クラスターを作成します。クラスターを作成する前に...)
このコマンドの使い方がわからない場合は、「Get-Help New-Cluster –Examples」というコマンドを使用してサンプルを確認できます。次に、その例を示します。
名前
New-Cluster
概要
Create a new failover cluster.Before you can create a cluster, you
must connect the hardware (servers, networks, and storage), and run
the validation tests. (新しいフェールオーバー クラスターを作成します。クラスターを作成する前に、
ハードウェア (サーバー、ネットワーク、およびストレージ) を接続して実行する必要があります)。
-------------------------- 例 1 --------------------------
C:\PS>New-Cluster -Name cluster1 -Node node1,node2,node3,node4
Name
----
cluster1
説明
-----------
This command creates a four-node cluster named cluster1, using default
settings for IP addressing. (このコマンドでは、IP アドレスの割り当てに既定の設定を使用して、
cluster1 という名前の 4 つのノードで構成されたクラスターを作成します)
Windows でイベントが発生したら、そのイベントについて的確に理解することをお勧めします。すべてのイベントで十分な情報が提供されるとは限りません。イベントの説明を含む、すべてのイベントの情報については、TechNet ライブラリのオンライン ページ (英語) で確認できます。
イベント ログが鍵を握る
問題が発生したら、初めにクラスター イベントを確認することをお勧めします。システム イベント ログでは、重大、エラー、または警告レベルのイベントが表示されます。情報メッセージ (グループがオフラインになったこと、グループが別のノードに移動したことなど) は、FailoverClustering の Operational に保存されます。情報メッセージは、イベント ビューアーの [アプリケーションとサービス ログ]、[Microsoft]、[Windows]、[FailoverClustering] を展開すると確認できます。
問題が発生しているサービス/アプリケーションのグループやリソースを特定できない場合は、フェールオーバー クラスター管理コンソールでイベントを確認できます。また、特定のグループと関連があることを把握している場合は、[このアプリケーションの重要イベントの表示] をクリックします。特定のリソースと関連があることを把握している場合は、[このリソースの重要イベントの表示] をクリックします。
これらのコマンドを実行すると、システム イベント ログが表示され、特定のグループやリソースでイベントがフィルター処理されます。また、クラスターの全ノードのシステム イベント ログで検出されたインスタンスがすべて表示されます。情報を 1 つの場所で確認できるので、これは便利な機能です。
リソースを特定したら、システム イベント ログにアクセスして、問題の原因となっている要素が他にあるかどうかを確認します。現象に気を取られることなく、原因を特定することに集中してください。たとえば、ネットワーク名や IP アドレスで問題が発生している場合、この問題の原因となる他のネットワーク関連のイベントがないかどうかを確認します (たとえば、TCP/IP スタックのエラー、ネットワーク カードの誤動作などは、この問題の原因になり得ます)。
クラスター デバッグ ログは、イベントのトレース セッションに変化をもたらしました。CLUSTER.LOG は廃止され、ログは %WinDir%\System32\winevt\logs フォルダーにある ETL (抽出、変換、および読み込み) ファイルに書き込まれるようになりました。ETL ファイルから、これら 3 つのすべての処理で表示する 1 つの cluster.log を生成できます。ただし、このログファイルは、ログ作成時点におけるスナップショットです。つまり、Cluster.log を生成すると、それ以降、情報が Cluster.log ファイルに追加で書き込まれることはありません。ノードで Cluster.log ファイルを生成するたびに、既存のファイルは上書きされ、新しいものに置き換えられます。
ログは、Windows PowerShell の Get-ClusterLog コマンドレットを使用して生成できます。このコマンドレットは、クラスターの全ノードに対して実行され、%WinDir%\Cluster\Reports フォルダーには、ノードごとにファイルが作成されます。ノードの数とファイルのサイズによっては、スイッチを追加することをお勧めします。
たとえば、9 つのノードで構成されたクラスターで、すべてのノードのログを生成する必要があるとします。–Destination スイッチを使用すると、すべてのノードのログを生成し、生成したログを指定の場所にコピーすることができます。このスイッチを使用すると、ログを 1 つの場所にまとめることができます。また、ログ ファイルの名前にはノード名が含まれます (たとえば、「Get-ClusterLog –Destination c:\logs」というコマンドを実行すると、C:\logs フォルダーに Node1_Cluster.log や Node2_cluster.log のような名前のログ ファイルが作成されます)。
簡単に再現できる問題の場合は、–Timespan スイッチの使用を検討します (時間は分単位で指定します)。ノードで問題を再現し、「Get-ClusterLog –Timespan 5 –Node Node1」というコマンドを実行します。このコマンドを実行すると、Node1 についてのみ Cluster.log を生成し、過去 5 分間に発生したイベントのみをキャプチャできます。
このレベルのトラブルシューティングについて、いくつかヒントを紹介しましょう。
- ログは冗長で複雑です。最初にログを確認するのは得策ではありません。
- 少なくとも過去 3 日分相当のデータをキャプチャします。このようにすると、金曜日の夜に障害が発生した場合でも、月曜日の朝にデータが消失せずに残っているからです。各ログのサイズは 100 MB です。サイズを大きくする必要がある場合は、Windows PowerShell のコマンド「Set-Clusterlog –Size 200」を使用します (サイズは、200 ではなく任意のサイズを MB 単位で指定できます)。
- ログに多くのデータを記録するアプリケーションもあります。そのようなアプリケーションがある場合には、ログのサイズを大きくする必要があります。
- クラスター デバッグ ログの時刻は GMT (グリニッジ標準時) で記録されるので、イベントが発生した時刻をローカル時間に変換する必要があります。
- 収集する必要がある情報に応じて、–Destination スイッチまたは –Timespan スイッチを使用します。
来月は、いくつかの一般的なトラブルシューティング シナリオを紹介します。
.jpg)
John Marlin は、マイクロソフトの Commercial Technical Support Group でシニア サポート エスカレーション エンジニアとして働いています。勤続 19 年で、14 年前からクラスター サーバーを担当しています。