Я настраиваю сервер для небольшой, но читаемой базы данных с интенсивным вводом-выводом. Он служит главным индексом для общего доступа к более крупной базе данных Oracle RAC. При рассмотрении требований к вводу-выводу было определено, что массив твердотельных накопителей обеспечит требуемую производительность при более низкой стоимости, чем большое количество шпинделей SAS 15K. У меня есть сервер HP с Smart Array P400, который будет подключен только к твердотельным накопителям. Контроллер имеет 256 МБ BBWC. Твердотельные накопители - это (я полагаю) Samsung производства SLC на 60 Гбайт 2,5 "SATA.
Мне интересно, есть ли у кого-нибудь представление о лучших размерах полос для RAID 10 или 5, рекомендации по файловой системе? Мы собираемся делать Oracle 11g, поэтому я считаю, что мне нужна файловая система, а не блочное устройство RAW. Сервер будет работать под управлением RHEL 5.5.
За последние несколько месяцев я много читал о твердотельных накопителях, и я не против того, чтобы сделать намного больше, но мой гугл-фу начал подводить меня в продвижении вперед. Большинство документов, которые я нахожу по SSD RAID, предназначены для людей, использующих RAID 0 для твердотельных накопителей потребительского уровня для загрузочного диска на своем домашнем компьютере, чтобы ускорить загрузку Windows 7 и игры. Я говорю о том, что я не ищу кого-то для выполнения моей работы, просто предоставлю любой опыт, который у них был, или ссылку на документ, который они где-то нашли.
Заранее спасибо!
ИЗМЕНИТЬ для получения дополнительной информации, а не отвечать на каждый отдельный комментарий:
Место на диске не вызывает проблем, поскольку база данных достаточно мала, чтобы без проблем поместиться на одном из твердотельных накопителей.
Поскольку я очень много читал БД (95% + случайное чтение в 4-8k), я подумал, что могу получить лучшую производительность от RAID 5 только потому, что я могу читать с дисков N-1 в массиве, а не только с активных дисков в зеркало, поскольку я читал вещи, указывающие на то, что Smart Array P400 не поддерживает чтение с обеих сторон зеркала в наборе RAID 10. Тем не менее, я вполне уверен, что контроллер станет узким местом, прежде чем мне придется беспокоиться об этом.
О TRIM: я вполне уверен, что даже если бы эти диски поддерживали TRIM (я не верю, что они поддерживают), было бы довольно сложно передать команды TRIM через контроллер RAID на отдельные диски. Поддержка ОС также сомнительна, поскольку Red Hat Enterprise Linux 5 по-прежнему основан на дереве ядра 2.6.18, хотя и с большим количеством настроек для включения функций из более поздних выпусков ядра. EXT4 также официально не поддерживается, и, будучи производственным устройством, мне нужно оставаться в той сфере, где Red Hat и HP помогут мне, если что-то пойдет не так. Тем не менее, я верю, что на уровне дисков происходит какая-то сборка мусора. Я заполнял диски несколько раз в ходе различных тестов и не заметил заметного снижения скорости записи, которого я ожидал бы, если бы мне пришлось ждать цикла стирания / программирования, а не только цикла программирования.
Вот некоторые эталонные данные для массива RAID 10 с 6 дисками с размером полосы 256 КБ. Раздел - EXT3, выровнен по 64 секторам. Используется планировщик NOOP, и опция NOATIME задается при монтировании. Я также увеличил кэш чтения ОС до 8 МБ (я считаю, что по умолчанию 512 КБ). Я использовал Iozone 3.347 для этого теста с размером записи 4 КБ и размером файла теста 25 ГБ, чтобы, надеюсь, убрать кэш из изображения и измерить фактическую производительность дисков. Я также запустил это с четырьмя потоками (файлы 4x25GB записываются 4 дочерними процессами для нагрузки на диск).
Начало забега: Пн 30 авг 12:09:57 2010
Record Size 4 KB
File size set to 26214400 KB
Command line used: /opt/iozone/bin/iozone -b /root/4k25g4t.xls -r 4k -s 25g -t 4 -i 0 -i 1 -i 2
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 4 processes
Each process writes a 26214400 Kbyte file in 4 Kbyte records
Children see throughput for 4 initial writers = 253416.93 KB/sec
Parent sees throughput for 4 initial writers = 229461.66 KB/sec
Min throughput per process = 61416.07 KB/sec
Max throughput per process = 64604.90 KB/sec
Avg throughput per process = 63354.23 KB/sec
Min xfer = 24924492.00 KB
Children see throughput for 4 rewriters = 259375.90 KB/sec
Parent sees throughput for 4 rewriters = 234136.11 KB/sec
Min throughput per process = 63879.16 KB/sec
Max throughput per process = 65675.30 KB/sec
Avg throughput per process = 64843.97 KB/sec
Min xfer = 25497648.00 KB
Children see throughput for 4 readers = 490873.09 KB/sec
Parent sees throughput for 4 readers = 490830.09 KB/sec
Min throughput per process = 119007.65 KB/sec
Max throughput per process = 124878.35 KB/sec
Avg throughput per process = 122718.27 KB/sec
Min xfer = 24984912.00 KB
Children see throughput for 4 re-readers = 477533.65 KB/sec
Parent sees throughput for 4 re-readers = 477503.03 KB/sec
Min throughput per process = 115802.55 KB/sec
Max throughput per process = 121579.46 KB/sec
Avg throughput per process = 119383.41 KB/sec
Min xfer = 24973364.00 KB
Children see throughput for 4 random readers = 35728.62 KB/sec
Parent sees throughput for 4 random readers = 35728.53 KB/sec
Min throughput per process = 8926.97 KB/sec
Max throughput per process = 8937.35 KB/sec
Avg throughput per process = 8932.16 KB/sec
Min xfer = 26183936.00 KB
Children see throughput for 4 random writers = 23527.42 KB/sec
Parent sees throughput for 4 random writers = 20701.37 KB/sec
Min throughput per process = 5757.43 KB/sec
Max throughput per process = 6035.68 KB/sec
Avg throughput per process = 5881.86 KB/sec
Min xfer = 25011236.00 KB
"Throughput report Y-axis is type of test X-axis is number of processes"
"Record size = 4 Kbytes "
"Output is in Kbytes/sec"
" Initial write " 253416.93
" Rewrite " 259375.90
" Read " 490873.09
" Re-read " 477533.65
" Random read " 35728.62
" Random write " 23527.42
Некоторые моменты, которые я пока не увидел в других ответах:
В целом SSD примерно в 100 раз быстрее дисков SAS при произвольном вводе-выводе. Еще немного. В зависимости от ваших требований вполне возможно заменить RAID 10 SAS на RAID 5 SSD и при этом значительно опередить - как по IOPS, так и по цене.
Оптимальный размер полосы, как правило, кратен 64 КБ, особенно когда SSD читает / записывает в этих сегментах. Тогда TRIM не обязательно нужен (без частичной записи) ... но было бы неплохо иметь это.
У MS есть несколько папок на SSD в базах данных, которые также применимы к oracle (тот же принцип - оптимизация IOPS). У Oracle тоже должно быть немного.
RAID-10 был бы идеальным.
Учитывая, что стоимость типичного твердотельного накопителя Intel SLC 64 ГБ составляет около 700 долларов, вам понадобится 4 из них для создания RAID-10, в то время как 64 ГБ ОЗУ DDR3 Registered ECC стоят около 1600 долларов (если вы не покупаете его у Dell) Возможно, разумнее было приобрести оперативную память, которая работает быстрее и прослужит намного дольше, чем любой SSD.
Идея заключалась бы в том, чтобы разместить всю базу данных в ОЗУ, если размер вашей базы данных плюс ее индексы не превышают 64 ГБ.
Я не вижу проблемы, так как даже с R5 / R6 вы получаете безумную сумму более 15 тысяч SAS. Подумывал сделать массив R6 22 SSD +2 для горячего резерва.
Эта ссылка содержит хорошее резюме и рекомендации для Raid 10: http://www.yonahruss.com/architecture/raid-10-vs-raid-5-performance-cost-space-and-ha.html
Raid 5 обычно не рекомендуется. У него странные характеристики для пишущих приложений. Я бы выбрал Raid 10. Я не знаю, что касается размеров полос, но не уверен, что это будет иметь большое значение.
Убедитесь, что ваш дистрибутив Linux поддерживает TRIM для SSD. Похоже, вам нужно ядро: Linux 2.6.33 и Ext4.
Используйте RAID10, если вам не нужно дисковое пространство, которое может предоставить RAID5. В большинстве случаев вы получите лучшую производительность от RAID10.
Как сказала Амала, убедитесь, что диски и ОС поддерживают TRIM. Используйте размер полосы, который согласуется с размером блока ОС (64 КБ - довольно распространенное явление для серверов БД), и убедитесь, что раздел смещен в несколько раз больше (смещение в 1 МБ довольно часто).