Я начал смотреть на смену моделей зарядки накопителей. Исторически сложилось так, что это было чисто за гиг в большом общем пуле.
Но я смотрю на расширение модели и на предложения многоуровневого хранилища - в основном потому, что мы смотрим на инвестиции в SSD - но при нашей предыдущей модели зарядки мы действительно не смогли оправдать это. (У нас есть кое-что как «апгрейд кэша контроллера»).
Моя первоначальная отправная точка:
Разделите IOP и пропускную способность на доступный ТБ, чтобы установить «распределение производительности» на основе каждого «купленного» ТБ. И посмотрите на образец конфигурации SATA, образец конфигурации FC / SAS и SSD.
Я знаю, что это скорее упрощение, и это, скорее, наихудший сценарий в мире больших толстых кешей и множества других узких мест.
У меня есть большая куча статистики производительности «среднего использования», и я знаю, как выглядят мои коэффициенты попадания в кэш в реальном мире, но теперь я немного застрял в том, как «масштабировать» это. В качестве примера - мои файловые системы NetApp дают мне 20-25% пропусков из кэша чтения и делают что-то совершенно другое с кешем записи и WAFL, что затрудняет сравнение этого элемента. (Но я думаю, что допущение, что большое количество попаданий в кэш записи не является необоснованным, и, таким образом, позволяет мне игнорировать штраф за запись и задержку пакетной записи).
Итак, это мой вопрос - какой подход вы бы предложили для объединения, скажем, трех уровней «предложения хранения» (архивный, «стандартный» и высокопроизводительный)? Как бы вы учесть ожидаемую отдачу от кэширования и консолидации?
Что касается многоуровневого хранилища - это вариант, потому что это фактически то, что мы уже делаем с помощью больших кешей контроллеров. Но по-прежнему существует необходимость различать «дешевое» и «быстрое» хранилище, и мне тоже нужна оценка.
Самый простой ответ - взимать плату за ТБ и основывать свою цену на том, сколько вам стоит его предоставить. Имейте один класс хранилища, который представляет собой диски и SSD, другой класс для только дисков и модификаторы для других служб (например, как они создаются, реплицируются ли они и т. Д.). В этой среде, если вы даже столкнетесь со стеной производительности, основанной на составе вашего пула, вам нужно будет заплатить за дополнительный SSD, не обязательно кому-то передать это.
Если вы хотите получить какой-то SLA для производительности, вам понадобится QOS. Некоторые платформы позволяют вам ограничивать определенные рабочие нагрузки с точки зрения некоторой метрики, которая может быть чем-то, что позволяет вам быть хорошим соседом, а также взимать с тяжелых пользователей небольшой объем хранилища пропорционально тому, сколько они стоят вам за размещение.