Скорость или объем? Автоматизация управления системами хранения с разнородными характеристиками

в 10:46, , рубрики: ssd, ssd+hdd, Блог компании Teradata, метки: ,

Твердотельные накопители (SSD) enterprise-класса появились как новые технологии хранения данных и уже вовсю применяются при проектировании высокопроизводительных систем. SSD значительно быстрее, чем жесткие диски (HDD), но они и дороже. Здесь и сейчас их ролью является участие в гибридных средах хранения (SSD и жесткие диски вместе), а их стоимость препятствует полному переходу на их использование для большинства компаний. Разбираемся с многоуровневой средой хранения, где твердотельные накопители – самые быстрые и самые дорогие устройства, а жесткие диски высокой емкости, наоборот, наиболее медленные и дешевые. Термин «гибридная» и словосочетание «многоуровневая система хранения данных» можно считать синонимами.
Ключом к успешному использованию твердотельных накопителей в гибридной среде хранения является программное обеспечение, которое автоматически управляет размещением данных и отвечает за то, что наиболее часто используемые данные размещаются на быстрых SSD.
Продукт Teradata Virtual Storage (TVS) разработан Teradata Labs специально для управления такой гибридной средой хранения. В этой статье мы посмотрим на TVS с точки зрения целей его разработки и расскажем о том, как он работает.
Данная статья написана по материалам моего доклада на конференции Teradata Форум 2012, которая прошла в Москве в конце ноября.

В основе эффективности гибридных систем хранения лежит идея о том, что разные данные используются потребителями с разной частотой. Например, для ежедневной отчетности и оперативного анализа нужны данные за последние день-неделю, в то время как обращение к данным, которые старше трех лет, требуется не каждый день, и только по одному-двум показателям. Характеристику данных через частоту доступа легко представить в виде температуры, как её понимают в школьной физике, только вместо молекул здесь «движутся» блоки данных. Так, данные, которые лежат мертвым грузом, назовем холодными, а наиболее востребованные данные – горячими.
Под управлением на основе температуры данных мы понимаем способность управлять приоритетом выделения системных ресурсов на основе бизнес-правил, полнее используя возможности разных систем хранения данных с учетом постоянно растущих объемов информации.

Объем данных тоже имеет значение. Если взглянуть на то, сколько данных в системе являются горячими, а сколько – холодными, получится характеристика, уникальная для конкретной системы в конкретный момент времени. Выходит, что частота доступа к данным и объем этих данных взаимно не коррелируют, а сочетание их усредненных (за некоторый период) значений вместе является характеристикой той системы, которую мы анализируем.
В отношении объема данных нужно также учесть, что за последний десяток лет мощность процессоров и мощность подсистемы ввода-вывода растут по-разному. Сравнивать их напрямую – не цель данной статьи, но соотношение количества процессорных секунд на единицу ввода-вывода изменяется ежегодно, и не в пользу HDD.

Конфигурации систем «HDD-only» развивались (и развиваются) так:

  • Объем данных в расчете на узел – растет;
  • Гранулярность роста довольно велика (73 ГБ – 136 ГБ – 300 ГБ…);
  • С числом дисков растет место, занимаемое стойками в дата-центре;
  • Производительность CPU в расчете на терабайт данных – падает.

Постоянный рост производительности CPU привел к увеличению числа дисков, которые нужны, чтобы нагрузка на процессоры и диски была равномерной. Больше дисков – больше данных. Есть и третий путь – мало дисков и много данных. Но если пользователей (читай – параллельных запросов) в системе много, то малое количество дисков становится узким местом. Ведь скорость доступа к данным на HDD практически не менялась за последнее десятилетие, а скорость случайного доступа – ключевая характеристика для дисковой подсистемы в условиях многосессионной нагрузки.
Такой рост вполне подходит для тех компаний и систем, у которых низкие требования к CPU на терабайт. Остальным остается смириться с избыточной емкостью жестких дисков (сейчас уже не найти HDD меньше 300 ГБ, что для Teradata означает минимальный объем в 14 ТБ на узел).
Пришествие SSD на рынок на текущий момент поменяло ситуацию. Отличия SSD известны, это флэш-память с интерфейсом, идентичным HDD по физическим и электрическим параметрам. К тому же enterprise-класс имеет свои особенности:

  • Используется технология single-level cell (SLC), когда в одной ячейке хранится только один бит информации;
  • Фабричный тестовый отбор микросхем;
  • Алгоритмы коррекции ошибок;
  • Встроенные контроллеры с ПО оптимизации производительности и контроля надёжности.

Teradata потратила много лет и сил, чтобы подготовиться к изменениям в устройствах хранения, и разработала слой виртуализации, который расположился между логической файловой системой Teradata File System и реальными устройствами. Результат назвали Teradata Virtual Storage.
В качестве ключевых особенностей при проектировании были выбраны:

  • Автоматизация. В Teradata Labs не планировали создавать новых задач для DBA.
  • Распределение I/O между устройствами внутри гибридной системы хранения.
  • Производительность. Мы всегда о ней думаем, что бы под этим термином ни подразумевалось.

