Рубрикатор |
Статьи | ИКС № 5 2006 |
01 мая 2006 |
Удаленная репликация данных для защиты информационных ресурсов
Характеристики и архитектура резервного ЦОД индивидуальны: в одном случае это копия основного центра с возможностью полного восстановления работы в течение нескольких часов, в другом – небольшая инфраструктура для выполнения отдельных функций информационной системы в случае аварии в основном центре.Базовый способ репликации данных – физическая транспортировка на удаленную площадку оригиналов или дубликатов резервных копий на ленточных накопителях. Там они помещаются в защищенное хранилище либо восстанавливаются на серверах. В результате доступной становится даже информация двухдневной давности и более. Конечно, такая технология используется крайне редко, например при обрыве линии связи.
Современные требования предполагают наличие в резервном центре более свежей копии, с отставанием от восстанавливаемых данных не более чем на несколько часов, а во многих случаях имеется даже мгновенная консистентная копия контента основного ЦОД, что требует использования каналов ПД между основным и резервным центрами. Вместо метода disaster recovery, который в основном предполагает восстановление с резервных копий, все чаще используют disaster restart – быстрое переключение на резервную инфраструктуру в случае аварии, что дает минимальную потерю данных.
Выбор технологии репликации зависит от ценности информации, пропускной способности и задержки каналов связи, применяемого оборудования и ПО, ИТбюджета, требований ко времени восстановления работоспособности, удаленности резервного центра и др. Рассмотрим основные принятые сегодня методы репликации данных в удаленный резервный центр.
Резервное копирование
ПО резервного копирования на корпоративном уровне (Veritas Netbackup, Legato Networker и др.) позволяет строить сложные распределенные системы, в которых копии могут создаваться одновременно на нескольких носителях (ленточных, оптических, дисковых библиотеках) и размещаться на разных площадках.
Технология синтетических резервных копий помогает оптимизировать использование каналов связи (выполняется только инкрементальное копирование, а полные копии формируются серверами), уменьшить «окно резервного копирования» и нагрузку на серверы.
Для переноса данных в резервный центр все чаще пользуются методом копирования на диск. В качестве целевых устройств можно применять удаленные NAS с сетевой файловой системой CIFS или NFS или томами iSCSI, а также дисковые системы Fiber Channel при наличии связи между SAN основного и резервного ЦОД.
Репликация средствами систем хранения
Репликация на уровне дисковых систем – наиболее популярное решение переноса данных в резервный центр. При этом, как правило, используются технологии Fiber Channel SAN. На дисковой системе резервного центра создается и поддерживается копия логических дисков основного ЦОД.
Различают синхронную и асинхронную репликации. В первом случае при каждой записи на логический диск система обновляет данные на удаленной копии и только после этого возвращает хосту подтверждение о завершении операции. При асинхронной репликации подтверждение возвращается немедленно, независимо от результата или длительности операции.
Метод синхронной репликации для достижения приемлемого быстродействия требует использования дорогостоящих высокоскоростных каналов связи между основным и резервным центрами на основе темного оптоволокна (DWDM или SONET). Поэтому им обычно пользуются для организации распределенных кластеров высокой доступности с жесткими требованиями по времени переключения и с потерей минимального объема данных.
Асинхронная репликация менее чувствительна к пропускной способности и задержкам каналов связи и допускает использование более дешевых технологий передачи данных, например по протоколу IP. В основных реализациях метод содержит средства обеспечения целостности. К примеру, данные для переноса формируются в блоки определенной длины и передаются на удаленную систему (каждый следующий блок передается после подтверждения о доставке предыдущего). Помимо постоянной асинхронной репликации часто используется репликация по расписанию, когда синхронизация данных происходит в указанные периоды времени. При этом могут переноситься как все данные, так и только измененные. Естественно, что при асинхронной репликации любого типа копия данных в резервном центре отстает по времени от оригинала.
Несомненные достоинства репликации на уровне ПО дисковых систем – освобождение серверов от операции по переносу данных, относительная прозрачность операции для приложений и сравнительная простота реализации. Кроме того, этот метод наиболее развит по функционалу (отслеживание изменений, обратная синхронизация, группы консистентности, снэпшоты с реплик и др.). Однако его организация обычно требует наличия в резервном ЦОД дисковых систем и модельного ряда того же производителя, что и в основном центре. Правда, есть и исключения: например, EMC SANCopy и OpenReplicator с определенными ограничениями выполняют репликацию данных и на системы других производителей.
В последнее время получили распространение устройства виртуализации систем хранения – IBM SVC, EMC Invista, Storage SVM. Это аппаратно-программные комплексы, которые создают логическое представление инфраструктуры систем хранения и имеют функционалы для синхронной и/или асинхронной репликации данных, что позволяет создавать копии данных без жесткой привязки к системам хранения одного типа на уровне инфраструктуры SAN.
Программная репликация данных
Спектр средств программной репликации данных довольно широк – от функционала низкоуровневого ПО класса Volume Management до встроенных систем в приложениях.
Функционал ПО управления томами, например Veritas Volume Manager и Volume Replicator, фактически идентичен уже описанным дисковым системам, за исключением того, что основная обработка и перенос осуществляются самими серверами данных. Простейший способ программной репликации – зеркальное отображение данных на разных дисковых массивах. ПО управления томами сегодня присутствует в большинстве серверных ОС. В кластерном ПО или его расширениях от многих производителей также содержится этот функционал на уровне файлов, файловых систем или блочного доступа (HP MirrorDisk/UX, HACMP/XD и др.), работающий по протоколам IP или FCP.
Использование ПО на уровне управления томами, с одной стороны, позволяет обеспечить репликацию данных более интеллектуально, консистентно и без привязки к используемому для их хранения оборудованию, с другой – создает дополнительную нагрузку на серверы. Такие средства обычно обладают менее развитым функционалом по сравнению с дисковыми системами.
Наиболее эффективный метод с точки зрения обеспечения интеллектуальности и консистентности операции переноса – репликация на уровне приложений (СУБД, почтовая система, сервер приложений и т.д.). Такой функционал, однако, доступен только в избранных ПО корпоративного класса: Oracle Database Enterprise Edition (DataGuard, Advanced Replication, Oracle STREAMS и др.) или MS SQL Server (Transactional Replication, Snapshot Replication). Кроме того, некоторые способы такой репликации предполагают дополнительную настройку, а часто и программирование приложений для поддержки. Эти технологии могут создавать дополнительные сложности для администраторов,если репликация данных других приложений производится иными способами. Тем не менее при защите данных наиболее важного приложения, например БД Oracle, это обычно оптимальный способ.
С помощью перечисленных способов репликации можно создавать комбинированные технологии: резервное копирование с удаленной реплики, репликацию дисковой резервной копии, многоточечную и многоступенчатую репликацию, миграцию данных на другую платформу и т.д.
Выбор репликации для защиты данных от катастроф
Репликация – один из методов защиты данных, а к выбору технологии защиты необходимо подходить с особой тщательностью и учитывать как технологические, так и экономические аспекты. Например, копирование на дисковых системах может быть значительно дороже в первоначальной стоимости программного решения, но при большом количестве серверов (с учетом стоимости лицензирования каждого из них) его выбор экономически наиболее эффективен. Следует также учитывать стоимость эксплуатации решения, удобство использования и т.д. Кроме того, технология репликации определяется политикой защиты информации, стоимостью простоя, ценностью информации, требованиями ко времени восстановления и др.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!