Modifica

Condividi tramite

Domande frequenti su Replica archiviazione

  • Domande frequenti

Questo articolo contiene le risposte alle domande frequenti su Replica di archiviazione.

Replica archiviazione è supportata in Azure?

Sì. È possibile usare gli scenari seguenti con Azure:

  • Replica da server a server in Azure (in modo sincrono o asincrono tra le macchine virtuali IaaS) dell'infrastruttura distribuita come servizio (VM) in uno o due domini di errore del data center o in modo asincrono tra due aree separate.
  • Replica asincrona da server a server tra Azure e locale (usando una rete privata virtuale (VPN) o Azure ExpressRoute.
  • Replica da cluster a cluster in Azure (in modo sincrono o asincrono tra macchine virtuali IaaS in uno o due domini di errore del data center o in modo asincrono tra due aree separate).
  • Replica asincrona da cluster a cluster tra Azure e locale (tramite VPN o Azure ExpressRoute).
  • Estendere il clustering usando dischi condivisi di Azure (in modo sincrono o asincrono tra macchine virtuali IaaS in uno o due domini di errore del data center o in modo asincrono tra due aree separate).

Per altre informazioni sul clustering guest in Azure, vedere Distribuire cluster guest di macchine virtuali IaaS in Azure.

Note importanti:

Come si visualizza lo stato di avanzamento della replica durante la sincronizzazione iniziale?

I messaggi con ID evento 1237 nel registro eventi amministratore replica archiviazione nel server di destinazione mostrano il numero di byte copiati e i byte rimanenti ogni 10 secondi.

Un'altra opzione consiste nell'usare il contatore delle prestazioni replica archiviazione nel server di destinazione in \Statistiche replica archiviazione\Totale byte ricevuti per uno o più volumi replicati.

È anche possibile eseguire query sul gruppo di replica usando Windows PowerShell. Ad esempio, il comando di esempio seguente ottiene il nome dei gruppi nella destinazione e quindi esegue una query su un gruppo denominato Replica 2 ogni 10 secondi per visualizzare lo stato di avanzamento:

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

È possibile specificare le interfacce di rete da usare per la replica?

Sì. Per specificare le interfacce di rete da usare per la replica, usare il cmdlet Set-SRNetworkConstraint. Questo cmdlet opera a livello di interfaccia. È possibile usarlo sia in scenari cluster che non cluster.

Ad esempio, con un server autonomo (in ogni nodo), eseguire questi comandi:

Get-SRPartnership

Get-NetIPConfiguration

Si notino le informazioni sul gateway e sull'interfaccia (su entrambi i server) e le direzioni della partnership. Eseguire quindi:

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

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

Per configurare i vincoli di rete in un cluster esteso, eseguire:

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"

È possibile configurare la replica uno-a-molti o la replica transitiva (da A a B a C) ?

No, Replica archiviazione supporta solo una replica uno-a-uno di un server, un cluster o un nodo del cluster esteso. È possibile configurare la replica tra vari server di una coppia di volumi specifica in entrambe le direzioni. Ad esempio, Server 1 può replicare il volume D in Server 2 e il volume E da Server 3.

È possibile aumentare o ridurre i volumi replicati replicati dalla replica di archiviazione?

È possibile aumentare (estendere) i volumi, ma non ridurli. Per impostazione predefinita, Replica archiviazione impedisce agli amministratori di estendere i volumi replicati. Prima del ridimensionamento, usare l'opzione Set-SRGroup -AllowVolumeResize $TRUE nel gruppo di origine.

Per esempio:

  1. Eseguire questo comando nel computer di origine: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE.
  2. Aumentare il volume usando la tecnica preferita.
  3. Eseguire questo comando nel computer di origine: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE.

È possibile portare online un volume di destinazione per l'accesso in sola lettura?

Windows Server 2016: No. Replica archiviazione smonta il volume di destinazione all'avvio della replica in Windows Server 2016.

Windows Server 2019: Sì. È possibile montare l'archiviazione di destinazione usando la funzionalità di failover di test. Per eseguire un failover di test, è necessario disporre di un volume formattato NTFS o ReFS inutilizzato che attualmente non esegue la replica nella destinazione. Montare quindi temporaneamente uno snapshot dell'archiviazione replicata per scopi di test o backup.

Per creare un failover di test per il gruppo di replica RG2 nel server di destinazione SRV2, usando T: come unità temporanea che non viene replicata, eseguire il comando seguente:

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

Il volume replicato è ora accessibile in SRV2. È possibile leggere e scrivere in esso normalmente, copiare i file da esso o eseguire un backup online che si salva altrove per la conservazione sicura. Il volume T: contiene dati di log.

Per rimuovere lo snapshot di failover di test e rimuovere le modifiche, eseguire:

Dismount-SRDestination -Name RG2 -Computername SRV2

È consigliabile usare la funzionalità di failover di test solo per operazioni temporanee a breve termine. Non è destinato all'utilizzo a lungo termine. Quando in uso, la replica continua con il volume di destinazione reale.

È possibile configurare Scale-Out file server in un cluster esteso?

Sebbene sia tecnicamente possibile, questa configurazione non è consigliata a causa della mancanza di consapevolezza del sito nei nodi di calcolo che contattano l'istanza sofS. Se si usano reti a distanza campus, in cui le latenze sono in genere inferiori a un millisecondo, questa configurazione funziona in genere senza problemi.

In una replica da cluster a cluster, Replica archiviazione supporta completamente sofS, incluso l'uso di Spazi di archiviazione diretta, quando si esegue la replica tra due cluster.

I volumi condivisi del cluster devono essere replicati in un cluster esteso o tra cluster?

No. È possibile eseguire la replica usando volumi condivisi cluster o una prenotazione disco permanente (PDR) di proprietà di una risorsa cluster, ad esempio un ruolo file server.

Nella replica da cluster a cluster, Replica di archiviazione supporta completamente sofS, incluso l'uso di Spazi di archiviazione diretta, durante la replica tra due cluster.

È possibile configurare Spazi di archiviazione diretta in un cluster esteso con Replica archiviazione?

No. Questa configurazione non è supportata in Windows Server.

Nella replica da cluster a cluster, Replica di archiviazione supporta completamente sofS e server Hyper-V, incluso l'uso di Spazi di archiviazione diretta.

Come si configura la replica asincrona?

Eseguire New-SRPartnership -ReplicationMode e specificare l'argomento Asynchronous. Per impostazione predefinita, tutte le repliche in Replica archiviazione sono sincrone. È anche possibile modificare la modalità eseguendo Set-SRPartnership -ReplicationMode.

Come si impedisce il failover automatico di un cluster esteso?

Per impedire il failover automatico, è possibile usare PowerShell per configurare Get-ClusterNode -Name "NodeName").NodeWeight=0. Questo comando rimuove il voto per ogni nodo nel sito di ripristino di emergenza. È quindi possibile eseguire Start-ClusterNode -PreventQuorum nei nodi del sito primario e Start-ClusterNode -ForceQuorum nei nodi del sito di emergenza per forzare il failover. La prevenzione del failover automatico non è disponibile come opzione di configurazione dell'interfaccia utente ed è consigliabile non impedire il failover automatico.

