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

Да. В Azure можно использовать следующие сценарии:

• Репликация между серверами в Azure (синхронно или асинхронно между виртуальными машинами IaaS в одном или двух доменах сбоя центра обработки данных или асинхронно между двумя отдельными регионами)
• Асинхронная репликация между Azure и локальной репликацией (с помощью VPN или Azure ExpressRoute)
• Репликация между кластерами в Azure (синхронно или асинхронно между виртуальными машинами IaaS в одном или двух доменах сбоя центра обработки данных или асинхронно между двумя отдельными регионами)
• Асинхронная репликация кластеров между Azure и локальной средой (с помощью VPN или Azure ExpressRoute)
• Растяжение кластеризации с помощью общих дисков Azure (синхронно или асинхронно между виртуальными машинами IaaS в одном или двух доменах сбоя центра обработки данных или асинхронно между двумя отдельными регионами)

Дополнительные заметки о кластеризации гостевых машин в Azure см . в разделе "Развертывание гостевых кластеров виртуальных машин IaaS" в Microsoft Azure.

Важные примечания.

• Существуют шаблоны Azure Resource Manager для кластеризации реплики реплики хранилища на основе локальных дисковых пространств при создании локальных кластеров SOFS с репликой хранилища для аварийного восстановления в регионах Azure.
• Для кластеризации связи RPC в Azure (требуется API кластера для предоставления доступа между кластером) требуется настройка сетевого доступа для CNO. Необходимо разрешить TCP-порт 135 и динамический диапазон выше TCP-порта 49152. Эталонное создание отказоустойчивого кластера Windows Server на виртуальной машине Azure IAAS — часть 2 сеть и создание.
• Можно использовать гостевые кластеры с двумя узлами, где каждый узел использует циклический iSCSI для асимметричного кластера, реплицированного репликой хранилища. Но это, скорее всего, будет иметь очень низкую производительность и должно использоваться только для очень ограниченных рабочих нагрузок или тестирования.

Сообщения о событии 1237, которые отображаются в журнале административных событий реплики хранилища на конечном сервере каждые 10 секунд, информируют о количестве скопированных и оставшихся байт. Также можно использовать счетчик производительности реплики хранилища на узле назначения, который отображает общее количество полученных байтов для одного или нескольких реплицируемых томов (\Storage Replica Statistics\Total Bytes Received). Еще можно с помощью Windows PowerShell отправить запрос к группе репликации. Так, команда из этого примера возвращает имена групп на целевом компьютере, а затем каждые 10 секунд запрашивает одну группу с именем Replication 2 и отображает ход выполнения задания:

Get-SRGroup

do{
    $r=(Get-SRGroup -Name "Replication 2").replicas
    [System.Console]::Write("Number of remaining bytes {0}`n", $r.NumOfBytesRemaining)
    Start-Sleep 10
}until($r.ReplicationStatus -eq 'ContinuouslyReplicating')
Write-Output "Replica Status: "$r.replicationstatus

Да, с помощью Set-SRNetworkConstraint. Этот командлет работает на уровне интерфейсов, как для кластерных развертываний, так и без использования кластеров. Пример команды для изолированного сервера (выполнить на каждом узле):

Get-SRPartnership

Get-NetIPConfiguration

Запишите сведения о шлюзе и интерфейсе (на обоих серверах), а также информацию о направлениях партнерства. Затем запустите:

Set-SRNetworkConstraint -SourceComputerName sr-srv06 -SourceRGName rg02 -
SourceNWInterface 2 -DestinationComputerName sr-srv05 -DestinationNWInterface 3 -DestinationRGName rg01

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

Чтобы настроить сетевые ограничения для растянутого кластера, выполните:

Set-SRNetworkConstraint -SourceComputerName sr-cluster01 -SourceRGName group1 -SourceNWInterface "Cluster Network 1","Cluster Network 2" -DestinationComputerName sr-cluster02 -DestinationRGName group2 -DestinationNWInterface "Cluster Network 1","Cluster Network 2"

