Китайцы производители и спонсоры проведения тестов, о чем честно написано в отчете SPC-1 — то есть они платят деньги за это тестирование.
Конфигурация для тестирования тоже в общем то достаточно интересная — 96xSLC диски в RAID-10. Диски по 200GB. Объем usable дискового пространства который получили по факту согласно www.storageperformance.org/benchmark_results_files/SPC-1/Huawei/A00119_Huawei_Dorado5100/a00119_Huawei_Dorado5100_SPC-1_executive-summary.pdf — 6.5TB — то есть меньше половины x-Break с дисками на 800GB. Ценник обозначен как $500K (надо понимать, что ценник не российский, у нас он несколько другой), то есть получает что для получения эквивалентного объема нам нужно две системы от китийцев напротив одного X-Break, то есть по деньгам будет дороже, либо делать RAID-5 — а вот тут я полаю с производительностью сразу станет все значительно хуже.
Но конечно в случае RAID-10 и двух систем по 96 SLC дисков performance полагаю будет выше в сравнение с одним X-Break — уж слишком монстровая конфигурация получиться у Huawei.
Мы делали базовые тесты на Dorado2100 G2 (это конечно не 5100, но и на этой железки brend тоже заявляет 600 000 IOPS). На практике получили:
awg iops, read 41877
awg iops, write 17947
awg latency, read, ms 4,5
awg latency, write, ms 3,3
В общем не впечатлило (сильно разошлось с китайским маркетингом). Повторно Huawei железку для проведения полного цикла тестирования и формирования статьи пока не дал. В связи с этим я бы очень аккуратно относился к тому, что публикуют китайцы, вернее говоря не верил бы без реальной проверки
Так все правильно, Вы делали snapshot, при split у вас начал работать механизм CoW, основной том дополнительно подгрузился — front end IOPS упали. Начали писать с V-VOL — дали дополнительную нагрузку на P-VOL — front end IOPS еще упали. В принципе у Вас даже не очень плохие результаты получились, учитывая то что при работе CoW к каждому front end IOPS добавляется, как правило, два back-end IOPS без учета пенальти на RAID.
Если нужно snapshot которые не оказывают виляние на производительность, то это к NetApp, EMC (VNX — последних моделей), Oracle (ZFS), которые используют Write Redirect Snapshot, но в этих решениях вы получите не предсказуемый показатели на поточных операциях чтения из-за фрагментации данных. В общем идеальных решений не бывает, при наличии «плюсов» всегда есть «минусы», но про них не все знают, а те кто знает не всегда говорит.
Очень странные у Вас поучись результаты. Если для ShadowImage (клона) завершилась синхронизация и он оторван от оригинала (сделан split), то накладные расходы на его существование заключаются только в ведение битовой карты, что очень не существенно.
В случае Thin Image (snapshot) влияние на операциях записи в оригинальный том конечно будет, так как оригинальные блоки при изменении будут копироваться в pool-VOL, степень влияния будет сильно зависеть от конфигурации и вида нагрузки. Если вы в оригинальный том пишете в несколько потоков dd, то влияние может быть значимым. С другой стороны, выглядит странным использование snapshot для томов подразумевающих поточную нагрузку на запись, если подобная задача стоит то для этого есть другие решения и подходы.
Конфигурация для тестирования тоже в общем то достаточно интересная — 96xSLC диски в RAID-10. Диски по 200GB. Объем usable дискового пространства который получили по факту согласно www.storageperformance.org/benchmark_results_files/SPC-1/Huawei/A00119_Huawei_Dorado5100/a00119_Huawei_Dorado5100_SPC-1_executive-summary.pdf — 6.5TB — то есть меньше половины x-Break с дисками на 800GB. Ценник обозначен как $500K (надо понимать, что ценник не российский, у нас он несколько другой), то есть получает что для получения эквивалентного объема нам нужно две системы от китийцев напротив одного X-Break, то есть по деньгам будет дороже, либо делать RAID-5 — а вот тут я полаю с производительностью сразу станет все значительно хуже.
Но конечно в случае RAID-10 и двух систем по 96 SLC дисков performance полагаю будет выше в сравнение с одним X-Break — уж слишком монстровая конфигурация получиться у Huawei.
awg iops, read 41877
awg iops, write 17947
awg latency, read, ms 4,5
awg latency, write, ms 3,3
В общем не впечатлило (сильно разошлось с китайским маркетингом). Повторно Huawei железку для проведения полного цикла тестирования и формирования статьи пока не дал. В связи с этим я бы очень аккуратно относился к тому, что публикуют китайцы, вернее говоря не верил бы без реальной проверки
Если нужно snapshot которые не оказывают виляние на производительность, то это к NetApp, EMC (VNX — последних моделей), Oracle (ZFS), которые используют Write Redirect Snapshot, но в этих решениях вы получите не предсказуемый показатели на поточных операциях чтения из-за фрагментации данных. В общем идеальных решений не бывает, при наличии «плюсов» всегда есть «минусы», но про них не все знают, а те кто знает не всегда говорит.
В случае Thin Image (snapshot) влияние на операциях записи в оригинальный том конечно будет, так как оригинальные блоки при изменении будут копироваться в pool-VOL, степень влияния будет сильно зависеть от конфигурации и вида нагрузки. Если вы в оригинальный том пишете в несколько потоков dd, то влияние может быть значимым. С другой стороны, выглядит странным использование snapshot для томов подразумевающих поточную нагрузку на запись, если подобная задача стоит то для этого есть другие решения и подходы.