• Звонок по России бесплатный 8 800 200-59-60
  • Москва +7 (495) 232-92-30
  • Санкт-Петербург +7 (812) 327-59-60
  • Екатеринбург +7 (343) 378-41-50

Пресс-центр

Комплексная виртуализация СХД в мультипротокольном кластере непрерывной защиты данных масштаба предприятия

COGITATIONIS POENAM NEMO PATITUR (ULPIANUS)

Краткий словарь терминов:
Continuous Data Protection (непрерывная защита данных), далее CDP - методика постоянного отслеживания изменений данных и сохранения изменений независимо от первичных данных, позволяющая восстановить данные на любой момент времени в прошлом.

CDP системы могут быть реализованы на уровне блоков, файловых систем или отдельных приложений и обеспечивать сколь угодно малую дискретность при восстановлении объектов на любой момент времени, вплоть до одиночной операции записи. Согласно этому определению SNIA (Storage Networking Industry Association - ассоциация индустрии сетевого хранения), все CDP решения должны иметь следующие свойства:

  1. Изменения постоянно отслеживаются и записываются
  2. Все изменения хранятся на отдельном устройстве
  3. RPO (точка восстановления) - произвольная и не должна быть определена заранее (до момента восстановления)

Recovery Point Objective (RPO) - Допустимая точка восстановления

[Data Recovery] The maximum acceptable time period prior to a failure or disaster during which changes to data may be lost as a consequence of recovery. Data changes preceding the failure or disaster by at least this time period are preserved by recovery. Zero is a valid value and is equivalent to a "zero data loss" requirement.

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

Recovery Time Objective (RTO) - Допустимое время восстановления

[Data Recovery] The maximum acceptable time period required to bring one or more applications and associated data back from an outage to a correct operational state.

Максимально допустимый период времени, требуемый для того, чтобы вернуть приложение и требуемые для его работы данные в состояние, приемлемое для продолжения корректной работы с ними.

Пролог

