Российский Форум по системам искусственного интеллекта (RAIF)
Российский Форум по системам искусственного интеллекта (RAIF)
ИТ-портал компании «Инфосистемы Джет»

Оптимизация затрат на инфраструктуру хранения

Оптимизация затрат на инфраструктуру хранения

Итак, мы продолжаем разговор о технологиях и аспектах защиты данных от различных типов сбоев.

Мгновенные снимки

Несмотря на обилие вариантов построения отказоустойчивой инфраструктуры СРК (они были рассмотрены в части 1 настоящей статьи), возможностей современных СРК может оказаться недостаточно для восстановления в заданный срок. В этом случае помогут технологии создания мгновенных снимков (snapshot) средствами дискового массива. Технология подразумевает фиксацию состояния основного тома СРК на определенный момент времени. При этом измененные данные хранятся либо в выделенном томе, либо на тех же ресурсах массива – в зависимости от реализации.

На практике суточный объем изменений данных, которые создают большинство ИС, не превышает 30% от первоначального состояния. Таким образом, для отката к первоначальному состоянию потребуется передать всего 30% данных, что значительно сокращает время восстановления. Кроме того, ряд решений позволяет при восстановлении копировать данные в фоновом режиме прозрачно для пользователей. Поэтому дисковая подсистема становится доступной почти мгновенно после запуска процедуры восстановления. При использовании этого типа решений стоит обратить внимание на объем изменений, которые вносит ИС за цикл резервного копирования, а также на реализацию механизмов snapshot в применяемой модели массива. Часть производителей до сих пор применяют механизм Copy-On-Write, что может драматически снижать производительность ввода-вывода на томах, где хранятся созданные snapshots. Причина тому – необходимость предварительного копирования изменяемого блока на томе-источнике в специально отведенную область на дисковом массиве, что добавляет к трудозатратной операции записи еще несколько операций на back-end дискового массива. Некоторые производители борются с этим эффектом при помощи асинхронного применения изменений за счет использования большого объема кэш-памяти. Более продвинутые используют технологию Redirect-On-Write, предполагающую запись изменяемых данных в новое место того же пула ресурсов с сохранением лишь структуры указателей в оперативной памяти массива.

Еще одна особенность использования мгновенных снимков для оперативного отката данных – необходимость обеспечить согласованность (целостность, консистентность) данных snapshot с состоянием приложения. Для корректного создания копии приложение должно находиться в соответствующем состоянии: нужно исключить возможность нахождения в кэше приложения измененных блоков, не записанных на диск, а также изменения данных в ходе создания копии. Для этих целей можно применять самостоятельно разработанные скрипты либо готовое ПО. Большинство производителей дисковых массивов предоставляют подобное ПО интеграции в качестве отдельного продукта.

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

Continuous Data Protection

Отдельно стоит отметить класс решений, совмещающий репликацию данных и журналирование операций ввода-вывода (CDP, Continuous Data Protection). В этом случае мы получаем защиту данных как при аварии, так и при логических ошибках: журнал позволяет оперативно откатить данные на определенный момент времени в прошлом, при этом точка отката может быть гибко задана. Но для этого типа решений проблема обеспечения консистентности данных также актуальна. Подобные механизмы восстановления данных реализованы на уровне ПО в большинстве промышленных баз данных, для них применение CDP не имеет большого смысла. Тем не менее для приложений, где данный функционал отсутствует, но необходим, CDP является прекрасным вариантом. Стоимость решения нельзя назвать низкой, в общем случае применение snapshot на уровне дискового массива обойдется дешевле. Это связано как со стоимостью аппаратного и программного обеспечения, так и с необходимостью либо виртуализации ресурсов, либо применения определенных моделей дисковых массивов. Кроме того, журналы с сохранением всех изменений занимают значительный объем, порой заметно больше объема первичного тома. В качестве альтернативы можно рассматривать создание с заданной периодичностью классических snapshot – это даст ценовую оптимизацию взамен увеличения гранулярности восстановления.

Хранение в облаке

