Perguntas frequentes sobre réplicas de armazenamento

Sim. Você pode usar os seguintes cenários com o Azure:

• Replicação de servidor para servidor dentro do Azure (de forma síncrona ou assíncrona entre máquinas virtuais (VMs) de infraestrutura como serviço (IaaS) em um ou dois domínios de falha de datacenter ou de forma assíncrona entre duas regiões separadas).
• Replicação assíncrona de servidor para servidor entre o Azure e o local (usando uma rede virtual privada (VPN) ou a Rota Expressa do Azure).
• Replicação de cluster para cluster dentro do Azure (de forma síncrona ou assíncrona entre VMs IaaS em um ou dois domínios de falha de datacenter ou de forma assíncrona entre duas regiões separadas).
• Replicação assíncrona de cluster para cluster entre o Azure e o local (usando VPN ou Azure ExpressRoute).
• Amplie o clustering usando os Discos Compartilhados do Azure (de forma síncrona ou assíncrona entre VMs IaaS em um ou dois domínios de falha de datacenter ou de forma assíncrona entre duas regiões separadas).

Para obter mais informações sobre clustering de convidado no Azure, consulte Implantar clusters de convidado de VM IaaS no Azure.

Notas importantes:

• Para modelos do Azure Resource Manager para clustering de Réplica de Armazenamento baseado em Espaços de Armazenamento Direto, consulte Criar um cluster SOFS Direto de Espaços de Armazenamento com Réplica de Armazenamento para recuperação de desastres em regiões do Azure.
• A comunicação RPC de cluster para cluster no Azure (exigida pelas APIs de cluster para conceder acesso entre clusters) requer a configuração do acesso à rede para o Operador de Rede de Cluster (CNO). Tem de permitir a porta TCP 135 e o intervalo dinâmico superior à porta TCP 49152. Para obter mais informações, consulte Criar um cluster de failover do Windows Server em uma VM IaaS do Azure - Parte 2 Rede e criação.
• É possível usar clusters convidados de dois nós, em que cada nó usa iSCSI de loopback para um cluster assimétrico replicado pela Réplica de Armazenamento. Mas essa configuração pode ter um desempenho insatisfatório e deve ser usada apenas para cargas de trabalho limitadas ou testes.

As mensagens de ID do Evento 1237 no log de eventos do administrador da réplica de armazenamento no servidor de destino mostram o número de bytes copiados e os bytes restantes a cada 10 segundos.

Outra opção é usar o contador de desempenho da Réplica de Armazenamento no servidor de destino em \Estatísticas da Réplica de Armazenamento\Total de Bytes Recebidos para um ou mais volumes replicados.

Você também pode consultar o grupo de replicação usando o Windows PowerShell. Por exemplo, o comando de exemplo a seguir obtém o nome dos grupos no destino e, em seguida, consulta um grupo chamado Replicação 2 a cada 10 segundos para mostrar o progresso:

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

Sim. Para especificar as interfaces de rede a serem usadas para replicação, use o cmdlet Set-SRNetworkConstraint. Este cmdlet opera na camada de interface. Você pode usá-lo em cenários de cluster e não cluster.

Por exemplo, com um servidor autônomo (em cada nó), execute estes comandos:

Get-SRPartnership

Get-NetIPConfiguration

Observe as informações do gateway e da interface (em ambos os servidores) e as direções da parceria. Em seguida, execute:

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

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

Para configurar restrições de rede em um cluster stretch, execute:

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"

Não, a Réplica de Armazenamento suporta apenas a replicação um-para-um de um servidor, cluster ou nó de cluster estendido. Você pode configurar a replicação entre vários servidores de um par de volumes específico em qualquer direção. Por exemplo, o Servidor 1 pode replicar seu volume D para o Servidor 2 e seu volume E do Servidor 3.

Você pode aumentar (ampliar) volumes, mas não encolhe-los. Por padrão, a Réplica de Armazenamento impede que os administradores estendam os volumes replicados. Antes de redimensionar, use a opção Set-SRGroup -AllowVolumeResize $TRUE no grupo de origem.

Por exemplo:

1. Execute este comando no computador de origem: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE.
2. Aumente o volume usando a técnica que preferir.
3. Execute este comando no computador de origem: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE.

