Последние несколько лет для ИТ-индустрии были особенно богатыми на новые технологии и на термины, которыми они обозначаются. Слово “репликация” (равно как и “виртуализация” и некоторые другие) может иметь несколько значений, в зависимости от того, какой смысл в него закладывает производитель того или иного решения. Поэтому перед ИТ-директором современного предприятия зачастую встает проблема — разобраться в разновидностях репликации, систематизировать ее варианты и, что сложнее всего, — выбрать наиболее рациональный способ и продукт для репликации, исходя из внутренней специфики предприятия.
 Рисунок 1.Репликация на уровне хоста (варианты решений на базе Backbone Netvault Replicator) |
С точки зрения ИТ, репликация данных (англ. data replication) — это механизм синхронизации содержимого нескольких копий объекта (например, базы данных, файловой системы, др.). Репликация данных (далее репликация) предполагает, что изменения, сделанные в одной копии объекта, будут отображены во всех копиях, на которые она распространяется.
Часто в литературе можно встретить два основных термина, которые используются для обозначения механизма поддержки синхронного состояния данных — это репликация и зеркалирование. Зеркалированием называется механизм создания полностью идентичной (зеркальной) копии данных или нескольких зеркальных копий относительно главного хранилища, в то время как репликация не обязательно поддерживает зеркальную копию. Важный нюанс заключается в том, что главной задачей в большинстве случаев является не обеспечение зеркального отображения носителя (что в общем случае обеспечивает зеркалирование), а обеспечение целостного образа данных, который будет функциональным в случае прерывания работы приложения.
Репликация может осуществляться как средствами самого приложения (если такие запрограммированы), так и дополнительными внешними средствами. Так как мы не рассматриваем сейчас конкретное приложение, то будем говорить о внешних средствах, которые позволяют осуществлять репликацию вне зависимости от приложений, которые используют эти данные. Естественно, что каждое приложение может особенным образом работать с данными, и, соответственно, при использовании внешних средств репликации нужны механизмы, которые будут обеспечивать целостность данных в случае прерывания работы приложения. Хотя если приложение обладает своими средствами поддержки целостности данных, то в некоторых случаях можно обойтись без дополнительных средств контроля целостности данных.
Типичными задачами, которые помогает решать репликация, являются:
• обеспечение непрерывности бизнеса (отказоустойчивые и катастрофоустойчивые решения);
• создание резервных копий данных;
• распределение/распространение контента;
• консолидация систем хранения данных и серверов;
• миграция данных.
Различают репликацию в реальном времени (online data replication) и отложенную или автономную репликацию (offline data replication).
 Рисунок 2. Репликация на удалённое клиентское приложение средствами Constant Data Replicator (сейчас Backbone Netvault Replicator) |
Для репликации в реальном времени обычно используют два варианта осуществления синхронизации копий данных:
• Синхронный режим — данные, с точки зрения приложения, считаются записанными только тогда, когда они записаны на все хранилища (обычно два или три — главное и резервные, могут находиться как в рамках одной системы хранения, так и на различных системах хранения данных). Такой режим поддерживают традиционные средства создания зеркальной копии.
• Асинхронный режим — данные, с точки зрения приложения, считаются записанными тогда, когда они записаны на главное хранилище (такой режим могут поддерживать как средства обычного зеркалирования (асинхронного), так и средства репликации, поддерживающей целостность данных).
Особенность процесса записи заключается в том, что приложение считает данные записанными на хранилище не тогда, когда они физически записаны на носитель, а тогда, когда приложение получает подтверждение от нижестоящего в системной иерархии устройства. Понимание этого поможет избежать неожиданностей при проектировании катастрофоустойчивого или отказоустойчивого решения.
Репликация может осуществляться на различных уровнях ИТ-инфраструктуры:
• на уровне хоста (используется как для серверов, так и для ПК);
• на уровне сети (обычно в сети хранения данных);
• на уровне контроллера системы хранения данных.
Репликацию на уровне хоста можно осуществлятьна различных подуровнях, в том числе на уровне приложений, а также на уровне файловой системы, на уровне менеджера томов или ее можно внедрить в ОС на уровень, который позволяет абстрагироваться от файловой системы, обеспечивая блочную репликацию.
Программное обеспечение репликации на уровне хоста осуществляет синхронизацию данных на разных хранилищах, отправляя данные на удаленное клиентское приложение или же на локальный либо сетевой диск. Использование копирования на удаленное клиентское приложение обычно позволяет более гибко управлять данными, например, использовать шифрование, сжатие данных или двухстороннюю репликацию c поддержкой целостности данных.
Преимущества репликации на уровне хоста :
• простота использования при малом количестве хостов;
• самый недорогой метод для малого количества хостов;
• большая гибкость решений;
• простота реализации репликации с поддержкой целостности данных;
• не нужно использовать дополнительное оборудование;
• не зависит от используемых систем хранения данных.
Недостатки:
• влияние на производительность хостов;
• высокая сложность управления и цена при большом количестве хостов;
• зависимость от программного обеспечения хоста (ОС, файловой системы, менеджера томов или приложения), которая в принципе не является большим недостатком, в случае если выбранный продукт прекрасно интегрируется с уже установленным на хосте программным обеспечением.
 Рисунок 3.Репликация на уровне сети на примере Falconstor IPStor Replication Services |
Существует два подхода к расположению устройств, осуществляющих репликацию в сети, — это in-band и out-of-band расположение соответственно на пути следования данных и за его пределами. Оба подхода достаточно интересны и имеют как преимущества, так и недостатки. Но в последнее время in-band технология (рисунок 3) получила развитие в виде устройств, поддерживающих кластеризацию, таким образом, был нивелирован основной недостаток in-band технологии — ограниченное масштабирование, в то время как использование кластеризации для out-of-band устройств не позволяет полностью устранить такой же недостаток.
К преимуществам репликации на уровне сети относятся:
• простота использования при большом количестве хостов;
• недорогой метод для большого количества хостов;
• большая гибкость решений и простота управления;
• не зависит от используемых систем хранения данных и хостов;
• не уменьшает производительность приложений (при количестве хостов больше 100 используется кластеризиция).
Недостатки:
• необходимость в использовании дополнительного оборудования;
• высокая цена при малом количестве хостов.
На рисунке 3 показана схема с использованием журнальной репликации, вместе с которой может быть применена технология непрерывной защиты данных — CDP (Continuous Data Protection), обеспечивающая возможность восстановления при повреждении данных, на любой период времени, определенного конфигурацией.
Репликация на уровне контроллера системы хранения данных является неким частным случаем варианта репликации на базе сети. Иногда системы хранения данных, использующие репликацию на базе контролера, используют практически аналогичные предыдущему типу архитектурные решения, с тем лишь отличием, что устройство репликации встроено в систему хранения данных и не может быть использовано отдельно от нее. К наиболее интересным решениям репликации на уровне контроллера можно отнести сложные мощные решения виртуализации серии Universal Storage Platform Hitachi Data Systems и простые недорогие реплики на базе контроллера начального и среднего уровня от Dothill (эта функция еще не используется в серийных устройствах, но ее обещают запустить в июне 2006 года). USP Hitachi практически реализует модель виртуализации (в т.ч. репликации) в сети хранения, позволяя подключать к контроллеру не только собственные диски системы хранения, но и другие целостные системы.
Система самостоятельно обеспечивает управление данными на всех подключенных хранилищах. (рис. 4).
Системы хранения данных от DotHill, реализующие репликацию, обеспечивают эту функцию средствами пакетного удаленного копирования моментальных снимков, осуществленных средствами контролера системы хранения данных.
Таким образом, копия данных откладывается на уровне контроллера системы хранения данных. Поскольку эта функция достаточно простая, ожидается, что это решение будет доступным по цене.
Преимущества:
• Простота использования для одного хранилища в простых системах.
• Объединение всех преимуществ систем репликации на уровне сети для продвинутых решений.
• Отсутствие необходимости в использовании дополнительного оборудования.
• Простота управления одной системой (в простых решениях) либо группой подключенных хранилищ (в продвинутых системах).
Недостатки:
• Дорогое решение при использовании продвинутых мощных систем.
• Привязка к одному производителю.
• Отсутствие гибкости при использовании простых решений.
• Слишком упрощенный функционал недорогих решений.
 Рисунок 4. Схема подключения Hitachi Universal Storage Platform |
С Владимиром Савьяком, исполнительным директором ПНВП “Юстар”, можно связаться по адресу
sv@ustar.ua
