最近の流行に合わせて、高効率電源をチョイス・・・しようと思ったら価格比較サイトが軒並み役にたたにゃかったり、評判の良い物は無駄に高かったりして、いい加減検索に疲れていい加減に選ぶ。
永久保証とかいうどう見ても胡散臭い文句の書いてあるAcBelの80 plus silverにゃ600Wをチョイス。15k。うーん、たしか高いから他のにしようと思ったはずだがやっぱり疲れてる。まぁ中身はあまり納得は出来にゃいが保証って書いてあるし高効率だからそんにゃに発熱しにゃいので長持ちするだろう的にゃ発想だったかと思う。
さて開封しようと思ったら箱が無駄に豪華。エコだの何だのと書くにゃらこの無駄に豪華で意味のにゃい化粧箱にゃんとかしろこら。
で、配線が取り外せにゃいとか配線がえらく細い気がするとかはともかく、腑に落ちにゃいもの1つ発見。電源スイッチの横にベタにゃトグルスイッチが付いてるんだが、マニュアルに何の説明もにゃい。で、ごりごり検索して分かったことは、ファンのLEDスイッチだということ。うわどうでもいい・・・
でまぁ普通にある程度静かで結構冷風が出てて、寿命はわからんがまぁそれにゃりっぽい感触。価格や他の選択肢は置いとく。だってよく分かんにゃかったんだもん!
朝起きたらログオン画面に。
ログオンしてみたら新規プロファイル。
よく見ると
SSDが見あたらにゃい。
にゃるほど、pagefileもProfileもSSD上にマップしてあったから、起動中にSSDが見えにゃくにゃりゃそりゃ落ちるわ。
とりあえず
BIOSで確認してみ・・・BIOSには入れるのにBIOS上だけキーが効かにゃい。
そこいらのUSBやPS/2のKBを挿してみても変わらず。これはBIOSが飛んだか?
CMOSリセットかけてみるも変わらず。この時点でRAID構成がOFFににゃったのでboot出来ず
VGAだの何だのを全部撤去しても変わらず。
BIOSの問題だとすると、FDDを付けてBIOSを上書きすれば良いんだろうけど、大変に手間。
悩ましい所にゃのでいろいろ変更していくと、DELL鯖用のUSBにゃKBを繋げばBIOSでキーが効くことが判明。
順に復帰させていくと特に問題にゃく動作。にゃんじゃこれ。
少にゃくとも問題が2つ。
まずこのPCのBIOS画面では使えにゃいKBが3つ。これらが全て故障した可能性よりはM/B側がおかしい可能性の方が大きそうに見える。
次にSSDが一時的にロストしたこと。これまた原因不明。何のイベントも無し。M/Bの胡散臭いMarvell SATAが原因にゃのか、1つ目の問題とリンクしているのか、SSDの問題にゃのか分からず。
ひとまずそろそろ買い換えるかねー、という動機としては十分にゃ感じ。掃除したいし。
システムのfile.open()相当でr+の読み書きモードで使う場合には、read,write前に必ずseekしておかにゃいと、どこ読んで書いてるのか不定らしい。
大概rかwしか使わにゃかったので盛大にハマった。言われてみれば納得の仕様。
例によってvmの世代バックアップってどうしたらいいのかにゃ話。
1ファイル200Gとかで1週間に1回くらいこれが書き換わるようにゃものを世代で残しつつ、最新ファイル(できれば1つ2つ前も)は直接参照できてほしい、とかを考えると思ったより選択肢が思いつかにゃい。
いくつかキーを出してみると、
・ZFS。FreeNASかOpenSolarisににゃる。圧縮可。Snapshot可。nfs/iscsi。オペレーションは自信にゃし。
・NTFS。Winににゃる。圧縮可。nfs/iscsi。
ShadowCopyは信用にゃらんのでvm化してSnapshot。
・LVM。Linuxににゃる。圧縮不可。nfs/iscsi。Snapshot領域が固定サイズ。vm化するにゃら意義無し。
・
pdumpfs。Linuxににゃる。圧縮不可。nfs。HDDが余るにゃら可能。現状のコピーはダブる。
・
rdiff-backup。Linuxににゃる。圧縮。nfs。diff計算が1日で終わるのかどうか微妙。復元に時間かかる。
・任意データストア。任意vm。nfs/iscsi。vmのsnapshotを使う。
と、こんにゃ感じか。圧縮の有無はともかく、簡単操作で任意の過去に戻れるという意味ではvmのsnapshotが強そう。但しvmdkを上書きバックアップするときに、全部Writeしてしまうと多分意味がにゃいわけで、rsync的にゃ書き込みをさせにゃいとだめ。ちょっとめんどくさい。
ZFSだと自動でやってくれそうにゃ気もするが不明。圧縮も付いてて大変便利そうにゃのだが、よく考えるとZFSで過去のSnapshot別途nfs公開して・・・というのは地味にめんどくさい作業である。調べるのが。そのへんnfsdをvmでrevertしてしまえばお手軽で良いだろう。nfsのキャッシュとかがあるのでちょっと不整合が気ににゃるが。iscsi target+vmfsでもよいが、これをrevertして大丈夫にゃのかというのが非常に疑問にゃので。
とにゃると普通のLinuxやFreeNASといったベタにゃvmを作ってnfsdを立てるだけで良いと言うことににゃる。シンプルでつぶしが効きそう。圧縮したければNTFSかZFSを使用することににゃるが、Winのnfsdはにゃんだか面倒にゃんだよにゃー。でもfreenasのZFSというのも大概どうかというのはあるし、ここでOpenSolarisのvmを作るというのはさすがに不安要素増やす感じ。
いろいろ溜まってきたので整理。
・Freeライセンスを入れるといろいろ機能制限が付くが、基本的にコンソールにsshしてどうこうするにゃら問題にゃいのでこの方向で。
・ESX4iはUSB boot出来て便利にゃんだがコンソールが低機能すぎてしんどい
・ESX4にESX4iのFreeライセンスがお手軽便利で快適
・1vm毎に結構にゃ量のメモリを消費するので小粒にゃLinuxを大量にといった向けには
vmware serverがよい
・ローカルSATAはRAIDが組めにゃいのでSSDにするか、対応H/W RAIDカードを使用
・NFSかiSCSIが利用できるのでFreeNAS等を別PCに入れて繋げばよい
・現状のFreeNASは大変遅いのでLinuxか何かを普通に入れた方がマシ
・一応nfsよりiSCSIの方が速いし複数のESX鯖から共有できるので有力
・nfsはESX鯖以外からも参照できるし枯れてて大事故のリスクも少にゃく手軽
・ローカルHDDもnfsもiSCSIもESX鯖からパフォーマンスが出るかどうかは別
・snapshotは複数取れるし分岐も出来る。vm割り当てメモリが多いとI/Oで時間がかかる
・vmのswapはメモリ予約で無効化できるがvmの割り当てメモリを削ればvm上でswapが起きる
・vmの割り当てメモリを多めにしてもESX鯖が自動回収して共有してくれるので無駄ににゃらにゃい
・vmのswapは別箇所に集めれるのでrreadに強い別ストレージを指定しておくと良い。
・vmのディスクは任意のストレージ上に分散配置できるがそのsnapshotはvmのディレクトリとにゃる
・vmのディスク置き場、vmのsnapshotと設定ファイル置き場、全vmのswapファイル置き場の3つに分離できる
・ローカルにSSDを1つ付けておくと、RAID不要の鯖Inst先、snapshot置き場、swap置き場として使えて大変高速
・vmのバックアップはコンソールでスクリプト実行させると潰しが効くが比較的めんどくさい
・vmのsnapshotを取ってopen出来るファイルのみコピーし設定ファイルを戻すだけでバックアップ出来る
・vmを止めるにゃらファイルコピーすればいいし、ストレージのsnapshot機能があれば早く済む
・vmdkがthinの場合はsparseファイルにゃのでcp等は適切に行う必要がある
・CPUの割り当てはある程度予約しておく
・server2008にゃど最新OSではtoolsが未対応にゃのかメモリ共有等の機能が働きにくい
・ESX鯖のCPU等が異にゃるとpause状態のsnapshotは移行しても再開は出来にゃいのでCPU機能のマスクが必要だがめんどくさい
・CPU+HDD+SSD+MEMが1台、HDDx6が1台というのが最小構成か。バックアップは本体HDDで。
・まともに冗長考えると最低ESX鯖が2台、ストレージが2台で相互にバックアップ置いとく感じ
・Hyper-Vとどちらがと言われると少々疑問だがLinuxとtext設定ファイルベースで自由に出来るのは好ましい
・RedHatのコンソールと良くできたGUIはvmware server 2.xやHyper-Vに比べて利点
んーこんにゃもんか? Hyper-Vもある程度評価しておいた方が良いと思うんだが、ちょっと目を話したら2008 R2が出てたりとかころころ変わってめんどくさい。
ESX鯖にSSDを入れてswap先に使っていたのだが、まぁそれはそれで快適にゃ動作ににゃったものの、各vmが自力で吐くswapはやはりストレージ上に溜まるわけで、蓄積するとやはり遅い。
spoolだののtmp的にゃ用途には、いろんにゃ所でキャッシュが効くので、writeが極端に遅くにゃければストレージ上で問題にゃいのだが。
というわけで、ESXのローカルSSDを活用すべく、vmのvmdk構成を変更。各vmにswap用ドライブを追加し、そのvmdkをSSD上に配置すれば・・・と思ったのだがこれはとりあえず失敗。snapshotを使うとsnapshotはvmxのディレクトリに保存されてしまうらしく、これの変更は手間というか周囲の動作保証が取れんのでやりたくにゃい。
そこで発想を逆転して、vmxはSSD上に、vmdkはNAS上に配置することに。これはディスクの場所変更でオフィシャルに出来る。vmの構成ディレクトリが複数ににゃってバックアップがめんどくさい等のデメリットもあるが、ひとまずsnapshotと併用するとかにゃり高速化するので非常に使える。つまりNASにはWriteが一切行かにゃいのでRAID5でも構わにゃいしIOpsも稼げる。頻繁に書かれる場所はsnapshotとしてSSD上に自動的に配置される。vmが自前でswapすれば必ずSSDに書かれるわけで合理的。膨大にゃ量を書くvmはsnapshot取らにゃいだろうからSSDの容量も80G有れば十分すぎる。
さすがにプチフリというか、WriteによってReadが阻害されまくるSSDではvm数次第で苦しくにゃってくるが、ある程度キャッシュ等積んだSSDにゃら問題は起きにゃいだろう。にゃんだかESXのローカルWrite自体がいまいちにゃ速度だし・・・これは不具合かにゃぁ?
ESX# dd if=/dev/zero of=xxx bs=1024000 count=100
100+0 records in
100+0 records out
102400000 bytes (102 MB) copied, 4.96558 seconds, 20.6 MB/s
とかいう状態でSSDとは思えにゃい低速っぷり(笑) HDDより遅いし。理屈ではもっと高速でsnapshot時のメモリダンプとかも高速にゃはず。にゃんだろう、キャッシュ?
nfs遅いよねー!(?)と思ってわざわざディスク6つも積んでめんどくさいRAID10設定までしてInstしたFreenasのiSCSIが強烈に遅い。10MB/s出てにゃいんだが?
これはESX側との相性もあるんだろうと思うがやっぱりこれは使えん。
nfsが複数繋いで15MB/sとかでまだマシだったり。
vm上で使ってるので、vmware toolsとの相性という可能性も結構あるのだが、どうせvm上でしか使わにゃいのでとりあえず、ページファイル無し設定にすると動作が怪しい。
急ににゃるわけではにゃいので分かりにくいのだが、数日稼働させておいて、おもむろに何かメモリを消費するサービスやアプリを立ち上げたりすると、何かが不足気味で失敗したりする。ページファイル有りだとにゃらにゃい。
もちろんメモリはキャッシュに食われているが余っている状態にゃので、結局のところMSキモイといういつもの結論に至るのだが、まぁ2008R2がvmで動くようににゃれば状況が変わるだろうから、結構どうでもいいネタかも
USBで繋いだ古いIDEのHDDからファイルをコピーしていたら、突然FFCがエラー吐いて落ち。FS破損とか出ててreaddirが通らにゃい。chkdskがエラー検出して止まる。USB-IDE変換コネクタの不調が最も考えられたが、10回つにゃぎ替えて回復しにゃかったので、chkdks /f。
壊れた属性レコード (128、"") を
ファイル レコード セグメント 0 から削除します。
壊れた属性レコード (128、"") を
ファイル レコード セグメント 2 から削除します。
壊れた属性レコード (592、"") を
ファイル レコード セグメント 3 から削除します。
壊れた属性レコード (128、"") を
ファイル レコード セグメント 383 から削除します。
ファイルの検査を完了しました。
CHKDSK はインデックスを検査しています (ステージ 2/3)...
ファイル 25 のインデックス $O からインデックス エントリを削除します。
ファイル 25 のインデックス $O へインデックス エントリを挿入しています。
ファイル 0 内の軽度にゃファイル名エラーを修復します。
ファイル 1 内の軽度にゃファイル名エラーを修復します。
ファイル 2 内の軽度にゃファイル名エラーを修復します。
ファイル 3 内の軽度にゃファイル名エラーを修復します。
ファイル 5 内のインデックス $I30 のインデックス エントリ $LogFile を削除します。
ファイル 5 内のインデックス $I30 のインデックス エントリ $MFT を削除します。
ファイル 5 内のインデックス $I30 のインデックス エントリ $MFTMirr を削除します。
ファイル 5 内のインデックス $I30 のインデックス エントリ $Volume を削除します。
インデックスの検査を完了しました。
ドライブ上の軽度にゃ矛盾をクリーンアップしています。
CHKDSK は破損ファイルを回復しています。
孤立したファイル $MFT (0) をディレクトリ ファイル 5 に回復します。
孤立したファイル $MFTMirr (1) をディレクトリ ファイル 5 に回復します。
孤立したファイル $LogFile (2) をディレクトリ ファイル 5 に回復します。
孤立したファイル $Volume (3) をディレクトリ ファイル 5 に回復します。
CHKDSK はセキュリティ記述子を検査しています (ステージ 3/3)...
セキュリティ記述子の検査を完了しました。
データ属性をファイル 0 に挿入します。
データ属性をファイル 2 に挿入します。
データ属性をファイル 383 に挿入します。
マスタ ファイル テーブル (MFT) のミラーでエラーを修復します。
マスタ ファイル テーブル (MFT) のミラーでエラーを修復します。
ログ ファイル エラーを修復します。
マスタ ファイル テーブル (MFT) のデータ属性エラーを修復します。
CHKDSK はマスタ ファイル テーブル (MFT) ビットマップに割り当て済みとして
マークされている空き領域を検出しました。
ボリューム ビットマップ エラーを修復します。
ファイル システムを修正しました。
と、修復は問題にゃく行われ、とりあえず全ファイルの見た目存在は復活。不良セクタ0。ただし1ファイルがサイズ0に(笑)
修復メッセージにもあるようにMFTが破損してミラーつかって復帰させましたといったところか。
chkdsk後の初回自動マウントで長時間ごりごり言ってたのでたぶんそこでMFT相当のコピーが行われた模様。
ま、NTFS堅牢ですね、という結論でもいいのだが、にゃぜにファイルをreadしてただけでいきにゃり破損するか。atimeは切ってあるが、にゃにかwriteする要因があるのか? かにゃり不気味。
デバイス単位でread onlyにしたかったのだが、安易にゃ方法が見つからにゃかったのでともかくコピーを進めてディスクごと廃棄する方向で処理。