kourin.org管理人ブログ

録画PCのリプレイスでESXをインストールした所までを前回記事にしましたが、いよいよ録画PC環境をリプレイスするために、そもそもESXでちゃんと構成できるのか、思うように動かせるのか… を確認してみました。
（画像はクリックで拡大します）

インストールしたESXにIPを設定してやり、ブラウザでアクセスするとVMWare vSphere Client がインストールできます。サクっとインストールしてアクセスしてみると… こんな感じでインストールできました。 🙂

プロセッサのステータスはこの通り、ちゃんとCore i7-2600 が認識されています。
ハイパースレッディングが有効なので、論理8CPUになっています。
（…が、どうもESXのリソースとしては4CPU計算らしく設定にズレが出る模様 🙄 ）

メモリもちゃんと8GB認識しています。
ただ、管理人がやろうとしている構成を取る場合、このままだとLinux用のメモリが不足する事が判明… まぁ、空きのメモリスロットもあるし、いざとなったら増設すれば良いかな… 😕

ストレージは適当に転がっていたHDDを繋いでみました。まぁテストですしいいでしょう…？
システムディスク兼データストアとなるHDDはRAIDにしたい所なんですが、用意したマザーボードだとオンボードでのRAID機能は無いので、ちょっと別の方法で実現できないか検討中です… 😐

ネットワークはこんな感じです。オンボードのNICが利用出来ないのでLinuxのゲストOSに直接 DirectPath I/O でアサインする事も考えたのですが、これをやるとスナップショットが使えないんですね… 録画PCは止むを得ないとしてもLinux側は避けたいところ。
うーん、ホスト側で何とかできないものかなぁ… 🙁

詳細設定では、DirectPath I/O でのパススルーデバイスを設定してみました。
とりあえず、オンボードデバイスとHighPoint RocketRAID2300を設定しています。
実際に稼働する際には、これにアースソフト PT2 も追加で指定するイメージでいます。
ちなみに… ESX 6.0 では、パススルーデバイスは8個までだそう。。。

オンボードデバイスはこのままだと何だか分からないのでメモっときます。
Intel Corporation P8H77-I Motherboard (1E2D) – USB
Intel Corporation P8H77-I Motherboard (1E20) – Sound
Intel Corporation P8H77-I Motherboard (1E26) – USB
こんな感じでした。（上から順に）

ちゃんと動くかテストするために、Windows10 Technical Preview を前にダウンロードしておいたので突っ込んでみました。
録画PCのOSは、Windows10 32bit版にするつもりです。と言うのも、32bitでしか動かないドライバとか色々制限がある為、仕方なく… 😥

Windows10TPをインストールしたゲストOSに、最新のRocektRAIDのドライバと管理ソフトを入れたところ、ちゃんと認識してくれました！
HDDを何も接続していないので稼働は未確認ですが… まぁ、多分大丈夫じゃないかなぁ… 🙂

最後に、今の録画PC（AMD Phenom9600 4コア）と、ESX（Intel Core i7-2600 4コア/8スレッド）上の仮想Windows10ゲストOS（3コア/6スレッド 相当）で、同じTSファイルを同一オプションにてffmpegでエンコードしてみたところ…

Phenom9600 ffmpeg 3スレッド処理 => 66分（約1時間）
Core i7-2600 ffmpeg 4スレッド処理 => 35分（約30分）
（エンコード中の他の処理が遅延しない様に全スレッド使用しない値で実施）

と言う事で、約半分の時間でエンコード出来ることがわかりました！
8スレッド処理にしたら… 15分でできるのか。。。胸熱だね！！ 😛

管理人は結構メールを溜めちゃう方なんですが… 思い出したようにメールを受信したら、8月1日に光輪サーバーのRAIDが外れたエラーメッセージが届いてました…  😕

どうやらI/Oエラーが頻発した後にディスクが認識できなくなったようです。光輪サーバーのHDDって前面から簡単に取り出せる様にスロットイン式なのですが… 接触不良を時々起こしているので、今回もそうかなぁ。。。と

再起動すればまた認識するかなぁ… なんて軽い気持ちで再起動したら、あがってこなくなっちゃいました。 😆
これは現地に赴いて確認するしかない… という事で夜に覗いて来ました。

もしやRAID構成が正しく無くて吹っ飛んじゃったんじゃ… なんて危惧したものの、BIOSでSMARTの検知を有効にしていたため、BIOSのポスト画面で止まっていただけでした。

BIOSのエラー停止を無効にして、念のためサーバーを軽く掃除した上でHDDを付け直して起動したところ、すべてのディスクもちゃんと見えてデータも問題なさそうでした。 😛
とりあえずは、様子見ですかねぇ…

録画PCの録画データをおいたりしているRAID上の領域に対してたまには…
と、深く考えもせずデフラグを流してぽけーっとしていたんですが、
なーんか、やけに速度が遅いなぁーとRocketRAIDのWEB管理画面を開いてみると、、、

はい、なんかディスクが1台ぶっ壊れてて
勝手にスペアドライブにリビルドしかけてる最中でした 😯
いやぁ、それは遅くもなるよ…うん。

