vual のすべての投稿

vSphere4環境でAPC製UPSと連携を行うために必要なことまとめ

<環境>

  • UPS APC Smart-UPS
  • ESX vSphere4

<必要な手順>

  1. ESX側にPCNSをインストールする
  2. UPSにESX(PCNS)を登録する
  3. ESXに稼働中のゲストOSをシャットダウンするスクリプトを設置する
  4. PCNSのシャットダウン時に実行されるスクリプトに先のスクリプトを指定する
    <以下格闘の記録>

非HA環境の場合は、ESXのシャットダウン時にゲストOSは連動してシャットダウンされるが、HA環境の場合、ESXの停止がUPSからのシャットダウンなのかホスト障害による停止なのか判別がつかずもう一方のESXにゲストOSをHAしてしまう。

それを回避するため、UPS交換からのシャットダウン指示の場合は、稼働中のゲストOSをシャットダウンしESXを停止するような設定(スクリプト)が必要となる。

現在のところ、PCNSのv2.2.4(最新版)はvSphereのESX,ESXiの 4.0.0 update 1までの対応。ESX,ESXi 4.0.0 update2及び、最新のESX,ESXi 4.1には未対応。

2010/11/02追記

上記の取り消し部分について追記。

2010/10/29付の対応OS表によると4.1および4.0.0 update2に対応したとのこと。ESX、ESXi双方が対応。しかもESXi向けにVIMA用カスタムインストールスクリプトまで用意された。時間が無いので未検証だが、これで一応ESXiでもPCNSが利用出来ることになった。

ここで、ESXとESXiの場合の設定が異なることについてメモ。

ESXにはServiceConsole(COS)があるので、そこにPCNS(ESX版)をインストールする。ESXiにはCOSがないのでVIMA(vMA)という仮想アプライアンスを稼働させ、そこにPCNS(ESXi版)をインストールする。

つまりUPSからのシャットダウンシグナルを前者は直接ESXが受け取り、後者ではVIMA(vMA)が受け取ることになる。

シグナル受信後の振る舞いはPCNSの設定に依存する。通常はShutdown Configurationでシャットダウン時に実行するスクリプトを指定し、Configuration EventsでOn Battery等のイベント時にシャットダウンするよう設定しておく。

設定するスクリプトについてはAPCがサンプルをWEBに公開しているが、一部修正しないと動かなかった。

情報共有のために書いておく。

stopVMs.pl : ESX Server上で稼動しているゲストOSを確認しShutdownを行う。
——
#
# stop running VMs
#
$vmwarecmd = "/usr/bin/vmware-cmd";
# enumerate all VMs
@configs = `$vmwarecmd -l`;
chomp(@configs);
# stop VM if its running
foreach $config (@configs) {
$isalive = `$vmwarecmd "$config" getstate`;
chomp($isalive);
if ($isalive =~ /=.on/) {
print "Stopping $confign";
$retval = `$vmwarecmd "$config" stop`;

$retval = `$vmwarecmd "$config" stop soft`;

}
}
——
stopHAs.sh : stopVMsの呼び出し用シェルスクリプト。
——
/usr/bin/perl /usr/local/bin/PowerChute/stopVMs.pl

——

vmware-cmdの仮想マシンの停止を行うコマンドで、stop soft(=シャットダウン)するように明示しないといけない模様。

stopHAs.shをPCNSのShutdown Scriptで指定してやれば、UPSからの信号受信時にスクリプトが実行され稼働中のゲストOSが停止する。

動作確認がとれているのはESXのみだが、同様の理屈でESXi(VIMA(vMA))でも稼働するはず…なのだが、VIMA(vMA)がUPSからのシャットダウン信号を受信してもシャットダウンがかからない、という状況。

結果的にはESXiでの実装を諦め、ESXでの実装に切替えた。

VMware、及びAPCから正式なドキュメントが出ていない状況なので、しばらくESXiの実装は避けようと思う。

ESXi 4.1とPowerChuteNetworkShutdownでハマり中

