Назад | Перейти на главную страницу

Тип хранилища для реализации VMware View

Мы проводим пилотный проект виртуального рабочего стола, и мне было интересно, какое хранилище SAN обычно используется. Я слышал противоречивые отчеты о дисках SAS / SATA или даже о SSD или больших настройках кеша чтения / записи.

Требования:

Я просмотрел VMware Определение размера сервера и хранилища для VMware VDI: предписывающий подход и они используют диски SATA 7200 об / мин для аналогичной рабочей нагрузки, в то время как коллеги в аналогичных ситуациях наблюдали низкую производительность:

Мы используем 60 шпинделей SATA для 20 одновременных подключений. Он работал на 20 веретенах, но был слишком медленным.

Я не знаю, кому / чему верить. Есть ли другие хорошие ресурсы? Какой у других опыт?

Что ж, это пилотный проект, здесь вы можете узнать кое-что о вашем случае использования.

Я бы просто пошел с тем, что у вас есть, посмотрел, насколько он быстрый / медленный, и экстраполировал оттуда - для этого нет практического правила, только вы можете решить, что вам нужно.

Возвращайтесь к нам, когда у вас будут какие-то данные.

Причина путаницы в том, что есть документы, такие как VMware, которые указывают, что 5 операций ввода-вывода в секунду на пользователя являются разумными, и есть другие, которые оценивают 10-15, и я видел доказательства небольшого пилотного проекта, в котором фактическая нагрузка, которую мы видели, была старше 40 лет.

Тестирование \ пилотирование - действительно единственный вариант - просто выберите решение для хранения, которое позволит вам масштабироваться в ответ или стремиться к пилотному проекту, чтобы вы могли получить хорошие данные в худшем случае. Наихудший случай - это количество операций ввода-вывода в секунду виртуальной машины, когда хранилище фактически не имеет ограничений. Как только вы узнаете, что это такое, вы сможете лучше оценить, как шаблоны будут масштабироваться по мере добавления пользователей.

Есть довольно подробная статья об оценке IOP VDI на сайте Сайт сообщества Citrix который охватывает множество проблем, таких как оценка одновременных пиковых нагрузок в дополнение к средним значениям в устойчивом состоянии и пикам ввода-вывода из-за одновременных штормов входа / загрузки. Он отмечает, что большинство общих средних оценок пользовательских операций ввода-вывода в секунду не учитывают интенсивность рабочих нагрузок для многих пользователей - в то время как 4/5 операций ввода-вывода могут быть приемлемыми для обычного пользователя на виртуальной машине с большим количеством ОЗУ, это будет неточно. для всех, кто каким-либо образом продвигает систему. Я предпочитаю его способ разбить пользователей на опытных пользователей, потребляющих 25 и 50 IOP в течение значительных периодов времени. Эти цифры не являются чрезмерными, поскольку именно таких пользователей вы будете предоставлять дискам со скоростью 7200 об / мин в физических системах.

Он пришел к расчету пиковых значений IOP около 77 тыс. Для 3,5 тыс. Пользователей или 20 операций ввода-вывода в секунду на пользователя, что далеко от показателя VMware 5.

Chopper3 здесь мертв. Пока вы не узнаете больше о том, какой тип ввода-вывода вам нужен от VDI, вы не сможете точно предсказать, какое хранилище удовлетворит потребность. Если вам нужно знать, прежде чем покупать все, приобретите несколько тонких клиентов, раздайте их людям и отслеживайте, какие операции ввода-вывода им требуются. Затем экстраполируйте до 50.

Одна из причин, по которой нет хороших руководящих принципов для определения размера хранилища для VDI, заключается в том, что среда хранения настолько изменчива, что трудно дать хорошее руководство. Если хранилище используется для других вещей (например, базы данных MS-SQL), у вас меньше места, чем если бы хранилище было выделено для VDI. Также производительность каждой подсистемы хранения может влиять на вещи, что еще больше загрязняет воду.

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