Windows Server 2016: Não. A Réplica de Armazenamento desmonta o volume de destino quando a replicação começa no Windows Server 2016.

Windows Server 2019: Sim. Você pode montar o armazenamento de destino usando o recurso de de failover de teste. Para executar um failover de teste, você deve ter um volume formatado NTFS ou ReFS não utilizado que não esteja sendo replicado no destino. Em seguida, monte um snapshot do armazenamento replicado temporariamente para fins de teste ou backup.

Para criar um failover de teste para o Grupo de Replicação RG2 no servidor de destino SRV2, usando T: como uma unidade temporária que não está sendo replicada, execute o seguinte comando:

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

O volume replicado agora está acessível em SRV2. Você pode ler e gravar nele normalmente, copiar arquivos dele ou executar um backup on-line que você salva em outro lugar para segurança. O volume T: contém dados de log.

Para remover o instantâneo de failover de teste e descartar suas alterações, execute:

Dismount-SRDestination -Name RG2 -Computername SRV2

Você deve usar o recurso de failover de teste apenas para operações temporárias de curto prazo. Não se destina ao uso a longo prazo. Quando em uso, a replicação continua para o volume de destino real.

Embora seja tecnicamente possível, não recomendamos essa configuração devido à falta de reconhecimento do site nos nós de computação que entram em contato com a instância SOFS. Se você usar a rede à distância do campus, onde as latências geralmente são inferiores a um milissegundo, essa configuração normalmente funciona sem problemas.

Em uma replicação de cluster para cluster, a Réplica de Armazenamento oferece suporte total a SOFS, incluindo o uso de Espaços de Armazenamento Diretos, quando você replica entre dois clusters.

Não. Você pode replicar usando Volumes Compartilhados de Cluster ou uma reserva de disco persistente (PDR) de propriedade de um recurso de cluster, como uma função de Servidor de Arquivos.

Na replicação de cluster para cluster, a Réplica de Armazenamento oferece suporte total a SOFS, incluindo o uso de Espaços de Armazenamento Diretos, ao replicar entre dois clusters.

Não. Esta configuração não é suportada no Windows Server.

Na replicação de cluster para cluster, a Réplica de Armazenamento suporta totalmente SOFS e servidores Hyper-V, incluindo o uso de Espaços de Armazenamento Diretos.

Execute New-SRPartnership -ReplicationMode e forneça o argumento Asynchronous. Por padrão, toda a replicação na réplica de armazenamento é síncrona. Você também pode alterar o modo executando Set-SRPartnership -ReplicationMode.

Para evitar o failover automático, você pode usar o PowerShell para configurar Get-ClusterNode -Name "NodeName").NodeWeight=0. Este comando remove a votação em cada nó no site de recuperação de desastres. Em seguida, você pode executar Start-ClusterNode -PreventQuorum em nós no site primário e Start-ClusterNode -ForceQuorum em nós no local de desastre para forçar o failover. Impedir o failover automático não está disponível como uma opção de configuração da interface do usuário, e recomendamos que você não impeça o failover automático.

Para impedir que o novo recurso de resiliência de máquina virtual Hyper-V seja executado e, em vez disso, pause as VMs em vez de fazer o failover delas para o site de recuperação de desastres, execute (Get-Cluster).ResiliencyDefaultPeriod=0.

Você pode usar o armazenamento de provisionamento fino para acelerar os tempos de sincronização iniciais. A réplica de armazenamento consulta e usa automaticamente o armazenamento provisionado de forma fina, incluindo espaços de armazenamento não clusterizados, discos dinâmicos Hyper-V e LUNs (números de unidade lógica) da SAN (Storage Area Network, rede de armazenamento de dados). Após o início da replicação inicial, não é possível reduzir ou cortar o volume.

Você também pode usar volumes de dados propagados para reduzir o uso de largura de banda e, em alguns cenários, o tempo de sincronização. Use a opção Seeded no Gerenciador de Cluster de Failover ou use o cmdlet New-SRPartnership para garantir que o volume de destino tenha algum subconjunto de dados do site primário. Se o volume estiver praticamente vazio, o uso da sincronização semeada pode reduzir o tempo e o uso da largura de banda.