ESXi 4.1でUPS(APC)で電源管理を行う場合、vMAを利用することになります。が、現行のPowerChute Network Shutdown EnterpriseはESXi 4.1に未対応の様子。vMA 4.1でESXi向けPCNSのinstall.shを実行してもOS=Linuxとなってしまいます(対応バージョンだとOS=vimaとなります)

ESXi 4.0 update1はPCNS2.2.4で対応しているようなので、vMAの4.0との組み合わせで電源管理を実現できるかテストしてみよう。

VMwareHAのIsolation Addressについて

VMwareHA構成で生じた障害について備忘録代わりにまとめておきます。

<環境>

・VI3 (3.5)

・ESXは2台

・VMFSはFC接続

・VMwareHA済み

先日、ESXホストの1台がHW障害で停止しました。その際、残されたESXに仮想マシンが引き継がれずに仮想マシンがパワーオフしたままとなってしまいました。

ログには、残されたESXが[isolated]されたことを示すエントリがありました。isolatedについて調査したところ、次のような状況であることが分かりました。

ESXホストの停止=ネットワーク応答の停止です。残されたESXは相手方の故障なのか、自分が故障したのかどうか、判定を行います。これは、あるアドレスに対してICMP Echoを投げて返事があるかどうか、という仕組みで判定します。

あるアドレス=isolation addressと呼ばれ、デフォルトではServiceConsoleのデフォルトゲートウェイがそのアドレスになります。今回はこのデフォルトゲートウェイが運用の中でPing応答を返さないよう設定変更されていたため、「isolation addressからの返事が無い=隔離モードに移行」となってしまったようです。

このゲートウェイアドレスは他社管理であったため、自社管理できるアドレスにisolation addressを変更する必要が産まれました。

変更は非常に簡単で、vSphere ClientでVMwareHAの構成画面で「詳細オプション」を開き、「das.isolationaddress1」を指定することで変更が可能です。

このdas.isolationaddress1は1~10まで指定することができ、複数指定した場合は全てに対して応答が無くなったとき、隔離モードに移行するようになります。

詳しくは、

http://www.atmarkit.co.jp/fserver/articles/vmwaredep/15/02.html

この記事に記載されています。

やっとVPN問題が解決した

FW切替後、VPNを再設定したところ、厄介な問題が発生していました。結果からみると、よくある話(MTUサイズの調整不足)だったのですが、途中で起こったことが珍しいことだったので、ブログに書いておこうと思います。

IPSecVPNを設定。双方のセグメントにあるホストへPingがきれいに通り、無事開通、と思ったのもつかの間。リモートサイトにある端末からローカル側のサーバにHTTPでアクセスできません。

私の作業用PCで確認したところ、サクサクに動いてます。が、お客様のPCではNGです。どうやっても繋がりません。Pingは通るのに。

作業用PCとIPアドレスを入れ替えてもNG。お客様のPCをリカバリにかけてみてもNG。

時間をおいて、会社から違うPCを持ち込んだところ、これまたサクサク動く。

完全に手詰まりです。

基本に立ち返ってWiresharkでパケットキャプチャしたところ、[TCP segment of a reassembled PDU]の嵐。

ここでようやくMTUサイズ問題だと気づきました。

ルータでMTUを大幅に下げたところ、あっさりと接続。めでたしめでたしです。

しかし、どうして作業用PCや社から持ち込んだPCではOKで、お客様のPCではNGだったのか。

どうやら、Path MTU Black Hole Detection機能が関係しているようです。

Configure TCPIP stack settings in Windows NT にある

To configure Path MTU Black Hole Detection:

[HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services Tcpip Parameters]
EnablePMTUBHDetect = 0 (Enabled = 1, Disabled = 0, Default = 0)
Note Windows 2003 SP2, Windows XP SP3 and Windows Vista enables black hole detection by default, and changes the PMTU to 536 bytes if retransmissions occurs (If the following retransmission also fails then the PMTU is returned to its original size). More Info MS KB Q925280
More Info MS KB Q136970
More Info MS KB Q159211
More Info MS KB Q314825

