チラシの裏に書くと捨ててしまうので

データベースの一括バックアップは、当然ですがサーバの負荷も高くなるため、サーバリソースに余裕がある(あるいはデータベースが十分小さい)場合でないと躊躇してしまいます。少なくとも本番環境などではあまり現実的ではない選択肢なので、普段はmysqldumpコマンドで該当テーブルのみピンポイントでバックアップして不慮の事態に備えるようにしています。

# mysqldump -u [username] -p [password] -t [database] [table] | gzip > [filename].gz

パイプ使ってgzipに渡してあげれば、圧縮する手間も省けて便利。
ただ圧縮にはそれなりにCPUの負荷がかかりますので、ディスク容量に余裕があるなら無圧縮でダンプを吐き出すのもあり。

# mysqldump -u [username] -p [password] -t [database] [table] > [filename]

まあVMware Server とか ESXiとか使ってるのであれば、VMのスナップショット取っちゃうのが一番簡単なんですけどね。スナップショットのリストアが高負荷なのでアレですが、それに勝るお手軽さが魅力です。

ESXi 3.x以前はRPMパッケージで提供されいていたVMware Toolsですが、vSphere 4からはソース(tar.gz)しか提供されなくなったみたいです。俺が見つけられないだけという可能性はさておき、毎回tarで解凍するときのオプションなんだっけと検索するのも面倒なのでメモっておきます。

(1) vSphere Client上で対象VMを右クリック->「ゲスト」->「VMware Tools のインストール／アップグレード」を選択。ごちゃごちゃメッセージが表示されますがとりあず「OK」を押す

(2) イメージをマウント＆コピーする
# mount /mnt/cdrom /mnt
# cp /mnt/cdrom/VMwareTools-4.0.0-171294.tar.gz /root
# umount /mnt

(3) tarボールを展開してインストールプログラムを実行する
# cd /root
# tar zxf VMwareTools-4.0.0-171294.tar.gz
# cd ./vmware-tools-distrib/
# perl vmware-install.pl

(4) 全ての質問に何も考えずエンターを押し続ける

(5) おしまい

念のためvSphere Client上で対象VMの「サマリ」のタブをクリックしてVMware Toolsの項目が「OK」になっていることを確認すればなおよろし。

今気づいたですけどvSphere 4からCentOS 3.x系が「Red Hat Linux Enterprise 5」ではなく「その他の2.6x Linux」として認識されるようになってる。ソースしか提供されないのってひょっとしてこのせいアルか？

PFエラーなのでメモリ関係のトラブルだとは思うのですが、原因はまだ分かってません。

症状としては不定期に突然ホストが赤紫色？の画面を表示して落ちてしまいます。エラーメッセージはすべてPFエラーなのですが、それに続くエラーコードは毎回異なるという状態です。

最初はESXi 4.0固有の問題かと思って色々調査していたのですが、実はESXi 3.5 から ESXi 4.0 へのアップグレードと同時にメモリも増設しており、とりあえずそっちの原因を疑っている状況です。

というのも、ESXi 4.0アップグレード当時のメモリ構成が

Slot1: CFD 2GB (A)
Slot2: CFD 2GB (B)
Slot3: UMAX 1GB (C)
Slot4: UMAX 1GB (D)

で、運用途中に突然死。
メモリ不足なのかなーと新たにメモリを追加して

Slot1: CFD 2GB (A)
Slot2: CFD 2GB (B)
Slot3: CFD 2GB (E)
Slot4: CFD 2GB (F)

という構成で運用していたのですが、これでもタメ。
ならば(A)(B)メモリが原因かと思い、この２本を外して

Slot1: (空)
Slot2: (空)
Slot3: CFD 2GB (E)
Slot4: CFD 2GB (F)

これだとOK。ただしこれだとメモリが足りなくて運用上支障が出るので、最初に外したUMAXの(C)(D)メモリを追加して

Slot1: UMAX 1GB (C)
Slot2: UMAX 1GB (D)
Slot3: CFD 2GB (E)
Slot4: CFD 2GB (F)

としたら数時間でアウト。(涙)
とりあえず現在は

Slot1: CFD 2GB (E)
Slot2: CFD 2GB (F)
Slot3: CFD 2GB (A)
Slot4: CFD 2GB (B)

という構成で様子を見てます。
以前試した(A)(B)(E)(F)状態と似たようなものですが、メモリセットの位置をずらしてます。これで何も起きなければ幸せになれるんですが、私の経験上そんなハッピーエンドが待っている確率は非常に低い事も理解しております。

ちなみに被疑者である(A)(B)(C)(D)メモリは、全てMemtest86+を数回走らせてチェックしてみたのですがエラーは発生しません。なんなんだ、、、

