Ранее мы уже рассказывали про реализацию технологии QoS в системах Dell Compellent, но на этом нововведения в SCOS версии 7 не заканчиваются и сегодня несколько слов про них.

В системах Compellent технология многоуровневого хранения (Data Progression) появилась уже довольно давно, когда для многих систем хранения midrange класса не было о ней даже и речи. Как и тогда, перемещение блоков данных между уровнями сейчас также происходит по расписанию, а не в “онлайн” режиме. Это позволяет контролировать нагрузку на систему, избегая деградации производительности из-за выполняемых процессов миграции. Хотя, учитывать активность нагрузки нужно заранее при планировании. Организация данных в системах Compellent основана на страницах данных размером от 512КБ до 4МБ (дефолтный размер страницы 2МБ). Миграция также осуществляется на уровне отдельных страниц. За счет этого данные могут более избирательно распределяться по уровням хранения. Запись новых данных всегда происходит на самый быстрый уровень (“быстрые” диски в RAID10 или ssd) и это также нужно учитывать при изначальном планировании.


Начиная с версии SCOS 6.5.1 была добавлена возможность компрессии данных. Она также происходит в оффлайне, параллельно с перераспределением страниц по уровням хранения. Чтобы объяснить принцип работы Data Reduction в СХД Dell Compellent, необходимо сказать, что страницы данных, которыми оперирует система, бывают трех видов:

? “Active” (активные страницы) — недавно записанные данные. Эти страницы всегда находятся на самом быстром уровне хранения и данные в них могут быть как прочитаны, так и перезаписаны.
? “Frozen accessible” (замороженные доступные) — страницы после создания мгновенного снимка. Данные в них еще не перезаписывались, поэтому они доступны для чтения, но как только будет попытка изменить их, будет создана новая active page, а эта страница будет переведена в режим “frozen inaccessible”.
? “Frozen inaccessible” (замороженные недоступные) страницы, которые были перезаписаны после создания снимка. Данные из них уже не могут быть прочитаны при обращении к тому (без восстановления снапшота), а перезаписанные блоки находятся в активных страницах на самом высоком уровне хранения.

Во всех процессах Data Progression и Data Reduction участвуют только “замороженные” страницы. Ежедневно по расписанию создается очередной мгновенный снимок (в этот момент все активные страницы “замораживаются”) и начинается миграция между уровнями. Сжатие всегда работает с блоками размером 64КБ, независимо от размера страницы. Если после применения алгоритмов сжатия оказывается, что сжатые данные вместе с необходимым набором метаданных занимают больше места, чем несжатые, компрессия для данной страницы не применяется. Так как система оперирует именно страницами, то на финальном этапе процесса Data Progression происходит объединение частично занятых страниц с целью освободить место на дисках. SCOS также умеет распознавать и заменять ссылками блоки, заполненные нулями, что позволяет добиться еще более высоких показателей сжатия.

Но использование SSD дисков и распространение All-Flash систем требует более активного использования технологий оптимизации данных для снижения стоимости хранения. Поэтому в версии SCOS 7 Data Reduction дополнился еще и дедупликацией. Так как все оптимизации происходят параллельно с перемещением данных между уровнями, то и для компрессии, и для дедупликации потребуется лицензия на Data Progression. All Flash массивы с единственным уровнем хранения являются исключением и для них можно эту лицензию не покупать. Отметим, что если в массиве не используются ssd-диски, то ни сжатие, ни дедупликацию использовать невозможно. На первый взгляд это довольно странно — ведь обе эти технологии работают на страницах, которые могли быть и перемещены с самого быстрого уровня хранения на обычные диски. Все верно — сжатые данные могут храниться на обычных дисках, но для доступа к ним нам всегда требуется дополнительное обращение к служебным метаданным. И поэтому SSD диски (минимум 6 дисков) необходимы в том числе и для хранения этой информации, так как если бы мы размещали метаданные на обычных дисках, наблюдалась бы значительная деградация производительности при обращении к сжатым данным.

Дедупликация поддерживается только на контроллерах, обладающих достаточной производительностью процессора — SC4020, SC7000, SC8000, SC9000. Системы на базе SC40 и SCv2000 не поддерживаются. Для оптимизации данных используются выделенные ядра процессоров в контроллерах, поэтому в большинстве случаев нет заметного влияния фоновых процессов на производительность ввода-вывода. Но в любой момент вы можете поставить на паузу процессы Data Reduction, если вдруг они действительно стали влиять на скорость работы системы.

Процессы оптимизации являются фоновыми и могут запускаться либо по расписанию, либо, как только вы сделаете новый снимок тома. После создания снимка запускается процесс “on-demand data progression” и, как следствие, компрессия и дедупликация (если они конечно включены для данного тома). Между этими двумя вариантами есть серьезное различие — ежедневная оптимизация обрабатывает все замороженные страницы, а “быстрый” вариант только те, которые появились при создании снимка. Как следствие, такой фоновый процесс меньше загружает систему в рабочие часы.

Дедупликация, в отличие от компрессии, работает уже с блоками размером 4КБ. Принцип реализации стандартный — как и в других системах считается хэш от блока и сравнивается со словарем. Если такой хэш в словаре уже есть, то блок данных заменяется ссылкой, за счет чего и происходит экономия дискового пространства. Затем, уже после дедупликации, запускается компрессия. На этом этапе сжимаются уже только оставшиеся уникальные 4К блоки. Все, что было сказано про сжатие ранее, остается в силе — в ряде случаев компрессия может не дать желаемого эффекта и тогда страница будет записана на диск “как есть”.

Для каждого тома можно выбрать, какие именно технологии использовать — компрессию, компрессию в паре с дедупликацией или вообще отключить Data Reduction. Включить дедупликацию без компрессии невозможно. В зависимости от того, какие уровни хранения используются, оптимизация может работать по-разному:



Как это обычно и бывает, при разработке нового решения, необходимо помнить про некоторые особенности реализации. Репликация на уровне СХД поддерживается для сжатых и дедуплицированных томов, но в момент фактической передачи данных происходит декомпрессия передаваемых данных в памяти контроллера (данные на дисках остаются сжатыми) и “наружу" передаются только несжатые данные. Да, при настройке репликации можно отдельно включить дедупликацию данных, но этот процесс будет работать только при отправке данных на удаленную систему, а сами данные будут предварительно “регидрированы”. Если вы хотите изменить контроллер, владеющий томом с Data Reduction, потребуется предварительно выключить сжатие и дедупликацию, дождаться полного восстановления (после очередного цикла Data Progression) и уже потом изменить владельца на другой контроллер.

Да, было время когда многоуровневое хранение в Dell Compellent могло позиционироваться как новое и уникальное решение. Но сейчас, когда All-Flash набирают популярность, нельзя оставлять систему без возможности оптимизации данных — слишком высокой становится цена за ГБ по сравнению с конкурентами. Появление нового функционала в SCOS не может не радовать, а учитывая, что обновление поддерживается и на уже используемых контроллерах, заказчики получают возможность начать более оптимально использовать уже имеющиеся СХД. Насколько периодическая дедупликация хуже или лучше постоянной вопрос открытый и для каждого отдельного проекта будет свой ответ. Правильный путь — тестировать оборудование перед приобретением и слушать не только маркетинговые заявления вендоров при выборе решения.

Инженеры Тринити будут рады проконсультировать вас по вопросам виртуализации серверов, систем хранения данных, рабочих мест, приложений, сетей.

Посетите популярный технический форум Тринити или закажите консультацию.

Другие статьи Тринити можно найти в блоге и хабе Тринити. Подписывайтесь!