Perguntas frequentes sobre Réplica de Armazenamento

Sim. É possível 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 VMs de 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 VPN ou o Azure ExpressRoute)
• Replicação de cluster para cluster dentro do Azure (de forma síncrona ou assíncrona entre VMs de 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)
• Cluster estendido usando discos compartilhados do Azure (de forma síncrona ou assíncrona entre VMs de IaaS em um ou dois domínios de falha de datacenter ou de forma assíncrona entre duas regiões separadas)

Outras observações sobre o clustering de convidados no Azure podem ser encontradas em: Implantando clusters convidados de VM de IaaS no Microsoft Azure.

Observações importantes:

• Há modelos do Resource Manager do Azure para clustering de Réplica de Armazenamento baseado em Espaços de Armazenamento Diretos em Criar um Cluster SOFS de Espaços de Armazenamento Diretos com Réplica de Armazenamento para Recuperação de Desastre em regiões do Azure.
• A comunicação da RPC de cluster para cluster no Azure (exigida pelas APIs de cluster para conceder acesso entre os clusters) requer a configuração do acesso de rede para o CNO. Você deve permitir a porta TCP 135 e o intervalo dinâmico acima da porta TCP 49152. Referência Criar Cluster de Failover do Windows Server na VM de IaaS do Azure – parte 2 Rede e Criação.
• É possível usar clusters convidados de dois nós, em que cada nó está usando o iSCSI de loopback para um cluster assimétrico replicado pela Réplica de Armazenamento. Mas isso provavelmente terá um desempenho muito ruim e deve ser usado apenas para cargas de trabalho ou testes muito limitados.

As mensagens de Evento 1237 mostradas no log de eventos do Administrador de Réplica de Armazenamento no servidor de destino mostram o número de bytes copiados e os bytes restantes a cada 10 segundos. Você também pode usar o contador de desempenho de Réplica de Armazenamento no destino exibindo \Estatísticas de Réplica de Armazenamento\Total de bytes recebidos para um ou mais volumes replicados. Também pode consultar o grupo de replicação usando o Windows PowerShell. Por exemplo, esta amostra de comando obtém o nome dos grupos no destino e então 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, usando Set-SRNetworkConstraint. Este cmdlet opera na camada da interface e é usado em cenários de cluster e não cluster. Por exemplo, com um servidor autônomo (em cada nó):

Get-SRPartnership

Get-NetIPConfiguration

Observe as informações de gateway e interface (em ambos os servidores) e as instruções de 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 estendido:

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 só oferece suporte à replicação de um para um de um servidor, cluster ou nó de cluster estendido. Isso pode mudar em uma versão posterior. Você pode, claro, 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 no Servidor 2, e seu volume E do Servidor 3.

Você pode aumentar (expandir) os volumes, mas não pode reduzi-los. Por padrão, a Réplica de Armazenamento impede que os administradores estendam os volumes replicados; use a opção Set-SRGroup -AllowVolumeResize $TRUE no grupo de origem, antes do redimensionamento. Por exemplo:

1. Uso contra o computador de origem: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE
2. Aumentar o volume usando qualquer técnica de sua preferência
3. Uso contra o computador de origem: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE

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

No entanto, na versão do Windows Server 2019 e de Windows Server Canal Semestral a partir da versão 1709, a opção para montar o armazenamento de destino agora é possível. Esse recurso é chamado de "Teste de Failover". Para fazer isso, você deve ter um volume não utilizado, com formatação NTFS ou ReFS, que não está atualmente replicando no destino. Em seguida, você pode montar um instantâneo do armazenamento replicado em nós de destino temporariamente para fins de teste ou backup.

Por exemplo, para criar um failover de teste onde você replica um volume "D:" no Grupo de replicação "RG2" do servidor de destino "SRV2" e tem uma unidade "T:" em SRV2 que não está sendo duplicada:

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

O volume replicado D: agora é acessível em SRV2. Você pode ler e gravar o volume normalmente, copiar arquivos dele ou executar um backup online que você salva em outro lugar para segurança no caminho D:. O volume T: conterá apenas dados de log.

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

Dismount-SRDestination -Name RG2 -Computername SRV2

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

Embora seja tecnicamente possível, essa não é uma configuração recomendada devido à falta de reconhecimento de local nos nós de computação que contatam o SOFS. Se for usada a rede de distância de campus, em que as latências são, normalmente, inferiores a milissegundos, essa configuração provavelmente funcionará sem problemas.

