自宅サーバの起動ドライブが壊れてからOS入れ替えてMackerelでディスク監視するまでの話
このエントリで話してること
書いてたらやたら長くなったので要約します。
- 記憶域プールはOSをクリーンインストールしてもちゃんと認識するよ
- Hyper-V Server 2019とWindows10Proのワークグループ環境では、サーバマネージャーを使う時のTrustedHostsと資格情報マネージャーにNetBIOS名とFQDNのどっちも設定する必要があるよ
- MackerelのFreeプランで簡単なディスク障害なら検知できそうだよ
自宅サーバ運用5年目にして障害
HP ProLiant MicroServer Turion II NEO N5 F1F35A0-AAAE http://t.co/5CwnoYc8k2 お安くなってたので勉強のため購入
— 妖介🍬 (@kiai_hissatsu) July 26, 2014
2014年にHP Microserverを購入しました。当時家庭内NASにQNAP TS-110を使ってたんですが、やっぱRAID組みたいなって思いまして。あと大阪日本橋ふぁすとばっくで実物を見かけてなにこれめっちゃかわいい欲しい好きLOVE……ってなったので。
で、届いてからESXiがオンボードRAID認識しなくて*1泣いたり、CentOSで組んだZFSが翌日吹っ飛んで泣いたり、OpenMediaValueのVirtualBoxプラグイン*2が思った以上に遅くて泣いたりして、最終的にこちらの記事を参考にHyper-V Server 2012 R2＋記憶域プールでファイルサーバ＋仮想基盤を構築したわけです。
無料のHyper-V Server 2012 R2でファイル共有kero3.wordpress.com
Hyper-VでNASが作れて何が嬉しいって、SMB3以上が使える ってことですよ。パフォーマンスがぜんぜん違うの。ほんと違う。めっちゃ快適。
それで5年近く運用してたんですが、最近になってWindows Update後の再起動後に正常起動しないことが多くなってきました。
自動更新設定で概ね毎月第2水曜の数日後くらいに現象が出てたので、いやだなーこわいなーいやだなーこわいなーと脳内稲川淳二が遠回しに警告してきていたんですが、忙しさにかまけてつい電源ボタン長押しというその場しのぎをしておりました。
で、先日とうとう起動しなくなっちゃいました。
起動ドライブのディスク障害
ディスプレイを繋いで起動シーケンスを見守っていたら、無慈悲にもPXE BootがDHCPサーバを探しにいっておりました。要は起動ドライブの障害です。HDDの異音は聞こえませんでしたが、多分MBRあたりのセクタエラーでしょう。
で、起動ドライブを交換しました。WDのHDD160GBだったんですが、せっかくなのでSSD化します。手持ちで余ってたのはノートから抜いた128GB。
サーバの手術(オペ)してる pic.twitter.com/GfoeP2e8pB
— 妖介🍬 (@kiai_hissatsu) October 12, 2019
Microserverには3.5インチのストレージスロット✕4本とと5インチベイ✕1本を備えています。ストレージスロットは2TB以上のHDDで埋めて記憶域プールとして使い切ることにし*3、5インチベイに3.5インチドライブ用のブラケットを使って起動ドライブとしていました。今考えるとこの構造は振動を生みやすいのでHDDの寿命を縮めてしまったのかもしれません。
復元ではなく再構築へ
で、5インチベイのスペースにSSDを無造作に置いて接続しましたが、問題は中身です。
一応Hyper-V Server 2012 R2で構築した当時のWindows Backupイメージは残ってたんですが、今回このイメージは使えません。160GBのHDDから128GBのSSD、つまり小さいディスクへの移行はWindows Backupでは対応していないためです。
もともとHyper-V Server 2012 R2はメインストリームサポートが2018/01/09で終了して延長サポートフェーズにありますし、Hyper-V Server 2019へのアップグレードを行おうにもそもそもインプレースアップグレードできない仕様なので、この際クリーンインストールすることにしました。再構築といっても単一のHyper-V Serverホストには大した設定項目もありませんので、まぁ楽勝です。
記憶域プールの引き継ぎ
OS側はクリーンインストールするとして、問題は記憶域プールです。OSを初期化した場合、記憶域プールの構成がどうなるのか。構成情報が無くなったら中のデータが消失するのでやばいですね。
結論から言うと問題ありません。記憶域プールの構造はOS側ではなく、記憶域プールを構成しているディスク(プールディスク)側で保持しており、記憶域プールをサポートしたOSで自動的に認識します。つまりちゃんと引き継げるわけですね。よかったよかった。
これ、ある意味チップに依存するハードウェアRAIDよりも耐障害性が高いかもしれません。まぁパリティ計算遅いんですけども。
なお、OSをインストールした直後の認識では OperationalStatus が Read-only になるケースがあるみたいですが、俺の環境では最初から正常認識されてました( FriendlyName が chihiro のもの)。
PS C:\> Get-StoragePool FriendlyName OperationalStatus HealthStatus IsPrimordial IsReadOnly Size AllocatedSize ------------ ----------------- ------------ ------------ ---------- ---- ------------- chihiro OK Healthy False False 8.64 TB 5.45 TB Primordial OK Healthy True False 8.76 TB 8.64 TB
ただし、OSクリーンインストールすると当然ながらユーザのSIDが新規になるので、中に入っているファイルのNTFSアクセス権は再設定する必要があります。
資格情報の運用について
自宅サーバなのでWindowsネットワークはActiveDirectoryではなくワークグループ環境なんですが、どうやら最近のWindows Serverはワークグループ環境下でRSATで管理する場合*4、WinRMの TrustedHosts で信頼するホストにNetBIOS名とFQDNのどっちも登録する必要があるようです。
例えばホスト名が morinaka の場合、 morinaka と morinaka.local の両方になります。
PS C:\Windows\system32> Get-Item WSMan:\localhost\Client\TrustedHosts WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client Type Name SourceOfValue Value ---- ---- ------------- ----- System.String TrustedHosts morinaka,morinaka.local
TrustedHostsへの登録はPowerShellで設定する場合とwinrmコマンドを使う場合のどちらでもOKです。
PowerShellで設定する場合
Set-Item WSMan:\localhost\Client\TrustedHosts "morinaka,morinaka.local" -Concatenate -Force
winrmコマンドで設定する場合
winrm set winrm/config/client '@{TrustedHosts=”morinaka, morinaka.local″}'
ちなみに、最近のWindows10ではwinrmコマンドの記述が厳密化され、＠(アットマーク)と最後のシングルコーテーションが必須になったようです。地味にハマりました。
また、同様に資格情報にも同じようにNetBIOS名とFQDNの両方の登録が必要です。
cmdkeyでも確認できます。
PS C:\Windows\system32> cmdkey /list:morinaka*
morinaka* のために現在保存されている資格情報:
ターゲット: morinaka
種類: ドメイン パスワード
ユーザー: morinaka\yousuke
ターゲット: morinaka.local
種類: ドメイン パスワード
ユーザー: morinaka\yousuke
FQDNはサーバーマネージャーそのものへの追加とHyper-Vマネージャ、NetBIOS名は共有サービスやコンピュータの管理(リモートサーバ)で使うようです。ローカルDNSがあるActiveDirectory環境ならこんなことは無さそうですが。
どうもFQDN以外にNetBIOS名も登録しないとファイル共有やコンピュータの管理に支障があるようだ。そして同じようにTrustedHostsもFQDNとNetBIOSのどちらも登録が必要。うーんめんどい。 pic.twitter.com/DWYdnczeVm
— 妖介🍬 (@kiai_hissatsu) October 13, 2019
今後に備えたMackerel監視
さてOSのクリーンインストールも完了し、記憶域プールも無事認識し、管理できるようになりました。それはいいんですが、このまま放置しているとまたOSが吹っ飛ぶようなディスク障害が発生して脳内稲川淳二が騒ぎそうなので、ちゃんと監視するようにしましょう。
ですが、さすがに我が家にはZabbixサーバなんていう大層なものはないので、素直にMackerelを使うことにしました。MackerelのエージェントはGoで書かれていてWindows用のバイナリも用意されています。いぇーい便利。
ただし、デフォルトで取れるのは死活監視とパフォーマンス関連のメトリックくらいです。ディスク障害の検知にはちょっと工夫が必要になります。
Windowsのディスク監視にはいろいろ方法はありますが、メジャーな手段であるCrystalDiskInfoのS.M.A.R.T.監視はCLI環境しかないHyper-V Serverでは使えません。代わりにWindowsイベントログで監視します。
幸い、MackerelのWindowsエージェントにはWindowsイベントログ監視プラグインが最初から入っています。あとはアラートを飛ばす対象イベントを書いてあげればよいわけです。
dev.classmethod.jp
こちらの記事を参考に、mackerel-agent.conf にこんな設定を組み込みます。
# DiskError detection 2019/10/15 Yousuke # https://dev.classmethod.jp/etc/mackerel-windows-eventlog/ [plugin.checks.DiskError-Physical] command = ["check-windows-eventlog", "--log", "System", "--type", "Error", "--source-pattern", "Disk", "--event-id-pattern", "11"] prevent_alert_auto_close = true [plugin.checks.DiskError-NTFS] command = ["check-windows-eventlog", "--log", "System", "--type", "Error", "--source-pattern", "NTFS", "--event-id-pattern", "55"] prevent_alert_auto_close = true
DiskError-Physical はディスクの物理破損の検知が目的です。
DiskError-NTFS はNTFSの論理障害(ファイルシステムエラー)の検知が目的です。
テストイベントも書き込んでみます。
Write-EventLog -LogName System -Source "Disk" -EntryType Error -EventID 11 -message "TestEvent"
Mackerelにもちゃんと飛んできました。メールも送られています。
これらイベントが発生したからといって直ちにディスク交換やchkdskが必要というわけではないので、例えば「24時間以内に5回発生したら通知する」などの設定する必要があるでしょう。
ただ、MackerelのFreeプランで使えるホストメトリック監視では、こういった追加メトリックを対象にすることはできないようです。まぁ自宅サーバですし、当面はメールが何通も来てたら対応する、くらいの体制でいいでしょう。
Mackerelで記憶域プールの監視はできない
上記の設定は主に起動ドライブに対する監視ですが、記憶域プール側のHDD監視もやっておきたいところです。
記憶域プールのイベントログは Microsoft-Windows-StorageSpaces-Driver/Operational のようです。
これを参考に、とりあえずこんな記述を mackerel-agent.conf に追記します。
# DiskError detection 2019/10/20 Yousuke # https://satsumahomeserver.com/blog/7885 [plugin.checks.StorageSpaces-Driver] command = ["check-windows-eventlog", "--log", "Microsoft-Windows-StorageSpaces-Driver/Operational", "--type", "Error"]
ただ、MackerelのWindowsイベントログ監視プラグインではアプリケーションログ・セキュリティログ・システムログの3つのみが対象となっており、それ以外のイベントログは対応していないようです。
実際にこの設定を組み込んでmackerelサービスの再起動後、テストイベントを書き込んでみたのですが、Mackerelには通知は届きませんでした。
おそらくStandardプランにすれば式による監視が使えると思いますが、自宅サーバですし今回は諦めましょう。
以上、自宅サーバで起きたトラブルでいろいろ知見が得られたので書きました。
