システムをパニックさせる深刻なRAID問題
システム：デュアルXeon E5-2630 CPU、32GB RAM、プライマリディスクはSATA-III 512GB Crucial SSD OS：Xubuntu 14.04.1
この新しいシステムでRAIDに深刻な問題が発生しているため、一部のユーザーが何らかの洞察を提供できることを願っています。現在、ルートファイルシステムを持つプライマリSSDはミラーリングされていませんが、将来的には2番目の同一のSSDにミラーリングする予定です。セカンダリHDDセットでRAIDをセットアップしようとしていますが、この問題が解決するまでプライマリSSDセットをアップグレードするつもりはありません。
このシステムには、SATA-III Seagate ST4000DM0004TB Baracuda 4TBドライブのペアがあり、単一の大きなext4 GPTパーティションで同じようにフォーマットされています。これらのディスク上に有用なRAID 1ミラーを作成して、/ xにマウントしようとしています。ある時点で、安定しているように見える何かがあり、アレイを変更しようとするまで数週間実行しましたが、その時点で失敗しました。ミラーに障害が発生するたびに、システムにパニックが発生し、SSDのルートファイルシステムが/ etc/fstabの設定に従って読み取り専用で再マウントされます（errors = remount-ro）。もちろん、システムは今では役に立たず、ハードリセットが必要です。システムは再起動しますが、ミラーは完全に破損しているため、通常は破棄して再構築する必要があります。ハードウェア診断を実行しましたが、問題はありません。ログファイル（dmesg、kern.log、syslog）のどこに問題があるかについてのヒントはありません。詳細は次のとおりです。
次のように配列を作成します。
# mdadm --create /dev/md2 --verbose --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdc1 appears to contain an ext2fs file system
size=-387950592K mtime=Wed Dec 31 16:00:00 1969
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: /dev/sdd1 appears to contain an ext2fs file system
size=-387950592K mtime=Wed Dec 31 16:00:00 1969
mdadm: size set to 3906885440K
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
RAIDビルドの進行状況を確認します。
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdd1[1] sdc1[0]
3906885440 blocks super 1.2 [2/2] [UU]
[>....................] resync = 0.4% (17314560/3906885440) finish=415.6min speed=155968K/sec
unused devices: <none>
上記のコマンドを使用して再同期操作を定期的に監視し続け、問題なく動作します。ただし、ある時点で（再同期を4％から60％に同期させた）、システムがパニックし、ルートがROに再マウントされます。システムを再起動すると、通常次のことがわかります。
# l /dev/md*
/dev/md127 /dev/md127p1
/dev/md:
dymaxion:2@ dymaxion:2p1@
/ dev/md2をビルドして実行することができた場合、/ dev/md2および/ dev/md2p1デバイスがあり、/ dev/mdサブディレクトリには何もありませんでした。ここで、パニック状態のシステムは、配列をmd127として回収しようとしているようです。理由はわかりませんが、これは繰り返し発生しています。おそらく、mdadmソフトウェアにコード化されたアルゴリズムの結果である可能性があります。
Md127アレイは、ブート時にマウントできないほど低下し（/ etc/fstabにアレイのエントリがあります）、マウントして再同期を試みます。ただし、この操作中にシステムがパニックになることが多く、継続的な再起動が発生します。
次に、アレイを破棄し、再作成を試みます。これらは、それを破壊するために使用するコマンドです。
# mdadm --stop /dev/md127
mdadm: stopped /dev/md127
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
未使用のデバイス：
# mdadm -QD /dev/md127
mdadm: cannot open /dev/md127: No such file or directory
# mdadm --zero-superblock /dev/sdc1
# mdadm --zero-superblock /dev/sdd1
いくつかのターミナルウィンドウ以外のデスクトッププロセスが実行されていない静かなシステムでアレイを構築しようとしました。私は、checkbox-guiハードウェアテストスイートを実行しましたが、すべて正常にチェックアウトできます。他のすべてのSATAディスク、USBポート、カードリーダー、光学ディスクなどを取り外してから、ビルドを実行しても失敗します。
誰かがアレイが失敗する理由を見つけたり、何が起こっているのかをより良く判断する方法を提案したりできますか？
ここに私の努力に関する追加情報があります。
Sun Server（Solaris 10）で過去10年間行ってきたことは、3番目のディスクをアレイに接続し、同期させ、アレイから切り離し、災害復旧のためにサイトから外すことです。これは非常にうまく機能しており、これがこのUbuntuシステムで行う予定でした。
上記の手順を使用して、2つの内部ディスクで/ dev/md2を適切に構築することに成功しました。システムは数週間問題なく動作したので、ホットスワップベイを使用して3番目のディスクを接続する準備ができました。ホットスワップベイの3番目のディスクで再起動しました。任意のデバイスの再割り当てのため、新しいディスクは/ dev/sdaとして表示され、ミラーは/ dev/sddおよび/ dev/sdeを使用していました。
# mdadm -QD /dev/md2p1 (or: # mdadm -QD /dev/md2)
/dev/md2:
Version : 1.2
Creation Time : Tue Sep 9 17:50:52 2014
Raid Level : raid1
Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Fri Sep 19 14:02:45 2014
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : dymaxion:2 (local to Host dymaxion)
UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
Events : 129
Number Major Minor RaidDevice State
3 8 65 0 active sync /dev/sde1
2 8 49 1 active sync /dev/sdd1
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdd1[2] sde1[3]
3906885440 blocks super 1.2 [2/2] [UU]
unused devices: <none>
すべてがよさそうだ。/dev/md2p1にスペアとして/ dev/sda1を追加しましょう。
# mdadm /dev/md2 --add /dev/sda1
# mdadm -QD /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Tue Sep 9 17:50:52 2014
Raid Level : raid1
Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Fri Oct 17 13:36:13 2014
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1
Name : dymaxion:2 (local to Host dymaxion)
UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
Events : 130
Number Major Minor RaidDevice State
3 8 65 0 active sync /dev/sde1
2 8 49 1 active sync /dev/sdd1
4 8 1 - spare /dev/sda1
OK、growオプションを使用してスペアをアレイに接続しましょう。
# mdadm /dev/md2 --grow -n3
# mdadm -QD /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Tue Sep 9 17:50:52 2014
Raid Level : raid1
Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Fri Oct 17 14:43:08 2014
State : clean, degraded, recovering
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1
Rebuild Status : 0% complete
Name : dymaxion:2 (local to Host dymaxion)
UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
Events : 134
Number Major Minor RaidDevice State
3 8 65 0 active sync /dev/sde1
2 8 49 1 active sync /dev/sdd1
4 8 1 2 spare rebuilding /dev/sda1
いいね！ 3番目のディスクの同期を許可します。
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sda1[4] sdd1[2] sde1[3]
3906885440 blocks super 1.2 [3/2] [UU_]
[>....................] recovery = 0.7% (27891328/3906885440) finish=376.2min speed=171823K/sec
unused devices: <none>
ミラーが10％以上同期した後、システムがパニックになりました。今回は、システムを再起動したときに、ブートプロセスがミラーを/ xに再接続できず、マウントを再試行またはスキップするように求められました。私はそれをスキップし、システムが起動したとき、/ dev/md2を再アクティブ化する方法がありませんでした。最終的に、私はそれを破壊してやり直さなければなりませんでした。私はこれを二度と近づけなかった。これが機能した場合、3番目のディスクを故障としてマークし、それを取り外し、アレイを2つのデバイス（または2つのデバイスと欠落したスペア）に戻す計画でした。
このビルド手順に何か問題がありますか？
長い投稿をおaびします。質問をする前にできるだけ多くの情報を提供しようと考えました。
どんな提案も大歓迎です。私は、システムがパニックを引き起こす原因について特に懸念しています。
以下のすべてが2014年11月15日土曜日に追加されました
まず、明らかな誤解を明確にします。 @psusiの書き込み：
RAIDアレイにファイルシステムを作成し、アレイの作成後にマウントすることについて言及しなかったため、/ adm/sdc1にはすでにext2ファイルシステムが含まれているとmdadmから警告されたので、すでにファイルシステムが/ dev/sdc1。これが読み取り専用で再マウントされます。
いいえ。他の2つの4TBディスク（sdcとsdd）を使用してmd2ミラーを構築しようとしている間、ルートファイルシステムは独自のソリッドステートSATA-IIIドライブ（sda1）上にあります。このミラーが同期している間、何かがうまくいかず、システム全体がパニックに陥り、読み取り専用で再マウントされるのはミラーではなくルートファイルシステムであり、OS全体が動作不能になり、ハードリセットが必要になります。再起動すると、ミラーは再構築されるように見えますが、通常は/ dev/md127という名前になります。
はい、以前にGPTパーティションテーブルでパーティション分割され、1つの大きなext4ファイルシステムでフォーマットされた2つのディスクを使用してミラーを作成しようとしました。私が読んだすべてのものから、これは許容できるはずです。
[注：mdadmが「/ dev/sdd1にext2fsファイルシステムが含まれているように見える」と表示される場合、ext4fsを誤認しています。おそらく、正しく更新されていないハードコードエラーメッセージが原因です。パーティションの種類に関しては、GPartedではfd型として直接フォーマットすることはできませんが、配列にアセンブルするときにmdadmでタグ付けされると考えています。]
以下のコメントに基づいて、これは私が試したことです：
1：4TBのすべてのドライブ（ミラー用に2つ、将来のスペアとして2つ）で拡張S.M.A.R.T.表面テストを実行しました。各テストは8.5時間以上かかり、すべてのディスクがエラーなしで報告されました。個別にシステムパニックを引き起こしたことはありません。
2：GPartedを使用して、sdcおよびsddディスクからext4パーティションを削除しました。
3：元のGPTパーティションテーブルが削除されたことを確認するために、次を実行しました。
# sgdisk -Z /dev/sdc
# sgdisk -Z /dev/sdd
4：2つの未フォーマットディスクを使用してアレイを再作成しました。
# mdadm --create /dev/md2 --verbose --level=1 --metadata 1.2 --raid-devices=2 /dev/sdc /dev/sdd
mdadm: size set to 3906887360K
mdadm: array /dev/md2 started
5：「cat/proc/mdstat」を使用して同期の監視を開始し、順調に進んでいるのを確認しました。
数分後、システムは通常どおりパニック状態になり、ルートファイルシステム（sda1）が再マウントされましたRO。ハードリセットが必要でした。 「resync = PENDING」状態にあり、自動的に同期を試行しません。同期が完了したら、ミラー上にGPTパーティションテーブルとext4パーティションを作成することを意図していました（おそらく先に進んで完了できたことを知っています）これは同期中ですが、問題がどこにあるかを確認するためにこのプロセスのステップを分離しようとしています。）
Syslogおよびkern.logファイルで重複していることがわかった新しい情報を次に示します。これらのメッセージは、remount-ro操作の直前に記録されました。
Nov 15 14:31:15 dymaxion kernel: [58171.002154] ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Nov 15 14:31:15 dymaxion kernel: [58171.002163] ata8.00: failed command: IDENTIFY DEVICE
Nov 15 14:31:15 dymaxion kernel: [58171.002167] ata8.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 16 pio 512 in
Nov 15 14:31:15 dymaxion kernel: [58171.002167] res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov 15 14:31:15 dymaxion kernel: [58171.002169] ata8.00: status: { DRDY }
Nov 15 14:31:15 dymaxion kernel: [58171.002175] ata8: hard resetting link
Nov 15 14:31:15 dymaxion kernel: [58171.329795] ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Nov 15 14:31:15 dymaxion kernel: [58171.330336] ata8.00: supports DRM functions and may not be fully accessible
Nov 15 14:31:15 dymaxion kernel: [58171.334346] ata8.00: disabling queued TRIM support
Nov 15 14:31:15 dymaxion kernel: [58171.339116] ata8.00: supports DRM functions and may not be fully accessible
Nov 15 14:31:15 dymaxion kernel: [58171.343149] ata8.00: disabling queued TRIM support
Nov 15 14:31:15 dymaxion kernel: [58171.347557] ata8.00: configured for UDMA/133
Nov 15 14:31:15 dymaxion kernel: [58171.347625] ata8: EH complete
これはある種のSATAエラーを示しているようですが、現時点では解釈できません。
それで、これは何が間違っているのかについての追加の手がかりを提供しますか？これまで本当に助かりました。いくつかの新しい方向に考えさせられました。誰かがさらなる洞察や提案を提供できることを願っています。ありがとう。
以下のすべてが2014年12月20日土曜日に追加されました
この物語の最後のエントリとして、私は次の情報を提供し、将来他の人を助けることを期待しています。
私はこの問題に関して米国のASUSサポートに連絡することができました。交換用のZ9PE-D8 WSマザーボードを受け取り、インストールして構成しました。 RAIDテストを実行すると、元のマザーボードとまったく同じ結果が観察されました。ルートファイルシステムドライブをMarvelコントローラーに接続した場合：
追加のRAID 1ディスクがMarvelコントローラー上にある場合、アレイで重要なmdadm（8）操作を実行しようとすると、上記のカーネル例外とエラーが生成され、OS全体がパニックになります。
RAIDディスクがMarvelコントローラーから移動した場合、mdadm（8）操作は問題なく実行でき、システムは問題なく動作します。
ルートパーティションをミラーリングするつもりだったので、ルートファイルシステムをMarvelコントローラーから削除し、RAIDをそこに戻すとどうなるかを心配していました。残念ながら、ルートファイルシステムがオンボードIntel C602チップセットに移動された場合、OSを起動する方法を見つけることができませんでした。これは、両方のマザーボードに当てはまりました。
[注：なぜこれができなかったのかについての手がかりがあれば、その理由を聞いていただければ幸いです。たとえば、GRUB2はインストール時にコントローラー固有の特定の情報を保存しますか？]
したがって、私は弾丸を噛み、最新のUbuntu Serverバージョン14.10を完全に再インストールし、インストールプロセスの一部としてルートファイルシステムをミラーリングすることにしました。 SSDをIntelコントローラーによって制御されるSATA-IIIポートのペアに移動し、新規インストールを実行しました。すべてがうまくいきました。
今、ミラー化されたルートを持つ実行中のシステムで、2つの4TBドライブをMarvelコントローラーに接続し、新しいRAID 1アレイを構築しようとしました。アレイはすぐに失敗しました。したがって、MarvelコントローラーはソフトウェアRAID管理と互換性のない何かをしていると結論付けることができます。
4TBドライブをIntel C602で制御されるSATA-IIポートに移動しましたが、すべて正常に機能し、問題なく機能し続けます。元の6つのSATA-IIIポートのうち4つが使用できないマシンが残っている間に、ASUSエンジニアリングが問題を調査しています。
レッスンは、Marvel PCIe 9230コントローラーを使用するLinuxマシンを検討している人は、RAIDの互換性を気にする必要があるということです。
この情報がお役に立てば幸いです。 Marvelコントローラーで同様の問題を発見した人がいて、さらに主題を明らかにできる場合は、私に連絡してください。ありがとう。 〜
すべての間違った場所で愛を探して....
ご協力ありがとうございます。psusiとppetrakiに感謝します。あなたはそれぞれ、LinuxでRAIDがどのように機能するかについて追加の洞察を与えてくれました。
RAIDアレイの作成と操作に使用していたディスクまたはmdadmコマンドに問題はなかったことがわかりました。 ata8カーネルメッセージを発見したら、それらをキーとしてインターネットを検索し、Marvel SATAコントローラーに関連する同様のメッセージを報告する他のユーザーを見つけました。 ASUS Z9PE-D8 WSマザーボードには、これらのディスクに使用されていた4つのSATA-IIIポートを駆動するオンボードMarvel PCIe 9230コントローラーが搭載されています。これらのポートからドライブを取り外し、Intel C602チップセットによって駆動されていたボード上の他のSATAポートに接続し、再起動しました。この時点で、問題なく複数のアレイの構築、再構成などを行うことができました！
ルートファイルシステムを備えた単一のSSDは、まだMarvelコントローラーに接続されており、実行に問題はありません。ただし、このドライブをMarvelコントローラーから削除するまで、このドライブをミラーリングしようとする予定はありません。
この問題に関して、ASUSから情報を取得しようとしています。ハードウェアまたはBIOSの問題を示している可能性はありません。これまでのところ、ASUSのテクニカルサポートは私のリクエストへの対応が遅かった。彼らのサービスには感心していません。
Marvelコントローラーの問題に関連する追加情報があれば、ぜひ聞いていただければ幸いです。
だから、私は当分の間ビジネスに戻っている、4つのSATA-IIIポートは適切に動作するシステムを恥ずかしがる。助けてくれてありがとう。
私が見る最大の問題はこれです
mdadm: /dev/sdd1 appears to contain an ext2fs file system
また、これらのパーティションは、Linuxファイルシステムではなく、 RAIDメンバー（fdタイプ） とマークする必要があります。
これは、extfsツールがfsckのようにラッチできるスーパーブロックがあり、あなたの世界を台無しにすることを意味します。 ddを使用してドライブをアレイに追加する前に、ドライブを完全に消去することを強くお勧めします。
dd if=/dev/zero of=/dev/bye-bye-entire-sd-device
メンバーではなく、ファイルシステムでMDデバイスをフォーマットしていることを確認してください。
それがすべてうまくいき、まだランダムな破損が見られる場合、たまにガベージを書き戻してディスクを破壊しているわずかなメモリがある可能性があります。
詳細なリファレンス： https://raid.wiki.kernel.org/index.php/RAID_setup
RAIDアレイにファイルシステムを作成し、アレイの作成後にマウントすることについて言及しなかったため、mdadmは/ dev/sdc1に既にext2ファイルシステムが含まれていると警告しているので、すでに/ dev/sdc1にファイルシステムがあり、それが読み取り専用で再マウントされています。これは、ディスクまたはパーティションからRAIDアレイを作成することは一般に破壊的な操作であるため、mdadmが警告した理由です。 RAIDメタデータをパーティションに書き込むと、そこにある既存のファイルシステムが破損します。
この時点で、/ dev/sdc1内の既存のデータを復元する場合は、行った損傷を試して元に戻す必要があります。古いファイルシステムをアンマウントすることから始めて、作成したRAIDスーパーブロックを吹き飛ばし、古いファイルシステムをfsckして、修復できることを望みます。
umount /dev/sdc1
mdadm --zero-superblocks /dev/sdc1 /dev/sdd1
e2fsck -fy /dev/sdc1
既存のファイルシステムをraid1にアップグレードするには、最初にonly新しいディスクを使用してraid配列を作成し、次に古いFS新しいものへ：
mdadm --create --level 1 -n 2 /dev/sdd1 missing
mkfs.ext4 /dev/md0
mkdir /mnt/new
mkdir /mnt/old
mount /dev/md0 /mnt/new
mount /dev/sdc1 /mnt/old
cp -ax /mnt/old/* /mnt/new/
umount /mnt/old
umount /mnt/new
rmdir /mnt/old
rmdir /mnt/new
/ etc/fstabを編集して、/ dev/sdc1の古いボリュームではなく、/ dev/md0の新しいボリュームをマウントし、最後に/ dev/sdc1をmdに渡して/ dev/sdd1のすべてをミラーリングできます。
mdadm /dev/md0 --add /dev/sdc1
blkidを使用して、raid配列で新しいファイルシステムのUUIDを検索し、それを使用して/ etc/fstabの古いUUIDを置き換えることができます。また、これらのコマンドはすべてルートとして実行する必要があるため、Sudo -s最初にルートになる。
最後に、参考までに、raid1の代わりにraid10を使用することもできます。オフセットレイアウト（-p o2からmdadm）および大きなチャンクサイズサイズ（-c 1024から4096）で、raid1の冗長性とraid0の順次読み取りスループットを得ることができます。