うちの仮想環境では、ESXIの仮想マシンとして、NexentastorというストレージOSを実行し、RAIDとNFS機能をESXiに提供しています。
で、いつの間にか１つのプールがデグレートしていたので、確認と対策です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
root@NS003:/volumes# zpool status | more pool: RAIDZ-SATA-1 state: DEGRADED status: One or more devices are faulted in response to persistent errors. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the faulted device, or use 'zpool clear' to mark the device repaired. scan: resilvered 3.18G in 0h3m with 0 errors on Sun Apr 29 22:42:59 2018 config: NAME STATE READ WRITE CKSUM RAIDZ-SATA-1 DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 c2t0d0 ONLINE 0 0 0 c2t1d0 FAULTED 0 0 0 too many errors c2t2d0 ONLINE 0 0 0 logs c2t6d0 ONLINE 0 0 0 cache c2t5d0 ONLINE 0 0 0 errors: No known data errors |
RAIDZ-SATA-1のc2t1d0の調子が悪いようです。
修復コマンド[zpool clear RAIDZ-SATA-1]も試してみましたが、少し経つとまたデグレートします。
c2t1d0は、ESXiが直接認識しているSATA HDD上のVMFS5上にあるVMDKが実態です。確認してみます。
|
|
#Nexentastor上の認識 c2t1d0 sd6 disk 2.00 TB RAIDZ-SATA-1 mpt VMware, Rev. 1.0 #nexentastor仮想マシン上の認識 ハードディスク 9 [VMSV03-SATA-5] NS003/NS003.vmdk 2TB (SCSI 1:1) |
実際に調子悪いデータストアは、VMSV03-SATA-5のようです。
この情報は控えておきましょう。
特に、HDD番号、ファイルパス、容量、ディスクSCSI IDは控えておきましょう。
VMSV03-SATA-5を丸ごと交換しますので、このデータストアを使用している仮想マシン名と、割り当てしているVMDKを控えておきます。（今回は、Nexenta仮想マシンの１台のみ）
vCenterで管理している場合は、データストアで割り当てしている仮想マシンの一覧が確認できます。ただ、テンプレートなどは出てこないので、データストアブラウザでも必ず確認しておきましょう。
では、ESXiのデータストアで、VMSV03-SATA-5の情報を確認します。
|
|
VMSV03-SATA-5 標準 Local ATA Disk (naa.50014ee2ba5bb332):1 非 SSD 3.64 TB 1.01 TB VMFS5 2018/04/30 9:02:04 有効 無効 不明 |
対象ディスクのIDは、naa.50014ee2ba5bb332のようです。
（esxcli storage vmfs extent listコマンドでも確認できます。）
ESXiのコンソールから、naa.50014ee2ba5bb332の詳細情報を確認します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
/etc/init.d # esxcli storage core device list -d naa.50014ee2ba5bb332 naa.50014ee2ba5bb332 Display Name: Local ATA Disk (naa.50014ee2ba5bb332) Has Settable Display Name: true Size: 3815447 Device Type: Direct-Access Multipath Plugin: NMP Devfs Path: /vmfs/devices/disks/naa.50014ee2ba5bb332 Vendor: ATA Model: WDC WD40EFRX-68W Revision: 0A82 SCSI Level: 5 Is Pseudo: false Status: on Is RDM Capable: false Is Local: true Is Removable: false Is SSD: false Is Offline: false Is Perennially Reserved: false Queue Full Sample Size: 0 Queue Full Threshold: 0 Thin Provisioning Status: unknown Attached Filters: VAAI Status: unknown Other UIDs: vml.020000000050014ee2ba5bb332574443205744 Is Local SAS Device: false Is USB: false Is Boot USB Device: false No of outstanding IOs with competing worlds: 32 /etc/init.d # |
VMSV03-SATA-5のDisk(naa.50014ee2ba5bb332)の実態は、
“WDC WD40EFRX-68W”
とのことです。
ESXiのストレージアダプタのところで、naa.50014ee2ba5bb332を探すと、
ストレージアダプタが「Patsburg 4-Port SATA Storage Control」で
ランタイム名が「vmhba2:C2:T0:L0」となっています。
Z820でいうと、内蔵SATAポートのうち、3Gbps対応4ポートの3番目に接続されているHDDですね。
できれば交換用パーツも同型番がよいので、WDC WD40EFRXを用意します。
（Amazonの翌日配送すごく便利）
また、今回のように仮想マシン内でRAIDを組んでいるディスクであれば不要ですが、そうでない場合は、できるだけデータストア「VMSV03-SATA-5」上の仮想マシンデータ(vmxやvmdk)を別のデータストアに待避しておきましょう。
vCenterで管理している場合は、データストアで割り当てしている仮想マシンの一覧が確認できます。ただ、テンプレートなどは出てこないので、データストアブラウザでも必ず確認しておきましょう。
（今回はHDDの死に掛け状態でデータの待避する余裕がありましたが、完全にHDDを認識しなくなる場合もありますので、バックアップやRAID化による冗長化をお勧めします。）
交換用パーツが用意できたら、壊れたHDDを交換します。
HDDのホットプラグに対応していなければ、一度PCの電源断が必要です。
交換したら、ESXiのストレージで、対象のDiskがなくなっていることを確認します。もし、まだあるようであれば、違うDISKを交換したということです。
すぐに正しいDIskと交換しましょう。
では、交換したDiskをストレージの追加からESXiに認識させます。
ストレージから、ディスク/LUNとして追加させますが、ここで注意が１つ。
ESXiをvCenterで管理している場合、以前使用していた「VMSV03-SATA-5」というデータストア名は使用できません。（vCenterで以前のデータストア名に仮想マシンが紐付けされてしまっているため）
とりあえず、「VMSV03-SATA-5-2」と名前を変えて、追加します。
新しいディスクをデータストアとして登録できたら、以前のデータストア「VMSV03-SATA-5」に日も図いていた仮想マシンのVMDKを修正していきます。
vCenterで管理していれば、データストアの「VMSV03-SATA-5」に仮想マシンが登録されていますので、順次該当ディスクの割り当てを変更していきます。
該当ディスクかどうかは、仮想マシンの編集から、ハードディスクをクリックして、ディスクファイルが、「VMSV03-SATA-5」で始まっているものを確認します。状態が認識できていないので、サイズが0となっているのでこちらも確認して、削除しします。
そのまま、Diskを新しいデータストア「VMSV03-SATA-5-2」に割り当てします。控えておいた以下の情報を元に、Diskを以前と同様に追加していきます。
（容量、ディスクSCSI IDは必ず一致させましょう。）
|
|
#nexentastor仮想マシン上の認識（控えていた情報） ハードディスク 9 [VMSV03-SATA-5] NS003/NS003.vmdk 2TB (SCSI 1:1) |
すべての仮想マシンのディスク割り当てを同様に修正していきます。
データストアに紐ついた仮想マシンがなくなれば、vCenterから以前のデータストア「VMSV03-SATA-5」が削除されます。
以前のデータストア「VMSV03-SATA-5」が削除されたのを確認したら、今回追加した新しいデータストア「VMSV03-SATA-5-2」を「VMSV03-SATA-5」にリネームします。
これで、vSphereとしては、復旧完了です。
Nexentastorで実施しているRAID冗長化は、Nexentastorの仮想マシンを起動すれば、自動的に新しいDISKが挿入されたことを確認して、リビルドが開始されます。
（リビルドが実行されない場合は、NexentastorのWeb GUIからreplaceを実施）
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
root@NS003:/volumes# zpool status RAIDZ-SATA-1 pool: RAIDZ-SATA-1 state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Tue May 1 03:19:50 2018 34.7G scanned out of 2.28T at 15.3M/s, 42h38m to go 11.5G resilvered, 1.49% done config: NAME STATE READ WRITE CKSUM RAIDZ-SATA-1 DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 c2t0d0 ONLINE 0 0 0 replacing-1 DEGRADED 0 0 0 c2t1d0/old FAULTED 0 0 0 too many errors c2t1d0 ONLINE 0 0 0 (resilvering) c2t2d0 ONLINE 0 0 0 logs c2t6d0 ONLINE 0 0 0 cache c2t5d0 ONLINE 0 0 0 errors: No known data errors |
約9時間後にリビルド完了
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
root@NS003:/usr/sbin# zpool status pool: RAIDZ-SATA-1 state: ONLINE scan: resilvered 676G in 8h32m with 0 errors on Tue May 1 11:52:26 2018 config: NAME STATE READ WRITE CKSUM RAIDZ-SATA-1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 c2t1d0 ONLINE 0 0 0 c2t2d0 ONLINE 0 0 0 logs c2t6d0 ONLINE 0 0 0 cache c2t5d0 ONLINE 0 0 0 errors: No known data errors |
（余談）
取り外しした調子の悪くなってしまったHDDですが、別のWindows PCにUSBで認識させて「Crystal Disk Info」で確認してみましたが、そんなにひどい状況ではありませんでした。
・代替処理済みのセクタ数 0
・代替処理保留中のセクタ数 3
・回復不可能セクタ数 3
正直、このHDDをVMFS領域として使用するのはためらわれますが、
NTFSで完全フォーマットすれば一時ファイル領域としてはまだつかえそうなので、NTFSでフォーマットしようとしますが、今の状態ですと領域開放でできません。
VMFS5でフォーマットされたディスクはWindowsからは認識できないのと、
「GPT保護パーティション」がかかっているため、ボリュームの削除ができません。
GPT保護パーティションを開場するためには、DiskPartでコマンドを実行する必要があります。
・Diskpartを起動
・list Disk (対象ディスクを確認)
・select disk 3 (対象ディスクを選択)
・list partition (確認)
・clean (保護パーティション属性のクリア)
http://www.atmarkit.co.jp/ait/articles/1106/10/news117.htmlWindowsでGPT保護パーティションを削除する
以上の作業で、VFS領域がクリアされます。
後は、完全フォーマットを実施してみて、smart値が正常に戻ればも儲けものです
（完全フォーマット開始から24時間ほどかかって現在61%完了。）
（この時点でsmart値がすべて正常に戻りました。）
（このHDDはまだがんばってもらえそうです。）