Автоматическая работа, как фундаментальное требование, должно было исключать необходимость ручного вмешательства в процесс размещения и миграции самых горячих данных на самые быстрые устройства, и наоборот. У DBA много другой работы, чтобы еще следить за тем, соответствует ли профиль нагрузки от пользователей тому, как расположены данные между дисками.
На оптимальное распределение нагрузки влияет множество факторов: общий объем данных в системе, емкость каждого носителя, температура данных, к которым идет обращение, текущий уровень активности в системе, скорость изменения паттернов доступа. Все эти показатели меняются динамически, и бессмысленно предполагать, что ввод-вывод будет идти с самых быстрых носителей (если только не все данные в системе на них умещаются).

Философией TVS стало достижение сбалансированного распределения операций ввода-вывода: место хранения должно соответствовать температуре данных. Цель была определена так: как минимум 80% операций ввода-вывода должны проходить через самые быстрые устройства, а остальное – с более медленных слоев. Заранее зная, что к медленным слоям тоже будут обращаться, нужно внимательнее отнестись к соотношению SSD и HDD в системе, чтобы жесткие диски были способны выдержать эти оставшиеся – потенциальные – 20%.
Удерживая горячие данные на быстрых SSD, на них переходит большая часть нагрузки HDD. В результате получаем лучшее и плотнее распределенное время отклика как с тех, так и с других. Как только уровень активности на HDD возрастает, длина очереди на диске увеличивается, скорость доступа замедляется или скачет. Особенно это заметно, когда короткий тактический запрос, которому нужна единичная операция I/O, стоит в очереди после больших аналитических запросов. Перемещая горячие данные на SSD, мы уменьшаем очереди на дисках и обеспечиваем хорошее время отклика.

В то же время диски и дисковые массивы отличаются по своим характеристикам производительности. В Teradata Labs провели большую работу по профилированию разных массивов разных вендоров, разных поколений и разных типов (SSD/HDD). Собранная в результате база данных используется TVS в процессе конфигурации, чтобы определить уровень скорости, с которой работает конкретное устройство или место внутри него.
В частности, внутри HDD определяются его медленные и быстрые зоны. В жестких дисках нижние Logical Block Addresses (LBA) каждого физического диска соответствуют его внешним дорожкам и самому быстрому времени отклика. Разбитый на партиции диск для каждой партиции будет иметь свою оценку скорости работы, а значит, и свою позицию на шкале скорости работы устройств.
Данные в СУБД Teradata распределены (в идеале – равномерно) между различными виртуальными процессорами (называемыми AMP). Каждый AMP хранит свою часть данных пользовательского объекта (таблицы), и только он имеет к ней доступ. Индивидуальные записи на уровне файловой системы Teradata File Storage группируются в блоки данных, те, в свою очередь, – в цилиндры (группа блоков данных, непрерывно последовательных на диске). Блок данных содержит сортированные записи одной таблицы. Блоки имеют различный размер, максимум – 127.5 КБ, то есть 255 секторов по 512 байт каждый. В зрелой системе блоки данных в среднем имеют объем 96 КБ. С точки зрения файловой системы, о таблице можно думать как о совокупности блоков данных, которые лежат на всех AMP’ах.

Teradata Virtual Storage выделяет три уровня скорости устройства хранения: быстрый, средний и медленный. При ранжировании учитываются всевозможные факторы: тип устройства, скорость вращения (для HDD), физическое расположение (внутренние или внешние дорожки HDD). От пространства быстрых устройств TVS отделяет часть, называемую soft reserve, под критические объекты СУБД:

  • Spool – Временные таблицы, содержащие промежуточные и окончательные результаты при выполнении запросов.
  • WAL (Write after Logging) – Содержит записи журнала транзакций, а также записи журнала WriteAheadLog, который используется для защиты от потери изменений обрабатываемых в памяти блоков данных.
  • DEPOT – Небольшая область данных, которая используется для защиты от сбоя дискового массива тех блоков данных, что обновляются «на месте», когда новые данные записываются прямо поверх существующих.

Скорость работы с этими объектами критична для общей производительности системы, поэтому мы храним их всегда на скоростных носителях.
Границы между soft reserve, быстрыми, средними и медленными областями устройств хранения заново определяются под каждую платформу и релиз СУБД.

В процессе конфигурации устройства и участки устройств различной скорости равномерно распределяются между AMP'ами так, что все получают эквивалентную производительность. В процессе работы системы TVS управляет распределением данных между этими устройствами, то есть увеличение производительности достигается через перераспределение данных.
Управление гибридной среды хранения данных вручную будет обременительной и трудоемкой задачей, требующей постоянного наблюдения и действий администратора. В случае TVS мы имеем дело с полностью автоматизированным сервисом.
Как уже говорилось, Teradata Virtual Storage распределяет данные автоматически в зависимости от их температуры. Частота доступа к каждому блоку данных отслеживается TVS и сохраняется в виде температуры данных, агрегированной на уровне цилиндра (то есть все блоки одного цилиндра всегда будут иметь одну и ту же температуру). Температура здесь – величина относительная внутри системы.
TVS периодически уменьшает настройки температуры по всем цилиндрам в системе. Вначале, при записи, температура цилиндра всегда выставляется средней по системе, но с течением времени к старым данным обращаются реже, чем к новым, и этот принцип выражается в процессе старения. При его активации равномерно понижается температура всех цилиндров в системе.

