vSphere Storage Applianceの認定ルールが変更されました
個人的に注目していたVSAですが、サーバー機種に対して認定されている必要があり、主要ベンダーの製品がほとんど認定されていなかったため、使用する機会がほとんどありませんでした。
1年以上前のエントリーですが・・・。
vSphere Storage Appliance って使えるの？
この認定ルールが、つい先日変更されました。
Major HCL changes for the vSphere Storage Appliance (VSA)
上記によると、これまでサーバー機種に対して認定されていたのが、RAIDコントローラーに対する認定に変更されたようです。
これにより、認定の敷居が大幅に下がることになるので、これから提案・構築する機会が増えるかもしれません。
ちなみに、2012/12/19現在、認定されているRAIDコントローラーはかなり少ないです。。。
Dellの製品が半分程度で、IBMやHPの製品はまだほとんど掲載されていないですね。
これから認定製品が増えることを期待したいと思います！
1年以上前のエントリーですが・・・。
vSphere Storage Appliance って使えるの？
この認定ルールが、つい先日変更されました。
Major HCL changes for the vSphere Storage Appliance (VSA)
上記によると、これまでサーバー機種に対して認定されていたのが、RAIDコントローラーに対する認定に変更されたようです。
これにより、認定の敷居が大幅に下がることになるので、これから提案・構築する機会が増えるかもしれません。
ちなみに、2012/12/19現在、認定されているRAIDコントローラーはかなり少ないです。。。
Dellの製品が半分程度で、IBMやHPの製品はまだほとんど掲載されていないですね。
これから認定製品が増えることを期待したいと思います！
Windows Server 2012 Hyper-V ゲストOSの監視機能 ②
前回のエントリーの続きです。
Windows Server 2012 Hyper-V ゲストOSの監視機能 ①
仮想マシンの応答監視を有効にしている状態で、ゲストOSにBSODが発生したらどうなるのか、実際に試してみました。
まず結果を書くと、以下のようになりました。
上記を見ると分かるように、ゲストOSのBSODが発生してから約1-2分で再起動が実行されました。
いろいろと設定を確認してみましたが、この「1-2分」という間隔については変更ができないようです。
おそらく、ゲストOS内で動作しているハートビートサービスが送信しているハートビートの間隔に依存しているのでしょう。
修復の挙動としては、まず同一のHyper-Vホスト上で再起動を試みます。
再びBSODが発生すると、他のHyper-Vホストに仮想マシンをフェールオーバーした上で、再起動を試みます。
フェールオーバークラスターのイベントログにも、きちんと関連するイベントが記録されます。
なお、上記はデフォルト設定の場合の挙動です。
フェールオーバークラスタ－マネージャーの設定で、再起動やフェールオーバーの回数を調節することができます。
まず、同一のHyper-Vホスト上での再起動ですが、デフォルト設定では1回のみ実行されます。
下の画像は、フェールオーバークラスターマネージャーで監視対象の仮想マシンリソースのプロパティを開いた画面です。
「ポリシー」タブの「リソースエラーへの対応」にある「指定期間内での再起動の試行回数」を変更することで、
Hyper-Vホスト上での再起動の試行回数を変更することができます。
デフォルトでは、画像のように「1」となっています。
また、「再起動に失敗した場合は、この役割のすべてのリソースをフェールオーバーする」という箇所が有効になっています。
この設定が有効にされているので、同一のHyper-Vホスト上での再起動に失敗した後にBSODが発生すると他のHyper-Vホスト上での再起動を試みます。
さらに、「再起動がすべて失敗した場合は、指定した期間後にもう一度再起動を開始する」という箇所に「1時間」という値が設定されています。
この設定によって、冒頭に書いたデフォルト設定の挙動にあるように、
一通りの再起動に失敗するとリソースを「失敗」状態に切り替え、1時間後に再起動を試みます。(最初の図の④→⑤の部分です。)
続いて、他のHyper-Vホストへのフェールオーバーを実行する回数も設定可能です。
これは、フェールオーバークラスターマネージャーで監視対象の仮想マシンのプロパティから設定できます。
「フェールオーバー」タブにある、「指定した期間内の最大エラー数」がデフォルトでは「1」に設定されているので、
他のHyper-Vホストへのフェールオーバー回数は1回だけ行われ、2回目はフェールオーバーせず、仮想マシンを「失敗」状態に切り替えます。
この設定を、例えば「2」に変更すると、最初の図の④の部分で、再び他のHyper-Vホストにフェールオーバーして再起動を試みます。
さらに失敗が続くと、仮想マシンを「失敗」状態に切り替えて放置することになります。
少し複雑ではありますが・・・・、
このようにWindows Server 2012 Hyper-VのゲストOSの応答監視は、かなり細かく挙動を設定することができるようになっています。
うまく活用して、仮想マシンのダウンタイムを最小化できるようにしたいものです。
Windows Server 2012 Hyper-V ゲストOSの監視機能 ①
仮想マシンの応答監視を有効にしている状態で、ゲストOSにBSODが発生したらどうなるのか、実際に試してみました。
まず結果を書くと、以下のようになりました。
上記を見ると分かるように、ゲストOSのBSODが発生してから約1-2分で再起動が実行されました。
いろいろと設定を確認してみましたが、この「1-2分」という間隔については変更ができないようです。
おそらく、ゲストOS内で動作しているハートビートサービスが送信しているハートビートの間隔に依存しているのでしょう。
修復の挙動としては、まず同一のHyper-Vホスト上で再起動を試みます。
再びBSODが発生すると、他のHyper-Vホストに仮想マシンをフェールオーバーした上で、再起動を試みます。
フェールオーバークラスターのイベントログにも、きちんと関連するイベントが記録されます。
なお、上記はデフォルト設定の場合の挙動です。
フェールオーバークラスタ－マネージャーの設定で、再起動やフェールオーバーの回数を調節することができます。
まず、同一のHyper-Vホスト上での再起動ですが、デフォルト設定では1回のみ実行されます。
下の画像は、フェールオーバークラスターマネージャーで監視対象の仮想マシンリソースのプロパティを開いた画面です。
「ポリシー」タブの「リソースエラーへの対応」にある「指定期間内での再起動の試行回数」を変更することで、
Hyper-Vホスト上での再起動の試行回数を変更することができます。
デフォルトでは、画像のように「1」となっています。
また、「再起動に失敗した場合は、この役割のすべてのリソースをフェールオーバーする」という箇所が有効になっています。
この設定が有効にされているので、同一のHyper-Vホスト上での再起動に失敗した後にBSODが発生すると他のHyper-Vホスト上での再起動を試みます。
さらに、「再起動がすべて失敗した場合は、指定した期間後にもう一度再起動を開始する」という箇所に「1時間」という値が設定されています。
この設定によって、冒頭に書いたデフォルト設定の挙動にあるように、
一通りの再起動に失敗するとリソースを「失敗」状態に切り替え、1時間後に再起動を試みます。(最初の図の④→⑤の部分です。)
続いて、他のHyper-Vホストへのフェールオーバーを実行する回数も設定可能です。
これは、フェールオーバークラスターマネージャーで監視対象の仮想マシンのプロパティから設定できます。
「フェールオーバー」タブにある、「指定した期間内の最大エラー数」がデフォルトでは「1」に設定されているので、
他のHyper-Vホストへのフェールオーバー回数は1回だけ行われ、2回目はフェールオーバーせず、仮想マシンを「失敗」状態に切り替えます。
この設定を、例えば「2」に変更すると、最初の図の④の部分で、再び他のHyper-Vホストにフェールオーバーして再起動を試みます。
さらに失敗が続くと、仮想マシンを「失敗」状態に切り替えて放置することになります。
少し複雑ではありますが・・・・、
このようにWindows Server 2012 Hyper-VのゲストOSの応答監視は、かなり細かく挙動を設定することができるようになっています。
うまく活用して、仮想マシンのダウンタイムを最小化できるようにしたいものです。
Windows Server 2012 Hyper-V ゲストOSの監視機能 ①
前回のエントリーから、随分と時間が経過してしまいました。
Windows Server 2012 Hyper-Vの仮想マシン内サービスの監視機能 ①
Windows Server 2012 Hyper-Vの仮想マシン内サービスの監視機能 ②
前回は、ゲストOSの中で動いているサービスの監視機能について書きました。
今回は、ゲストOSそのものの稼働監視を行う機能について書きます。
例えば、ゲストOSがブルースクリーン(BSOD)になった場合、そのまま放置されると当然困ります。
何らかの仕組みでゲストOSのBSODを検知し、自動的に修復してくれるとありがたいわけです。
Windows Server 2012 Hyper-Vでは、ゲストOSのBSODやフリーズを検知し、自動的に仮想マシンの再起動を行うことで修復する機能があります。
いろいろ検証を行なってみて、いくつか分かったことがあるので、簡単に記録を残しておきたいと思います。
まず、ゲストOSの応答停止を検知する仕組みです。
ゲストOSにHyper-Vの統合サービスを導入すると、「Hyper-V HeartBeat Service」というサービスが動作します。このサービスが定期的にハートビートを送信することで、ゲストOSの応答をHyper-Vホストが確認できるようになります。
ハートビートの切断を検知すると、あらかじめ設定されたフェールオーバーポリシーにしたがって修復を試みます。(ポリシーについては、次回のエントリーで触れようと思います。)
自動修復を実行するために必要な設定は、フェールオーバークラスターマネージャーで行います。
フェールオーバークラスターマネージャーで監視対象の仮想マシンのプロパティを開くと、以下のような画面が表示されます。
「ハートビート設定」の「仮想マシンでのハートビートモニタリングを有効にする」という項目にチェックが入っていれば、先ほど書いたハートビートの仕組みを使って、仮想マシンの応答を監視するようになります。
ちなみに、Windows Server 2008 R2のHyper-V 2.0では、デフォルトでこの監視機能は無効にされていました。Windows Server 2012 Hyper-Vではデフォルトで有効になっているので、特に手動で設定を行う必要はありません。
次回のエントリーでは、実際にゲストOSでBSODを発生させた場合にどのような挙動をするのか、という点について書きたいと思います。
Windows Server 2012 Hyper-Vの仮想マシン内サービスの監視機能 ①
Windows Server 2012 Hyper-Vの仮想マシン内サービスの監視機能 ②
前回は、ゲストOSの中で動いているサービスの監視機能について書きました。
今回は、ゲストOSそのものの稼働監視を行う機能について書きます。
例えば、ゲストOSがブルースクリーン(BSOD)になった場合、そのまま放置されると当然困ります。
何らかの仕組みでゲストOSのBSODを検知し、自動的に修復してくれるとありがたいわけです。
Windows Server 2012 Hyper-Vでは、ゲストOSのBSODやフリーズを検知し、自動的に仮想マシンの再起動を行うことで修復する機能があります。
いろいろ検証を行なってみて、いくつか分かったことがあるので、簡単に記録を残しておきたいと思います。
まず、ゲストOSの応答停止を検知する仕組みです。
ゲストOSにHyper-Vの統合サービスを導入すると、「Hyper-V HeartBeat Service」というサービスが動作します。このサービスが定期的にハートビートを送信することで、ゲストOSの応答をHyper-Vホストが確認できるようになります。
ハートビートの切断を検知すると、あらかじめ設定されたフェールオーバーポリシーにしたがって修復を試みます。(ポリシーについては、次回のエントリーで触れようと思います。)
自動修復を実行するために必要な設定は、フェールオーバークラスターマネージャーで行います。
フェールオーバークラスターマネージャーで監視対象の仮想マシンのプロパティを開くと、以下のような画面が表示されます。
「ハートビート設定」の「仮想マシンでのハートビートモニタリングを有効にする」という項目にチェックが入っていれば、先ほど書いたハートビートの仕組みを使って、仮想マシンの応答を監視するようになります。
ちなみに、Windows Server 2008 R2のHyper-V 2.0では、デフォルトでこの監視機能は無効にされていました。Windows Server 2012 Hyper-Vではデフォルトで有効になっているので、特に手動で設定を行う必要はありません。
次回のエントリーでは、実際にゲストOSでBSODを発生させた場合にどのような挙動をするのか、という点について書きたいと思います。
vSphere ClientとWeb Clientの違い
vSphere 5.1ではWeb Clientの使用が推奨されているのか、Web Clientでなければ使えない機能がいくつかあります。
vSphere Data ProtectionやvSphere Replicationあたりが代表的な例ですね。
これまでは、vSphere Clientを使って管理を行うのが一般的でしたが、これからはWeb Clientによる管理が一般的になっていくのかもしれません。
ところで、vSphere ClientとWeb Clientは、それぞれできることとできないことがあります。
以下のblogで違いが整理されていましたので紹介したいと思います。
Which vSphere client should I use and when?
こちらを見る限り、やはりWeb Clientの方ができることが多そうです。
共有ストレージなしのvMotionも、Web Clientが必要なのですね。
vSphere Data ProtectionやvSphere Replicationあたりが代表的な例ですね。
これまでは、vSphere Clientを使って管理を行うのが一般的でしたが、これからはWeb Clientによる管理が一般的になっていくのかもしれません。
ところで、vSphere ClientとWeb Clientは、それぞれできることとできないことがあります。
以下のblogで違いが整理されていましたので紹介したいと思います。
Which vSphere client should I use and when?
こちらを見る限り、やはりWeb Clientの方ができることが多そうです。
共有ストレージなしのvMotionも、Web Clientが必要なのですね。
XenApp 6.5の初期構成時に外部SQLサーバーとの接続テストでエラーが出る
XenApp 6.5を初めてインストールしましたが、外部SQL Serverとの接続で詰まりました。
既存のSQL Serverを使用する場合、XenAppで新しいファームを作成するときにSQL Serverのサーバー名やデータベース名を入力します。
適当に入れてしまうと、次の段階で行う「接続のテスト」が見事に失敗します。
いろいろ試した結果、以下でテストに成功しました。
以下は、外部SQL Serverとして、SQL Server 2008 R2 Express Editionを使用した場合の例です。
ちなみに今回は検証目的で構築したこともあり、設定の妥当性については一切考慮していない点にはご注意ください・・・。
・ファーム作成時、データベースサーバー名には「ホスト名\インスタンス名,1433」という形式で入力 (ex: dbserver\sqlexpress,1433)
・SQL Serverで構成マネージャーを使用し、「TCP/IP」を有効化
・「TCP/IP」のプロパティで、接続するIPアドレスを有効化
・「TCP/IP」のプロパティで、「IPAll」の動的ポートの欄を空白にし、「TCPポート」に「1433」を指定
他にもいろいろといじったかもしれませんが、同じ問題に遭遇されている方は、とりあえず上記を試してみてください。
最初のデータベースサーバー名の入力形式が、一番大きいかなと思います。
既存のSQL Serverを使用する場合、XenAppで新しいファームを作成するときにSQL Serverのサーバー名やデータベース名を入力します。
適当に入れてしまうと、次の段階で行う「接続のテスト」が見事に失敗します。
いろいろ試した結果、以下でテストに成功しました。
以下は、外部SQL Serverとして、SQL Server 2008 R2 Express Editionを使用した場合の例です。
ちなみに今回は検証目的で構築したこともあり、設定の妥当性については一切考慮していない点にはご注意ください・・・。
・ファーム作成時、データベースサーバー名には「ホスト名\インスタンス名,1433」という形式で入力 (ex: dbserver\sqlexpress,1433)
・SQL Serverで構成マネージャーを使用し、「TCP/IP」を有効化
・「TCP/IP」のプロパティで、接続するIPアドレスを有効化
・「TCP/IP」のプロパティで、「IPAll」の動的ポートの欄を空白にし、「TCPポート」に「1433」を指定
他にもいろいろといじったかもしれませんが、同じ問題に遭遇されている方は、とりあえず上記を試してみてください。
最初のデータベースサーバー名の入力形式が、一番大きいかなと思います。