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.
И еще одно замечание напоследок. Как и любая другая, задача уменьшения потребляемого объема данных не является абсолютной самоцелью. Не стоит увлекаться и забывать о требованиях производительности, надежности и управляемости комплекса. Поиск оптимального сочетания является действительно трудной задачей... Зато не скучно… ;)
20 августа 2010 г.
19 августа 2010 г.
Архитектура Clariion
Когда-то написал небольшую заметку по архитектуре дисковых массивов Clariion. Может кому пригодится...
На рынке дисковых массивов среднего уровня (mid-range) компания EMC предлагает модельный ряд Clariion, который с 2002 г. активно развивается в рамках серии CX. Последним поколением этих дисковых хранилищ является CX4 UltraFlex (кодовое название Fleet). На рынке SMB предлагаются “облегченное” решение AX4. Архитектурно (но не конструктивно) эти массивы похожи на CX4 и поэтому подробно здесь рассматриваться не будут.
Clariion CX4, как и модели предыдущих серий, является модульной системой. Используются три типа модулей-полок (enclosures):
В дисковых массивах AX4 дисковая полка DAE0 совмещена с Storage Processors в единый модуль DPE (Disk Processor Enclosure).
В рамках технологии UltraFlex, для подключения к серверам (Front-end) и полкам DAE (Back-end) используются специальные интерфейсные модули (I/O modules). Их установка в SPE позволяет достаточно гибко подходить к требуемой конфигурации интерфейсов, снабжая Clariion необходимым количеством портов FC 8Gbps, iSCSI на базе 1Gbit/s или 10Gbit/s Ethernet, а также 10Gbit/s FCoE.
Интерфейс CMI (Clariion Messaging Interface) на базе PCI-express применяется для передачи команд, информации о статусе выполнения запросов между SPs, а также репликации данных кэша на запись.
Карты LCC (Link Control Card) используются для подключения полок DAE, а также функций их контроля (статус датчиков температуры, состояние дисков, включение световых индикаторов и т. д.). В зависимости от модели дискового массива, полки можно подключать посредством 2, 4, 8 или 16 Back-end петель FC_AL. Важно отметить, что в современных дисковых массивах физические петли FC_AL не используются. Вместо этого каждый порт диска подключается к LCC в режиме p-2-p (point-to-point). Процесс инициализации, FC-примитивы и обязательные элементы FC_AL эмулируются специальными контроллерами. Этот подход упрощает подключение к общей петле дисков с различными интерфейсами (FC, SATA, SAS), уменьшает латентность FC_AL, а также более эффективно изолирует ошибки.
Все операции, производимые дисковыми массивами Clariion, контролируются операционной средой FLARE. В моделях CX4 она базируется на 64-битной операционной системе Windows. Функциональность глубоко интегрирована в ОС и реализована при помощи нескольких уровней драйверов. Драйвер Access Logix обеспечивает контроль доступа серверов к логическим томам (LUN masking). Драйверы layered apps обеспечивают работу локальной и удаленной репликации SnapView, MirrorView, RecoverPoint и SAN Copy. Драйверы Flare, прежде всего, отвечают за управление логическими томами LUNs. Их объединение в MetaLUN также контролируется специальным драйвером.
Основные характеристики дисковых массивов Clariion CX4 приведены в таблице.
На рынке дисковых массивов среднего уровня (mid-range) компания EMC предлагает модельный ряд Clariion, который с 2002 г. активно развивается в рамках серии CX. Последним поколением этих дисковых хранилищ является CX4 UltraFlex (кодовое название Fleet). На рынке SMB предлагаются “облегченное” решение AX4. Архитектурно (но не конструктивно) эти массивы похожи на CX4 и поэтому подробно здесь рассматриваться не будут.
Clariion CX4, как и модели предыдущих серий, является модульной системой. Используются три типа модулей-полок (enclosures):
- SPE (Storage Processor Enclosure) содержит один или два интеллектуальных контроллера SP (Storage Processors), которые обеспечивают управление массивом, подключение к серверам и кэширование данных
- DAE (Disk Array Enclosures) имеет 15 слотов для накопителей. Диски внутри полки подключаются к двум независимым петлям FC_AL (Fibre Channel Arbitrated Loop). Дисковый массив в зависимости от модели может состоять из нескольких таких полок.
- SPS (Standby Power Supply) используются для обеспечения питания SPE и первой полки DAE на время сброса данных, находящихся в write cache, в случае проблем с электропитанием.
В дисковых массивах AX4 дисковая полка DAE0 совмещена с Storage Processors в единый модуль DPE (Disk Processor Enclosure).
В рамках технологии UltraFlex, для подключения к серверам (Front-end) и полкам DAE (Back-end) используются специальные интерфейсные модули (I/O modules). Их установка в SPE позволяет достаточно гибко подходить к требуемой конфигурации интерфейсов, снабжая Clariion необходимым количеством портов FC 8Gbps, iSCSI на базе 1Gbit/s или 10Gbit/s Ethernet, а также 10Gbit/s FCoE.
Интерфейс CMI (Clariion Messaging Interface) на базе PCI-express применяется для передачи команд, информации о статусе выполнения запросов между SPs, а также репликации данных кэша на запись.
Карты LCC (Link Control Card) используются для подключения полок DAE, а также функций их контроля (статус датчиков температуры, состояние дисков, включение световых индикаторов и т. д.). В зависимости от модели дискового массива, полки можно подключать посредством 2, 4, 8 или 16 Back-end петель FC_AL. Важно отметить, что в современных дисковых массивах физические петли FC_AL не используются. Вместо этого каждый порт диска подключается к LCC в режиме p-2-p (point-to-point). Процесс инициализации, FC-примитивы и обязательные элементы FC_AL эмулируются специальными контроллерами. Этот подход упрощает подключение к общей петле дисков с различными интерфейсами (FC, SATA, SAS), уменьшает латентность FC_AL, а также более эффективно изолирует ошибки.
Все операции, производимые дисковыми массивами Clariion, контролируются операционной средой FLARE. В моделях CX4 она базируется на 64-битной операционной системе Windows. Функциональность глубоко интегрирована в ОС и реализована при помощи нескольких уровней драйверов. Драйвер Access Logix обеспечивает контроль доступа серверов к логическим томам (LUN masking). Драйверы layered apps обеспечивают работу локальной и удаленной репликации SnapView, MirrorView, RecoverPoint и SAN Copy. Драйверы Flare, прежде всего, отвечают за управление логическими томами LUNs. Их объединение в MetaLUN также контролируется специальным драйвером.
Основные характеристики дисковых массивов Clariion CX4 приведены в таблице.
Характеристика | CX4-120 | CX4-240 | CX4-480 | CX4-960 |
CPU | 2x dual core 1,2Ghz LV-Woodcrest | 2x dual core 1,6Ghz LV-Woodcrest | 2x dual core 2,2Ghz LV-Woodcrest | 2x quad core 2,33Ghz Clovertown |
Системная память | 6 GB | 8 GB | 16 GB | 32 GB |
Максимум write cache | 598 MB | 1261 MB | 4,5 GB | 10,8 GB |
Количество I/O модулей | 6 | 8 | 10 | 12 |
Максимум 4Gbps FE FC портов | 12 | 12 | 16 | 24 |
Базовая конфигурация 4Gbps FE FC портов | 4 | 4 | 8 | 8 |
Максимум 8Gbps FE FC портов | xxx | 12 | 16 | 24 |
Максимум 1Gbit/s iSCSI портов | 8 | 12 | 12 | 16 |
Базовая конфигурация 1Gbit/s iSCSI портов | 4 | 4 | 4 | 4 |
Максимум 10Gbit/s iSCSI портов | 2 | 2 | 4 | 4 |
Максимум 10Gbit/s + 1Gbit/s iSCSI портов | 4 | 8 | 8 | 8 |
Максимум BE 4Gbps FC портов | 2 | 4 | 8 | 16 |
Базовая конфигурация BE 4Gbps FC портов | 2 | 4 | 8 | 8 |
Максимум дисков | 120 | 240 | 480 | 950 |
Максимум Throughput с дисков | 27370 IOPS | 54970 IOPS | 68417 IOPS | 95480 IOPS |
Максимум Bandwidth с дисков | 733 MB/s | 1160 MB/s | 1244 MB/s | 3020 MB/s |
10 августа 2010 г.
Windows в Clariion
Где-то с год назад я натолкнулся на очень интересный пост о набившей уже многим оскомину теме Windows в Clariion. Он был напечатан в блоге одного из девелоперов FLARE старой гвардии, известного популяризатора инновационного подхода к разработке продуктов Стива Тода. И вот я все-таки сподобился его перевести. Оригинал здесь.
"Решение о Windows
Одним из наиболее интересных моментов в дискуссиях по поводу CLARiiON является факт того, что внутри него “крутится” Windows XP embedded. Некоторые читатели спрашивали меня об этом. Также я обнаружил множество запросов в Google с попыткой найти на моем сайте побольше информации на эту тему. Многие любопытствуют, почему и когда было принято решение об использовании Windows? Ведь в 90-е годы CLARiiON не был продуктом на Windows.
Хорошо, у меня есть ответы. Предупреждаю, что они могут несколько отличаться от других ответов на эту тему, которые вы уже, возможно, получали. Мои воспоминания являются точкой зрения программного архитектора.
Как я помню, была необходимость в смене архитектуры CLARiiON по одной основной причине: конкуренция против EMC.
В конце 90-х CLARiiON был продуктом, разработанным компанией Data General. Я участвовал в создании программной архитектуры микрокода CLARiiON, известной как FLARE. Начиная с 80-х я отвечал за алгоритмы RAID, кэш на запись и обработки ошибок (горячее восстановление, переключение и обратное переключение в случае сбоев компонент), а также за все связанное с целостностью данных.
Архитектура, основанная на процессах
Первоначально программная архитектура FLARE была просто набором процессов. Для каждого диска был свой процесс. Был процесс для обработки запросов на чтение и запись от приложений на серверах. Был процесс перестроения RAID, фоновый процесс верификации, процесс для выполнения настроек и т. д. Операционная среда для всех этих процессов была самодельной проприетарной системой, которая называлась HEMI (потому, что планировщик в ней использовал полусферический (hemispherical) алгоритм).
В первые 6 или 7 лет существования мы добавляли в нее новую функциональность. Мы добавили поддержку протокола SCSI. Мы добавили поддержку дисков горячей замены. Мы добавили кэш на запись, поддержку новых уровней RAID, улучшенную производительность и добавили поддержку графического пользовательского интерфейса. Мы ушли от фиксированного количества дисков при помощи возможности добавления новых полок. Мы добавили поддержку SAN (например, LUN маскинг). Первоначальная архитектура вобрала в себя все это и доказала свою масштабируемость и сервисо-пригодность.
И по мере того, как в середине и конце 90-х рынок хранения данных просто взлетел, парни, заведующие бизнесом CLARiiON, все чаще стали посматривать на огромные прибыли, которые могли принести системы хранения верхнего уровня, такие как EMC Symmetrix. Эти продукты уже мешали друг другу в случае продаж, когда заказчик рассматривал возможность приобретения “нажнего хай-энда” либо “верхнего мидренджа”.
Symm против CLARiiON
Определенно, Symmetrix был сильным игроком и одна из основных сложностей конкуренции с ним была в том, что Symm имел возможность соединения с огромным количеством серверов (обеспечивая это большим объемом кэш). Но DG в основном думала не о аппаратном обеспечении, а о допольнительных программных возможностях, которые генерировали громадные доходы: SRDF и TimeFinder. CLARiiON не имел такой функциональности. Для все большего количества заказчиков удаленная репликация и возможность создания мгновенных снимков стали основополагающим фактором, а CLARiiON ими не обладал.
К счастью, CLARiiON имел несколько других выдающихся достоинств. Symm (в то время) не имел алгоритмов работы с RAID-5, зеркалируемого кэш на запись и не обладал простым графическим пользовательским интерфейсом (Navisphere). Но без удаленной репликации и возможностей создания мгновенных снимков CLARiiON не мог конкурировать. Удаленная репликация и мгновенные снимки указывали на то, что программная архитектура CLARiiON, основанная на процессах имеет некоторые недостатки.
Уровни против процессов
Как я уже упоминал, FLARE имел front-end процесс для обработки входящих запросов от приложений на серверах. Этот процесс также поддерживал кэш на запись. Когда данные из кэш перемещались на диск, front-end процесс должен был "открыть коннект" с соответствующим другим процессом и послать ему "сообщение". А так как количество дисков сначала возросло с 20 до 30, потом до 40 и, в конце концов, до 120, во FLARE добавлялось все большее и большее число процессов. Коннекты между всеми этими процессами реализовывались огромным количеством пайпов, через которые пересылалось чудовищное количество сообщений.
Решение о том, куда все-таки вставить функциональность удаленной репликации и мгновенных снимков, не было очевидным. Добавление нового процесса привело бы к еще большим “пляскам с балалайкой”. Модификация существующих процессов размыло бы четкие границы архитектуры и нарушила бы инкапсуляцию функций. Существовали опасения насчет производительности и поддержки архитектуры.
Было бы здорово, если бы FLARE поддерживала “включение” этой функциональности более реализуемым способом не тревожа функциональность таких компонент как кэш на запись и алгоритмы RAID. Ну, типа как в многоуровневой реализации поддержки устройств. Эй, а разве Windows не использует отличную многоуровневую модель стека устройств?
Реакция на решение
Вы можете себе представить, с каким скептицизмом внутри компании было встречено известие о переводе FLARE на Windows embedded. На вопросы о том, будет ли FLARE показывать заказчикам “синие экраны” в шутку отвечали: “мы просто не собираемся для этого поставлять экраны” ;>). Мягко говоря, это было несколько спорное внутренне решение.
Заказчики также отнеслись к нему скептически. Один из наших вице-президентов встречался со многими клиентами, которые регулярно задавали ему вопросы об уровне качества нового продукта. К его чести, он признавал, что переход на новую архитектуру в самом начале может вызвать некоторые проблемы с качеством. Однако, DG и не имело причин скрывать проблемы с качеством, т. к. в заднем кармане у нее был такой козырь, как DAQ. ПО Disk Array Qualifier все еще гоняет свой комплект тестов целостности данных и проверяет на прочность новые решения на базе Windows. DAQ запускался как на старой, так и на новой архитектуре благодаря так называемым “крючкам качества” которые всегда были частью FLARE и которые работали на Windows. Кэш на чтение мог быть полностью протестирован.
Это удовлетворяло опасения заказчиков. И когда они поняли, что многоуровневый стек устройств обеспечивает, во первых, лучшую производительность и, во вторых, возможность внедрения функциональности в конкретный уровень не затрагивая другой существующий код, они начали инвестировать в новую архитектуру.
Это работает
Разработчики программного обеспечения для CLARiiON проделали отличную работу перегруппируя различные части процессов архитектуры HEMI в разные уровни стека драйверов Windows. Производительность была превосходной (особенно после того, как кэш на запись был портирован без проблем). Новые драйвера устройств удаленной репликации и мгновенных снимков реализованы в виде уровней поверх базовой функциональности HEMI.
Смелое решение оправдало себя. DG было приобретено EMC. На сколько хорошо EMC продало решение, основанное на Windows? Посмотрите последний пресс-релиз об анонсе массивов CX в начале августа (прим. пост был опубликован 28 августа 2008 г.). EMC докладывает о продаже более, чем 300000 CLARiiON, каждый из которых имеет доступность 99.999. Качество , производительность, гибкость и доход. Откровенно говоря, более 300000 CLARiiON, работающих по всему миру, все еще удивляют меня. Вот что случается, когда стораджевый продукт куплен стораджевой компанией.
Дополнительные многоуровневые драйверы разрабатывались годами и о некоторых из них я надеюсь написать в будущих постах.
Стив"
PS Кстати, в прошлом году я немного пообщался со Стивом в питерском центре разработки EMC. Надо сказать, очень обаятельный и увлеченный своим делом дядька...
"Решение о Windows
Одним из наиболее интересных моментов в дискуссиях по поводу CLARiiON является факт того, что внутри него “крутится” Windows XP embedded. Некоторые читатели спрашивали меня об этом. Также я обнаружил множество запросов в Google с попыткой найти на моем сайте побольше информации на эту тему. Многие любопытствуют, почему и когда было принято решение об использовании Windows? Ведь в 90-е годы CLARiiON не был продуктом на Windows.
Хорошо, у меня есть ответы. Предупреждаю, что они могут несколько отличаться от других ответов на эту тему, которые вы уже, возможно, получали. Мои воспоминания являются точкой зрения программного архитектора.
Как я помню, была необходимость в смене архитектуры CLARiiON по одной основной причине: конкуренция против EMC.
В конце 90-х CLARiiON был продуктом, разработанным компанией Data General. Я участвовал в создании программной архитектуры микрокода CLARiiON, известной как FLARE. Начиная с 80-х я отвечал за алгоритмы RAID, кэш на запись и обработки ошибок (горячее восстановление, переключение и обратное переключение в случае сбоев компонент), а также за все связанное с целостностью данных.
Архитектура, основанная на процессах
Первоначально программная архитектура FLARE была просто набором процессов. Для каждого диска был свой процесс. Был процесс для обработки запросов на чтение и запись от приложений на серверах. Был процесс перестроения RAID, фоновый процесс верификации, процесс для выполнения настроек и т. д. Операционная среда для всех этих процессов была самодельной проприетарной системой, которая называлась HEMI (потому, что планировщик в ней использовал полусферический (hemispherical) алгоритм).
В первые 6 или 7 лет существования мы добавляли в нее новую функциональность. Мы добавили поддержку протокола SCSI. Мы добавили поддержку дисков горячей замены. Мы добавили кэш на запись, поддержку новых уровней RAID, улучшенную производительность и добавили поддержку графического пользовательского интерфейса. Мы ушли от фиксированного количества дисков при помощи возможности добавления новых полок. Мы добавили поддержку SAN (например, LUN маскинг). Первоначальная архитектура вобрала в себя все это и доказала свою масштабируемость и сервисо-пригодность.
И по мере того, как в середине и конце 90-х рынок хранения данных просто взлетел, парни, заведующие бизнесом CLARiiON, все чаще стали посматривать на огромные прибыли, которые могли принести системы хранения верхнего уровня, такие как EMC Symmetrix. Эти продукты уже мешали друг другу в случае продаж, когда заказчик рассматривал возможность приобретения “нажнего хай-энда” либо “верхнего мидренджа”.
Symm против CLARiiON
Определенно, Symmetrix был сильным игроком и одна из основных сложностей конкуренции с ним была в том, что Symm имел возможность соединения с огромным количеством серверов (обеспечивая это большим объемом кэш). Но DG в основном думала не о аппаратном обеспечении, а о допольнительных программных возможностях, которые генерировали громадные доходы: SRDF и TimeFinder. CLARiiON не имел такой функциональности. Для все большего количества заказчиков удаленная репликация и возможность создания мгновенных снимков стали основополагающим фактором, а CLARiiON ими не обладал.
К счастью, CLARiiON имел несколько других выдающихся достоинств. Symm (в то время) не имел алгоритмов работы с RAID-5, зеркалируемого кэш на запись и не обладал простым графическим пользовательским интерфейсом (Navisphere). Но без удаленной репликации и возможностей создания мгновенных снимков CLARiiON не мог конкурировать. Удаленная репликация и мгновенные снимки указывали на то, что программная архитектура CLARiiON, основанная на процессах имеет некоторые недостатки.
Уровни против процессов
Как я уже упоминал, FLARE имел front-end процесс для обработки входящих запросов от приложений на серверах. Этот процесс также поддерживал кэш на запись. Когда данные из кэш перемещались на диск, front-end процесс должен был "открыть коннект" с соответствующим другим процессом и послать ему "сообщение". А так как количество дисков сначала возросло с 20 до 30, потом до 40 и, в конце концов, до 120, во FLARE добавлялось все большее и большее число процессов. Коннекты между всеми этими процессами реализовывались огромным количеством пайпов, через которые пересылалось чудовищное количество сообщений.
Решение о том, куда все-таки вставить функциональность удаленной репликации и мгновенных снимков, не было очевидным. Добавление нового процесса привело бы к еще большим “пляскам с балалайкой”. Модификация существующих процессов размыло бы четкие границы архитектуры и нарушила бы инкапсуляцию функций. Существовали опасения насчет производительности и поддержки архитектуры.
Было бы здорово, если бы FLARE поддерживала “включение” этой функциональности более реализуемым способом не тревожа функциональность таких компонент как кэш на запись и алгоритмы RAID. Ну, типа как в многоуровневой реализации поддержки устройств. Эй, а разве Windows не использует отличную многоуровневую модель стека устройств?
Реакция на решение
Вы можете себе представить, с каким скептицизмом внутри компании было встречено известие о переводе FLARE на Windows embedded. На вопросы о том, будет ли FLARE показывать заказчикам “синие экраны” в шутку отвечали: “мы просто не собираемся для этого поставлять экраны” ;>). Мягко говоря, это было несколько спорное внутренне решение.
Заказчики также отнеслись к нему скептически. Один из наших вице-президентов встречался со многими клиентами, которые регулярно задавали ему вопросы об уровне качества нового продукта. К его чести, он признавал, что переход на новую архитектуру в самом начале может вызвать некоторые проблемы с качеством. Однако, DG и не имело причин скрывать проблемы с качеством, т. к. в заднем кармане у нее был такой козырь, как DAQ. ПО Disk Array Qualifier все еще гоняет свой комплект тестов целостности данных и проверяет на прочность новые решения на базе Windows. DAQ запускался как на старой, так и на новой архитектуре благодаря так называемым “крючкам качества” которые всегда были частью FLARE и которые работали на Windows. Кэш на чтение мог быть полностью протестирован.
Это удовлетворяло опасения заказчиков. И когда они поняли, что многоуровневый стек устройств обеспечивает, во первых, лучшую производительность и, во вторых, возможность внедрения функциональности в конкретный уровень не затрагивая другой существующий код, они начали инвестировать в новую архитектуру.
Это работает
Разработчики программного обеспечения для CLARiiON проделали отличную работу перегруппируя различные части процессов архитектуры HEMI в разные уровни стека драйверов Windows. Производительность была превосходной (особенно после того, как кэш на запись был портирован без проблем). Новые драйвера устройств удаленной репликации и мгновенных снимков реализованы в виде уровней поверх базовой функциональности HEMI.
Смелое решение оправдало себя. DG было приобретено EMC. На сколько хорошо EMC продало решение, основанное на Windows? Посмотрите последний пресс-релиз об анонсе массивов CX в начале августа (прим. пост был опубликован 28 августа 2008 г.). EMC докладывает о продаже более, чем 300000 CLARiiON, каждый из которых имеет доступность 99.999. Качество , производительность, гибкость и доход. Откровенно говоря, более 300000 CLARiiON, работающих по всему миру, все еще удивляют меня. Вот что случается, когда стораджевый продукт куплен стораджевой компанией.
Дополнительные многоуровневые драйверы разрабатывались годами и о некоторых из них я надеюсь написать в будущих постах.
Стив"
PS Кстати, в прошлом году я немного пообщался со Стивом в питерском центре разработки EMC. Надо сказать, очень обаятельный и увлеченный своим делом дядька...
5 августа 2010 г.
20% Guaranteed
Пара забавных рекламных роликов о платформе EMC Unified Storage. Если не получите 20%, требуйте в магазине возврата товара... :)
Про гольф:
Про превышение скорости:
Про гольф:
Про превышение скорости:
Подписаться на:
Сообщения (Atom)