現時点で考えられる原因は、
(1) ML115本体のメモリスロット(Slot1 or Slot2)がイカれた
(2) ML115のバグ (BIOSは一応最新)
(3) ESXi 4.0のバグ

ぐらいでしょうか。とりあえず次回同様の症状がみられたら、一度ESXi 3.5に戻して様子を見たいと思います。

調べれば調べるほど奥が深いESXi上の仮想マシン(VM)の時刻同期。
どうやら現状ではNTPを使うのが最善策のようです。

まずお手軽な解決策として考えられるのは、
(1) VMware Toolsの時刻同期設定オプションを設定する
(2) NTPを利用する

のどちらか。

さらに「時刻がずれる」という現象そのものにも2パターンあって、
(A) 時刻が進んでしまう
(B) 時刻が遅れてしまう

という、それぞれのケースについて考えなければなりません。
以前は(1)が鉄板だと思われていた(というか俺が思っていた)のですが、この方法は(B)のケースでしか有効でない事が判明しました。

なぜなら(A)の時刻が進んでしまうのはLinux2.6系で設定されている毎秒1000回(わお)というタイマー割り込みをVM上ではエミュレートできないためで、エミュレートしきれない→タイマー取りこぼし発生→遅延が発生したと思い込んだカーネルが補正しようと時刻を進めてしまう、という堂々巡りの果てに引き起こされる問題であり、VMWare Toolsの設定で何とかなる範疇を超えてしまっているからです。

Time in a Linux 2.6 guest operating system runs faster than real time due to lost tick overcompensation

Time in virtual machine drifts due to hardware timer drift

この(A)の問題については、カーネルパラメータを変更する事でタイマー割り込み頻度をVM上での適正な値に抑えることができます。必要なパラメータについては、VMWare社がKBとして公式に発表しているので、こちらをご参照下さい。

Timekeeping best practices for Linux

ちなみにこのKBによれば、「全ての場合においてVMware Toolsの時刻同期設定(Periodic Time Synchronization)よりも、NTPを(優先して)使え」と明言します。生み親にまで否定されてしまった時刻同期設定オプションの立場ったら。

上記パラメータを設定をすることで時刻のずれをかなり小さくする事ができますが、カーネルパラメーターをいじるのが不安だとか、完璧な時刻同期が必要なんだ！という方はやはりNTPを使うのが良いでしょう。ただしNTPを利用する場合は別途UDP123番のポートを開く必要があるので、ネットワーク運用規定上NGな場合などは別途ネットワーク上にNTPサーバを立てて下さい。最近のルーターはNTPサーバ機能がついているものも多いので、外向きルータ(デフォルトゲートウェイとか)への追加設定とVMマシンへのNTPインストール＆設定だけで済むんじゃないでしょうか。

ちなみにNTPを利用する場合はVMware Toolsの時刻同期設定(Periodic Time Synchronization)を無効にする必要があります。つまり(1)と(2)の組み合わせは不可ということですね。完全に居場所を失ってますね時刻同期設定オプション。
よくわかんないけどがんばってください。

通常コマンドライン(CLI)上から実行するSVMotionを、VMWare Infrastructure Client上から実行できるプラグインを作ったえらい人がいます。

VIP – VMware Infrastructure 3 Plug-in

MSI形式のインストーラーをダウンロードして、何も考えずインストールするだけでOKです。

使い方は、

1. VMware Infrastructure Clientを起動する
2. SVMotionを実行したいVM上で右クリックし、表示されたメニューの最下部にある「Migrate Strage」を選択する
3. 現在認識されているストレージ一覧と、対象VMが格納されているストレージが表示される
4. ぐりぐりっと対象VMを希望するストレージに移動させる
5. 「Apply」を押す

これだけです。簡単です。

環境にもよりますが、５GB程度のイメージの移動は10分くらいで完了しました。
世の中便利になったものです。

ちゃんと調べようとすると情報が少ないVMWare ESXi。
結局VMware ESXi 4でどんな機能が追加されたのかちゃんと調べたかったので、とりあえずVMWareのESXi公式サイトに掲載されている新機能(「NEW!」マークがついてるやつ)を書き出してみました。

原文が読みたい方はこちらをどうぞ(英文)：
VMware ESXi Features

主な特徴

• 8900トランザクション／秒
• 200,000 I/O／秒のオペレーション
• 1物理ホスト上に最大16,000のExchange Mailboxをサポート
• 1物理ホストあたり64論理コア、256の仮想CPU、1TBのメモリをサポート

アーキテクチャ

• 64-bit ハイパーバイザー・アーキテクチャ：実績のあるハイパーバイザー・テクノロジーによる、ネイティブに近いバーチャルマシンの性能を実現

新進のリソース・マネジメント