Но это только часть работы модуля, который носит имя Мигратор (Migrator). Как можно догадаться, Мигратор использует величину температуры цилиндра для определения того, надо ли его переместить на устройство хранения с иной скоростью. На каждом AMP’е Мигратор ведет упорядоченную очередь «неправильно» размещенных цилиндров. Те из них, что содержат горячие данные, но лежат на медленном носителе, помещаются в начало очереди. Холодные данные, которые оказываются на быстрых носителях, – наоборот. От их переноса не будет никакой немедленной выгоды, и только если место на быстром носителе заканчивается – Мигратор принимается избавлять его от холодных данных.
Например, вначале в некоторый момент времени блоки разной температуры расположены на произвольных носителях. Постепенно с работой Мигратора картина меняется: горячие блоки мигрируют на быстрые носители, холодные – на медленные, теплые – на носители средней производительности.
Процессы TVS работают на каждом узле. Мигратор выбирает из очереди и выполняет в среднем миграцию одного цилиндра на каждом AMP’е каждые 5 минут, и не более двух параллельных миграций на узле. Так продолжается до тех пор, пока не закончится очередь. С такой скоростью примерно 10% всех занятых в системе цилиндров могут мигрировать за неделю. Представляется, что нагрузка на систему, которая в этом режиме составляет около 2% по CPU и I/O, является более чем приемлемой платой за достигнутое качественное распределение данных устройствам.
Пока цилиндр мигрирует, запись в него невозможна, и обратное тоже верно.
TVS поддерживает и другой режим миграции, который называется оптимизация (optimize). В этом режиме Мигратор использует все доступные ресурсы системы на как можно более быструю миграцию данных, и те же 10% данных могут мигрировать примерно за 8 часов. Естественно, ни о каком применении на промышленной системе речь не идет, но иногда полезно.
Когда заполнение системы данными превысит 95%, Мигратор остановит свою работу.
В дополнение к двум вышеописанным режимам работы, есть еще один режим – асинхронной миграции, который запускается еще реже, чем режим регулярной миграции, – тогда, когда свободное место в soft reserve, на быстром или среднем по скорости носителе, падает до 10% его емкости. Назначение этого режима – освободить место на быстром носителе для свежих горячих пирожков данных. В этом режиме Мигратор будет работать до тех пор, пока 10%-ный порог не пройден или пока не останется «неправильно размещенных» цилиндров, то есть горячие данные в этом режиме не покидают быстрых носителей, а теплые – средних.
Одной из интересных возможностей управления TVS является так называемая начальная температура данных. По умолчанию она задается в системных параметрах, но, используя свойство сессии query band (это текстовая строка) и ключевое слово TVSTemperature, можно эти настройки поменять для данных, которые загружаются этой сессией.

Для примера посмотрим на варианты конфигурации одной из серьезных систем, поставляемых Teradata, – Active EDW 6690. Ее особенности в отношении дисков таковы:

  • 15 – 20 штук 400 ГБ SSD;
  • объем горячих данных: 1.6 – 2.2 ТБ;
  • 60 – 160 штук 300 или 600 ГБ HDD;
  • объем теплых и холодных данных: 4.9 – 26 ТБ;
  • до 174 дисков на узел.

Используются только диски форм-фактора 2.5”, SSD и HDD располагаются в одном и том же дисковом массиве. Причем диски в систему не обязательно ставить все сразу, можно и потом добавить.
Когда новая система только начинает жить, невозможно предсказать распределение данных по температуре. Но для уже работающих систем Teradata предлагает проводить оценку фактической температуры данных. В процессе такой оценки определяется оптимальный объем данных на каждый узел и рекомендуемая доля SSD в нём.
Для оценки используется инструмент сбора данных (утилита носит название IOCNT). Утилита устанавливается на нескольких узлах существующей у заказчика системы и собирает информацию о соотношении горячих и холодных данных. Для уменьшения погрешности измерений утилита подключается к нескольким AMP’ам и агрегирует информацию о реальной активности доступа к данным за выбранные периоды времени.

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

В заключение позвольте привести пример скриншота портлета TVS Monitor из инструмента администрирования Teradata Viewpoint. Портлет позволяет отслеживать статистику температуры данных и степень загруженности устройств разной скорости. Администратор может видеть, как данные распределены сейчас, оценить текущую потребность в миграции данных, а также изучать, как изменялось распределение в прошлом.
Скорость или объем? Автоматизация управления системами хранения с разнородными характеристиками

Автор: Ergotoro

Источник

Поделиться

* - обязательные к заполнению поля