ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

2016年5月18日水曜日

RAID6 のディスク交換

家のサーバーのディスクの1つにバッドセクタが出てきました。SMARTで調べたら、もう5.7年も稼働しているディスクのようで、そろそろ交換していいころですね。よく頑張ってくれました。そのディスクは2.0TBのやつなのですが、確かあの頃はすごくディスクが安くて確か6000円とかで買えたような気がします。手元にある3.0TBのやつが確か半年前ぐらいに買ったのですが8000円ぐらいしてたように思うので、5年ほど経った割にほとんど価格が変わってないなぁと思ったりもします。

さて早速交換しましょう。バッドセクタがあるとは言え、現状動いているのでまずアレイから抜く作業をします。Disk Utility 等でどのディスクが交換対象なのかは押さえておきます。私の場合 /dev/sdd でした。シリアルナンバー等も控えておきます。(同じサイズのものが複数あるので)

まずは取り外しのコマンドから
# mdadm --manage /dev/md126 --fail /dev/sdd1
すると
# mdadm --detail /dev/md126
(略)
    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       2       8       81        1      active sync   /dev/sdf1
       3       8       19        2      active sync   /dev/sdb3
       4       8       33        3      active sync   /dev/sdc1
       6       8       65        4      active sync   /dev/sde1
      10       0        0       10      removed

       5       8       49        -      faulty   /dev/sdd1
のように faulty としてマークされ、アレイから除去されます。そしたらシャットダウンして、物理的にディスクを交換します。

交換したら起動して、新しいディスクにパーティションを作成します。今回はOSが入っているディスクと同じサイズのディスクなので、OS部分のパーティションを切った関係で sdd1 だったものが sde3 になりました。その領域を追加します。
# mdadm --manage /dev/md126 --add /dev/sde3
mdadm: added /dev/sde3
大丈夫そうですね。もう一度上の detail で調べると
# mdadm --detail /dev/md126
(略)
    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       2       8       81        1      active sync   /dev/sdf1
       3       8       19        2      active sync   /dev/sdb3
       4       8       33        3      active sync   /dev/sdc1
       6       8       49        4      active sync   /dev/sdd1
       7       8       67        5      spare rebuilding   /dev/sde3
 
となり、リビルドが開始します。なんて簡単なんだ・・・。とはいえ、作業は簡単ですが2TB領域のリビルドなんで時間だけは盛大にかかります。とりあえずリビルドが終わるまではあまり負荷をかけないようにします。まあ現状でもRAID5の正常状態と同じなので安心感はありますが。

2014年2月2日日曜日

自己満足的自宅サーバーディスク構成変更(6)~仕上げ

さてようやく2.0TBのRAID5/2から4.0TBのRAID6/4となり、サイズも倍、冗長性も倍となりました。まあこの時点ではRAID10と同等と言えなくもないですが、RAID10は2本壊れるとダメな組み合わせもあるわけで、少しは改善したかな?

しかしアレイを大きくしただけではLVMのPVとしては大きくなっていません。
# pvdisplay /dev/md127
  --- Physical volume ---
  PV Name               /dev/md127
  VG Name               vg_data
  PV Size               1.82 TiB / not usable 3.50 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              476899
  Free PE               41829
  Allocated PE          435070
  PV UUID               N1cjJ3-N5Zy-7SqP-aVsz-47H4-9eF1-uucRbY
これを大きくするには
# pvresize /dev/md127
  Physical volume "/dev/md127" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
# pvdisplay /dev/md127
  --- Physical volume ---
  PV Name               /dev/md127
  VG Name               vg_data
  PV Size               3.64 TiB / not usable 2.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              953799
  Free PE               518729
  Allocated PE          435070
  PV UUID               N1cjJ3-N5Zy-7SqP-aVsz-47H4-9eF1-uucRbY
でOKです。これが終わったら最後に残っているRAID 1のアレイにあるextentをここに移動します。(また数時間仕事w)それが終わったらそのアレイをLVMから外し、パーティションを切りなおし、またRAID 6のアレイに追加します。
# mdadm --add /dev/md127 /dev/sdd1 /dev/sde1 
mdadm: added /dev/sdd1
mdadm: added /dev/sde1
# mdadm --detail /dev/md127
/dev/md127:
    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       2       8       81        1      active sync   /dev/sdf1
       3       8       19        2      active sync   /dev/sdb3
       4       8       33        3      active sync   /dev/sdc1

       5       8       49        -      spare   /dev/sdd1
       6       8       65        -      spare   /dev/sde1

スペア2台になりました。サイズを増やします。やっぱひとつずつだよね・・・。
# mdadm --grow /dev/md127 --raid-devices=6
mdadm: Need to backup 2048K of critical section..
おっ!?いきなり2個分増やせたのかな?
# cat /proc/mdstat 
md127 : active raid6 sde1[6] sdd1[5] sdb3[3] sda3[0] sdc1[4] sdf1[2]
      3906763776 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      [>....................]  reshape =  0.0% (607232/1953381888) finish=1849.1min speed=17600K/sec
できてるっぽい!しかもたった(!)1849分=30時間じゃないか!(←既に麻痺してるw)実際は26時間ほどで完成しました。
# mdadm --detail /dev/md127 
/dev/md127:
        Version : 1.2
  Creation Time : Fri Jan 24 09:11:13 2014
     Raid Level : raid6
     Array Size : 7813527552 (7451.56 GiB 8001.05 GB)
  Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Sat Feb  1 09:49:27 2014
          State : clean 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       2       8       81        1      active sync   /dev/sdf1
       3       8       19        2      active sync   /dev/sdb3
       4       8       33        3      active sync   /dev/sdc1
       6       8       65        4      active sync   /dev/sde1
       5       8       49        5      active sync   /dev/sdd1

おお・・・。8.0TBのディスク(しかも2本の冗長性)なんてもはや家庭用とは思えないw これで子どもの写真や動画とかがなくなるリスクが軽減されたのだと納得させます。
もちろん
# pvresize /dev/md127 
をしてLVM上でも使えるようにすることをお忘れなく。

これにて完成!まとめると
  1. 2.0TB (/boot, swap, /, pv(1))
  2. 2.0TB (/boot, swap, /, pv(1))
  3. 2.5TB (pv(2))
  4. 2.5TB (pv(2))
  5. 3.0TB (pv(3), data)
  6. 2.0TB (pv(3))
でデータ領域はpv(1) (1.5TB RAID 1) + pv(2) (2.5TB RAID 1) + pv(3) (2.0TB RAID 1)= 6.0TB の構成だったわけですが、
  1. 3.0TB (/boot, /, pv)
  2. 2.5TB (/boot, /, pv)
  3. 2.5TB (pv)
  4. 2.0TB (pv)
  5. 2.0TB (pv)
  6. 2.0TB (pv)
で pv (2.0TBx6 RAID 6) = 8.0TB の構成となりました。この後、1から3のディスクには空きが少しあるので、swap 領域の確保とテンポラリ領域を作成して終わりです。

本当は停電対策(正確にはUPS故障対策)のために別アレイにコピーしたいんですけどね。いろいろ考えていたら、RAID 6ってデータ書き込むとき全ディスクにほぼ同時にアクセスするわけじゃないですか。その瞬間にUPSが壊れて電源ロスが起きたら同時に3台以上のディスクがダメになるということも考えられなくもないかなと。まあそれはかなりのレアケースだと思うので、現状はこの状態で運用しようと思います。

2014年1月30日木曜日

自己満足的自宅サーバーディスク構成変更(5)~他のアレイを移行

会社から帰ってきたらRAID 5(2台)の構築は終わっていました。
# mdadm --detail /dev/md5 
/dev/md5:
        Version : 1.2
     Raid Level : raid5
     Array Size : 1953381888 (1862.89 GiB 2000.26 GB)
  Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Number   Major   Minor   RaidDevice State
       0       8       67        0      active sync   /dev/sde3
       2       8       81        1      active sync   /dev/sdf1
ふむふむ。いい感じです。この状態だと前のRAID 1と(サイズ的にも、冗長性的にも)同等の状態なのでこれを再びLVMに戻して他のディスクをあけます。
# pvcreate /dev/md5
  Physical volume "/dev/md5" successfully created
この時点では、まだVGに属してないボリュームとして見えます。
早速追加します。
# vgextend vg_data /dev/md5
  Volume group "vg_data" successfully extended
pvdisplay等でも正しく追加されたことが確認できますが、GUIでも
のように確認できます。あとはここに次に移行したいアレイから extent を移動します。今度は /dev/md4 をあけました(ってさらって書いてますがこれも5、6時間は放置してたかなw)。同じようにすべて"Unused Space"になっているのを確認して"Remove Volume from Volume Group"してからアレイを停止します。

その外したディスクについて新しくパーティションを切ります。切ったパーティションを今度は前回作ったRAID 5のアレイに追加します。

# mdadm --add /dev/md5 /dev/sdc3 /dev/sdd1 
mdadm: added /dev/sdc3
mdadm: added /dev/sdd1
# cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] 
md5 : active raid5 sdd1[4](S) sdc3[3](S) sdf1[2] sde3[0]
      1953381888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [2/2] [UU]

# mdadm --detail /dev/md5
/dev/md5:
        Version : 1.2
  Creation Time : Fri Jan 24 09:11:13 2014
     Raid Level : raid5
     Array Size : 1953381888 (1862.89 GiB 2000.26 GB)
  Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB)
   Raid Devices : 2
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sat Jan 25 16:20:44 2014
          State : clean 
 Active Devices : 2
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 2

         Layout : left-symmetric
     Chunk Size : 512K

    Number   Major   Minor   RaidDevice State
       0       8       67        0      active sync   /dev/sde3
       2       8       81        1      active sync   /dev/sdf1

       3       8       35        -      spare   /dev/sdc3
       4       8       49        -      spare   /dev/sdd1

