web-dev-qa-db-ja.com

LinuxソフトウェアRAID5ランダムスモールライトパフォーマンスアビスマル-再構成のアドバイス

私は3台の1 TB HDDと3台の500GB HDDを持っています。現在、各サイズのグループ化はRAID 5にあり、どちらもLVMボリュームグループ（ストライプLV）にあります。

これは、小さなランダム書き込みでの使用には遅すぎると感じています。 RAIDレベルとLVMストライプレベルの両方でストライプサイズをいじり、ストライプキャッシュと先読みバッファサイズを増やしました。また、通常のアドバイスに従ってNCQを無効にしました。

これで、LinuxソフトウェアRAID 5は終了しました。専用のコントローラーがないと、私の目的には役立ちません。

別の1 TBドライブと別の500GBドライブを追加しているので、それぞれ4つです。

最高の小さなランダム書き込みパフォーマンスを得るために、8つのドライブをどのように構成しますか？もちろん、単純なRAID 0を除いて、このセットアップのポイントは明らかに冗長性のためでもあります。 4つの500GBディスクを2つのRAID0に配置し、それを他の4つのRAID10に追加することを検討しました。1TB HD、6ディスクRAID 10の場合）。これが最善の解決策です。

編集：ハードウェアのアップグレードのための予算はもうありません。私が本当に求めているのは、4つの1 TBドライブがRAID10であることが非常に簡単である限り、4x1TB RAID10に最適になるように4つの500GBドライブで何をするかです。冗長性やパフォーマンスの問題になることなく、私が持っていたもう1つのアイデアは、4つの500GBドライブすべてをRAID10にまとめ、LVMを使用して4x1TB RAID10でその容量を追加することでした。他に考えられることはありますか？

別の編集：既存の配列は次のようにフォーマットされます。

1 TB ext4 formatted lvm striped file share. Shared to two Macs via AFP.
1 500 GB lvm logical volume exported via iscsi to a Mac, formatted as HFS+. Used a Time Machine backup.
1 260 GB lvm logical volume exported via iscsi to a Mac, formatted as HFS+. Used as a Time Machine backup.
1 200 GB ext4 formatted lvm partition, used a disk device for a virtualised OS installtion.
An lvm snapshot of the 500 GB time machine backup.

私が試したことのないことの1つは、Time Machine LVをext4ファイルシステム上のファイルに置き換えることです（iscsiマウントがブロックデバイスではなくファイルを指すようにします）。速度の問題は解決できると思いますが、それらのパーティションのスナップショットを撮ることができなくなります。したがって、トレードオフの価値があるかどうかはわかりません。

将来的には、iPhotoとiTunesライブラリを別のHFS + iscsiマウント上のサーバーに移動する予定です。そのテストにより、非常識なランダム書き込みパフォーマンスに気づき始めました。

興味があれば、このURLのRaid Mathセクションの情報を使用しました： http://wiki.centos.org/HowTos/Disk_Optimization ext4のすべてをセットアップする方法を理解するために、パーティション（そしてその結果、優れたパフォーマンスが見られます）しかし、これはiscsi共有HFS +ボリュームには何の役にも立たないようです。

より多くの詳細：

 output of lvdisplay:

  --- Logical volume ---
  LV Name                /dev/array/data
  VG Name                array
  LV UUID                2Lgn1O-q1eA-E1dj-1Nfn-JS2q-lqRR-uEqzom
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                1.00 TiB
  Current LE             262144
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:0

  --- Logical volume ---
  LV Name                /dev/array/etm
  VG Name                array
  LV UUID                KSwnPb-B38S-Lu2h-sRTS-MG3T-miU2-LfCBU2
  LV Write Access        read/write
  LV snapshot status     source of
                         /dev/array/etm-snapshot [active]
  LV Status              available
  # open                 1
  LV Size                500.00 GiB
  Current LE             128000
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:1

  --- Logical volume ---
  LV Name                /dev/array/jtm
  VG Name                array
  LV UUID                wZAK5S-CseH-FtBo-5Fuf-J3le-fVed-WzjpOo
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                260.00 GiB
  Current LE             66560
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:2

  --- Logical volume ---
  LV Name                /dev/array/mappingvm
  VG Name                array
  LV UUID                69k2D7-XivP-Zf4o-3SVg-QAbD-jP9W-cG8foD
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                200.00 GiB
  Current LE             51200
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:3

  --- Logical volume ---
  LV Name                /dev/array/etm-snapshot
  VG Name                array
  LV UUID                92x9Eo-yFTY-90ib-M0gA-icFP-5kC6-Gd25zW
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/array/etm
  LV Status              available
  # open                 0
  LV Size                500.00 GiB
  Current LE             128000
  COW-table size         500.00 GiB
  COW-table LE           128000
  Allocated to snapshot  44.89% 
  Snapshot chunk size    4.00 KiB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:7


