21 декабря 2010 г.

Коммутаторы Brocade 16Gbps

Declaimer: за что купил, за то и продаю. До официального релиза, все это слухи, слухи… а меня в этот раз подписывать ничего не заставляли, так что…

Компания Brocade уже с лета говорит о том, что в начале 2011 г. появятся коммутаторы 16Gbps. В этом посте немного подробностей о новых продуктах.

Коммутаторы 16Gbps построены на новых ASIC Condor 3 (будут ли Goldeneye 3 я, честно говоря, не знаю). В контексте эволюции поколений эти ASIC являются шестым поколением.

Поколение ASIC
1
2
3
4

5
6
7
ASIC
Stitch
Loom
Bloom, Bloom-II
Condor / Goldeneye
Egret
Condor 2 / Goldeneye 2
Condor 3
?
Количество портов ASIC
2
4
8
32 / 24
bridge chip 3x4Gbps в 12,75Gbps 
40 / 24
48

Год выхода
1997
1999
2001
2004
2007
2008
2011
2014
Кол-во портов
2
4
8
32 / 24

40 / 24


Transfer Rate
1,063Gbps
1,063Gbps
2,126Gbps
4,252Gbps
12,75Gbps
8,5Gbps
14,025Gbps
28,05Gbps
Кодирование
8B/10B
8B/10B
8B/10B
8B/10B
64B/66B
8B/10B
64B/66B
64B/66B
Теоретическая макс. Bandwidth half duplex
100 MB/s
100 MB/s
200 MB/s
400 MB/s

800 MB/s
1600 MB/s
3200 MB/s
Реальная макс. Bandwidth half duplex
90 MB/s
95 MB/s
190 MB/s
380 MB/s

760 MB/s
1552 MB/s
3104 MB/s
Внешние модули коммутаторов
GBIC
GBIC
SFP
SFP
XFP
SFP+
SFP+
SFP+
Длина линков OM3 Link
860
860
500
380
300
150
100
60


48 портов Condor 3 работают в режимах 2GFC, 4 GFC, 8 GFC, 10 GFC и 16 GFC (обратите внимание 1 GFC больше не поддерживается, зато поддерживается 10 GFC). По типам, порты могут быть EX/E/F/M/D.
Пропускная способность 768Gbps позволяет передавать до 350 млн. фреймов в сек.

Важной особенностью нового ASIC является использование не классического кодировании 8b/10b, а более экономного 64b/66b. Группа ANSI T11 решила, что теперь именно такой способ кодирования будет стандартом для 10G Ethernet и 16G FC. Это позволяет снизить накладные расходы на кодирование с 25% до 3%.
Как вы помните у Brocade уже были платы с 10GFC на чипах Egret, в которых также использовалось кодирование 64b/66b. Однако, они не были обратно совместимы с классическими 1,2,4,8Gbps, использующими 8b/10b. В отличии от Egret, новый Condor 3 будет совместим с 2,4,8Gbps. Правда, на сколько я понял, 8b/10b-64b/66b autonegotiation работать не будет.

Буферы портов сделаны в 4 раза больше - 8KB (для чего это нужно, я пока не понял). Общего количества буферов хватит для передачи данных на расстояния до 21000 км.
С FOS 7.0 (предположительно, Q2/2011) появится новая функциональность обнаружения и восстановления потерянных буферных кредитов на уровне Virtual Channels. В Condor 2 такая функциональность работала только на уровне портов.

Количество Virtual Channels (VCs) увеличено до 40.
В trunk как и раньше можно объединять до 8x ISLs (в сумме 128Gbps).

В качестве дополнительных вкусностей Condor 3 поддерживает:
  • Шифрование данных E-порт в E-порт на лету (алгоритм AES-GCM, 256bit ключи) (вроде, будет поддерживаться только с FOS 7.0, Q2/2011)
  • Компрессия данных E-порт в E-порт (алгоритм McLZO, дополнительная лицензия не нужна) (вроде, будет поддерживаться только с FOS 7.0, Q2/2011)
  • Совместимость с 10G Ethernet

Что пока известно о продуктах? Будут объявлены директоры DCX 8510, коммутаторы 6510 и 16Gbps HBA. Надеюсь, что маркетинг Brocade все-таки изменит эти интуитивно непонятные названия, например на какой-нибудь DCX+ ;) .

