Всегда пожалуйста.
К сожалению, исходя из «отдельного пункта», как раз «узкие» IP каналы могут стать проблемой при необходимости восстанавливать большие объемы. Но это проблема не только конкретно вашего решения, но и многих коммерческих реализаций бэкапов.
Я как раз подводил вас к мысли, что даже синтетические тесты по возможности лучше подводить ближе к реалиям жизни. В том числе и для того что бы не создавать неоправданных завышенных ожиданий у ваших клиентов :-). В этом ракурсе как раз отключение кэша на время тестирования смысла не имеет. В моей практике были ситуации когда включенный кэш (алгоритмы кэширования) приводили к снижению производительности устройства или решения :-).
Ну и никто не отменял утверждения, что тестирование синтетическими тестами -это тестирование «сферического коня в вакууме». Все зависит от конкретных сценариев нагрузки, настроек софта и оборудования. У того же линукса есть минимум 4 интегрированных io шедулера и дефолтный не всегда бывает оптимальным выбором :-). Ну и в любом случае тесты дают пищу к размышлениям, а иногда и в прямую влияют на выбор конкретным заказчиком конкретного решения/оборудования.
В качестве бесплатной альтернативы относительно дорогим «энтерпрайз» продуктам для бэкапа вполне интерестное решение. Смущает только одно. Помимо процессов бэкапа и хранения резервных копий, есть еще процессы восстановления из этих бэкапов в случае сбоев. И тут скорость восстановления в пределах даже небольших организаций бывает критична. Простаивать сутки и более бизнес обычно не любит. Ну и кроме того сами сценарии восстановления продумывать и отрабатывать (тестировать) лучше заранее. Что бы понимать «куда бежать? и что делать?» в случае необходимости, а кроме того понимать сколько потребуется времени.
Еще раз. Может я плохо объясняю :-). Я имел в виду что нагрузку на каждую ноду дает обычно не одна VM, а несколько. VM работает не только с одним Gb горячих даных, которые в итоге и попадают в кэш. Имеет смысл все таки тестировать бОльшие объемы даных на одну ноду. По хорошему раза в 3-5 больше чем ОЗУ ноды.
Про недостижимые идеалы речи не идет. Тест от получаса до пары часов вполне информативен. Тестирование с отключением кэша или с direct io не интерестно, так как совсем уж далеко от жизни получается. Все равно кэши использоваться будут, поэтому и интерестны ситуации когда они используется, но не справляется со всей нагрузкой.
По поводу 16Gb, у вас же соотношение не одна VM на одну ноду обычно? Значит и тестировать корректнее или несколько нагружаемых файлов по 16Gb на ноду, или один большой файл размером 16Gb*X VM.
Ну и уж если совсем «придираться» :-) нагрузка блоками по 4K не совсем типична для VM. Даже транзакционные базы данных оперируют страницами по 8K. Другие приложения обычно более крупными блоками оперируют. Кроме того не плохо бы понимать соотношение операци чтения и операций записи в тестируемом профиле нагрузки.
Вам не кажется, что тестовый файл в 16 Gb на одну ноду слишком мал? Учитывая количество оперативной памяти даже в современных десктопах (8Gb ОЗУ уже норма, 16 тоже не редкость), не говоря уже про сервера. C такими маленькими тестовыми файлами на ноду в итоге вы тестируете производительность ОЗУ в каждой ноде кластера.
Так же не понятен выбор времени теста в одну минуту. Я думаю гораздо интереснее как решение себя ведет под продолжительной интенсивной нагрузкой. Когда кэши насыщаются или просто уже не могут справляться с потоком данных и на сцену выходит она самая :) — производительность шпиндельных дисков.
По поводу энтерпрайз СХД — там давно многие производители пришли к использованию именно софтовых Raid и дисковых пулов. Циклы разработки короче, чем для железячных контроллеров. Разработчиков найти/вырастить проще, баги править удобнее и опять же быстрее. Нет узкого места в виде железных контроллеров. Платформа x86 на данный момент победила, соответственно меняем железо на новое поколение и все. Софт можно использовать старый, а производительность уже выросла. Искусственные ограничения типа: «новая прошивка» не устанавливается на «старое» железо и т.п. сейчас не рассматриваем.
Мне всегда интересно в подобных кластерных решениях в какой момент приложение или VM получает ack о том что запрошенная запись данных произведена. Когда нода получила блок данных в свой кэш? Тогда что будет если в этот момент нода «умрет»? Если ack идет приложению или VM когда блок данных скопирован на другие ноды, то мне кажется проблемой могут стать каналы в 1Gbit/s между нодами и время задержки в самой сети Ethernet между ними. Особенно если кластер физически подключается в общую сеть с потребителями (пользователями или VM).
Единственное с чем полностью и безоговорочно согласен :), так это с тем что файл для теста забитый «мусорными» данными нужно генерировать заранее.
К сожалению, исходя из «отдельного пункта», как раз «узкие» IP каналы могут стать проблемой при необходимости восстанавливать большие объемы. Но это проблема не только конкретно вашего решения, но и многих коммерческих реализаций бэкапов.
Ну и никто не отменял утверждения, что тестирование синтетическими тестами -это тестирование «сферического коня в вакууме». Все зависит от конкретных сценариев нагрузки, настроек софта и оборудования. У того же линукса есть минимум 4 интегрированных io шедулера и дефолтный не всегда бывает оптимальным выбором :-). Ну и в любом случае тесты дают пищу к размышлениям, а иногда и в прямую влияют на выбор конкретным заказчиком конкретного решения/оборудования.
По поводу 16Gb, у вас же соотношение не одна VM на одну ноду обычно? Значит и тестировать корректнее или несколько нагружаемых файлов по 16Gb на ноду, или один большой файл размером 16Gb*X VM.
Ну и уж если совсем «придираться» :-) нагрузка блоками по 4K не совсем типична для VM. Даже транзакционные базы данных оперируют страницами по 8K. Другие приложения обычно более крупными блоками оперируют. Кроме того не плохо бы понимать соотношение операци чтения и операций записи в тестируемом профиле нагрузки.
Так же не понятен выбор времени теста в одну минуту. Я думаю гораздо интереснее как решение себя ведет под продолжительной интенсивной нагрузкой. Когда кэши насыщаются или просто уже не могут справляться с потоком данных и на сцену выходит она самая :) — производительность шпиндельных дисков.
По поводу энтерпрайз СХД — там давно многие производители пришли к использованию именно софтовых Raid и дисковых пулов. Циклы разработки короче, чем для железячных контроллеров. Разработчиков найти/вырастить проще, баги править удобнее и опять же быстрее. Нет узкого места в виде железных контроллеров. Платформа x86 на данный момент победила, соответственно меняем железо на новое поколение и все. Софт можно использовать старый, а производительность уже выросла. Искусственные ограничения типа: «новая прошивка» не устанавливается на «старое» железо и т.п. сейчас не рассматриваем.
Мне всегда интересно в подобных кластерных решениях в какой момент приложение или VM получает ack о том что запрошенная запись данных произведена. Когда нода получила блок данных в свой кэш? Тогда что будет если в этот момент нода «умрет»? Если ack идет приложению или VM когда блок данных скопирован на другие ноды, то мне кажется проблемой могут стать каналы в 1Gbit/s между нодами и время задержки в самой сети Ethernet между ними. Особенно если кластер физически подключается в общую сеть с потребителями (пользователями или VM).
Единственное с чем полностью и безоговорочно согласен :), так это с тем что файл для теста забитый «мусорными» данными нужно генерировать заранее.