Нет, реплика хранилища поддерживает только одну репликацию сервера, кластера или растянутого узла кластера. Возможно, ситуация изменится в более поздней версии. Конечно, вы можете настроить репликацию в любом направлении между разными серверами определенной пары томов. Например, сервер 1 может реплицировать свой том D на сервер 2, а свой том E — с сервера 3.

Вы можете увеличивать (расширять) тома, но не сжимать их. По умолчанию реплика хранилища запрещает администраторам расширять реплицированные тома; Set-SRGroup -AllowVolumeResize $TRUE используйте параметр исходной группы перед изменением размера. Например:

1. Используйте для исходного компьютера: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE
2. Увеличение объема с помощью любого метода, который вы предпочитаете
3. Используйте для исходного компьютера: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE

Не в Windows Server 2016. Реплика хранилища отключает целевой том при запуске репликации.

Однако в Windows Server 2019 и Windows Server Semi-Annual Channel, начиная с версии 1709, теперь можно подключить целевое хранилище. Эта функция называется "Тестовая отработка отказа". Для этого необходимо иметь неиспользуемый том, форматированный том NTFS или ReFS, который в настоящее время не реплицируется в назначении. Затем можно временно подключить моментальный снимок реплицированного хранилища для тестирования или резервного копирования.

Например, чтобы создать тестовую отработку отказа, в которой выполняется репликация тома "D:", в группе репликации "RG2" на целевом сервере "SRV2" и на SRV2 есть диск "T:", который не реплицируется:

Mount-SRDestination -Name RG2 -Computername SRV2 -TemporaryPath T:\

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

Чтобы удалить моментальный снимок тестовой отработки отказа и отменить изменения:

Dismount-SRDestination -Name RG2 -Computername SRV2

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

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

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

Нет. Вы можете реплицировать резервирование csv-файлов или сохраняемого диска (PDR), принадлежащие ресурсу кластера, например роли файлового сервера.

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

Эта конфигурация не поддерживается в Windows Server. Возможно, ситуация изменится в более поздней версии. Для сценариев межкластерной репликации реплика хранилища полностью поддерживает масштабируемые файловые серверы и серверы Hyper-V, в том числе использование локальных дисковых пространств.

Выполните New-SRPartnership -ReplicationMode с аргументом Asynchronous. По умолчанию все репликации в реплике хранилища являются синхронными. Этот режим также можно изменить командлетом Set-SRPartnership -ReplicationMode.

Чтобы избежать автоматической отработки отказа, выполните командлет Get-ClusterNode -Name "NodeName").NodeWeight=0. Эта операция удаляет голоса с каждого узла на сайте аварийного восстановления. Теперь для принудительной отработки отказа нужно выполнить Start-ClusterNode -PreventQuorum на узлах первичного сайта, а затем Start-ClusterNode -ForceQuorum на узлах сайта аварийного восстановления. Невозможно отключить автоматическую отработку отказа с помощью графических средств. Мы рекомендуем никогда не отключать автоматическую отработку отказа.

Чтобы предотвратить запуск новой функции устойчивости виртуальных машин Hyper-V и, следовательно, приостановку работы виртуальных машин вместо отработки отказа на сайт аварийного восстановления выполните запуск. (Get-Cluster).ResiliencyDefaultPeriod=0

Для ускорения процесса начальной синхронизации можно использовать хранилище с тонкой подготовкой. Реплика хранилища запрашивает и автоматически использует хранилища с тонкой подготовкой, в том числе некластеризованные дисковые пространства, динамические диски Hyper-V и SAN LUN. После запуска начальной репликации том не сможет уменьшить или обрезать.

Вы также можете использовать затраченные тома данных для уменьшения использования пропускной способности и иногда времени, гарантируя, что целевой том содержит некоторые подмножества данных из основного, а затем с помощью параметра "Засеять" в диспетчере отказоустойчивости кластеров или New-SRPartnership. Если том практически пуст, использование синхронизации с заполнением может уменьшить затрачиваемое время и использование пропускной способности. Существует несколько способов заполнения данных с различной степенью эффективности:

• Предыдущая репликация — путем репликации с обычной начальной синхронизацией локально между узлами, содержащими диски и тома, удаляя репликацию, отправляя конечные диски в другое место, а затем добавляя репликацию с заполненным параметром. Это наиболее эффективный метод, так как реплика хранилища гарантирует зеркальное отображение блокировки, и единственное, что необходимо реплицировать, — разностные блоки.
• Восстановленная резервная копия на основе моментального снимка или восстановленная резервная копия на основе моментального снимка на основе тома, необходимо иметь минимальные различия в макете блока. Это следующий наиболее эффективный метод, так как блоки, скорее всего, совпадают благодаря моментальным снимкам томов зеркальных изображений.
• Скопированные файлы — путем создания нового тома в назначении, который никогда не использовался раньше и выполняя полную копию данных robocopy /MIR, скорее всего, будут блочные совпадения. При использовании проводника Windows или копирования некоторых частей дерева не будет создаваться много совпадений блоков. Копирование файлов вручную является наименее эффективным способом заполнения.

Командлет можно использовать Grant-SRDelegation . Он позволяет назначить сценарии межсерверной и межкластерной репликации, а также репликации растянутого кластера конкретным пользователям, которые получат разрешения на создание, изменение или удаление репликации, не являясь при этом членами группы локальных администраторов. Например:

Grant-SRDelegation -UserName contso\tonywang

Командлет напомнит, что для вступления этих изменений в силу пользователи должны выйти из системы на сервере, который они будут администрировать, и снова войти в нее. Управлять такими полномочиями можно с помощью Get-SRDelegation и Revoke-SRDelegation.

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

Чтобы создавать для реплицируемых томов данных периодические моментальные снимки, согласованные на уровне приложений, можно запустить VSSADMIN.EXE на исходном сервере. Например, если вы используете реплику хранилища для репликации тома F:, выполите:

vssadmin create shadow /for=F:

Затем вы сможете восстановить такой моментальный снимок до состояния на момент времени на том же исходном томе или на томе назначения (для этого переключите направление репликации или удалите репликацию). Пример команд для того же тома F:

vssadmin list shadows
vssadmin revert shadow /shadow={shadown copy ID GUID listed previously}

Можно также настроить периодический запуск этого средства с помощью запланированной задачи. Дополнительные сведения об использовании VSS см. здесь: Vssadmin. Нет никакой необходимости или пользы в резервном копировании томов журналов. VSS будет игнорировать такие попытки.

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

Реплика хранилища использует SMB и WSMAN для репликации и управления. Это означает, что требуются следующие порты:

• 445 (SMB — протокол транспорта репликации, протокол управления RPC кластера)
• 5445 (iWARP SMB — требуется только при использовании сети iWARP RDMA)
• 5985 (протокол управления WSManHTTP для WMI/CIM/PowerShell)

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

• Более крупный или меньший журнал не делает вас быстрее или медленнее
• Более крупный или меньший журнал не имеет никакого отношения к тому данных 10 ГБ и объему данных 10TB, например

Более крупный журнал просто собирает и сохраняет больше операций записи, прежде чем они будут упакованы. Это позволяет прерывать работу между исходным и конечным компьютером, например сбоем сети или назначением в автономном режиме. Если журнал может хранить 10 часов записи, и сеть выходит из строя в течение 2 часов, когда сеть возвращает источник, может просто воспроизвести разность несинхронных изменений обратно в назначение очень быстро, и вы снова защищены очень быстро. Если журнал содержит 10 часов и сбой составляет 2 дня, источник теперь должен воспроизводиться из другого журнала, называемого растровым изображением, и, скорее всего, будет медленнее, чтобы вернуться в синхронизацию. После синхронизации он возвращается к использованию журнала.

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

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

Рекомендации по размеру журнала можно получить, выполнив средство Test-SRTopology. Кроме того, можно использовать счетчики производительности на существующих серверах для принятия решения по размеру журнала. Формула проста: отслеживайте пропускную способность диска данных (Avg Write Bytes/Sec) в рабочей нагрузке и используйте ее для вычисления времени, необходимого для заполнения журнала различных размеров. Например, пропускная способность диска данных 50 МБ/с приведет к тому, что журнал 120 ГБ будет упаковывать в 120 ГБ/50 МБ или 2400 секунд или 40 минут. Таким образом, время, когда целевой сервер может быть недоступен до упаковки журнала составляет 40 минут. Если оболочка журнала, но назначение становится доступным снова, источник будет повторять блоки с помощью журнала битовой карты вместо основного журнала. Размер журнала не влияет на производительность.

