Асинхронная репликация снимков из пода ActiveCluster на ещё одну систему хранения

Автор: Anthony Nocentino, Asynchronous Replication of Snapshots from an ActiveCluster Pod to a Third Array

Я восстанавливал свою трёхсайтовую демонстрационную лабораторию SQL Server и столкнулся с тем, чего давно хотел. Если вы когда-либо проектировали среду SQL Server на ActiveCluster, вам знаком этот сценарий: два FlashArray, работающие с синхронно реплицируемым модулем (pod) для нулевой точки восстановления (RPO) между сайтами, и третья система хранения где-то ещё для более длительного хранения и копии для аварийного восстановления. Проблема была в том, что вы не могли получить данные на эту третью систему хранения напрямую из пода Группы защиты внутри растянутого пода просто не могли иметь целью систему хранения.

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

В этой статье я покажу, как настроить это «от начала до конца» с помощью Pure Storage PowerShell SDK2, чтобы вы могли автоматизировать этот процесс. Поехали.

Проблема, которую мы решаем

Вот архитектура, которую большинство из нас в итоге хочет для критически важного SQL Server:

• Нулевая RPO между двумя локальными сайтами: ActiveCluster поддерживает модуль, синхронно реплицируемый между двумя FlashArray. Ваши тома SQL Server находятся в этом модуле, и обе системы хранения могут обслуживать ввод-вывод.
• Третья географически удалённая копия: Асинхронная репликация на третью систему хранения для регионального аварийного восстановления, долгосрочного хранения снимков или копии, защищённой SafeMode, которая находится за пределами метро-кластера.

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

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

У этой конфигурации есть название, и знание его значительно упрощает поиск в документации: Everpure называет это Active-Active Asynchronous Replication. В руководстве по лучшим практикам асинхронной репликации это описывается как «использование групп защиты внутри модулей ActiveCluster, настроенных с целью асинхронной репликации по расписанию».

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

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

Есть ещё одно ограничение, о котором стоит знать перед началом, потому что оно определяет всю архитектуру. Том ActiveCluster может быть источником асинхронной репликации, но не может быть целью. Снимки передаются из модуля на третью систему хранения, и ничто не передаётся обратно в модуль таким образом. На третьей системе хранения эти снимки попадают как обычные снимки групп защиты, поэтому при восстановлении там вы копируете их в обычные тома, а не в растянутый модуль. Это нормально для копии аварийного восстановления, и об этом стоит знать, прежде чем рисовать топологию, предполагающую репликацию в под.

Моя лабораторная конфигурация

Вот с чем я работаю. Системы хранения работают под управлением Purity//FA 6.10.6 с включённым SafeMode.

Компонент	Имя	Роль
ActiveCluster array 1	flasharray1	Участник пода, источник асинхронной репликации
ActiveCluster array 2	flasharray2	Участник пода, синхронный партнёр
Третья система хранения	flasharray3	Цель асинхронной репликации
Pod	SQL-AC-FTDemo	Растянутый под, содержащий тома SQL Server
Том	SQL-AC-FTDemo::SQL-ACTIVEC01-FTDemo	Том данных SQL Server внутри модуля
Группа защиты	SQL-AC-FTDemo::ASYNC	Находится внутри пода, целью является третья система хранения

А вот архитектура защиты, которую я создаю. Это классический шаблон: короткое локальное хранение и более длительное удалённое хранение:

• Расписание снимков: Создавать снимок на источнике каждые 5 минут, хранить каждый на источнике в течение 3 дней.
• Расписание репликации: Реплицировать снимок на цель каждые 5 минут, хранить каждый на цели в течение 2 недель.

Это моё тестирование в лаборатории. Я искал чёткое указание на стабильный релиз (GA) для этого конкретного рабочего процесса и не нашёл его. Ближайшая версия, которую я нашёл, — это то, что ActiveCluster по Fibre Channel, сосуществующий с ActiveDR или асинхронной репликацией в одной системе, поддерживается на Purity//FA 6.1.3 и новее, а в руководстве по лучшим практикам асинхронной репликации Pure документирована Active-Active Asynchronous Replication с 2021 года. В FAQ по ActiveCluster следует проверять точные функции, предостережения и требования к версии перед тем, как проектировать на основе этого. Ваши результаты могут отличаться.

Настройка с помощью PowerShell

Теперь я проведу вас через весь процесс сборки с помощью Pure Storage PowerShell SDK2. Все выводы ниже получены в моей лаборатории.

Шаг 0: Подключение к обеим системам хранения

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

Import-Module PureStoragePowerShellSDK2

