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 комментариев:

  1. Бррр, буквально на днях мельком показывали CX4-120 с новым интерфейсом - юнисферой. В пулах можно было только R5 и R6 - это значит что FLARE старая в массиве стояла?

    (c) villain

    ОтветитьУдалить
  2. Пока странное ощущение оставляют pool-ы - вроде как идет дублирование функциональности raid group - и есть мысль, что такие же что-то одно должно "умереть" или быть реализовано друг через друга.

    Хотя хз как оно там унутри наворочено 8-)

    (c) villain

    ОтветитьУдалить
  3. Вы совершенно правы. RAID Groups должны постепенно отойти. Гибкая внутренняя организация pools позволяет реализовывать более сложную функциональность. При этом, возможность использования толстых томов подменяет необходимость создания классических RAID Groups.

    Правда, для меня остается вопрос различий в производительности между томами в RAID Groups и thick LUNs в pool. Поспрашиваю на эту тему знатоков.

    ОтветитьУдалить
  4. EMC изобрела NetApp 8-)))

    Вообще было бы интересно где-нть почитать о "потрохах", вопросов пока больше чем ответов.

    Что станет с metaLUN? Можно ли будет вкладывать pool в pool? и т.д

    (c) villain

    ОтветитьУдалить
  5. >> EMC изобрела NetApp 8-)))
    к тому времени, как NetApp тоже изобретет NetApp, EMC уже изобретет очередное EMC... :)))

    Ну, а если серьезно, то у NetApp в продуктах реализована масса замечательных идей. Отличная компания с очень интересной корпоративной культурой. Но не думаю, что идея гибкой внутренней организации пулов принадлежит этой компании.
    Кстати, по патентному праву получить авторское право на идею вообще не возможно. Только на ее выражение (картины, музыка) или реализацию.

    MetaLUN в pools не нужны.
    А зачем вкладывать pool в pool? Как-то не придумать реальную ситуацию когда это нужно...

    ОтветитьУдалить
  6. 8-)

    с metaLUN - как мне из ээ 15 дисков сделать RAID5?
    и диски на 2 Тб и не хочется ждать как на иголках что вылетит второй винт во время ребилда и копибэка? с metaLUN был выход. Как сейчас пока смутно

    rg/pool в pool вкладывать - нууу пофантазирую - например для FAST 8-) сначала SATA R6 потом SATA R10, далее тоже самое для SAS и потом EFD 8-)
    во как навернул 5 уровней вместо 3-х 8-). В том же линуксе кто мешает собрать эээ lvm из кучи разных md-ек? (а потом с этой фигней взлететь 8-)) блочные устройства и в Африке блочные.

    (c) villain

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.