この状態ではRAID 5(2台+スペア2台)になります。これをRAID 5(3台+スペア1台)に変更します。(再起動した関係でデバイス名が変わっています。)
# mdadm --grow /dev/md127 --raid-devices=3
mdadm: Need to backup 1024K of critical section..
# mdadm --detail /dev/md127
/dev/md127:
        Version : 1.2
  Creation Time : Fri Jan 24 09:11:13 2014
     Raid Level : raid5
     Array Size : 1953381888 (1862.89 GiB 2000.26 GB)
  Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB)
   Raid Devices : 3
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sat Jan 25 17:57:44 2014
          State : clean, reshaping 
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 512K

 Reshape Status : 0% complete
  Delta Devices : 1, (2->3)

    Number   Major   Minor   RaidDevice State
       0       8       67        0      active sync   /dev/sde3
       2       8       81        1      active sync   /dev/sdf1
       3       8       35        2      active sync   /dev/sdc3

       4       8       49        -      spare   /dev/sdd1
無事3台構成のRAID 5としてreshapeのプロセスに入ったようですね。いつもの /proc/mdstat も見てみましょう。
# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md125 : active raid1 sdb1[1] sde1[2] sdc1[3]
      524276 blocks super 1.0 [3/3] [UUU]
      
md126 : active raid1 sdb4[1] sda4[0]
      1676161496 blocks super 1.2 [2/2] [UU]
      
md127 : active raid5 sde3[0] sdc3[3] sdf1[2] sdd1[4](S)
      1953381888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      [>....................]  reshape =  0.1% (2117632/1953381888) finish=1676.8min speed=19393K/sec
えええっ! 1676分!27時間じゃないですか!w ディスク2本のときは6時間だったので1本増えた分で9時間ぐらいかなと思ってたんですが甘かったですね・・・。これ6本になったら3週間ぐらいかかっちゃう!?

今さらだけど、RAID5/2 -> RAID6/4 にするのはエラーになったので、RAID5/2 -> RAID5/3 -> RAID 6/4 という道で行くことにしたんだけど、もしかしてRAID5/2 -> RAID5/4 なら一度で行けたのかな?もしできるなら RAID5/2 -> RAID5/4 -> RAID6/6 としたほうが reshape の数が少なくてよかったのかな・・・。それともやっぱりRAID5/2 -> RAID5/4 もエラー?

まあはじめてしまったのは仕方ないので、27時間待ちますw 問題は定期的に行われる resync? もこのぐらいかかるのだと一日では到底終わらないので困るんですがどうなんだろう。あとやっぱりこんなにかかるとなると、degradeしたときのRAID 5ってやっぱりこわいですね。冗長性を復活させるのに丸一日かかってたら、その間にもう一本やられちゃうこともありそうです。なのでRAID 6の安心にコストを払うのが正解という判断で。

そう思って一晩置いたところ、開始後15時間ほどでまだ50%ぐらいだったんですが、なぜか残り時間が220分とかになってますね。
# cat /proc/mdstat     
md127 : active raid5 sde3[0] sdc3[3] sdf1[2] sdd1[4](S)
      1953381888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      [==========>..........]  reshape = 53.5% (1045575200/1953381888) finish=220.5min speed=68608K/sec
その後もちょくちょくチェックしてたらスピードが最初のころの5倍とかのままでどんどん進んでいます。何か2フェーズにわかれてるのかな?

最終的に23時間ほどで完了しました。
# mdadm --detail /dev/md127
/dev/md127:
        Version : 1.2
  Creation Time : Fri Jan 24 09:11:13 2014
     Raid Level : raid5
     Array Size : 3906763776 (3725.78 GiB 4000.53 GB)
  Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB)
   Raid Devices : 3
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sun Jan 26 16:38:19 2014
          State : clean 
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

    Number   Major   Minor   RaidDevice State
       0       8       67        0      active sync   /dev/sde3
       2       8       81        1      active sync   /dev/sdf1
       3       8       35        2      active sync   /dev/sdc3

       4       8       49        -      spare   /dev/sdd1
ちゃんとサイズが4TBになっているのがわかりますね。すばらしい。さあいよいよRAID 6です。
# mdadm --grow /dev/md127 --level=6 --raid-devices=4 --backup-file=/root/raid.back
mdadm: level of /dev/md127 changed to raid6
# cat /proc/mdstat 
md127 : active raid6 sde3[0] sdc3[3] sdf1[2] sdd1[4]
      3906763776 blocks super 1.2 level 6, 512k chunk, algorithm 18 [4/3] [UUU_]
      [>....................]  reshape =  0.0% (96256/1953381888) finish=3719.6min speed=8750K/sec
      
わははw 3719分ということは61時間、約3日かかる計算ですw 実際はまた途中から早くなるかもしれないですけど。これは気長に待つしかないですね。

そして1日経過、まだまだw

2日経過、60%は越えましたが途中から早くなるかもという希望は打ち砕かれましたw

開始から2日半でようやく80%台を越え、残り976分と1000分を切りました!w

そして開始から3日と6時間ぐらいたったころ、ようやく完了しました。長かった・・・けどまだ2本追加するんですがw

終わる直前↓w
# cat /proc/mdstat 
md127 : active raid6 sde3[0] sdc3[3] sdf1[2] sdd1[4]
      3906763776 blocks super 1.2 level 6, 512k chunk, algorithm 18 [4/3] [UUU_]
      [===================>.]  reshape = 99.9% (1952316928/1953381888) finish=3.3min speed=5360K/sec

2014年1月28日火曜日

自己満足的自宅サーバーディスク構成変更(4)~RAID 6の元になるアレイの作成

さていよいよ最終的にはでかいRAID 6のアレイに育てるアレイを作ります。まず外したアレイのメンバだった2.0TBのディスクを全体で1つパーティションを切ります。(全体なので切らなくてもいいような気もしますが、これより大きいディスクでサイズをあわせやすくするために一応切っておきます。)そして3.0TBのディスクはシステム部分が入っているとはいえ2.0TB以上あまっているので、ここに同じサイズのパーティションを作成しました。
(parted) unit b                                                           
(parted) print                                                            
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sde: 3000592982016B
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start          End             Size            File system  Name  Flags
 1      1048576B       537919487B      536870912B      ext4               raid
 2      537919488B     275415826431B   274877906944B                      raid
 3      275415826432B  2275813621759B  2000397795328B                     raid

(parted) select /dev/sdf
Using /dev/sdf
(parted) print                                                            
Model: ATA WDC WD20EARX-00P (scsi)
Disk /dev/sdf: 2000398934016B
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start     End             Size            File system  Name  Flags
 1      1048576B  2000398843903B  2000397795328B                     raid

このように1バイト単位まで同じです。さていよいよ「ディスク2本のRAID 5」は作れるのか!?

# mdadm --create /dev/md5 --level=5 --raid-devices=2 /dev/sde3 /dev/sdf1
mdadm: /dev/sdf1 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Tue Jan  1 10:32:54 2013
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md5 started.

# cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] 
md5 : active raid5 sdf1[2] sde3[0]
      1953381888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [2/1] [U_]
      [>....................]  recovery =  0.1% (3436876/1953381888) finish=389.9min speed=83342K/sec

むむっ、拍子抜けするぐらい普通に作れたんですけどw あ、小さい領域で実験してからにすべきだったか・・・。しかも2.0TB2本で389分ということは、6本全部構成し終わったらresyncに1200分、つまり20時間かかる計算!?w

というわけで、20時間待って失敗は悲しいので、小さい領域で実験してみることにしました。まずは4つパーティションを用意します。
(parted) unit gib
(parted) mkpart primary 1 2                                               
(parted) mkpart primary 2 3
(parted) mkpart primary 3 4
(parted) mkpart primary 4 5
(parted) set 1 raid on
(parted) print                                                            
モデル: ATA M4-CT128M4SSD2 (scsi)
ディスク /dev/sdd: 119GiB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos

番号  開始     終了     サイズ   タイプ   ファイルシステム  フラグ
 1    1.00GiB  2.00GiB  1.00GiB  primary                    raid
 2    2.00GiB  3.00GiB  1.00GiB  primary                    raid
 3    3.00GiB  4.00GiB  1.00GiB  primary                    raid
 4    4.00GiB  5.00GiB  1.00GiB  primary                    raid
違うマシンでやったのでロケールが日本語になってますがご容赦を。さてパーティションは切れたので早速RAID 5のアレイを作ってみます。実際と同様に2台です。
# mdadm --create /dev/md0 --level=5 --raid-devices=2 /dev/sdd1
/dev/sdd2
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md0 : active raid5 sdd2[2] sdd1[0]
      1047552 blocks super 1.2 level 5, 512k chunk, algorithm 2 [2/1] [U_]
      [====>................]  recovery = 24.1% (253736/1047552) finish=0.1min
speed=84578K/sec
      
# mkfs.ext4 /dev/md0
# mount /dev/md0 /mnt/tmp
ファイルシステムも作ってマウントしました。念のためということでそこにランダムなデータのファイルを作り、それを別のパーティションにもコピーしておきます。
# dd if=/dev/urandom of=random.dat count=1800000
$ cp /mnt/tmp/random.dat .
さあ準備はできたのでいよいよ1パーティション壊してみましょう。まずは fail にしてから remove です。
# mdadm --fail /dev/md0 /dev/sdd2
mdadm: set /dev/sdd2 faulty in /dev/md0
# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md0 : active raid5 sdd2[2](F) sdd1[0]
      1047552 blocks super 1.2 level 5, 512k chunk, algorithm 2 [2/1] [U_]

# mdadm --remove /dev/md0 /dev/sdd2
mdadm: hot removed /dev/sdd2 from /dev/md0
# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md0 : active raid5 sdd1[0]
      1047552 blocks super 1.2 level 5, 512k chunk, algorithm 2 [2/1] [U_]