Директоры Brocade DCX 8510-8 и DCX 8510-4:
  • Максимум до 384 портов 16Gbps
  • Платы FC16-32 и FC16-48
  • C FOS 7.0 (предположительно, Q2/2011) поддержка плат FC8-64 (все знают , что такие уже вышли? ;) ), FX8-24 (маршрутизация), FS8-18 (шифрование) и FCoE10-24 (FCoE)
  • C FOS 7.0 update (предположительно, Q4/2011) поддержка плат FC8-32 и FC8-48 (жаль, что поздновато)
  • Общая пропускная способность - 8.2Tbps
  • Пропускная способность на слот - 512Gbps
  • Архитектура такая же, как и в 8Gbps DCX: 8x ASICs на платах CR и по 2x ASICs на платах ввода-вывода
  • 32x 64Gbps QSFP ICL в директорах DCX 8510-8
  • 16x 64Gbps QSFP ICL в директорах DCX-8510-4
  • Общая пропускная способность ICL - 2Tbps (в 4x раза больше, чем в директорах 8Gbps)
  • C FOS 7.0 поддержка для подключения к ICL универсальных оптических кабелей (до 50 метров)
  • Объединение до 5x директоров при помощи ICL в топологию mesh (можно организовывать core-edge прямо на ICL, правда, oversubscription все равно будет)
  • Лицензия ICL ports-on-demand

Коммутаторы Brocade 6510
  • Размер 1U
  • 48 портов 16Gbps FC
  • Общая пропускная способность - 768Gbps

HBAs Brocade 16 Gbps:
  • До 1600 MB/sec и 500K IOPs на порт
  • Поддержка функциональности SR-IOV, QoS, N_Port Trunking

12 октября 2010 г.

ИТ-афоризмы

Во натолкнулся на несколько забавностей...  :)

“A fool with a tool is still a fool.”
Дурак с инструментом…  все равно дурак.

“Know what you are automating before you automate it.”
Узнайте, что вы автоматизируете, до того, как начнете автоматизировать.

“Real men don't click.”
Реальные пацаны не кликают. (в смысле пользуются только CLI ;) )

“Windows is like a submarine. As soon you open up a window, the problems begins”
Windows как подводная лодка: проблемы начинаются сразу, как только вы откроете окно.

You can have it done right, cheap, or quick. Pick two.
Вам все сделают правильно, дешево и быстро…  (подчеркните только два варианта)

“OSI layer 8 error”.
Ошибка восьмого уровня модели OSI.

“Nothing is permanent, except for temporary solutions.”
Ничто так не постоянно, как временное.

“There are only 2 types of people..people that have experienced a harddisk crash and people that are going to expierence a harddisk crash!”
Существуют всего 2 типа людей: те, кто не понаслышке знает, что такое крэш диска, и те, кто уже скоро об этом узнают…

"There are only 10 types of people in the world: Those who understand binary, and those who don't"
В мире существуют только 10 типов людей: тех кто понимает двоичное исчисление и тех кто нет.

10 октября 2010 г.

Нет повода не...

Сегодня я совершенно случайно обнаружил, что день-то праздничный. Это, конечно, не День взятия Бастилии, но повод закусить, определенно, есть... :) По календарю сегодняшнее число 10.10.10. Безмерно ликовать и радоваться можно по двум причинам:

-во первых, 101010 само по себе красиво. Особенно, если вспомнить об этом в 10:10...

-а во вторых, любой ИТ-шник сразу переведет его из bin в dec и получит... о чудо... 42 !!! , что, как всем известно, есть ответ на "Самый главный вопрос жизни, Вселенной и вообще"... ;)  

PS я вот все думаю над вопросом...  %(   может "приборы?"

PPS "Life, the Universe & Tape or Disk" еще раз, для тех кто читал оригинал..  :)))

8 октября 2010 г.

Статья "Эффективное хранение данных"

Журнал опубликовал мою статейку. Исключительно в целях бессмысленного повышения энтропии Вселенной запощу ее и сюда  ;) . Оригинал здесь.

PS мне сказали, что название должно быть именно таким...  :)  от этого и плясал...

"Люди общаются друг с другом посредством слов. Однако некоторые слова от частого использования затираются и теряют свой смысл. От регулярного бездумного употребления превратилось в бессмыслицу и слово “эффективность”. Мы постоянно видим его в маркетинговых брошюрах, слышим в докладах конференций и презентациях продуктов. Постепенно слово перестало что-либо означать, стало просто обязательным атрибутом расхваливания товаров.

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

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

Начнем с обсуждения очень актуальной проблемы. Мир тонет. Наша маленькая планета буквально захлебывается в колоссальных объемах данных, которые с каждым годом увеличиваются в сумасшедшей прогрессии. Для борьбы с потопом можно, конечно, использовать самый простой метод — постоянно приобретать новые емкости, тем самым, увеличивая доступное пространство хранения. К сожалению, этот способ хорош только на первых порах. После достижения некого критического уровня суммарных емкостей в любой компании остро встают вопросы роста капитальных и операционных затрат (из-за необходимости увеличения площадей серверных комнат для размещения нового оборудования), увеличения численности группы администрирования СХД и поиска дефицитных дорогостоящих “стораджевиков”. Каждый год приходится выкладывать все возрастающие суммы на сервисную поддержку. Мониторинг такого комплекса и управление им превращаются в кошмар. Начинают играть заметную роль факторы, которые раньше совсем не принимались во внимание. Например, стоимость электропитания или отвод тепла из серверной. Безрадостная картина, не правда ли?