Резервное копирование должно выполняться только на диске данных из исходного кластера. Диски журнала реплики хранилища не должны создавать резервные копии, так как резервное копирование может конфликтовать с операциями реплики хранилища.

Реплика хранилища поставляется в трех основных конфигурациях: растянутый кластер, кластер — кластер и сервер— сервер. Существуют различные преимущества для каждого.

Топология растянутого кластера идеально подходит для рабочих нагрузок, требующих автоматической отработки отказа с помощью оркестрации, таких как кластеры частного облака Hyper-V и FCI SQL Server. Он также имеет встроенный графический интерфейс с помощью диспетчера отказоустойчивых кластеров. Она использует классическую асимметричную архитектуру общего хранилища дисковых пространств, SAN, iSCSI и RAID с помощью постоянного резервирования. Это можно запустить с несколькими 2 узлами.

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

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

Во всех случаях топологии поддерживают как на физическом оборудовании, так и на виртуальных машинах. При использовании виртуальных машин базовый гипервизор не требует Hyper-V; это может быть VMware, KVM, Xen и т. д.

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

Да, дедуплация данных поддерживается с репликой хранилища. Включите дедупликацию данных на томе на исходном сервере и во время репликации целевого сервера получает дедупликированную копию тома.

Хотя необходимо установить дедупликацию данных на исходных и конечных серверах (см. раздел "Установка и включение дедупликации данных"), важно не включить дедупликацию данных на целевом сервере. Реплика хранилища позволяет записывать только на исходном сервере. Так как дедупликация данных выполняет запись в том, она должна выполняться только на исходном сервере.

К сожалению, мы не поддерживаем создание нового партнерства между Windows Server 2019 и Windows Server 2016. Вы можете безопасно обновить сервер или кластер под управлением Windows Server 2016 до Windows Server 2019, и все существующие партнерские отношения будут продолжать работать.

Однако для повышения производительности репликации Windows Server 2019 все члены партнерства должны запускать Windows Server 2019, и необходимо удалить существующие партнерские отношения и связанные группы репликации, а затем повторно создать их с заполненными данными (при создании партнерства в Windows Admin Center или с командлетом New-SRPartnership).

Для технической помощи с репликой хранилища можно разместить на форумах Майкрософт. Вы также можете отправлять сообщения электронной почты srfeed@microsoft.com по реплике хранилища. Сведения о проблемах с этой документацией см. в разделе "Отзывы" в нижней части этой страницы и выберите эту страницу.

Реплика хранилища — это односторонняя технология репликации. Он будет реплицироваться только из источника в место назначения на каждый том. Это направление может быть отменено в любое время, но по-прежнему находится только в одном направлении. Однако это не означает, что невозможно выполнить репликацию томов (источника и назначения) в одном направлении, а другой набор дисков (источник и назначение) реплицироваться в противоположном направлении. Например, необходимо настроить репликацию сервера на сервер. Сервер1 и Сервер2 имеют буквы диска L:, M:, N:и O: и вы хотите реплицировать диск M: с сервера1 на сервер2, но диск O: репликация с Server2 на Server1. Это можно сделать до тех пор, пока для каждой группы есть отдельные диски журнала. НАПРИМЕР.

• Исходный диск Server1 M: с исходным диском журнала L: репликация на целевой диск Server2 M: с целевым диском журнала L:
• Исходный диск Server2: с диском журнала источника N: репликация на целевой диск Server1: с диском журнала назначения N:

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

• Обзор реплики хранилища
• Репликация растянутого кластера с помощью общего хранилища
• Репликация хранилища сервера на сервер
• Репликация кластера в хранилище кластеров
• Реплика хранилища: известные проблемы

• Общие сведения о хранилище
• Локальные дисковые пространства