Репликация хранилища — это процесс непрерывного или осуществляемого по расписанию копирования данных из одной системы хранения в другую, благодаря чему на второй системе доступна актуальная копия на случай выхода из строя первой. Копия, называемая репликой, может находиться в том же центре обработки данных или на удаленном объекте. Она может создаваться дисковым массивом, операционной системой сервера, гипервизором или облачным сервисом хранения. Репликация хранилища является важным компонентом киберустойчивости, особенно в контексте аварийного восстановления и обеспечения непрерывности бизнес-процессов.

В этой статье объясняется разница между репликацией хранилища и репликацией данных, описывается принцип работы репликации хранилища, места ее выполнения, факторы, формирующие стратегию репликации, а также подход Everpure к репликации.

Репликация хранилища против репликации данных

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

Как работает репликация хранилища

У каждых отношений репликации есть источник (также называемый первичной системой) и назначение (также называемое вторичной системой или репликой). Механизмы репликации обычно сначала копируют весь набор данных целиком, а затем отправляют только изменения. Например, в документации Proxmox VE описывается инкрементная отправка новых данных после проведения первоначальной полной синхронизации.

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

Синхронная репликация

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

Обратной стороной является задержка записи. Каждая операция записи включает обратный сетевой вызов ко второму сайту, поэтому расстояние ограничивается величиной дополнительной задержки, которую могут выдержать приложения. В своей документации по Storage Replica Microsoft рекомендует поддерживать среднюю задержку туда и обратно в пределах 5 мс или менее для синхронной репликации.

Асинхронная репликация

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

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

Асинхронная репликация может быть периодической или непрерывной. Периодическая репликация отправляет изменения между снимками состояния (снапшотами) по расписанию, как это делает Proxmox VE. Непрерывная асинхронная репликация передает потоком изменения на целевой объект по мере их возникновения, не дожидаясь подтверждения от целевого объекта. Microsoft заявляет, что служба Storage Replica, выполняющая репликацию непрерывно, теоретически обладает меньшим значением RPO.

Типы репликации хранилища

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

Репликация на уровне массивов (SAN)

Репликация на уровне массивов (также называемая репликацией на базе хранилища или сетей хранения данных / SAN) выполняется операционной системой дискового массива. Массив копирует тома на второй массив на блочном уровне, независимо от записывающих на них хостов.

Репликация на уровне хоста

Репликация на уровне хоста выполняется на сервере. Служба Windows Server Storage Replica, которую Microsoft относит к решениям на уровне хоста, реплицирует тома между серверами или кластерами на блочном уровне и поддерживает как синхронную, так и асинхронную репликацию.

Репликация на уровне гипервизора

Репликация на уровне гипервизора копирует отдельные виртуальные машины. Broadcom описывает VMware vSphere Replication как репликацию виртуальных машин на базе гипервизора и «альтернативу репликации на базе хранилища». Proxmox VE реплицирует гостевые тома на другой узел по расписанию с интервалами от одной минуты до одного раза в неделю.

Репликация на уровне приложений и баз данных

Выше уровня хранилища базы данных реплицируют собственные транзакции. В группах доступности SQL Server Always On режим доступности определяет это поведение: режим с асинхронной фиксацией не ждет, пока вторичные реплики зафиксируют журнал транзакций, в то время как режим с синхронной фиксацией ожидает такого подтверждения ценой увеличения задержки транзакций. Другим примером является репликация баз данных Oracle. Репликация на уровне приложений работает с транзакциями, тогда как репликация на уровне хранилища копирует расположенные ниже тома независимо от того, что на них записывается.

Облачная репликация и репликация объектов

Сервисы облачного объектного хранения выполняют репликацию между бакетами. AWS описывает Amazon S3 Replication как автоматическое асинхронное копирование объектов между регионами AWS или внутри одного региона.

Локальная, городская и удаленная репликация

Репликацию часто делят на три уровня в зависимости от расстояния между источником и назначением:

Локальная репликация: источник и назначение находятся в одном дата-центре. Это защищает от сбоя системы, но не от потери всего сайта.
Городская (метро) репликация: сайты находятся достаточно близко друг к другу (обычно в пределах одного мегаполиса), чтобы синхронная репликация укладывалась в допустимый бюджет задержки приложения. На этом уровне обычно строятся растянутые кластеры, в которых хосты на обоих сайтах работают с одними и теми же данными.
Удаленная репликация: целевой объект расположен достаточно далеко, чтобы пережить региональное ЧП. В удаленных соединениях обычно используется асинхронная репликация, которая исключает обратный сетевой вызов к удаленному сайту из каждой операции записи.

Проекты могут комбинировать уровни. SNIA отмечает, что данные могут реплицироваться на несколько вторичных сайтов. Трехсайтовая архитектура предполагает синхронную репликацию между двумя близлежащими сайтами и асинхронную — на удаленный третий сайт, сочетая нулевой показатель RPO между первыми двумя сайтами и защиту от регионального сбоя.

Активно-активная и активно-пассивная репликация

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

Факторы, формирующие стратегию репликации хранилища

Стратегия репликации представляет собой набор решений относительно режима, уровня, расстояния и процесса восстановления.

RPO и RTO

Национальный институт стандартов и технологий (NIST), в SP 800-34 Rev. 1, defines определяет целевую точку восстановления (RPO) как момент времени, до которого должны быть восстановлены данные после сбоя. Он определяет целевое время восстановления (RTO) как продолжительность времени, в течение которого компоненты системы могут находиться в фазе восстановления до того, как пострадают основные задачи или бизнес-процессы организации.

Нулевое значение RPO для реплики требует синхронной реплики. При запланированной асинхронной репликации данные, записанные после последней завершенной синхронизации, находятся под угрозой, поэтому интервал настраивается в соответствии с RPO. RTO зависит от процесса восстановления: насколько быстро приложения могут перезапуститься на основе реплики. См. RTO против RPO.

Расстояние, задержка и пропускная способность

Двусторонняя задержка (round-trip latency), которая увеличивается с расстоянием, определяет, насколько практична синхронная репликация. Пропускная способность, измеряемая по скорости записи, определяет, успевает ли репликация за процессами. Предварительные требования к Storage Replica от Microsoft требуют наличия сети с достаточной пропускной способностью для обработки рабочей нагрузки ввода-вывода (I/O) на запись. При асинхронной репликации данные перемещаются по мере возможностей сети, поэтому, когда операции записи поступают быстрее, чем канал может их передать, задержка репликации увеличивается.

Группы согласованности и порядок записи

Приложениям, распределяющим данные по нескольким томам (например, база данных с раздельными томами данных и журналов), требуется репликация этих томов как единого целого. SNIA определяет группу согласованности как «совокупность наборов репликации, сгруппированных вместе для обеспечения согласованности порядка записи по всем первичным томам наборов репликации». Без нее на реплике могут оказаться последние записи одного тома наряду с более старым состоянием другого тома.

Отказоустойчивость, возврат исходного состояния и тестирование DR

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

Режим репликации может ограничивать возможные варианты отказоустойчивости. В группах доступности SQL Server режим синхронной фиксации поддерживает ручной и, опционально, автоматический переход на резервный ресурс после синхронизации вторичной системы, в то время как режим асинхронной фиксации поддерживает только принудительный переход с возможной потерь данных. Тестирование DR выполняет процесс перехода на резервную площадку для реплики без ожидания реального сбоя.

Почему репликация хранилища сама по себе не останавливает программы-вымогатели (ransomware)

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

То же самое относится и к ransomware. Шифрование — это изменение данных, и механизм репликации, который копирует каждое изменение, копирует зашифрованные данные на реплику. Восстановление после атаки зависит от точечных копий (point-in-time), которые атака не может изменить или удалить, таких как неизменяемые снимки (immutable snapshots), защищенные от преждевременного удаления, изолированные резервные копии, хранящиеся под 3-2-1 backup strategy, и среда кибервосстановления (cyber recovery).

Репликация и точечные копии покрывают разные виды сбоев. Репликация поддерживает актуальную копию, готовую к отказоустойчивости после сбоя оборудования или площадки. Точечные копии позволяют вернуться к состоянию, которое было до начала повреждения или шифрования. Определения каждого из них см. в snapshots vs. backups vs. replication.

