Ask CORE

Microsoft Japan Windows Technology Support

Multi-Domain Cluster 作成後にノードの削除、再追加がエラーで失敗する

こんにちは。Windows プラットフォーム サポートの松岡です。 Windows Server 2016 では、Active Directory に依存しないフェールオーバー クラスターを作成する機能が導入されており、異なるドメインのサーバーでクラスターを構成する「Multi-domain Clusters」とワークグループのサーバーでクラスター構成する「Workgroup Clusters」という新機能が追加されています。 「Multi-domain Clusters」と「Workgroup Clusters」の要件や作成手順は、下記ブログに記載がございますのでご参考ください。   <参考> Workgroup and Multi-domain clusters in Windows Server 2016 https://blogs.msdn.microsoft.com/clustering/2015/08/17/workgroup-and-multi-domain-clusters-in-windows-server-2016/   本日は「Multi-domain Clusters」の環境でノードの追加が失敗する事象を紹介します。 クラスター作成後にノードの削除、再追加を行うと認証を正常に行うことができず、下記エラー (error code 0x5b4) が発生しノード追加に失敗することがあります。   ※ error code 0x5b4 は ERROR_TIMEOUT を示します。   このエラーは、再度追加するノードと同じドメインのサーバーがクラスターに 1 台も参加していない場合に発生します。 例えば下記 3 台のノードでクラスターを作成した後で、ノード Node3 (ドメイン B) の削除、再追加を行うと再追加時にはドメイン A のサーバーしかクラスターに参加していないため、エラー… Read more

Windows Server 2012 R2 の Hyper-V クラスター環境で、非高可用性の仮想マシンを、オンラインの状態で高可用性の仮想マシンに構成する際の注意事項

こんにちは。Windows プラットフォーム サポートの加藤です。 本日は、Windows Server 2012 R2 の Hyper-V クラスター環境で、非高可用性の仮想マシンを、オンラインの状態で高可用性の仮想マシンに構成する際の注意事項についてご案内いたします。 ※ 非高可用性の仮想マシン = 仮想マシンリソースに登録されていない仮想マシン ※ 高可用性の仮想マシン = 仮想マシンリソースに登録されている仮想マシン Windows Server 2012 以降のクラスターでは、非高可用性の仮想マシンを、オンラインの状態で高可用性の仮想マシンに構成できます。 ※ 以前のバージョンでは、仮想マシンを一旦停止する必要がございました。 オンラインの状態で仮想マシンリソースに登録することは可能ですが、Windows Server 2012 R2 の環境では登録後に以下の事象が発生いたします。 1. 仮想マシンの NIC の構成を変更することができない。 2. 仮想マシンの再起動時に、仮想マシンリソースが障害ステータスとなる。 1 の事象は、仮想マシンの NIC の構成 (VLAN ID や帯域幅管理など) の変更を実施すると以下のエラーが発生し、変更に失敗します。 2 の事象は、以下のイベントが記録され仮想マシンリソースが一旦障害ステータスとなります。 —————– ソース: Microsoft-Windows-Hyper-V-VmSwitch イベント ID: 32 レベル: エラー 説明: Failed… Read more

クラスターノード再起動後のノード間通信失敗について

こんにちは。Windows プラットフォーム サポートの古谷です。 本日は、WSFC 環境でパッシブのクラスター ノード再起動後にノード間通信失敗する事象についてご紹介します。 クラスター環境では、各クラスター ノードのメモリ上に他のノードとのコネクション情報を保持しています。 本コネクション情報はノード間通信で使用されますが、クラスターノードが起動したタイミングや他ノードとのネットワークが接続されたタイミングで構成され、ノードが停止したタイミングやネットワークが切断されたタイミングで削除されます。 しかしながら、稀に削除が実施されるべきタイミングで削除が正常に行われず、コネクション情報が残存してしまい、クラスター サービスの起動に問題が発生することが報告されております。 具体的には、パッシブのクラスター ノードを再起動した際に、アクティブのノード上でパッシブ ノードのコネクション情報が残ってしまうために、ノード間通信の失敗が発生する事例が弊社に複数寄せられております。 例として、以下、クラスター 2 ノード (WSFC1、WSFC2) の環境において説明いたします。 通常、パッシブ ノードである WSFC2 を再起動すると、アクティブ ノード WSFC1 では WSFC2 と接続が切断されるため WSFC2 のコネクション情報は削除されます。そして、パッシブ ノード起動後アクティブ ノード WSFC1 はパッシブ ノードとのネットワークが接続されたタイミングで、パッシブ ノード WSFC2 からコネクション情報を受け取り、ノード間通信を行います。 しかしながら、パッシブ ノードを再起動した際にアクティブ ノード WSFC1 上にコネクション情報が残る事象が発生した場合、パッシブ ノードと接続された際にパッシブノードから受け取るコネクション情報が既に保持しているコネクション情報と重複しているためアクティブノードで破棄する処理を行い、再接続を拒否します。 そのため、アクティブ ノードとパッシブ ノードの間で通信が行えない問題が発生します。 本事象が発生した際はパッシブ ノードのシステムログ上に以下のログが記録されます。 ———— ログの名前  : System ソース      :… Read more

