フェール オーバー クラスタ。 フェールオーバークラスタリング(WSFC)とは

フェールオーバー クラスタリング

フェール オーバー クラスタ

Windows Server のフェールオーバー クラスタリング Failover Clustering in Windows Server• この記事の内容 適用先:Windows Server 2019、Windows Server 2016 Applies to: Windows Server 2019, Windows Server 2016 フェールオーバー クラスターは、互いに連携する個々のコンピューターが集まって形成され、クラスター化された役割 以前は、クラスター化されたサービス、クラスター化されたアプリケーションと呼ばれていました の可用性とスケーラビリティを高めます。 A failover cluster is a group of independent computers that work together to increase the availability and scalability of clustered roles formerly called clustered applications and services. クラスター サーバー ノード は、物理ケーブルとソフトウェアにより接続されます。 The clustered servers called nodes are connected by physical cables and by software. クラスター ノードに障害が発生した場合、他のノードがサービスの提供を開始します。 このプロセスを "フェールオーバー" といいます。 If one or more of the cluster nodes fail, other nodes begin to provide service a process known as failover. また、クラスター化された役割は能動的に監視され、正常に機能しているかどうかが確認されます。 In addition, the clustered roles are proactively monitored to verify that they are working properly. 正常に機能していない役割は、再起動されるか、または別のノードに移されます。 If they are not working, they are restarted or moved to another node. フェールオーバー クラスターには、一貫性のある分散名前空間を提供するクラスターの共有ボリューム CSV 機能も用意されています。 これにより、クラスター化された役割のすべてのノードから共有記憶域にアクセスできます。 Failover clusters also provide Cluster Shared Volume CSV functionality that provides a consistent, distributed namespace that clustered roles can use to access shared storage from all nodes. フェールオーバー クラスタリング機能により、ユーザーに対するサービスの中断を最小限に抑えることができます。 With the Failover Clustering feature, users experience a minimum of disruptions in service. フェールオーバー クラスタリングには、次のような多くの実用的なアプリケーションがあります。 Failover Clustering has many practical applications, including:• Microsoft SQL Server、Hyper-V 仮想マシンなどのアプリケーションを対象とした高可用性の 継続的に使用可能な ファイル共有記憶域。 Highly available or continuously available file share storage for applications such as Microsoft SQL Server and Hyper-V virtual machines• 物理サーバー上、または Hyper-V を実行するサーバーにインストールされた仮想マシン上で実行される高可用性のクラスター化された役割。 Highly available clustered roles that run on physical servers or on virtual machines that are installed on servers running Hyper-V 概要 Understand 計画 Planning 展開 Deployment 管理 Manage ツールと設定 Tools and settings コミュニティ リソース Community resources 関連記事.

次の

フェールオーバークラスタリングのシステムログイベント

フェール オーバー クラスタ