無事抜けました。この状態でも degraded ですが動いている(はず)。さっきコピーしておいたファイルとマウントしているところにあるファイルを比べてみると
$ diff random.dat /mnt/tmp/random.dat 
$
おお、問題なさそうですね!念のためその外したディスクは別のデータで上書きしてみます。
# mkfs.ext4 /dev/sdd2
# mount /dev/sdd2 /mnt/tmp2
# ls /mnt/tmp2/
lost+found

$ diff random.dat /mnt/tmp/random.dat 
$
やはり問題はないです。すばらしい。 さていよいよ本題のRAID 6への変換です。 先ほど外したパーティションを戻してから、さらに2つのパーティションを追加します。
# umount /mnt/tmp2
# mdadm --add /dev/md0 /dev/sdd2
mdadm: added /dev/sdd2
# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md0 : active raid5 sdd2[2] sdd1[0]
      1047552 blocks super 1.2 level 5, 512k chunk, algorithm 2 [2/1] [U_]
      [=============>.......]  recovery = 68.6% (720256/1047552) finish=0.0min
speed=102893K/sec

# mdadm --add /dev/md0 /dev/sdd[34]
mdadm: added /dev/sdd3
mdadm: added /dev/sdd4
# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md0 : active raid5 sdd4[4](S) sdd3[3](S) sdd2[2] sdd1[0]
      1047552 blocks super 1.2 level 5, 512k chunk, algorithm 2 [2/2] [UU]

# mdadm --detail /dev/md0
/dev/md0:
    Number   Major   Minor   RaidDevice State
       0       8       49        0      active sync   /dev/sdd1
       2       8       50        1      active sync   /dev/sdd2

       3       8       51        -      spare   /dev/sdd3
       4       8       52        -      spare   /dev/sdd4
はい。2台追加されてスペアとなっています。これを4台のRAID 6に・・・と思ったらエラーになりました。1台ずつしかできないのかな?とにかく1台ずつ行きます。3台ではまだRAID 6にできないので、まずは3台のRAID 5にします。
# mdadm --grow /dev/md0 --raid-devices=3
mdadm: Need to backup 1024K of critical section..
# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md0 : active raid5 sdd4[4] sdd3[3](S) sdd2[2] sdd1[0]
      1047552 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      [=====>...............]  reshape = 26.1% (273920/1047552) finish=0.4min
speed=30321K/sec

なんか Need to backup... って言われたのでコマンドはrejectされたのかと思いきや普通にRAID 5への変換が行われました。いいねいいね。終わったらいよいよRAID 6への変換です。
# mdadm --grow /dev/md0 --level=6 --raid-devices=4
mdadm: level of /dev/md0 changed to raid6
mdadm: /dev/md0: Cannot grow - need backup-file
mdadm: aborting level change

おお、今度はちゃんとrejectされました。バックアップファイルを指定して再実行です。
# mdadm --grow /dev/md0 --level=6 --raid-devices=4
--backup-file=/home/raid.back
mdadm: level of /dev/md0 changed to raid6
# cat /proc/mdstat 
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] 
md0 : active raid6 sdd4[4] sdd3[3] sdd2[2] sdd1[0]
      2095104 blocks super 1.2 level 6, 512k chunk, algorithm 18 [4/3] [UUU_]
      [>....................]  reshape =  1.5% (16384/1047552) finish=2.0min
speed=8192K/sec

すばらしい。うまくいきました。

でもこれってつまり2台追加するときは2回 reshape するってことよね。2.0TBが2台で6時間として、3台は9時間、4台は12時間、5台は15時間、6台が18時間、それぞれ全部やらないといけないということは合計39時間w

2014年1月26日日曜日

自己満足的自宅サーバーディスク構成変更(3)~システムパーティションの移動

前回LVMから外した3.0TBのディスクに/bootと/を持ってきます。切りなおしてファイルコピーでもいいんですが、せっかくなのでRAID 1の機能を使って行きましょう。

まず現状を確認です。
# parted
GNU Parted 2.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit b                                                           
(parted) print                                                            
Model: ATA WDC WD20EARS-00M (scsi)
Disk /dev/sda: 2000398934016B
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start          End             Size            Type     File system  Flags
 1      1048576B       537919487B      536870912B      primary  ext4         boot, raid
 2      537919488B     9127854079B     8589934592B     primary               raid
 3      9127854080B    284005761023B   274877906944B   primary               raid
 4      284005761024B  2000396321279B  1716390560256B  primary               raid

(parted) select /dev/sde
Using /dev/sde
(parted) print                                                            
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sde: 3000592982016B
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start           End             Size            File system  Name  Flags
 1      1048576B        2000398843903B  2000397795328B                     raid
 2      2000398843904B  3000592498687B  1000193654784B

(parted)
ここでsdaの1と3が/bootと/なのでこれと同じサイズのパーティションを作成します。
(parted) rm 1                                                             
(parted) rm 2                                                             
(parted) unit mib                                                         
(parted) mkpart                                                           
Partition name?  []?                                                      
File system type?  [ext2]?                                                
Start? 1                                                                  
End? 513                                                                  
(parted) mkpart                                                           
Partition name?  []?                                                      
File system type?  [ext2]?                                                
Start? 513                                                                
End? 262657                                                               
(parted) set 1 raid on                                                    
(parted) set 2 raid on                                                    
(parted) unit b                                                           
(parted) print                                                            
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sde: 3000592982016B
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start       End            Size           File system  Name  Flags
 1      1048576B    537919487B     536870912B                        raid
 2      537919488B  275415826431B  274877906944B                     raid

(parted) 
これでサイズも全く同じパーティションができました。これをアレイに追加します。
# mdadm --add /dev/md0 /dev/sde1
mdadm: added /dev/sde1
# cat /proc/mdstat 
Personalities : [raid0] [raid1] 
md0 : active raid1 sde1[2](S) sdb1[1] sda1[0]
      524276 blocks super 1.0 [2/2] [UU]

スペアとして追加されてることがわかります。それを3台構成のRAID 1として定義しなおします。
# mdadm --grow /dev/md0 --raid-devices=3
raid_disks for /dev/md0 set to 3
# cat /proc/mdstat 
Personalities : [raid0] [raid1] 
md0 : active raid1 sde1[2] sdb1[1] sda1[0]
      524276 blocks super 1.0 [3/2] [UU_]
      [============>........]  recovery = 62.5% (327680/524276) finish=0.0min speed=109226K/sec
問題なさそうですね。同じことを / 用のアレイにも行えば /boot と / を3.0TBのディスクに移動したのと等価になります。

さて、あとは忘れずにこのディスクにもGRUBを入れなければいけません。
grub> root (hd4,0)
root (hd4,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd4)
setup (hd4)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd4)"... failed (this is not fatal)
 Running "embed /grub/e2fs_stage1_5 (hd4,0)"... failed (this is not fatal)
 Running "install /grub/stage1 (hd4) /grub/stage2 p /grub/grub.conf "... succeeded
Done.
果たしてこれで立ち上がってくれるのか?

一応確認のため、UEFIの起動順をこのディスクに変えて起動。大丈夫そうです。まあ厳密には他のディスクを外してみないと、本当にこのディスクだけから立ち上がってるかどうかの確認はできてないですが。

最後の仕上げで、今は3台のRAID 1になってるので、それから1台抜いて2台に戻します。
# mdadm --fail /dev/md0 /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md0
# cat /proc/mdstat 
Personalities : [raid0] [raid1] 
md0 : active raid1 sdb1[1] sde1[2] sda1[0](F)
      524276 blocks super 1.0 [3/2] [_UU]

# mdadm --remove /dev/md0 /dev/sda1
mdadm: hot removed /dev/sda1 from /dev/md0
You have new mail in /var/spool/mail/root
# cat /proc/mdstat 
Personalities : [raid0] [raid1] 
md0 : active raid1 sdb1[1] sde1[2]
      524276 blocks super 1.0 [3/2] [_UU]

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.0
  Creation Time : Fri Dec 21 23:57:28 2012
     Raid Level : raid1
     Array Size : 524276 (512.07 MiB 536.86 MB)
  Used Dev Size : 524276 (512.07 MiB 536.86 MB)
   Raid Devices : 3
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Fri Jan 24 08:24:51 2014
          State : clean, degraded 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       17        1      active sync   /dev/sdb1
       2       8       65        2      active sync   /dev/sde1