クラスター ログにおける MSMQ エラーについて

こんにちは。Windows プラットフォーム サポートの野村です。今回はクラスター ログに記録される MSMQ エラーについてご紹介します。 PowerShell の Get-ClusterLog コマンドレットまたは、管理者権限のコマンドプロンプトにて cluster log /g を実行することでクラスター ログを生成できます。生成したログを確認すると以下のエラーが記録されていることがございます。 ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQ returned 21.’ WARN  [RCM] Failed to load restype ‘MSMQ’: error 21. ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQTriggers returned 21.’ WARN  [RCM] Failed to load… Read more

Windows Server 2012 R2 におけるネットワーク障害からの仮想マシンの復旧について

こんにちは。Windows プラットフォーム サポートの野村です。今回は、Windows Server 2012 R2 の新機能である “保護されているネットワーク” により、ネットワーク障害から仮想マシンが復旧するシナリオについてご紹介します。 Windows Server のフェールオーバー クラスターの機能は仮想マシンの実行状態、およびクラスター ネットワークとクラスター ストレージの正常性をを常時監視しています。さらに、仮想マシンのネットワークと仮想スイッチの接続の障害検知も行います。 Windows Server 2012 R2 では、ネットワーク障害が発生した場合にライブ マイグレーションによって、仮想マシンをフェールオーバー クラスターの他のノードに移動させる新機能を導入しました。これにより、仮想マシン内で起動しているサービスが中断してしまうようなネットワーク障害が発生した場合でも、仮想マシンをネットワーク アクセスが提供できるノードへ移動することで、可用性を向上させることができます。既定では、この機能を提供するプロパティである [保護されているネットワーク接続] が全ての仮想ネットワーク アダプターにおいて有効になっています。 なお、ライブ マイグレーション先のノードにおいて使用可能なネットワークが無い場合、上述の仮想マシンのライブ マイグレーションは実行されません。これは、そもそもライブ マイグレーションを開始させるリソースを所有していないノードへ仮想マシンが移動することを避けるためです。クラスター ノード上の必要なネットワークとシステム リソースが利用可能である限り、そのノードは仮想マシンの移動先として選択されます。 また、同時にライブ マイグレーションが可能な仮想マシンの台数には制限があります。ホスト上のネットワーク障害により影響を受ける仮想マシンが、同時ライブ マイグレーション可能台数よりも多い場合、仮想マシンのライブ マイグレーションは一旦キューに登録されます。ネットワーク障害が復旧し再び利用可能になると、ライブ マイグレーション キューに登録されている仮想マシンのライブ マイグレーションはキャンセルされます。 [保護されているネットワーク接続] のプロパティは、仮想マシンのネットワーク アダプターの設定では [高度な機能] の新しいプロパティです。このプロパティにより、ネットワーク障害が起きた際に、仮想マシンを他のノードへ移動させて可用性を保つための重要なネットワーク アダプターにするかどうかを選択することができます。 例えば、仮想マシンに外部ネットワークとバックアップとして使用するネットワークの 2 つの仮想スイッチが接続されている場合、バックアップ用ネットワーク アダプターに対してプロパティを無効にし、外部用ネットワークに対して有効にする、といった仮想ネットワーク アダプター単位の設定が可能です。この場合、もし、バックアップ用ネットワークに障害が発生しても、仮想マシンは移動しませんが、外部用ネットワークに障害があった場合、仮想マシンはネットワークが有効なノードにライブ マイグレーションされます。 なお、多くのネットワーク障害のシームレスな処理および冗長性確保のためにも、運用に際して重要なネットワークに対してはネットワーク チーミングを使用することを推奨しています。   <シミュレーション>… Read more

フェールオーバー クラスターの異なるネットワーク セグメント間通信について