• 向上した電源管理：Intel SpeedStepおよびAMD PowerNow!のサポートによるエネルギー効率の向上

パフォーマンス及び拡張性

• 仮想負荷(virtulized workload)に対するパフォーマンス向上
• iSCSIストレージに対するパフォーマンス向上
• より強力なサーバ向けハードウェアのサポート：64物理CPU、256仮想CPU、1TBメモリ、及び数百台の仮想マシンを1物理ホストをサポート
• より大きな仮想マシンのサポート：仮想マシンへ255GBまでメモリ割当てが可能
• 8-way仮想SMPのサポート：1仮想マシンに最大8物理CPUを割り当てることが可能
• ハードウェアの仮想化をサポート：AMDのRapid Virtualization Indexingや、IntelのExtended Page Tablesといった次世代のハードウェア仮想化技術をサポート
• ネットワークパフォーマンスの向上：TCP Segmentation Offloading (TSO)、VLAN and checksum offloading、およびジャンボフレームといった機能をサポート。さらにI/O性能を向上させるNetQueueもサポート
• 新たなハイパフォーマンスデバイス及びプロトコルのサポート：10Gbイーサーネットカード及びストレージ・アレイをサポート
• VMDirectPath I/O：頻繁なI/Oアクセスを必要とするアプリケーションのCPU利用効率を強化。ただしこの機能を利用した場合、VMware VMotionといった他の仮想化技術やハードウェアに特化したI/Oデバイスは利用不可

相互運用性

• OSのサポート：VMware ESXiはWindows,Linux,Solaris,Novel Netwareといった広範囲のOSをサポートしているが、今回新たに20のOSをサポートした

セキュリティ

• VMware VMsafe：サードパーティー製のアンチウイルスソフトが仮想ホストを管理可能にするAPIを提供

管理ツール

• VMware vSphere Command-Line Interface 4.0 (vCLI)：リモート環境からVMware ESXiを管理できる。ESXi 4.0では新たなコマンドがいくつか追加された
• VMware vSphere Power Command-Line Interface 4.0 (PowerCLI)：VMware vSphere Clientで利用できる管理機能を、コマンドライン上からも利用可能にする。Microsoft PowerShell技術がベースになっている
• VMware vSphere Management Assistant：開発者及び管理者がESXiホストを管理可能にする仮想マシン。vCLIとその他のパーケージ化されたソフトウェアで構成されている

—

オレオレ意訳なので間違ってたらごめん。っていうか教えて。

個人的にいいなあと思うのは仮想マシンへ割り当て可能なリソースの上限が上がったのと、iSCSIのパフォーマンス向上でしょうか。実際どれだけ向上したのかは未検証してないので何とも言えないのですが。

ただ、iSCSI上に作成できるストレージのサイズは相変わらず最大2TBという制限がかかっているみたいです。新ストレージの導入を担当していた同僚が悲しそうに教えてくれました。

ちょっと前の話題になりますが、3.5 Update 4がリリースされて間もないうちに、4がリリースされましたね。

VMware ESXi 4

4は64bitハードウェア正式対応が一番のウリのようです、というか32bitハードウェア使いたきゃ3.5使えというニュアンスなので、100％ピュア64bitハードウェア環境(ヘンな文章)の方だけ使ってね、という感じみたい。

今どきのサーバ環境なら32bitハードウェアという制限に引っかかることはまずないと思います。ただ周囲のエロい人たちから「VMwareの初モノは笑えないバグがある」と常々すり込まれているので、会社でも個人的にもとりあえず静観なのかなあと。

Update 3を導入したESXiマシンで、高負荷をかけ続けると数ヶ月でサービスコンソールが真っ白け、という現象に何度か遭遇しています。それが治るのなら4も前向きに検討すると思うのですが、、、もう少し情報を集めてみます。

ntpd入れろよとか言われそうですが、ESXi上で動いてるゲストＯＳだとそうもいかないので。

VMWare Clients達の見事なまでの時刻の狂いっぷりにつきましては、通常VMWare Tools入れると解消されると思われがちなのですが実はソースに手を入れないと完全に時刻同期してくれみたい。めんどくせぇ。

話はそれましたが答えはこう↓

date -s “06/04/2009 17:09:00″

月/日/年 時:分:秒 という書式なんですよねー。なんだかなー。

ちなみに変更後の時刻(システムクロック)にハードウェアクロックを同期させたいときは

hwclock -w

であります。

追記：(2009/11/10)
ESXi上でも時刻同期はNTP、という公式見解がWMware社から出されています。
具体的な内容及び設定方法をまとめてみましたので、興味のある方はこちらもどうぞ。
VMWare ESXi上 のVMで完全な時刻同期を目指す(Centos5)