output of pvs --align -o pv_name,pe_start,stripe_size,stripes

PV         1st PE  Stripe  #Str
  /dev/md0   192.00k      0     1
  /dev/md0   192.00k      0     1
  /dev/md0   192.00k      0     1
  /dev/md0   192.00k      0     1
  /dev/md0   192.00k      0     0
  /dev/md11  512.00k 256.00k    2
  /dev/md11  512.00k 256.00k    2
  /dev/md11  512.00k 256.00k    2
  /dev/md11  512.00k      0     1
  /dev/md11  512.00k      0     1
  /dev/md11  512.00k      0     0
  /dev/md12  512.00k 256.00k    2
  /dev/md12  512.00k 256.00k    2
  /dev/md12  512.00k 256.00k    2
  /dev/md12  512.00k      0     0

output of cat /proc/mdstat

md12 : active raid5 sdc1[1] sde1[0] sdh1[2]
      976770560 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU]

md11 : active raid5 sdg1[2] sdf1[0] sdd1[1]
      1953521152 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU]



output of  vgdisplay:


--- Volume group ---
  VG Name               array
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  8
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               3
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               2.73 TiB
  PE Size               4.00 MiB
  Total PE              715402
  Alloc PE / Size       635904 / 2.43 TiB
  Free  PE / Size       79498 / 310.54 GiB
  VG UUID               PGE6Oz-jh96-B0Qc-zN9e-LKKX-TK6y-6olGJl



output of dumpe2fs /dev/array/data | head -n 100 (or so)

dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          /mnt/array/data
Filesystem UUID:          b03e8fbb-19e5-479e-a62a-0dca0d1ba567
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              67108864
Block count:              268435456
Reserved block count:     13421772
Free blocks:              113399226
Free inodes:              67046222
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      960
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              128
RAID stripe width:        128
Flex block group size:    16
Filesystem created:       Thu Jul 29 22:51:26 2010
Last mount time:          Sun Oct 31 14:26:40 2010
Last write time:          Sun Oct 31 14:26:40 2010
Mount count:              1
Maximum mount count:      22
Last checked:             Sun Oct 31 14:10:06 2010
Check interval:           15552000 (6 months)
Next check after:         Fri Apr 29 14:10:06 2011
Lifetime writes:          677 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      9e6a9db2-c179-495a-bd1a-49dfb57e4020
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x000059af
Journal start:            1




output of lvs array --aligned -o seg_all,lv_all

  Type    #Str Stripe  Stripe  Region Region Chunk Chunk Start Start SSize   Seg Tags PE Ranges                                       Devices                             LV UUID                                LV           Attr   Maj Min Rahead KMaj KMin KRahead LSize   #Seg Origin OSize   Snap%  Copy%  Move Convert LV Tags Log Modules 
  striped    2 256.00k 256.00k     0      0     0     0     0      0   1.00t          /dev/md11:0-131071 /dev/md12:0-131071           /dev/md11(0),/dev/md12(0)           2Lgn1O-q1eA-E1dj-1Nfn-JS2q-lqRR-uEqzom data         -wi-ao  -1  -1   auto 251  0      1.00m   1.00t    1             0                                                 
  striped    2 256.00k 256.00k     0      0     0     0     0      0 500.00g          /dev/md11:131072-195071 /dev/md12:131072-195071 /dev/md11(131072),/dev/md12(131072) KSwnPb-B38S-Lu2h-sRTS-MG3T-miU2-LfCBU2 etm          owi-ao  -1  -1   auto 251  1      1.00m 500.00g    1        500.00g                                        snapshot
  linear     1      0       0      0      0  4.00k 4.00k    0      0 500.00g          /dev/md11:279552-407551                         /dev/md11(279552)                   92x9Eo-yFTY-90ib-M0gA-icFP-5kC6-Gd25zW etm-snapshot swi-a-  -1  -1   auto 251  7      1.00m 500.00g    1 etm    500.00g  44.89                                 snapshot
  striped    2 256.00k 256.00k     0      0     0     0     0      0 260.00g          /dev/md11:195072-228351 /dev/md12:195072-228351 /dev/md11(195072),/dev/md12(195072) wZAK5S-CseH-FtBo-5Fuf-J3le-fVed-WzjpOo jtm          -wi-ao  -1  -1   auto 251  2      1.00m 260.00g    1             0                                                 
  linear     1      0       0      0      0     0     0     0      0 200.00g          /dev/md11:228352-279551                         /dev/md11(228352)                   69k2D7-XivP-Zf4o-3SVg-QAbD-jP9W-cG8foD mappingvm    -wi-a-  -1  -1   auto 251  3      1.00m 200.00g    1             0                                                 