こんにちは。Windows プラットフォーム サポートの古谷です。 日々のサポート業務の中で、お問い合わせを頂く内容についてご紹介します。 本日は、フェールオーバー クラスターが行うクラスター ノード間の異なるネットワーク セグメント間通信についてご紹介します。 フェールオーバー クラスターでは、既定でクラスター ノード間で別ネットワーク セグメントが存在する場合、別ネットワーク セグメントに対して定期的に通信 (UDP 3343) を行っております。 【発生する通信】 ・UDP 通信 ・サービス:ms-cluster-net(3343ポート) これは、マルチサイト クラスター構成のための重要な通信であり、異なるネットワーク セグメントに対してハートビート通信ができるかルート検出を行う動作となります。 例えば、本動作によりクラスター ノード間で以下の通信が発生します。 フェールオーバー クラスター  2 ノード(WSFC1、WSFC2)環境において、クラスター ノード間に 2 つのネットワークが存在している。 ① Public 用ネットワーク(クライアント アクセスポイントが割り当てられたパブリック ネットワーク) ② HeartBeat用ネットワーク (クラスター ノード間を結ぶ Closed なプライベート ネットワーク) 本環境で、WSFC1 の Publicnet から WSFC 2 の HeartBeatnetに対して、また、WSFC2 の Publicnet からWSFC1… Read more

「フェールオーバー クラスターの IP アドレス変更手順」

こんにちは。日本マイクロソフトの松岡でございます。 本日は、クラスター環境の IP アドレス変更手順についてご紹介いたします。   クラスター環境の移行をおこなう場合など、クラスターを構成している各ノードの物理 IP アドレスと、クラスター上で稼働しているアプリケーションに紐づく仮想 IP アドレスを変更する必要がある場合があります。その際、クラスター環境の IP アドレス変更については、以下の 3 種類の IP アドレスの変更を検討していただく必要があります。   物理 IP アドレス: ・クラスター構成ノード (物理サーバー) の IP アドレス 仮想 IP アドレス: ・クラスター管理用 (クラスター コア リソース) の仮想 IP アドレス ・クラスター化されたアプリケーションの仮想 IP アドレス 今回は上記 3 つの IP アドレスの変更の順番と、変更方法についてご案内したいと思います。 ※注意点※ クラスター環境構成後はドメイン移行、物理ホスト名の変更はサポートしておりません。 変更が必要となる場合には、一度クラスターを解除する必要があります。 仮想 IP の変更を行う場合、クラスター化されたアプリケーションの設定も変更が必要な場合があります。 詳細につきましてはご利用のアプリケーションの提供元様にご確認ください。  ■設定手順 =========== 本 Blog では… Read more

Windows Server 2012 R2 の "保護されているネットワーク" について

こんにちは。Windows プラットフォーム サポートの野村です。今回は、Windows Server 2012 R2 の Hyper-V における新機能の一つである "保護されているネットワーク" についてご紹介いたします。 この “保護されているネットワーク” を設定することで、仮想マシンの仮想ネットワーク アダプターで切断が検知された場合、その仮想マシンは自動的に別の Hyper-V ホストに移動します (※この機能は、Hyper-V クラスタリングを構成している場合に機能します)。 "保護されているネットワーク" は Hyper-V の仮想マシンの設定ウインドウにて、対象の [ネットワーク アダプター] の[高度な機能]を展開して設定することができ、既定では有効化されています。そのため、Windows Server 2012 R2 において、仮想マシンに追加されたネットワーク アダプターは、いずれも保護されているネットワーク アダプターとして自動的に構成されます。   “保護されているネットワーク” の設定がされた仮想マシンにおいて、仮想ネットワーク アダプターと紐づいている仮想スイッチの物理 NIC に切断が検知された場合、その仮想マシンのライブ マイグレーションが行われます。この動作が実行される前には、移動先の Hyper-V ホストの仮想スイッチが正常にネットワークに接続されていることを確認します (※移動先のHyper-V ホストのスイッチでネットワーク障害を検知して、仮想マシンのライブ マイグレーションが何度も行われることを避けるためです)。 “保護されているネットワーク” が設定されていない場合、仮想ネットワーク アダプターと紐づいている仮想スイッチの物理 NIC に障害が発生しても、仮想ネットワーク上では障害の発生を検知できないため、仮想マシンのセッションの維持に影響を及ぼします。 従いまして、この "保護されているネットワーク" の機能を有効にすることで、ライブ マイグレーションにより仮想マシンのセッション状態を維持できるため、ダウンタイムが生じなくなり、より高いレベルでネットワークの可用性を維持することができます。   <参考情報>… Read more

Windows Server 2012 R2 のクラスターの共有ボリュームにおける Defrag および Chkdsk コマンドの実行について

