Оптимизация затрат и защиты инфраструктуры хранения
СХД, СРК СХД, СРК

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

Главная>СХД, СРК>Оптимизация затрат на инфраструктуру хранения
СХД, СРК Обзор

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

Дата публикации:
10.04.2017
Посетителей:
260
Просмотров:
231
Время просмотра:
2.3

Авторы

Автор
Всеволод Козинов В прошлом - старший инженер проектировщик систем хранения данных, компания «Инфосистемы Джет»
Непрерывность бизнеса – одно из ключевых условий успешного функционирования любой современной компании. Обеспечению непрерывности уделяется значительное внимание, в том числе и при создании системы хранения данных. Защищенность данных от аппаратных и программных сбоев напрямую влияет на непрерывность бизнеса.

 

 

В настоящей статье мы рассмотрим аспекты защиты данных от различных типов сбоев как в классических системах хранения, так и в современных масштабируемых решениях для построения облачной инфраструктуры.

Избыточность

 

Архитектура СХД определяется прежде всего требованиями к целевым параметрам назначения ИС – параметрами RTO и RPO. В зависимости от этих требований можно подобрать решение с учетом бюджетных ограничений.

 

Для обеспечения высокой доступности в СХД уже давно применяется дублирование компонентов: избыточные дисковые массивы (RAID), несколько аппаратных контроллеров, множественные пути доступа к данным (MPIO). Эти решения помогают при локальных аппаратных сбоях, они отточены в ходе многолетней практики применения. Думаю, этот вариант обеспечения отказоустойчивости де-факто давно стал стандартом в индустрии и хорошо знаком читателю, поэтому не будем останавливаться на нем подробно.

Репликация

 

Однако для обеспечения высокой доступности требуется также учитывать риски выхода из строя оборудования в пределах стойки или ЦОД в целом. В таких случаях на помощь приходят технологии репликации – синхронной и асинхронной.

 

Схема с синхронной репликацией данных за многие годы тоже стала классической. Как правило, синхронная репликация используется в решениях, где расстояние между ЦОД не превышает 100 км. Что касается асинхронной репликации, стоит обратить внимание на то, что она в первую очередь является средством для передачи данных на большие (более 100 км) расстояния, а не более доступной альтернативой синхронной репликации. Причина проста: целевые параметры восстановления зачастую требуют организации каналов с широкой полосой пропускания, что уравнивает стоимость организации каналов в синхронном и асинхронном вариантах. Кроме того, еще до недавнего времени решения многих производителей требовали дополнительных накладных расходов на стороне массива-источника (дополнительная емкость). А применение технологии Copy-On-Write Snapshot, хотя зачастую и скрытое от пользователя, могло значительно влиять на время отклика подсистемы хранения, что негативно сказывалось на производительности ИС. Впрочем, во многом благодаря бурному развитию Flash-памяти и ее активному применению для хранения данных ИС асинхронная репликация в последнее время становится преимущественным вариантом. Дело в том, что при всех плюсах синхронной репликации в решениях с применением Flash-памяти, где задержки измеряются сотнями микросекунд, фактор задержки в канале является критичным. Никому не понравится, если новый AFA-массив, показывающий результаты по отклику операций ввода-вывода в пределах нескольких сотен микросекунд, при работе с синхронной репликацией вернется к показателям отклика, которые прежде обеспечивал стандартный дисковый массив. Именно по этой причине большинство производителей существенно пересмотрели подход к организации асинхронной репликации, оптимизировав архитектуру с целью минимизации задержек дисковой подсистемы до приемлемого уровня.

 

Хочу отметить, что мы нисколько не стремимся принизить в глазах читателя подход с применением асинхронной репликации данных. Однако при выборе того или иного подхода рекомендуем тщательно взвесить все «за» и «против», учитывая реальные расходы и особенности конкретного решения.

 

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

Параллельный доступ к данным

 

Нельзя не обратить внимание на рост популярности подхода с применением СХД, обеспечивающей параллельный доступ к данным в основном и резервном ЦОД. Подобные решения, как правило, требуют виртуализации ресурсов хранения – либо с помощью внешних программно-аппаратных решений, либо средствами самих дисковых массивов. Этот тип решений позволяет размещать ИС на ресурсах кластеров, растянутых между ЦОД, что обеспечивает как минимальное время потери данных (RPO) в случае сбоя, так и сокращение времени восстановления сервисов до таких же значений, как у стандартных технологий локальной кластеризации. Как правило, такие решения основаны на синхронной репликации данных и имеют дополнительные ограничивающие требования к расстоянию между ЦОД, а точнее, к качеству каналов.

 

В качестве примера такой реализации можно привести архитектуру VMWare Storage MetroCluster, позволяющую не только использовать средства отказоустойчивости платформы виртуализации (VMWare HA), но и динамически распределять ресурсы между ЦОД без остановки (VMWare vMotion Over Distance). В последнем случае мы получаем возможность использовать ОЦОД и РЦОД в режиме Active-Active, что позволяет эффективно использовать инвестиции, вложенные в построение инфраструктуры РЦОД.

 

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

 

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

 

Резервные копии

 

Рассмотренные решения предназначены для восстановления сервисов в случае аппаратных сбоев. Однако нарушение целостности данных на программном уровне – ситуация тоже вполне вероятная.

 

Безусловно, основным средством защиты от логической порчи данных является резервное копирование. В качестве устройств хранения могут использоваться ленточные носители – самые экономичные средства хранения резервных копий, имеющие, однако, ряд особенностей, накладывающих ограничения на их применение. Альтернативные варианты – дисковые устройства с дедупликацией в виде программно-аппаратных комплексов или решения класса Software Defined Storage с дедупликацией. Оба варианта имеют право на жизнь, каждый из них призван решить определённый круг задач.

 

