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
編集：では、ここに何か問題があるかどうかは誰にもわかりませんか？具体的なアドバイスはありませんか？うーん。
申し訳ありませんが、RAID 5は、コントローラーに十分なキャッシュがない限り、小さな書き込みには常に適していません。チェックサムには多くの読み取りと書き込みがあります。
あなたの最良のベッドはハードウェアコントローラーのRAID10です-本当の悲鳴を上げるパフォーマンスのために、アダプテックのようなものを手に入れて、半分をドライブSSDにします....明らかに分割する必要があります。 Linuxソフトウェアが同じことを実行できるかどうかはわかりません。
残りは完全にあなたの使用パターンに依存します、そして基本的に-あなたは私たちにそれについて何も言わなかった。
オプション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します）。
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スケジューラーを試すこともできます。
RAID 5は、ディスクに書き込む前に各ドライブの各RAIDブロックを最初に読み取る必要があるため、小さな書き込みには本質的に適していません。ハードウェアコントローラーは、ディスクがシークするのを待つ必要がないバッテリーバックアップキャッシュを使用することで、これを回避します。このようなキャッシュは、RAID 5だけでなく、すべての小さな書き込みに役立ちますが、そこでは特に役立ちます。
ただし、解決策がある可能性があります。ファイルシステムを切り替えてデータをジャーナル化してみてください。
tune2fs -o journal_data /dev/md0
（それは明らかにext3用です）
ジャーナルのサイズを大きくすることもできます。ジャーナリングに別のデバイスを使用すると、さらに速く進むことができます。通常、システムにRAID 1があり、データに大きなRAID 5がある場合は、最初にボリュームを予約します。そうすれば、半分のシークが必要になるため、ジャーナルのコミットがはるかに高速になります。 （これを行う方法の詳細については、man tune2fs）
重要な注意：私はこれをテストしていません。動作するはずですが、理論的に可能なほど多くの利点が得られない可能性もあります。