一瞬 degraded になりますが(当然メールも飛びますが)、2台体制に戻します。
# mdadm --grow /dev/md0 --raid-devices=2
raid_disks for /dev/md0 set to 2
# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.0
  Creation Time : Fri Dec 21 23:57:28 2012
     Raid Level : raid1
     Array Size : 524276 (512.07 MiB 536.86 MB)
  Used Dev Size : 524276 (512.07 MiB 536.86 MB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Fri Jan 24 08:26:04 2014
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

    Number   Major   Minor   RaidDevice State
       1       8       17        0      active sync   /dev/sdb1
       2       8       65        1      active sync   /dev/sde1

これで問題なく移動が完了しました。/ 用のアレイについても同様に処理しました。

まあこの移行の間にディスクが故障するってことを警戒しなければ、3つにして1つ抜くなんてしないでいきなり1つ抜いて別のと sync すりゃいいんだと思うんですが、基本ディスクは壊れるものという信念で作業しておりますw

2014年1月25日土曜日

自己満足的自宅サーバーディスク構成変更(2)~LVMからアレイを外す

それでは<お約束>ここに書かれていることを試す場合はデータをバックアップし、自己責任でお願いします。間違い等があっても責任は負いません。</お約束>

さて、まずは領域をあけます。ディスク上の不要なデータを削除して、なんとか2.5TBぐらいは開き領域を作成しました。つまり4TB程度はデータがある状態になります。Logical Volume Management を開き、必要ならLVのサイズを減らし、空きextentを確保します。この状態で、除去しようとしているアレイから使用中の extentを他のアレイに移動しなければいけません。早速行ってみましょう。

まず除去しようとしているアレイを Physical View でポイントします。すると以下のような絵が出てくると思います。この時点で全部が"Unused Space"だったら今すぐにでも除去できるわけですが、たいていの場合このように使用中になっていると思います。その場合は移動したいextent、下だとlv_shareが割り当てられているところをクリックします。あ、もちろんこの時点で他のPhysical Volumeに今選んでいる領域が使っているextentの数以上の空きextentがあることは確認してください。大丈夫であれば"Migrate Selected Extent(s) From Volume"をクリックします。


すると、確認のダイアログが出ます。

ここで適当に移動してもらってもいい場合は Automatically ... で、指定したい場合は Destination を選んでいざ OK を押します。

あれ、今さら気づいたけど、"Only migrate extends belonging to LV" ってのがチェックされてないってことは、もしかしてこれって選択してる領域にかかわらず全部移動するのかな?未確認。もし複数のLVがある場合はお気をつけください。

ともかくこれを実行してのんびり待つと空のPhysical Volumeとなります。今回の場合は2時間ぐらい後に見たら終わってました。
 こんな感じに全部が Unused Space になったらあとは"Remove Volume from Volume Group"をクリックするだけです。こちらはすぐに終わります。

せっかくなのでアレイの停止とかもGUIでやってみますか。Disk Utilityを開いて"Stop RAID Array"を押します。これは慎重に。間違えちゃだめなやつですよね?w
これでアレイは停止状態になりました。ちなみにコマンドでは mdadm -S <device> ですね。

自己満足的自宅サーバーディスク構成変更(1)~計画

先日のエントリで会社の開発機に起きた顛末をつらつらと書き連ねましたが、無事復活したことで急に家のサーバーのディスクは大丈夫かいなと思い始めました。ディスクの稼動時間なら会社のやつに負けないよ?いっぱい壊れてるかもよ?w

早速帰宅して調べたところ、すばらしいことにどのディスクも1つも不良セクタはないようです(ディスクが気づいてないだけかもw)。一番長いやつで 3.4 years となっているので3年以上稼動しているようですが。とりあえずそんなひどい状況ではないようです。

自宅サーバーはこんな感じでRAID 1のアレイをいくつか作り、それをLVMで取りまとめていたわけですが、今回LinuxのソフトウェアRAIDの便利さに感銘を受けたので、もっと使い込もうかなと。しかも当時誤解していたのか、ソフトウェアRAIDって0/1/10ぐらいしかできないと思ってたのに5や6もできるんですね。Linuxすばらしい。

現状のディスクはちょっとずつ買ったせいでサイズはまちまちです。
  1. 2.0TB (/boot, swap, /, pv(1))
  2. 2.0TB (/boot, swap, /, pv(1))
  3. 2.5TB (pv(2))
  4. 2.5TB (pv(2))
  5. 3.0TB (pv(3), data)
  6. 2.0TB (pv(3))
/boot, /, pv(1), pv(2), pv(3) はすべてRAID 1、swap は RAID 0、data は素の領域となっています。これをもっと改善できないかな?

/boot や / は何もディスクをケチるほど大きくないので RAID 1 のままでよいとして、他はせっかく6台もあることだし、RAID 5/6 にしたいですよね。私は個人的にはRAID 5が嫌いなので6にしたいかなと。もし/bootや/を2.5TBや3.0TBのディスクに移動できれば、2.0TBx6(RAID 6)=8.0TB になるわけで、現状の約6.0TBから2.0TBも増やせた上に冗長性が高くなります。これはやらない手はない。なぜRAID 5が嫌いかというと、5ってリビルドの負荷がかなり高くて、その間に大丈夫だったディスクがやられちゃうのが怖いのです。 6なら仮にそれがおきてもさらに1台やられない限り大丈夫なので気持ちの余裕が違うかなと。

しかしやるとなっても、システムには既にデータが数TBオーダーで置いてあるので、退避して戻すのは不可能。そんなでかいストレージは他にないです。なのでオンラインで変更できるわけもないし無理かなーと思っていたのですが、できそうなんですよ。確かに言われて見ると、「2台のRAID 5」=「RAID 1」なわけで、それをRAID 5、さらに6と上げていくのは技術的には可能でおかしくはないか。このあたりを読むとRAID 5から6への変更は mdadm コマンドでできるっぽいので、もしかしたらRAID 1から5もできたりしないのかな?

しかし、それができるとわかっても、やっぱりデータが載ってるRAID 1のアレイをリンク先の手順に書いてあるように一度消して作り直すのはちょっと怖い。なので、やるなら以下の方法がいいかなと思ったわけです。
  1. 現状LVMに参加しているアレイの最大サイズ(2.5TB)の分だけなんとか領域をあける
  2. そのアレイをLVMから抜く
  3. そのアレイをRAID5/2(RAID5の2台の意)にする
  4. 再びLVMに参加
  5. 別のアレイをLVMから抜く
  6. そのアレイを壊して3で作ったアレイに追加し、RAID5/2+2(RAID5の2台+スペア2台)
  7. RAID5/2+2をRAID6/4に変更
  8. 最後のアレイをLVMから抜く
  9. そのアレイを壊して7のアレイに追加し、RAID6/6に変更
 いやこれはまた壮大ですねw

しかも理想的には最低サイズ(2.0TB)にあわせてアレイを構築したほうがいいので、 /boot 等のシステム用のパーティションはでかいディスクに移したいわけです。まずはそこから手をつけるか?
  1. 3.0TBが参加しているアレイをLVMから抜く
  2. パーティションを切りなおし、既存の2.0TBのシステム用パーティションにあわせる
  3. RAID 1として参加させる
  4. GRUBをセットアップ
  5. 既存のディスクをアレイから抜く
基本これでいけるはず。じゃあアレイの構築とか相当時間がかかると思うのでのんびり行きますか。

2014年1月23日木曜日

再びディスクの話

おっと気づいたら2014年初エントリですね。つまりこんな感じで頻繁に書くものではないですが、今年もよろしくお願いします。

突然ですが、私はソフトウェア開発を生業としております。従って会社でもプログラムを書く仕事をしていて、机にはいわゆる「開発機」という開発専用のマシンを所有して(もちろん正確には貸与されて)います。会社は社員にノートPC(Windows)を貸与しているので日々の業務アプリケーション等は Windows が基本ですが、WindowsでないとできないものはノートPCでやればいいので、開発機は各自の自由な管理となっています。大半の人はWindowsですけどね。私はもちろんLinux - Red Hat Enterprise Linux を入れて活用しています。

その開発機もディスクが飛んですべて吹っ飛ぶのはいやなので、家のサーバーのように RAID 1 で冗長化しています。正確には、悲しいかな会社で使うマシンはうちのマシンより高いくせに貧弱(失礼)で、ディスクも 1.5TB/1.0TB/500GB を後生大事に使い続けるという状態なので、大事なデータを RAID 1 (1.5TB のうち 1.0TB と 1.0TB)と RAID 0 (1.5TB のうち 500GB と 500GB)で運用しています。しかもその1.5TBと1.0TBは前のマシンから転用してきたので結構前からあるやつです。

それが先週ふと GNOME の上のバーのところに、ディスクのアイコンに「!」がついてるアイコンがでていることに気づきました。最初は「何だろ?ディスクいっぱいにでもなったかな?」と思ったのですが、クリックしてみると

「ディスクが壊れかけています」(うろ覚え)

!!!
これはまずいと思いさらにクリックだかダブルクリックだかでディスクユーティリティーなるものが開くので見てみます。(余談ですが Linux もずいぶん便利になりましたよね。)すると、1.0TBのディスクの表示が既に「故障しています」になっているではないですか。 orz

どうも SMART の情報に何かあるということでクリックしてみると、"Reallocated Sector Count" という項目に赤が。ダメになって別のところが使われたと判定されたセクタの数ということですね。警告の出る閾値が確か100ぐらいだったんですがなんと2000越え。これは危険だ。仕方ないので交換用のディスクを注文し、翌日見ると3000越え。その翌々日見たら4000越えと日増しに増えてました。

とはいえ、上に書いたようにこのディスクは基本 RAID 1 のメンバーなので、最悪吹き飛んでもいいわけです。なのでのんびり見てたんですが、さすがにこんだけ増えてくるとなるともう外したほうがいいかと思って物理的に外しました。/proc/mdstat を見るとしっかり全部 degrade 状態に変化します。

秋葉原で買ってくれば即日なのに会社ってのは面倒なもんで、指定した業者から納品されたのは1週間後ぐらいでしたか。秋葉原で買ってくれば半額ぐらいなのに。 早速つないで RAID を再構築です。全く簡単な話で、既にあるアレイと同じか大きいパーティションを作成し、
# mdadm --add /dev/md127 /dev/sdb1
などとするだけです。しばらくして resync が終われば冗長性も完全復活です。

しかしですね、もうお分かりかと思うんですが、今さら同じサイズ(1.0TB)のディスク買う理由はないのですよ。というわけで今回買ったのは秋葉原なら普通に3.0TBや4.0TBも買えるのになぜか2.0TBの大容量!w つまり1.0TBも多いのです!(遠い目

なので、そのあまった分も RAID に組み入れたい、と思ったわけですが。当然アレイのサイズは変えられないし、別のアレイを作って LVM に追加かなぁと思っていたところ、アレイのサイズは変えられるんですね。Linux えらい。

詳細な手順は間違えているかもしれませんが、覚えている限りやったのは以下です。上の mdadm --add する前、既存のアレイが degraded の状態からです。
  1. 大きくしたいサイズでパーティションを切る(私の場合既存のアレイが800GB ぐらいでしたが、1.3TB ぐらいで切りました)
  2. mdadm --add して追加する
  3. mdadm --detail や /proc/mdstat 等で resync が終わるのを待つ
  4. mdadm --fail や物理的に外すなどで元の小さいパーティションをアレイから除く
  5. パーティションを切りなおす
  6. mdadm --add して追加する
この時点ではまだアレイのサイズは変わりませんが、アレイが乗っているディスクのサイズはどちらも増えた状態ということになります。なのでアレイのサイズを増やすことができます。
  1. mdadm --grow <device> -z max
これで使える最大サイズのアレイとなりました。実行する前と後で mdadm --detail <device> | grep Size などとすれば違いがわかると思います。

私はこのアレイをさらに LVM で使っていたので、PV としても大きくなってもらわなければ意味がありません。が、pvdisplay 等で見てもまだ前のサイズのままです。なのでもうひと手間かけましょう。
  1. pvresize <device>
これで無事 PV としても大きなサイズになりました。めでたしめでたし。

ちなみにパーティションのサイズは完全に一致している必要はありません。追加するほうがちょっと大きいぐらいなら無駄にはなりますが全く問題はありません。が、しかし、小さいとちょっと面倒です。先に大きいほうのパーティションでアレイを構築してしまうと、「アレイのサイズ」=「大きいほうのパーティションのサイズ」となってしまい、後から小さいのを追加すると怒られます。アレイのサイズを小さくすればいいのかもですが、大きくするのに比べて小さくするのはちょっと怖い感じですので・・・。(昔乗ってるファイルシステムよりLVを小さくしてぶち壊した経験ありますw)

さらになんでこのエントリが「自宅サーバー」ラベルなのか?それはこの出来事に触発されて自宅サーバーをいじることにしたからです。それはまた後日。

2013年3月10日日曜日

CentOS で 宅内 DNS の構築

開発機のアドレスが正しくアサインされてなかったことに気づいてあわててルーターの設定を直していたのですが、そのときにいつも http://192.168.0.1 と打ってまして、これなんとかならないのかなぁと思っておりました。よく使うマシンとかは hosts に書いてるんですが、家には何台かマシンがあり、全部のファイルを管理するのは嫌なので。そこでせっかく Linux マシンがあることだし、宅内用に DNS を構築してみることにしました。

まずはいつものように
# yum install bind

(snip)

Installed:
  bind.x86_64 32:9.8.2-0.17.rc1.el6.3
でインストールします。設定ファイルは /etc/named* と /var/named/* に配置されます。まず /etc/named.conf の options に以下のエントリを追加してローカルネットにのみ使用されるようにします。
        allow-query{
                127.0.0.1;
                192.168.0.0/24;
        };
        allow-recursion{
                127.0.0.1;
                192.168.0.0/24;
        };
        allow-transfer{
                127.0.0.1;
                192.168.0.0/24;
        };
次にLAN内以外の名前解決のため、ほかの(もともと使っていた)DNSサーバーを指定します。うちの場合はルーターを指定すればよいので以下のようになります。
        forwarders {
                192.168.0.1;
        };
さて解決したいアドレス群たちは別ファイルにします。named.conf で directory のところに指定されたディレクトリ、恐らく /var/named になっていると思いますが、そこにファイルを作成することになります。named.conf にはそのエントリだけです。
zone "mydomain.net" {
        type master;
        file "mydomain.net";
};

zone "0.168.192.in-addr.arpa" {
        type master;
        file "0.168.192.in-addr.arpa";
};
です。もちろん mydomain.net はご自分のドメインに書き換えてくださいね。

さてそれぞれのファイル自身の書き方が難しいです。named やら named.conf やらの man を見たんですが見つかりませんでした。このへんを参考にさせていただいて書いてみました。まずは正引き、つまり名前をIPアドレスに変換するほうです。
$TTL 1D
@       IN SOA  server.mydomain.net. root.server.mydomain.net. (
                                        2013030901      ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        IN NS   server.mydomain.net.
        IN MX 10        server.mydomain.net.
router  IN A    192.168.0.1
server  IN A    192.168.0.2

なにやら呪文のようですが・・・。アドレスの最後の . が結構肝みたいです。このファイル自体が "mydomain.net" 用というのを named.conf で指定したので、省略が利用できます。たとえば @ はそれ自身、つまり mydomain.net そのものの代わりです。また、 . で終わらないもの(上では router とか)は後ろに .mydomain.net がつくと解釈されます。なので、router の行では 「router.mydomain.net を 192.168.0.1 とする」という定義になります。

今度は逆引き、つまりIPアドレスを名前に変換するほうです。記法は基本一緒です。
$TTL 1D
@       IN SOA  server.mydomain.net. root.server.mydomain.net. (
                                        2013030901      ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        IN NS   server.mydomain.net.
        IN PTR  mydomain.net.
        IN A    255.255.255.0

1       IN PTR  router.mydomain.net.
2       IN PTR  server.mydomain.net.

ここでも同じです。さきほど 0.168.192.in-addr.arpa 用に定義したファイルなので、1 とかは 1.0.168.192.in-addr.arpa を定義したことになります。

これらのファイルが記述できたら、ツールで確認ができます。
# named-checkzone mydomain.net /var/named/mydomain.net 
zone mydomain.net/IN: loaded serial 2013030901
OK
# named-checkzone 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa
zone 0.168.192.in-addr.arpa/IN: loaded serial 2013030901
OK
よさそうですね。いざ起動します。
# service named start
一応 /var/log/message を確認して大丈夫なことを確認して・・ってあれれ?
Mar  9 23:25:37 named[11531]: zone 0.168.192.in-addr.arpa/IN: loading from master file 0.168.192.in-addr.arpa failed: permission denied
Mar  9 23:25:37 named[11531]: zone 0.168.192.in-addr.arpa/IN: not loaded due to errors.
なるほど、ほかのファイルたちは group が named になってるのに私は root のままにしてました。
# chgrp named mydomain.net 
# chgrp named 0.168.192.in-addr.arpa 
# service named restart
今度は無事起動したようです。/etc/resolv.conf のエントリを /etc/sysconfig/network-scripts 等から変更し、ネットワークの再起動をします。確認します。
# nslookup router
Server:  127.0.0.1
Address: 127.0.0.1#53

Name: router.mydomain.net
Address: 192.168.0.1

# nslookup 192.168.0.1
Server:  127.0.0.1
Address: 127.0.0.1#53

1.0.168.192.in-addr.arpa name = router.mydomain.net.

# nslookup www.google.com
Server:  127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: www.google.com
Address: 173.194.38.81
Name: www.google.com
Address: 173.194.38.82
Name: www.google.com
Address: 173.194.38.83
Name: www.google.com
Address: 173.194.38.84
Name: www.google.com
Address: 173.194.38.80

内部のアドレス、外部のアドレスとも問題なく解決されました。あとはこのサーバーをDNSサーバーとしてクライアントに登録するだけで利用できます。

実際に使ってみたところだめでした。 orz
原因の1つめは named.conf をよーく見ると
listen-on port 53 { 127.0.0.1; };

とありました。つまりそのサーバーだけでしか使えなくなっています。 上のテストはサーバー上だったので使えていたのですね。 まずはこれを修正します。 そうしたら一応使えてるっぽいんですが、なぜか1度目は失敗します。
C:\>nslookup www.formula1.com
サーバー:  server.mydomain.net
Address:  192.168.0.2

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** server.mydomain.net への要求がタイムアウトしました

C:\>nslookup www.formula1.com
サーバー:  server.mydomain.net
Address:  192.168.0.2

権限のない回答:
名前:    pc-b.bitgravity.com
Address:  64.185.181.238
Aliases:  www.formula1.com
          f1tata.pc.cdn.bitgravity.com
また /var/log/messages に戻ると、大量のエラーが。
Mar 10 00:14:14 named[13184]: validating @0x7fe418008ea0: . NS: got insecure response; parent indicates it should be secure
どうもルーターが dnssec に対応してないようですね。どうせLAN内だから別にいいか。(本当はどうかわからないですが。)/etc/named.conf の dnssec-validation を no に変えたところ無事動きました。

ネットワークの設定はいろいろ大変ですね。ここまでやってようやく http://router でルーターの管理画面に入れたわけですが、そこまでの価値があったのかどうかw まあ自己満足でOKとします。

2013年1月17日木曜日

xrdp でターミナルの補完時に待たされる件

ちょっと前に書きましたが、今自宅サーバーに接続するには xrdp 経由のリモートデスクトップで接続しています。いちいち Windows マシンに VNC クライアントを入れなくていいので重宝しているのですが、今のところ唯一かつ致命的な難点がありまして。それは
”ターミナルを開いて補完すると遅いことがある”
というものでした。とにかく接続したときに例えば
$ ls / <TAB><TAB>
などと打つと、普通はさっと / 直下のディレクトリやファイルが列挙されると思いますが、このときなぜか1秒程度待たされるのです。
$ ls /usr/loc<TAB>
のように候補が1つしかないものはさっと /usr/local とかになってくれるんですが、
$ ls /usr/li<TAB>
のように /usr/lib /usr/lib64 /usr/libexec 等複数の候補があったり、まったく候補がないような場合も同様に1秒程度待たされた後に /usr/lib まで補完されます。

どうにもストレスするので、使うの止めようかとも思ったんですが、VNCよりクリックしたときのクリック感(?)とかがコンソールからログインしてるときに近いとか、セッションがないときにも勝手にあげてくれるとかいいところもあるので原因を探っていました。そして今日ようやく見つけました!ググってもあまり出てこないところを見るとあまりみなさん気にしてないのか、こんな環境あまりないのか、はたまた私の何かの設定のせいで会社のサーバーも自宅のサーバーも同じような状態に陥ってるのかわかりませんが、とにかく解決方法です。

解決方法は
gnome-terminal の Preferences で "Terminal bell" をオフにする
でした。なるほど、音まわりでしたか。リモートデスクトップってリモートのマシンの音もローカルに持ってこれましたよね。そのあたりに何かありそうです。

なぜこれにたどり着けたかというと、この補完が遅いという事象、今のところは gnome-terminal を使ったときにしか観測されてないんですね。なので別のターミナルを入れてみようかということで、terminator というものを入れてみました。これはこれでなかなかよさげなツールなんですが、これを使った場合、補完は遅くなかったのです。おお、解決したか!と思ったんですが、補完した瞬間(というか上の例で補完が遅い瞬間)、terminator に何かアイコンのようなものが表示されます。
 なんでしょうね、これ。と思って急いでクリックしたりなんかしてたんですがわからない。そこでデバッグオプションをつけて実行してみたところ、こんなログがでました。
ConfigBase::get_item: ConfigBase::get_item: urgent_bell found in profile default: False
ConfigBase::get_item: ConfigBase::get_item: icon_bell found in profile default: True

ベル・・・。もしや!?と思って先ほどの設定をしたところ見事に解決した、というわけです。めでたしめでたし。

2013年1月11日金曜日

Linux にリモートデスクトップで接続

表題のとおりです。なかなかいいよという噂を聞いたので試してみました。

まずは EPEL を enable しておきます。
# yum search xrdp
(snip)
Installed:
  xrdp.x86_64 0:0.5.0-0.13.el6                                                                                                 

Complete!
インストールは簡単ですね。
# service xrdp start
いきなり開始します。これだけ。そして・・・


このように Windows のリモートデスクトップ接続で接続できます。ただこのままだと日本語キーボードでは問題があるのでこのファイルを /etc/xrdp に置く必要があります。(以降のバージョンでは直っている可能性があります。その場合は xrdp-genkeymap を実行するとそのファイルが生成できるはずです。)

ちなみに接続する解像度がキーになっているのか、同一の解像度で接続すると同じセッションが取得できます。逆に言うと別の解像度で接続すると新たなセッションが割り当てられます。ログアウトすると当然そのセッションはなくなります。

なかなか感動もんですがどうなってるか気になりますよね。これを見ればある程度わかるかも?
$ ps -ef | grep vnc
user   18453 18451  0 23:17 pts/0    00:00:01 Xvnc :10 -geometry 1680x1050 -depth 16 -rfbauth /home/user/.vnc/sesman_user_passwd -bs -ac -nolisten tcp -localhost -dpi 96
つまり通信はリモートデスクトップのプロトコルに準じてるわけですが、その先は VNC サーバーを自動で立ち上げてくれているみたいです。なので上に書いたように解像度を変えると別のセッションになったりしますが、最悪 VNC のディスプレイ番号を見つければ、そのマシン上からは vncviewer で接続できます。

まあ家だとつないでるマシンとサーバー間に距離がない、というかGBitの中なので VNC とどっちがいいとかあまりないですが、vncclient を入れてない Windows 機からもつなげるのはありがたいですね。ちなみに、/etc/xrdp/xrdp.ini をいじると、固定の VNC ディスプレイに接続することもできます。vino とかを使ってる場合はそれで :0 につなげることも確認しました。

なかなか便利ですよね。しばらく使ってみることにします。

2013年1月5日土曜日

git との格闘w その4 githubとの格闘w

いよいよ本題に近づいて参りました。ようやく github の前半3文字を少し理解できるようになったので次は github です。いけいけゴーゴー! (古っ?w)

ここあたりを参考に進めます。さらにこちらも参考にさせていただきました。

github にアカウントを作ってログインします。検索やら何やらで参加するプロジェクト(と呼ぶのかな?)を探します。そして Fork を・・・。

いいのかな~。本当にいいのかな~。いいや、失敗してもいいって @yusuke さんが言ってくれたし。(正確には「何度でもやり直しできるので」であって失敗していいってわけではないんですがw)えいっ!

・・・とりあえずデモのrepoで試してみますw
$ ls
sample
$ git clone https://github.com/Sdk0815/Spoon-Knife.git
Initialized empty Git repository in ~/git/Spoon-Knife/.git/
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 24 (delta 7), reused 18 (delta 2)
Unpacking objects: 100% (24/24), done.
$ ls
sample  Spoon-Knife
$ cd Spoon-Knife/
$ ls
forkit.gif  index.html  README
最終的には親に pull request を送るので、fork 元のrepoを足します。
$ git remote -v
origin https://github.com/Sdk0815/Spoon-Knife.git (fetch)
origin https://github.com/Sdk0815/Spoon-Knife.git (push)
$ git remote add upstream https://github.com/octocat/Spoon-Knife.git
$ git remote -v
origin https://github.com/Sdk0815/Spoon-Knife.git (fetch)
origin https://github.com/Sdk0815/Spoon-Knife.git (push)
upstream https://github.com/octocat/Spoon-Knife.git (fetch)
upstream https://github.com/octocat/Spoon-Knife.git (push)
ふむふむ。いい感じ。適当に変更を作る branch を用意します。
$ git checkout -b work
この branch 上で変更を作ります。変更ができたら pull request 用の branch を作ります。
$ git checkout -b fix_css
$ git rebase -i master
Successfully rebased and updated refs/heads/fix_css.
rebase するときに複数の commit を一つにまとめるそうです。そうでないとローカルでいろいろやった変更がサーバー上にも見えちゃうとか。

さていよいよサーバーに push してみますかね。
$ git push origin fix_css
error: The requested URL returned error: 403 while accessing https://github.com/Sdk0815/Spoon-Knife.git/info/refs

fatal: HTTP request failed
おうふ・・・。そういえばそもそもログインとかしてないような・・・。.git/config の origin のところ、https://... を https://Sdk0815@... に変えます。
$ vi .git/config 
$ git push origin fix_css
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 285 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To https://Sdk0815@github.com/Sdk0815/Spoon-Knife.git
 * [new branch]      fix_css -> fix_css
おおお!できましたね! git push のときにパスワードを聞かれます。

さて今度はブラウザで見てみましょう~。
 キター!

最後に pull request です。やり方はこちら。デモなんでがんがん行きますよ~。まず
 のように作業したブランチを選択。そして右上の"Pull Request"ボタンをクリック。
いざ "Send pull request" をクリック~!おおおおお!

これはなかなか楽しいですなw


gitとの格闘w その3 リモート

そういえば呪文のように打っていたコマンド
$ git push origin master
がありましたがチュートリアルの次のページでようやくわかりました。
$ git remote
origin
最初にクローンしたので remote としてそのクローン元が origin として定義してくれてたんですね。で、master というブランチ(?)を origin に push するコマンドが呪文の正体だったと。なるほど。

別のディレクトリで同じリポジトリに大して clone してたほうからいくと
$ git status
# On branch master
nothing to commit (working directory clean)
$ git fetch
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git://localhost/sample
   aa7f9ba..2c64353  master     -> origin/master
$ git status
# On branch master
# Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
#
nothing to commit (working directory clean)
$ git pull
Updating aa7f9ba..2c64353
Fast-forward
 README |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
$ git status
# On branch master
nothing to commit (working directory clean)
fetch の時点では変更内容をとるだけでファイルの変更等はしないと。これもまあ当たり前ですかね。ブランチの情報とかもこの時点で持ってくるみたいです。その後変更を取り入れるなら pull で取り込むと。ふむふむ。
$ git log --pretty=oneline --graph
* 2c64353f62ac483887e773f58fe59315eeb3f2e1 Delete one more line
* aa7f9ba17d78193174415b97dae2b32264fc2061 Delete a line
*   0961ac4a66fbfcace7c0fc766544fa8da4b678dd Resolve conflict
|\  
| * 700f0dcca4861dd99ceb5dee12220d687c793433 Commit on branch
* | 9fb2424b4d9314e8d50f1bdb619d050b57675e07 Conflict!
|/  
* fda2f7be817a8534594a094b0b6e5b20e22d622d Commit
* ae419f95f40424091667aa750bf495b0665d133b Add another line
* 2698c25066c123921d74115385a52a627c067f30 Add one line
* 253133b619739070a06835181c4ed6c40aa7e08c initial commit
いい感じw

あとは実際に使うときに必要に応じてヘルプを見ながらすすめればいけそうですね。

git との格闘w その2 いろいろ変更

さて、サーバーにも接続できるようになったところでチュートリアルに戻ります。さっき clone したところに移動して、
$ vi README        <-- 適当に編集
$ git commit -a
[master 2698c25] Add one line
 1 files changed, 1 insertions(+), 0 deletions(-)
git commit をするとエディタが上がるので適当に commit のコメントを追加。これも git push origin master で push してみるとうまくいく。なるほど。

次はstaging。
$ vi README 
$ vi tmp/README 
$ git status
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   README
# modified:   tmp/README
#
no changes added to commit (use "git add" and/or "git commit -a")
何か変更を作ってみた。一つ staging。
$ git add README 
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
# modified:   README
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   tmp/README
#
コミットしてみる。
$ git commit
[master ae419f9] Add another line
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   tmp/README
#
no changes added to commit (use "git add" and/or "git commit -a")
ほほう。1つはちゃんと commit されて、もう一つの変更はそのままと。さっき何も考えずに commit -a としていたが、その -a は全部ファイルを commit しちゃうためのものだったとか。(それを知らずに -a して全部コミットされたアカウントはこちらですw その場合は git reset --hard HEAD~ とやると全部投げ捨てられる模様。)なるほどなるほど。この状態でまた push すると当然 commit されたものだけ飛んでいきます。

次はいよいよブランチ。
$ git branch
* master
作成。
$ git branch experiment
$ git branch
  experiment
* master
作成されました。
$ git checkout experiment
M tmp/README
Switched to branch 'experiment'
$ git branch
* experiment
  master
$ git status
# On branch experiment
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   tmp/README
#
no changes added to commit (use "git add" and/or "git commit -a")
なるほど・・・。さっき commit してなかった変更とかはそのままなんですね。当たり前か。
$ vi TODO
$ git add TODO 
$ git commit -am "Commit on branch"
[experiment 700f0dc] Commit on branch
 2 files changed, 3 insertions(+), 1 deletions(-)
 create mode 100644 TODO
$ git status
# On branch experiment
nothing to commit (working directory clean)
あれ、commit どこいった?
$ git diff master
diff --git a/TODO b/TODO
new file mode 100644
index 0000000..295f16a
--- /dev/null
+++ b/TODO
@@ -0,0 +1,2 @@
+Todo file
+
diff --git a/tmp/README b/tmp/README
index edb0724..3105724 100644
--- a/tmp/README
+++ b/tmp/README
@@ -1,2 +1,2 @@
 This is sample file 2.
-
+This is another line in another file.
とりあえず master との比較ではずれがあることはわかる。(コマンドがこれでいいのかは不明。)
$ ls
README  tmp  TODO
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
$ ls 
README  tmp

さあ conflict させてみますよ。
$ vi tmp/README 
$ git commit -am 'Conflict!'
[master 9fb2424] Conflict!
 1 files changed, 1 insertions(+), 1 deletions(-)
これで master と experiment がそれぞれ先へ進みました。マージしてみます。
$ git merge experiment
Auto-merging tmp/README
CONFLICT (content): Merge conflict in tmp/README
Automatic merge failed; fix conflicts and then commit the result.
おうふ・・・。ちょっと変更が近すぎましたかね。TODO のほうは成功したんですが tmp/README がだめでした。ファイルの中身はどうなってるかな?
$ cat tmp/README 
<<<<<<< HEAD
This is sample file 2 and more!.

=======
This is sample file 2.
This is another line in another file.
>>>>>>> experiment
解決するには編集して普通に add して commit だそうで。
$ vi tmp/README 
$ git add tmp/README 
$ git commit -am 'Resolve conflict'
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 4 commits.
#
nothing to commit (working directory clean)
それぞれの変更が入った状態の完成です。最後にワークに使った branch を消す。
$ git branch -d experiment
Deleted branch experiment (was 700f0dc).

git との格闘w その1 git サーバー on CentOS 6

気楽に Twitter4J の JavaDoc のリンク切れをドヤ顔で指摘したら、pull request してくださいとの返答をいただき、これまた気軽にりょうかいしたところ、やったことない人には壮絶に敷居が高そうなことがわかりましたw 自宅で1人で書いてるコードの変更管理なら CVS やら SVN やらで十分だし、仕事では某社のツールべったりだったし、目にはしたけど使ったことないんですよね、git。なのでもちろん github も見るだけでして。ここで諦めてもいいんですが、せっかくなので挑戦してみますか。まずは git から。

インストール

ふむふむ。git はコマンドラインでいろいろやるっぽいですね。もちろん IDE からもできるはずですがコマンドの理解から入るほうが理解しやすいですし。最終的にはせっかく買ったこの子から使いますよ。で、コマンドライン環境は・・・そんな時のために Linux サーバーがあるんですよ! ええ!早速インストールです。
# yum install git
(snip)
Setting up Install Process
Package git-1.7.1-2.el6_0.1.x86_64 already installed and latest version
Nothing to do
既に入ってましたw

使ってみる

まあ何はともあれ使ってみよう。まずはこのへんを読んでみる。ポイントは分散開発環境では当然問題になる部分ですが”cheap branching and easy merging”という部分にありそうですね。

まずは全体の環境設定から。
$ git config --global user.name "Sdk0815"
$ git config --global user.email "***@***.***"
何かリポジトリを作ってみます。
$ mkdir -p git/sample
$ cd git/sample
$ git init
Initialized empty Git repository in ~/git/sample/.git/
適当にファイルを置いて
$ git add .
$ git log
fatal: bad default revision 'HEAD'
$ git commit -m "initial commit"
[master (root-commit) 253133b] initial commit
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 README
 create mode 100644 tmp/README
$ git log
commit 253133b619739070a06835181c4ed6c40aa7e08c
Author: Sdk0815 <***@***.***>
Date:   Fri Jan 4 13:55:45 2013 +0900

    initial commit
ふむ。何かコミットできたようです。

・・・というか、ここから先はサーバーとやりとりするようになってる。せっかくだから自宅サーバーも git のサーバーとして使えるようにしてみるか?

サーバー構築

今度は
# yum install git-daemon
(snip)
Running Transaction
  Installing : 2:xinetd-2.3.14-35.el6_3.x86_64         1/2 
  Installing : git-daemon-1.7.1-2.el6_0.1.x86_64       2/2 
  Verifying  : git-daemon-1.7.1-2.el6_0.1.x86_64       1/2 
  Verifying  : 2:xinetd-2.3.14-35.el6_3.x86_64         2/2 

Installed:
  git-daemon.x86_64 0:1.7.1-2.el6_0.1
Dependency Installed:
  xinetd.x86_64 2:2.3.14-35.el6_3

Complete!
入ってませんでしたのでめでたくインストールw /etc/xinetd.d/git を開き、disable = yes を no に変更し、xinitd を restart。

ん、これだけ?よくわからんのでとりあえずリポジトリを作って進んでみよう。ユーザーも特に作られてないし・・・。
# cd /var/lib/git/
# mkdir sample
# cd sample
# git init --bare --shared
さっきのプロンプトに戻って
$ git remote add origin git://localhost/sample
$ git push origin master
fatal: The remote end hung up unexpectedly
ですよね・・・。そううまくいくわけはなく。/var/log/messages を見ると
git-daemon[25672]: 'receive-pack': service not enabled for '/var/lib/git/sample'
なるほど。さっきの /etc/xinetd.d/git の server_args に --enable=receive-pack を追加して xinetd を再起動してみる。
$ git push origin master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 333 bytes, done.
Total 5 (delta 0), reused 0 (delta 0)
error: unpack failed: unpack-objects abnormal exit
To git://localhost/sample
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'git://localhost/sample'
めげるな!またログを見ろ!
git-daemon[25747]: error: insufficient permission for adding an object to repository database ./objects
ふむ。さっきの /var/lib/git/sample には objects ってディレクトリがあってそこは root の持ち物になってる。xinetd は root だが・・・ってそうか!また /etc/xinitd.d/git に戻り、ユーザーをチェックすると、nobody になってる。なるほど、では git ユーザーを作って再挑戦。ついでに repository のディレクトリも ~git/repo に変更。xinitd を再起動していざ。
$ git push origin master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 333 bytes, done.
Total 5 (delta 0), reused 0 (delta 0)
To git://localhost/sample
 * [new branch]      master -> master
おおお?うまくいったかな?確認。
$ cd ..
$ ls
sample
$ rm -rf sample
$ ls
$ git clone git://localhost/sample
Initialized empty Git repository in ~/git/sample/.git/
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 5 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (5/5), done.
$ ls
sample
$ cat sample/README 
This is test file.

おおお、できましたね!

2013年1月4日金曜日

Linux で日本語

実際のところそんなには利用頻度は高くないですが、Linux 環境でも日本語を入力したくなることはあります。たとえばここに書くときとかw これまでは Linux で作業したやつをコピペして Windows 上で書いてたのですが、いい加減面倒くさくなってきました。 なので大した手間ではなかったので手順を書いておきます。

インプットメソッド

インストールしたときに日本語を選んでおけばよかったのですがそんなつもりもなかったので英語でインストールしてました。でもその状態でも IM とかはちゃんと入ってるようですね。

  1. gnome 上から System -> Preferences -> Imput Method を選ぶ
  2. iBus を選び、Imput Method Preferences をクリック
  3. Imput Method タブで Japanese -> Anchy を選び、Add
  4. ログアウトしてログインしなおす
これで日本語入力ができるようになるはずですし、直接コンソールから入ってる場合は Ctrl+Space や半角全角キーで日本語モードになるはず。

しかし私の環境では Linux マシンにはディスプレイ等はつながっておらず、常に VNC で作業してる状態なのですが、VNC 経由では Ctrl+Space は効くものの半角全角は効かない。しかも Ctrl+Space って IDE/エディタでは重要なキーバインドなのでやはり半角全角で変換したいです。なので先ほどの Input Method Preference に戻ります。
  1. Keyboard Shortcuts の Enable or disable : のところの ... をクリック
  2. Keycode の ... のところをクリック
  3. ダイアログが出てるところで半角全角キーを押す
  4. 出てきた「Hankaku」と「Zenkaku」を "Release" のチェックを外して Add
VNC の設定等で回避できるのかもしれないのですがキーコードが Hankaku か Zenkaku になるようですね。

これで日本語の入力ができるようになりました。

フォント

入力はできるようになりました。しかし表示は相変わらず昔のコンピュータみたいです。もう少しマシなフォントを入れますか・・・。おお、今時はIPAフォントが base からとれるんですね。
# yum install ipa-*-fonts
(snip)
Installed:
  ipa-gothic-fonts.noarch 0:003.02-4.2.el6           ipa-mincho-fonts.noarch 0:003.02-3.1.el6          ipa-pgothic-fonts.noarch 0:003.02-4.1.el6         
  ipa-pmincho-fonts.noarch 0:003.02-3.1.el6         

Complete!
$ fc-list  | grep IPA
IPAGothic,IPAゴシック:style=Regular
IPAPGothic,IPA Pゴシック:style=Regular
IPAMincho,IPA明朝:style=Regular
IPAPMincho,IPA P明朝:style=Regular
楽々ですね。ってもそんなに綺麗にはなってない気がしますが・・・。文字が少しぼけた感じなのはフォントを変える前からですが。

2013年1月2日水曜日

RAID と LVM と 4K セクタ

フォロワーさん(いつもありがとうございます!)から教えていただいた情報。
LVM on RAID するときの注意点
そういえば(爆)使ってるディスクたちは Western Digital のいわゆる Advanced Format、つまり4096バイトセクタを採用しているディスクたちでした。もともと512バイトが一般的だったので、それを前提としたフォーマットを特に考えないで使ってしまうとパフォーマンスが劣化すると言うやつですね。まあぶっちゃけるとサイズにばかり目が行ってて忘れてました。 orz

で、ようやく全ステップが完了したのでのんびり(おい)対応していこうかなぁと。また無駄なデータの移動とかしちゃうけどね~。楽しいからいいもんね~。などと自分をごまかしつつ。

ディスク全体をRAID1にしてる場合

まずは上記のリンクにあるように、ディスク全体を RAID 1 にしてる人。そんなことしてるわけが・・・ありました。うーむ。まずは RAID の superblock のバージョンですが、
# mdadm --detail /dev/md4
/dev/md4:
        Version : 1.2
おうふ・・・。お勧めの1.0なんかにはもちろんしていない。上のリンクでは、1.0だとmetadata の位置が領域の最後方となるため、データ領域がディスクの先頭=4096バイトセクタの先頭ということですよね。えー、でも1.0より新しい気がするのに問題あるとか納得いかない感じなのですが・・・。1.2とはどういうものかというとこれによれば、superblock の場所が
4K from the beginning of the device
とあります。1.0だとたしかに at the end of device とあるのでデータ領域は先頭のようです。しかしどう読んでも superblock の長さもわからないのでデータ領域がいくつから始まってるのか不明。いろいろ調べたら mdadm で調べられると。コマンド発行対象のデバイスはディスク自体であることに注意です。
# mdadm -E /dev/sdc
/dev/sdc:
        Version : 1.2
(snip)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
たしかに superblock は 8 sectors = 512x8 bytes = 4096 ですね。でも Data Offset はちゃんと 2048 sectors = 512x2048 bytes で 4K セクタに合っているではないですか!GJ!(であってますかね?w)

なので RAID のほうはこのままで OK と。次はPV(物理ボリューム)のほうです。 これもデータ領域がどこから始まってるかが問題。
# pvdisplay --verbose /dev/md4
    Using physical volume(s) on command line
  --- Physical volume ---
  PV Name               /dev/md4
  VG Name               vg_data
  PV Size               2.27 TiB / not usable 1.64 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
(snip)
うーむ。これもまたデータ領域がどこから始まってるのかわからない。man pvcreate 等を見ていたら、pvs でどこから始まってるのかがわかるそうな。
# pvs -o +pe_start
  PV         VG      Fmt  Attr PSize   PFree   1st PE 
  /dev/md4   vg_data lvm2 a--    2.27t      0    1.00m
おお!?これって最初のPEが1Mから始まってるってことですよね?ということはこれも4KにアラインしてるということでOK!(でいいんですかね?w)そして PE の単位は上で調べたとおり4Mなので当然4Kにアラインします。というわけで、結論。
 ディスク全体を RAID 1 にしたものについてはこのまま運用!w
 あってるかどうか実験しようもないのであくまでも推察ですが・・・。結局のところ勝手によきにはからってくれるようないい時代になったってことですかね。

パーティションを切ってRAID1してる人たち(>2TB)

次はパーティションを切ってる場合の調査です。これはさんざいわれてましたね。fdiskを使うときに。
# fdisk /dev/sde

WARNING: GPT (GUID Partition Table) detected on '/dev/sde'! The util fdisk doesn't support GPT. Use GNU Parted.


WARNING: The size of this disk is 3.0 TB (3000592982016 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 
partition table format (GPT).


The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): q

・・・って新しく買ったディスク、3TBなので fdisk を使おうとすると警告が出ます。というか警告多すぎw そのまま使うと正しく認識されなかったりさんざんな目にあうとか。実際 2.5TB のディスクを Windows につけたら謎のパーティション構成になってました。そちらは dos 形式の MBR を gpt に変更したら直りましたけど。

で、今回はいよいよ上の警告でお勧めされている parted を使いました。なんか使ったことないので怖いぞw parted で mkpart を実行すると、もう画面はどっかいっちゃったので見せられませんが、「このままだとパフォーマンス悪いよー」的な警告が。その対策としては「ユニットをMiBにすればいいよ」と。なので u MiB をしてからパーティションを作成すると何も言われずに作成されます。果たしてこのパーティションは 4K バイトに沿っているのでしょうか?
(parted) u s                                                              
(parted) print                                                            
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sde: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start        End          Size         File system  Name  Flags
 1      2048s        3907028991s  3907026944s                     raid
 2      3907028992s  5860532223s  1953503232s
ユニットをs(セクタ)にして print してみたところ、ちゃんと開始が 2048s になってました。ということでこれもOKだし、RAID の superblock も
# mdadm -E /dev/sde1
/dev/sde1:
(snip)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
なのでこれも問題なし!(ですよね?ww)というわけで、結論。
 3TB で RAID 1 にしたものについてもこのまま運用!ww

 パーティションを切ってRAID1にしてる人たち(ブート)

さて最後に残った一番怪しそうなところです。今回 CentOS を新たにインストールしたとき、インストーラの時点で RAID のパーティションを作成してインストールしました。ここが一番うまくいってなさそうな気配です。ここを上と同様にチェックしてみます。
(parted) u s                                                              
(parted) print                                                            
Model: ATA WDC WD20EARS-00M (scsi)
Disk /dev/sda: 3907029168s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start       End          Size         Type     File system  Flags
 1      2048s       1050623s     1048576s     primary  ext4         boot, raid
 2      1050624s    17827839s    16777216s    primary               raid
 3      17827840s   554698751s   536870912s   primary               raid
 4      554698752s  3907024064s  3352325313s  primary               raid
まずいきなり見えた1から2048セクタなのでいい感じ?ほかもすべて 2048 (64) の倍数から開始しているのでこれもよさそうな感じではないですか!(本当にいいんですよね?www) RAID の superblock も同じように 2048 sector から開始しているようです。なんだすばらしいじゃないですか。ちなみに partition 3 は / 用に切ったパーティションなんですが、この人はなぜか metadata 1.1 になってます。インストーラから作る /boot でないやつは 1.1 になるんですかね。

というわけで、結論。
 インストール時に作ったものについてもこのまま運用!www
 というわけで、今現在ささっているすべてのディスクについてこのまま運用するという結論が出ました。めでたしめでたし。

(間違ってるところあったらぜひ指摘していただけるとうれしいです。)

Step 9-11 : 完了

さていよいよ最終ステップです。
  1. もともと VG に入っている 1.5TB の HDD を抜き、新たに 3.0TB と交換
  2. 開発機から 1.0TB のディスクを抜いて刺し、3.0TB の RAID 1 を VG に追加
  3. 開発機に 2.5TB、1.5TB を刺し、1.5TB RAID1 + 1.0TB にする
これも技術的には特に問題なし。mdadm, pvcreate, vgextend 等を使って追加します。開発機のほうも移動したディスクに cygwin の rsync で全コピーしてドライブレターを付け替えるだけで問題なく移行できました。

これにてストレージに関しては

Server      : RAID1 6.5TB
Dev Machine : RAID1 1.5TB + non-RAID 1.0TB

となりました。めでたしめでたし(?)

2012年12月31日月曜日

Step 8 : 2.5TB RAID 1 を追加

さあサーバー移行もぼちぼち完了が近づいてきました。ここから先はほぼ技術的な困難はないと思われます。
  1. 7で空いた 2.5TB HDD x 3 のうち2本をサーバーにつけ、RAID 1 で VG に追加
です。どっちかというと物理的な結線のほうに時間がかかる作業。問題なく完了し、起動。
# mdadm --create /dev/md4 --level 1 --raid-devices 2 /dev/sdc /dev/sdd
これまでのディスクと違い、全く同じサイズの2つのディスク全体を RAID 1 にしてしまってかまわないので、パーティション等は切らずにいきなり追加できます。あ、でもこれってどっちかのディスクが壊れたときに同じサイズのディスクを用意しないとじゃないと復旧できないのかな・・・?まあでもおそらく新しいディスクのほうが大きなサイズで、それに同じサイズのパーティションを用意してそれをメンバにすればよさそうな気はしますね。なのでこのまま続行です。 vgdisplay によるともともと以下のような状態でしたが
  VG Size               1.56 TiB
  PE Size               4.00 MiB
  Total PE              409218
  Alloc PE / Size       409218 / 1.56 TiB
  Free  PE / Size       0 / 0  
以下のコマンドで追加します。
# pvcreate /dev/md4
# vgextend vg_data /dev/md4
結果は
  VG Size               3.84 TiB
  PE Size               4.00 MiB
  Total PE              1005382
  Alloc PE / Size       409218 / 1.56 TiB
  Free  PE / Size       596164 / 2.27 TiB
と無事増量成功です。

あ、そうだ、次の Step 9 以降ですが、秋葉原に行ったときに2Tのディスクを買おうと思ってレジに並んだところつい3Tを買ってしまったのでまた改定しますw

  1. もともと VG に入っている 1.5TB の HDD を抜き、新たに 3.0TB と交換
  2. 開発機から 1.0TB のディスクを抜いて刺し、3.0TB の RAID 1 を VG に追加
  3. 開発機に 2.5TB、1.5TB を刺し、1.5TB RAID1 + 1.0TB にする
これが終わると自宅サーバー上には合計 6.5TB RAID 1 のディスクアレイの完成です。何に使うんだ!w

mysql の移行

インストール
# yum install mysql-server
# service mysqld stop
構成
# vi /etc/my.cnf
データディレクトリの移動と
[mysql]
default-character-set = utf8
の追加。動いているマシンからデータのコピー。終わったら
# service mysqld start
% mysql -p <database_name>
などで確認。