実家用ESXサーバを作ろう その1

さて、ちょっと前に先日のマザーボード交換やSSD交換、メモリ交換にてあまったパーツで実家用のESXサーバを作ろう… とか何とか書いた気がします。
ぼちぼちパーツがそろってきたので、そこら辺に転がっていたPCケースを流用してサクっとベース環境だけ作ってみました。


『Intel Core i5-3470 LGA1155』

リビングESXと同じ第2世代と、チップセットが対応している第3世代で安価な4コア4スレッドのものを探していたんですが、第3世代のCore i5-3470が安く手に入ったのでこちらをチョイス! 🙂

リビングESXは第2世代Core i7だったので、メモリはせっかくDDR3 1600対応でしたが1333でしか動作していませんでした。シュリンクにより消費電力量も落ちているので実家用としては良いのではないかと…


『富士通 D2516-C11 H/W SAS RAID Card(上)』
『HP NC360T Intel 2Port NIC(下)』

D2516-C11は、LSI MegaRAID 2008チップを採用した富士通オリジナルの基盤だそうです。
VMwareのサポートリストにはありませんでしたが、恐らくは普通にLSI MegaRAID 2008として認識するんではないかと予想… 🙄
HP NC360Tは、リビングESXにて既に使用中なので実績アリです。


とりあえず仮組み…
ストレージは、先日のSSD交換にて余った120GBと128GBのSSD2台をMegaRAIDに接続。


よくわかりませんが、ちゃんと起動しました!
LSI MegaRAIDのBIOS画面でWebBIOSを選択すると、何故かマザーボードの設定画面が起動してくるので、BOOTからRAIDっぽいものを選択したらこんな画面に… 😛

愛と勇気と根性でなんとかRAID0のボリューム作成に成功…
とりあえずUSBメモリを接続してESXi 6.7 Update1をインストールするところまでは完了! 😀

Intel NICや、MegaRAIDのボリュームは予想通りちゃんと見えてますね。
オンボードNICは当然ですが見えてないです。
…まぁここら辺は追々やっていきますかね!! :mrgreen: 

録画PCもといリビングESXのデータを保護する!

録画PCもといリビングESXは、現在OS上のミラーで構成していますが、そのうちまたH/W 基盤(初期に使ってたヤツ)に戻そうかな… なんて考えていたりします。

…で、前々から問題だとは思っていたんですがどうしようもなかったのが…
「HDD壊れたときってどうやって気づくねん問題」です。 🙄
リビングESXには3.5インチベイはシャドウベイしかないため、外からはHDDの動作状況が全然わかりません。
…なので、極端な話… 壊れていたとしても気づきません。
それでは意味が無いよね… ってことで改造してみました!


『iCY DOCK FlexiDOCK MB522SP-B』

3.5インチベイに2.5インチHDD/SSDを2台収納でき、イジェクトボタン兼アクセスLEDでディスクの稼動状況が確認できるヤツです! 😛


箱を開けるとこんな感じ…

背面はこんな感じで、めちゃくちゃシンプル…

前面はこんな感じになってます。
これに適当なHDDを挿入してみると…

こんな感じでイジェクトボタンが飛び出します。
この2.5インチHDD/SSDスロットにはロック(飛び出し防止)機構はありませんが、上から強力な板バネで押さえつけられているので、そう簡単には抜けそうに無いです。(むしろ硬いくらい)


これをリビングESXのこの3.5インチシャドウベイに取り付けます。

ねじ穴の位置が合わなかったのでドリルで穴あけ改造…

5mmの穴をケース横に開けて…
そこに適当な長さにカットした5mmのアクリルパイプを通せば…

アクセスLEDの完成!
これでディスクの動きがおかしかったら簡単に確認できますね!! 😀

余談ですが、FlexiDOCKの固定用ネジの穴が、インチネジじゃなくてミリネジだったのでこれ要注意…




Linux LVMミラーを構成する!

折角のG/WなのでESXのバージョンを6.0から6.5にUpdateしようと思って色々とやってみたらデータが飛んだ今日この頃です…  😥 