が世間的に盛り上がっている? なか、お金がないという理由でしょうがなく旧来の3レイヤ構成Hyper-Vクラスターを組むことになった。 まだまだ高いよHCI... 正直なとこ自分は3レイヤ構成で構築したことがなく、その上物理機器もない。 あるのは割と高スペックなパソコンのみ。 このままではとても不安なので、構築の流れだけでも把握できるように、なんとかして疑似環境を組むことにした。 要件としてはホストサーバー2台でクラスターを構成し、ライブマイグレーションおよび障害時のフェイルオーバーが可能なものとする。 検証環境 ルートホストサーバー上に全要素を仮想マシンで構築する。 ルートホストサーバー: Windows 10 Pro 1703• ストレージサーバー: CentOS 7. クラスタ管理ADサーバー: WindowsServer 2016 Standard 評価版• ホストサーバー1: WindowsServer 2016 Standard 評価版• ホストサーバー2: WindowsServer 2016 Standard 評価版• Windowsゲストサーバー: WindowsServer 2016 Standard 評価版• Linuxゲストサーバー: CentOS 7. 4 物理NICは1つしかないため、本来分けるべきネットワークが分けられていない。 よって、全仮想マシンは全て同じネットワークのアドレスを持つ。 以下にIPアドレス割り当てを示す。 ルートホストサーバー: DHCP• ストレージサーバー: 192. 168. クラスタ管理ADサーバー: 192. 168. ホストサーバー1: 192. 168. ホストサーバー2: 192. 168. クラスタ管理用アドレス: 192. 168. Windowsゲストサーバー: DHCP• Linuxゲストサーバー: DHCP ホストサーバーに対してNestedHyper-Vを有効にする Windows10 WindowsServer2016 からHyper-Vの仮想マシン上でHyper-Vサーバーを構築できるNested Hyper-V機能を有効に出来るようになった。 ルートホストサーバー上に仮想マシンを作成したら停止し、以下の手順でホストサーバー1とホストサーバー2のNestedHyper-Vを有効にすること。 OSの基本的な設定は済ませてあること。 iSCSIを利用するにあたり、事前にを決めておかなければいけないので、以下のように決めておいた。 ホストサーバー1: iqn. 2017-09. com. test:host-sv1• ホストサーバー2: iqn. 2017-09. com. test:host-sv2• ストレージサーバー: iqn. 2017-09. com. 2017-09. com. 2017-09. com. 2017-09. com. 2017-09. com. ちなみにホストサーバー上にクラスタ管理ADの役割も持たせるといったズルをすると、後で設定が進められなくなるので注意すること。 ActiveDirectoryインストールとクラスター用ドメインの作成 サーバーマネージャーを開いて「Active Directory ドメインサービス」の役割を追加する。 必要な機能も自動で選択されるので、一緒に入れておくこと。 クラスター用ドメインを作成し、ドメインコントローラーに昇格する。 ドメイン名: cluster. local• フォレストレベル: Windows Server 2016• ドメインレベル: Windows Server 2016 ホストサーバーの構築 iSCSIストレージに接続する iSCSIイニシエーターにアクセスして自身のIQNを確認する。 iSCSIターゲット側で設定したIQNと違っていれば直すこと。 IQNを修正したら、iSCSIターゲットのIPアドレスを入力して接続する。 ターゲット側のIQNが表示され、接続完了となっていればOK。 iSCSIストレージをフォーマットする この作業はホストサーバー1でのみ行う事! ディスクの管理にアクセスし、接続されたたクォーラムディスクと共有ディスクをオンラインにしてGPTで初期化する。 その後、両方のディスクをNTFSでフォーマットする。 ドライブレターは割り当てなくともよい。 iSCSIストレージをオンラインにする ホストサーバー1は既にオンラインになっているため、ホストサーバー2も同様にオンラインにする。 こちらもドライブレターを割り当てる必要はない。 ホストサーバー1でフォーマット済みであるため、オンラインにした時点でNTFSフォーマットになっていることが確認できる。 Hyper-Vをインストールする サーバーマネージャーを開いて「Hyper-V」の役割を追加する。 必要な機能も自動で選択されるので、一緒に入れておくこと。 フェールオーバークラスタリングをインストールする サーバーマネージャーを開いて「フェールオーバークラスタリング」の機能を追加する。 必要な機能も自動で選択されるので、一緒に入れておくこと。 この時点では特に設定は必要ない。 クラスター用ドメインに参加する ホストサーバーを2台とも普通にドメイン参加する。 Hyper-Vの構築 Hyper-Vマネージャーを起動して仮想スイッチを作成する。 今回はNICが1つしかないためネットワークアダプタは管理用オペレーティングシステムと共用させている。 なお、マイグレーション時に仮想スイッチの設定が完全に一致している必要がある。 スイッチ名や構成はクラスターを構成するホストサーバー同士で合わせておくこと。 Hyper-Vクラスターの構築 ホストサーバー1にて作業を行う。 以降の作業は クラスター用ドメインの管理者ユーザーでログインして作業すること。 クラスターを構築する ホストサーバー1のフェールオーバークラスターマネージャーを起動する。 左ツリーのフェールオーバークラスターマネージャーを右クリックし、クラスターの作成を選択する。 クラスターに参加させたい全てのホストサーバーを入力し、「追加」ボタンで追加していく。 追加が終わったら「次へ」で進む。 検証するかどうか聞かれるので、念のため検証を行っておく。 今回は無理やり1NICで設定したため、いくつか警告が出ている。 気にせず完了する。 クラスタ名とクラスタ管理用の仮想IPを聞かれるので、任意の設定を入力して次へ進む。 以降は次々と進めて、クラスターの作成を完了させる。 ディスクサイズを見て自動判断しているのか、クォーラムディスクと共有ディスクが自動で設定されていた。 共有ディスクをクラスター共有ボリュームに変換する iSCSIディスクはホストサーバーでアクセス可能になっているが、クラスター用に変換されていない。 共有ディスクを選択して、右にあるメニューから「クラスターの共有ボリューム」を押す。 変換はすぐ終わる。 変換されると、適用先名が「クラスターの共有ボリューム」に変わる。 ディスクの管理でみても、NTFSからCSVFSという専用フォーマットになっている。 クラスタ専用領域は基本的にHyper-V仮想マシン構成ファイル以外のファイルを置くことは推奨されないとのこと。 むやみに触れないことにする。 また、クラスタ専用領域はアンチウィルスソフトの検索から除外することも忘れずに。 クラスターが破損する危険性がある。 クラスターに接続できることを確認する ホストサーバー2のフェールオーバークラスターマネージャーを起動する。 左ツリーのフェールオーバークラスターマネージャーを右クリックし、「クラスターへの接続」を選択する。 どのサーバーのクラスタに接続するか聞かれるので、「」を選択して「OK」を押す。 問題なく作成済みのクラスタに接続できれば、ホストサーバー1と同様にクラスタにアクセスすることができる。 仮想マシンの作成 ここまでくれば、あとは仮想マシンを作成するだけとなる。 ただし、Hyper-Vマネージャーからではなく、フェールオーバークラスターマネージャー上で作成しなければ、マイグレーションやフェイルオーバーが動作しない。 ホストは後でマイグレーション出来るのでどれでも良い。 あとは見慣れたウィザードでこれまで通りに仮想マシンを作成するだけだが、仮想マシンの構成ファイルをクラスタ専用領域に指定しなければならない点に注意すること。 これで、マイグレーション可能なHyper-Vクラスタが構築できた。 あとはマイグレーションのテストや障害発生のテストを粛々とするとよい。 動作検証メモ ライブマイグレーションの挙動 ゲストOS 可否 WindowsServer2016 OK CentOS7. 4 NG 恐らくLinux系はライブマイグレーション不可なのではないかと。 ライブマイグレーション実行時の仮想マシンの挙動は以下のように想定される。 指定先クラスタノードに仮想マシンを移動• 仮想マシンを再開 クイックマイグレーションの挙動 ゲストOS 可否 WindowsServer2016 OK CentOS7. 4 OK Windows・LinuxともにOK クイックマイグレーションの仮想マシンの挙動は以下のように想定される。 仮想マシンを一時停止• 指定先クラスタノードに仮想マシンを移動• 仮想マシンを再開 フェールオーバーの挙動 ゲストOS 可否 WindowsServer2016 OK CentOS7. 4 OK フェイルオーバー発生時の仮想マシンの挙動は以下のように想定される。 電源断 故意の障害発生• クラスタノードに通信が出来なくなったことをクラスタが検知• 5分程度待機• 有効なクラスタノードに仮想マシンを移動 優先順位は設定できるが、場合によりけり• 仮想マシンを起動 自動で生きているノードで起動しようとするが、結局は電源断が発生しているので仮想マシンが壊れる可能性がある。 フェイルオーバー後の障害ノード復旧後の挙動 例えばホストサーバー2が異常終了後、復旧させると有効なクラスタノードとして再認識される ただし、フェイルオーバーで移動した仮想マシンは戻らない。 フェールバックが無効になっているから? 気になる点として、復旧までの時間にActiveDirectoryみたいに時間制限があるのかどうかが気になる。 ActiveDirectoryはあまりにも長い時間復旧しないと、復旧が難しくなる。 フェイルオーバーに関して WindowsServer2012R2時代のクラスターはノード障害を検知すると即座にフェイルオーバーしていたが、WindowsServer2016のクラスターは猶予時間 4分 がある模様。 実機上でブルースクリーンを疑似的に発生させてみたがフェイルオーバーせず、2-3分ほどでノードが再起動完了してしまうためフェイルオーバーに至らなかった。 この設定を変更するには以下のコマンドをいずれかのノード上のPowerShellで実行すれば変更できた。