このあたりの記述にヒントが。NGだったお客様のPCはWindowsXPSP2、持ち込んだPCはVista、作業用PCは7でした。

どうやらOKだった端末はMTUサイズのエラーを検知して、自動的にMTUを縮めていたようです。

なまじ接続が出来るPCがあったもので、解決までかなり時間がかかってしまいましたが、理屈の通る現象で一安心です。

XenApp、ICAファイルから公開アプリケーションが起動しない(解決済み)

ICAファイルからの公開アプリケーションの起動に失敗する件。

http://support.citrix.com/article/CTX120926

これに合致していた。

このHotfix Rollup Packをインストールすると、ICAファイルのパラメータTcpBrowserAddressではなくHttpBrowserAddressが使用されるようになります。ただし、デリバリーサービスコンソールで作成されるICAファイルには、デフォルトでSSLEnable=ONが指定されます。このため、ICAファイルでサーバーポートとして80を指定すると、アプリケーションが起動に失敗します。この問題を避けるには、サーバーポートとして80を指定する場合はICAファイルをSSLEnable=OFFに変更してください。[#214876]

作成したICAファイルをNotepadで編集して、SSLEnable=OFFとしたところ無事起動した。

「TCP/IP+HTTPブラウスのチェックボタン」をオフにして作成した場合、TcpBrowserAddressだけしかエントリが無いので起動に失敗する。HttpBrowserAddressを追記してやれば起動に成功する。

つまり回避方法は2通り。

  1. 「TCP/IP+HTTPブラウスのチェックボタン」をオンにして作成した場合はSSLEnable=OFFにする。
  2. 「TCP/IP+HTTPブラウスのチェックボタン」をオフにして作成した場合はHttpBrowserAddressを追記する。

チェックボタンの有無はXenAppサーバの検出時、ICAクライアントからブロードキャストが送信されるかどうかの違い。オフにするとブロードキャストで検出を試みる。このためネットワークトラフィックが発生するので、基本的にはオンにしてICAファイルを作成する。詳細は以下。

http://support.citrix.com/article/CTX114457

FWの切替でハマる

NetScreenからCisco ASAに切替。MIPをStaticに、AccessRuleをACLに、とコンフィグリストを突き合わせて設定。

で、切り替え。通信出来ない…。

散々こねくり回したけど全くダメ。

で、PingをISPに投げてやると…。

通った。通らないサーバも同様にPingを投げると通っていく。

xlateやarpのエントリの加減なんだろうか…。

XenApp動いた…

テスト環境を作っていましたが、Web Interfaceのサイト作成にどうしても失敗してました。

XenAppサーバにインストールしていたんですが、別のサーバにインストールしてみるとアッサリ動いてしまいました。

XenAppのライセンスサーバにWeb Interfaceをインストールしてます。

XenAppサーバのインストールの時、IPSEC Serviceが無効になっているとインストール途中で失敗するという罠もあります。

私はIPSEC Serviceを無効にしがちなので、ハマりました。

VMware:ESX 3.5 –> VMware Server 2.0.2 –> ESX 3.5というV2V2V

仮想マシン上に業務システムを構築する案件。納入先が遠距離ということもあって、V2V2Vを駆使して環境を構築することになりました。

  1. ESX3.5が稼働している環境で仮想マシンを作成
  2. vCenter ConverterのBootCDで仮想マシンをブートさせ、VMware Server向けの.vmdkにコンバート
  3. 社内に持ち帰ってVMware Serverにインポートして色々設定
  4. 再びvCenter ConverterのBootCDでコンバート
  5. Converter Standaloneで、仮想マシンをESX3.5にインポート

ざっくりとした手順はこんな感じです。

vmfsデータストアから直接FTPやSCPでダウンロードする方法がありますが、ESXのバージョン違いなどでトラブルがありそうなので、Converterを利用することにしました。

コンバートしたvmdkはUSB-HDDで運びましたが、帯域さえあればネットワーク越しで運べるので、改めて仮想化のメリットを感じることが出来た仕事です。