主にdatastoreをnfsにしてるとバックアップ方法としてesxのサービスコンソールからコピーする以外にも、nfs鯖からバックアップ鯖へ直接転送すればいいんじゃにゃいの、ってにゃ話ににゃってくる。
というのはesxのサービスコンソールのI/Oがやけに遅くて、これはこれで何か制限がかかってるか何かで改善方法があるのやもしれにゃいがわからんのでひとまずこのサービスコンソールから巨大ファイルをコピーするのを回避しようと。
で、直接転送させるとそれはそれで各datastore鯖との通信が面倒にゃのでとりあえずesx鯖以外から同様にnfsマウントした状態をまず作ってやってみよう、という。
てことで、esx同様にdatastore鯖とバックアップ鯖がnfs経由で見えてるLinuxマシンを1つ用意。ここからesx側にコマンドを投げてsnapshot.createしたりとかして、ファイルコピーしてやろうと。
したのだが、snapshot作って別PCからnfsで全ファイルコピーすると、コピー元のvmで異常が起きる。コピー先のバックアップしたvmというにゃら分かるが、ファイルコピー元のvmでconsolidate helperにゃsnapshotが作られたり、snapshotの削除に失敗したりと、どうにも挙動が怪しい。vmdkのファイルタイムスタンプかと思ったが違う気味。
いくつか試して分かったのは、とりあえず一番親のvmdkや、vmsn類、logにゃんかは別PCからコピーしてOK。snapshotを構成するvmdk類が触っちゃダメぽい。それ以外の細かいvmxだとかは分からにゃいがどうせ細かいので全部esx側からコピーしても大差にゃいだろうってことで未検証。
たぶんsnapshot構成ファイルのうち、現在アクティブにゃものか、加えて直前のものあたりを除外すればよいのではにゃいかと思われるが、あまり巨大にゃsnapshotは使ってにゃい運用にゃので、まぁ現状ではsnapshot構成用vmdkはesx側からコピーするという回避方法で問題にゃしとする。
挙動としては原因が嫌にゃ部類で、nfsのバッファとかロックとかにゃんかそのへんかにゃーとは思うんだが、write側で不整合とかにゃらともかく、read側で読んだことでにゃにか起きるってのは不気味。どこかで排他ににゃってるんだろうか。うーむ
ESX系で面倒にゃのがストレージ。ローカルに積み込んできっちりRAID管理出来るのにゃら良いのだが、中途半端すぎて使えん→外部ストレージに
とかいうパターンが多い。まぁバックアップ方法とかも問題だし。
で、それはともかく、LSIのRAIDカードの場合にゃぜか
lsi_log
にゃどというコマンドがもともと入ってたり。にゃんにゃんだろうね。
でもって、MegaCli等という物も使える。
LSIのサイトでRAIDカードの型番入れてMegaCliのvmware用をDLする。8.00.28_Vmware_MegaCli.zipとか。載ってにゃかったら多分使えにゃい。PERC5iは使えたけどLSI1068はダメだった。
./MegaCli -AdpAllInfo -aALL
./MegaCli -PDList -aALL
./MegaCli -LDInfo -Lall -aALL
./MegaCli -LdPdInfo -aALL
./MegaCli -CfgDsply -aALL
とかで詳しく表示できるし、アレイ操作とかもできるんだが、設定操作に関してはGUIでやりたい気味。
ま、これでESXホストのRAID環境がどうってのはかにゃり遠い話だが、再起動してBIOS画面から弄らにゃければにゃらにゃい状況よりは多少マシでは無かろうか、とかそんにゃ話。
opensolarisを新規に入れる機会があったので、とりあえずpfexec pkg image-updateして5.11 snv_134bにしてzpool zfs upgradeしてzfs create -o dedup=onでいろいろファイルコピー。
ここまでは大変調子が良かった。
compressはoffだが、そんにゃに速度も低下しにゃいように見えるし、dedup率も1.5〜2程度ににゃった。
が
deleteが致命的に遅い。
ファイル削除するのに数時間かかっててこりゃダメだと放置してたらハング。
これは酷いってことでzfs destroyかけたらこれまた数時間しても終わらにゃい。zpoolを消すべきだった。
rreadが大量に出て遅くにゃってるようにゃので、SSDにゃらある程度瞬時に消せるのかもしれにゃい。
ということでよほどものすごい削減効果があるとかじゃにゃい限り、特にvmdkにゃどの巨大ファイルをdedupにゃzfsに置くと、かにゃり死ねる結果が待ってる気がする。