Se for configurada a replicação de cluster para cluster, a Réplica de Armazenamento dará suporte completo a Servidores de Arquivos de Escalabilidade Horizontal, incluindo o uso de Espaços de Armazenamento Direto, ao replicar entre dois clusters.

Não. Você pode replicar com CSV ou PDR (reserva de disco persistente) pertencente a um recurso de cluster, como uma função de Servidor de Arquivos.

Se for configurada a replicação de cluster para cluster, a Réplica de Armazenamento dará suporte completo a Servidores de Arquivos de Escalabilidade Horizontal, incluindo o uso de Espaços de Armazenamento Direto, ao replicar entre dois clusters.

Essa não é uma configuração compatível com o Windows Server. Isso pode mudar em uma versão posterior. Se for configurada a replicação de cluster para cluster, a Réplica de Armazenamento dará suporte completo a Servidores de Arquivos de Escalabilidade Horizontal e Servidores Hyper-V, incluindo o uso de Espaços de Armazenamento Direto.

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

Para evitar o failover automático, você pode usar o PowerShell para configurar Get-ClusterNode -Name "NodeName").NodeWeight=0. Isso remove o voto em cada nó no local de recuperação de desastre. Você pode usar Start-ClusterNode -PreventQuorum em nós no local principal e Start-ClusterNode -ForceQuorum em nós no local de desastre para forçar o failover. Não há uma opção gráfica para evitar o failover automático, não é recomendado e impedir o failover automático.

Para impedir que o novo recurso de resiliência de máquina virtual do Hyper-V seja executado e, portanto, pause máquinas virtuais em vez de fazer o failover delas para o local de recuperação de desastre, execute (Get-Cluster).ResiliencyDefaultPeriod=0

Você pode usar o armazenamento provisionado como uma maneira de agilizar os tempos de sincronização inicial. A Réplica de Armazenamento consulta e usa automaticamente o armazenamento provisionado dinâmico, incluindo Espaços de Armazenamento sem clusters, discos dinâmicos Hyper-V e LUNs SAN. Depois que a replicação inicial for iniciada, o volume não poderá ser reduzido ou ajustado.

Também é possível usar volumes de dados propagados para reduzir a largura de banda e, algumas vezes, economizar tempo, ao garantir que o volume de destino tenha algum subconjunto dos dados do principal e, então, usar a opção Propagado no Gerenciador de Cluster de Failover ou em New-SRPartnership. Se o volume estiver quase vazio, usar a sincronização propagada pode reduzir o uso de largura de banda e economizar tempo. Há várias maneiras de propagar dados, com diferentes graus de eficácia:

• Replicação anterior – replicando com a sincronização inicial normal localmente entre nós que contêm os discos e volumes, removendo a replicação, enviando os discos de destino para outro lugar e, em seguida, adicionando replicação com a opção propagada. Esse é o método mais eficaz, pois a Réplica de Armazenamento garantiu um espelho de cópia em bloco e a única coisa a ser replicada são os blocos delta.
• Instantâneo restaurado ou backup baseado em instantâneo restaurado – restaurando um instantâneo baseado em volume no volume de destino, deve haver diferenças mínimas no layout do bloco. Esse é o próximo método mais eficaz, pois os blocos provavelmente coincidirão devido às imagens de volume de snapshot serem espelhos uma da outra.
• Arquivos copiados – criando um novo volume no destino que nunca foi usado antes e executando uma cópia completa de árvore robocopy /MIR dos dados, é provável que haja correspondências de bloco. Usar o Explorador de Arquivos do Windows ou copiar parte da árvore não criará muitas correspondências de bloco. Copiar arquivos manualmente é o método menos eficaz de propagação.

Você pode usar o cmdlet Grant-SRDelegation. Isso permite que você defina usuários específicos em cenários de replicação de servidor para servidor, cluster para cluster e cluster estendido com as permissões para criar, alterar ou remover a replicação, sem serem membros do grupo de administradores locais. Por exemplo:

Grant-SRDelegation -UserName contso\tonywang

O cmdlet o lembrará de que o usuário precisa fazer logoff e logon do servidor que pretende administrar para que a alteração tenha efeito. Você pode usar Get-SRDelegation e Revoke-SRDelegation para controlar isso.

A Réplica de Armazenamento oferece suporte a backup e restauração do volume de origem. Também à criação e restauração de instantâneos do volume de origem. Você não pode fazer backup nem restaurar o volume de destino enquanto ele é protegido pela Réplica de Armazenamento, pois ele não está montado nem acessível. Se ocorrer um desastre em que o volume de origem seja perdido, o uso de Set-SRPartnership para promover o volume de destino anterior para ser, agora, uma origem de leitura/gravação permitirá que você faça backup ou restaure o volume. Também é possível remover a replicação com Remove-SRPartnership e Remove-SRGroup para remontar o volume como leitura/gravação.