Come si disabilita la resilienza delle macchine virtuali?

Per evitare che la nuova funzionalità di resilienza delle macchine virtuali Hyper-V sia in esecuzione e sospendi le macchine virtuali anziché eseguirne il failover nel sito di ripristino di emergenza, eseguire (Get-Cluster).ResiliencyDefaultPeriod=0.

Come è possibile ridurre il tempo per la sincronizzazione iniziale?

È possibile usare l'archiviazione con thin provisioning per velocizzare i tempi di sincronizzazione iniziali. Le query di Replica di archiviazione per e usano automaticamente l'archiviazione con thin provisioning, inclusi spazi di archiviazione non cluster, Hyper-V dischi dinamici e numeri di unità logica (SAN) della rete di archiviazione (SAN). Dopo l'avvio della replica iniziale, non è possibile compattare o tagliare il volume.

È anche possibile usare i volumi di dati con seeding per ridurre l'utilizzo della larghezza di banda e, in alcuni scenari, l'ora di sincronizzazione. Usare l'opzione Seeded in Gestione cluster di failover o usare il cmdlet New-SRPartnership per assicurarsi che il volume di destinazione disponga di un sottoinsieme di dati dal sito primario. Se il volume è per lo più vuoto, l'uso della sincronizzazione con seeding potrebbe ridurre il tempo e l'utilizzo della larghezza di banda.

