EMC начала глобальный хаеринг в команду vSpecialist. Сейчас открыто почти 100 позиций.
Этика работы в группе "you’ll work your buns off, but will be part of something fun" (ты будешь работать как проклятый, но станешь частью чего-то интересного).
Да, чуть не забыл... опыт чтения рэпа обязателен... ;)
We’re number #1
vSpecialist we get the job done
текст
23 сентября 2010 г.
20 сентября 2010 г.
Эффективная конфигурация под FAST
В этом посте хотелось бы немного поговорить о методах расчета наиболее эффективной с точки зрения производительности и стоимости конфигурации дискового массива, в котором предполагается использование функциональности FAST. Напомню, что функция Fully Automated Storage Tiering (FAST) позволяет автоматизировать перемещение данных между уровнями хранения в соответствии с активностью доступа к ним.
В качестве примера инструмента, используемого для расчетов конфигурации дисковых массивов, я буду использовать EMC Tier Advisor.
Начнем с обсуждения термина “уровень”. Под ним подразумевается совокупность двух факторов:
• типов используемых накопителей (flash/FC/SATA, объема и скорости вращения шпинделей)
• типом используемого RAID (RAID10/5/6, количество накопителей)
Для оценки требуемой конфигурации необходима информация о количестве и среднем размере томов, а также пиковых или усредненных характеристиках производительности (Throughput, Bandwidth, соотношение чтение-запись). Всю эту информацию не сложно получить, анализируя статистику производительности доступа к дисковому массиву. Утилита EMC Tier Advisor делает это автоматически при загрузке файлов конфигурации и статистики.
Для того, чтобы охарактеризовать равномерность нагрузки на тома часто используется параметр Skew. Для ее расчета тома сортируются в порядке убывания нагрузки. После этого строится график зависимости кумулятивной нагрузки (нагрузка на том 1, суммарная нагрузка на том 1 + том 2, суммарная нагрузка на том 1 + том 2 + том 3 и т. д.) от кумулятивной суммарной емкости (размер тома1, суммарный размер тома 1 + тома 2, суммарный размер тома 1 + тома 2 + тома 3 и т. д.). Для удобства кумулятивной нагрузка и емкость нормализуются по максимальным значениям. Точка пересечения с графиком y=1-x даст нам значение Skew.
По сути, параметр Skew отражает принцип Парето, более известный как закон 80/20. В данном случае он отражает дисбаланс нагрузки: 80% запросов предназначены 20% томов. Конечно, соотношение 80/20 является условным и реальные значения Skew очень сильно зависят от конкретной системы.
Кстати, интересную статью о принципе Парето можно почитать здесь.
Итак, у нас есть “уровни” с некоторыми характеристиками производительности и внешняя нагрузка. Как же рассчитывать “эффективную” конфигурацию? В детали я погружаться не стану (да и не знаю я многих деталей ;) ), но общий принцип расскажу. Помните, мы уже здесь и здесь рассуждали о том, что время отклика нелинейно зависит от нагрузки. При определенном уровне утилизации, даже небольшой прирост нагрузки приведет к огромному росту Response Time. Именно точка перегиба, начиная с которой кривая начинает расти быстрее вверх, чем уходить вправо, и считается наиболее эффективным режимом работы. У систем с различными характеристиками точки перегиба находятся в разных местах.
На основе реальных замеров производительности дисков различных типов в разных RAID уже сформированы графики зависимости от нагрузки и определены точки перегиба. При расчетах оптимальной конфигурации, как только нагрузка какой-либо группы RAID превышает точку перегиба, программой автоматически добавляются дополнительные накопители. Требования производительности являются первичными. В некоторых случаях, особенно при использовании дисков SATA, утилита добавляет накопители, не дожидаясь заполнения всей доступной емкости группы RAID. В таких случаях предполагается работа в Short Stroke.
Давайте теперь сравним две конфигурации одна из которых (Baseline) состоит только из дисков FC 300GB 15K RPM в RAID5 3+1 (192 шт., 100% емкости), а другая (Drive Optimization) является сочетанием flash 200GB в RAID5 3+1 (8 шт. 3% емкости), FC 300GB 15K RPM в RAID5 3+1 (36 шт. 40% емкости) и SATA 1TB 7,2K RPM в RAID6 6+2 (16 шт. 57% емкости).
Мы видим, что Drive Optimization при 32% уменьшении стоимости (Rel Cost) дает 78% уменьшение Service Time (Rel ST) и 72% снижение энергопотребления (Rel Power).
Из графиков внизу скриншота видно, что при увеличении нагрузки различие в производительности будет еще расти.
При изменении пропорции чтения и записи ситуация изменится.
Для обеспечения такого же уровня производительности потребуется 20 накопителей flash, 64 FC и 16 SATA. Стоимость конфигурации по сравнению с Baseline, конечно, несколько увеличится до 0,75. Однако, даже в этом случае выигрыш использования композитной конфигурации очевиден.
Уменьшим нагрузку в IOPS в 4 раза.
В итоге, финансовая привлекательность конфигурации Drive Optimization станет хуже, чем у Baseline на 44%. Можно конечно попробовать подобрать другую пропорцию накопителей. Я это попробовал сделать. После череды экспериментов было установлено, что в случае низких нагрузок использование композитных конфигураций и FAST не эффективно.
Вернем нагрузку назад и попробуем изменить равномерность распределение нагрузки между томами. Вместо 95/10 поставим Skew равным 80/20.
Видно, что при низком Skew выигрыш в производительности от использования композитной конфигурации заметно уменьшился, а цена решения приблизилась к Baseline. Делаем вывод, чем более равномерно нагрузка распределена между томами, тем менее эффективным в контексте цена/производительность будет использование FAST.
Как же улучшить ситуацию? Можно поэкспериментировать и найти более оптимальное сочетание накопителей. Конфигурация Optimal дает нам очень заметный выигрыш по всем параметрам.
Конфигурация, дававшая нам в одних условиях колоссальный положительный эффект, может быть совершенно не приемлемой в других. Так, если в предыдущем примере снизить нагрузку и увеличить пропорцию операций чтения, относительная стоимость решения Optimal увеличится почти в 5 раз. Поэтому при разработке оптимальной конфигурации стоит использовать максимально точные данные о требованиях к производительности.
Ну и последнее. Разные производители для расчета эффективной конфигурации дискового массива используют свои собственные инструменты. К сожалению, EMC Tier Advisor является утилитой для внутреннего использования, так что в свободном доступе в Интернете ее не найти. Если вам интересно проверить какую-то свою конфигурацию, существуют 2 способа сделать это. Или пришлите мне все вводные и я вам посчитаю сам, или поймайте меня на предстоящем EMC Forum и потыкайте кнопки самостоятельно…
В качестве примера инструмента, используемого для расчетов конфигурации дисковых массивов, я буду использовать EMC Tier Advisor.
Начнем с обсуждения термина “уровень”. Под ним подразумевается совокупность двух факторов:
• типов используемых накопителей (flash/FC/SATA, объема и скорости вращения шпинделей)
• типом используемого RAID (RAID10/5/6, количество накопителей)
Для оценки требуемой конфигурации необходима информация о количестве и среднем размере томов, а также пиковых или усредненных характеристиках производительности (Throughput, Bandwidth, соотношение чтение-запись). Всю эту информацию не сложно получить, анализируя статистику производительности доступа к дисковому массиву. Утилита EMC Tier Advisor делает это автоматически при загрузке файлов конфигурации и статистики.
Для того, чтобы охарактеризовать равномерность нагрузки на тома часто используется параметр Skew. Для ее расчета тома сортируются в порядке убывания нагрузки. После этого строится график зависимости кумулятивной нагрузки (нагрузка на том 1, суммарная нагрузка на том 1 + том 2, суммарная нагрузка на том 1 + том 2 + том 3 и т. д.) от кумулятивной суммарной емкости (размер тома1, суммарный размер тома 1 + тома 2, суммарный размер тома 1 + тома 2 + тома 3 и т. д.). Для удобства кумулятивной нагрузка и емкость нормализуются по максимальным значениям. Точка пересечения с графиком y=1-x даст нам значение Skew.
По сути, параметр Skew отражает принцип Парето, более известный как закон 80/20. В данном случае он отражает дисбаланс нагрузки: 80% запросов предназначены 20% томов. Конечно, соотношение 80/20 является условным и реальные значения Skew очень сильно зависят от конкретной системы.
Кстати, интересную статью о принципе Парето можно почитать здесь.
Итак, у нас есть “уровни” с некоторыми характеристиками производительности и внешняя нагрузка. Как же рассчитывать “эффективную” конфигурацию? В детали я погружаться не стану (да и не знаю я многих деталей ;) ), но общий принцип расскажу. Помните, мы уже здесь и здесь рассуждали о том, что время отклика нелинейно зависит от нагрузки. При определенном уровне утилизации, даже небольшой прирост нагрузки приведет к огромному росту Response Time. Именно точка перегиба, начиная с которой кривая начинает расти быстрее вверх, чем уходить вправо, и считается наиболее эффективным режимом работы. У систем с различными характеристиками точки перегиба находятся в разных местах.
На основе реальных замеров производительности дисков различных типов в разных RAID уже сформированы графики зависимости от нагрузки и определены точки перегиба. При расчетах оптимальной конфигурации, как только нагрузка какой-либо группы RAID превышает точку перегиба, программой автоматически добавляются дополнительные накопители. Требования производительности являются первичными. В некоторых случаях, особенно при использовании дисков SATA, утилита добавляет накопители, не дожидаясь заполнения всей доступной емкости группы RAID. В таких случаях предполагается работа в Short Stroke.
Давайте теперь сравним две конфигурации одна из которых (Baseline) состоит только из дисков FC 300GB 15K RPM в RAID5 3+1 (192 шт., 100% емкости), а другая (Drive Optimization) является сочетанием flash 200GB в RAID5 3+1 (8 шт. 3% емкости), FC 300GB 15K RPM в RAID5 3+1 (36 шт. 40% емкости) и SATA 1TB 7,2K RPM в RAID6 6+2 (16 шт. 57% емкости).
Мы видим, что Drive Optimization при 32% уменьшении стоимости (Rel Cost) дает 78% уменьшение Service Time (Rel ST) и 72% снижение энергопотребления (Rel Power).
Из графиков внизу скриншота видно, что при увеличении нагрузки различие в производительности будет еще расти.
При изменении пропорции чтения и записи ситуация изменится.
Для обеспечения такого же уровня производительности потребуется 20 накопителей flash, 64 FC и 16 SATA. Стоимость конфигурации по сравнению с Baseline, конечно, несколько увеличится до 0,75. Однако, даже в этом случае выигрыш использования композитной конфигурации очевиден.
Уменьшим нагрузку в IOPS в 4 раза.
В итоге, финансовая привлекательность конфигурации Drive Optimization станет хуже, чем у Baseline на 44%. Можно конечно попробовать подобрать другую пропорцию накопителей. Я это попробовал сделать. После череды экспериментов было установлено, что в случае низких нагрузок использование композитных конфигураций и FAST не эффективно.
Вернем нагрузку назад и попробуем изменить равномерность распределение нагрузки между томами. Вместо 95/10 поставим Skew равным 80/20.
Видно, что при низком Skew выигрыш в производительности от использования композитной конфигурации заметно уменьшился, а цена решения приблизилась к Baseline. Делаем вывод, чем более равномерно нагрузка распределена между томами, тем менее эффективным в контексте цена/производительность будет использование FAST.
Как же улучшить ситуацию? Можно поэкспериментировать и найти более оптимальное сочетание накопителей. Конфигурация Optimal дает нам очень заметный выигрыш по всем параметрам.
Конфигурация, дававшая нам в одних условиях колоссальный положительный эффект, может быть совершенно не приемлемой в других. Так, если в предыдущем примере снизить нагрузку и увеличить пропорцию операций чтения, относительная стоимость решения Optimal увеличится почти в 5 раз. Поэтому при разработке оптимальной конфигурации стоит использовать максимально точные данные о требованиях к производительности.
Ну и последнее. Разные производители для расчета эффективной конфигурации дискового массива используют свои собственные инструменты. К сожалению, EMC Tier Advisor является утилитой для внутреннего использования, так что в свободном доступе в Интернете ее не найти. Если вам интересно проверить какую-то свою конфигурацию, существуют 2 способа сделать это. Или пришлите мне все вводные и я вам посчитаю сам, или поймайте меня на предстоящем EMC Forum и потыкайте кнопки самостоятельно…
19 сентября 2010 г.
Автостопом по клаудам
Hitcher's Guide to Private Cloud... для тех, кто читал оригинал :)
Don't Panic
Geekfish
Storage Priests
9 сентября 2010 г.
Data footprint
В различной англоязычной литературе я регулярно встречал термин data footprint. Недавно, увидев его в очередной раз, я понял, что не понимаю до конца его значение и попробовал разобраться. Оказывается, этот очень емкий термин описывает достаточно актуальную проблему практически всех комплексов хранения данных. Давайте немного порассуждаем об этом...
Для начала задумаемся, каким образом потребляется емкость хранения. К примеру, рассмотрим полезные данные размером 10GB. Помещенные в некую абстрактную СУБД за счет разреженности они могут занимать заметно больший объем, скажем, 20GB. Количество данных со временем растет, и администратор СХД просто обязан выделять тома с неким запасом емкости. Допустим, в текущий момент утилизация выделенных томов равна 50%, что в итоге приводит к потреблению 40GB. Для защиты информации применяется RAID. При использовании зеркалирования нам потребуются 80GB физической емкости. Катастрофоустойчивое решение предполагает реализацию репликации на удаленный дисковый массив и потреблению дополнительных 80GB. Полное и инкрементальное резервное копирование за неделю потребует не менее 25GB, а для его выполнения в горячем режиме необходимо использовать функциональность мгновенных снимков, что в среднем увеличивает потребление ресурсов хранения еще на 20% от полезного объема. Средам тестирования и разработки также необходима физическая емкость, скажем 5GB. Итого, в нашем достаточно консервативном примере при хранении 10GB полезной информации придется выделить объем более 190GB(!).
Для обозначения такого потребляемого брутто-объема данных как раз и используется термин data footprint. Заметим, что даже небольшое сокращение объема полезных данных приведет к значительному снижению data footprint. А если потребность в данных исчезает совсем, единовременно освобождаются огромные емкости на системах хранения различного уровня (диски различных типов и RAID, ленточные библиотеки).
Большие объемы data footprint требуют значительных капитальных и оперативных затрат на приобретение и модернизацию оборудования, его сервисную поддержку, управление комплексом, энергообеспечение и т. д. Поэтому сокращение пропорции потребляемого и полезного объемов является одной из основных задач оптимизации хранения данных.
Каковы же основные методы уменьшения data footprint? В первую очередь, это сокращение объема полезных данных за счет архивирования их неактивных или устаревших частей. Когда это возможно, отличным устройством для архивирования является /dev/null, т. е. просто удаление ненужной информации ;) . Архивирование может выполняться как средствами самих приложений и СУБД (например, выгрузка информации в другую базу данных), либо такими программными продуктами, как EMC DiskXtender или SourceOne.
Другими достаточно эффективными методами являются дедупликация и компрессия данных. В настоящий момент многие системы хранения поддерживают эту функциональность в автоматическом режиме и совершенно прозрачно для пользователя. Так в дисковых массивах EMC Clariion на уровне томов можно настроить сжатие данных, а при миграции информации на “ тонкие ” тома происходит автоматическое изъятие блоков заполненных нулями (space reclamation). NAS устройства Celerra работают с компрессией и дедупликацией данных на уровне файлов (на момент написания этого поста). Заметное влияние на data footprint оказывает использование технологии мгновенных снимков вместо полных копий/клонов томов.
Очень большая часть потребляемого объема составляют емкости, выделенные “на вырост”, в расчете на увеличение количества информации в перспективе ближайших лет. Наиболее эффективный метод сокращения этих объемов является динамическое выделение ресурсов (virtual provisioning). Это функциональность позволяет не резервировать заранее дисковое пространство, а автоматически выделять его из общего пула ресурсов по мере роста данных.
Общая утилизация дисковых ресурсов и значительно оптимизируется при использовании единого консолидированного хранилища вместо нескольких обособленных дисковых массивов. Конечно такой подход благотворно влияет на оптимизацию data footprint.
И еще одно замечание напоследок. Как и любая другая, задача уменьшения потребляемого объема данных не является абсолютной самоцелью. Не стоит увлекаться и забывать о требованиях производительности, надежности и управляемости комплекса. Поиск оптимального сочетания является действительно трудной задачей... Зато не скучно… ;)
Для начала задумаемся, каким образом потребляется емкость хранения. К примеру, рассмотрим полезные данные размером 10GB. Помещенные в некую абстрактную СУБД за счет разреженности они могут занимать заметно больший объем, скажем, 20GB. Количество данных со временем растет, и администратор СХД просто обязан выделять тома с неким запасом емкости. Допустим, в текущий момент утилизация выделенных томов равна 50%, что в итоге приводит к потреблению 40GB. Для защиты информации применяется RAID. При использовании зеркалирования нам потребуются 80GB физической емкости. Катастрофоустойчивое решение предполагает реализацию репликации на удаленный дисковый массив и потреблению дополнительных 80GB. Полное и инкрементальное резервное копирование за неделю потребует не менее 25GB, а для его выполнения в горячем режиме необходимо использовать функциональность мгновенных снимков, что в среднем увеличивает потребление ресурсов хранения еще на 20% от полезного объема. Средам тестирования и разработки также необходима физическая емкость, скажем 5GB. Итого, в нашем достаточно консервативном примере при хранении 10GB полезной информации придется выделить объем более 190GB(!).
Для обозначения такого потребляемого брутто-объема данных как раз и используется термин data footprint. Заметим, что даже небольшое сокращение объема полезных данных приведет к значительному снижению data footprint. А если потребность в данных исчезает совсем, единовременно освобождаются огромные емкости на системах хранения различного уровня (диски различных типов и RAID, ленточные библиотеки).
Большие объемы data footprint требуют значительных капитальных и оперативных затрат на приобретение и модернизацию оборудования, его сервисную поддержку, управление комплексом, энергообеспечение и т. д. Поэтому сокращение пропорции потребляемого и полезного объемов является одной из основных задач оптимизации хранения данных.
Каковы же основные методы уменьшения data footprint? В первую очередь, это сокращение объема полезных данных за счет архивирования их неактивных или устаревших частей. Когда это возможно, отличным устройством для архивирования является /dev/null, т. е. просто удаление ненужной информации ;) . Архивирование может выполняться как средствами самих приложений и СУБД (например, выгрузка информации в другую базу данных), либо такими программными продуктами, как EMC DiskXtender или SourceOne.
Другими достаточно эффективными методами являются дедупликация и компрессия данных. В настоящий момент многие системы хранения поддерживают эту функциональность в автоматическом режиме и совершенно прозрачно для пользователя. Так в дисковых массивах EMC Clariion на уровне томов можно настроить сжатие данных, а при миграции информации на “ тонкие ” тома происходит автоматическое изъятие блоков заполненных нулями (space reclamation). NAS устройства Celerra работают с компрессией и дедупликацией данных на уровне файлов (на момент написания этого поста). Заметное влияние на data footprint оказывает использование технологии мгновенных снимков вместо полных копий/клонов томов.
Очень большая часть потребляемого объема составляют емкости, выделенные “на вырост”, в расчете на увеличение количества информации в перспективе ближайших лет. Наиболее эффективный метод сокращения этих объемов является динамическое выделение ресурсов (virtual provisioning). Это функциональность позволяет не резервировать заранее дисковое пространство, а автоматически выделять его из общего пула ресурсов по мере роста данных.
Общая утилизация дисковых ресурсов и значительно оптимизируется при использовании единого консолидированного хранилища вместо нескольких обособленных дисковых массивов. Конечно такой подход благотворно влияет на оптимизацию data footprint.
И еще одно замечание напоследок. Как и любая другая, задача уменьшения потребляемого объема данных не является абсолютной самоцелью. Не стоит увлекаться и забывать о требованиях производительности, надежности и управляемости комплекса. Поиск оптимального сочетания является действительно трудной задачей... Зато не скучно… ;)
Подписаться на:
Сообщения (Atom)