У меня 3 жестких диска по 1 ТБ и 3 жестких диска по 500 ГБ. Сейчас каждая группа размеров находится в RAID 5, оба из которых находятся в группе томов LVM (с чередующимися LV).
Я считаю, что это слишком медленно для моего использования при небольших случайных записях. Я повозился с размерами полос как на уровне RAID, так и на уровне полос LVM, а также с увеличением размера полосового кеша и буфера чтения. Я также отключил NCQ по обычному совету.
Итак, я закончил с программным рейдом Linux 5. Без выделенного контроллера он бесполезен для моих целей.
Я добавляю еще один диск на 1 ТБ и еще один диск на 500 ГБ, так что по 4 каждого.
Как бы вы сконфигурировали восемь дисков, чтобы добиться максимальной производительности при произвольной записи небольших объемов данных? Исключая, конечно, простой RAID 0, так как цель этой настройки, очевидно, также предназначена для избыточности. Я подумал о том, чтобы поместить 4 диска по 500 ГБ в 2 RAID 0, а затем добавить это к RAID 10 из других 4 жестких дисков емкостью 1 ТБ для 6-дискового RAID 10, но я не уверен, что это лучшее решение. Что скажешь?
Изменить: больше нет бюджета на обновление оборудования. Я действительно спрашиваю, поскольку четыре диска по 1 ТБ могут быть довольно просто RAID 10, что мне делать с четырьмя дисками по 500 ГБ, чтобы они лучше всего подходили для RAID 10 4x1 ТБ, не создавая проблем с избыточностью или производительностью? Другая идея заключалась в том, чтобы объединить в RAID 10 все четыре диска по 500 ГБ вместе, а затем использовать LVM для добавления этой емкости с RAID10 4x1TB. Вы можете придумать что-нибудь получше?
Другое редактирование: существующий массив отформатирован следующим образом:
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.
Одна вещь, которую я не пробовал, - это заменить LV Time Machine файлом в файловой системе ext4 (чтобы точка монтирования iscsi указывала на файл, а не на блочное устройство). У меня есть чувство, что это решит мои проблемы со скоростью, но это не позволит мне делать снимки этих разделов. Так что я не уверен, что это стоит того.
В будущем я намерен переместить библиотеку iPhoto и iTunes на сервер на другом монтировании HFS + iscsi, при тестировании которого я начал замечать бессмысленную производительность произвольной записи.
Если вам интересно, я использовал информацию из раздела Raid Math этого URL: http://wiki.centos.org/HowTos/Disk_Optimization чтобы выяснить, как настроить все для раздела ext4 (и в результате я вижу отличную производительность на нем), однако это, похоже, не принесло пользы для общих томов HFS + iscsi.
Намного подробнее:
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 ВСЕГДА плох для небольших записей, если у контроллера нет большого количества кеша. Для контрольной суммы выполняется множество операций чтения и записи.
Лучшая кровать - это Raid 10 на аппаратном контроллере - для НАСТОЯЩЕЙ кричащей производительности возьмите что-то вроде Adaptec и сделайте ПОЛОВИНУ дисков SSD .... таким образом все операции чтения будут идти на SSD, который даст вам тонну производительности там, хотя и пишет очевидно должны быть разделены. Не уверен, что программное обеспечение Linux может делать то же самое.
Остальное полностью зависит от вашей схемы использования, и в основном - вы нам ничего об этом не сказали.
Вариант А.) Вам нужно место? Вы можете «сократить» диски емкостью 1 ТБ до 500 ГБ и запустить массив RAID10 с 8 дисками (для 2 ТБ полезного пространства). Поскольку вы не упомянули, я предполагаю, что все они шпиндели со скоростью вращения 7200 об / мин, так что вы смотрите на ~ 400 случайных операций записи в секунду.
Это ваш лучший вариант производительности, для всего остального потребуется лучшее оборудование или raid0.
Вариант Б.) Один 4-дисковый массив RAID10 из дисков 1 ТБ, другой 4-дисковый массив из дисков 500 ГБ, простое объединение lvm. Это дает 200 случайных операций ввода-вывода в секунду для одного и 200 операций ввода-вывода в случайном порядке записи на другом.
Вариант C.) Один 8-дисковый массив RAID10 из первых 500 ГБ всех дисков, затем 4-дисковый массив RAID10 из «задних» 500 ГБ дисков по 1 ТБ, охватываемый lvm. Это даст пиковое значение 400 операций произвольной записи в секунду, когда вы находитесь в разделе VG с набором из 8 дисков.
Вы не сказали нам ничего о приложении, если его один последовательный журнал записывает, вам лучше всего использовать C.Если оно разбито по крайней мере на два параллельных потока записи, я бы предпочел простоту B (и не lvm их вместе).
В дополнение к настройке RAID и LVM, пробовали ли вы другой лифт дискового ввода-вывода? CFQ в настоящее время кажется, что это значение по умолчанию для многих дистрибутивов, и для определенных рабочих нагрузок это нормально. Меня это сильно укусило пару раз - например, один резервный сервер, на котором было создано резервное копирование около 20 хостов, всего около 30 миллионов файлов и несколько терабайт, был на удивление медленным, а ввод-вывод занимал много времени.
После того, как я перешел на крайний срок планировщик, все операции на этом сервере стали примерно вдвое быстрее, чем раньше. Хорошо, в моем случае файловая система была (и остается ...) XFS, а в прошлом у комбинации XFS + CFQ были свои подводные камни, но все равно попробовать стоит.
Если вы хотите изменить лифт ввода / вывода на лету:
echo deadline >/sys/block/yourdisk/queue/scheduler
Если вы хотите сделать это изменение постоянным, добавьте в ядро строка в вашем grub.conf - или любой другой загрузчик, который вы используете - параметр elevator=deadline.
Вы также можете попробовать anticipatory и noop планировщики.
Raid 5 по своей сути плох для небольших операций записи, потому что он должен сначала прочитать каждый raid-блок на каждом диске перед записью на диск. Аппаратные контроллеры решают эту проблему, имея кэш с резервным питанием от батареи, что позволяет избежать ожидания поиска дисков. Такой кеш поможет при любой небольшой записи, не только в Raid 5, но там он особенно полезен.
Однако может быть решение: попробуйте переключить файловую систему на журналирование данных:
tune2fs -o journal_data /dev/md0
(Очевидно, это для ext3)
Вы также можете увеличить размер журнала. Вы можете пойти еще быстрее, используя другое устройство для ведения журнала. Обычно, если у вас есть Raid 1 для вашей системы и большой Raid 5 для данных, зарезервируйте том на первом; таким образом фиксация журнала будет намного быстрее, так как для этого потребуется вдвое меньше поисков. (man tune2fs для получения дополнительной информации о том, как это сделать)
Важное примечание: я не тестировал это. Он должен работать, но также возможно, что он не дает столько преимуществ, сколько теоретически.