電源障害後のCentOS 6サーバーVMホストの確認方法


9

今日の午後、私たちのオフィスの誰かが、サーバーが外に押し寄せていたので、サーバーからプラグを抜くことを決めました。彼らはそれをシャットダウンしませんでした、彼らはそれが走っている間にプラグを抜いただけです。

サーバーには、ソフトウェアRAID 10構成の4つのSATAドライブがあり、LVMはRAIDの上で実行されます。サーバーはCentOS 6.2 Minimalを実行しており、KVMを使用する仮想マシンホストです。プラグが抜かれたとき、コンピュータ上で実行されている多くのゲストマシンがありました。各ゲストには、ハードドライブとして直接使用する1つ以上のLVMパーティションがあります。ゲストパーティションは、EXT3、EXT4、およびNTFSです。ホストOSはEXT4パーティションにあります。

その後、電源が回復すると、その人が電源に接続して起動しました。彼らは最初にモニターを接続せずにそれを接続したので、画面に何が出てきたかを確認する方法はありません。ここでモニターを接続してみましたが、起動時にモニターが接続されていないと機能しません。(さらに)何も台無しにしたくないので、アドバイスが得られるまで、そのままにしておきます。

SSH経由でホストにアクセスできます。ログのどこかに役立つと思われる場合に備えて、まだ再起動していません。

可能であれば、すべてのディスクとパーティションのデータの整合性をチェックする必要があります。RAID 10はある種のメモリベースのキャッシュを使用していると思いますが、ドライブに一貫性がないか、またはまだ書き込まれていないドライブに書き込むための手がかりがあった場合にファイルが破損するのではないかと心配しています。

[root@othello ~]# cat /proc/mdstat
Personalities : [raid10] [raid1] 
md2 : active raid1 sdc1[2] sda1[0] sdd1[3] sdb1[1]
      102388 blocks super 1.0 [4/4] [UUUU]

md0 : active raid10 sda3[0] sdc3[2] sdd3[3] sdb3[1]
      1952289792 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

md1 : active raid10 sdc2[2] sda2[0] sdd2[3] sdb2[1]
      1022976 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]

unused devices: <none>

それはまた、それが私の配列を "near-copies"と呼んでいることに私を悩ませます。それは正常ですか?

ドライブとデータに問題がないことを確認するには、どのようなディスクチェックを実行する必要がありますか?他に確認すべきことはありますか?

更新

mdadm --detailの出力

[root@othello ~]# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.1
  Creation Time : Sat Feb 25 09:26:20 2012
     Raid Level : raid10
     Array Size : 1952289792 (1861.85 GiB 1999.14 GB)
  Used Dev Size : 976144896 (930.92 GiB 999.57 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Sun Mar 11 12:59:30 2012
          State : active 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : near=2
     Chunk Size : 512K

           Name : othello.myserver.com:0  (local to host othello.myserver.com)
           UUID : 58ba40ab:12516733:e3779362:68200fdd
         Events : 2208

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3
       2       8       35        2      active sync   /dev/sdc3
       3       8       51        3      active sync   /dev/sdd3

回答:


3

RAIDは問題ありません。すべてのUUUUは、アレイ内のすべてのディスクが稼働していることを意味します。今のところ、そのことさえ心配していません。

VMについては、それらでfscksを実行する場合は、VMを停止して実行します。

fsck.ext3 (ext4, etc) /path/to/lvm (通常/ dev / vg-name / lv-nameのように)

KVMを使用virshしている場合は、を使用してVMに対して必要なことをすべて実行できるはずです。ここにvirsh manページへのリンクがありますhttp://linux.die.net/man/1/virsh

RAIDアレイでディスクチェックを実行したい場合は、個々の/ dev / mdXデバイスをfsckできるように、シングルユーザーモードで再起動するか、ライブCDから起動する必要があります。プライマリファイルシステムはEXT4なので、気になりません。停電の場合はEXT3よりもはるかに優れています。


+1、明日試してみます。
Nick

1

mdadm --detail / dev / md0を試してください(md1とmd2でも同じです)。

次に、以下のアドバイスを試してください:http : //linas.org/linux/raid.html


mdadm --detail /dev/md0上記の出力を投稿しました。リンクしたガイドを読みましたが、EXT4ファイルシステム、または特に整合性をチェックするために何ができるかについては触れられていませんか?
Nick

ファイルシステムのタイプは、RAIDの整合性の点では重要ではありません。メンテナンス期間がある場合は、影響を受けるファイルシステムとfsckそれらをアンマウントできます。RAIDデバイス自体をチェックしたい場合は、のようなことができますecho "check" > /sys/block/md0/md/sync_action。または、「修復」をエコーし​​て、何らかのmdadm修復を実行します。
cjc 2012年

明日これを試して報告します。
Nick
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.