К счастью, кроме способа экстенсивного расширения ресурсов существует метод их более интенсивного использования. Для начала задумаемся, каким образом потребляется емкость хранения. Для примера рассмотрим полезные данные размером 1 Tбайт. Помещенные в некую СУБД за счет разреженности они могут занимать заметно больший объем, скажем 2 Tбайт. Объем данных со временем растет, и администратор СХД просто обязан выделять тома с неким запасом по емкости. Допустим, в текущий момент утилизация выделенных томов равна 50%, что в итоге приводит к потреблению 4 Tбайт. Для защиты информации применяется RAID. При использовании зеркалирования RAID10 нам потребуются 8 Tбайт физической емкости. Катастрофоустойчивое решение предполагает реализацию репликации на удаленный дисковый массив, и это приводит к потреблению дополнительных 8 Tбайт. Полное и инкрементальное резервное копирование за неделю потребует не менее 2,5 Tбайт, а для его выполнения в горячем режиме необходимо использовать функциональность мгновенных снимков, что в среднем увеличивает потребление ресурсов хранения еще на 20% от полезного объема. Средам тестирования и разработки также нужна физическая емкость, скажем 500 Гб в RAID5. Итого, в нашем примере при хранении 1 Tбайт полезной информации придется выделить объем более 19 Tбайт. В англоязычной литературе для обозначения потребляемого брутто-объема данных используется термин data footprint. Интересно, что даже небольшое сокращение объема полезных данных, например за счет их архивирования, приведет к значительному снижению потребляемой емкости.

Сокращение data footprint заметно снижает капитальные и операционные затраты и поэтому является одной из основных задач оптимизации хранения данных. Давайте рассмотрим две современных технологии, которые компания EMC предлагает для решения этой задачи: динамическое выделение ресурсов хранения (virtual provisioning) и компрессия данных.

Динамическое выделение ресурсов хранения позволяет не резервировать заранее дисковое пространство под рабочие тома, а автоматически делать это из общего пула ресурсов по мере роста данных. В дисковых массивах CLARiiON в новой 30-й версии операционной среды Flare функциональность пулов была значительно расширена. Поддерживаются RAID 5, 6 и 10. В пуле можно одновременно создавать как классические чуть более производительные “толстые” тома с предварительным резервированием ресурсов, так и динамические “тонкие” тома. Оптимизирована технология динамического расширения пулов при добавлении новых дисков. Теперь это происходит без использования функциональности MetaLUN.

Если серверы заказчика работают с операционной системой Windows Server 2008, для сокращения data footprint в пулах можно применить технологию изъятия неиспользуемых ресурсов томов (LUN shrink). Видимый размер тома уменьшается мгновенно. Реальное же его сокращение реализуется в дисковом массиве при помощи фоновых процессов, которые выискивают 8-Kбайт блоки, заполненные нулями, и возвращают их обратно в пул.

Подобная технология подойдет и владельцам других операционных систем. Для освобождения неиспользуемых ресурсов рекомендуется провести миграцию данных на “тонкие” тома. При этом 8-Kбайт блоки нулей, как и в случае технологии LUN shrink, возвращаются в общий пул. Данная функциональность работает и при миграции данных с других дисковых массивов с помощью SANcopy.

Стоит заметить, что применение общего пула позволяет значительно сократить время создания и расширения ресурсов хранения, тем самым в долговременной перспективе заметно снизить затраты на администрирование комплекса.

Для дополнительного снижения потребляемой емкости можно воспользоваться компрессией томов. При включении эта функциональность совершенно прозрачно для пользователя перемещает данные на “тонкие” тома, освобождая неиспользуемые ресурсы. Во время такой миграции прямо “на лету” обнаруживаются и сжимаются повторяющиеся элементы данных в блоках по 64 Kбайт. К блокам, в которых можно сжать менее 8 Кбайт данных, компрессия не применяется. В дальнейшем для снижения нагрузки на дисковый массив компрессия работает в фоновом режиме, но не постоянно, а только при достижении пороговых значений. Процесс начинается при любом из двух условий: было изменено 10% данных тома или модифицировано 10 Гб информации. При чтении данных сжатая информация загружается в кэш и там автоматически распаковывается. Данные на диске остаются в компрессированном виде. Для контроля нагрузки на процессоры дискового массива каждому тому можно устанавливать один из трех приоритетов. При низком приоритете дополнительная загрузка CPU не превышает 15%.

