> Соответственно в реальной жизни, многих деталей мы можем просто не знать, чтобы (правильно) считать RPO/RTO.

А кто говорил, что будет легко? ;) Если требования RPO/RTO не знает клиент, ему должен помочь их сформулировать интегратор/партнер, в конце концов получает он свой процент разницы между партнерской ценой, и тем, что появляется в инвойсе, отправленном клиенту, совсем не за красивые глаза. ??менно эти услуги и оплачивает конечный клиент этим процентом, да, я понимаю, что многие из партнеров уже это какбыэтосказать забыли про эту функцию интегратора.
Ну пусть не обижаются, что у клиентов все шире представление о интеграторах, как о бездельниках и ненужных мироедах. Оно, зачастую, справедливо. К сожалению.

Я нарочно поставил через чёрточку “систему”. Так как на практике конечный покупатель выбирает “решение” по СХД, но в целом для его инфраструктуры, это только часть решения. Соответственно в реальной жизни, многих деталей мы можем просто не знать, чтобы (правильно) считать RPO/RTO.

Сложно сказать однозначно, они, SSD, ведь разные бывают.
А почему вы чувствуете недоверие к данным EMC, по вашему сколько должно быть, больше или меньше?
Вы еще не забывайте, что на запись у SSD, по крайней мере у тех, что сейчас используются в энтерпрайз-системах, все совсем не радужно при random write, и при наличии в паттерне ввода-вывода случайной записи мелкими блоками на SSD, вы сразу сильно, в десятки раз просядете.

C 2040 вы в 20-25 тысяч не уложитесь :(
Хотя 2040 с дисками, допустим, SAS 300GB, возможно, будет довольно близка к вашему решению.

Если нет необходимости решить вот прям счас, то я бы посоветовал вам подождать некоторых событий в ноябре, о которых я пока не могу говорить, но которые для вашей задачи могут быть интересны.

Моя задачка: 6000 IOPS full random; 2TB места в 6 RAID (RAID-DP); бюджет 20-25 k$
??меет ли мне смысл рассматривать FAS 2040 или лучше сразу смотреть более “взрослые” версии?

Спасибо огромное за ответ.

> Есть какие-то best practices может быть на этот счет?
Рекомендую вот это:
http://media.netapp.com/documents/tr-3705.pdf

8 глава там как раз про сайзинг.
Я его даже перевожу, и даже где-то в следующем месяце он будет опубликован в библиотеке Netwell. Там же, в библиотеке, есть уже и про Xen Desktop, если интересно.

Также вот имеет смысл посмотреть блог автора Best Practices
http://communities.netapp.com/community/netapp-blogs/virtualization/blog
?? вот этот документ может дать полезную пищу подумать.
http://media.netapp.com/documents/tr-3949.pdf

Насчет подписаться на комменты - ну… я попробую что-нибудь придумать :)

Моя реальная задача - это спланировать как раз VDI на ~ 400 рабочих мест, на данный момент я лишь знаю что одна вирт. машина “генерит” порядка 20 IOPS. Есть какие-то best practices может быть на этот счет?

Еще выпорос: допусим я знаю, что NFS volume - vdi, на которой лежат VDI машины находится на aggr из 14 SAS дисков. Предполагая, что 200 IOPS на диск мы получаем 2800 IOPS. В реальности я наблюдаю что vdi генерит в пиках 3400 IOPS. Вопрос: откуда беруться 3400 - 2800 = 600 IOPS еще? Я догадываюсь, что это RAM cash моего filer’a влияет, но мне хотелось быть иметь четкую формулу, по которой я могу расчитать число IOPS, которое я получу скажем на 2 полках с SAS дисками.

PS: как подписаться на комменты?

Ну, прежде всего это зависит от того, что у вас за OS. В разных OS есть разные инструменты. Например в Windows можно воспользоваться стандартным perfmon, с достаточной степенью точности он дает представление и цифры. Я как-то об этом даже писал.
http://blog.aboutnetapp.ru/archives/13

Померяв и просуммировав показатели имеющихся серверов, можно получить оценочное, приблизительное, но все же более-менее понятное значение ориентировочной нагрузки на диски.

Мне вот этот момент очень интересен, каким образом я могу изменирить предполагаемую “нагрузку”?