Windows Server 2012 Hyper-Vの仮想マシン内サービスの監視機能 ②
前回のエントリーの続きです。
Windows Server 2012 Hyper-Vの仮想マシン内サービスの監視機能 ①
「監視対象のサービスに障害が発生した場合、どのような挙動をするのか？」という点についてですが、以下のようにまとめてみました。
下記は、「Print Spooler」サービスを監視対象とした場合の例です。
デフォルト設定では、サービスの再起動を2回試みます。
それでも解決しない場合は、クラスターに障害を通知します。
通知を受けたクラスターは、仮想マシンを同一のHyper-Vホスト上で再起動します。
それでも解決しない場合は、仮想マシンを別のHyper-Vホストで再起動します。
ゲストOS内のサービス障害をクラスターが検知できる、という点が最大のポイントですね。
クラスターのイベントログにも、障害イベントが記録されます。イベントIDは1250です。
なお、最初の2回のサービス再起動は、ゲストOS内の監視対象サービスのプロパティにある回復操作の設定に依存します。
以下のように、最初のエラーと次のエラーでサービスを再起動する設定になっているため、2回の再起動を行うようになっています。
ユーザーによっては、「サービス障害をクラスターで検知したいが、仮想マシンを自動的に再起動するのは困る」という場合もあるでしょう。
その場合は、仮想マシンリソースのプロパティで「アプリケーションの健全性の監視で自動回復を有効にする」オプションを無効化すればよいです。
無効化すると、仮想マシンの再起動は行いませんが、クラスターのイベントログにイベントは記録されます。
次回は、仮想マシンそのもののハートビート監視について書きたいと思います。
Windows Server 2012 Hyper-Vの仮想マシン内サービスの監視機能 ①
「監視対象のサービスに障害が発生した場合、どのような挙動をするのか？」という点についてですが、以下のようにまとめてみました。
下記は、「Print Spooler」サービスを監視対象とした場合の例です。
デフォルト設定では、サービスの再起動を2回試みます。
それでも解決しない場合は、クラスターに障害を通知します。
通知を受けたクラスターは、仮想マシンを同一のHyper-Vホスト上で再起動します。
それでも解決しない場合は、仮想マシンを別のHyper-Vホストで再起動します。
ゲストOS内のサービス障害をクラスターが検知できる、という点が最大のポイントですね。
クラスターのイベントログにも、障害イベントが記録されます。イベントIDは1250です。
なお、最初の2回のサービス再起動は、ゲストOS内の監視対象サービスのプロパティにある回復操作の設定に依存します。
以下のように、最初のエラーと次のエラーでサービスを再起動する設定になっているため、2回の再起動を行うようになっています。
ユーザーによっては、「サービス障害をクラスターで検知したいが、仮想マシンを自動的に再起動するのは困る」という場合もあるでしょう。
その場合は、仮想マシンリソースのプロパティで「アプリケーションの健全性の監視で自動回復を有効にする」オプションを無効化すればよいです。
無効化すると、仮想マシンの再起動は行いませんが、クラスターのイベントログにイベントは記録されます。
次回は、仮想マシンそのもののハートビート監視について書きたいと思います。
Windows Server 2012 Hyper-Vの仮想マシン内サービスの監視機能 ①
最近、とある理由からWindows Server 2012 Hyper-Vの検証をしています。
検証でいろいろと分かったことがありますが、今回は仮想マシン内で稼働するサービスの監視機能について書きます。
Windows Server 2012 Hyper-Vでは、Windowsのクラスターの機能を使って仮想マシン内のサービスを監視できるようになっています。
仮想マシンで動いているサービスに障害が発生すると、自動的にサービスの再起動を行ったり、仮想マシン自体の再起動を行ったりすることができます。
この監視機能を使用するための要件は、以下のとおりです。
①ペアレントOSとゲストOSがどちらもWindows Server 2012であること
②Windowsファイアウォールで「仮想マシンの監視」トラフィックが許可されていること
③ゲストOSはペアレントOSと同一もしくは信頼関係にあるドメインに参加していること
①の要件が重要ですね。今のところ、ゲストOSとしてはWindows Server 2012が必須です。
厳密には、③については必須ではなく、ドメインの要件を満たされていない場合でもPowerShellによる監視設定はできるようです。（後述するGUIでの設定ができない。）
が、まだ実機で確認できていないので、未確認情報です。。。
設定方法は、非常に簡単です。
フェールオーバークラスターマネージャーで仮想マシンを右クリックし、「他のアクション」から「監視の構成」を選択します。
続いて、ゲストOS内で稼働しているサービスの一覧が表示されます。
この中から、監視対象にしたサービスのチェックボックスにチェックを入れます。
設定はこれだけです。非常に簡単です。
次回は、実際にサービス障害が発生した場合の挙動について書きます。
検証でいろいろと分かったことがありますが、今回は仮想マシン内で稼働するサービスの監視機能について書きます。
Windows Server 2012 Hyper-Vでは、Windowsのクラスターの機能を使って仮想マシン内のサービスを監視できるようになっています。
仮想マシンで動いているサービスに障害が発生すると、自動的にサービスの再起動を行ったり、仮想マシン自体の再起動を行ったりすることができます。
この監視機能を使用するための要件は、以下のとおりです。
①ペアレントOSとゲストOSがどちらもWindows Server 2012であること
②Windowsファイアウォールで「仮想マシンの監視」トラフィックが許可されていること
③ゲストOSはペアレントOSと同一もしくは信頼関係にあるドメインに参加していること
①の要件が重要ですね。今のところ、ゲストOSとしてはWindows Server 2012が必須です。
厳密には、③については必須ではなく、ドメインの要件を満たされていない場合でもPowerShellによる監視設定はできるようです。（後述するGUIでの設定ができない。）
が、まだ実機で確認できていないので、未確認情報です。。。
設定方法は、非常に簡単です。
フェールオーバークラスターマネージャーで仮想マシンを右クリックし、「他のアクション」から「監視の構成」を選択します。
続いて、ゲストOS内で稼働しているサービスの一覧が表示されます。
この中から、監視対象にしたサービスのチェックボックスにチェックを入れます。
設定はこれだけです。非常に簡単です。
次回は、実際にサービス障害が発生した場合の挙動について書きます。
VMwareとHyper-VのLACPへの対応状況
小ネタに近いですが。。。
NICチーミングで複数の物理NICを束ねて帯域を増やす場合、いわゆるIEEE 802,3adの規格に対応した対向スイッチが必要になります。
同時に、VMwareやWindows Server 2012 Hyper-Vの場合は、ハイパーバイザーのNICチーミング機能を使うため、NICチーミング機能側でも対応が必要になります。
①VMwareの対応状況
静的EtherChannelについては、ESX3.xの時代からサポート済みです。
VMware KB: Sample configuration of EtherChannel / Link aggregation with ESXi/ESX and Cisco/HP switches
ただし、LACPについてはvSphere 5.1になって、ようやくサポートされました。
この点については、上記のKB1004048の文中に記載されています。
一応、以下のようなKBも出ているのですが、少し分かり辛いです。
VMware KB: Does ESX/ESXi 4.0, 4.1 & ESXi 5.x support 802.3ad Dynamic?
②Windows Server 2012 Hyper-Vの対応状況
Hyper-Vについては、Windows Server 2012からOSの機能でNICチーミングができるようになりました。
「チーミングモード」というパラメータの中に、「スタティック」と「LACP」という項目があります。
実機では確認していないのですが、これを見る限り、LACPには対応していると考えて問題ないでしょう。
どちらかというと、VMwareについては注意が必要ですね。
vSphere 5.1以外のバージョンについては、LACPがサポートされていません。
対向スイッチの選定や設定を行う際にご注意ください。
NICチーミングで複数の物理NICを束ねて帯域を増やす場合、いわゆるIEEE 802,3adの規格に対応した対向スイッチが必要になります。
同時に、VMwareやWindows Server 2012 Hyper-Vの場合は、ハイパーバイザーのNICチーミング機能を使うため、NICチーミング機能側でも対応が必要になります。
①VMwareの対応状況
静的EtherChannelについては、ESX3.xの時代からサポート済みです。
VMware KB: Sample configuration of EtherChannel / Link aggregation with ESXi/ESX and Cisco/HP switches
ただし、LACPについてはvSphere 5.1になって、ようやくサポートされました。
この点については、上記のKB1004048の文中に記載されています。
一応、以下のようなKBも出ているのですが、少し分かり辛いです。
VMware KB: Does ESX/ESXi 4.0, 4.1 & ESXi 5.x support 802.3ad Dynamic?
②Windows Server 2012 Hyper-Vの対応状況
Hyper-Vについては、Windows Server 2012からOSの機能でNICチーミングができるようになりました。
「チーミングモード」というパラメータの中に、「スタティック」と「LACP」という項目があります。
実機では確認していないのですが、これを見る限り、LACPには対応していると考えて問題ないでしょう。
どちらかというと、VMwareについては注意が必要ですね。
vSphere 5.1以外のバージョンについては、LACPがサポートされていません。
対向スイッチの選定や設定を行う際にご注意ください。
知っておきたいVMFSの制限事項
構成上の制限という意味では、VMwareから「構成の上限」というガイドが出ています。
このエントリーでは、構成の上限ガイドに書かれていない重要な制限事項を2つ紹介したいと思います。
まず、一つ目。
①1台のESXiホストからアクセス可能なVMFS上の仮想ディスクサイズはデフォルトで8TBまで
詳細は、以下のKBに書かれています。
VMware KB: An ESXi/ESX host reports VMFS heap warnings when hosting virtual machines that collectively use 4 TB or 20 TB of virtual disk storage
VMFSにはヒープサイズのパラメータがあり、ESXi5.xではデフォルトで80MBに設定されています。
この場合、1台のホストから8TBまでの仮想ディスクにアクセスすることができます。
ヒープサイズの最大値は256MBであり、この値では25TBまでアクセス可能です。
例えば、仮想ディスクvmdkを2TB単位で作成し、複数の仮想ディスクを1台の仮想マシンに認識させるような場合に注意が必要です。
合計で8TBを超えると、あるタイミングでI/Oが停止したり、レスポンスが低下したりする可能性があります。
次に、二つ目。
②VMFSデータストア上のファイルを共有可能なホスト台数
ESXi 5.1では、VMFSデータストア上の読み取り専用ファイルを共有可能なホストの台数が32台に拡張されています。
旧バージョンでは、8台まででした。
詳細は、こちらに記載されています。
vSphere 5.1 Storage Enhancements – Part 1: VMFS-5 |
32台という数字は十分すぎるように思えます。確かに十分な台数です。
ただし、VMware View環境では注意が必要です。
VMware View環境の場合、このファイル共有の台数制限が8台になります。32台ではありません。
特に、Linked Cloneを使う場合に注意が必要です。
この点については、先日出たばかりのホワイトペーパーに書かれています。
VMFS File Locking and Its Impact in VMware View 5.1
このような上限値は、冒頭で触れた「構成の上限」にまとめておいてもらえると非常に助かるのですが・・・。
現時点では、上記のKBやホワイトペーパーで情報を拾うしかありません。
KBは頻繁に公開や修正が行われるので、要チェックですね！
このエントリーでは、構成の上限ガイドに書かれていない重要な制限事項を2つ紹介したいと思います。
まず、一つ目。
①1台のESXiホストからアクセス可能なVMFS上の仮想ディスクサイズはデフォルトで8TBまで
詳細は、以下のKBに書かれています。
VMware KB: An ESXi/ESX host reports VMFS heap warnings when hosting virtual machines that collectively use 4 TB or 20 TB of virtual disk storage
VMFSにはヒープサイズのパラメータがあり、ESXi5.xではデフォルトで80MBに設定されています。
この場合、1台のホストから8TBまでの仮想ディスクにアクセスすることができます。
ヒープサイズの最大値は256MBであり、この値では25TBまでアクセス可能です。
例えば、仮想ディスクvmdkを2TB単位で作成し、複数の仮想ディスクを1台の仮想マシンに認識させるような場合に注意が必要です。
合計で8TBを超えると、あるタイミングでI/Oが停止したり、レスポンスが低下したりする可能性があります。
次に、二つ目。
②VMFSデータストア上のファイルを共有可能なホスト台数
ESXi 5.1では、VMFSデータストア上の読み取り専用ファイルを共有可能なホストの台数が32台に拡張されています。
旧バージョンでは、8台まででした。
詳細は、こちらに記載されています。
vSphere 5.1 Storage Enhancements – Part 1: VMFS-5 |
32台という数字は十分すぎるように思えます。確かに十分な台数です。
ただし、VMware View環境では注意が必要です。
VMware View環境の場合、このファイル共有の台数制限が8台になります。32台ではありません。
特に、Linked Cloneを使う場合に注意が必要です。
この点については、先日出たばかりのホワイトペーパーに書かれています。
VMFS File Locking and Its Impact in VMware View 5.1
このような上限値は、冒頭で触れた「構成の上限」にまとめておいてもらえると非常に助かるのですが・・・。
現時点では、上記のKBやホワイトペーパーで情報を拾うしかありません。
KBは頻繁に公開や修正が行われるので、要チェックですね！
VMFSのUUIDについて考える②
VMFSのUUIDについて考える①
前回のエントリーの続きです。
UUIDが重複している2つのボリュームを、同時に単一のESXiホストにマウントすることはできません。
この場合、片方のボリュームのUUIDを書き換えること(再署名)でマウントが可能になります。
vSphere 5.xであれば、vSphere ClientのGUIで再署名ができます。
一連の手順について確認しました。
①10GBのボリュームを作成し、VMFSデータストアとしてESXiホストにマウント
②①で作成したボリュームをストレージの機能で複製
③複製したボリュームのUUIDを書き換えてESXiホストにマウント
①「UUID_Original」という名前で10GBのVMFSデータストアを作成します。
このデータストアのUUIDは、以下のコマンドで確認できます。
②ストレージの機能で「UUID_Original」データストアを複製します。
複製先ボリュームのように、同じUUIDを持つボリュームは「snapshot LUN」と呼ばれます。
ESXiホストの接続先にsnapshot LUNが存在するかどうかは、以下のコマンドで確認可能です。
以下の例では、「UUID_Original」データストアのsnapshot LUNが存在していることを表しています。
③snapshot LUNをESXiホストにマウントします。
vSphere Clientで新しいデータストアを追加します。
データストアの追加ウィザードでsnapshot LUNを選択すると、以下のような画面が表示されます。
「Assign a new signature」を選択することで、UUIDの書き換えを行い、マウントできるようにします。
マウントすると、以下のように「snap-xxxxxxx-<オリジナルLUN名>」というラベルが自動的に設定されます。
esxcliコマンドを実行すると、以下のように出力されます。
UUIDを書き換えたことでsnapshot LUNがなくなったため、esxcli storage vmfs snapshot listコマンドの結果は空になります。
また、各データストアのUUIDを確認すると、異なるUUIDが設定されていることが分かります。
以下のKBにも詳細が書かれているので、参考にしてください！
VMware KB: vSphere handling of LUNs detected as Snapshot LUNs
http://kb.vmware.com/kb/1011387
前回のエントリーの続きです。
UUIDが重複している2つのボリュームを、同時に単一のESXiホストにマウントすることはできません。
この場合、片方のボリュームのUUIDを書き換えること(再署名)でマウントが可能になります。
vSphere 5.xであれば、vSphere ClientのGUIで再署名ができます。
一連の手順について確認しました。
①10GBのボリュームを作成し、VMFSデータストアとしてESXiホストにマウント
②①で作成したボリュームをストレージの機能で複製
③複製したボリュームのUUIDを書き換えてESXiホストにマウント
①「UUID_Original」という名前で10GBのVMFSデータストアを作成します。
このデータストアのUUIDは、以下のコマンドで確認できます。
②ストレージの機能で「UUID_Original」データストアを複製します。
複製先ボリュームのように、同じUUIDを持つボリュームは「snapshot LUN」と呼ばれます。
ESXiホストの接続先にsnapshot LUNが存在するかどうかは、以下のコマンドで確認可能です。
以下の例では、「UUID_Original」データストアのsnapshot LUNが存在していることを表しています。
③snapshot LUNをESXiホストにマウントします。
vSphere Clientで新しいデータストアを追加します。
データストアの追加ウィザードでsnapshot LUNを選択すると、以下のような画面が表示されます。
「Assign a new signature」を選択することで、UUIDの書き換えを行い、マウントできるようにします。
マウントすると、以下のように「snap-xxxxxxx-<オリジナルLUN名>」というラベルが自動的に設定されます。
esxcliコマンドを実行すると、以下のように出力されます。
UUIDを書き換えたことでsnapshot LUNがなくなったため、esxcli storage vmfs snapshot listコマンドの結果は空になります。
また、各データストアのUUIDを確認すると、異なるUUIDが設定されていることが分かります。
以下のKBにも詳細が書かれているので、参考にしてください！
VMware KB: vSphere handling of LUNs detected as Snapshot LUNs
http://kb.vmware.com/kb/1011387