Para semear dados, você pode escolher entre opções que oferecem vários graus de eficácia:

• Replicação anterior. Replique por meio da sincronização inicial normal localmente entre nós que contêm os discos e volumes, remova a replicação, envie os discos de destino para outro lugar e, em seguida, adicione replicação usando a opção seeded. Esse método é o mais eficaz porque a réplica de armazenamento garante um espelho de cópia de bloco, e a única coisa a ser replicada são os blocos delta.
• Snapshot restaurado ou backup baseado em snapshot restaurado. Ao restaurar um instantâneo baseado em volume no volume de destino, deve haver diferenças mínimas no layout do bloco. Este método é o próximo mais eficaz. É provável que os blocos correspondam porque os instantâneos de volume são imagens espelhadas.
• Arquivos copiados. Crie um novo volume no destino que não foi usado e, em seguida, execute uma cópia completa da árvore de robocopy /MIR dos dados. É provável que haja partidas em bloco. Usar o Explorador de Arquivos do Windows ou copiar alguma parte da árvore não cria muitas correspondências de bloco. Copiar arquivos manualmente é o método menos eficaz de semeadura.

Sim. Use o cmdlet Grant-SRDelegation para delegar usuários. Você pode usar o comando para definir usuários específicos em cenários de replicação de servidor para servidor, de cluster para cluster e de replicação de cluster estendido. O comando delega as permissões para criar, modificar ou remover a replicação sem ser membro do grupo de administradores locais.

Por exemplo:

Grant-SRDelegation -UserName contoso\tonywang

O cmdlet lembra que o usuário precisa sair e, em seguida, entrar no servidor que planeja administrar para que a alteração entre em vigor. Você pode usar os cmdlets Get-SRDelegation e Revoke-SRDelegation para controlar ainda mais a delegação.

A réplica de armazenamento oferece suporte ao backup e à restauração do volume de origem. Ele também suporta a criação e restauração de instantâneos do volume de origem. Não é possível fazer backup ou restaurar o volume de destino enquanto ele estiver protegido pela Réplica de Armazenamento porque ele não está montado ou acessível.

Se ocorrer um desastre e o volume de origem for perdido, você poderá usar o cmdlet Set-SRPartnership para promover o destino como o novo volume de origem. Na fonte recém-promovida, você pode fazer backup ou restaurar esse volume. Você também pode remover a replicação usando os cmdlets Remove-SRPartnership e Remove-SRGroup para remontar o volume como lido/gravável.

Para criar instantâneos periódicos consistentes com o aplicativo, você pode usar o VSS (Serviço de Cópias de Sombra de Volume) executando VSSAdmin.exe no servidor de origem para criar instantâneos de volumes de dados replicados.

Por exemplo, quando você estiver replicando o volume F: com a Réplica de Armazenamento, execute este comando:

vssadmin create shadow /for=F:

Em seguida, depois de alternar a direção da replicação, remover a replicação ou simplesmente ainda estar no mesmo volume de origem, você poderá restaurar qualquer instantâneo para seu point-in-time.

Por exemplo, ainda usando F:, execute:

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

Você também pode agendar essa ferramenta para ser executada periodicamente usando uma tarefa agendada. Para obter mais informações sobre como usar o VSS, consulte vssadmin. O VSS ignora o volume de log, portanto, você não precisa fazer backup do volume de log.

A réplica de armazenamento suporta backups baseados em arquivos. A Réplica de Armazenamento não oferece suporte a backup e restauração baseados em blocos.

A Réplica de Armazenamento depende do SMB (Server Message Block) e do WSMan (Web Services Management) para sua replicação e gerenciamento, portanto, as seguintes portas são necessárias:

• 445 (SMB; protocolo de transporte de replicação, protocolo de gerenciamento RPC de cluster)
• 5445 (iWARP SMB; necessário apenas ao usar a rede RDMA (acesso remoto direto à memória) iWARP)
• 5985 (WSManHTTP; protocolo de gerenciamento para WMI (Instrumentação de Gerenciamento do Windows)/CIM (Common Information Model)/PowerShell)

O tamanho ideal do log varia muito de acordo com o ambiente e a carga de trabalho, e com a quantidade de E/S de gravação executada pela carga de trabalho.