H/W RAID基板で無理やりRAID1化していたので、片方のSATAケーブルを抜いてUpdateしようとしたところ、ESXが見えなくなるという事態が発生…
新しく交換したH/W RAID基板が役に立たない事がここにきて判明…
何故か基板を通さずに接続すると中のデータは見えたので、旧H/W RAID基板に交換してUpdateしようとしたんですが…


普通に起動すると問題ないにも関わらず、CDから起動するとVMFSパーティションが発見できない自体に…  😆
仕方なく、ココを参考にESXの設定をダウンロードしてUSBメモリに新規でESXをインストールして設定を書き戻ししてなんとか復旧。

壊れかけたRAIDは意味がないので、片方のディスクを直接接続して新規にデータストアを作成し中のデータをちまちまコピー…
やっとこさっとこESXのバージョンを6.5に上げたのですが、USBパススルーで見せていたICカードリーダーがどうやっても使えない事が判明…(ライセンスの関係か?)
仕方なく元のバージョンに戻すハメに。
色々復旧作業をしている最中にハングアップ状態になったため強制的にリセットを掛けたらLinuxが起動不可能に…  👿

症状は、データディスク「xxxx.vmdk」が依存しているスナップショット ディスクの 1 つを開くことができません… などというもの。
色々調査してみたものの、構成ファイルに不足はなくvmdkファイルを再作成しても解消せず…
コピーも何もできず、Invalid argument (1441801) エラーが出力されるのみ。
どうもVMFSのハートビート情報とやらが壊れているんだとか。解消法はVMwareにコンタクトしろ…と書かれた情報しか見つからなかった。  :mrgreen:

仕方ないので新規にまっさらなディスクを作成しLinuxにアサイン
元のディスク構成をこのブログに書いていたので、Googleのキャッシュから同容量でvgを再作成。
後は、日次で自動的に取得しているバックアップ(数日に1回しか成功してないけど)からリカバリ…

これで一部領域を覗いて、1週間前程度までは何とか復旧できた。  😕
DBの情報だけはシステムディスク側にも最新のデータをちゃんとコピー出来ていたので復旧できたものの、画像ファイル(このブログのもの)などは再度Uploadし直して記事を修正したり…