В таблице представлены некоторые вехи из истории разработки ПО резервного копирования и ориентировочные стоимостные показатели "сырой емкости" (цены на устройства хранения взяты с сайта http://www.mattscomputertrends.com)

 

Дата Наиболее востребованные диски (MB) Цена $/MB Цена диска, $ Среднее количество файлов на одном диске
1986 - первый релиз GNU Tar 40 MB 57 2300 сотни
1990 - Legato Networker 1.0 110 MB 13 1500 тысячи
1999 - первый релиз rsync 17,000 MB 0,002 340 10,000+
2002 - первый релиз FalconStor CDP 80,000 MB 0,002 212 100,000+
2005 - IPStor для OEM (iSer Infiniband), первый релиз R1Soft CDP для Linux 200,000 MB 0,0007 140 1,000,000+
2007 - AIX JFS2& Solaris ZFS snap-mirror, MS VSS near-CDP, EMC RecoverPoint (Kashya) 320,000 MB 0,0004 140 3,000,000+
2009 - MS DPM, IBM FastBack, NexentaStor CDP - Freeware. 2,000,000 MB 0,00007 150 10,000,000+

 

Вместе с положительным эффектом от масштаба, наблюдаемым для "сырой" емкости хранения, запросы на рынке систем резервного копирования c 2000г начали меняться вследствие быстро увеличивающегося разрыва между производительностью внешних систем хранения, требуемой емкостью и производительностью серверов и сетевого оборудования.Подобный дисбаланс приводил к большому времени восстановления в случае катастрофы системы хранения с неструктурированными данными или к существенному удорожанию всего решения по защите от катастроф. На фоне отсутствия корпоративных решений в области CDP очередной опрос Forrester Research выявил интересную тенденцию в среде крупных компаний. Низкая эластичность по показателю [Цена/GB при минимальных RTO/RPO] существующих на тот момент систем резервного копирования предвещала для новой категории продуктов очень комфортный старт. С этого момента инструменты по непрерывной защите данных начали свое самостоятельной развитие. До 2000 г. CDP функциональность была доступна только как дополнительная функция в составе систем хранения. Принципиальная несовместимость механизмов CDP между системами хранения различных производителей не позволяла воспользоваться всеми конкурентными преимуществами этих систем при объединении их в рамках одной инфраструктуры заказчика.

В настоящий момент SNIA описывает CDP как часть инициативы по защите данных (DPI):

Навигация для быстрого поиска материалов на сайте SNIA:

SNIA ( http://www.snia.org )
В категории "CDP продуктов" по классификации SNIA представлены: FalconStor СDP и EMC RecoverPoint CDP.
 

Картина первая, лирическая … "Делайте что хотите, но чтоб через полчаса в лесу было сухо, светло и медведь!"

Воссоздавая в памяти первый поучительный инцидент из области "непрерывности бизнеса" более полно, невольно возвращаюсь к 1990г., когда работа в качестве технического специалиста в банке совмещалась с написанием диплома. Испытания на инженерную смекалку проходили каждый день т.к. головное отделение банка внедряло в филиалах новый "операционный день" (в наши дни подобное ПО является частью любой Автоматизированной Банковской Системы) и инструкции по эксплуатации не содержали описания всех исключительные ситуаций, в которых система побывала с момента начала внедрения (про CoBIT, ITIL, SLA и прочие правильные понятия в лихие 90-е задумывались редко). Один из подобных трудовых будней запомнился особенно ярко. В отделе валютных операций перестала работать система электронных переводов. Причина на первый взгляд казалась тривиальной. ПК не загружался со знакомым всем сообщением, что устройство, необходимое для загрузки, отсутствует. Однако, очень скоро стало понятно, что подключенное к этому ПК заведомо исправное загрузочное устройство проблему не решит. Привычное поведение ПК при загрузке изменялось благодаря дополнительному устройству, компоненты которого были залиты лаком, и единственная разборчивая надпись очень напоминала номер телефона. Позвонив по этому номеру и попав на очень приветливого оператора, сотрудники банка были огорчены следующим ответом - "Система защиты от несанкционированного доступа была Вам поставлена с двумя аппаратными ключами, и если один из них вышел из строя, то Вы можете воспользоваться другим. Изготовление новой дополнительной пары ключей займет несколько дней". Растерянное лицо оператора ПК, который держал в руках один из "неисправных" ключей подсказало очевидное решение. Второй ключ нашелся быстро, но множество растерянных лиц пополнилось еще одним - лицом руководителя отдела валютных операций. По законам жанра второй ключ тоже не подошел. В подобных ситуациях часы начинают тикать особенно громко. После того, как из операционного зала поступил запрос от клиента, который пришел за денежным переводом, руководство решило, что стоимость ПК не сопоставима с теряемой банком репутацией и произнесло сакраментальную фразу - "Делайте что угодно, но система переводов должна заработать в течение часа!". На окошке оператора повесили табличку с объявлением "Технический перерыв" и отдали ПК в тех.отдел в нарушении всех инструкций вместе с ключами и всей документацией. На коротком совещании все сошлись во мнении, что необходимо решить две задачи: 1 - научиться сравнивать ключи между собой, 2 - заставить работать систему без ключей. Задача № 1 позволяла ответить на вопрос о целостности ключей и собственном уровне надежности поставленного нам средства защиты от "несанкционированного доступа". Решение задачи №2 избавляло некоторых сотрудников от увольнения. 20-и минутные старания с выбором правильного момента задержки при подключении PATA шлейфа к диску были потрачены не напрасно и ПК удалось запустить без ключа. Далее, приложив вроде бы неисправный ключ, запустили и систему переводов. После этого инцидента методику резервирования сервиса пересмотрели в корне - поставили еще один ПК с отдельной парой ключей (которые были уникальными, как выяснилось позже, после успешного решения задачи №1). Поучительность этой истории в том, что истинная цена победы была гораздо ниже - всего один блок на диске (даже не начальный), но понять это в условиях сильного сопротивления со стороны системы защиты бывает порой не просто. Задача о внесении изменений в конфигурацию вычислительной системы с оператором (называемой эргатическим комплексом) с требованием "безусловной высокой доступности" сервиса в строгих терминах эквивалентна поиску глобального экстремума у функции нескольких переменных с ограничением по параметрам (число конкурентных лицензий, целостность системы, доступность каналов и т.д.), которые в свою очередь зависят от времени. Еще более экзотические классы задач приходится решать, когда система перестает быть устойчивой при попытке оптимизации скоринговых процедур в экспертной части ITSM. Анализ рисков при выборе в пользу "чуть большей безопасностью" и "чуть меньшей доступностью" сильно осложняется, когда ключевые информационные ресурсы компании распределены географически и организационная структура не позволяет получить состоятельную оценку риска за требуемый промежуток времени. Несмотря на то, что банки и страховые компании одними из первых стали применять "Attrition scoring", собственные информационные ресурсы в комплексе с системой безопасности обычно выпадают из этого анализа. К сожалению, описание первопричин этого феномена не укладывается в рамки данной статьи. Но даже если оставить в стороне аксиомы и красивые выводы из них, результат теории оптимизации эргатических комплексов удручает не меньше - внешние воздействия оператора предсказать и эффективно компенсировать невозможно и на все случаи жизни заранее просчитать сценарии оптимального реагирования нельзя (оптимизатор отнимет ресурсов больше, чем Вы получите эффект от оптимизации, иначе оператора можно исключить). Как же тогда обеспечить высокую доступность сервиса? Ответ очевиден - нужно быть готовым к самому худшему из сценариев - к катастрофе. Все промежуточные состояния легко экстраполируются, как в известной истории с математиком и чайником... "по индукции".

Картина вторая - парадоксы логики ответственных за принятие решений.

В руководстве по катастрофоустойчивости одного известного вендора эпиграфом к главе "Backup" выбрана замечательная русская поговорка "Fix your cart in winter, and sled in summer. Russian proverb". Следующая глава "Recovery" начиналась не менее известной, но уже британской поговоркой "The Lord helps those who help themselves.". Вся современная парадигма "обеспечения непрерывности бизнеса" по прежнему умещается в этих простых народных мудростях. Для обеспечения непрерывности бизнеса (как минимум) требуется сделать непрерывными три связанных процесса:

  1. Непрерывное сохранение генерируемых изменений (в самом простом случае их сериализация)
  2. Непрерывное восстановление (прикладывание изменений к резервным копиям)
  3. Непрерывная оценка доступности сервиса и своевременное переключение на требуемую резервную копию

В этом месте изложения апологеты ERP систем и администраторы БД этих ERP систем обычно произносят что-то вроде - "В ERP системах все критичные для бизнеса изменения уже защищены журналами транзакций и технология резервных БД с успехом применяется для построения катастрофоустойчивых решений уже второй десяток лет". Это достойный аргумент для организации проекта по внедрению подходящей ERP системы, но те, кто работает с ERP два десятка лет прекрасно знают, что журнал БД приложить сложнее, чем журнал CDP. Представьте себе, что при параллельном безостановочном перестроении кластерного индекса на трех экземплярах Real Application Cluster с одновременной загрузкой данных в кластер на трех оставшихся экземплярах один из потоков изменений в архивном журнале N будет содержать ошибку? Сколько времени придется потратить на выяснение первопричины ошибки и, главное - как изменится RTO резервной БД?

Рассмотрим некоторые нюансы возможных комбинаций "CDP уровня приложения" и "CDP блочного уровня" более детально на следующем примере:

Вводные: Компания X строит резервный ЦОД для защиты основного от катастроф. Организован канал связи между основным и резервным ЦОДами с гарантированной полосой пропускания в 2-а раза превышающей среднюю скорость генерации изменений. Анализ скорости проводится за год, интервал усреднения - 1 час. Надежность канала умышленно исключим из анализа. Средняя латентность канала - 250mc (London-Tokyo). На расстоянии в 3km от основного ЦОДа есть резервный кампус с аналогичным по полосе каналом до основного и резервного ЦОДа. Спрашивается: каким будет максимальное время восстановления (RTO) и самый пессимистичный сценарий развития событий в случае катастрофы? Понятно, что при двойном запасе по полосе пропускания максимальное время восстановления будет около 30мин. (представьте себе график, на котором за первую минуту мы генерируем 100% изменений, а затем начинаем передавать их по каналу. Двойной запас по полосе сокращает время с часа до 30 мин) Но более неожиданным может быть тот факт, что при катастрофе (полной недоступности) основного ЦОДа в период пиковой нагрузки время восстановления может быть меньше 30 мин., а вот потери для бизнеса могут быть невосполнимыми (RPO>0) . Ключевым здесь является тот факт, что канал до кампуса не рассчитан на пиковую нагрузку, а только на среднюю. Потеря 20 мин. работы может иметь более тяжелые последствия, чем прерывание операционной деятельности на 30 мин. Если потеря изменений дороже простоя, то каналы асинхронной репликации необходимо закладывать из расчета на пиковую скорость генерации изменений или переходить на синхронную репликацию до кампуса и мириться с ограничением производительности всей системы. Но как можно предсказать будущие пики? Не можем предсказать - попробуем построить механизм для их сглаживания…Потоком изменений эффективнее всего управлять, если это поток с уровня приложения. На практике это означает, что для восстановления используется не "сырой" журнал изменений с уровня блочных устройств, а некая его производная. Типичным примером являются потоки журнальных операций БД или журнальные файлы, если используется асинхронная передача. Прикладывание журнала БД к резервной копии не всегда гарантирует 100%-е совпадение с оригинальной БД. Это может быть следствием выполнения массивных операций перестроения индексов, отсутствие которых при старте с резервной БД замедлит работу компании, но не прервет ее. Но что делать, если объем изменений сопоставим с объемом БД? Разумно иметь два механизма: первый - для поддержания точных резервных копий на кампусе; второй - для быстрого старта после катастрофы, следующей за массивными изменениями на основном сайте. В случае проблем с журналами БД администратор CDP всегда сможет подстраховать DBA, а DBA сможет сгладить пиковую нагрузку и защитить компанию от потери данных в случае катастрофы. В отличие от журналов БД, CDP журналы всегда можно приложить к резервной копии. Достаточно иметь исправное блочное устройство. Ошибки с журналированием на уровне RDBMS больше не будут носить фатальный характер. Более того, имея два независимых механизма всегда можно сравнить результаты и выбрать правильную стратегию восстановления БД. На этом простейшем сценарии по оптимизации показателей RTO/RPO отчетливо прослеживается необходимость в согласованных действиях между администратором CDP кластера и DBA для достижения оптимального отношения "RTO/цена решения" при RPO=0. Пытливый DR-менеджер (сотрудник, ответственный за восстановление в случае катастроф) быстро обнаружит неполноту в этих рассуждениях. Действительно, показатели RTO при оценке доступности бизнес-сервиса почти всегда не совпадают с RTO при оценке доступности конфигурационной единицы. Если после восстановления БД необходимо откатить транзакции, которые блокируют некий бизнес-сервис, то это время тоже необходимо учесть в RTO. Понятно, что катастрофа в момент выполнения процедуры закрытия года в ERP системе скорее всего приведет к существенному увеличению RTO.

Кроме технической составляющей, стоит затронуть организационный вопрос:
"Сrash-consistent image" vs "Transaction-consistent image". Интересная дилемма, суть которой в следующем: представьте, что Вам необходимо принять решение о том, прикладывать ли все изменения к резервной копии вплоть до последних миллисекунд, когда сгорающее оборудование еще работало, или Вы решите потерять 5 минут с транзакциями, полученными "из огня" (с процессора, перегретого так, что его отключил IPMI, после чего тоже сгорел)? Сложность дилеммы в том, что оперативный анализ подобных рисков сродни гаданию на кофейной гуще. Обстановка уточняется по ходу принятия решения. Наличие плана восстановления (Disaster Recovery Plan, далее DRP) в этом случае сохраняет DR-менеджеру массу нервных клеток, но для этого придется приложить усилия в процессе создания и утверждения самого плана спасения.

Эпилог.

Представьте себе, что в потоке сгенерированных изменений Вам необходимо обнаружить и отменить необратимый процесс, запущенный по ошибке. Последствия этой ошибки уже сохранены в CDP журнале, переданы и приложены к резервным копиям. Получается, что права на ошибку у ответственных исполнителей больше нет? Требования непрерывности бизнеса обязывают планировать свои действия более тщательно? Это уже начинает напоминать не бизнес, а минное поле. Если система журналирования обеспечивает только хранение изменений на блочном уровне, то все последствия ошибок падают на плечи тех, кто принимает решение о запуске необратимых процессов. Апологеты RDBMS могут упрекнуть автора в том, что здесь оставлены без внимания такие механизмы "CDP уровня приложений", как LogMiner, Streams, и будут правы, частично. Современный бизнес все еще зависит от доступности неструктурированных данных. Представьте, что Вы вернулись из отпуска и не можете найти почту в своем корпоративном ящике, почему-то очищен календарь, и список контактов явно поредел. Начиная вспоминать, что же Вы сделали в последний рабочий день, понимаете, что обучение нового офис-менеджера работе с корпоративной почтой не прошло без последствий. Вы обращаетесь с вопросом к IT менеджеру, который через 15 мин. демонстрирует Вам содержание Вашего почтового ящика на тот злосчастный момент в прошлом, когда началось обучение офис-менеджера. На этом чудеса не заканчиваются, и Вы замечаете, что вся входящая почта, поступившая за время Вашего отпуска тоже доступна. При этом IT менеджер специально не контролирует именно Вашу переписку и не вникает во все проблемы бизнеса. В чем секрет фокуса? В первом приближении (почему только в первом станет ясно чуть позже), большинство современных CDP решений позволяют решать описанные задачи. В контексте построения сервиса корпоративного уровня по обработке CDP журналов внимание привлекают продукты, обладающие следующими качествами:

  1. Централизованный, кластеризуемый сервис по хранению и обработке CDP журналов.
  2. Репликатор уровня SAN и, как следствие, "OS agnostic" CDP код. Для различных ОС ключевая функциональность реализуется одним программным кодом. Это качество оказывает сильное влияние на скорость развития продукта и стабильность критичных участков кода.
  3. Полноценный CLI для кастомизации процедур управления журналами, снимками, резервными копиями и т.д.
  4. Возможность обратимой виртуализации для "CDP блочного уровня". Включение CDP механизма не оказывает влияния на защищаемое блочное устройство. Уникальность этого свойства состоит в том, что в любой момент времени один CDP продукт можно заменить на другой.
  5. Поддержка современных протоколов блочного уровня: FC, iSCSI, iSer

В отношении заявленных свойств продукты из перечня SNIA (см.начало статьи) привлекают к себе самое пристальное внимание. Они не случайно выделены SNIA и стоят особняком от других CDP продуктов, таких как: Symantec BackupExec CDP ( http://eval.symantec.com/mktginfo/products/White_Papers/Data_Protection/Backup_Exec_10d_CPS_best_practices_final.pdf ), IBM Tivoli FastBack (http://www-01.ibm.com/software/au/tivoli/fastback), CommVault Simpana (http://www.commvault.com/pdf/DS_QR_Overview.pdf), R1Sorf CDP, и т.д.

Формат данной статьи не позволяет рассмотреть в деталях оба продукта. Сегодня мне хотелось бы обратить Ваше внимание на преимущества FalconStor NSS (Network Storage Server (NSS) ). FalconStor NSS выделяется в первую очередь тем, что это полноценный программный продукт для установки под Linux. В отличие от большинства программно-аппаратных комплексов он может быть установлен в целях ознакомления как на виртуальную платформу (VmWare, Xen, VirtualBox и т.д.) так и на существующее у Вас физическое оборудование. Полноценно кластеризуемое решение доступно как на виртуальных машинах, так и на физических. Поддерживаются две топологии кластера - симметричная и несимметричная (не все блочные устройства должны быть доступны на обоих узлах). В отношении мультипротокольности это самый открытый из существующий продуктов. Судите сами - CDP сервис доступен по протоколам iSCSI, iSCSI(iSer), FC в любых сочетаниях систем хранения и для любых клиентов. Вы можете предоставить одновременный доступ к FC HDS массиву для iSer Linux клиентов и FC клиентов AIX. На лабораторном стенде компании Тринити успешно реплицируются изменения с томов IBM DS4700 на Infortrend F16F-S4031 и далее на IBM DS3400. Помимо защиты данных это еще и удобное средство виртуализации, в котором можно объединить емкости этих устройств в общий пул и раздать его группам администраторов CDP, разграничив доступ и установив квоты по управлению виртуальными блочными устройствами. Скорости доступа к блочным устройствам, полученные на реальных образцах техники представлены для ознакомления:

Для начального этапа внедрения FalconStor NSS исключительно важным является то, что это CDP продукт с обратимой виртуализацией. Вы можете включить его "в разрыв" между любой СХД с SAN и проверить функциональность не внося изменений в хранимые данные. Если какие-то показатели Вас не устроят, то достаточно вернуть схему коммутации и настройку хостов в прежнее состояние.

Типичная схема организации мультипротокольного CDP кластера на базе FalconStor NSS:

Ключевая функциональность CDP кластера на базе FalconStor NSS:

  1. Быстрое восстановление локальных данных в случае повреждения или системного сбоя в любой момент времени в прошлом (случайно удален файл, перемещен каталог, отформатирована файловая система и т.д.).
  2. Восстановление после локальных или региональных катастроф путем переключения на резервный сайт
  3. Безостановочное резервное копирование в любой момент времени без влияния на производительность промышленной системы.
  4. Безостановочная миграция данных на другие системы хранения.
  5. Методика отладки приложений над точными копиями промышленных данных, не требующая ожидания процедур копирования и не требующая дополнительного объема.
  6. Защита данных для серверов с непосредственным хранением (DAS) при наличии свободного Fibre Channel/Ethernet/IB канала.
  7. Наивысшая из всех альтернативных технологий скорость сохранения изменений.

Основные триггеры для принятия решения о необходимости внедрения CDP кластера:

  1. Снижение затрат на хранение журналов при увеличении их суммарного объема (возможность сокращения расходов от положительного эффекта масштаба http://en.wikipedia.org/wiki/Returns_to_scale)
  2. Независимость DRP от сложности сети хранения данных
  3. Формализация процедур верификации DRP (оценка предельных циклов переключения между основным и резервным сайтами)
  4. Единая точка контроля над рисками потери данных (минимизация RPO) и временем простоя компании (устранение организационной SPOF)
  5. Максимизация эластичности показателя цена/качество по ключевым параметрам (RTO, цена каждого GB защищенных данных, масштабируемость по объему и скорости доступа к основным ресурсам защищаемой СХД).

EMC RecoverPoint - во многом аналогичный продукт и заслуживает отдельного повествования, чему и я с удовольствием посвящу одну из следующих статей.

Дополнительная информация по всей линейке продуктов FalconStor расположена на сайте компании Тринити: http://www.trinitygroup.ru/products/soft/falconstor

Обратите внимание на возможность интеграции FalconStor NSS в процедуры управления восстановлением резервного сайта на базе VMware vCenter (FalconStor Failback Manager for VMware vCenter Site Recovery Manager). Весь потенциал технологий виртуализации СХД по настоящему раскрывается в составе комплексной виртуализации центров обработки данных.

С уважением,
Виталий Зверев.

Система Orphus