28 марта 2011 г.

Самый эффективный протокол

Недавно попались на глаза расчеты эффективности различных протоколов. Как-то они мне показались не
убедительными: то поле в хедере забудут, то из максимального payload не вычтут часть накладных расходов.
В общем, решил все пересчитать сам и свести в одну табличку, пригодится в качестве шпаргалки по
протоколам.
Может тоже что-нибудь забыл, зато с честной совестью и ощущением полной собственной правоты ;)

Напомню, "эффективность" считается как отношение максимального объема полезных данных к сумма всех
передаваемых данных.

Размеры в байтах. Аббревиатуры: SOF - Start Of Frame, EOF - End Of Frame, IFG - Iner-Frame Gap.

FCIP FCoE
Ethernet Ethernet Ethernet iSCSI iSCSI Fibre
(Untagged (Untagged
(Untagged (Tagged (Tagged (Tagged (Tagged Channel
Поле Baby Baby SAS
Standard Standard Jumbo Standard Jumbo (FCP,
Jumbo Jumbo
Frames) Frames) Frames) Frames) Frames) Class3)
Frames) Frames)
Preamble 7 7 7 7 7 7 7
Ethernet
1 1 1 1 1 1 1
SOF
Ethernet
14 16 16 16 16 14 14
Header
IP
20 20 20
Header
TCP
20 20 20
Header
iSCSI
48 48
Header
FCIP
24
Header
FCoE
16
Header
SOF 4 4 4 4
FC
24 24 24
Header
SAS
24
Header
Maximum
1500 1500 9000 1412 8912 2112 2112 2112 1024
payload
CRC 4 4 4 4 4 4 4 4 4
EOF +
4 4 4 4
Padding
IFG 12 12 12 12 12 12 12 24 2
SAS
R_RDY
8
and ACK
overhead
Efficiency 97,98% 97,85% 99,63% 92,11% 98,66% 94,33% 96,39% 97,24% 95,70%

Пятиминутная медитация на таблицу в качестве сатори дает общее понимание структуры протоколов... Для
совсем ленивых прилагаю уже пережеванную картинку... ;)

В общем, получается, что самый "выгодный" стораджевый протокол все-таки Jumbo iSCSI...
Ему бы еще и остальные достоинства FC или хотя бы FCoE.... ;) но это тема отдельного разговора.

Кстати, понравилась эта статья про Etherner фреймы, кратко и очень толково. В контексте активного
продвижения 10G CEE в мир storage, все дружно вспоминаем уже позабытую. сетевую теорию... :)

5 коммент. Автор: Vasily Pantyukhin

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 поддерживаются.
 7 коммент. Автор: Vasily Pantyukhin

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

3 коммент. Автор: Vasily Pantyukhin

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.

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

5 коммент. Автор: Vasily Pantyukhin

4 августа 2010 г.

Rebuild на массивах Clariion

Давайте немного поговорим о перестройке (rebuild) данных на hot spare в слeчае сбоя диска на массивах
Clariion.

Начать надо с того, что при ребилде операционная среда Flare работает не со всем диском, а на уровне
конкретных LUNs. При этом, единовременно может перестраиваться только один том. Процедура rebuild
считается законченной только тогда, когда будут последовательно перестроены все LUNs, находящиеся на
диске. За выполнение операции отвечает owner SP. Соответственно, ребилдом различных LUNs на одном
диске попеременно будут заниматься оба Storage Processors.

Выбор томов для ребилда производится в соответствии со следующей перевернутой пирамидой:

При ребилде RAID1 или RAID10 кусок данных, состоящий из трех блоков по 512KB просто считываются со
“здорового” подзеркала и записываются на Hot Spare.

При перестройке RAID3, RAID5 или RAID6 одновременно считываются данные всего страйпа RAID Groups.
Обычно это происходит кусками, состоящими из 8x блоков по 512KB. SP пересчитывает данные и parity, а
потом записывает их на Hot Spare.

В случае, когда LUN имеет ASAP rebuild priority, после завершения операции копирования немедленно
начинается следующая итерация. Такой подход, конечно, очень сильно влияет на нагрузку дискового массива
в целом и может негативно сказаться на производительности доступа к данным со стороны хостов. Если же
том имеет приоритет High, Medium или Low, следующая операция начинается только после некоторой
заранее определенной задержки. Однако, случае простоя дискового массива (нет операций ввода-вывода с
хостов) не зависимо от текущего приоритета будет всегда применяться режим ASAP.

При ребилде не используются области кэш, выделенные для чтения и записи данных. Временное
размещение данных происходит в системной области памяти.
Если во время описанного процесса какой-либо хост запишет данные в блоки сбойного диска информация
будет либо сразу помещаться на Hot Spare (в случае если эти блоки уже были перестроены или используется
RAID10), либо будут временно записана в блок, в котором хранится parity данного stripe (RAID5, RAID6 parity
shedding). В момент непосредственного ребилда конкретного stripe, все операции записи или сброса кэш
временно приостанавливаются.
При выполнении операций rebuild и pro-active copy внутренняя буферизация диска всегда отключается. Это
приводит к некоторому увеличению времени выполнения операций.

В процессе перестроения данных всегда выставляются чекпоинты. Поэтому если при ребилде произойдет
выключение дискового массива в связи со сбоем питания, то после следующей загрузки Clariion,
перестроение будет продолжено с момента последнего чекпоинта. К сожалению я не знаю точных деталей
того, как это работает. Предположительно, чекпоинты записываются в полях rebuild time записей CRU
Signature, находящейся в зарезервированной 34MB области каждого диска. Но это только предположение.
Если кто-либо из читателей точно знает, как это происходит, хотя бы намекните в комментах к этому посту.

После замены сбойного диска начинается обратный процесс эквалайзинга (equalize). Данные копируются с
Hot spare на новый диск. Необходимо помнить, что если вы заменили диск достаточно оперативно и процесс
ребилда еще не закончился, то эквалайзинг начнется только после полного окончания перестроения диска
на Hot spare т. к. процесс ребилда прервать нельзя.

Значения Bandwidth и дополнительной нагрузки на SP при ребилде и эквалайзинге сильно зависят от

семейства Clariion (CX, CX3, CX4) и версии Flare. Поэтому за их точными значениями я отсылаю к
соответствующим открытым best practices на powerlink. Однако, можно вкратце отметить несколько факторов,
от которых зависит скорость перестроения:

Конечно, rebuild bandwidth растет с повышение приоритета.

За счет отсутствия необходимости пересчета parity при равном количестве дисков, ребилд RAID10
происходит значительно быстрее, чем RAID5 или RAID6.

При повышении количества дисков в RAID5 и RAID6 скорость перестроения данных заметно
падает.

Если принять скорость ребилда дисков FC 4Gbps 15K RPM за 1, то для дисков FC 2Gbps 10K RPM
она будет равна 0,65, для SATA 7.5K RPM – 0,75, а для EFD (SSD) – 1,43.

За счет высоких требований к пересчету parity, дополнительная нагрузка на процессоры SP при

ребилде RAID5 и RAID6, состоящими из многих дисков, достаточно велика (до 20%).