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 その1

管理人宅のESX化された録画PCのRAIDボリュームですが、ここ数年容量がひっ迫しております。

5インチベイ上段がRAIDディスク6本、下段がリムーバブルHDDになっています。
見えている部分以外にも1本RAIDディスクがあるので、1TB×7本 RAID6で… 5TBの容量があるんですが、微妙にあふれ気味です。  😉

そこでそこで!、管理人的クリスマスプレゼント!!って事で。


いよいよ全部入れ替えの為に用意しましたHDD!!!


『左側:Seagate ST3000DM008 3.5インチ内蔵SATA 3.0TB』
『右側:Seagate ST2000LM007 2.5インチ内蔵SATA 2.0TB 7mm厚』
別に7mm厚に拘りがある訳ではないんですが、普通にコレが一番安かったのでこれを選択しております…  😆


Adaptec Storage Manager を起動してRAIDの情報を確認します。

実は、7本中の3本は2TBに交換済みだったりします。ちまちま交換しているのでロットや型番がバラバラなのがアレ(うち2本は9.5mm厚だし)ですが…

交換する対象の1TB(931.513GB)のディスクを選んで「Blink physical drive」をポチり

アクセスLEDが周期的に点滅しているHDD(この場合は右下)を交換します。

「OK」を押して問題のHDDを電源入ったままの状態でサクっと取り外し!

HGST(左)からSeagate(右)へ交換します。

元通りスロットに挿入して暫く経つと…

リビルドが開始されました!
RAID6なので、2本同時に交換しても… まぁいいんですが、まぁのんびり行きましょう。  🙂

…で、取り外した旧HDDはと言うと…

ちょっと前の秋葉原週間の時に800円くらいで購入したUSB3.0 HDDケースに挿入…
これで我が家にもUSB3.0機器が登場したぜ!  😛 

好評につき売切れです


好評につき売切れです

好評につき売切れです

Redhat/CentOS yumアップデート前に自動的にESXのスナップショットを作成する

Redhat/CentOSのyumアップデートは皆さんどのくらいの頻度で実施されているんでしょうか…
管理人は過去に自動的に毎日実施する様にしていたら、gccのライブラリ更新でエラーを吐き始めてそのままOSがお亡くなりになっていた事があり、それから慎重になってしまいました。
ただ、現在の光輪サーバはESX上で動いているのでスナップショットで簡単にバックアップが撮れるので活用する事に…

ただ手動でやるのは面倒なのでスクリプトを作ってみました。
まず、ホストのESXiシェルとSSHを有効にしておく必要があります。


(上記クリックでダウンロード)

事前にTeraTerm等でESXにログインして、vim-cmd vmsvc/getallvms コマンドでVMIDを控えて下さい。

例)
 [root@Living-ESX:~] vim-cmd vmsvc/getallvms
 Vmid          Name                                File                              Guest OS          Version                Annotation
 1     Linux-Server          [datastore] Linux-Server/Linux-Server.vmx       rhel6_64Guest            vmx-11    Redhat
 2     WindowsXP             [datastore] WindowsXP/WindowsXP.vmx             winXPProGuest            vmx-11
 3     Windows10             [datastore] Windows10/Windows10.vmx             windows9_64Guest         vmx-11
 [root@Living-ESX:~]

上記スクリプトの下記を環境に合わせて修正
VMID=上記で控えたVMID
PASSWORD=’ESXのパスワード
ESXIPADD=”ESX 管理IPアドレス

これを対象Linuxにて、OS側で自動的なyum updateが仕込んである場合はそちらを停止した上で、rootのcronに以下の様な感じで登録すればOKです。(/root/updateyum.shに配置した場合)

30   01 *  *  *  /root/updateyum.sh >> /root/updateyum.log 2>&1


成功するとこんな感じでスナップショットが作成されます。

ESXの余剰リソースでMoneroをマイニング!

現在管理人宅で稼働しているリビングESXマシンですが、ゲストとして動作している光輪サーバを除くと、録画PCは夜間しか殆どCPUを使いません。
ねんがら年中検証している訳でもないですし、殆どの時間CPUは遊んでる事になります。
遊んでるくらいなら… と物は試しにUbuntuをESXのゲストとしてインストールして、MinarGateと言うマイニングソフトを入れてみました。
CPUの優先度をめちゃくちゃ低く設定し、最低限のリソースを割り当ててマイニング開始! 😛


それから数ヶ月…


それなりに溜まってきました。
こんなのがお金に成るのか…? かなり半信半疑な管理人です。
物は試しに換金してみることに。 😎


今のレートはこんな感じです。
徐々に下がっている様に見えますが、スケールを大きくしてみると徐々に上昇している感じですかね…

Moneroから日本円への換金はココのサイトを参考に行いました。
実際のところ、coincheckという下記の取引サイトにMinarGateから送金してconcheckで売却して日本円にするだけです。

ビットコイン取引高日本一の仮想通貨取引所 coincheck bitcoin


まずcoincheckにユーザー登録をして、本人確認を行います。
免許証、パスポート、顔写真付きのマイナンバーカードなどがあれば簡単です。
coincheckの準備ができたら、「コインを受け取る」でMoneroの入金用アドレスを作成します。


MinarGateにてWithdrawから送金したい金額を入力します。
coincheckでは少数第8位以降は切り捨てなので、無駄に送金しない様に注意…


無事に送金処理ができればこんな感じで表示されます。


送金が完了するとcoincheckではこんな感じで表示されます。
なお、送金にはそれなりに時間が掛かりました。


「コインを売る」メニューから、Moneroを選択して売却します。
レートはリアルタイムで更新されているので、いいタイミングで「売却する」ボタンを押すべし!


売却されて日本円になりました。


今度は「日本円を出金する」から振込先口座を指定して「出金申請をする」でOK!
金額が3900円より多いのは、口座開設の本人確認のために1000円入金している為です。
数日で指定口座におかねが振り込まれる事になります… 😀

わーぉ、本当にお金になりましたよ。なんと言うか、不思議な世界ですねぇ…

ビットコイン取引高日本一の仮想通貨取引所 coincheck bitcoin

Next »