FYI
К сожалению, только для Питерцев... :( ну, а тем кому повезло ;) , настоятельно рекомендую...
-----Original Message-----
From: emc-academic-alliance-russia-newsletters@googlegroups.com
Sent: Monday, October 04, 2010 10:41 PM
To: EMC Academic Alliance Russia Newsletters
Subject: EMC Academic Alliance Russia Newsletter #35/10
Уважаемые коллеги!
Сотрудник корпорации ЕМС Стив Тод (Steve Todd)
http://stevetodd.typepad.com/my_weblog/steve-todd-curriculum-vitae.html
занимает должность инженера.
Однако его интересы простираются далеко за пределы его должностных
функций.
Его врожденные способности к систематизации информации и искренний
интерес к информационным технологиям, вместе со способностями к работе
с аудиторией привели к тому, что Стив
- написал и издал книгу по основам корпоративного предпринимательства,
- регулярно проводит публичные выступления как перед сотрудниками
различных подразделений корпорации, так и перед сотрудниками других
корпораций и студенческой аудиторией различных стран.
Стив приезжал и в Россию год назад.
Его выступление запомнилось непринужденностью обстановки, яркой
харизмой и умением просто рассказать о сложном.
Уверен, те кто был на встрече с Тодом захотят прийти снова.
Не только захватывающе, но и поучительно посмотреть как технический
специалист может позиционировать себя в качестве собеседника и
соучастника.
Встречайте:
Стив Тодд, заслуженный инженер компании EMC, прочитает лекцию "Global
High-Tech Innovations" сразу в двух петербургских вузах:
7 октября в четверг в 16 30 в Санкт-Петербургском государственном
университете информационных технологий, механики и оптики (ИТМО,
Кронверский пр, актовый зал)
и
8 октября в пятницу в 13 00 в Санкт-Петербургском государственном
университете (СПБГУ, Петергоф, Университетский пр., д.28, мат-мех,
ауд. 405)
Стив Тодд является заслуженным инженером в корпорации EMC. Созданная
им программная реализация технологии RAID была одной из первых и
наиболее успешных за всю историю индустрии хранения данных. В мире
установлено более полумиллиона устройств хранения CLARiiON, которые
защищают наиболее важную и критичную информацию планеты с помощью
созданных Стивом алгоритмов. Стив является (со)автором более чем 160
патентов в различных областях информационных технологий.
Лекция будет посвящена следующим основным вопросам:
- Глобализация инноваций
- Последние инновационные достижения в мире, созданные разработчиками
программного обеспечения
- Изменение корпоративной культуры в области инноваций на примере
корпорации EMC
- Советы по успешной карьере в области ИТ
Блог Стива Тодда: http://bit.ly/aaMVWi
Книга Стива Тодда "Инновации, влияющие на мир" http://www.booklocker.com/books/4145.html
Регистрация:
http://vkontakte.ru/event20037521 - ИТМО
http://vkontakte.ru/event20043544 - СПБГУ
PS. Встреча пройдет на хорошем международном английском языке. Перевод и запись ранее обсуждались, но положительного решения пока нет
4 октября 2010 г.
3 октября 2010 г.
Приостановка передачи в SAN
Один из читателей блга прислал мне чрезвычайно интересный вопрос по поводу приостановки передачи данных в фабрике. Дмитрий, большое спасибо.
Ответом я решил поделиться со всеми и сделал из него такой короткий пост. Сори, если он получился слишком техническим и не понятным…
Одними из наиболее распространенных причин приостановки передачи данных в фабрике сети SAN являются процессы перестроения (Build Fabric) и реконфигурации фабрики (Reconfigure Fabric).
Для начала разберемся в принципиальных различиях между ними.
Процесс Build Fabric (BF) является не разрушающим (non-disruptive), т. е. хотя передача данных на какой-то небольшой период времени приостанавливается, но никакая информация не теряется. Это связано с тем, что списки Domain ID не обнуляются и адресация всех устройств гарантированно сохраняется. Principal Switch, приоритеты и маршруты передачи остаются прежними. Открытые exchange не сбрасываются.
Процесс Reconfigure Fabric (RCF), напротив, является разрушающим (disruptive) и передаваемые данные всегда теряются. Ведь списки Domain ID непременно сбрасываются и Domain ID назначаются заново. Если Domain ID какого-либо коммутатора изменился, после обязательного повторного логина в фабрику всех оконечных устройств изменятся и адреса соответствующих N-портов. При RCF весь трафик класса F прерывается. Обязательно начинается процесс перевыборов Principal Switch. По времени RCF продолжительнее, чем BF.
Ниже приведены несколько примеров ситуаций, для разрешения которых используются эти процессы.
Избежать задержек передачи данных в результате BF или RCF не возможно. Ведь эти процессы предназначены для обеспечения жизнедеятельности самой фабрики. Однако, в некоторых случаях можно значительно сократить время BF и минимизировать его влияние на коммутаторы. Так, в коммутаторах Cisco при включенной опции fast restart, выход из строя Principal Link не вызывает полноценный Build Fabric. Если между коммутаторам существует дублирующий линк, то процесс его назначения Principal Link затронет не всю VSAN, а только два соответствующих коммутатора и займет всего несколько миллисекунд. Если дублирующего линка нет, то опция, конечно не поможет…
Остается вопрос, как же все-таки минимизировать воздействие описанных выше процессов на SAN? Ответ вы, конечно, знаете сами. Обязательное построение сети хранения в виде двух физически или логически (VSAN) изолированных друг от друга redundant фабрики вкупе с ПО multipathing!!!
Добавлено Brocade утверждает,что в современных релизах FOS Reconfigure Fabric никогда не происходит. Охотно верю.
Ответом я решил поделиться со всеми и сделал из него такой короткий пост. Сори, если он получился слишком техническим и не понятным…
Одними из наиболее распространенных причин приостановки передачи данных в фабрике сети SAN являются процессы перестроения (Build Fabric) и реконфигурации фабрики (Reconfigure Fabric).
Для начала разберемся в принципиальных различиях между ними.
Процесс Build Fabric (BF) является не разрушающим (non-disruptive), т. е. хотя передача данных на какой-то небольшой период времени приостанавливается, но никакая информация не теряется. Это связано с тем, что списки Domain ID не обнуляются и адресация всех устройств гарантированно сохраняется. Principal Switch, приоритеты и маршруты передачи остаются прежними. Открытые exchange не сбрасываются.
Процесс Reconfigure Fabric (RCF), напротив, является разрушающим (disruptive) и передаваемые данные всегда теряются. Ведь списки Domain ID непременно сбрасываются и Domain ID назначаются заново. Если Domain ID какого-либо коммутатора изменился, после обязательного повторного логина в фабрику всех оконечных устройств изменятся и адреса соответствующих N-портов. При RCF весь трафик класса F прерывается. Обязательно начинается процесс перевыборов Principal Switch. По времени RCF продолжительнее, чем BF.
Ниже приведены несколько примеров ситуаций, для разрешения которых используются эти процессы.
- Новый коммутатор с чистым списком Domain ID присоединяется к уже функционирующей фабрике. Ему нужно назначить Domain ID, поэтому начнется процесс BF.
- Сливаются две продуктивные фабрики, имеющие собственные списки Domain ID. При этом, одинаковых Domain ID в этих фабриках нет. В этом случае необходимо вместо двух независимых Principal Switch выбрать один. В ходе процесса BF выбирается новый единый Principal Switch.
- Предыдущий случай, но в фабриках есть совпадающие Domain ID. Конфликт надо разрешить, поэтому начинается процесс RCF.
- Соединяются два новых коммутатора с девственно чистыми списками Domain ID. Начинаются выборы Principal Switch и, соответственно, процесс BF (или RCF).
- Если по каким-то причинам разрывается upstream principal ISL. Для нахождения альтернативного пути запускается BF. Если такой путь не найден, то после BF проходит RCF.
- Если какой-то коммутатор пытается достигнуть Domain ID, которого нет в фабрике, Principal Switch начинает RCF.
- В случае наличия сегментированных портов, модернизация микрокода может вызвать BF или даже RCF.
- При разрыве trunk master в 1Gbps и 2Gbps коммутаторов Brocade запускается BF.
- Если Principal Switch выключился или начал перегружаться, начинаются перевыборы и процесс RCF.
- Если по какой-то причине процесс BF закончился не удачно (не были получены пакеты подтверждения), начинается RCF.
- В коммутаторах Cisco вы можете принудительно вручную рестартовать домен. При disruptive restart запускается RCF, при nondisruptive restart – BF. Сделать disruptive restart обязательно придется, если захочется сменить текущее значение Domain ID (например, для разрешения конфликта). Изменение параметра Preferred Domain ID по понятным причинам потребует всего лишь nondisruptive restart.
Избежать задержек передачи данных в результате BF или RCF не возможно. Ведь эти процессы предназначены для обеспечения жизнедеятельности самой фабрики. Однако, в некоторых случаях можно значительно сократить время BF и минимизировать его влияние на коммутаторы. Так, в коммутаторах Cisco при включенной опции fast restart, выход из строя Principal Link не вызывает полноценный Build Fabric. Если между коммутаторам существует дублирующий линк, то процесс его назначения Principal Link затронет не всю VSAN, а только два соответствующих коммутатора и займет всего несколько миллисекунд. Если дублирующего линка нет, то опция, конечно не поможет…
Остается вопрос, как же все-таки минимизировать воздействие описанных выше процессов на SAN? Ответ вы, конечно, знаете сами. Обязательное построение сети хранения в виде двух физически или логически (VSAN) изолированных друг от друга redundant фабрики вкупе с ПО multipathing!!!
Добавлено Brocade утверждает,что в современных релизах FOS Reconfigure Fabric никогда не происходит. Охотно верю.
23 сентября 2010 г.
vSpecialist
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
текст
Этика работы в группе "you’ll work your buns off, but will be part of something fun" (ты будешь работать как проклятый, но станешь частью чего-то интересного).
Да, чуть не забыл... опыт чтения рэпа обязателен... ;)
We’re number #1
vSpecialist we get the job done
текст
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 |
Подписаться на:
Сообщения (Atom)