# Участник ActiveCluster, от которого мы будем управлять конфигурацией
$SourceArrayName = 'flasharray1'

# Третья система хранения, наша цель асинхронной репликации
$TargetArrayName = 'flasharray3'

# Имена объектов Purity. Префикс модуля делает эту работу возможной.
$PodName    = 'SQL-AC-FTDemo'
$VolumeName = 'SQL-AC-FTDemo::SQL-ACTIVEC01-FTDemo'
$PGroupName = 'SQL-AC-FTDemo::ASYNC'

$Credential = Get-Credential

$SourceFlashArray = Connect-Pfa2Array -Endpoint $SourceArrayName -Credential $Credential -IgnoreCertificateError
$TargetFlashArray = Connect-Pfa2Array -Endpoint $TargetArrayName -Credential $Credential -IgnoreCertificateError

# Purity ссылается на системы хранения по их имени, которое может отличаться от конечной точки,
# к которой вы подключились. Получите реальные имена, чтобы каждый следующий шаг использовал правильное значение.
$SourceArrayShortName = (Get-Pfa2Array -Array $SourceFlashArray).Name
$TargetArrayShortName = (Get-Pfa2Array -Array $TargetFlashArray).Name

"Source array: $SourceArrayShortName"
"Target array: $TargetArrayShortName"

Вывод:

Source array: flasharray1
Target array: flasharray3

Это последнее замечание важнее, чем кажется. Некоторые из следующих командлетов ожидают имя Purity, а не конечную точку, к которой вы подключились, и в лаборатории с псевдонимами DNS эти два значения быстро расходятся.

Шаг 1: Подтверждение, что модуль растянут

Прежде чем что-либо создавать, давайте подтвердим, что модуль действительно растянут на две системы хранения. Get-Pfa2PodArray возвращает модуль и его участников. Обратите внимание, что свойство, которое вы раскрываете, — это _Member (с ведущим подчёркиванием).

$PodMembers = Get-Pfa2PodArray -Array $SourceFlashArray -GroupName $PodName |
    Select-Object -ExpandProperty _Member

$PodMembers | Format-Table Name, Id -AutoSize

Вывод:

Name         Id
----         --
flasharray1  ac5fc11f-8b3b-49a0-8261-43baf50b281b
flasharray2  081f096d-1c16-42a6-9855-92678d705a1c

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

$PeerArrayShortName = ($PodMembers | Where-Object Name -ne $SourceArrayShortName).Name
"ActiveCluster peer: $PeerArrayShortName"

Вывод:

ActiveCluster peer: flasharray2

Шаг 2: Проверка подключения к третьей системе хранения

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

Get-Pfa2ArrayConnection -Array $SourceFlashArray -Name $TargetArrayShortName |
    Format-Table Name, Type, Status, ReplicationTransport, Encryption -AutoSize

Вывод:

Name        Type              Status    ReplicationTransport Encryption
----        ----              ------    -------------------- ----------
flasharray3 async-replication connected ip                   unencrypted

Если у вас ещё нет этого подключения, вы создаёте его, получив ключ подключения с целевой системы хранения и используя его на источнике:

# Получите ключ подключения с ЦЕЛЕВОЙ системы хранения
$ConnectionKey = (Get-Pfa2ArrayConnectionKey -Array $TargetFlashArray).ConnectionKey

# Создайте подключение с ИСТОЧНИКА
New-Pfa2ArrayConnection -Array $SourceFlashArray `
    -ManagementAddress $TargetArrayName `
    -ConnectionKey $ConnectionKey `
    -Type 'async-replication' `
    -Encryption 'unencrypted'

Параметр -Type 'async-replication' отличает это подключение от подключения sync-replication, которое уже существует между вашими двумя системами ActiveCluster. -Encryption по умолчанию имеет значение unencrypted (незашифрованное), что и используется в моей лаборатории. Если этот трафик репликации покидает ваш центр обработки данных, установите для него значение encrypted намеренно.

Важно: Требуются асинхронные подключения от обоих участников ActiveCluster к третьей системе хранения, а не только рекомендуется. В руководстве по лучшим практикам асинхронной репликации Pure прямо сказано: «Требуются асинхронные подключения репликации от обоих источников ActiveCluster к целевой системе хранения». Целевая система хранения одновременно переносит обновления снимков от обоих источников, и если одна система ActiveCluster выходит из строя, «асинхронная репликация автоматически продолжается с выжившей системы ActiveCluster», поэтому ваше RPO сохраняется независимо от того, какая сторона выжила.