こんにちは。Windows プラットフォーム サポートの野村です。今回は、Windows Server 2012 R2 のフェールオーバー クラスター環境のクラスターの共有ボリューム (CSV) における Defrag および Chkdsk コマンドの実施方法についてご案内いたします。 クラスターの共有ボリューム (CSV) とは、1 つの論理ボリュームに対して複数のクラスター ノードからアクセス可能になる技術です。Windows Server 2012 R2 では、ディスクを NTFS または Resilient File System (ReFS) として、リソースを割り当てることができます。 CSV でない通常のボリュームと同様に、CSV のファイル システムに対してデフラグまたは Chkdsk の実行が必要となる場合があります。以下に、CSV にてデフラグおよび Chkdsk を行う際の推奨される手順をご案内いたします。   ================================== CSV における Defrag コマンドの実行手順 ================================== CSV におけるファイルの断片化はシステムのパフォーマンスに影響を及ぼします。従いまして、定期的に CSV にデフラグを実行することにより、ボリューム上の断片化したファイルを統合することを推奨いたします。 スタンドアロン サーバーにおけるデフラグは、メンテナンス タスクとして自動的に実行されますが、CSV においてはデフラグは自動的に実行されません。よって、手動またはスクリプトにて実行する必要があります。なお、デフラグの実行はシステムのパフォーマンスに影響を与える可能性があるため、システムの負荷が少ない時間帯に実施することを推奨いたします。  … Read more

Azure 上でフェールオーバー クラスターを構築する際の留意事項について

こんにちは。Windows プラットフォーム サポートの加藤です。 本日は、Azure 上でフェールオーバー クラスターを構築する際の留意事項についてご案内します。最近、Azure 上の仮想マシンで構築したフェールオーバー クラスターがハートビート通信のダウンでフェールオーバーが発生する報告がございました。 ハートビート通信とは、ノード間で実施される通信で、目的はノード間ネットワークの死活監視です。全てのハートビート通信がダウンすると相手ノードが停止したと判断します。フェールオーバー クラスターのハートビート通信のタイムアウトの閾値の既定値は 5 秒であり、これを超えてもハートビート通信ができない場合には、相手ノードのダウンと判断され、停止したノードがアプリケーションのオーナーノードであった場合には、そのアプリケーションは他のノードへフェールオーバーされます。 – 参考フェールオーバー クラスターのハートビートについてhttp://blogs.technet.com/b/askcorejp/archive/2012/03/22/3488080.aspx Azure 環境では、後述の計画的なメンテナンス時に 30 秒ほど仮想マシンが一時停止する場合がございます。30 秒間クラスター ノードが停止すると、もう一方のクラスター ノードは、一時停止しているノードとハートビート通信が実施できない状況に陥り、上述の事象が発生します。 ========================================Azure Virtual Machines に対する計画的なメンテナンスhttps://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-planned-maintenance/該当箇所を抜粋します。 Microsoft Azure の更新のクラスの場合、実行中の仮想マシンに何らかの影響があってもお客様にはわかりません。これらの更新の多くは、実行中のインスタンスに干渉することがなく更新可能なコンポーネントまたはサービスを対象にしています。これらの更新の一部は、ホスト オペレーティング システムのプラットフォーム インフラストラクチャに対する更新であり、仮想マシンの完全な再起動を必要とせずに適用できます。 これらの更新は、ライブ移行 ("メモリ保護" 更新) を実現するテクノロジによって達成されます。更新時、仮想マシンは "一時停止" 状態になり、RAM 内のメモリは保護されます。この状態で、基礎となるホスト オペレーティング システムが必要な更新プログラムと修正プログラムを受信します。仮想マシンは、30 秒以内の一時停止で再開されます。再開後、仮想マシンのクロックは自動的に同期されます。 このメカニズムを使用してすべての更新をデプロイできるわけではありませんが、一時停止の期間が短い場合、この方法で更新をデプロイすることにより、仮想マシンへの影響が大幅に軽減されます。 複数インスタンスの更新 (可用性セット内の仮想マシンの場合) が、一度に 1 つの更新ドメインに適用されます。======================================== フェールオーバーの発生自体は、クラスター上のアプリケーションを救うための正常な動作ですが、Azure メンテナンス時に極力フェールオーバーの発生を抑えたい場合には、このハートビートの閾値を事前に延長しておくことをお勧めいたします。 具体的な設定値につきましては、クラスター上のアプリケーションの停止時間がどの程度まで許容できるかによって異なります。例えば 20 秒間の停止では、クラスター上のアプリケーションを使用したシステムに影響を及ぼさないのであれば、ハートビートの閾値を 21 秒に延長することで、Azure… Read more