Per eseguire il seeding dei dati, è possibile scegliere tra opzioni che offrono diversi gradi di efficacia:

  • replica precedente. Eseguire la replica tramite la normale sincronizzazione iniziale in locale tra i nodi che contengono i dischi e i volumi, rimuovere la replica, spedire i dischi di destinazione altrove e quindi aggiungere la replica usando l'opzione seeded. Questo metodo è il più efficace perché Replica archiviazione garantisce un mirror di copia a blocchi e l'unica cosa da replicare è blocchi differenziali.
  • il backup basato su snapshot ripristinato o ripristinato. Ripristinando uno snapshot basato su volume nel volume di destinazione, dovrebbero esserci differenze minime nel layout del blocco. Questo metodo è più efficace. È probabile che i blocchi corrispondano perché gli snapshot del volume sono immagini mirror.
  • file copiati. Creare un nuovo volume nella destinazione non usata e quindi eseguire una copia ad albero robocopy /MIR completa dei dati. È probabile che siano presenti corrispondenze di blocco. L'uso di Esplora file di Windows o la copia di alcune parti dell'albero non crea molte corrispondenze di blocco. La copia manuale dei file è il metodo meno efficace di seeding.

È possibile delegare gli utenti per amministrare la replica?

Sì. Usare il cmdlet Grant-SRDelegation per delegare gli utenti. È possibile usare il comando per impostare utenti specifici in scenari di replica da server a server, da cluster a cluster e da estendere. Il comando delega le autorizzazioni per creare, modificare o rimuovere la replica senza essere membro del gruppo administrators locale.

Per esempio:

Grant-SRDelegation -UserName contoso\tonywang

Il cmdlet ricorda che l'utente deve disconnettersi e quindi accedere al server che intende amministrare per rendere effettiva la modifica. È possibile usare i cmdlet Get-SRDelegation e Revoke-SRDelegation per controllare ulteriormente la delega.

Quali sono le opzioni di backup e ripristino per i volumi replicati?

Replica archiviazione supporta il backup e il ripristino del volume di origine. Supporta anche la creazione e il ripristino di snapshot del volume di origine. Non è possibile eseguire il backup o ripristinare il volume di destinazione mentre è protetto da Replica archiviazione perché non è montato o accessibile.

Se si verifica un'emergenza e il volume di origine viene perso, è possibile usare il cmdlet Set-SRPartnership per alzare di livello la destinazione come nuovo volume di origine. Nell'origine appena promossa è possibile eseguire il backup o il ripristino di tale volume. È anche possibile rimuovere la replica con usando i cmdlet Remove-SRPartnership e Remove-SRGroup per rimontare il volume come in lettura/scrivibile.

Per creare snapshot periodici coerenti con l'applicazione, è possibile usare il servizio Copia Shadow del volume eseguendo VSSAdmin.exe nel server di origine per creare snapshot dei volumi di dati replicati.

Ad esempio, in cui si esegue la replica del volume F: con Replica archiviazione, eseguire questo comando:

vssadmin create shadow /for=F:

Dopo aver cambiato direzione di replica, rimuovere la replica o semplicemente nello stesso volume di origine, è possibile ripristinare qualsiasi snapshot nel tempo.

Ad esempio, usando ancora F:, eseguire:

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

È anche possibile pianificare l'esecuzione periodica di questo strumento usando un'attività pianificata. Per altre informazioni sull'uso di VSS, vedere vssadmin. Vss ignora il volume di log, quindi non è necessario eseguire il backup del volume di log.

Replica archiviazione supporta backup basati su file. Replica archiviazione non supporta il backup e il ripristino basati su blocchi.

Quali porte di rete richiedono Replica archiviazione?