Шаг 3: Создание группы защиты внутри модуля

Это та часть, которая раньше была тупиком. Вы создаёте группу защиты с именем, начинающимся с префикса модуля: pod::pgroup, и Purity создаёт её внутри модуля.

New-Pfa2ProtectionGroup -Array $SourceFlashArray -Name $PGroupName

Вывод (сокращён):

Name                : SQL-AC-FTDemo::ASYNC
Id                  : a99154ee-3c4c-1f82-c9d6-9b65350456ec
Pod                 : @{Id='4840a8a0-acea-b473-1c75-844f2199424b'; Name='SQL-AC-FTDemo'}
Source              : @{Name='SQL-AC-FTDemo'}
TargetCount         : 0
VolumeCount         : 0
...

Обратите внимание на свойства Pod и Source. Группа защиты знает, что принадлежит SQL-AC-FTDemo, и под является её источником. Значение Source определяет, какое имя эта группа защиты получит на целевой системе хранения, поэтому в итоге у вас там будет SQL-AC-FTDemo:ASYNC вместо flasharray1:ASYNC.

Обратите также внимание, что оба расписания запускаются отключёнными с частотами по умолчанию, и обе политики хранения являются значениями по умолчанию Purity. Мы исправим всё это на Шаге 7.

Если вы создавали и удаляли это ранее, вы получите сообщение Name belongs to a protection group that has been destroyed and is pending eradication (Имя принадлежит уничтоженной группе защиты, ожидающей окончательного удаления). Уничтоженная группа защиты сохраняет своё имя в течение всего периода ожидания окончательного удаления. Либо выберите другое имя, либо сначала окончательно удалите старую.

Шаг 4: Добавление тома

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

New-Pfa2ProtectionGroupVolume -Array $SourceFlashArray `
    -GroupName $PGroupName `
    -MemberName $VolumeName

Get-Pfa2ProtectionGroupVolume -Array $SourceFlashArray -GroupName $PGroupName |
    Format-Table @{n='Group';e={$_.Group.Name}}, @{n='Member';e={$_.Member.Name}} -AutoSize

Вывод:

Group                Member
-----                ------
SQL-AC-FTDemo::ASYNC SQL-AC-FTDemo::SQL-ACTIVEC01-FTDemo

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

Шаг 5: Добавление третьей системы хранения в качестве цели

Теперь добавляем цель. New-Pfa2ProtectionGroupTarget принимает группу защиты в -GroupName и целевую систему хранения в -MemberName.

New-Pfa2ProtectionGroupTarget -Array $SourceFlashArray `
    -GroupName $PGroupName `
    -MemberName $TargetArrayShortName

Вывод:

Context : @{Id='ac5fc11f-8b3b-49a0-8261-43baf50b281b'; Name='flasharray1'; ResourceType='remote-arrays'}
Allowed : True
Group   : @{Id='a99154ee-3c4c-1f82-c9d6-9b65350456ec'; Name='SQL-AC-FTDemo::ASYNC'}
Member  : @{Id='f269a914-00c5-408f-b6ba-a3c4048cdbfd'; Name='flasharray3'; ResourceType='array'}
Status  : replicating

Allowed вернулось как True, а Status показывает replicating немедленно. Purity устанавливает этот флаг самостоятельно, основываясь на лимитах репликации и состоянии подключения, поэтому в здоровой конфигурации вы получаете True без каких-либо действий с вашей стороны. Если у вас вернулось False, не хватайтесь за командлет первым делом. Проверьте состояние подключения и ваши лимиты репликации, потому что именно об этом Purity сообщает, и репликация не будет выполняться, пока флаг равен False.

Шаг 6: Разрешение репликации с целевой системы хранения

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

# Имя группы защиты В ТОМ ВИДЕ, КАК ОНО ВИДНО С ЦЕЛЕВОЙ СИСТЕМЫ: pod:pgroup, одно двоеточие
$RemotePGroupName = $PodName + ':' + ($PGroupName -split '::')[-1]
"Protection group as seen on the target: $RemotePGroupName"