Para criar instantâneos de aplicativos consistentes e periódicos, você pode usar VSSADMIN.EXE no servidor de origem para criar instantâneos de volumes de dados replicados. Por exemplo, você está replicando o volume F: com a Réplica de Armazenamento:

vssadmin create shadow /for=F:

Em seguida, depois de alternar a direção da replicação, remover a replicação ou se simplesmente ainda estiver no mesmo volume de origem, é possível restaurar qualquer instantâneo para seu ponto no tempo. Por exemplo, ainda usando F:

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

Você também pode agendar essa ferramenta para execução periódica usando uma tarefa agendada. Para saber mais sobre como usar o VSS, consulte Vssadmin. O backup de volumes de log não é necessário nem tem valor. Tentativas de fazer isso serão ignoradas pelo VSS.

O uso do Backup do Windows Server, do Backup do Microsoft Azure, do Microsoft DPM ou de outras tecnologias de instantâneos, VSS, máquina virtual ou baseadas em arquivo têm suporte na Réplica de Armazenamento contanto que operem na camada do volume. A Réplica de Armazenamento não dá suporte ao backup e à restauração baseados em bloco.

A Réplica de Armazenamento depende de SMB e WSMAN para replicação e gerenciamento. Isso significa que as seguintes portas são necessárias:

• 445 (SMB – protocolo de transporte de replicação, protocolo de gerenciamento de RPC de cluster)
• 5445 (SMB de iWARP – somente necessário ao usar rede de iWARP RDMA)
• 5985 (WSManHTTP – Protocolo de gerenciamento para WMI/CIM/PowerShell)

O tamanho ideal do log varia muito por ambiente e carga de trabalho e é determinado por quanto de E/S de gravação sua carga de trabalho executa.

• Um log maior ou menor não te fará mais rápido ou mais lento
• O tamanho de um log não influencia um volume de dados de 10GB em comparação a 10TB, por exemplo

Um log maior simplesmente coleta e retém mais gravações IOs antes de serem encapsulados. Isso permite que uma interrupção no serviço entre o computador de origem e destino – como uma interrupção na rede ou de destino sendo offline - dure mais tempo. Se o log palpáveis 10 horas de gravações, e a rede cai para 2 horas, quando a rede retorna que a origem pode simplesmente reproduzir o delta das alterações de volta para o destino muito rápido e você está protegido novamente muito rapidamente. Se o log contém 10 horas e a interrupção é 2 dias, a fonte agora tem a reprodução de um log diferente chamado o bitmap – e provavelmente será mais lento para entrar novamente em sincronização. Depois que estiver em sincronia, ele volta a usar o log.

A Réplica de Armazenamento depende do log para todo o desempenho da gravação. Desempenho de log essencial para o desempenho de replicação. Certifique-se de que o volume de log tem melhor desempenho que o volume de dados, como o log será serializar e sequentialize todos e/s de gravação. Você sempre deve usar uma mídia flash, como SSD, em volumes de log. Você nunca deve permitir que outras cargas de trabalho sejam executadas no volume do log. Da mesma maneira, você nunca deve permitir que outras cargas de trabalho sejam executadas em volumes de log do banco de dados SQL.

Novamente: Microsoft recomenda veementemente que o armazenamento de log seja mais rápido do que o armazenamento de dados e volumes de log nunca devem ser usados para outras cargas de trabalho.

Você pode obter recomendações de dimensionamento de log executando a ferramenta Test-SRTopology. Você também pode usar contadores de desempenho em servidores existentes para fazer um julgamento sobre o tamanho do log. A fórmula é simples: monitore a taxa de transferência do disco de dados (Média de Bytes de Gravação/S) na carga de trabalho e use-a para calcular o tempo necessário para preencher o log de tamanhos diferentes. Por exemplo, a taxa de transferência do disco de dados de 50 MB/s fará com que o log de 120 GB seja encapsulado em 120 GB/50 MB segundos ou 2400 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 encapsulado, mas o destino se tornar acessível novamente, a origem repetirá os blocos por meio do log do mapa de bits em vez do log principal. O tamanho do log não tem efeito sobre o desempenho.

SOMENTE o backup do disco de dados do cluster de origem deve ser feito. Os discos de Log da Réplica de Armazenamento NÃO devem ter backup, pois 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: cluster estendido, de cluster para cluster e de servidor para servidor. Há várias vantagens a cada um.