Windows10Proであれば標準機能でソフトウェアミラーが組めることがわかったので、H/W RAID基板無しで構成してみることに…(参考はこちら
LinuxのLVMの場合はどうすればいいのか… やってみたので以下に残しておきます。

PVを初期化
[root@Linux-Server ~]# pvcreate /dev/sdc
Physical volume "/dev/sdc" successfully created.
[root@Linux-Server ~]#

初期化したPVをミラーを構成するVGに追加
[root@Linux-Server ~]# vgextend /dev/vg01 /dev/sdc
Volume group "vg01" successfully extended
[root@Linux-Server ~]#

VGのに追加されたことを確認
[root@Linux-Server ~]# vgdisplay -v vg01
--- Volume group ---
VG Name vg01
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 6
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 4
Max PV 0
Cur PV 2
Act PV 2
VG Size 599.99 GiB
PE Size 4.00 MiB
Total PE 153598
Alloc PE / Size 75776 / 296.00 GiB
Free PE / Size 77822 / 303.99 GiB
VG UUID z1jfRV-0Udm-N1l0-aGrS-4DQc-0LPY-qLcMjF

--- Logical volume ---
LV Path /dev/vg01/lvol1
LV Name lvol1
VG Name vg01
・・・中略・・・
--- Physical volumes ---
PV Name /dev/sdb
PV UUID zBeoFk-K6dd-O72O-oSlh-AlHt-4K1j-XEQyoa
PV Status allocatable
Total PE / Free PE 76799 / 1023

PV Name /dev/sdc
PV UUID TB8AGg-685e-d3Mk-CJwe-bxpv-axNr-317b3D
PV Status allocatable
Total PE / Free PE 76799 / 76799

ミラー構成の対象となる論理ボリュームの数と名前を確認
[root@Linux-Server ~]# vgdisplay -v vg01 | grep lvol
LV Path /dev/vg01/lvol1
LV Name lvol1
LV Path /dev/vg01/lvol2
LV Name lvol2
LV Path /dev/vg01/lvol3
LV Name lvol3
LV Path /dev/vg01/lvol4
LV Name lvol4
[root@Linux-Server ~]#

ミラー構成
[root@Linux-Server ~]# lvconvert -m1 /dev/vg01/lvol1
Are you sure you want to convert linear LV vg01/lvol1 to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume vg01/lvol1 successfully converted.
[root@Linux-Server ~]# lvconvert -m1 /dev/vg01/lvol2
Are you sure you want to convert linear LV vg01/lvol2 to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume vg01/lvol2 successfully converted.
[root@Linux-Server ~]# lvconvert -m1 /dev/vg01/lvol3
Are you sure you want to convert linear LV vg01/lvol3 to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume vg01/lvol3 successfully converted.
[root@Linux-Server ~]# lvconvert -m1 /dev/vg01/lvol4
Are you sure you want to convert linear LV vg01/lvol4 to raid1 with 2 images enhancing resilience? [y/n]: y
Logical volume vg01/lvol4 successfully converted.
[root@Linux-Server ~]#

ミラーの構成情報を確認
[root@Linux-Server ~]# lvs -a -o name,copy_percent,devices vg01
LV Cpy%Sync Devices
lvol1 18.80 lvol1_rimage_0(0),lvol1_rimage_1(0)
[lvol1_rimage_0] /dev/sdb(0)
[lvol1_rimage_1] /dev/sdc(1)
[lvol1_rmeta_0] /dev/sdb(75776)
[lvol1_rmeta_1] /dev/sdc(0)
lvol2 100.00 lvol2_rimage_0(0),lvol2_rimage_1(0)
[lvol2_rimage_0] /dev/sdb(61440)
[lvol2_rimage_1] /dev/sdc(61442)
[lvol2_rmeta_0] /dev/sdb(75777)
[lvol2_rmeta_1] /dev/sdc(61441)
lvol3 100.00 lvol3_rimage_0(0),lvol3_rimage_1(0)
[lvol3_rimage_0] /dev/sdb(61696)
[lvol3_rimage_1] /dev/sdc(61699)
[lvol3_rmeta_0] /dev/sdb(75778)
[lvol3_rmeta_1] /dev/sdc(61698)
lvol4 100.00 lvol4_rimage_0(0),lvol4_rimage_1(0)
[lvol4_rimage_0] /dev/sdb(68096)
[lvol4_rimage_1] /dev/sdc(68100)
[lvol4_rmeta_0] /dev/sdb(75779)
[lvol4_rmeta_1] /dev/sdc(68099)

新たな不具合が出ない事を祈る…  😎 

録画PC RAIDディスク交換2017 その3

さて、RAID6ボリュームの拡張を開始してから24時間以上が経過しましたが…

Adaptec Storage Managerを見てみると…

Logical devicesのステータスが「Optimal」に変わってますので、やっと終了した様です。 🙂

イベントログを見てみると…
25日の1時29分から、26日の13時41分ですから… 36時間12分!
ふぃー、お疲れ様です。


ディスクの管理から該当のディスクを見てみても大きくなった感じはありません。
デバイスマネージャーを開いてスキャンとかもしてみましたが特に変化はなし… 何か方法はあるのでしょうが、メンドイのでサクっと再起動しましょう!  😉

Windows10は起動停止がサクサクなのでいいですね…

はい、再度ディスクの管理を開くと… ちゃんと拡張されて「未割り当て」ができてます。

既存の領域を右クリックして「ボリュームの拡張(X)」をポチり!

ボリュームの拡張ウィザードなるものが起動しますので「次へ(N)」

デフォルトで拡張された未割り当て分が表示されますので… 注目すべきは「ボリュームサイズの合計(MB)」部分でしょうかね。

最後に「完了」を押せば終了!簡単です。  😀

はい、無事に中のデータはそのままでボリュームが拡張されました!!


あとはひたすらにデータを戻す作業の始まりです…  🙄

« Prev - Next »