古い記事になりますので、ここでは
レガシーBIOSのMBRの話になります。
MBRでは2TBまでしか扱えないので、2TB以上の
HDDではUEFI BIOSを使用し、GPTによる
フォーマットを採用します。
Windowsマシンのおさがりで構築する場合など
古いレガシーBIOSだたら参考になると思い
削除しないでおきます。
片割れがお逝きになった
# cat /proc/mdstat
Personalities : [raid1]
md6 : active raid1 sdb8[1] sda8[0]
3144696 blocks super 1.1 [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk
md4 : active raid1 sdb6[1] sda6[0]
1048568 blocks super 1.1 [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk
md0 : active raid1 sdb1[2] sda1[0]
524276 blocks super 1.0 [2/2] [UU]
md2 : active raid1 sda3[0]
31456188 blocks super 1.1 [2/1] [U_]
bitmap: 1/1 pages [4KB], 65536KB chunk
md5 : active raid1 sda7[0]
2096120 blocks super 1.1 [2/1] [U_]
bitmap: 1/1 pages [4KB], 65536KB chunk
md3 : active raid1 sda5[0]
5241848 blocks super 1.1 [2/1] [U_]
bitmap: 1/1 pages [4KB], 65536KB chunk
md7 : active raid1 sdb9[1] sda9[0]
911358844 blocks super 1.1 [2/2] [UU]
bitmap: 2/7 pages [8KB], 65536KB chunk
md8 : active raid1 sdb10[1] sda10[0]
6142968 blocks super 1.1 [2/2] [UU]
md1 : active raid1 sdb2[1] sda2[0]
5241848 blocks super 1.1 [2/2] [UU]
bitmap: 1/1 pages [4KB], 65536KB chunk
md2・md3・md5のRAIDアレイ構成からsdbが仲間はずれ・・
一応
# mdadm -D /dev/md2
などとやってみましたが、結果はTotal Devicesや
ActiveDevicesが1個しか検出されません。
なにかの拍子でこうなるけど、自然復帰や
RAIDアレイに再構築してやると直ることもあるので、
まずは悪あがきを。
sdaは全て活きていて、sdb3(md2)・sdb5(md3)
・sdb7(md5)が死んでるので以下を実行してみる。。。
# mdadm --manage /dev/md2 -a /dev/sdb3
# mdadm --manage /dev/md3 -a /dev/sdb5
# mdadm --manage /dev/md5 -a /dev/sdb7
で、活き返ったのはmd5に参加するsdb7だけでした。
1回やってダメなら絶対深追いしてはなりませぬ。
かえって事態を悪化させてしまうことになりかねません。
1台交換決定ということで。
HDDは2年に1度、定期的に片方のみ交換しているので
毎年1度はこの作業を行いますが、実験で最初から
古い中古HDDを使ったとき以外は、HDDがコケての
交換は始めてですが、作業は慣れたものです。ｗ
該当サーバーはこのBLOGも発信しているもので、
つまり拙生の個人的使用なものであるため、
ホットスワップでやる必要はなく、ちょうどやる
予定だった清掃も含め、作業はシャットダウンして
行いました。
まずは以下の要領でsdbの関わるパーティションを
RAIDアレイから切り放してしまいます。
故障と認識させSYNCを禁じます。
# mdadm /dev/md0 --manage –-fail /dev/sdb1
RAIDアレイの構成から取り除きます。
# mdadm /dev/md0 –-manage –-remove /dev/sdb1
拙生の場合はsdb10(md8)まであるので、
この作業を延々と続けます。
これが終了したらシャットダウンさせます。
交換したHDDをsdbとして、再度sdaとRAID1を
構築するには、sdaと全く同じパーティションを
切らなくてはいけません。
fdiskのPで表示されるsdaのパーティションの
シリンダ数でsdbを切ってフォーマットするのは
結構手間のいる作業です。
しかもRedHat系は、インストール時にGUIでRAID
構築をすると、シリンダ数が1-50・50-100
のように切れ目が同じ50となるため、これを
fdiskで切ろうとすると1-50の次は51から
始めないとダメ！って怒られてしまいます。
そんな時拙生は以下のお気に入りsfdiskコマンドで、
sdaのパーティションをsdbに一気に丸ごとコピー
してしまいます。
# sfdisk -d /dev/sda | sfdisk /dev/sdb --force
ものぐさにはこの世に勝るコマンドなし！って
感じですね。ｗ
後は
# mdadm /dev/md0 --manage –a /dev/sdb1
# mdadm /dev/md1 --manage –a /dev/sdb2
# mdadm /dev/md2 --manage –a /dev/sdb3
のごとく、sdbのすべてのパーティションをRAID
アレーへの組み込みを全部終わるまで繰り返します。
注意としては、HDDのプライマリパーティションは
4つまでで、それ以上はプライマリの一つを
拡張パーティションとして切ることになります。
拙生の場合はsdb1~sdb3までがプライマリ、sdb4は
拡張パーティションの全体であり、さらにそれを
細かく切ったものがsdb5・sdb6・・のように続きます。
sdb4はRAIDアレーに参加するわけではないので、
md3以降に参加するのはsdb5以降になるので
間違ってはいけません。
注 （MBRの場合であって、GPTではプライマリ
パーティションは128個まで作成できます。）
めでたく復旧して【！万歳！】かと思いきや、
syncの状況確認で
# cat /proc/mdstat
を何度か実行していると、一度UUに戻ったアレイが
再度_Uに・・・💦💦
なんと今度はsdaのパーティションの1つがコケました。
前述した定期交換で1台しか交換しないのは、同時に
寿命を迎えないための回避策なのですが、今回は
交換して日が浅いほうがコケたので、冷却や印加
電圧などに不具合がないかチェックし、問題なさげ
なので、不運にもよろしくないやつに当たっちゃった
のでしょう。。。
ま、ギリギリセーフということで事なきを得ました。
両方一緒だったらと思うとぞっとしますね。
SYNCさせるのに両方とも高負荷になることも
こけた理由だったかもしれません。
GRUBとGRUB2
昔はRAID1の構成にCentOSなどをインストールしても、
GRUBだけは指定した片方にしかインストールされず、
もう一方をgrubコマンドでhd0に指定してインストール
しておかなければ、GRUBがインストールされている方が
逝かれたら起動しなくなってしまいましたが、
grub2だと勝手にインストールしてくれますねぇ。
プラットホームやRAID・LVMのサポート、パーティション
・テーブルやファイルシステムのサポートが格段に充実して、
もうGRUB2以外は使う気になれません。
慣れ親しんだGRUB (Grand Unified Bootloader)
Legacy の時代に幕が下りたということなのでしょう。
もう一つだけ
パーティションの話の際にしつこく付け加えるのですが、
交換するHDDは必ず容量が同じか大きくなくては駄目です。
少しでも容量足りないと、同じパーティションは
切れないので構成することは不可能です。
1TBや2TBと表示があっても、メーカーやロッドにより
若干容量が違うので要注意です。
回避策は、2TBなら1.8とか1.9しか使わないことで、
微妙な容量の違いを吸収できます。
どぉしてもぎりぎりまで使いたい場合は、後から
# mdadm --grow /dev/md7 –z max
のごとく拡大できるので、あまりケチらないように。ｗ
さらに2TB以上のHDDを使いこなすには、MBRなどを
よく勉強してからでないと痛い目にあいます。
Logical Block Addressingでアクセスできる
セクタ数40億に論理セクターの512Bを掛けると
2TBという限界が見えてくる・・・
などというお話は次回にということで。。。
ま、32bitの壁ってやつですね。
（2TB以上はGPTで、ということです。）