次の

Always On フェールオーバー クラスター インスタンス

フェール オーバー クラスタ

が世間的に盛り上がっている? なか、お金がないという理由でしょうがなく旧来の3レイヤ構成Hyper-Vクラスターを組むことになった。 まだまだ高いよHCI... 正直なとこ自分は3レイヤ構成で構築したことがなく、その上物理機器もない。 あるのは割と高スペックなパソコンのみ。 このままではとても不安なので、構築の流れだけでも把握できるように、なんとかして疑似環境を組むことにした。 要件としてはホストサーバー2台でクラスターを構成し、ライブマイグレーションおよび障害時のフェイルオーバーが可能なものとする。 検証環境 ルートホストサーバー上に全要素を仮想マシンで構築する。 ルートホストサーバー: Windows 10 Pro 1703• ストレージサーバー: CentOS 7. クラスタ管理ADサーバー: WindowsServer 2016 Standard 評価版• ホストサーバー1: WindowsServer 2016 Standard 評価版• ホストサーバー2: WindowsServer 2016 Standard 評価版• Windowsゲストサーバー: WindowsServer 2016 Standard 評価版• Linuxゲストサーバー: CentOS 7. 4 物理NICは1つしかないため、本来分けるべきネットワークが分けられていない。 よって、全仮想マシンは全て同じネットワークのアドレスを持つ。 以下にIPアドレス割り当てを示す。 ルートホストサーバー: DHCP• ストレージサーバー: 192. 168. クラスタ管理ADサーバー: 192. 168. ホストサーバー1: 192. 168. ホストサーバー2: 192. 168. クラスタ管理用アドレス: 192. 168. Windowsゲストサーバー: DHCP• Linuxゲストサーバー: DHCP ホストサーバーに対してNestedHyper-Vを有効にする Windows10 WindowsServer2016 からHyper-Vの仮想マシン上でHyper-Vサーバーを構築できるNested Hyper-V機能を有効に出来るようになった。 ルートホストサーバー上に仮想マシンを作成したら停止し、以下の手順でホストサーバー1とホストサーバー2のNestedHyper-Vを有効にすること。 OSの基本的な設定は済ませてあること。 iSCSIを利用するにあたり、事前にを決めておかなければいけないので、以下のように決めておいた。 ホストサーバー1: iqn. 2017-09. com. test:host-sv1• ホストサーバー2: iqn. 2017-09. com. test:host-sv2• ストレージサーバー: iqn. 2017-09. com. 2017-09. com. 2017-09. com. 2017-09. com. 2017-09. com. ちなみにホストサーバー上にクラスタ管理ADの役割も持たせるといったズルをすると、後で設定が進められなくなるので注意すること。 ActiveDirectoryインストールとクラスター用ドメインの作成 サーバーマネージャーを開いて「Active Directory ドメインサービス」の役割を追加する。 必要な機能も自動で選択されるので、一緒に入れておくこと。 クラスター用ドメインを作成し、ドメインコントローラーに昇格する。 ドメイン名: cluster. local• フォレストレベル: Windows Server 2016• ドメインレベル: Windows Server 2016 ホストサーバーの構築 iSCSIストレージに接続する iSCSIイニシエーターにアクセスして自身のIQNを確認する。 iSCSIターゲット側で設定したIQNと違っていれば直すこと。 IQNを修正したら、iSCSIターゲットのIPアドレスを入力して接続する。 ターゲット側のIQNが表示され、接続完了となっていればOK。 iSCSIストレージをフォーマットする この作業はホストサーバー1でのみ行う事! ディスクの管理にアクセスし、接続されたたクォーラムディスクと共有ディスクをオンラインにしてGPTで初期化する。 その後、両方のディスクをNTFSでフォーマットする。 ドライブレターは割り当てなくともよい。 iSCSIストレージをオンラインにする ホストサーバー1は既にオンラインになっているため、ホストサーバー2も同様にオンラインにする。 こちらもドライブレターを割り当てる必要はない。 ホストサーバー1でフォーマット済みであるため、オンラインにした時点でNTFSフォーマットになっていることが確認できる。 Hyper-Vをインストールする サーバーマネージャーを開いて「Hyper-V」の役割を追加する。 必要な機能も自動で選択されるので、一緒に入れておくこと。 フェールオーバークラスタリングをインストールする サーバーマネージャーを開いて「フェールオーバークラスタリング」の機能を追加する。 必要な機能も自動で選択されるので、一緒に入れておくこと。 この時点では特に設定は必要ない。 クラスター用ドメインに参加する ホストサーバーを2台とも普通にドメイン参加する。 Hyper-Vの構築 Hyper-Vマネージャーを起動して仮想スイッチを作成する。 今回はNICが1つしかないためネットワークアダプタは管理用オペレーティングシステムと共用させている。 なお、マイグレーション時に仮想スイッチの設定が完全に一致している必要がある。 スイッチ名や構成はクラスターを構成するホストサーバー同士で合わせておくこと。 Hyper-Vクラスターの構築 ホストサーバー1にて作業を行う。 以降の作業は クラスター用ドメインの管理者ユーザーでログインして作業すること。 クラスターを構築する ホストサーバー1のフェールオーバークラスターマネージャーを起動する。 左ツリーのフェールオーバークラスターマネージャーを右クリックし、クラスターの作成を選択する。 クラスターに参加させたい全てのホストサーバーを入力し、「追加」ボタンで追加していく。 追加が終わったら「次へ」で進む。 検証するかどうか聞かれるので、念のため検証を行っておく。 今回は無理やり1NICで設定したため、いくつか警告が出ている。 気にせず完了する。 クラスタ名とクラスタ管理用の仮想IPを聞かれるので、任意の設定を入力して次へ進む。 以降は次々と進めて、クラスターの作成を完了させる。 ディスクサイズを見て自動判断しているのか、クォーラムディスクと共有ディスクが自動で設定されていた。 共有ディスクをクラスター共有ボリュームに変換する iSCSIディスクはホストサーバーでアクセス可能になっているが、クラスター用に変換されていない。 共有ディスクを選択して、右にあるメニューから「クラスターの共有ボリューム」を押す。 変換はすぐ終わる。 変換されると、適用先名が「クラスターの共有ボリューム」に変わる。 ディスクの管理でみても、NTFSからCSVFSという専用フォーマットになっている。 クラスタ専用領域は基本的にHyper-V仮想マシン構成ファイル以外のファイルを置くことは推奨されないとのこと。 むやみに触れないことにする。 また、クラスタ専用領域はアンチウィルスソフトの検索から除外することも忘れずに。 クラスターが破損する危険性がある。 クラスターに接続できることを確認する ホストサーバー2のフェールオーバークラスターマネージャーを起動する。 左ツリーのフェールオーバークラスターマネージャーを右クリックし、「クラスターへの接続」を選択する。 どのサーバーのクラスタに接続するか聞かれるので、「」を選択して「OK」を押す。 問題なく作成済みのクラスタに接続できれば、ホストサーバー1と同様にクラスタにアクセスすることができる。 仮想マシンの作成 ここまでくれば、あとは仮想マシンを作成するだけとなる。 ただし、Hyper-Vマネージャーからではなく、フェールオーバークラスターマネージャー上で作成しなければ、マイグレーションやフェイルオーバーが動作しない。 ホストは後でマイグレーション出来るのでどれでも良い。 あとは見慣れたウィザードでこれまで通りに仮想マシンを作成するだけだが、仮想マシンの構成ファイルをクラスタ専用領域に指定しなければならない点に注意すること。 これで、マイグレーション可能なHyper-Vクラスタが構築できた。 あとはマイグレーションのテストや障害発生のテストを粛々とするとよい。 動作検証メモ ライブマイグレーションの挙動 ゲストOS 可否 WindowsServer2016 OK CentOS7. 4 NG 恐らくLinux系はライブマイグレーション不可なのではないかと。 ライブマイグレーション実行時の仮想マシンの挙動は以下のように想定される。 指定先クラスタノードに仮想マシンを移動• 仮想マシンを再開 クイックマイグレーションの挙動 ゲストOS 可否 WindowsServer2016 OK CentOS7. 4 OK Windows・LinuxともにOK クイックマイグレーションの仮想マシンの挙動は以下のように想定される。 仮想マシンを一時停止• 指定先クラスタノードに仮想マシンを移動• 仮想マシンを再開 フェールオーバーの挙動 ゲストOS 可否 WindowsServer2016 OK CentOS7. 4 OK フェイルオーバー発生時の仮想マシンの挙動は以下のように想定される。 電源断 故意の障害発生• クラスタノードに通信が出来なくなったことをクラスタが検知• 5分程度待機• 有効なクラスタノードに仮想マシンを移動 優先順位は設定できるが、場合によりけり• 仮想マシンを起動 自動で生きているノードで起動しようとするが、結局は電源断が発生しているので仮想マシンが壊れる可能性がある。 フェイルオーバー後の障害ノード復旧後の挙動 例えばホストサーバー2が異常終了後、復旧させると有効なクラスタノードとして再認識される ただし、フェイルオーバーで移動した仮想マシンは戻らない。 フェールバックが無効になっているから? 気になる点として、復旧までの時間にActiveDirectoryみたいに時間制限があるのかどうかが気になる。 ActiveDirectoryはあまりにも長い時間復旧しないと、復旧が難しくなる。 フェイルオーバーに関して WindowsServer2012R2時代のクラスターはノード障害を検知すると即座にフェイルオーバーしていたが、WindowsServer2016のクラスターは猶予時間 4分 がある模様。 実機上でブルースクリーンを疑似的に発生させてみたがフェイルオーバーせず、2-3分ほどでノードが再起動完了してしまうためフェイルオーバーに至らなかった。 この設定を変更するには以下のコマンドをいずれかのノード上のPowerShellで実行すれば変更できた。

次の