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

Достаточно ли основывать требования к хранилищу на основе IOPS?

Текущая система, о которой идет речь, работает под управлением SBS 2003 и будет перенесена с нового оборудования на SBS 2008. В настоящее время я наблюдаю в среднем 200-300 дисковых передач в секунду в общей сложности по всем массивам в системе. Массив, в котором наблюдается большая часть активности, представляет собой 6-дисковый RAID 6 со скоростью 7200 об / мин, и он изо всех сил пытается справиться с высокими нагрузками (время простоя часто составляет всего 10-20%; время отклика достигает пика 20-50 + мс). Основываясь на некоторых приблизительных расчетах, это имеет смысл (в среднем ~ 245 IOPS для этого массива при соотношении чтения и записи 70/30).

Я рассматриваю возможность использования гораздо более простой конфигурации дисков с использованием одного массива RAID 10 из 10K дисков. Используя те же параметры для моих вычислений выше, я получаю в среднем 583 случайных IOPS / сек.

Конечно, SBS 2008 - это не то же самое, что 2003, но я хотел бы сделать предположение, что он будет аналогичным с точки зрения производительности диска, если не лучше (Exchange 2007 проще на диске и нет ISA-сервера).

Правильно ли я полагаю, что предложенная система будет достаточной с точки зрения производительности, или я чего-то упускаю? Я так много читал о рекомендуемых конфигурациях дисков для различных продуктов, таких как Exchange, и они часто упоминают такие вещи, как выделение шпинделей для журналов и т. Д. Я понимаю причины этого, но если у меня более чем достаточно накладных расходов случайного ввода-вывода , это действительно важно? У меня всегда были как минимум отдельные шпиндели для ОС, но я действительно мог бы снизить стоимость и сложность, если бы у меня был только один, хорошо работающий массив.

Чтобы не заставлять вас выполнять мою работу за меня, общая версия этого вопроса такова: если у меня есть прогнозируемый показатель IOPS для новой системы, достаточно ли использовать только это значение для спецификации хранилища, игнорируя «передовой опыт» "конфигурации? (учитывая аналогичную технологию, не переходя с DAS на SAN или что-то еще)

Я бы не стал игнорировать передовой опыт в отношении различных шпинделей. Вот мои причины. Для ОС наличие ОС на другом шпинделе дает преимущества с точки зрения резервного копирования, восстановления и обновлений, которые не имеют ничего общего с производительностью ввода-вывода. Что касается журналов, то есть две причины для размещения хранилищ и журналов Exchange на разных шпинделях. Первый - это резервные копии, если они находятся на разных шпинделях, требуется более катастрофическое событие, чтобы удалить их обоих, что хорошо. Второй вариант более тонкий. По сути, Exchange чередует запись в файлы журнала и запись в хранилище данных (это чрезмерное упрощение, но пока достаточно). Если эти две вещи находятся на одном шпинделе, вы заставляете ОС переключаться между ними, что означает, что диск проводит гораздо больше времени в состоянии поиска, требующем много времени, и гораздо меньше времени в состоянии последовательного чтения / записи. По сути, диск пытается найти нужные секторы вместо того, чтобы что-то делать, и это может значительно снизить реальную производительность диска. По этой же причине производительность диска повышается после выполнения дефрагментации.