Replica di archiviazione si basa su SMB (Server Message Block) e Gestione servizi Web (WSMan) per la replica e la gestione, quindi sono necessarie le porte seguenti:

  • 445 (SMB; protocollo di trasporto di replica, protocollo di gestione RPC del cluster)
  • 5445 (iWARP SMB; necessario solo quando si usa la rete RDMA (Remote Memory Access) iWARP
  • 5985 (WSManHTTP; protocollo di gestione per Strumentazione gestione Windows (WMI)/Common Information Model (CIM)/PowerShell)

Nota

Il cmdlet Test-SRTopology richiede ICMPv4/ICMPv6, ma non per la replica o la gestione.

Quali sono le procedure consigliate per il volume di log?

Le dimensioni ottimali del log variano notevolmente in base all'ambiente e al carico di lavoro e in base alla quantità di operazioni di I/O di scrittura eseguite dal carico di lavoro.

  • Un log più grande o più piccolo non rende la replica più veloce o più lenta.
  • Un log di dimensioni maggiori o minori non ha alcun effetto su un volume di dati da 10 GB rispetto a un volume di dati da 10 TB( ad esempio).

Un log più grande raccoglie e mantiene più operazioni di I/O di scrittura prima di essere sottoposto a wrapping. Un log di dimensioni maggiori consente un'interruzione del servizio tra il computer di origine e di destinazione, ad esempio un'interruzione di rete o la destinazione offline, di andare più a lungo. Ad esempio, il log è configurato per contenere fino a 10 ore di scrittura e la rete si arresta per 2 ore. Al termine della rete, l'origine può riprodurre solo il delta delle modifiche non sincronizzate alla destinazione. Se il log contiene 10 ore e l'interruzione è di due giorni, l'origine deve ora riprodurre da un log diverso denominato bitmap e non è in genere più lento per tornare sincronizzato. Quando è sincronizzato, torna a usare il log.

Replica archiviazione si basa sul log per tutte le prestazioni di scrittura. Le prestazioni dei log sono fondamentali per le prestazioni di replica. È necessario assicurarsi che il volume di log funzioni meglio del volume di dati perché il log serializza e sequenzializza tutte le operazioni di I/O di scrittura. È consigliabile usare sempre supporti flash come un'unità SSD (Solid State Drive) nei volumi di log. Non è mai necessario consentire l'esecuzione di altri carichi di lavoro nel volume di log, allo stesso modo in cui non è mai possibile consentire l'esecuzione di altri carichi di lavoro nei volumi di log del database SQL.

Importante

È consigliabile che l'archiviazione dei log sia più veloce rispetto all'archiviazione dei dati e che i volumi di log non vengano mai usati per altri carichi di lavoro.

È possibile ottenere raccomandazioni per il ridimensionamento dei log eseguendo il cmdlet Test-SRTopology. In alternativa, è possibile usare i contatori delle prestazioni nei server esistenti per determinare le dimensioni del log. La formula è semplice: monitorare la velocità effettiva del disco dati (Avg Write Bytes/Sec) nel carico di lavoro e usarla per calcolare il tempo necessario per riempire il log di dimensioni diverse. Ad esempio, la velocità effettiva del disco dati di 50 MB/s causa il wrapping del log di 120 GB in 120 GB diviso per 50 MB per secondi, ovvero 2.400 secondi o 40 minuti. Pertanto, la quantità di tempo in cui il server di destinazione potrebbe non essere raggiungibile prima del wrapping del log è di 40 minuti. Se il log esegue il wrapping ma la destinazione diventa nuovamente raggiungibile, l'origine riproduce i blocchi tramite il log bitmap anziché il log principale. Le dimensioni del log non influisce sulle prestazioni.

è necessario eseguire il backup solo disco dati dal cluster di origine. I dischi del log di Replica archiviazione devono non essere sottoposti a backup perché un backup può essere in conflitto con le operazioni di replica archiviazione.

Quale topologia è necessario scegliere: estendere cluster, cluster a cluster o da server a server?

Replica archiviazione include tre configurazioni principali: stretch cluster, cluster-to-cluster e server-to-server. Ogni topologia presenta vantaggi diversi.

La topologia del cluster esteso è ideale se il carico di lavoro richiede il failover automatico con orchestrazione, ad esempio in un cluster cloud privato Hyper-V o per l'istanza del cluster di failover di SQL Server. Include anche un'interfaccia grafica predefinita, Gestione cluster di failover, per semplificare l'uso. Usa l'architettura classica di archiviazione condivisa del cluster asimmetrico di Spazi di archiviazione, SAN, iSCSI e RAID tramite prenotazione permanente. È possibile eseguire questa topologia con un numero limitato di due nodi.

La topologia da cluster a cluster usa due cluster separati. Questa topologia è ideale se si vuole eseguire il failover manuale o quando viene effettuato il provisioning del secondo sito per il ripristino di emergenza e non per l'uso quotidiano. L'orchestrazione è manuale. A differenza di una topologia di cluster esteso, è possibile usare Spazi di archiviazione diretta in questa configurazione . Per le avvertenze, vedere domande frequenti sulla replica di archiviazione e la documentazione su cluster a cluster. È possibile eseguire questa topologia con un numero limitato di quattro nodi.

La topologia da server a server è ideale se si esegue hardware che non può essere cluster. Richiede failover manuale e orchestrazione. È ideale per distribuzioni economiche tra succursali e data center centrali, soprattutto quando si usa la replica asincrona. Questa configurazione può spesso sostituire le istanze dei file server protetti da Replica file system distribuita (replica DFS) usati per scenari di ripristino di emergenza a master singolo.

In tutti i casi, le topologie supportano sia l'esecuzione su hardware fisico che l'esecuzione in macchine virtuali. In una macchina virtuale, l'hypervisor sottostante non richiede Hyper-V. È possibile usare, ad esempio, VMware, KVM o Xen.

Replica archiviazione ha anche una modalità da server a self, in cui si punta la replica a due volumi diversi nello stesso computer.

La deduplicazione dati è supportata con Replica archiviazione?

Sì. Abilitare Deduplicazione dati in un volume nel server di origine e durante la replica il server di destinazione riceve una copia deduplicata del volume.

Anche se è necessario installare Deduplicazione dati sia nei server di origine che nei server di destinazione (vedere Installare e abilitare la deduplicazione dati), è importante non abilitare Deduplicazione dati nel server di destinazione. Replica archiviazione consente le scritture solo nel server di origine. Poiché La deduplicazione dati esegue operazioni di scrittura nel volume, deve essere eseguita solo nel server di origine.

È possibile eseguire la replica tra Windows Server 2019 e Windows Server 2016?

Sfortunatamente, non è supportata la creazione di una nuova partnership tra Windows Server 2019 e Windows Server 2016. È possibile aggiornare in modo sicuro un server o un cluster che esegue Windows Server 2016 a Windows Server 2019 e qualsiasi partnership esistenti continui a funzionare.

Per ottenere prestazioni di replica migliorate di Windows Server 2019, tutti i membri della partnership devono eseguire Windows Server 2019. È inoltre necessario eliminare le partnership esistenti e i gruppi di replica associati e quindi ricrearli con i dati di inizializzazione (quando si crea la partnership in Windows Admin Center o usando il cmdlet New-SRPartnership).

Come si segnala un problema con Replica archiviazione o con la documentazione?

Per assistenza tecnica con Replica archiviazione, è possibile inviare un post in Microsoft Q & Un o contattare supporto tecnico Microsoft Business.

Per i problemi relativi a questa documentazione, vedere la sezione Commenti e suggerimenti nella parte inferiore di questa pagina e selezionare Questa pagina.

Replica archiviazione può essere configurata per la replica in entrambe le direzioni?

Replica archiviazione è una tecnologia di replica unidirezionale. Replica solo dall'origine alla destinazione in base al volume. La direzione può essere invertita in qualsiasi momento, ma viene comunque replicata in una sola direzione.

È possibile replicare un set di volumi (origine e destinazione) in una direzione e un set diverso di unità (origine e destinazione) replicate nella direzione opposta.

Ad esempio, si vuole configurare la replica da server a server. Server1 e Server2 dispongono di lettere di unità L:, M:, N:e O:. Si vuole replicare M: unità da Server1 a Server2e replicare O: unità da Server2 a Server1. Se sono presenti unità di log separate per ognuno dei gruppi, è possibile usare questa configurazione:

  • Server1 M: di unità di origine con unità log di origine L: replica in Server2drive M: di destinazione con l'unità dei log di destinazione L:.
  • Server2'unità di origine O: con unità di log di origine N: replica in Server1drive O: di destinazione con unità di log di destinazione N:.

È possibile inserire i dischi del cluster in modalità di manutenzione?

Replica archiviazione impedisce a tutti i dischi del cluster di entrare in modalità di manutenzione. Per alcune attività, ad esempio l'abilitazione o la disabilitazione di BitLocker, i dischi devono essere in modalità di manutenzione. Per le attività che richiedono che i dischi siano in modalità di manutenzione, la relazione deve prima essere interrotta e quindi creata di nuovo al termine dell'attività.

È possibile configurare Replica archiviazione tra versioni diverse del sistema operativo?

Replica archiviazione blocca una nuova relazione se le versioni del log di replica non corrispondono o se una funzionalità non è supportata da entrambi i server. La compressione replica archiviazione è un esempio di funzionalità che non corrisponde tra le versioni del sistema operativo perché è stata aggiunta per la prima volta in Windows Server 2022. Il tentativo di configurare una relazione con un server che non supporta una funzionalità restituisce l'errore "L'operazione richiesta non è supportata".

La tabella seguente illustra la matrice di interoperabilità della versione del log corrente:

Replica da/a Windows Server 2016 Windows Server 2019 Windows Server 2022
Windows Server 2016
Windows Server 2019
Windows Server 2022

Contenuto correlato