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

Размер хранилища для виртуальных машин

В настоящее время я провожу исследование, чтобы определить коэффициент консолидации, которого моя компания могла бы ожидать, если мы начнем использовать платформу виртуализации. Я постоянно захожу в тупик при исследовании того, как преобразовать наблюдаемую производительность (данные за несколько недель) в требования к жесткому диску для сервера виртуализации. Я знаком с концепцией IOP, но они кажутся чрезмерно упрощенными измерениями, не учитывающими кеш, объединение записи и т. Д. Есть ли плодотворная работа по анализу производительности массива хранения, которую я упустил? Это похоже на область, где слухи и «черная магия» взяли верх над холодным, твердым фактом.

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

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

Взгляните на цифры, а не просто догадывайтесь. Многие из чисел не будут показывать, какова частота попаданий в кэш; а если вы выберете SAN, у него, вероятно, будет кеш большего размера (где частота попаданий в кеш может сильно отличаться).

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

Если вы можете, вы можете провести некоторое тестирование дискового массива, чтобы убедиться, какой тип ввода-вывода вы сможете получить, x количество дисковых шпинделей. Мое практическое правило: 150, 200, 250 операций ввода-вывода в секунду для дисков размером 7,2, 10 и 15 тыс. Соответственно, а для RAID 10 каждая зеркальная пара, добавленная в набор полос, добавляет такое количество операций ввода-вывода в секунду в пул. Таким образом, чередование двух зеркал для дисков 7.2k составит около 300 IOPS, или 500 IOPS, если вы используете диски 15k.

Предполагая, что у вас есть более крупная среда для консолидации, вы, вероятно, пытаетесь выяснить, сколько полок на диске вам нужно. Если вы используете 15 дисковых полок, то 2 полки дают вам 14 пар зеркал, которые можно разделить на полосы, и 2 горячие запасы, что обеспечивает до 3500 операций ввода-вывода в секунду. Когда вы добавляете кэширование, а также упорядочивание и планирование ввода-вывода, вы можете получить более высокую производительность, чем это, но вы не должны получать более низкую производительность.

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