自作PCサーバーで利用のHDDを3.5″から2.5″のものに交換して省電力化する。
はじめに
自作PCサーバーのOS周りは、ESXiをハイパーバイザーとして各種VMにLinuxやWindowsをSSDに導入して運用しているが、データディスクとしてHDDを利用している。
HDDには、3.5″(「”」はインチと読む)のものを利用しているが、今回、これを2.5″のものに交換する。
3.5″や2.5″は内蔵しているディスクのサイズで、パーツとしてのサイズは大きく異なり2.5″のものは容積がより小さい。
2.5″のものは主にノート用を前提に設計している部分もあり、消費電力も少ない。
ただし、3.5″の方が大容量でデータ転送速度も速い。
今回対象のデータディスクでは、容量や転送速度の優先度は低く、消費電力を低減することが主な目的となります。
なお、「自作PCサーバーの消費電力を約40W削減した話」記事の投稿順は、作業順とは違いますのでご了承ください。
旧環境と新環境
- 旧環境
VMとしてCentOSとWindowsとOMV(OpenMediaVault)があり、3.5″8TBのHDD上にVHD(仮想ハードディスク)がCentOSとWindows用にそれぞれ2TBと4TBが存在していた。
なお、8TB中の残りの約2TBは、インストール用OSのISOや、手動でバックアップしたVMのコピーを格納していた。
3.5″8TBにはSeagate BarraCuda ST8000DM004 5400rpmを利用、データシート(https://www.seagate.com/www-content/datasheets/pdfs/3-5-barracudaDS1900-14-2007JP-ja_JP.pdf)から動作時の消費電力は5.3Wとなる。 - 新環境
CentOS用のVHD2TBとISOやバックアップを2.5″4TBに移行。
WindowsのVHD4TB内部の各ファイルをNAS-RAID5に移行し、VHDは廃止。
2.5″4TBにはToshiba MQ04ABB400 5400rpm 15mm厚を利用、データシート(https://toshiba.semicon-storage.com/content/dam/toshiba-ss-v3/master/en/storage/product/internal-specialty/cHDD-MQ04AB_product-overview_r2s.pdf)には4TBモデル(15mm厚)は載ってないが、2TBモデル(9.5mm厚)や1TBモデル(7mm厚)の動作時の消費電力はどちらも1.65Wなので、4TBモデルはあっても2Wぐらいだろう。
VHD2TBのコピーで問題発生
Windowsで利用の旧VHD4TB内部の各ファイルは、NAS-RAID5を構築した(2020年)後、少しずつコピーしていたので問題とならなかったが、CentOSで利用のVHD2TBは今回3.5″8TB(ST8000DM004)から2.5″4TB(MQ04ABB400)にコピーしなければならない。
当初、全VMをシャットダウンし、ESXiにSSHでログインして、VHDファイル一式(拡張子vmdk)をコピーしようとしたのだが、コピーの進捗状況を確認すると2TB分コピーするのに約22時間かかることが判明した。
VHDの本体は2TBの1つのファイルなので遅すぎないか?と思いつつも、約22時間のVM停止は致し方なしとコピーを続けたのだが、1時間30分ぐらいに「cp: read error: Input/output error」でコピーが停止してしまった。
このためvomaコマンドで修復(fix)を試みたのだが、Errorは見つかる(Found)ものの、修復(Fixed)されるものではない。
[root@ESXi:~] voma -m vmfs -f fix -d /vmfs/devices/disks/t10.ATA_____ST8000DM0042D2CX188__________________________________XXXXXXXX
Running VMFS Checker version 2.1 in fix mode
Initializing LVM metadata, Basic Checks will be done
Checking for filesystem activity
Performing filesystem liveness check..\Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).
Phase 1: Checking VMFS header and resource files
Detected VMFS-6 file system (labeled:'SG8TB-004') with UUID:XXXXXXXX-XXXXXXXX-XXXX-XXXXXXXXXXXX, Version 6:82
Found stale lock [type 10c00008 offset 97542144 v 16, hb offset 3211264
gen 509, mode 1, owner XXXXXXXX-XXXXXXXX-XXXX-XXXXXXXXXXXX mtime 1941
num 0 gblnum 0 gblgen 0 gblbrk 0][Cleared]
Found stale lock [type 10c00002 offset 98107392 v 18, hb offset 3211264
gen 503, mode 1, owner XXXXXXXX-XXXXXXXX-XXXX-XXXXXXXXXXXX mtime 3176
num 0 gblnum 0 gblgen 0 gblbrk 0][Cleared]
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
ON-DISK ERROR: JBC inconsistency found: (15,0) allocated in bitmap, but never used
Total Errors Found: 1
Total Errors Fixed: 0
Total Partially Fixed errors: 0
仕方ないので、CentOS(VM)を起動してxfs_repairコマンドで修復を試みた。
# xfs_repair /dev/sdb1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
:
ログの続きの記録は取り損なっているが、エラーは出てなかったので修復はされなかった。
仕方がないので、2.5″4TB上に新規でVHD2TBを作成し、CentOS(VM)に新旧のVHD2TBを両方とも接続(mount)し、VHD内部のファイルをcpコマンドでコピーすることにした。
CentOS(VM)上で動作させているサービスその他は動作したままで、「cp -drpu」のオプションで旧VHD2TBから新VHD2TBへコピーする。
cpコマンドの各オプションは次の動作となる。
d: –no-dereference(コピー元にあるシンボリックリンクを決してたどらない) –preserve=links(ディレクトリ内のハードリンク属性の維持) と同様
r: 再帰的にディレクトリをコピーする
p: –preserve=mode,ownership,timestamps と同様=ファイルの属性のmode(パーミッション),ownership(所有者),timestamps(タイムスタンプ)を維持する
u: ファイルがコピー先ファイルより新しいか存在しない時だけコピーする
VHD2TBのうち実際に利用しているのは1.4TB程だが、コピー対象となるファイルは数KBのものが多く、終了するまでに約24時間かかってしまった。
その際、4ファイルのコピーに失敗していた(cp: `/mnt/old/XXX’ の読み込みエラー: 入力/出力エラーです)が、VHD2TB内のファイルは、週に1回NAS-RAID5にrsyncでバックアップを取っているため、そこからリストアすることで解決した。
また、CentOS(VM)のサービスその他は動作したままなので、旧VHD2TB上には新規や更新のファイルが追加されている。
そのため、旧VHD2TBと新VHD2TBの接続(mount)を入れ替え(スワップ)、再度「cp -drpu」のオプションで旧VHD2TBから新VHD2TBへコピーを実施することで、コピー中に追加された分も漏れなくコピーすることで解決しました。
最後に、旧VHD2TBをCentOS(VM)の設定から切り離して、3.5″8TBのHDD本体を外して交換終了です。
消費電力の低減
HDD交換前後の自作PCサーバーの消費電力は次となりました。
交換前(3.5″)消費電力:118~122W
交換後(2.5″)消費電力:115~118W
3~4W程度の省電力化を確認しました。
最後に
3.5″HDDから2.5″HDDの移行は、2020年にNAS-RAID5を構築したときから予定していたものなのだけど、今回やっと移行が完了したものである。
途中、予期しないトラブルもありましたがその解決方法や、省電力化なども含めて何かの参考になれば幸いです。
ご意見、ご要望、不具合などのご連絡
ご意見、ご要望、不具合などのご連絡は次からお願いします。
- コメント
本投稿へ下部の コメントを書き込む からご連絡ください。
コメントは承認方式となっており、当方が承認しないと公開表示されません。
公開表示を希望されない方はその旨コメントに記述ください。 - Twitter
ご連絡は @dratech2020 https://twitter.com/dratech2020 の該当ツイートに返信するか、ハッシュタグ「#プログラミングの深淵を求めて」を付けてツイートしてください。 (すぐに気が付かない場合がありますので、ご了承ください)
コメント