まずは故障したディスクの変わりに新しいディスクを用意。
容量増強の思惑にて前に導入したHGST社製の1T HDDと同じモデルにした。

交換したディスクはこんな感じ。ポートマルチプライヤを通さない接続位置なので、
RocketRAIDの接続的には「1/2 ポート」といったところ。

左が壊れた古いディスク、右が新しい交換するディスクです。
いやぁ、WDは色々と苦労させられたからなぁ… 😐

故障したディスクを取り外して、新しいディスクに交換したところです。
交換したディスクのアイコンに「U」がついてます。
たぶん、UninitializedのUかな？

「Manage」から「Device」で詳細を確認。
上部にある「Initialize Device」を選びます。

新しいディスクが表示されるので、チェックを付けて「Submit」！

アイコンから「U」のマークが消え、RocketRAIDで操作できるようになりました。

勝手にリビルドされても困るので、次にスペアプールを空にします。
「Manage」から「Spare Pool」を選択。
現状スペアプールに割り当てられているディスクを選択して「Remove Spare」！

スペアから削除していいのか訊いて来るので「OK」！

スペアプールが空になったことを確認します。

1/2が入るべき部分に「1/4/4」があるのがわかります。
「Unplug」を押してAraay全体を一旦取り外します。
（この操作にはArrayへアクセスしているアプリを全て停止する必要があります）

こんなウィンドウが表示されれば取り外しは成功… 😎

ディスクが見えなくなりました。「Rescan Deivce」を選択！

ディスクをスキャンし、RAIDがクリティカル状態にて認識されました。
画面右上の「Maintenance」を選択すると、先ほどの「1/4/4」に置き換わっていたディスクがOffline Diskになっています。
「Add Disk」をクリックし、新しいディスクを選択します。

リビルドが開始されました！

スペアプールに忘れずにスペアを追加しておきましょう。
もともとスペアだったディスクを選択して「Add Spare」！

スペアを追加していいのか訊かれるので「OK」！

これでスペアプールが元の状態に戻りました。

あとは、リビルドが完了すれば対応完了です。 😀

もしかすると、スペアから元のディスクに戻すには、
OCE/ORLMを使えばいいのかもしれません…が、
今のところ1勝2敗なので、あまり使う気がおきず。。。

まぁ、とりあえず元に戻ったからいいや！ 😆

[rakuten]pc-idea:10000837[/rakuten]
[rakuten]blue-line:10016458[/rakuten]
[rakuten]bestdo-rk-shop:10036150[/rakuten]
[rakuten]gbbparts:10000951[/rakuten]

実は結構前から冗長化外れてたんですが、
このたびちょっくらディスクを交換してみたのでメモがてら…

作業はコチラを参考に実施
http://centossrv.com/centos5-raid-3.shtml

当初は壊れたDiskを差し換えて後はリモートで…
と思っていたんですが、ちょっくら再起動してみると驚きの新事実 😯

・・・ミラー側（正常な方）から起動できないじゃん（爆死）
なんかgrubのインストールがおかしかったんだろうか、
プライマリ側（壊れた方）から起動してミラー側に切り替わる
みたいな動きで辛うじて稼働していたらしい…恐ろしや 😐

とりあえず、故障したディスクに戻してOSを起動の後、
上記URLにもある、grub setup云々を実施。
壊れたディスクを抜いて、ミラー側単独起動できることを確認してから新しいディスクを挿入ー♪

とりあえずパーティションを切るので、正常なディスクを参照…
# fdisk -l /dev/sda

ディスク /dev/sda: 500.1 GB, 500107862016 バイト
ヘッド 255, セクタ 63, シリンダ 60801 Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O size (minimum/optimal): 512 bytes / 512 bytes
ディスク識別子: 0x000cfb83

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sda1   *           1         131     1048576   fd  Linux raid 自動検出
パーティション 1 は、シリンダ境界で終わっていません。
/dev/sda2             131       60797   487301120   fd  Linux raid 自動検出

・・・終点と始点が一緒かよ、
新しいディスク側に同じように切ろうとしても132スタートになっちゃぅのでとりあえず1個スライドさせて作成…
/proc/mdstatを見る限りでは、不良のディスクは既にエントリされていなかったため、あとはmdadmコマンドで新しいディスクをaddするだけ… なんですが、ここで問題発生！

# mdadm /dev/md0 –add /dev/sdb1
mdadm: Cannot open /dev/sdb1: Device or resource busy

なんか、忙しいってー？
でも、ddコマンドとか普通に使えるしなんだろーと思いながらも/dev/sdbにfuserをしてみると…
どうも、multipathdが定義ファイルに存在しない新しいディスクなので、マルチパスデバイスだと認識してガッツリつかんでいるしらい…

multipath -ll コマンドで、型番をコピーし、/etc/multipath.conf に例外として追記
service multipathd reload で束縛から解放されました…. 😛

あとは通常通りaddして、grubやって…終了！
交換したディスク側からの起動確認はできていない！！
（あと、正常なディスクは500GBだが、交換したディスクは1TBだ勿体ねー！！！）

[rakuten]pc-idea:10001917[/rakuten]
[rakuten]auc-fullspec:10000081[/rakuten]
[rakuten]auc-fullspec:10000080[/rakuten]