【VMware】vSphere 5.0 u1 におけるVMware HAの仕様変更
全く気が付きませんでしたが、vSphere 5.0 update 1では、VMware HAに関する仕様変更があるそうです。
Slight change in “restart” behavior for HA with vSphere 5.0 Update 1
上記のブログによると、変更点は以下になります。
・各ESXホストや仮想マシンの情報をprotectedlistファイルだけでなく、vCenterからも取得できるようになった
・複数のマスターが存在する場合に、各マスターがHAトリガー時に仮想マシンの再起動を実行できるようになった
最初この記事を読んだときは、さっぱりわかりませんでした。
いろいろと調べていくうちに、ようやく意味が分かりかけてきたので、備忘録としてメモを残したいと思います・・・。
まずは、protectedlistファイルについてです。
vSphere 5.0環境でVMware HAを初めて構成すると、HAクラスターの中でマスターとなるESXiホストが1台選出されます。
そして、protectedlistファイルが、HAクラスター内に存在する仮想マシンが稼働しているすべてのデータストアで生成されます。
このファイルには、そのデータストアに存在する仮想マシンの情報が記録されています。
すなわち、VMware HAの保護対象の仮想マシンについて記録されていることになります。
このprotectedlistファイルは、HAクラスターのマスターとして選出されたESXiホストが所有権を持ち、排他的ロックをかけます。
こうすることで、マスターではない他のESXiホスト（スレーブ）は、マスターがクラスター内に存在することを知ることができます。
マスターが、スレーブのダウンもしくは隔離状態を検知すると、マスターがそのスレーブで稼働している仮想マシンの再起動を実行します。
マスターは、protectedlistファイルを参照することで、再起動対象の仮想マシンを判断しています。
ここでポイントとなるのは、protectedlistファイルを所有できるのは1台のマスターに限られる、という点です。
排他的ロックをかけるので、1台に限られるわけです。
したがって、複数のマスターが存在するような事態に陥った場合、protectedlistファイルを所有できないマスターが発生します。
今回の仕様のアップデートは、このような状態になった場合に意味があるようです。
「複数のマスターが存在するような事態」というのは、通常運用時には発生しません。
しかしながら、ネットワーク障害等で発生する場合があります。
これを、「ネットワークパーティション状態」と呼ぶようですが、このあたりについては次のエントリーで整理しようと思います。
（protectedlistファイルについてメモ書きしたものの、理解不十分な部分がある点はご容赦ください。。。）
Slight change in “restart” behavior for HA with vSphere 5.0 Update 1
上記のブログによると、変更点は以下になります。
・各ESXホストや仮想マシンの情報をprotectedlistファイルだけでなく、vCenterからも取得できるようになった
・複数のマスターが存在する場合に、各マスターがHAトリガー時に仮想マシンの再起動を実行できるようになった
最初この記事を読んだときは、さっぱりわかりませんでした。
いろいろと調べていくうちに、ようやく意味が分かりかけてきたので、備忘録としてメモを残したいと思います・・・。
まずは、protectedlistファイルについてです。
vSphere 5.0環境でVMware HAを初めて構成すると、HAクラスターの中でマスターとなるESXiホストが1台選出されます。
そして、protectedlistファイルが、HAクラスター内に存在する仮想マシンが稼働しているすべてのデータストアで生成されます。
このファイルには、そのデータストアに存在する仮想マシンの情報が記録されています。
すなわち、VMware HAの保護対象の仮想マシンについて記録されていることになります。
このprotectedlistファイルは、HAクラスターのマスターとして選出されたESXiホストが所有権を持ち、排他的ロックをかけます。
こうすることで、マスターではない他のESXiホスト（スレーブ）は、マスターがクラスター内に存在することを知ることができます。
マスターが、スレーブのダウンもしくは隔離状態を検知すると、マスターがそのスレーブで稼働している仮想マシンの再起動を実行します。
マスターは、protectedlistファイルを参照することで、再起動対象の仮想マシンを判断しています。
ここでポイントとなるのは、protectedlistファイルを所有できるのは1台のマスターに限られる、という点です。
排他的ロックをかけるので、1台に限られるわけです。
したがって、複数のマスターが存在するような事態に陥った場合、protectedlistファイルを所有できないマスターが発生します。
今回の仕様のアップデートは、このような状態になった場合に意味があるようです。
「複数のマスターが存在するような事態」というのは、通常運用時には発生しません。
しかしながら、ネットワーク障害等で発生する場合があります。
これを、「ネットワークパーティション状態」と呼ぶようですが、このあたりについては次のエントリーで整理しようと思います。
（protectedlistファイルについてメモ書きしたものの、理解不十分な部分がある点はご容赦ください。。。）
【VMware】ESXi 5.0 Update 1 リリース
3/15に、ESXi 5.0 u1がリリースされていました。
ESXi 5.0のリリースから、もう半年経っているのですね。
VMware ESXi 5.0 Update 1 リリース ノート
新しいCPUやゲストOSのサポート、既知のバグFixが主なアップデート内容のようです。
VMware Toolsもアップデートされているようですね。
ESXi 5.0からアップデートする場合は、併せてゲストOSのVMware Toolsもアップデートする必要がありそうです。
ESXi 5.0のリリースから、もう半年経っているのですね。
VMware ESXi 5.0 Update 1 リリース ノート
新しいCPUやゲストOSのサポート、既知のバグFixが主なアップデート内容のようです。
VMware Toolsもアップデートされているようですね。
ESXi 5.0からアップデートする場合は、併せてゲストOSのVMware Toolsもアップデートする必要がありそうです。
【VMware】vSphere Storage Appliance のRAIDレベル
半年前のエントリーで、VSAのRAIDレベルについて触れました。
vSphere Storage Appliance って使えるの？
http://ameblo.jp/stocker1022/entry-11016211042.html
当時は、RAID10のみ記載されていましたが、いつの間にか情報がアップデートされていました。
以下にさりげなく書かれているのですが、RAID5/6/10がサポートされるようです。
vSphere Storage Appliance
http://www.vmware.com/jp/products/datacenter-virtualization/vsphere/vsphere-storage-appliance/features.html
RAID5とRAID6がいつの間にか追加されていたのですね。
ただ・・・相変わらず、HCLにサーバーが追加されないですね・・・。
情報のアップデートが遅いと思います。
vSphere Storage Appliance って使えるの？
http://ameblo.jp/stocker1022/entry-11016211042.html
当時は、RAID10のみ記載されていましたが、いつの間にか情報がアップデートされていました。
以下にさりげなく書かれているのですが、RAID5/6/10がサポートされるようです。
vSphere Storage Appliance
http://www.vmware.com/jp/products/datacenter-virtualization/vsphere/vsphere-storage-appliance/features.html
RAID5とRAID6がいつの間にか追加されていたのですね。
ただ・・・相変わらず、HCLにサーバーが追加されないですね・・・。
情報のアップデートが遅いと思います。
【KVM】RHEV Managerの導入時にpostgresqlが起動しない
最初に書いておきますが、このブログの著者は、Linuxに関しては素人です。
IPアドレスの設定すらGUIがないとできないレベルです。
そんなLinuxの素人が、果敢にもRHEV3.0の導入にチャレンジしてみたものの・・・
やはり相当つまづきました。。。
今回、手元の環境でRHEV3.0を構築しようと思い立ち、VMware上にRHEL6.2の仮想マシンを作成して、RHEV Managerを導入しました。
そのときにはまったポイントの1つが、タイトルのpostgresql問題です。
RHEV Managerを導入する際、rhevm-setupコマンドを実行します。
基本的な初期パラメータを設定した後に、DBの作成が行われるのですが、
「Creating Database...」という処理のところで「Error」となりました。
いろいろと調べてみると、そもそもpostgresqlが起動していない。。。
以下のガイドの、「Example3.5」の部分ですね。
Chapter 3. Manager Installation
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Installation_Guide/chap-Installation_Guide-Installing_the_RHEV_Manager-Manager.html#sect-Installation_Guide-Installing_the_RHEV_Manager-Packages
何度やってもここではまってしまい、かなり苦労しましたが、結論としてはRHEV Managerを導入するRHEL 6.2に設定した/etc/hostsの内容が原因でした。
今回の環境では、/etc/hostsを編集して、管理対象のKVMホストとRHEV Manager用サーバーの名前解決をしようと考えていました。
そのために、各サーバーのIPアドレスとホスト名を/etc/hostsに記載していたわけですが・・・
デフォルトで設定されている内容を消して、上書きしていたのがまずかったようです。
/etc/hostsに最初から書かれている設定内容は残しておいて、続けてIPアドレスとホスト名の組み合わせを追記しなければならなかったようです。
(Linuxの世界では常識なのかもしれませんが・・・。)
なぜ、/etc/hostsの内容でpostgresqlが起動しなくなるのか全くわかりませんが、同じ問題ではまっている方の一助になれば幸いです。
/etc/hostsのデフォルトの内容は消してはならない！ということですね・・・。
ちなみに、RHEV 3.0からRHEV ManagerをLinux OSに導入することができるようになったようです。
Linuxの扱いに慣れている人にとっては、KVMは非常に扱いやすい仮想化ソリューションになるかもしれません。
私のようにLinuxの素人にとっても、RHEV Managerの管理インターフェースである程度の管理はできるようですので、vCenter ServerやSCVMMといった他の管理ツールと、使い勝手を比較していきたいですね。
IPアドレスの設定すらGUIがないとできないレベルです。
そんなLinuxの素人が、果敢にもRHEV3.0の導入にチャレンジしてみたものの・・・
やはり相当つまづきました。。。
今回、手元の環境でRHEV3.0を構築しようと思い立ち、VMware上にRHEL6.2の仮想マシンを作成して、RHEV Managerを導入しました。
そのときにはまったポイントの1つが、タイトルのpostgresql問題です。
RHEV Managerを導入する際、rhevm-setupコマンドを実行します。
基本的な初期パラメータを設定した後に、DBの作成が行われるのですが、
「Creating Database...」という処理のところで「Error」となりました。
いろいろと調べてみると、そもそもpostgresqlが起動していない。。。
以下のガイドの、「Example3.5」の部分ですね。
Chapter 3. Manager Installation
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Installation_Guide/chap-Installation_Guide-Installing_the_RHEV_Manager-Manager.html#sect-Installation_Guide-Installing_the_RHEV_Manager-Packages
何度やってもここではまってしまい、かなり苦労しましたが、結論としてはRHEV Managerを導入するRHEL 6.2に設定した/etc/hostsの内容が原因でした。
今回の環境では、/etc/hostsを編集して、管理対象のKVMホストとRHEV Manager用サーバーの名前解決をしようと考えていました。
そのために、各サーバーのIPアドレスとホスト名を/etc/hostsに記載していたわけですが・・・
デフォルトで設定されている内容を消して、上書きしていたのがまずかったようです。
/etc/hostsに最初から書かれている設定内容は残しておいて、続けてIPアドレスとホスト名の組み合わせを追記しなければならなかったようです。
(Linuxの世界では常識なのかもしれませんが・・・。)
なぜ、/etc/hostsの内容でpostgresqlが起動しなくなるのか全くわかりませんが、同じ問題ではまっている方の一助になれば幸いです。
/etc/hostsのデフォルトの内容は消してはならない！ということですね・・・。
ちなみに、RHEV 3.0からRHEV ManagerをLinux OSに導入することができるようになったようです。
Linuxの扱いに慣れている人にとっては、KVMは非常に扱いやすい仮想化ソリューションになるかもしれません。
私のようにLinuxの素人にとっても、RHEV Managerの管理インターフェースである程度の管理はできるようですので、vCenter ServerやSCVMMといった他の管理ツールと、使い勝手を比較していきたいですね。
【VMware】vCPUのコア数とライセンスの制限について
VMwareで、仮想マシンに対して仮想CPU(vCPU)を設定する際、vCPU数の他に、コア数を指定することができます。
具体的には、「仮想ソケット数」と「ソケットあたりのコア数」というパラメータが該当します。
ところで、vSphere5.0のライセンスでは、最上位のEnterprise Plusライセンスでは単一の仮想マシンに対して32vCPUまで割り当て可能であり、それ以外のEditionについては8vCPUまで割り当てが可能です。
では、8vCPUまで割り当て可能なStandard Editionを使用する場合、この「仮想ソケット数」と「ソケットあたりのコア数」はそれぞれいくつまで割り当てられるのでしょうか。
これは、単純に「仮想ソケット数 × ソケットあたりのコア数」が8を超えなければOKです。
したがって、仮想ソケット数が「6」であっても、ソケットあたりのコア数を「２」に設定すると、8vCPUの制限を超えてしまうことになります。
この場合、ライセンス違反として、仮想マシンの構成時にエラーが表示されます。
そもそも、この「ソケットあたりのコア数」というパラメータが導入された理由は、ゲストOSの制限で設定可能な「仮想ソケット数」が制限されているような場合に、より多くのCPUリソースを仮想マシンに対して割り当てられるようにする、というものです。
コア数を設定するようなケースは少ないかもしれませんが、設定を行う場合は、上記のライセンスの制限について注意する必要がありますね。
具体的には、「仮想ソケット数」と「ソケットあたりのコア数」というパラメータが該当します。
ところで、vSphere5.0のライセンスでは、最上位のEnterprise Plusライセンスでは単一の仮想マシンに対して32vCPUまで割り当て可能であり、それ以外のEditionについては8vCPUまで割り当てが可能です。
では、8vCPUまで割り当て可能なStandard Editionを使用する場合、この「仮想ソケット数」と「ソケットあたりのコア数」はそれぞれいくつまで割り当てられるのでしょうか。
これは、単純に「仮想ソケット数 × ソケットあたりのコア数」が8を超えなければOKです。
したがって、仮想ソケット数が「6」であっても、ソケットあたりのコア数を「２」に設定すると、8vCPUの制限を超えてしまうことになります。
この場合、ライセンス違反として、仮想マシンの構成時にエラーが表示されます。
そもそも、この「ソケットあたりのコア数」というパラメータが導入された理由は、ゲストOSの制限で設定可能な「仮想ソケット数」が制限されているような場合に、より多くのCPUリソースを仮想マシンに対して割り当てられるようにする、というものです。
コア数を設定するようなケースは少ないかもしれませんが、設定を行う場合は、上記のライセンスの制限について注意する必要がありますね。