• Um log maior ou menor não torna a replicação mais rápida ou lenta.
• Um log maior ou menor não tem qualquer influência sobre um volume de dados de 10 GB versus um volume de dados de 10 TB (por exemplo).

Um log maior simplesmente coleta e retém mais E/S de gravação antes de serem empacotadas. Um log maior permite que uma interrupção no serviço entre o computador de origem e o computador de destino, como uma interrupção de rede ou o destino esteja offline, continue por mais tempo. Por exemplo, seu log é configurado para armazenar até 10 horas de gravações e a rede fica inativa por 2 horas. Quando a rede retorna, a origem pode reproduzir apenas o delta das alterações não sincronizadas de volta ao destino. Se o log durar 10 horas e a interrupção for de dois dias, a fonte agora terá que reproduzir de um log diferente chamado bitmap, e o ts normalmente é mais lento para voltar à sincronização. Quando está sincronizado, ele volta a usar o log.

A Réplica de Armazenamento depende do log para todo o desempenho de gravação. O desempenho do log é essencial para o desempenho da replicação. Você deve garantir que o volume de log tenha um desempenho melhor do que o volume de dados porque o log serializa e sequencia todas as E/S de gravação. Você deve sempre usar mídia flash como uma unidade de estado sólido (SSD) em volumes de log. Você nunca deve permitir que outras cargas de trabalho sejam executadas no volume de log, da mesma forma que nunca permitiria que outras cargas de trabalho fossem executadas em volumes de log do banco de dados SQL.

Você pode obter recomendações de dimensionamento de log executando o cmdlet Test-SRTopology. Como alternativa, você pode usar contadores de desempenho em servidores existentes para fazer um julgamento de tamanho de log. A fórmula é simples: monitorar a taxa de transferência do disco de dados (Avg Write Bytes/Sec) sob a carga de trabalho e usá-la para calcular a quantidade de tempo que leva para preencher o log de diferentes tamanhos. Por exemplo, a taxa de transferência do disco de dados de 50 MB/s faz com que o log de 120 GB seja encapsulado em 120 GB dividido por 50 MB por segundo, o que equivale a 2.400 segundos ou 40 minutos. Portanto, a quantidade de tempo que o servidor de destino pode ficar inacessível antes que o log seja encapsulado é de 40 minutos. Se o log for quebrado, mas o destino se tornar acessível novamente, a origem reproduzirá blocos por meio do log de bitmap em vez do log principal. O tamanho do log não afeta o desempenho.

Somente disco de dados do cluster de origem deve ser feito backup. Os discos de log da Réplica de Armazenamento não devem ser copiados porque um backup pode entrar em conflito com as operações da Réplica de Armazenamento.

A réplica de armazenamento vem em três configurações principais: stretch cluster, cluster-to-cluster e server-to-server. Cada topologia tem vantagens diferentes.

A topologia de cluster estendido é ideal se sua carga de trabalho exigir failover automático com orquestração, como em um cluster de nuvem privada Hyper-V ou para FCI do SQL Server. Ele também tem uma interface gráfica integrada, Failover Cluster Manager, para facilidade de uso. Ele usa a arquitetura clássica de armazenamento compartilhado de cluster assimétrico de Espaços de Armazenamento, SAN, iSCSI e RAID por meio de reserva persistente. Você pode executar essa topologia com apenas dois nós.

A topologia de cluster para cluster usa dois clusters separados. Essa topologia é ideal se você quiser failover manual ou quando o segundo site for provisionado para recuperação de desastres e não para uso diário. A orquestração é manual. Ao contrário de uma topologia de cluster stretch, você pode usar o Storage Spaces Direct nessa configuração (para obter advertências, consulte as Perguntas frequentes sobre réplica de armazenamento e a documentação de cluster para cluster). Você pode executar essa topologia com apenas quatro nós.

A topologia de servidor para servidor é ideal se você estiver executando hardware que não pode ser clusterizado. Requer failover manual e orquestração. É ideal para implantações baratas entre filiais e datacenters centrais, especialmente quando você usa replicação assíncrona. Essa configuração geralmente pode substituir instâncias de servidores de arquivos protegidos pela Replicação DFS (Replicação Distribuída) que você usa para cenários de recuperação de desastres de mestre único.