Независимое тестирование компании Enterprise Strategy Group показало, что 100- Гб том с файловой системой NTFS, заполненный 75 Гб различных данных (видео, документы MS Office, текст, бинарные файлы), после применения компрессии стал занимать всего 54 Гб. Поразительные результаты, правда? Другие тесты показывают, что особенно эффективно использовать сжатие данных в виртуальной среде VMware.

В NAS-устройствах хранения EMC Celerra потребляемую емкость можно сократить за счет одновременного применения компрессии на уровне блоков и дедупликации файлов. Эффект экономии дискового пространства может достигать 50%. Как это работает? Специальный фоновый процесс сканирует устройство хранения и по характеристикам последнего времени доступа и модификации идентифицирует неактивные файлы. Далее такие файлы сжимаются при помощи механизма компрессии, аналогичному используемому в дисковых массивах CLARiiON. Одновременно с этим выполняется вычисление уникального хэша данных файла. Результат записывается в специальную скрытую область. Если хэшы нескольких файлов совпадают, то вместо всех дублированных копий записываются короткие ссылки на оригинальные данные. При модификации файлов перестраиваются ссылки только на измененные блоки. Такой подход позволяет значительно повысить скорость доступа к файлам большого размера.

Еще один эффективный способ сокращения издержек на хранение данных и понижения общей стоимости владения (TCO) — это динамическое выделение ресурсов в зависимости от ценности информации и требований производительности доступа к ней. Именно для этих целей компания EMC предлагает технологию FAST (Fully Automated Storage Tiering), которая позволяет автоматизировать перемещение данных в соответствии с уровнем активности доступа к ним. Вкратце рассмотрим, как это работает. В единый пул ресурсов могут быть объединены накопители трех разных типов flash (EFD), FC и SATA. Дисковый массив постоянно осуществляет мониторинг загрузки томов, на которых включена функциональность FAST, и в соответствии с активностью доступа к ним перемещает блоки данных на наиболее подходящий уровень хранения. “Горячие” данные попадают на производительные накопители flash. Редко требуемые размещаются на дисках SATA. Для обеспечения оптимального соотношения гранулярности перемещения и уменьшения дополнительных накладных расходов, связанных с внутренним копированием данных, данные перемещаются блоками в 1 Гб. Перенос информации осуществляется в соответствии с заранее установленными расписаниями. Приоритеты размещения данных на дисках с различными уровнями производительности могут задаваться специальными правилами.

Возвращаясь к главной теме этой статьи, опять зададимся вопросом: “В чем заключается эффективность?”. Дело в том, что технология FAST позволяет добиваться очень высоких показателей цена/производительность. Оптимальное для каждого конкретного заказчика сочетание накопителей различных типов, объединенных в общий пул ресурсов с заданными требованиями к производительности, позволяет гибко организовывать хранение данных, минимизируя удельную стоимость хранения. При этом решение будет адаптивным. Оно станет динамически приспосабливать комплекс хранения под изменяющиеся нужды бизнеса. Упрощение первоначального планирования размещения данных и отсутствие необходимости постоянной ручной оптимизации производительности дает возможность заметно снизить затраты на управление комплексом хранения. (способы расчета конфигурации под FAST обсуждались здесь)

Как уже упоминалось в начале статьи, мерилом эффективности любой технологии являются выгоды для бизнеса. Нужного эффекта можно достичь тысячами различных способов. Поэтому поиск технологических решений, оптимальных для каждой конкретной компании, - непростая задача, требующая как знаний, так и интуиции. Самым действенным способом выработки нужного решения является обсуждение продуктов и технологических нюансов с коллегами, имеющими опыт реализации и администрирования реально функционирующих комплексов хранения."


PS Картинка к комментарию 
Я проверил на демо-массиве, все три типа RAID поддерживаются.

4 октября 2010 г.

Встреча со Стивом Тодом

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. Встреча пройдет на хорошем международном английском языке. Перевод и запись ранее обсуждались, но положительного решения пока нет

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.

Ниже приведены несколько примеров ситуаций, для разрешения которых используются эти процессы.
  • Новый коммутатор с чистым списком 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
текст

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 и потыкайте кнопки самостоятельно…

19 сентября 2010 г.

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.

И еще одно замечание напоследок. Как и любая другая, задача уменьшения потребляемого объема данных не является абсолютной самоцелью. Не стоит увлекаться и забывать о требованиях производительности, надежности и управляемости комплекса. Поиск оптимального сочетания является действительно трудной задачей... Зато не скучно…   ;)

19 августа 2010 г.

Архитектура Clariion

Когда-то написал небольшую заметку по архитектуре дисковых массивов Clariion. Может кому пригодится...

На рынке дисковых массивов среднего уровня (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