Comments 7
Вы можете потестить производительность snapshot-ов?
В последний раз тестировал их год или два назад и результаты были очень печальны.
В последний раз тестировал их год или два назад и результаты были очень печальны.
Можем. Под конкретную задачу, конечно.
Вы же понимаете, у любой системы такого класса много разных фитч. Далеко не все из них реально востребованны.
Вы же понимаете, у любой системы такого класса много разных фитч. Далеко не все из них реально востребованны.
Я делал колхозно — несколько экземпляров dd в приведённые тома, получал более-менее заметную нагрузку, потом делал снапшот и клон от него (забыл как это называется в терминах Hitachi) и тоже давал нагрузку такую же. Где-то даже сохранились графики, но производительность была не приемлемая даже для тестовых целей. Особенно низкая производительность была у клона. По всей видимости у них очень сильный overhead в реализации технологии, а жаль.
Очень странные у Вас поучись результаты. Если для ShadowImage (клона) завершилась синхронизация и он оторван от оригинала (сделан split), то накладные расходы на его существование заключаются только в ведение битовой карты, что очень не существенно.
В случае Thin Image (snapshot) влияние на операциях записи в оригинальный том конечно будет, так как оригинальные блоки при изменении будут копироваться в pool-VOL, степень влияния будет сильно зависеть от конфигурации и вида нагрузки. Если вы в оригинальный том пишете в несколько потоков dd, то влияние может быть значимым. С другой стороны, выглядит странным использование snapshot для томов подразумевающих поточную нагрузку на запись, если подобная задача стоит то для этого есть другие решения и подходы.
В случае Thin Image (snapshot) влияние на операциях записи в оригинальный том конечно будет, так как оригинальные блоки при изменении будут копироваться в pool-VOL, степень влияния будет сильно зависеть от конфигурации и вида нагрузки. Если вы в оригинальный том пишете в несколько потоков dd, то влияние может быть значимым. С другой стороны, выглядит странным использование snapshot для томов подразумевающих поточную нагрузку на запись, если подобная задача стоит то для этого есть другие решения и подходы.
Нашёл свой отчёт, чтобы не быть голословным.
Так все правильно, Вы делали 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, но в этих решениях вы получите не предсказуемый показатели на поточных операциях чтения из-за фрагментации данных. В общем идеальных решений не бывает, при наличии «плюсов» всегда есть «минусы», но про них не все знают, а те кто знает не всегда говорит.
Если нужно snapshot которые не оказывают виляние на производительность, то это к NetApp, EMC (VNX — последних моделей), Oracle (ZFS), которые используют Write Redirect Snapshot, но в этих решениях вы получите не предсказуемый показатели на поточных операциях чтения из-за фрагментации данных. В общем идеальных решений не бывает, при наличии «плюсов» всегда есть «минусы», но про них не все знают, а те кто знает не всегда говорит.
Sign up to leave a comment.
Тестирование флеш СХД. Hitachi HUS VM с модулями FMD