Em todos os casos, as topologias suportam a execução em hardware físico e em máquinas virtuais. Em uma máquina virtual, o hipervisor subjacente não requer o Hyper-V. Você pode usar, por exemplo, VMware, KVM ou Xen.

A Réplica de Armazenamento também tem um modo de servidor para si mesmo, no qual você aponta a replicação para dois volumes diferentes no mesmo computador.

Sim. Habilite a Desduplicação de Dados em um volume no servidor de origem e, durante a replicação, o servidor de destino recebe uma cópia desduplicada do volume.

Embora você deva instalar Eliminação de Duplicação de Dados nos servidores de origem e de destino (consulte Instalar e habilitar a Eliminação de Duplicação de Dados), é importante não habilitar Eliminação de Duplicação de Dados no servidor de destino. A Réplica de Armazenamento permite gravações somente no servidor de origem. Como a Eliminação de Duplicação de Dados faz gravações no volume, ela deve ser executada somente no servidor de origem.

Infelizmente, não oferecemos suporte à criação de uma nova parceria de entre o Windows Server 2019 e o Windows Server 2016. Você pode atualizar com segurança um servidor ou cluster que executa o Windows Server 2016 para o Windows Server 2019 e qualquer parcerias de existentes continuará a funcionar.

Para obter o melhor desempenho de replicação do Windows Server 2019, todos os membros da parceria devem executar o Windows Server 2019. Você também deve excluir parcerias existentes e grupos de replicação associados e, em seguida, recriá-los com dados propagados (ao criar a parceria no Windows Admin Center ou usando o cmdlet New-SRPartnership).

Para obter assistência técnica com a Réplica de Armazenamento, você pode postar em Microsoft Q & A ou entrar em contato com Microsoft Business Support.

Para problemas com esta documentação, consulte a seção Comentários na parte inferior desta página e selecione Esta página.

A réplica de armazenamento é uma tecnologia de replicação unidirecional. Ele replica apenas da origem para o destino por volume. A direção pode ser invertida a qualquer momento, mas ainda se replica em apenas uma direção.

Você pode ter um conjunto de volumes (origem e destino) replicados em uma direção e um conjunto diferente de unidades (origem e destino) replicados na direção oposta.

Por exemplo, você deseja ter a replicação de servidor para servidor configurada. Server1 e Server2 têm letras de unidade L:, M:, N:e O:. Você deseja replicar M: de unidade de Server1 para Server2e replicar O: de unidade de Server2 para Server1. Contanto que haja unidades de log separadas para cada um dos grupos, você pode usar esta configuração:

• Server1 unidade de origem M: com logs de origem L: replicando para Server2drive M: de destino com a unidade de logs de destino L:.
• Server2 unidade de origem O: com a unidade de log de origem N: replicando para Server1drive O: de destino com a unidade de log de destino N:.

A Réplica de Armazenamento impede que qualquer disco de cluster entre no modo de manutenção. Para algumas tarefas, como habilitar ou desabilitar o BitLocker, os discos devem estar no modo de manutenção. Para tarefas que exigem que os discos estejam no modo de manutenção, a parceria deve primeiro ser quebrada e, em seguida, criada novamente quando a tarefa for concluída.

A Réplica de Armazenamento bloqueia uma nova parceria se as versões do log de replicação não corresponderem ou se um recurso não for suportado por ambos os servidores. A compactação da Réplica de Armazenamento é um exemplo de um recurso que não corresponde entre as versões do sistema operacional porque foi adicionado pela primeira vez no Windows Server 2022. A tentativa de configurar uma parceria com um servidor que não suporta um recurso retorna o erro "A operação solicitada não é suportada".

A tabela a seguir mostra a matriz de interoperabilidade da versão de log atual:

Replicação de/para	Windows Server 2016	Windows Server 2019	Windows Server 2022
Windows Server 2016
Windows Server 2019
Windows Server 2022

• Visão geral da réplica de armazenamento
• Ampliar a replicação de cluster usando de armazenamento compartilhado
• de replicação de armazenamento de servidor para servidor
• de replicação de armazenamento de cluster para cluster
• Réplica de armazenamento : problemas conhecidos
• Visão geral do armazenamento
• Espaços de Armazenamento Diretos