Особенности ленточных решений на данный момент вполне очевидны: большое пространство, занимаемое в ЦОД; операционные затраты, связанные с хранением выгруженных копий; необходимость регулярной валидации и перезаписи долгосрочных копий; последовательный доступ к устройству хранения и невозможность полной утилизации носителей ввиду особенностей работы с лентой (старые данные замораживаются). Все эти факторы, несомненно, знакомы персоналу, сопровождающему классические СРК. Тем не менее стоимость носителей и увеличение их плотности, а также рекордно низкое энергопотребление делают этот вид хранения резервных копий наиболее доступным. Кроме того, современные ленточные устройства обладают довольно высокой скоростью последовательного доступа и с каждым поколением скорость растёт. Тем не менее, ленточные носители не подходят для задач, требующих оперативного доступа к резервным копиям, а также гранулярного восстановления данных.

 

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

 

Что касается катастрофоустойчивости средств хранения резервных копий, для ленточных решений существует два варианта. Первый вариант подразумевает клонирование данных на ленточных носителях для отчуждения с последующей выгрузкой носителей и перевозкой в удаленное помещение для надежного хранения. Второй – организация параллельной или отложенной записи на ленточные носители в двух ЦОД. На первый взгляд первый вариант может показаться более дешевым в реализации. Однако следует учитывать, что необходимо подготовить подробный регламент, организовать дежурную смену для работы с лентами, а также транспортировку лент в ударо- и/или жаропрочном корпусе на служебном транспорте, не говоря уже о сложности управления жизненным циклом носителей в такой схеме. Не стоит исключать и риски, связанные с возможностью потери или хищением лент при перевозке. Организация параллельной или отложенной записи в двух ЦОД требует прокладки каналов связи. В зависимости от целевых параметров назначения данный вариант может быть хорошей альтернативой первому подходу.

 

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

 

Оба варианта обеспечения катастрофоустойчивого хранения резервных копий требуют внимательного отношения к вопросу отказоустойчивости основного сервера СРК, без работоспособности которого резервные копии обычно недоступны для использования. Здесь хорошо помогают технологии кластеризации с применением репликации данных средствами дисковых массивов. Альтернативный вариант – «холодное» резервирование ресурсов в резервном ЦОД. Тем не менее восстановление сервера СРК из специализированной копии может нести в себе риски как с точки зрения длительности восстановления, так и возможности ошибок оператора в ходе восстановления. Стоит взвесить «мгновенные» затраты на построение решения, а также возможные риски при выборе способа защиты средств СРК.

 

В последнее время СРК обретают возможность интеграции с решениями облачного хранения данных. В некоторых случаях такой подход позволяет оптимизировать издержки на долговременное хранение резервных копий, а также оперативно получать ресурсы по запросу. Тем не менее, процесс восстановления из «облака» может быть довольно болезненным: в экономном варианте канал связи, организованный через сеть Интернет имеет весьма ограниченную пропускную способность. Кроме того, ряд известных провайдеров, позволяет сравнительно дешево передавать данные в облако, однако исходящий трафик оплачивается по более высоким тарифам. К сожалению, применению облачных ресурсов зачастую препятствуют и законодательные ограничения, особенно на территории РФ. Однако в последнее время тенденция меняется – отечественные облачные провайдеры уже предоставляют услуги по хранению данных, в том числе для «холодного» хранения. Стоит обратить внимание на такую возможность, особенно если необходимо оперативно разместить архивные данные при отсутствии РЦОД. 

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

 

Несмотря на обилие вариантов построения отказоустойчивой инфраструктуры СРК (они были рассмотрены в части 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: не преувеличивать выгоды и не приуменьшать риски при использовании таких решений. Начните с внутреннего пилотного проекта для размещения данных, не требующих максимальной доступности, и оцените, насколько такой подход применим именно для вас. А потом примите решение. И не забывайте поговорку о бесплатном сыре. Желаю вам не попасть в мышеловку.

Уведомления об обновлении тем – в вашей почте

Резервирование данных: выбор площадки

Резервный ЦОД — неотъемлемая часть процесса обеспечения непрерывности бизнеса.

Обзор технологий обеспечения непрерывности ИТ-сервисов в чрезвычайных ситуациях

Индустрия обеспечения непрерывности ИТ- cервисов в случае чрезвычайных ситуаций.   10–15 лет назад ведущие мировые компании, в первую очередь — финансовый сектор рынка, осознали степень зависимости бизнеса от информационных технологий. ...

Как повысить эффективность массива

Представим вполне стандартные для ведения «ИТ-хозяйства» ситуации: мы добавили новый instance базы данных на сервер БД или новое задание резервного копирования (РК)

Шлюзы как средство интеграции баз данных. Практический подход

Практика показывает, что сейчас в целом завершается этап создания оперативных баз данных организаций. В том или ином виде (в виде персональных или промышленных реляционных БД) во многих из них сформировались центры актуальных данных, ...

Как хранят и резервируют данные в 2021 г.

Как правильно управлять критичными данными и защититься от их потери? Основные технологии, применяемые для оптимизации времени восстановления при сбоях? Что умеют решения NetApp?

Обеспечение непрерывности деятельности организации в нештатных ситуациях

Концепция, методы и средства обеспечения непрерывности бизнеса (Business Continuity Planning – BCP) и восстановления деятельности после бедствий (Business Disaster Recovery – BDR) широко известны и апробированы на Западе.   Технология ...

Как добиться единства противоположностей

Мы живем в мире, пронизанном идеями дуализма. Что первично – курица или яйцо?

«В обеспечении непрерывности бизнеса главное слово – "бизнес"!»

Виталий Задорожный, Сбербанк, поделился своим 10-летним опытом в области обеспечения непрерывности бизнеса

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня