EchoStream: концепции репликации данных (часть 1)

В этой статье я попытаюсь привести описание архитектуры программного продукта компании VisionSolutions – EchoStream. Этот программный продукт позволяет реализовать концепцию непрерывной защиты данных (continuous data protection ) для восстановления их в случае аварии. Сразу необходимо отметить, что программный продукт EchoStream работает на серверах IBM Power System под управлением операционной системы AIX версий 5.2, 5.3 и 6.1.

В основе данной статьи лежит документ "EchoStream Version 3.5.0.0 Concepts Guide  For AIX".

 

Итак, что может EchoStream? Какое окружение (программное и аппаратное) ему необходимо для работы? И что мы можем получить в случае его использования?

 

Во-первых, стоит отметить, что EchoStream не нуждается в каком-либо специализированном аппаратном обеспечении. Он прекрасно работает на стандартном оборудовании. К оборудованию в данном случае можно отнести серверы, системы хранения данных и сети.

 

Во вторых, в набор стандартных «фич» EchoStream включено следующее:

1.      Асинхронная репликация данных

2.      Быстрый возврат к любой из предыдущих копий версий данных  за счет использования концепции виртуализации «Any PointInTime»

3.      Возможность создания снимков данных (snapshot), для работы с ними на другом узле

4.      EchoStream не оказывает практически никакого влияния на работы ваших приложений

5.       Позволяет минимизировать RTO (Recovery Time Objective) и RPO (Recovery Point Objective) внутри OWR (Optimized Recovery Window)

6.       Позволяет проверить целостность копии данных перед запуском приложений на запасном узле

7.       Поддерживает приложения работающие с данными как на файловом, так и на блочном уровне

8.       Позволяет использовать существующие на предприятии механизмы управления данными, процедуры резервного копирования, и системы высокой доступности.

 

                   Роль в системной архитектуре

 

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

Кроме того, в стандартной конфигурации EchoStream можно наблюдать и так называемый Административный Сервер (Administrative Server), который используется для настройки и мониторинга EchoStream. К Административному Серверу предъявляются минимальные требования по аппратному обеспечению. Один Административный Сервер может управлять несколькими EchoStream системами.

Кроме того, вы можете настроить один или несколько серверов репликации (Replicated Server(s)); на них могут храниться реплики данных скопированные с Recovery Server. Требования к аппаратному обеспечению Replicated Server похожи на требования к Recovery Server.

C точки зрения системной архитектуры EchoStream, роль Replicated Server очень схожа с ролью Recovery Server. Функционально они очень похожи. За одним исключением. Данные на Продуктивном сервере (Production Server) могут быть восстановлены только с Recovery Serer, и никогда с Replicated.

echostream1.jpg

 

                   Особенности работы и дизайна

 

            EchoStream спроектирован таким образом, что он перехватывает каждую операцию записи выполняемую приложением в синхронном режиме. Это позволяет убедиться в правильной последовательности записываемых EchoStream данных, а так же минимизировать их потерю в случае локального сбоя. Для того что бы минимизировать влияние EchoStream на работающие приложения, передача данных с Production Server на Recovery Server ведётся в асинхронном режиме.

            Для поддержки широкого набора приложений и аппаратного обеспечения EchoStream спроектирован как расширение стандартной парадигмы существующего механизма управления дисковой подсистемой (LVM). EchoStream позволяет обеспечить защиту данных приложений работающих как на блочном уровне, так и на уровне файловом. Кроме того, наличие в системе работающего EchoStream никак не влияет на выбор администратором инструментов для оценки работоспособности системы и настройки её производительности.

            Для того, что бы реализовать концепцию Any Point-In-Time Recovery, необходимо хранить историю (журнал) всех выполненных на Production Server операций записи. Эти журналы хранятся на Recovery Server. Такой выбор позволяет проводить различные операции по управлению журналами (такие как, например, оптимизация), без влияния на продуктивный сервер. Кроме того, хранение журналов на Recovery Server позволяет минимизировать влияние EchoStream на систему хранения продуктивного сервера.

 

                        «Контекст» в терминах EchoStream

Контекст (Context)  – это ни что иное, как набор объектов подлежащих защите со стороны EchoStream. При этом, EchoStream должен учитывать порядок записи данных на Production Server, а так же привязку данных к журналам и ассоциированными с ними аттрибутами. Иными словами Контекст EchoStream – это совокупность конфигурационной информации, и информации необходимой для восстановления данных. Приконфигурировании EchoSteram на продуктивном сервере администратор поределяет так называемый первичный контекст (Primary Context), а на Recovery и Replication серверах соответствующий первичному Failover Context. И конечно же, несколько контекстов могут использовать одно и тоже аппаратное обеспечение.

 

                        Файловый контейнер

Термин «Файловый контейнер» EchoStream (File Container) использутся для описания специальных объектов Echostream. Эти объекты используются EchoStream для поддержания контекстов в работоспособном состоянии. Существует довольно большое количество разнообразных файловых контейнеров. Наиболее распространённым, и необходимым для понимания является Log File Container (LFC). LFC – это логическая еденица использумая для передачи данных между системами. Как мы уже выяснили, EchoStream перехватывает все операции записи на продуктивном сервере. Эти операции дублируются в LFC. Как только LFC будет заполнен, его содержимое передаётся на Recovery Server. Как только содержимое LFC будет  передано, оно применяется к существующей реплике данных. В том случае если в системе имеется Replicated Server, то содержимое копируется и на него. После того как LFC скопирован с Production на Recovery сервер (а в случае существования Replicated  и на него), LFC на тивном сервере обвобождается для дальнейшего использования.

 

                        Описание EchoStream Datatap

В операционной системе AIX имеется замечательный механизм для виртуализации системы хранения – это LVM. В случае установки и использования EchoStream происходит следующее: EchoStream встраивает в ОС AIX собственные расширения ядра операционной системы. Так называемые datataps (даже не буду пытаться использовать перевод этого слова :). Хотя формально можно перевести как «устройство для перехвата (прослушивания данных))  Datataps распологаются над уровнем LMV.  Но под уровнем файловых систем. Наличие такого промежуточного уровня позволяет EchoStream перехватывать все блочные операции ввода-вывода. С технической точки зрения, datatap получает буферы подлежащие записи с уровня файловой системы. После этого данные обрабатываются и передаются ниже. На уровень менеджера логических томов. При чтении данных с дисков, никаких операций над данными не выполняется.

echostream2.jpg

Datatap должны быть загружены как на Production, так и на Recovery сервере. На продуктивном сервере, datatap ответственнен за «расщепление» операций записи. Результат каждой операции записи помещается как в защищаемый EchoStream том, так и в redo log. Каждый Redo Log – это отдельный логический том.

 

                        Журнал EchoStream

В архитектуре EchoStream существуют специальные структуры предназначенные для работы с Redo и Undo Log. Это After Image Log File Container (AILFC) и Before Image Log File Container (BILFC). Именно они используются Redo и Undo Log.  В совокупности они и представляют журнал EchoStream. На Recovery Server каждому Redo Log сопоставляется Undo Log. Обычно, эти журналы изображают в виде одного тома.

 

 

                   Агенты EchoStream

Первичный агент работающий на продуктивном сервере называется Log Creation

Agent (LCA). На Recovery сервере могут работать три агента: Assured Backup Agent (ABA), Archive Agent (AA), и Restore Agent (RA).

Доставка журналов с продуктивного сервера на recovery – это задача LCA. LCA считывает из журнала информацию относящуюся к redo log, и отправляет её по одной или нескольким IP сетям агенту работающему на recovery сервер. Оба агента используют один и тот же сокет. Номер порта для сокета может быть выбран из установок по умолчанию, а может быть и задан администратором.