# Allowed ДОЛЖНО быть установлено С ЦЕЛЕВОЙ системы хранения
Update-Pfa2ProtectionGroupTarget -Array $TargetFlashArray `
    -GroupName $RemotePGroupName `
    -MemberName $TargetArrayShortName `
    -Allowed $true

Вывод:

Protection group as seen on the target: SQL-AC-FTDemo:ASYNC

Context : @{Id='f269a914-00c5-408f-b6ba-a3c4048cdbfd'; Name='flasharray3'; ResourceType='remote-arrays'}
Allowed : True
Group   : @{Id='0cb14734-4710-7089-1916-954bdfcc2e73'; Name='SQL-AC-FTDemo:ASYNC'}
Member  : @{Id='f269a914-00c5-408f-b6ba-a3c4048cdbfd'; Name='flasharray3'; ResourceType='array'}
Status  : replicating

Update-Pfa2ProtectionGroupTarget является явным управлением флагом Allowed, и он должен выполняться с целевой системы хранения. На практике вы будете использовать его в обратном направлении, передавая -Allowed $false, чтобы остановить репликацию с источника в эту систему. Запуск с $true на уже разрешённой цели просто подтверждает состояние.

Сравните тут Id группы 0cb14734 с a99154ee, который мы видели на источнике на Шаге 5. Это два разных объекта. На источнике есть SQL-AC-FTDemo::ASYNC, а на цели — свой собственный SQL-AC-FTDemo:ASYNC, названный по имени пода. Собирайте эту строку из $PodName, и никогда из имени вашей системы хранения.

Шаг 7: Установка расписаний снимков и репликации

После создания инфраструктуры мы можем настроить два расписания, которые мы описали в начале статьи. Здесь я потратил больше всего времени, поэтому позвольте мне сэкономить ваше. Вы не можете установить расписания и хранение в одном вызове. Purity отклоняет весь PATCH с ошибкой Invalid combination of parameters specified. (schedule, retention). Есть ещё одна ловушка: если установить частоту и её флаг включения вместе, частота также не устанавливается. Поэтому требуется три вызова, в этом порядке. Обратите внимание на единицы измерения: частоты расписаний указываются в миллисекундах, а значения хранения — в секундах.

$FiveMinutesMs = 5 * 60 * 1000        # 300000 мс, то есть 5 минут
$ThreeDaysSec  = 3 * 24 * 60 * 60     # 259200 секунд, хранение на источнике (3 дня)
$TwoWeeksSec   = 14 * 24 * 60 * 60    # 1209600 секунд, хранение на цели (14 дней)

# 1. Частоты
Update-Pfa2ProtectionGroup -Array $SourceFlashArray -Name $PGroupName `
    -SnapshotScheduleFrequency $FiveMinutesMs `
    -ReplicationScheduleFrequency $FiveMinutesMs

# 2. Включить оба расписания
Update-Pfa2ProtectionGroup -Array $SourceFlashArray -Name $PGroupName `
    -SnapshotScheduleEnabled $true `
    -ReplicationScheduleEnabled $true

# 3. Хранение
Update-Pfa2ProtectionGroup -Array $SourceFlashArray -Name $PGroupName `
    -SourceRetentionAllForSec $ThreeDaysSec `
    -SourceRetentionDays 0 `
    -TargetRetentionAllForSec $TwoWeeksSec `
    -TargetRetentionDays 0

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

Get-Pfa2ProtectionGroup -Array $SourceFlashArray -Name $PGroupName |
    Select-Object Name, SnapshotSchedule, ReplicationSchedule, SourceRetention, TargetRetention |
    Format-List

Вывод:

Name                : SQL-AC-FTDemo::ASYNC
SnapshotSchedule    : @{Enabled=True; Frequency=300000}
ReplicationSchedule : @{Enabled=True; Frequency=300000}
SourceRetention     : @{AllForSec=259200; Days=0; PerDay=4; PerPeriod=4; PeriodLengthMs=86400000}
TargetRetention     : @{AllForSec=1209600; Days=0; PerDay=4; PerPeriod=4; PeriodLengthMs=86400000}

Это расписание снимков для локальных и удалённых расписаний, выраженное в числах. Оба расписания включены с частотой 300000 мс, что составляет 5 минут. SourceRetention.AllForSec = 259200 — это 3 дня, TargetRetention.AllForSec = 1209600 — это 2 недели. Установка Days=0 для обоих означает, что каждый снимок хранится в течение всего периода хранения, а затем удаляется, без «прореживания» (thinning). Если вы хотите классическое многоуровневое хранение, когда после начального окна снимки «прореживаются» до нескольких в день, установите Days и PerDay вместо этого.

Шаг 8: Создание снимка по запросу и его репликация немедленно

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

$SnapshotSuffix = 'BOOYAA'

$Snapshot = New-Pfa2ProtectionGroupSnapshot -Array $SourceFlashArray `
    -SourceName $PGroupName `
    -Suffix $SnapshotSuffix `
    -ReplicateNow $true `
    -ApplyRetention $true

$Snapshot | Format-List Name, Created, Suffix, Pod, Source

Вывод:

Name    : SQL-AC-FTDemo::ASYNC.BOOYAA
Created : 8/18/2026 9:32:55 PM
Suffix  : BOOYAA
Pod     : @{Id='4840a8a0-acea-b473-1c75-844f2199424b'; Name='SQL-AC-FTDemo'}
Source  : @{Id='a99154ee-3c4c-1f82-c9d6-9b65350456ec'; Name='SQL-AC-FTDemo::ASYNC'}

Параметр -ReplicateNow $true отправляет этот снимок на все разрешённые цели немедленно, вместо ожидания следующего запланированного интервала. -ApplyRetention $true гарантирует, что к нему будут применяться локальные и удалённые политики хранения, поэтому он будет удалён вместе со всеми остальными, а не будет жить вечно.

Шаг 9: Проверка, что снимок достиг цели

Здесь именование окупается. На целевой системе хранения мы ищем SQL-AC-FTDemo:ASYNC.BOOYAA.

$TargetSnapshotName = $RemotePGroupName + '.' + $SnapshotSuffix

Get-Pfa2ProtectionGroupSnapshot -Array $TargetFlashArray -Name $TargetSnapshotName |
    Select-Object Name, Created, @{ n='SnapshotsGB'; e={ [math]::Round($_.Space.Snapshots / 1GB, 2) } }

Вывод:

Name                       Created              SnapshotsGB
----                       -------              -----------
SQL-AC-FTDemo:ASYNC.BOOYAA 8/18/2026 9:32:55 PM        0.00

Снимок там с той же временной меткой создания, а SnapshotsGB показывает 0.00. Это не сбой; это работа дедупликации. На этой системе хранения уже были получены более ранние снимки этого же тома, поэтому почти каждый блок в этом снимке был дедуплицирован относительно уже существовавших данных. Первая репликация этого набора данных передала полные 140 ГБ по сети. Первая репликация оплачивает полную стоимость, а каждая последующая — почти бесплатна.

Если вы хотите наблюдать за передачей, а не просто подтверждать результат, Get-Pfa2ProtectionGroupSnapshotTransfer, запущенный на целевой системе хранения, покажет прогресс и завершение. Progress = 1 с заполненным полем Completed означает, что всё готово:

Get-Pfa2ProtectionGroupSnapshotTransfer -Array $TargetFlashArray `
    -Name $RemotePGroupName `
    -Filter "completed and name='$TargetSnapshotName'" |
    Format-List Name, Started, Completed, Progress, DataTransferred, PhysicalBytesWritten

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

Почему это важно для SQL Server

Если вы запускаете SQL Server на ActiveCluster, это закрывает реальный пробел в архитектуре:

• Одна копия данных, три местоположения: Ваши тома SQL Server остаются в поде с нулевой RPO между метро-сайтами, и те же самые тома питают асинхронную копию на вашем сайте аварийного восстановления. Никаких дублирующих макетов томов, никаких теневых групп защиты.
• Восстановление из снимка, а не восстановление из резервной копии: Поскольку эта третья копия является снимком группы защиты между системами хранения, вы можете скопировать его в новый том на третьей системе хранения и подключить его. Это практически мгновенное восстановление базы данных объёмом несколько терабайт вместо многочасового восстановления. Этот новый том является обычным томом, а не участником пода, поскольку под не может быть целью асинхронной репликации.
• Выживает при отказе системы хранения на метро-сайте: Благодаря подключению, настроенному от обоих участников модуля, потеря одной системы ActiveCluster не останавливает вашу аварийную репликацию.
• SafeMode там, где это важно: Третья система хранения может иметь собственную блокировку хранения SafeMode, что даёт вам неизменяемую копию за пределами зоны поражения метро-кластера.
• Чистая автоматизация: Каждый шаг выше — это один командлет SDK2, поэтому это легко вписывается в любую автоматизацию подготовки или резервного копирования, которую вы уже используете.

Заключение

Возможность реплицировать группу защиты изнутри модуля ActiveCluster на третью систему хранения устраняет последний неудобный обходной путь в трёхсайтовой архитектуре на FlashArray для SQL Server. Создайте группу защиты в поде, добавьте тома, добавьте цель, разрешите это с целевой стороны и установите расписания.

Две вещи, которые следует помнить при написании скриптов. Источником является под, а не система хранения, поэтому группа защиты на вашей целевой системе хранения называется pod:pgroup. И Update-Pfa2ProtectionGroup требует трёх отдельных вызовов для настройки расписания, потому что поля расписания и хранения не могут быть в одном PATCH.

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