Поможет ли добавление 2-го RAID-контроллера увеличить производительность?
Всем доброго дня! Наверное, очень простой вопрос, но всё же буду рад подсказкам и советам. Есть вот, скажем, хост, у которого 16 SSD-накопителей WDC WDS100T1B0A-00H9H0, они все подключены к контроллеру AVAGO 3108 MegaRAID и работают в RAID10. Есть достаточно свирепая нагрузка, создаваемая несколькими дюжинами виртуалок. И есть желание увеличить производительность дисковой подсистемы. Обычно iostat даёт что-то типа вот такого: Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 11.00 0.00 1186.00 205.00 96398.00 11464.00 77.54 4.66 3.17 2.90 4.74 0.72 99.90 dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 9.00 0.00 72.00 0.00 8.00 0.07 7.33 7.33 0.00 7.33 6.60 dm-2 0.00 0.00 1188.00 209.00 95688.00 11539.00 76.76 5.46 3.73 3.57 4.65 0.72 100.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 45.00 1.00 660.00 310.00 65892.00 23484.00 92.14 5.67 5.71 4.91 7.41 1.03 100.10 dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 40.00 0.00 320.00 0.00 8.00 2.14 53.60 53.60 0.00 4.25 17.00 dm-2 0.00 0.00 667.00 308.00 66474.00 23425.00 92.20 6.22 6.17 5.45 7.72 1.03 100.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 21.00 308.00 628.00 696.00 89385.00 44079.00 100.80 6.25 4.95 5.29 4.65 0.75 99.90 dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 14.00 313.00 112.00 2504.00 8.00 22.95 70.17 57.93 70.72 0.79 25.70 dm-2 0.00 0.00 633.00 692.00 88881.00 41695.00 98.55 6.47 5.16 6.25 4.16 0.75 100.00 Иногда, когда нагрузка становится немного меньше, это выглядит примерно так (я, кстати, так и не понял, почему иногда %util равен 100%, но количество операций, вроде, даже несколько меньше, чем когда %util явно ниже): Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 26.00 393.00 618.00 677.00 96618.00 50869.00 113.89 3.30 2.69 2.96 2.44 0.64 82.50 dm-0 0.00 0.00 7.00 0.00 128.00 0.00 18.29 0.02 3.14 3.14 0.00 1.57 1.10 dm-1 0.00 0.00 29.00 399.00 232.00 3192.00 8.00 14.59 34.09 45.41 33.27 0.53 22.50 dm-2 0.00 0.00 605.00 668.00 95362.00 47493.00 112.22 2.92 2.44 2.78 2.13 0.65 82.40 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 43.00 550.00 621.00 244.00 146329.00 10989.00 181.87 1.25 1.43 1.19 2.03 0.75 64.90 dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 40.00 561.00 320.00 4488.00 8.00 11.63 19.34 10.85 19.95 0.18 10.60 dm-2 0.00 0.00 628.00 233.00 146585.00 6501.00 177.80 1.07 1.22 1.24 1.18 0.72 61.80 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 62.00 172.00 707.00 316.00 113067.00 10133.00 120.43 3.96 3.61 3.02 4.94 0.83 84.70 dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 123.00 181.00 984.00 1448.00 8.00 17.45 55.71 8.26 87.96 0.91 27.80 dm-2 0.00 0.00 644.00 312.00 111699.00 8727.00 125.97 3.20 3.13 3.45 2.47 0.86 82.10 Как считаете, будет ли разумно добавить ещё один RAID-контроллер и перебросить половину накопителей на него, а оба RAID10 объединить уже в один LVM на уровне операционки, даст ли это какой-то существенный прирост производительности? Заранее благодарен за подсказки! -- V.Melnik
На самом железном хосте, что крутится? Виртуалки на нем же или по NFS?
On Fri, Dec 23, 2016 at 12:56:45PM +0200, Andrii Stesin wrote:
На самом железном хосте, что крутится? Виртуалки на нем же или по NFS?
Там CentOS-6.8, образы дисков живут там же, на /dev/sda. Всё никак не могу понять, как выкупить, дело в ограниченной пропускной способности PCI, RAID-контроллера или самих дисков. Статистика, которую даёт контроллер, мягко говоря, не шибко-то информативна. Насчёт дисков немножко сомневаюсь, что затык в них, кстати. Почему - потому что одна половина от этих виртуалок до того жила на хосте с 4-мя SSD-накопителями в RAID10, вторая - на похожем хосте с 4-мя похожими накопителями в RAID10. Оба хоста чувствовали заметно более уверенно в этой жизни. В хосте, на который переехали эти виртуалки, 16 накопителей, стало быть - нагрузка на каждый из них теоретически стала в 2 раза меньше. Потому и думаю, что, возможно, если я разделю диски между 2-мя контроллерами и затем объединю оба диска в один LVM, производительность хранилища радикально возрастёт. Только нет уверенности, вот и интересуюсь, вдруг кто имел подобный опыт. -- V.Melnik
Я пришел к выводу, что все современные контролеры (брали на тест
несколько Adaptec, и LSI) очень плохо работают с большим количеством
SSD. Почему, так и не удалось понять. Может они не рассчитаны на такую
низкую latency. Может еще что.
Оптимально получилось использовать набортные 6 SATA + простенькие
контроллеры на 4 диска (часто на серверных материнках сразу делают 6
базовых + 4 доп. контроллер на материнке),
И софтварный raid на SSD по всегда получался быстрее аппаратного.
23 декабря 2016 г., 15:41 пользователь Vladimir Melnik
On Fri, Dec 23, 2016 at 12:56:45PM +0200, Andrii Stesin wrote:
На самом железном хосте, что крутится? Виртуалки на нем же или по NFS?
Там CentOS-6.8, образы дисков живут там же, на /dev/sda.
Всё никак не могу понять, как выкупить, дело в ограниченной пропускной способности PCI, RAID-контроллера или самих дисков. Статистика, которую даёт контроллер, мягко говоря, не шибко-то информативна.
Насчёт дисков немножко сомневаюсь, что затык в них, кстати. Почему - потому что одна половина от этих виртуалок до того жила на хосте с 4-мя SSD-накопителями в RAID10, вторая - на похожем хосте с 4-мя похожими накопителями в RAID10. Оба хоста чувствовали заметно более уверенно в этой жизни. В хосте, на который переехали эти виртуалки, 16 накопителей, стало быть - нагрузка на каждый из них теоретически стала в 2 раза меньше. Потому и думаю, что, возможно, если я разделю диски между 2-мя контроллерами и затем объединю оба диска в один LVM, производительность хранилища радикально возрастёт. Только нет уверенности, вот и интересуюсь, вдруг кто имел подобный опыт.
-- V.Melnik
On Fri, Dec 23, 2016 at 03:59:22PM +0200, Serge Negodyuck wrote:
Я пришел к выводу, что все современные контролеры (брали на тест несколько Adaptec, и LSI) очень плохо работают с большим количеством SSD. Почему, так и не удалось понять. Может они не рассчитаны на такую низкую latency. Может еще что. Оптимально получилось использовать набортные 6 SATA + простенькие контроллеры на 4 диска (часто на серверных материнках сразу делают 6 базовых + 4 доп. контроллер на материнке),
И софтварный raid на SSD по всегда получался быстрее аппаратного.
Для LSI нужен Fastpath (раньше это был отдельный feature license key, последнее время часто сразу включен). Без него было совсем плохо. Ну и 16-ю SSD вполне можно забить PCIe шину, в зависимости от их скорости и версии/рядности шины. --igor
23 декабря 2016 г., 15:41 пользователь Vladimir Melnik
написал: On Fri, Dec 23, 2016 at 12:56:45PM +0200, Andrii Stesin wrote:
На самом железном хосте, что крутится? Виртуалки на нем же или по NFS?
Там CentOS-6.8, образы дисков живут там же, на /dev/sda.
Всё никак не могу понять, как выкупить, дело в ограниченной пропускной способности PCI, RAID-контроллера или самих дисков. Статистика, которую даёт контроллер, мягко говоря, не шибко-то информативна.
Насчёт дисков немножко сомневаюсь, что затык в них, кстати. Почему - потому что одна половина от этих виртуалок до того жила на хосте с 4-мя SSD-накопителями в RAID10, вторая - на похожем хосте с 4-мя похожими накопителями в RAID10. Оба хоста чувствовали заметно более уверенно в этой жизни. В хосте, на который переехали эти виртуалки, 16 накопителей, стало быть - нагрузка на каждый из них теоретически стала в 2 раза меньше. Потому и думаю, что, возможно, если я разделю диски между 2-мя контроллерами и затем объединю оба диска в один LVM, производительность хранилища радикально возрастёт. Только нет уверенности, вот и интересуюсь, вдруг кто имел подобный опыт.
-- V.Melnik
Я бы поступил так. 1. Нафиг RAID-контроллеры. Честный топовый HBA, типа https://www.broadcom.com/products/storage/host-bus-adapters/sas-9305-16i но это модно дорого, может достаточно не 12Gbps модели, а 6Gbps 2. ZFS, 16 x SSD например собрать в два массива raidz2 по 8 в каждом, конкатенировать в один том 3. Настроить загрузку системы с этого самого ZFS volume который two concatenated raidz2 vdevs PROFIT
до фени эти все контроллеры, если не будет трим-а, все эти гигабиты - все
до фени
23 декабря 2016 г., 22:01 пользователь Andrii Stesin
Я бы поступил так.
1. Нафиг RAID-контроллеры. Честный топовый HBA, типа https://www.broadcom.com/products/storage/host-bus-adapters/sas-9305-16i но это модно дорого, может достаточно не 12Gbps модели, а 6Gbps
2. ZFS, 16 x SSD например собрать в два массива raidz2 по 8 в каждом, конкатенировать в один том
3. Настроить загрузку системы с этого самого ZFS volume который two concatenated raidz2 vdevs
PROFIT
Всем привет,
В этом ворклоаде для garbage collect не будет времени - тримы просто будут игнорироваться.
Тут нужны другие устройства с другим ценником (которым btw трим пофиг - у меня есть таких в хозяйстве - 0.5Пб записано уже и стёрлось 7%). Почему-то топик стартер считает себя умнее маркетологов на рынке SSD - это большое заблуждение. А для данных - фатальное.
Сдохнут эти SSD очень неожиданно. И, из-за того, что получают линейный ворклоад в Raid10 - одновременно. Выглядеть это будет ржачно - херась, всё зависло. Ты такой на IPMI, жамкаешь ребут, а оно после ребута не видит ни одной SSD. Оживить дату не выйдет too
C выходными вас всех, бггг :-)
--- Оригінальне повідомлення ---
Від кого: "Vasiliy P. Melnik"
до фени эти все контроллеры, если не будет трим-а, все эти гигабиты - все до фени
23 декабря 2016 г., 22:01 пользователь Andrii Stesin
написал: Я бы поступил так.
1. Нафиг RAID-контроллеры. Честный топовый HBA, типа https://www.broadcom.com/products/storage/host-bus-adapters/sas-9305-16i
но это модно дорого, может достаточно не 12Gbps модели, а 6Gbps
2. ZFS, 16 x SSD например собрать в два массива raidz2 по 8 в каждом,
конкатенировать в один том
3. Настроить загрузку системы с этого самого ZFS volume который two
concatenated raidz2 vdevs
PROFIT
23 декабря 2016 г., 22:37 пользователь Vladimir Sharun < vladimir.sharun@ukr.net> написал:
Всем привет,
В этом ворклоаде для garbage collect не будет времени - тримы просто будут игнорироваться. Тут нужны другие устройства с другим ценником (которым btw трим пофиг - у меня есть таких в хозяйстве - 0.5Пб записано уже и стёрлось 7%). Почему-то топик стартер считает себя умнее маркетологов на рынке SSD - это большое заблуждение. А для данных - фатальное.
Конечно мое личное мнение, но если не хватает времени на трим, то что-то в этой сказочке не так, ибо даже по одному диску скорость работы нормального ссд-эшника больше стандартного гигабита минимум в 4 раза. Тут уже машина банально не будет справляться с обработкой этого потока данных
Всем привет,
Конечно мое личное мнение, но если не хватает времени на трим, то что-то в этой сказочке не так, ибо даже по одному диску скорость работы нормального ссд-эшника больше стандартного гигабита минимум в 4 раза. Тут уже машина банально не будет справляться с обработкой этого потока данных
Это теоретически или практически ?
23 декабря 2016 г., 23:38 пользователь Vladimir Sharun < vladimir.sharun@ukr.net> написал:
Всем привет,
Конечно мое личное мнение, но если не хватает времени на трим, то что-то в этой сказочке не так, ибо даже по одному диску скорость работы нормального ссд-эшника больше стандартного гигабита минимум в 4 раза. Тут уже машина банально не будет справляться с обработкой этого потока данных
Это теоретически или практически ?
Теоретически и логически. Если не хватает времени на трим, в таком случае система работает на максимально возможной скорости, вырост нагрузкки 10% ее полностью похоронит. Без трима скорость падет минимум в два раза - это тоже теоретически
Всем привет,
Практически, при невозможности трима (mixed load на чтение/запись, постоянная запись - например log mssql'я), скорость от "маркетинговой" падает совсем не в два раза, а хорошо если только в десять. И это надо не забывать, что картину маслом будет портить требование bio_flush как от ОС, так и от аппликух.
Т.е. вместо заявленных 50-70k iops записи хорошо если останется пара тысяч: на практике и их не будет. Under pressure даже топовые серверные, которым трим фиолетов, с собственным скрытым overprovisioning'ом, дают единицы тысяч iops. А вы про консьюмерские.
--- Оригінальне повідомлення ---
Від кого: "Vasiliy P. Melnik"
Конечно мое личное мнение, но если не хватает времени на трим, то что-то в этой сказочке не так, ибо даже по одному диску скорость работы нормального ссд-эшника больше стандартного гигабита минимум в 4 раза. Тут уже машина банально не будет справляться с обработкой этого потока данных
Это теоретически или практически ? Теоретически и логически. Если не хватает времени на трим, в таком случае система работает на максимально возможной скорости, вырост нагрузкки 10% ее полностью похоронит. Без трима скорость падет минимум в два раза - это тоже теоретически
Тезис о якобы "невозможности трима" меня как-то хм, удивляет и даже где-то умиляет. Чего бы вдруг. Надо ж понимать, что ZFS - умная штука, в отличие от дубовых RAID-контроллеров. В моем опыте переход с аппаратного RAID на ZFS визуально выглядел так, что полка дисков, которая до перехода постоянно горела огоньками дисковой активности ровно, как новогодняя елка, после перехода на ZFS стоит с темной мордой, а огоньки активности по ней раз в 5 секунд пробегают по морде полки бегущей волной ;) Эффект сравним с тем, когда в 90-х переводили машины с SCO на BSD. Там где SysV захлебывался дисковым дрочением, BSD только слегка и изредка помигивал дисками ;) велике полегшення нас тоді спіткало. Другой вопрос что если брать дешевые и заменимые устройства емкостью около 1Тб, типа http://hotline.ua/computer/diski-ssd/66705-9376-110252/ то надо понимать, что этих кошек надо уметь готовить и не надо жадничать. Прежде всего, чтобы декстопный SSD ставить под круглосуточную работу, надо принять волевое решение и давать им всем overcommit 20% сверх заводского. Подробности см. тут: https://www.thomas-krenn.com/en/wiki/Optimize_SSD_Performance и ОСОБЕННО вот тут: https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm То есть исходя из того, что дешевые SSD это расходник, а емкость того, что можно просто пойти-и-купить в любой момент, можно принять в диапазоне 960-1000 Гб, перед сборкой их в массив им всем полезно ограничить видимую системе емкость например до 800 Гб, проведя описанные во второй статье процедуры. Ну и как уже говорилось, никаких RAID - честный HBA и ZFS raidz2. Памяти коробке добавить, под ZFS ARC шоб нормально себя чувствовал и не теснился. И куды оно денется, с trim и с overprovisioning вместе, будет работать. Ну будут дешевые SSD периодически вылетать, пошел купил новый на 960 любой ближайший, точно так же приготовил эту кошку, заменил в полке и дальше полетели, ZFS сам разберется. Вот как-то так.
Привет,
Про trim и почему это не панацея и почему это может не работать и т.д.:
https://forums.freebsd.org/threads/56951/#post-328912
--- Оригінальне повідомлення ---
Від кого: "Andrii Stesin"
Все это он сказал верно и прекрасно с ровно одной оговоркой: в тексте
Theodore Ts'o НЕ ИДЕТ РЕЧЬ О ZFS - и тем не менее, вопрос легко
решается на ext4 например, читаем: on Linux the recommended way to use
TRIM is to use the fstrim command run out of cron, ... typically once
a week is plenty; some people will go every night, or even once a
month, since it is very workload dependent. ... this has nothing to do
with a particular file system or OS implementation, but is much more
about fundamental issues of how storage devices respond to TRIM
commands, so what is best practice for Linux would also be a good
thing to do on FreeBSD
Но надо понимать, что ZFS это такая отдельная интересная избушка, в
которой погремушки ну вот совершенно свои, не такие как.
Надо впрочем отметить, что я ZFS хорошо понимаю на FreeBSD и FreeNAS,
а на линуксах я ее юзал буквально на 4 не то 5 машинах всего, тут у
меня опыта поменее. Но я не предполагаю, что ситуация как-то может
отличаться, потому что в FreeBSD еще в 2014 (!!!) году писали на
форуме FreeNAS, цитирую: Trim on zfs ssds is supported starting with
freebsd 9.2 and it is enabled by default. Freenas 9.2.1.3 is already
on freebsd 9.2p3. So you will be ok. А сейчас в ходу уже FreeNAS
9.10-STABLE, и в линуксе ZFS тоже на месте ж не стоит.
Надо конечно уточнить для профилактики, но с вероятностью 99% я
предполагаю, что ZFS на линуксе тоже корректно отрабатывает TRIM.
2016-12-24 10:35 GMT+02:00 Vladimir Sharun
Привет,
Про trim и почему это не панацея и почему это может не работать и т.д.: https://forums.freebsd.org/threads/56951/#post-328912
И собственно, наличие в промежутке между ОС и SSD дурацкого
RAID-контроллера (а не честного HBA) - вот оно именно и вносит элемент
непредсказуемости в ситуацию. Иди его угадай, что эта дурная хреновина
делает, получая TRIM на свой псевдодиск. Нэ нада RAID, вот серьезно
говорю.
2016-12-24 11:01 GMT+02:00 Andrii Stesin
Все это он сказал верно и прекрасно с ровно одной оговоркой: в тексте Theodore Ts'o НЕ ИДЕТ РЕЧЬ О ZFS - и тем не менее, вопрос легко решается на ext4 например, читаем: on Linux the recommended way to use TRIM is to use the fstrim command run out of cron, ... typically once a week is plenty; some people will go every night, or even once a month, since it is very workload dependent. ... this has nothing to do with a particular file system or OS implementation, but is much more about fundamental issues of how storage devices respond to TRIM commands, so what is best practice for Linux would also be a good thing to do on FreeBSD
Но надо понимать, что ZFS это такая отдельная интересная избушка, в которой погремушки ну вот совершенно свои, не такие как.
Надо впрочем отметить, что я ZFS хорошо понимаю на FreeBSD и FreeNAS, а на линуксах я ее юзал буквально на 4 не то 5 машинах всего, тут у меня опыта поменее. Но я не предполагаю, что ситуация как-то может отличаться, потому что в FreeBSD еще в 2014 (!!!) году писали на форуме FreeNAS, цитирую: Trim on zfs ssds is supported starting with freebsd 9.2 and it is enabled by default. Freenas 9.2.1.3 is already on freebsd 9.2p3. So you will be ok. А сейчас в ходу уже FreeNAS 9.10-STABLE, и в линуксе ZFS тоже на месте ж не стоит.
Надо конечно уточнить для профилактики, но с вероятностью 99% я предполагаю, что ZFS на линуксе тоже корректно отрабатывает TRIM.
2016-12-24 10:35 GMT+02:00 Vladimir Sharun
: Привет,
Про trim и почему это не панацея и почему это может не работать и т.д.: https://forums.freebsd.org/threads/56951/#post-328912
Привет,
TRIM на freebsd/zfs может привести к data corruption.
Мы вроде даже получили такое. Больше не балуемся.
--- Оригінальне повідомлення ---
Від кого: "Andrii Stesin"
Все это он сказал верно и прекрасно с ровно одной оговоркой: в тексте Theodore Ts'o НЕ ИДЕТ РЕЧЬ О ZFS - и тем не менее, вопрос легко решается на ext4 например, читаем: on Linux the recommended way to use TRIM is to use the fstrim command run out of cron, ... typically once a week is plenty; some people will go every night, or even once a month, since it is very workload dependent. ... this has nothing to do with a particular file system or OS implementation, but is much more about fundamental issues of how storage devices respond to TRIM commands, so what is best practice for Linux would also be a good thing to do on FreeBSD
Но надо понимать, что ZFS это такая отдельная интересная избушка, в которой погремушки ну вот совершенно свои, не такие как.
Надо впрочем отметить, что я ZFS хорошо понимаю на FreeBSD и FreeNAS, а на линуксах я ее юзал буквально на 4 не то 5 машинах всего, тут у меня опыта поменее. Но я не предполагаю, что ситуация как-то может отличаться, потому что в FreeBSD еще в 2014 (!!!) году писали на форуме FreeNAS, цитирую: Trim on zfs ssds is supported starting with freebsd 9.2 and it is enabled by default. Freenas 9.2.1.3 is already on freebsd 9.2p3. So you will be ok. А сейчас в ходу уже FreeNAS 9.10-STABLE, и в линуксе ZFS тоже на месте ж не стоит.
Надо конечно уточнить для профилактики, но с вероятностью 99% я предполагаю, что ZFS на линуксе тоже корректно отрабатывает TRIM.
2016-12-24 10:35 GMT+02:00 Vladimir Sharun
: Привет,
Про trim и почему это не панацея и почему это может не работать и т.д.: https://forums.freebsd.org/threads/56951/#post-328912
2016-12-24 11:04 GMT+02:00 Vladimir Sharun
TRIM на freebsd/zfs может привести к data corruption.
Впервые слышу об таком. Где-то писали на эту тему?
Мы вроде даже получили такое. Больше не балуемся.
С этого места можно подробнее? Точно дело именно в TRIM, или это неочевидно? ZFS не самозалечил data corruption? Очень интересно и неожыданно.
Да, на форуме FreeNAS в ветке 2014 года действительно говорится, что
TRIM seems supported : see
http://www.freebsd.org/releases/9.2R/relnotes.html ... it could be
buggy.
Хороший повод покопаться дальше, интересна судьба вот этого it could
be buggy - поправлено ли, и если да, то когда именно. В ветках 2016
года я упоминаний такого бага не припоминаю.
2016-12-24 11:07 GMT+02:00 Andrii Stesin
2016-12-24 11:04 GMT+02:00 Vladimir Sharun
: TRIM на freebsd/zfs может привести к data corruption.
Впервые слышу об таком. Где-то писали на эту тему?
Мы вроде даже получили такое. Больше не балуемся.
С этого места можно подробнее? Точно дело именно в TRIM, или это неочевидно? ZFS не самозалечил data corruption? Очень интересно и неожыданно.
вот август 2016 года: TRIM works in its current implementation, what you have to watch for is the "TRIM on init" issue when adding SSD-based vdevs to a pool - TRIM seems to currently be issued as "wait for completion" and will actually pause pool I/O, which can cause timeouts/VM stun/other nasty business. Also affects addition of L2ARC/SLOG.
Вот оттуда же, тоже август 2016: It's even more important on a COW filesystem, because every single operation will write a new block. Running garbage collection without TRIM would be a nightmare for any drive with less-than-spectacular overprovisioning - which is nearly all SSDs. Но, как я уже отметил ранее, правильная готовка кошек (офисных SSD) предполагает overprovisioning сверх заводского, процентов на 20% что вполне соответствует рекомендациям лучших собаководов.
https://forums.freenas.org/index.php?threads/trim-status-on-ssd-attached-to-...
познавательное чтиво.
2016-12-24 11:21 GMT+02:00 Andrii Stesin
Вот оттуда же, тоже август 2016:
It's even more important on a COW filesystem, because every single operation will write a new block. Running garbage collection without TRIM would be a nightmare for any drive with less-than-spectacular overprovisioning - which is nearly all SSDs.
Но, как я уже отметил ранее, правильная готовка кошек (офисных SSD) предполагает overprovisioning сверх заводского, процентов на 20% что вполне соответствует рекомендациям лучших собаководов.
hi, Fri, Dec 23, 2016 at 22:37:17, vladimir.sharun wrote about "Re: [uanog] Re: [u":
Всем привет,
В этом ворклоаде для garbage collect не будет времени - тримы просто будут игнорироваться.
Ммм... _кому_ не хватает времени и _кем_ будет игнорироваться? Со спецификой SSD (по крайней мере типичных), TRIM нельзя игнорировать никем и никогда. Если кто-то так делает - бить по рукам.
Тут нужны другие устройства с другим ценником (которым btw трим пофиг - у меня есть таких в хозяйстве - 0.5Пб записано уже и стёрлось 7%).
Что за модель?
Почему-то топик стартер считает себя умнее маркетологов на рынке SSD - это большое заблуждение. А для данных - фатальное.
Сдохнут эти SSD очень неожиданно. И, из-за того, что получают линейный ворклоад в Raid10 - одновременно. Выглядеть это будет ржачно - херась, всё зависло. Ты такой на IPMI, жамкаешь ребут, а оно после ребута не видит ни одной SSD. Оживить дату не выйдет too
Они должны переходить в r/o, не? Ну и (не "или") предупреждать о подходе к заветному порогу. -netch-
2016-12-25 9:59 GMT+02:00 Valentin Nechayev
Сдохнут эти SSD очень неожиданно. И, из-за того, что получают линейный ворклоад в Raid10 - одновременно. Выглядеть это будет ржачно - херась, всё зависло. Ты такой на IPMI, жамкаешь ребут, а оно после ребута не видит ни одной SSD. Оживить дату не выйдет too Они должны переходить в r/o, не? Ну и (не "или") предупреждать о подходе к заветному порогу.
Если оно подключено через прослойку из RAID-контроллера, то совершенно не факт, что эта дурная железяка что-либо а) поймет вообще, б) поймет правильно. Как не гарантируется и то, что RAID нормально понимает TRIM, выданный на логический диск. Только честный прозрачный HBA. А лучший RAID - это ZFS (который заодно и S.M.A.R.T.-aware, и TRIM-aware).
2016-12-25 9:59 GMT+02:00 Valentin Nechayev
: Сдохнут эти SSD очень неожиданно. И, из-за того, что получают линейный ворклоад в Raid10 - одновременно. Выглядеть это будет ржачно - херась, всё зависло. Ты такой на IPMI, жамкаешь ребут, а оно после ребута не видит ни одной SSD. Оживить дату не выйдет too Они должны переходить в r/o, не? Ну и (не "или") предупреждать о подходе к заветному порогу.
Если оно подключено через прослойку из RAID-контроллера, то совершенно не факт, что эта дурная железяка что-либо а) поймет вообще, б) поймет правильно. Как не гарантируется и то, что RAID нормально понимает TRIM, выданный на логический диск.
Справедливости ради, "дурные железки" RAID умеют работать как HBA, коими они и так являются. Я, по крайней мере, не встречал еще таких, которые бы не умели отдавать JBOD. Да и passthru интерфейс до диска еще не отменяли. На всякий случай - это я не агитирую за железявый RAID, ради расширения спектра возможностей.
Только честный прозрачный HBA. А лучший RAID - это ZFS (который заодно и S.M.A.R.T.-aware, и TRIM-aware).
ZFS на смарт клал, с тримом - нюансы, потому что наличие стоп-листа, где trim несовместим с zfs - это, кажется, уже ручная работа, где колебания прошивки могут привести к фатальным моментам.
2016-12-25 10:34 GMT+02:00 Vladimir Sharun
Справедливости ради, "дурные железки" RAID умеют работать как HBA,
ДАЛЕКО не все умеют режим HBA. Из тех кто умеет, далеко не все умеют работать в этом режиме честно. Я проверял ;)
Я, по крайней мере, не встречал еще таких, которые бы не умели отдавать JBOD.
Встречал более чем неоднократно. Особенно LSI MegaRAID я хорошо изучил, и контроллеры типа 3ware. Спасибо, уважаемый, грабли хоженые топтаные, в частности то что MegaRAID называет "JBOD" - таковым не является, и "закирпичивать" LSI инженерными прошивками приходилось, и реанимировать потом... Нет-нет, спасибо спасибо, лично мне достаточно, я наигрался и мне есть на что потратить время. Только честный прозрачный HBA, как я уже и писал, и как рекомендуют лучшие собаководы по вопросам ZFS.
Да и passthru интерфейс до диска еще не отменяли.
Да-да, слово с тремя буквами "З" напомнить? ЩаЗЗЗЗЗ.
На всякий случай - это я не агитирую за железявый RAID, ради расширения спектра возможностей.
Нет-нет, спасибо, увольте, сыт уже.
Только честный прозрачный HBA. А лучший RAID - это ZFS (который заодно и S.M.A.R.T.-aware, и TRIM-aware).
ZFS на смарт клал,
Ну пошли по пунктам. ZFS "ловит" аппаратные отказы дисков и сбои чтения-записи. И делает это сам лично. И умеет "залечивать" сдохшие блоки. Чтобы это работало, ZFS-у нужно работать с дисками напрямую через прозрачный HBA, потому что прослойка из RAID, или pseudo-JBOD - она ПРЯЧЕТ железо дисков от ZFS-а, чем и портит ему всю малину. И да, эта часть истории - она не про S.M.A.R.T. вовсе, действительно. С этим спорить будем? Часть вторая. Для того, чтобы ПО ВОЗМОЖНОСТИ не доводить ZFS до необходимости таки бороться с отказами железа, а менять дохлое железо превентивно, в системе по крону пролетает демон, который обнюхивает S.M.A.R.T. и в случае обнаружения признаков умирания - кляузничает админу, мол "за такой-то канарейкой пришла маленькая нелепая смерть в цветастом балахончике, пора менять". Снова-таки, чтобы упомянутый демон мог получать с дисков S.M.A.R.T. - ему точно так же необходимо работать с дисками напрямую через прозрачный HBA, потому что прослойка из RAID, или pseudo-JBOD, не пропускает соотв. ATA COMMANDS для диагностики. (Ну Ок, для 3ware и его родственников есть костыль, чтобы сквозь псевдо-JBOD вынимать с дисков S.M.A.R.T. но это исключение только подтверждает правило - у MegaRAID разумного способа нету). С этим спорить будем? Вывод: честный топовый HBA рулит.
с тримом - нюансы, потому что наличие стоп-листа, где trim несовместим с zfs - это, кажется, уже ручная работа, где колебания прошивки могут привести к фатальным моментам.
Если HBA честный прозрачный, то о каком вообще "стоп-листе" речь?
Привет, Про винду только непонятно и задачу thin provisioning'а не решает. Собственно последнее и хочет получит топик-стартер. Решение конечно есть. Из текучих материалов, оно, к сожалению, не лепится.
Нет-нет, спасибо спасибо, лично мне достаточно, я наигрался и мне есть на что потратить время. Только честный прозрачный HBA, как я уже и писал, и как рекомендуют лучшие собаководы по вопросам ZFS.
с виндой то как раз все предельно ясно - только железный рейд. Что делать с тримом? а хз, как по мне то дисковая нагрузка и винда вещи просто несовместимые. Делал год назад сервер на хетзнере, надо было винду пошифровать, сделал просто: поставил линукс на mdadm рейд10 из двух ссд-эшников по 256 гигов, под хост-систему выделил 32 гига, что осталось выделил в раздел, раздел зашифровал криптесетапом, раздел подключил через рав-девайс к виртуальной винде. Винда просто летает.
Hi,
2016-12-25 11:41 GMT+02:00 Vladimir Sharun
Про винду только непонятно
А что собственно про винду-то непонятно? насчет винды, могу одно сказать с полной уверенностью, проверено: windows 10 в отличие от предыдущих, с SSD работает полностью корректно, делает все что следует, при этом делает правильно. Но причем тут винда?
и задачу thin provisioning'а не решает.
Почему ж не решает-то? я кстати не припоминаю акцента аффтара на этом именно моменте, но например по опыту VMware, хранящей свои vmdk на ZFS over NFS over 2*10GE, могу ответственно заявить: за счет lz4 сжатия, вопрос thin provisioning вообще не парит. VM свою vmdk-кашку видит как thick provisioned, а ZFS lz4 по факту ее упаковывает до смехотворных размеров.
Собственно последнее и хочет получит топик-стартер. Решение конечно есть. Из текучих материалов, оно, к сожалению, не лепится.
Что ты понимаешь под "текучими материалами"? железный RAID стиля 1990-х развешо, так от него я и рекомендую избавляться, в пользу top-grade HBA и ZFS + lz4
Привет,
2016-12-25 11:41 GMT+02:00 Vladimir Sharun
: Про винду только непонятно
А что собственно про винду-то непонятно? насчет винды, могу одно сказать с полной уверенностью, проверено: windows 10 в отличие от предыдущих, с SSD работает полностью корректно, делает все что следует, при этом делает правильно. Но причем тут винда?
zfs, hba - с какой стороны тут винду пришить, вот и я не понимаю. Вот у меня есть у смежников какое-то кол-во windows server и надо обеспечивать как отказоустойчивость, так и скорость. И вот тут железявый raid - это простейшее из доступных решений. EMC и NetApp не просто так живут на этом рынке.
и задачу thin provisioning'а не решает.
Почему ж не решает-то? я кстати не припоминаю акцента аффтара на этом именно моменте, но например по опыту VMware, хранящей свои vmdk на ZFS over NFS over 2*10GE, могу ответственно заявить: за счет lz4 сжатия, вопрос thin provisioning вообще не парит. VM свою vmdk-кашку видит как thick provisioned, а ZFS lz4 по факту ее упаковывает до смехотворных размеров.
Тут как грится our mileage may vary. У меня есть немножко опыта с NFS и его можно охарактеризоваться как "непредсказуемый".
Собственно последнее и хочет получит топик-стартер. Решение конечно есть. Из текучих материалов, оно, к сожалению, не лепится.
Что ты понимаешь под "текучими материалами"? железный RAID стиля 1990-х развешо, так от него я и рекомендую избавляться, в пользу top-grade HBA и ZFS + lz4
Из чего пуля не лепится - вот из чего.
2016-12-25 18:17 GMT+02:00 Vladimir Sharun
zfs, hba - с какой стороны тут винду пришить, вот и я не понимаю.
ZFS хранилище, ящику с HyperV отдавать по NFS а хоть и по iSCSI да хоть и по FC. И пусть себе работает.
Тут как грится our mileage may vary. У меня есть немножко опыта с NFS и его можно охарактеризоваться как "непредсказуемый".
Хммм VMware over NFS спокойно работает, граблей не припоминаю.
Собственно последнее и хочет получит топик-стартер. Решение конечно есть. Из текучих материалов, оно, к сожалению, не лепится.
Что ты понимаешь под "текучими материалами"? железный RAID стиля 1990-х развешо, так от него я и рекомендую избавляться, в пользу top-grade HBA и ZFS + lz4
Из чего пуля не лепится - вот из чего.
Из ZFS лепится. Точно знаю, сам лепил.
zfs, hba - с какой стороны тут винду пришить, вот и я не понимаю. Вот у меня есть у смежников какое-то кол-во windows server и надо обеспечивать как отказоустойчивость, так и скорость. И вот тут железявый raid - это простейшее из доступных решений. EMC и NetApp не просто так живут на этом рынке.
И что на ссд? У меня винда везде стоит только на хардах - главное чтобы база 1с в оперативку помещалась, тогда все работает. Скорость винта в случае с скульем не важна. Везде где она используется скорость дисковых операций не есть первая необходимость
On Sun, Dec 25, 2016 at 06:17:19PM +0200, Vladimir Sharun wrote:
Привет,
2016-12-25 11:41 GMT+02:00 Vladimir Sharun
: Про винду только непонятно
А что собственно про винду-то непонятно? насчет винды, могу одно сказать с полной уверенностью, проверено: windows 10 в отличие от предыдущих, с SSD работает полностью корректно, делает все что следует, при этом делает правильно. Но причем тут винда?
zfs, hba - с какой стороны тут винду пришить, вот и я не понимаю. Вот у меня есть у смежников какое-то кол-во windows server и надо обеспечивать как отказоустойчивость, так и скорость. И вот тут железявый
Виртуализация и iscsi. Хотя дома, на распаковке "что-то by fitgirl" на iscsi-диск (это извратные репаки, где сперва контейнеры разибрают на объекты, их потом сортируют/пакуют - соответственно при установке сперва куча мелких файлов, из которой собирают исходные контейнеры с данными игры - короче, "жалко качать - убейте SSD и постарейте с HDD"), этот самый iscsi (virtualbox+freebsd-10+пачка SATA, отдаём zvol) стабильно становилось плохо (что-то вылезало в консоль даже), с последующим отвалом и повреждением данных. В сети с такой проблемой мало кто сталкивался (если гуглу верить) и, думаю, не решили. Ещё вылезали грабли с параметром blocksize 4096 - некоторые игры с такого диска не работали (Saints Row 3, Just Cause 2, Red Faction) и тот же defraggler обломался такой диск даже анализировать.
raid - это простейшее из доступных решений. EMC и NetApp не просто так живут на этом рынке. Отчасти живут как "сковородка для прикрытия задницы" и "простое и понятное решение, которое просто поддерживать". Чтоб использовать самопальное решение вместо готового - нужно быть тем, кто принимает решения и готов за них отвечать и разбираться с граблями, а не писать тикеты в нетапп и качать головой, если там ничего хорошего не ответят..
и задачу thin provisioning'а не решает.
Почему ж не решает-то? я кстати не припоминаю акцента аффтара на этом именно моменте, но например по опыту VMware, хранящей свои vmdk на ZFS over NFS over 2*10GE, могу ответственно заявить: за счет lz4 сжатия, вопрос thin provisioning вообще не парит. VM свою vmdk-кашку видит как thick provisioned, а ZFS lz4 по факту ее упаковывает до смехотворных размеров.
Тут как грится our mileage may vary. У меня есть немножко опыта с NFS и его можно охарактеризоваться как "непредсказуемый".
Мне больше всего запомнился ребут после отвала NFS, растянувшийся на сутки :) Но с виндой - с NFS какие-то приложения работают, другие - крэшатся, ну и NFS+UTF-8/non-ascii в именах файлов "просто так" с виндой не дружит. -- Best regards, Paul Arakelyan.
Всем привет,
В этом ворклоаде для garbage collect не будет времени - тримы просто будут игнорироваться.
Ммм... _кому_ не хватает времени и _кем_ будет игнорироваться? Со спецификой SSD (по крайней мере типичных), TRIM нельзя игнорировать никем и никогда. Если кто-то так делает - бить по рукам.
trim - это hint, а не обязаловка, давал ссылку на Теодора Цо, где он этот момент распедаливает. Например у Samsung'ов trim игнорируется - тесты это показывают. Интеля - не игнорируют например.
Тут нужны другие устройства с другим ценником (которым btw трим пофиг - у меня есть таких в хозяйстве - 0.5Пб записано уже и стёрлось 7%).
Что за модель?
s3610
Почему-то топик стартер считает себя умнее маркетологов на рынке SSD - это большое заблуждение. А для данных - фатальное.
Сдохнут эти SSD очень неожиданно. И, из-за того, что получают линейный ворклоад в Raid10 - одновременно. Выглядеть это будет ржачно - херась, всё зависло. Ты такой на IPMI, жамкаешь ребут, а оно после ребута не видит ни одной SSD. Оживить дату не выйдет too
Они должны переходить в r/o, не?
C чего бы. Для них это неожиданность в т.ч.
Ну и (не "или") предупреждать о подходе к заветному порогу.
Заветный порог ты имеешь в виду wear подходит к 1 ? Нехватка времени (понял вопрос - это не в ОС ессн, а в мозгах ssd, по этой причине например у серверных ssd ваттаж уже переплёвывает винты, даже в idle) на wear level management от постоянного давления приводит к нелинейному износу блоков. Причем какой более нелинейно затёрт - неизвестно. Правильные алгоритмы снижают скорость работы (до уровня винта например), неправильные - убивают. Однозначно правильные - в серверных ssd, по-этому они адвертайзят не ахулиард iops, а что-то близкое к правде - единицы тысяч (впрочем и это маркетинг also, их under pressure тоже нет). Те же интеля 3610 под постоянным давлением дают пару тыщ iops на запись и при этом busy уже приближается к 100%. Может и неправда, но до накопления очереди в нормальной работе я еще не видел чтобы zfs доводил.
Собственно, про fastpath Игорь уже писал. Оно.
On Dec 23, 2016 15:59, "Serge Negodyuck"
On Fri, Dec 23, 2016 at 12:56:45PM +0200, Andrii Stesin wrote:
На самом железном хосте, что крутится? Виртуалки на нем же или по NFS?
Там CentOS-6.8, образы дисков живут там же, на /dev/sda.
Всё никак не могу понять, как выкупить, дело в ограниченной пропускной способности PCI, RAID-контроллера или самих дисков. Статистика, которую даёт контроллер, мягко говоря, не шибко-то информативна.
Насчёт дисков немножко сомневаюсь, что затык в них, кстати. Почему - потому что одна половина от этих виртуалок до того жила на хосте с 4-мя SSD-накопителями в RAID10, вторая - на похожем хосте с 4-мя похожими накопителями в RAID10. Оба хоста чувствовали заметно более уверенно в этой жизни. В хосте, на который переехали эти виртуалки, 16 накопителей, стало быть - нагрузка на каждый из них теоретически стала в 2 раза меньше. Потому и думаю, что, возможно, если я разделю диски между 2-мя контроллерами и затем объединю оба диска в один LVM, производительность хранилища радикально возрастёт. Только нет уверенности, вот и интересуюсь, вдруг кто имел подобный опыт.
-- V.Melnik
а на рейде жило? а то насколько мне не изменяет мой склероз, у рейд
контроллеров трим под вопросом очень большим
23 декабря 2016 г., 15:41 пользователь Vladimir Melnik
On Fri, Dec 23, 2016 at 12:56:45PM +0200, Andrii Stesin wrote:
На самом железном хосте, что крутится? Виртуалки на нем же или по NFS?
Там CentOS-6.8, образы дисков живут там же, на /dev/sda.
Всё никак не могу понять, как выкупить, дело в ограниченной пропускной способности PCI, RAID-контроллера или самих дисков. Статистика, которую даёт контроллер, мягко говоря, не шибко-то информативна.
Насчёт дисков немножко сомневаюсь, что затык в них, кстати. Почему - потому что одна половина от этих виртуалок до того жила на хосте с 4-мя SSD-накопителями в RAID10, вторая - на похожем хосте с 4-мя похожими накопителями в RAID10. Оба хоста чувствовали заметно более уверенно в этой жизни. В хосте, на который переехали эти виртуалки, 16 накопителей, стало быть - нагрузка на каждый из них теоретически стала в 2 раза меньше. Потому и думаю, что, возможно, если я разделю диски между 2-мя контроллерами и затем объединю оба диска в один LVM, производительность хранилища радикально возрастёт. Только нет уверенности, вот и интересуюсь, вдруг кто имел подобный опыт.
-- V.Melnik
participants (8)
-
Andrii Stesin
-
Igor Sviridov
-
Paul Arakelyan
-
Serge Negodyuck
-
Valentin Nechayev
-
Vasiliy P. Melnik
-
Vladimir Melnik
-
Vladimir Sharun