На другой стороне сокета (на Recovery server) за приём информации отвечает ABA. ABA принимает информацию из redo log в той последовательности, в которой она была создана на продуктивном сервере. Получив эту информацию ABA сохраняет её в Recovery Log (напоминаю – это блочное устройство, не взаимодействующее с файловой системой). Получив данные, ABA не только записывает их в Recovery Log, но и создаёт специальную служебную запись называемую State Map Transactions (SMTX) – по сути это ничто иное как карта транзакций продуктивного сервера.

После создания этой карты, но перед тем как применить транзакции к реплике данных, необходимо выполнить ещё одно действие. Необходимо записать то, что EchoStream собирается сделать в Undo Log. Нужно это для того, что бы была возможность сделать откат транзакций во времени. Физически Undo Log – это логический том.

После того как необходимая информация записана в Undo Log можно применять транзакции по отношению к реплике данных. Вуа-ля! Мы получили  практически точную копию данных продуктивного сервера.

 

На Recovery сервере, кроме ABA может работать и другой агент. Archive Agent (AA). Зачем он нужен? Нужен он для того что бы расширить возможности операции rollback (отката) за счёт копирования Redo и Undo Log на ленту. АА работает с Tivoli Storage Manager (TSM). Когда AA архивирует логи на ленту, то он всегда пишет их парами – redo и undo. За счёт этого мы получаем возможность произвести восстановление на любой момент времени (Any Point In Time).

За восстановление отвечает RA на Recovery сервере. В отличии от других агентов, он не запущен постоянно, а может быть активирован по требованию (из командной строки или из GUI).

C помощью RA можно выполнить следующие типы операций восстановления данных:

  • Виртуальное восстановление на указанную дату и время
  • Продуктивное восстановление на указанную дату и время
  • Виртуальное восстановление в виртуальный Full Backup (VFB)
  • Продуктивное восстановление в виртуальный Full Backup (VFB)
  • Восстановление индивидуальных томов

 

Виртуальное восстановление производится на запасном (backup) сервере. Продуктивное восстановление данных производится для всех томов указанных в контексте на продуктивный сервер.

 

                   Репликация

EchoStream работает на продуктивном сервере, создавая копию защищённых томов на Recovery сервере. Для повышения доступности и надежности, рекомендуется для Recovery сервер выделять удалённую машину. На рисунке ниже можно видеть процесс передачи данных во время их репликации.

 

echostream3.jpg

 

На продуктивном сервере операции записи расщепляются datatap. Одна из копий данных записывается на защищаемый том. Другая копия, совместно с метаданными пишется в redo log.

LCA просматривает журнал в поисках заполненных логов и изменённой информации.  При наличии оных, он передаёт log файл с использованием TCP/IP на recovery сервер. На нём ABA записывает log файл на диск (при выполнении этой операции, на recovery сервере данные не проходят через уровень datatap).

ABA просматривает log файлы (в порядке их поступления) и используя метаданные прочитанные из реплики вычисляет сколько места потребуется для записи вновт поступившей информации в Undo log. Затем, ABA считывает информацию из redo log и применяет модификации к реплике.

 

                   Конфигурация журналов

Продуктивный журнал (production log) хранит redo log буферы до тех пор, пока журналы не будут полностью переданы на Recovery сервер. После того как это случиться, журналы вновь становятся доступными для записи в них новой информации.

            Очень важной процедурой является выбор правильного размера журналов. В том случае, если они слишком маленькие, то из передача с продуктивного на recovery сервер будет выполняться очень часто (соответственно возрастает нагрузка на сеть). Если же журналы слишком велики, то возможна ситуация, когда большой объем информации не передан на recovery сервер, продуктивный выходит из строя, и восстановление последнего состояния production не представляется возможным.

 Продолжение следует………………

Оставьте комментарий