cat /sys/block/md11/queue/logical_block_size 
512
cat /sys/block/md11/queue/physical_block_size 
512
cat /sys/block/md11/queue/optimal_io_size 
524288
cat /sys/block/md11/queue/minimum_io_size 
262144

cat /sys/block/md12/queue/minimum_io_size 
262144
cat /sys/block/md12/queue/optimal_io_size 
524288
cat /sys/block/md12/queue/logical_block_size 
512
cat /sys/block/md12/queue/physical_block_size 
512

編集：では、ここに何か問題があるかどうかは誰にもわかりませんか？具体的なアドバイスはありませんか？うーん。

linuxraid5raid10
2
RibaldEddie

申し訳ありませんが、RAID 5は、コントローラーに十分なキャッシュがない限り、小さな書き込みには常に適していません。チェックサムには多くの読み取りと書き込みがあります。

あなたの最良のベッドはハードウェアコントローラーのRAID10です-本当の悲鳴を上げるパフォーマンスのために、アダプテックのようなものを手に入れて、半分をドライブSSDにします....明らかに分割する必要があります。 Linuxソフトウェアが同じことを実行できるかどうかはわかりません。

残りは完全にあなたの使用パターンに依存します、そして基本的に-あなたは私たちにそれについて何も言わなかった。

4
TomTom

オプションA.）スペースが必要ですか？ 1TBドライブを500GBに「ショートストローク」して、8ディスクRAID10アレイを実行できます（2TBの使用可能スペース用）。あなたが言及していないので、私はそれらがすべて7200rpmのスピンドルであると仮定するつもりです、それであなたは毎秒〜400のランダムな書き込みを見ています。

それがあなたの最高のパフォーマンスオプションです、他のものはより良いハードウェアまたはraid0を必要とします。

オプションB.）1TBドライブの1つの4ディスクRAID10アレイ、500GBドライブの別の4ディスクアレイ、単純なlvmスパニング。これにより、一方に200のランダム書き込みIOPSが、もう一方に200のランダム書き込みIOPSが得られます。

オプションC.）すべてのドライブの最初の500GBの1つの8ディスクRAID10アレイ、次に1TBドライブの「バック」500GBの4ディスクRAID10アレイ、lvmスパン。これにより、VGの8ディスクセットセクションにいるときに、ピーク400のランダム書き込みIOPSが得られます。

アプリケーションについて実際には何も言わなかった。1つのシーケンシャルログ書き込みがCで最善である場合。少なくとも2つの並列書き込みスレッドに分割されている場合は、Bの単純さを好む（そして好まない）それらを一緒にlvmします）。

2
cagenut

RAIDとLVMの構成に加えて、別のディスクI/Oエレベータを試しましたか？ [〜＃〜] cfq [〜＃〜]は、最近の多くのディストリビューションのデフォルトのようであり、特定のワークロードでは問題ありません。私にとっては、2、3回ひどく噛まれました。たとえば、1台のバックアップサーバーが約20のホスト、合計で約3,000万のファイルと数テラバイトをバックアップすると、驚くほど遅くなり、I/Oに多くの時間がかかりました。

deadlineスケジューラーに切り替えた後、そのサーバーでのすべての操作は以前の約2倍の速度になりました。 OK、私の場合、ファイルシステムはXFSでした（そして今でもそうです...）。過去にはXFS + CFQコンボに落とし穴がありましたが、とにかく試してみる価値があります。

I/Oエレベータをその場で変更したい場合：

echo deadline >/sys/block/yourdisk/queue/scheduler

その変更を永続的にしたい場合は、grub.confのkernel行-または使用するブートローダー-パラメータelevator=deadlineに追加します。

anticipatoryおよびnoopスケジューラーを試すこともできます。

1
Janne Pikkarainen

RAID 5は、ディスクに書き込む前に各ドライブの各RAIDブロックを最初に読み取る必要があるため、小さな書き込みには本質的に適していません。ハードウェアコントローラーは、ディスクがシークするのを待つ必要がないバッテリーバックアップキャッシュを使用することで、これを回避します。このようなキャッシュは、RAID 5だけでなく、すべての小さな書き込みに役立ちますが、そこでは特に役立ちます。

ただし、解決策がある可能性があります。ファイルシステムを切り替えてデータをジャーナル化してみてください。

tune2fs -o journal_data /dev/md0

（それは明らかにext3用です）

ジャーナルのサイズを大きくすることもできます。ジャーナリングに別のデバイスを使用すると、さらに速く進むことができます。通常、システムにRAID 1があり、データに大きなRAID 5がある場合は、最初にボリュームを予約します。そうすれば、半分のシークが必要になるため、ジャーナルのコミットがはるかに高速になります。 （これを行う方法の詳細については、man tune2fs）

重要な注意：私はこれをテストしていません。動作するはずですが、理論的に可能なほど多くの利点が得られない可能性もあります。

1
niXar