Зачем организации используют репликацию хранилища

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

Как Everpure помогает с репликацией хранилища

Everpure™ FlashArray™ включает синхронную, непрерывную асинхронную и периодическую асинхронную репликацию в операционной среде Purity//FA.

ActiveCluster™: Синхронная репликация между двумя системами FlashArray. При нормальной работе операция записи не подтверждается хосту до тех пор, пока она не будет защищена в NVRAM на обоих массивах, что обеспечивает поведение ActiveCluster с нулевым RPO на уровне хранилища. ActiveCluster также обеспечивает автоматический переход на резервный ресурс и активно-активный доступ к растянутым томам на двух площадках.
ActiveDR™: Непрерывная асинхронная репликация с почти нулевым RPO. Исходный массив подтверждает запись от хоста, не дожидаясь подтверждения от целевого массива, поэтому расстояние между массивами не добавляет задержки для приложений хоста. Переход на резервный ресурс выполняется вручную или через API, а тесты DR могут выполняться во время продолжения репликации.
Группы защиты: для периодической репликации на основе снимков группы защиты FlashArray настраивают расписание снимков и расписание репликации отдельно. Они группируют связанные тома в рамках общих политик защиты, позволяя защищать их и реплицировать вместе.
Трехплощадочная устойчивость: начиная с Purity//FA 6.10.5, выпущенной 1 апреля 2026 года, трехплощадочные конфигурации объединяют синхронную репликацию ActiveCluster на уровне метрополитена с асинхронной репликацией ActiveDR на удаленную третью площадку. Эта архитектура обеспечивает защиту с нулевым RPO между синхронизированными площадками в пределах города и дополнительную защиту от аварий при региональных сбоях. Фактические целевые показатели восстановления зависят от конфигурации и процедур восстановления приложений.
FlashBlade: Для неструктурированных данных Purity операционная среда на FlashBlade включает репликацию файлов и объектов.
Облачная выгрузка (Cloud offload): Purity CloudSnap™ выгружает снимки FlashArray в AWS или Azure для создания внеплощадочной долгосрочной копии.

Снимки SafeMode™ защищают снимки групп защиты от преждевременного удаления. Ни один человек, даже администратор, не может удалить защищенный снимок до наступления запланированного времени его удаления, а частота и сроки хранения снимков не могут быть уменьшены в одностороннем порядке. Руководство Everpure по восстановлению после программ-вымогателей рекомендует приостанавливать репликацию на вторичные площадки во время атаки, чтобы зашифрованные данные не перезаписали чистые копии.

Узнайте больше о решениях Everpure для киберустойчивости.

Заключение

Любой проект репликации хранилища балансирует между расстоянием и потерей данных. Синхронная репликация поддерживает нулевой RPO в пределах задержки, допускаемой каналом связи в пределах города, а асинхронная репликация допускает ненулевой RPO для достижения удаленной площадки. Уровень, на котором работает репликация, определяет, что защищается как единое целое: весь массив, отдельная виртуальная машина или бакет.

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

Часто задаваемые вопросы о репликации хранилища

Каковы два типа репликации?

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

В чем разница между резервным копированием и репликацией данных?

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

Что такое задержка репликации?

Задержка репликации — это время между записью данных на источник и моментом, когда эта же запись доходит до реплики. В то время как синхронная репликация находится в синхронном состоянии и реплика уже содержит каждую подтвержденную запись, задержка отсутствует. При асинхронной репликации задержка зависит от интенсивности записи, пропускной способности канала и расписания репликации, и именно она определяет, сколько недавних данных может быть потеряно.

Что такое программное обеспечение для репликации хранилища?

Программное обеспечение для репликации хранилища копирует данные между системами хранения и управляет связью между источником и назначением. Оно может быть встроено в операционную систему дискового массива, операционную систему сервера, такую как Windows Server Storage Replica, функцию гипервизора, такую как VMware vSphere Replication, механизм базы данных, такую как группы доступности SQL Server Always On, или облачный сервис, такую как Amazon S3 Replication.