Metaphorical Dream

<   2009年 10月 ( 29 )   > この月の画像一覧

vSpere ESX ちょっとまとめ

まだ、試してない機能

 1.Host Profile
 2.vCenter Server リンク モード
 3.vApp
 4.vSphere Host Update Utility
 5.vCenter Orchestrator
 6.VMware Data Recovery
 7.Enhanced VMotion Compatibility
 8.VMware vShield Zones

 1.
 ちょろっと見たんだけど、真面目にやろうとすると、膨大な項目があるのでパス
 イメージ的にはADのGPOに似てるかな。

 2.
 vCSを複数台並べて、、、ってところまでは、間に合ってまぁ~す。

 3.
 興味はあるけど、後回しかな。

 4.
 評価版=The Internetに接続しないのがオレのポリシーなので、まだ試していない。

 5.
 Orchestratorって、、、何かいいや(^^;
 オレから言わせれば、Conductorの方がいいんじゃね~の。
 っていうか、Sound Producerならぬ、Resource Producerか?(笑)

 6.
 興味はあるけど、後回しかな。
 
 7.
 XeonやOpteronなんかと下位CPUを組み合わせたりする場合に
 親和性を保ってくれる機能=今のオレには試せん。

 8.
 興味はあるけど、後回しかな。

「興味はある」って項目を追々やっていくことにしようかと思う。
けど、それほど近々ではないかな。

ちなみに今までやってみた箇所
 1.VMotion
 2.ssh接続:サポート対象外
 3.vCenterServer(クラスタ構成)
 4.vSwitch
 5.vNDS(vNetwork Distributed Switch)
 6.SerialConsole接続:断念
 7.FT
 8.HA:Bugにヒット?
 9.DRS
 10.DPM:断念
 11.StorageVMotion

[PR]
by mdesign21 | 2009-10-31 20:06 | IT系

ESX4.0 StorageVMotion その3

検証完了。

普通のVMotionと同じ。
やり方も普通のVMotionと同じ。

ただし、Dsikの読み書きをやるので、VMontionよりも時間が掛かる。
仮想マシンテンプレートのデプロイと同じくらいかな。

動作としては素直なんだけど、今のオレの構成では、
障害試験ライクなことができないので、とりあえず、
「できた!」ってことでOK。

[PR]
by mdesign21 | 2009-10-31 18:27 | IT系

ESX4.0 HA

切替わり時は問題なし。

切戻し時は問題あり。

ホスト1=192.168.11.72→障害時ゲストの退避先ホスト
ホスト2=192.168.11.81→障害発生ホスト
ゲスト=win2003-6→ホスト2で稼動

2:01:30
 shut(ホスト2が接続されているSwitchのポート)

2:02:30
 vCSにてホスト2障害検知

2:02:45
 ゲストPing復帰
 Ping復帰してもコンソールは効かない
 再起動が掛かってるハズ
 →しばらくした後コンソール復帰
 ホスト1にてゲストは正常稼動したことを確認

2:07:45
 no shut

2:08:00
 仮想マシンのメッセージ表示 ※1
 表示されたり消えたりを繰り返す
 Pingも落ちる
 両方のホストで仮想マシンをつかみ合っているような状態 ※2
 OKボタンをクリックしても状況変わらず

2:14:00
 復帰せずと判断

しばらくしてから、再度shutを実施。
5分以上経過してから、no shutを実施したところ、
無事ゲストが復帰したように見える。

がしかし、ゲストのコンソールが開かない。

再起動、シャットダウン、パワーオフ、リセットの
どれを実施しても以下のメッセージが表示。
「別のタスクが既に進行中です。」

5分経過については、可用性ガイドにあった、
 das.isolationShutdownTimeout
が、Default300secだったからなんだけど、
全然関係なかったっぽい。

試しに10分以上経過してから、
no shutってこともやってみたけど、事象変わらず。

こんなこと客先でやっちまったら、
 オレ「鯖が死んじゃいました」
 顧客「お前が死にてぇのか?」
っていう、やり取りが出来るに違いにない!

結局のところ、2台のホストを再起動することで、
ゲストのパワーオフができたw
→掴み合い状態が開放されたと想定

クラウド(仮想)化しても、これじゃあお粗末じゃないかな。

仮に復帰したからといってもさ、
 オレ「鯖が死なずに済んでよかったですね☆」
 顧客「確かに。でも、お前はもう死んでいる。」
ってな具合で、ケンシロウっぽく応対してくれるかもしれないw

※1の際の画面
もちろんOKを押してもダメ。
記載されているURLのkbを読む限り、ESX3.x系のこととして記載されている。
稀にしかないってなことを書いてあるけど、再現性100%なんだよねぇ(^^;
e0113173_1734547.jpg


※2の際の画面
win2003-6のサマリ画面なんだけど、「全般」項目内のホストのアドレス。
192.168.11.72で稼動していると表示されたり、
192.168.11.81で稼動していると表示されたり、
ってことを繰り返しているときの画面。

ホスト1上では正常稼動としているように見える
e0113173_1742726.jpg


ホスト2上では※1と同じメッセージが表示されてる
e0113173_1745394.jpg


んまぁ、とりあえず、VMのBug潰しをやっているわけじゃないので、
現時点では「危険」という評価として、次に行く。

[PR]
by mdesign21 | 2009-10-31 17:12 | IT系

ESX4.0 StorageVMotion その2

ESXやらvSphereの設定以前の話。

やっぱりオレはStorageに弱い。
なので、やっぱりオレはiSCSIを選んで(NFSではなく)正解だったと思う。

以下、マニュアルから抜粋。

<検出>
検出セッションは iSCSI プロトコルの一部で、
iSCSI ストレージ システムでアクセスできるターゲット セットを返します。
ESX/ESXi で利用できる 2 種類の検出方法は、動的検出と静的検出です。
動的検出ではアクセス可能なターゲットのリストを
iSCSI ストレージ システムから取得し、
静的検出ではターゲット名を使用して特定のターゲット 1 つのみにアクセスできます。

e0113173_22531453.jpg


 ・上記の絵に書かれている概念
 ・特定のターゲット 1 つのみにアクセス
ってことを根本的には理解できていなかった。

でなければ、下のブログに書いた
 「iSCSIターゲット2代目もとい2台目のシックプロビジョニング」
のようなアホなことはしなくても良かったのにぃ。

iSCSIターゲット2台目なんて騒いでたのが恥ずかしい。

ようするに、

(1)OKパターン
 アレイ*1
 ターゲット*1
 LUN*2

(2)アホパターン
 アレイ*2
 ターゲット*2
 LUN*2

「特定のターゲット1つのみ」という制限があるのに
アレイを2つ作ったもんだから、必然的にターゲットも2つとなってしまった、と。

なので、こんな風になってないとアホパターンになっちゃいます。

Target1の中にLUN1と2が構成されている感じ。=(1)

# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2009-10.jp.euphonium:LogVol02-03
System information:
Driver: iscsi
State: ready
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: deadbeaf1:0
SCSI SN: beaf10
Size: 0 MB
Online: Yes
Removable media: No
Backing store: No backing store
LUN: 1
Type: disk
SCSI ID: deadbeaf1:1
SCSI SN: beaf11
Size: 85891 MB
Online: Yes
Removable media: No
Backing store: /dev/VolGroup01/LogVol02
LUN: 2
Type: disk
SCSI ID: deadbeaf1:2
SCSI SN: beaf12
Size: 85891 MB
Online: Yes
Removable media: No
Backing store: /dev/VolGroup02/LogVol03
Account information:
ACL information:
ALL

もし仮にこんなことを現場でやらかしたら、、、って考えると恐ろしいです。

本番ステージの上を職場と考えてみる。。。
役者は本番ステージの上で練習しない。

さてと、これからStorageVMotion始めます。

遅ッ。

[PR]
by mdesign21 | 2009-10-29 23:06 | IT系

ESX4.0 StorageVMotion

StorageVMotionを実施するため、
只今、iSCSIターゲット2代目もとい2台目の
シックプロビジョニング中。

80GBにしてあるんだけど、結構時間掛かるのねん(^^;

マニュアルを読んでて登場した、
 ・シンプロビジョニング
 ・シックプロビジョニング
って言葉。

最初はピンと来なかったんだけど、
乱暴な言い方をすると、
 ・Allocate all disk space nowを未実施で仮想HDD追加=シンプロビジョニング
 ・Allocate all disk space nowを実施で仮想HDD追加=シックプロビジョニング
ってことで、概ね当たらずとも遠からずかな、と。

なので、時間が掛かるっぽい、と。

ペプシNEXでも飲むかぁ。。。

NEX飲むのはいいから、
 HAはどうなったんだ?
っていう突っ込みは勘弁してね。

必ずやるので。>HA

ちなみに、何でこんなにちょいちょいブログが更新できるか?っていうと、
 それはオレのやる気があるからなんだ。
っていうのは建前で、
実際のところ、 "待ち"が結構多かったりするんです。>これは本当の話

[PR]
by mdesign21 | 2009-10-29 19:41 | IT系

仮想化関連記事2つ

1つ目
[ITpro EXPO 2009]“仮想化脳”を鍛えよう---日本仮想化技術の宮原氏が強調
http://itpro.nikkeibp.co.jp/article/NEWS/20091028/339594/

最後のくだり、
 宮原氏は
  3台のPCさえあれば,フリーのソフトをインストールして
  仮想化技術のほとんどの機能を体感できる」と説明する。
  そして,自分で使ってみることが「“仮想化脳”を鍛えるうえで最も近道になる
 と強調した。
ってことは、まさにオレのことか?

んまぁ、それはいいとして(笑)

「仮想化脳を鍛える」っていうかさ、
 ・エンジニアとして、
 ・プロとして、
当たり前なプロセスだと思う。

トレンドをいち早くキャッチし、
 ・消化&吸収
 ・修得&会得
 ・実践&昇華
することで、
己の糧になるんじゃないかなと思う。

2つ目
[ITpro EXPO 2009]ガートナーが2010年のITリーダーの指針示す
http://itpro.nikkeibp.co.jp/article/NEWS/20091028/339527/

これも最後のくだり、
 山野井氏はクラウドについて,
  技術が成熟していないのに期待だけが先行する「バブル現象」が起こっていると指摘した。
  今はバブルがはじける直前の状況であり,この2~3年のうちにユーザーが幻滅を感じ、
  クラウド・ベンダーが淘汰される時期が来ると予想した。
  その一方,こうした現象はどの技術にも起こり得ることで,
  要素技術である仮想化の成熟にはあと3年はかかるが,
  その後に本当のクラウドが来る
 とした。
ってことは、クラウドバブルなのか?

んまぁ、そんなことはいいとして(笑)

オレの琴線にヒットしたフレーズを掻い摘むと、
 1.この2~3年のうちにユーザーが幻滅
 2.クラウド・ベンダーが淘汰
 3.こうした現象はどの技術にも起こり得ること
 4.仮想化の成熟にはあと3年はかかる
って当たりかな。

んでもって、オレの所感を書いちゃうと、
 1.オレも同感。実際に今作ってみて思う。

 2.オレの所属はどうかな?(笑)
  ただ、実際にやってみて思うことは、
   ・作る(構築する)のは易し
   ・運用する(継続して使う)のは難し
  だと思う。
  だってさ、
   ・1つ1つの操作にどれくらい時間が掛かるのか把握できない
   ・操作の順番を間違えただけで、ESX4は繋がらなくなる
  といった当たりの"感触※"については、
  実際にいじってみないとわからないから。
  ※
  "感触"って言葉が適切か?わからないけど、
  例えばね、
   ・○○のコマンドを打つと、プロンプトが返ってくるまでに若干のタイムラグがあるから、
    流し込む場合は、改行を一つ入れてから次のコマンドを流し込むようにしてね。
   ・WAN越しで××コマンドを打つと、画面上はグチャグチャになって表示されちゃうけど、
    ログ上では正常に表示されるから必ずログの方で確認してね。
  といった実際にやってみないとわからないノウハウ的なこと。
 
 3.確かに言えてる。
  だけど、"こうした現象"が起こり難く、且つ、末永く糧となる技術を
  修得&会得したいわけですよ、オレ的には。
  なので、消化&吸収のプロセスは大事かなと。
 
 4.あと3年。その頃には、エヘヘッ。
  オレの思い描くようになってればいいなぁ。
  けど、技術は7倍の速度で進歩していることを忘れちゃいかんよ。

[PR]
by mdesign21 | 2009-10-29 19:33 | IT系

ESX4.0 DPM その2

断念することにした。

 1.Enhanced AMD PowerNow!
 2.AMD PowerNow!

全くの別モノなのねん(涙)

 1.はOpteron系以上で対応
 2.はそれ以下のしょぼい系で対応

しかも、現行OpteronだとSocketFとなっていて形状が違う。
1世代前のAM2形状のOpteron(12xx系で12000円弱)もあるにはあるけど、
それで失敗したら、(涙)が止まらない、たぶん。

それにきっと失敗すると思う。
だって、
 CMOS:90nm SOI
なんだもん。

オレが使ってる9305eが65nmなことを考えると、
ありえないと思う。

なので、ここは潔く断念することにしたw

ただ、DPMを実施する前提として、スタンバイモードへの切替を実施するのだけれど、
そこで出てくるメッセージがDVFSとは関係無い気がしなくもない。

e0113173_025158.jpg


オレの使っているNIC*4個は、いずれもWake on LANには対応してて、
vCenterServer上において、Wake on LAN対応=Yesと表記されているんだけどねぇ。

ちなみに、クラスタの
 「コンプライアンス非準拠」
ってのに引っ掛かっていると思われる。
e0113173_0102436.jpg

また、
 「VMotionNICの速度が少なくても1000Mbpsではありません」
 「FTログ記録NICの速度が少なくても1000Mbpsではありません」
っていうのは、誤認識じゃないか?と思ってしまう。

Cat2950*1台構成から、Cat2950*1台、Cat3560*2台構成に変更し、
GigaNICの受け口を確保したんだけどねぇ。

やっぱ、Gigaスイッチじゃないとダメなのかねぇ。

「DPMはちょっぴり敷居が高かったぜ!」ってことで、許しておくんなさい。

n1kvに進みたい所もあるので、DRS&DPMはこの辺で一時終了。

あともう一歩のところで、辿り着けないのは、やっぱりちょっと悔しいなぁ。
CPUは致命的だから、しゃ~ないかぁ。。。

、、、あ!
でも、StorageVMotionなら出来そうな気がしてきたw

[PR]
by mdesign21 | 2009-10-29 00:10 | IT系

ESX4.0 DPM

DPMがうまくいかなかった理由が見えてきた。

ポイントは、
 1.1Gbps以上のリンクによる、VMKernelNICの接続
 2.DVFS(Dynamic Voltage and Frequency Scaling)
が必要っぽい。

っていうか、オレの構成で足りていなかった部分。

1.は、
 「はい、すいません。何とかして1Gbpsリンクを確保します。」
ってな感じ。

2.は、CPUにおける以下の機能が必要っぽい。
 ・Enhanced Intel SpeedStep
 ・Enhanced AMD PowerNow!

んでもって、BIOS上でEnableが必要っぽい。

なので、これから試してみる。

ちなみに、即行でAMDをサイトを確認したところ、
 ・日本語:AMD PowerNow!の表記無し
 ・英語:AMD PowerNow!の表記有り
なので、試すしかないな。と。

使用しているCPUは、Phenom X4 9350eなんだけど、
PhenomⅡ系なら間違いなく、AMD PowerNow!に対応しているっぽい(涙)

[PR]
by mdesign21 | 2009-10-28 22:14 | IT系

ESX4.0 DRS

やってみたw

負荷を掛けるホスト=srcESX
仮想OSを受け取るホスト=dstESX

絵を見ちゃった方が早いので、画面キャプをアップ。
HAやDRSの設定はDefault。

(1)負荷を掛ける前の状態
srcESX1
e0113173_23591694.jpg


dstESX1
e0113173_23595557.jpg


(2)負荷を掛ける過程 srcESXの状態遷移のみアップ
srcESX2
e0113173_01592.jpg

srcESX3
e0113173_015842.jpg

srcESX4
e0113173_021763.jpg

srcESX5 ←DRS発動!
e0113173_023496.jpg


(3)DRS中のsrc&dstESXの状態
srcESX6
e0113173_032122.jpg

dstESX6
e0113173_034993.jpg


※1 src&dstのCPU使用率遷移
srcESX_CPU
e0113173_05685.jpg

dstESX_CPU
e0113173_052054.jpg


※2 ExPingによる通信断(実行間隔=100ms,Timeout=100ms)
DRSにて自動VMotionしちゃった仮想OS=win2003-2=192.168.11.92
e0113173_064878.jpg


特筆すべきなのは、win2003-1をMcastストリーム配信サーバとして稼動させておいて、
Man in the Mirrorを聴いていたけど、Michaelの歌声は途絶えなかったことかな。
故に、DRS発動により自動VMotionする仮想OS以外の仮想OSには影響を与えないっぽいw

ステキだった!

ちなみに、HAやDRSの設定を積極的にすると、
 「おいおいおい! こっちに来るなよ!」
 「オレは片寄せが好きなんだよ!」
っていうことをシカトして自動VMotionを
ゴリゴリしてくれちゃいます(笑)

HAの検証もしてみたんだけど、それは後日。
所感として、
 ・障害時はOK
 ・復旧時は大丈夫かいな?
っていう事象を確認した。

[PR]
by mdesign21 | 2009-10-27 00:10 | IT系

仮想化の別な視点

1.VMware
2.KVM
3.Hyper-V
4.Xen

オレ的に残りそうな順番で列挙してみた。

1.は、一日の長があるのは確か。
でも、うかうかしてられないでしょ?と思う点はある。

2.は、他のキーワードよりかはメジャーではないかもしれない。
けど、LinuxKernelが無くならない限り、生き残れるハズだと思ってる。

いや、むしろオレの個人的見解を言わせてもらえれば、
VMの牙城を切り崩して欲しいと思ってしまうw

3と4はどっちもどっちかな。

3はそもそもKernelが違うので論外。
MSさんは自分の利を守ることに執着したため、
大きな時代の流れに取り残されたことを思い知るがいい。
と思ってしまったりする。

なぜなら、3.以外は全てLinuxKernelに関わるでしょ?
自社のWinKernelがどれほど凄いかは未公開としても、
数の暴力(っていう言葉は適切ではないと思うが)には敵わないんだよ、結局さ。

LinuxKernelをいじれるエンジニア > WindowsKernelをいじれるエンジニア

けど、WinKernelが無くならない限り、Hyper-Vも残るので、一応3.に入れておく。

4.=ごめん。でも、さよなら。
時代の流れをキャッチしてね。

IPXやNetWareような末路を辿ってしまう気がするのは、オレだけじゃないハズ!?

[PR]
by mdesign21 | 2009-10-26 03:18 | IT系