A topologia de cluster estendido é ideal para exigir que o failover automático com coordenação, como clusters de nuvem privada do Hyper-V e SQL Server FCI as cargas de trabalho. Ele também tem uma interface gráfica interna usando o Gerenciador de Cluster de Failover. Ele utiliza o clássico assimétrico arquitetura de armazenamento compartilhado de espaços de armazenamento, SAN, iSCSI, do cluster e RAID via reserva persistente. Você pode executar isso com um mínimo de 2 nós.

A topologia de cluster ao cluster usa dois clusters separados e é ideal para os administradores que desejam failover manual, especialmente quando o segundo local é provisionado para uso não diário e recuperação de desastres. Coordenação é manual. Ao contrário do cluster estendido, os Espaços de Armazenamento Diretos podem ser usados nessa configuração (com ressalvas – consulte as Perguntas frequentes sobre a Réplica de Armazenamento e a documentação de cluster para cluster). Você pode executar isso com um mínimo de quatro nós.

A topologia de servidor a servidor é ideal para clientes que executam o hardware que não pode ser agrupado. Isso requer coordenação e failover manual. É ideal para implantações baratas entre filiais e datacenters centrais, especialmente ao usar replicação assíncrona. Essa configuração geralmente pode substituir a instâncias de servidores de arquivos protegidos DFSR usado para cenários de recuperação de desastres de mestre único.

Em todos os casos, as topologias suportam a ambas as em execução no hardware físico, bem como em máquinas virtuais. Quando estiver em máquinas virtuais, o hipervisor subjacente não exige o Hyper-V; ele pode ser VMware, KVM, Xen, etc.

Armazenamento réplica também tem um modo de servidor-para-self, onde você apontar replicação em dois volumes diferentes no mesmo computador.

Sim, há suporte para a Eliminação de Duplicação de Dados com a Réplica de Armazenamento. Habilite a Eliminação de Duplicação de Dados em um volume no servidor de origem e, durante a replicação, o servidor de destino recebe uma cópia com eliminação de duplicação do volume.

Embora você deva instalar a 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 a 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 há suporte para a criação de uma nova parceria entre o Windows Server 2019 e o Windows Server 2016. Você pode atualizar com segurança um servidor ou cluster executando o Windows Server 2016 para o Windows Server 2019 e todas as parcerias existentes continuarão funcionando.

No entanto, para obter o desempenho de replicação aprimorado do Windows Server 2019, todos os membros da parceria devem executar o Windows Server 2019 e você deve excluir parcerias existentes e grupos de replicação associados e, em seguida, recriá-los com dados propagados (seja ao criar a parceria no Windows Admin Center ou com o cmdlet New-SRPartnership).

Para obter assistência técnica para a Réplica de Armazenamento, poste nos fóruns da Microsoft. Você também pode enviar um email para srfeed@microsoft.com em caso de dúvida sobre a Réplica de Armazenamento. 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. Ela só será replicada da origem para o destino por volume. Essa direção pode ser invertida a qualquer momento, mas ainda será apenas em uma direção. No entanto, isso não significa que você não possa 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 configurar a replicação de servidor para servidor. Servidor1 e Servidor2 têm letras de unidade L:, M:, N:, e O: e você deseja replicar a unidade M: do Servidor1 para Servidor2, mas a unidade O: você quer replicar do Servidor2 para Servidor1. Isso pode ser feito desde que haja unidades de log separadas para cada um dos grupos. por exemplo,

• Unidade de origem do Servidor1 M: com a unidade de log de origem L: replicando para a unidade de destino do Servidor2 M: com a unidade de log de destino L:
• Unidade de origem do Servidor2 O: com a unidade de log de origem N: replicando para a unidade de destino do Servidor1 O: com a unidade de log de destino N:

A Réplica de Armazenamento impedirá que qualquer disco de cluster entre no modo de manutenção. Para tarefas como habilitar ou desabilitar o Bitlocker, os discos devem estar no modo de manutenção. Para executar tarefas que exigem que os discos estejam no modo de manutenção, a parceria precisaria ser interrompida primeiro e criada novamente quando as tarefas forem concluídas.

• Visão geral da Réplica de armazenamento
• Replicação de cluster estendido usando Armazenamento Compartilhado
• Replicação de armazenamento de servidor para servidor
• Replicação de armazenamento de cluster para cluster
• Réplica de armazenamento: problemas conhecidos

• Visão geral de Armazenamento
• Espaços de Armazenamento Diretos