Пожалуй, мы рассмотрели все средства минимизации времени простоя, а также оперативного (или не очень) отката данных для ИС с классической архитектурой. Теперь стоит сказать несколько слов об активно развивающемся сегменте облачной инфраструктуры – о средствах построения облачного хранилища данных.

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

В качестве платформы хранения в облаке могут использоваться и классические дисковые массивы. Такой подход довольно часто встречается при построении частного облака на базе унаследованной инфраструктуры. Однако для построения современных решений, требующих максимальной гибкости и стандартизации применяемых аппаратных платформ, данный подход может оказаться неподходящим. В этом случае имеет смысл обратить внимание на решения класса SDS (Software Defined Storage), позволяющие организовать пространство хранения на базе существующего или вновь приобретенного пула вычислительных ресурсов с локальными ресурсами хранения (внутренние диски, JBOD, иногда – существующие дисковые массивы на время переходного периода).

Программно определяемые СХД

Решения SDS могут предоставлять как классический блочный доступ к ресурсам хранения – для классических приложений, размещаемых в облаке, так и специализированный объектный доступ для приложений Born-In-The-Cloud, или же доступ с эмуляцией особой файловой системы для организации распределенных вычислений. В любом из этих решений защита данных от локальных сбоев в основном обеспечивается либо путем зеркалирования блоков данных между узлами, либо применением алгоритмов Erasure Coding. Последние упрощенно можно назвать аналогом RAID уровней 5–6, работающим на уровне блоков, распределяемых между узлами хранения. Преимущества этой технологии такие же, как у RAID уровней 10 и 5–6 – меньшие накладные расходы на избыточность при снижении быстродействия.

Можно также провести аналогию с технологиями катастрофоустойчивого хранения. Аналоги асинхронной репликации, нередко с параллельным доступом к данным из двух ЦОД, присутствуют в большинстве решений с объектным доступом. Некоторые блочные решения также обладают указанным функционалом, но реже. Но применение синхронной репликации не характерно для данного класса решений.

К сожалению, стоимость промышленных SDS-решений зачастую не намного меньше, чем у классических систем хранения, а порой и значительно выше. Рынок таких решений все еще находится в стадии активного развития. Тем не менее будущее – во многом за решениями такого типа, хотя, скорее всего, в значительно трансформированном виде. С каждым годом бизнес развивается все более динамично, инфраструктура в целом и инфраструктура хранения в частности должны отвечать его потребностям. Горизонтально масштабируемые SDS-решения этому требованию отвечают. Уже просматривается тенденция заимствования идеологических парадигм SDS производителями классических СХД. Будем надеяться, что по мере популяризации решений этого типа их стоимость также будет снижаться.

А пока можно довольствоваться SDS-решениями из мира Open Source. Безусловно, эти решения позволяют снизить капитальные затраты на построение инфраструктуры хранения, и их уже нельзя назвать «сырыми» (вспомним об опыте CERN или некоторых облачных провайдеров). Однако стоит помнить, что их сопровождение существенно отличается от того, что было принято в индустрии на протяжении многих лет. Персонал, требуемый для их поддержки, должен обладать значительно более высокой квалификацией в совершенно разных областях: не только быть на ты с UNIX-сообществом, но и иметь навыки системного программирования. Как правило, администратору Open Source ПО неоткуда ждать помощи, поэтому каждый шаг должен быть взвешен. Скрытые операционные издержки могут быть значительно выше, чем экономия на капитальных затратах, при этом доступность построенной системы может оказаться далека от ожидаемой. Нельзя не согласиться с советом известного аналитического агентства Gartner: не преувеличивать выгоды и не приуменьшать риски при использовании таких решений. Начните с внутреннего пилотного проекта для размещения данных, не требующих максимальной доступности, и оцените, насколько такой подход применим именно для вас. А потом примите решение. И не забывайте поговорку о бесплатном сыре. Желаю вам не попасть в мышеловку.

Автор: Всеволод Козинов, старший инженер-проектировщик систем хранения данных, компания «Инфосистемы Джет»

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: