Domande frequenti su Replica archiviazione

Sì. È possibile gli scenari seguenti con Azure:

• Replica da server a server 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 server a server tra Azure e locale (tramite 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)
• Clustering esteso tramite 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 note sul clustering guest in Azure, vedere: Distribuzione di cluster guest delle VM IaaS in Microsoft Azure.

Note importanti:

• Sono disponibili modelli di Azure Resource Manager per il clustering di Replica archiviazione basato su Spazi di archiviazione diretta in Creare cluster SOFS di Spazi di archiviazione diretta con Replica di archiviazione per il ripristino di emergenza tra aree di Azure.
• La comunicazione RPC da cluster a cluster in Azure (richiesta dalle API del cluster per concedere l'accesso tra cluster) richiede la configurazione dell'accesso di rete per CNO. È necessario consentire la porta TCP 135 e l'intervallo dinamico sopra la porta TCP 49152. Informazioni di riferimento Creazione di cluster di failover Windows Server in una macchina virtuale IAAS di Azure - Parte 2: Rete e creazione.
• È possibile usare cluster guest a due nodi, in cui ogni nodo usa iSCSI loopback per un cluster asimmetrico replicato da Replica di archiviazione. Tuttavia, avranno probabilmente prestazioni molto scarse e devono essere usati solo per carichi di lavoro o test molto limitati.

I messaggi di Evento 1237 visualizzati nel log degli eventi dell'amministratore di Replica di archiviazione nel server di destinazione mostrano il numero di byte copiati e i byte rimanenti ogni 10 secondi. È inoltre possibile usare il contatore delle prestazioni di Replica archiviazione sulla destinazione \Statistiche Replica archiviazione\Byte totali ricevuti per uno o più volumi replicati. È inoltre possibile effettuare una query sul gruppo di replica tramite Windows PowerShell. Questo comando, ad esempio, ottiene il nome dei gruppi nella destinazione, quindi esegue una query di un gruppo denominato Replication 2 ogni 10 secondi per mostrare 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

Sì, usando Set-SRNetworkConstraint. Questo cmdlet opera a livello di interfaccia e viene usato in scenari con cluster e senza cluster. Ad esempio, con un server autonomo (in ogni nodo):

Get-SRPartnership

Get-NetIPConfiguration

Prendere nota delle informazioni sul gateway e l'interfaccia (su entrambi i server) e le direzioni della relazione. Eseguire quindi:

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

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

Per i vincoli della rete di configurazione in un cluster esteso:

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"

No, Replica archiviazione supporta solo la replica uno a uno di un server, un cluster o un nodo del cluster esteso. Questo limite potrebbe venire superato nelle versioni successive. Naturalmente, è possibile configurare la replica tra i vari server di una coppia di volumi specifica, in entrambe le direzioni. Ad esempio, Server 1 può replicare il volume D su Server 2 e il volume E su Server 3.

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

1. Usare con il computer di origine: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE
2. Far crescere il volume usando qualsiasi tecnica preferita
3. Usare con il computer di origine: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE

Non in Windows Server 2016. Replica archiviazione smonta il volume di destinazione quando inizia la replica.

Tuttavia, in Windows Server 2019 e Windows Server, Canale semestrale a partire dalla versione 1709, l'opzione per montare l'archiviazione di destinazione è ora presente. Questa funzionalità è denominata "Failover di test". A tale scopo, è necessario disporre di un volume formattato in NTFS o ReFS inutilizzato che attualmente non esegue la replica nella destinazione. È quindi possibile montare temporaneamente uno snapshot dell'archiviazione replicata a scopo di test o backup.

Ad esempio, per creare un failover di test in cui si replica un volume "D:" nel gruppo di replica "RG2" nel server di destinazione "SRV2" e si dispone di un'unità "T:" in SRV2 che non viene replicata:

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

Il volume replicato D: è ora accessibile in SRV2. È possibile leggere e scrivere normalmente, copiare i file o eseguire un backup online salvato altrove per la conservazione sicura, nel percorso D:. Il volume T: conterrà solo i dati di log.

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

Dismount-SRDestination -Name RG2 -Computername SRV2

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

Anche se tecnicamente possibile, non è una configurazione consigliata a causa della mancanza di riconoscimento dei siti nei nodi di calcolo che contattano SOFS. Se si usa una rete a distanza campus, dove le latenze sono in genere inferiori al millisecondo, questa configurazione funziona normalmente senza problemi.

Se si configura una replica da cluster a cluster, Replica archiviazione supporta completamente i File server di scalabilità orizzontale, inclusi l'uso di Spazi di archiviazione diretta, durante la replica tra due cluster.

N.: È possibile eseguire la replica con volume condiviso cluster o una prenotazione disco permanente (PDR) di proprietà di una risorsa cluster, ad esempio un ruolo file server.

Se si configura una replica da cluster a cluster, Replica archiviazione supporta completamente i File server di scalabilità orizzontale, inclusi l'uso di Spazi di archiviazione diretta, durante la replica tra due cluster.

Questa configurazione non è supportata in Windows Server. Questo limite potrebbe venire superato nelle versioni successive. Se si configura una replica da cluster a cluster, Replica archiviazione supporta completamente i File server di scalabilità orizzontale e i server Hyper-V, inclusi l'uso di Spazi di archiviazione diretta.

Specificare New-SRPartnership -ReplicationMode e fornire l'argomento Asincrono. Per impostazione predefinita, tutte le repliche in Replica archiviazione sono sincrone. È inoltre possibile modificare la modalità con Set-SRPartnership -ReplicationMode.

Per evitare il failover automatico, è possibile usare PowerShell per configurare Get-ClusterNode -Name "NodeName").NodeWeight=0. In questo modo si rimuove il voto in ogni nodo del sito di ripristino di emergenza. È quindi possibile usare Start-ClusterNode -PreventQuorum sui nodi nel sito primario e Start-ClusterNode -ForceQuorum sui nodi nel sito di emergenza per forzare il failover. Non esiste alcuna opzione grafica per evitare il failover automatico e in ogni caso non è consigliabile evitare il failover automatico.

Per evitare che la nuova funzionalità di resilienza della macchina virtuale Hyper-V venga eseguita, mettendo quindi in pausa le macchine virtuali invece di provocarne il failover al sito di ripristino di emergenza, eseguire (Get-Cluster).ResiliencyDefaultPeriod=0

È possibile usare l'archiviazione con thin provisioning per accelerare i tempi di sincronizzazione iniziali. Replica archiviazione esegue una query e usa automaticamente l'archiviazione con thin provisioning, compresi gli Spazi di archiviazione non cluster, i dischi dinamici Hyper-V e i LUN SAN. Dopo l'avvio della replica iniziale, il volume non sarà in grado di ridursi o troncarsi.

È inoltre possibile usare i volumi dei dati di seeding, per limitare l'uso della larghezza di banda e talvolta anche la durata, verificando innanzitutto che il volume di destinazione possieda un subset dei dati del database primario e quindi usando l'opzione Con seeding in Gestione cluster di failover o New-SRPartnership. Se il volume è prevalentemente vuoto, la sincronizzazione con seeding può ridurre la durata e l'uso della larghezza di banda. Esistono diversi modi per eseguire il seeding dei dati, con diversi gradi di efficacia:

• Replica precedente: replica della normale sincronizzazione iniziale in locale tra i nodi contenenti i dischi e i volumi, rimozione della replica, invio dei dischi di destinazione altrove, quindi aggiunta della replica con l'opzione seeded. Questo è il metodo più efficace perché Replica archiviazione garantisce un mirror di copia a blocchi e l'unica cosa da replicare sono i blocchi differenziali.
• Backup ripristinato o backup ripristinato basato su snapshot: ripristinando uno snapshot basato su volume nel volume di destinazione, dovrebbero esserci differenze minime nel layout del blocco. Questo è il metodo più efficace successivo perché è probabile che i blocchi corrispondano, grazie al fatto che gli snapshot del volume sono immagini mirror.
• File copiati: creando un nuovo volume mai usato prima nella destinazione ed eseguendo una copia ad albero robocopy /MIR completa dei dati, è probabile che si verifichino corrispondenze di blocco. L'uso di Esplora file di Windows o la copia di una parte dell'albero non creerà molte corrispondenze di blocco. La copia manuale dei file è il metodo meno efficace di seeding.

È possibile usare il cmdlet Grant-SRDelegation. Ciò consente di impostare utenti specifici in scenari di replica da server a server, da cluster a cluster e con cluster esteso che abbiano le autorizzazioni per creare, modificare o rimuovere la replica, pur non essendo un membro del gruppo di amministratori locale. Ad esempio:

Grant-SRDelegation -UserName contso\tonywang

Il cmdlet ricorderà che l'utente deve disconnettersi e riconnettersi al server che intende amministrare affinché le modifiche abbiano effetto. È possibile usare Get-SRDelegation e Revoke-SRDelegation per controllare ulteriormente questa opzione.

Replica archiviazione supporta il backup e il ripristino del volume di origine. Supporta inoltre la creazione e il ripristino degli snapshot del volume di origine. Non è possibile eseguire il backup o ripristinare il volume di destinazione quando è protetto da Replica archiviazione, in quanto non è montato né accessibile. Se si verifica una situazione di emergenza in cui il volume di origine viene perso, usando Set-SRPartnership per fare in modo che il volume di destinazione precedente venga promosso a origine di lettura/scrittura sarà possibile eseguire il backup o il ripristino di tale volume. È inoltre possibile rimuovere la replica con Remove-SRPartnership e Remove-SRGroup per rimontare tale volume come accessibile in lettura/scrittura.

Per creare snapshot periodici coerenti con l'applicazione, è possibile usare VSSADMIN.EXE sul server di origine per eseguire uno snapshot dei volumi di dati replicati. Ad esempio, se si sta replicando il volume F: con Replica archiviazione:

vssadmin create shadow /for=F:

Dopo aver modificato la direzione di replica, rimosso la replica o quando ci si trova semplicemente nello stesso volume di origine, è possibile ripristinare eventuali snapshot al momento in cui sono stati eseguiti. Ad esempio, usando ancora F:

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

È inoltre possibile pianificare questo strumento in modo che venga eseguito periodicamente tramite un'attività pianificata. Per altre informazioni sull'uso del Servizio Copia Shadow del volume, vedere Vssadmin. Il backup di volumi di registro non richiede azioni o valori particolari. Il tentativo di eseguire questa operazione verrà ignorato da Servizio Copia Shadow del volume.

L'uso di Windows Server Backup, backup di Microsoft Azure, Microsoft DPM o altri snapshot, Servizio Copia Shadow del volume, macchina virtuale o tecnologie basate su file è supportato da Replica archiviazione purché questi servizi operino all'interno del livello del volume. Replica archiviazione non supporta il backup e il ripristino basati su blocchi.

Replica di archiviazione si basa su SMB e WSMAN per la replica e la gestione. Ciò significa che 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 iWARP)
• 5985 (WSManHTTP - Protocollo di gestione per WMI/CIM/PowerShell)

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

• Un log più grande o più piccolo non aumenta né diminuisce rispettivamente la velocità
• Un log di dimensioni maggiori o minori non ha alcun impatto su un volume di dati da 10 GB rispetto a un volume di dati di 10 TB, ad esempio

Un log più grande raccoglie e mantiene più operazioni di I/O di scrittura prima di eseguirne il wrapping. Ciò consente una più lunga interruzione del servizio tra il computer di origine e quello di destinazione, ad esempio un'interruzione della rete o una destinazione offline. Se il log può contenere 10 ore di scrittura e la rete rimane non disponibile per 2 ore, quando la rete torna disponibile l'origine può semplicemente riprodurre il differenziale delle modifiche non sincronizzate alla destinazione molto velocemente e si rimarrà protetti di nuovo molto rapidamente. Se il log contiene 10 ore e l'interruzione è di 2 giorni, l'origine deve ora riprodurre da un log diverso denominato bitmap e probabilmente la sua risincronizzazione sarà più lenta. Una volta sincronizzato, torna a usare il log.

Replica archiviazione si basa sul log per tutte le prestazioni di scrittura. Registrare le prestazioni critiche per le prestazioni di replica. È necessario assicurarsi che il volume di log funzioni meglio del volume di dati, perché il log serializzerà e sequenzierà tutte le operazioni di I/O di scrittura. È consigliabile usare sempre supporti flash come SSD nei volumi di log. Non consentire mai l'esecuzione di altri carichi di lavoro nel volume di log, allo stesso modo in cui non bisogna mai consentire l'esecuzione di altri carichi di lavoro nei volumi di log del database SQL.

Anche in questo caso, Microsoft consiglia vivamente di velocizzare l'archiviazione dei log rispetto all'archiviazione dei dati e di non usare mai i volumi di log per altri carichi di lavoro.

È possibile ottenere raccomandazioni sul ridimensionamento dei log eseguendo lo strumento 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 (byte di scrittura media/sec) nel carico di lavoro e usarla per calcolare la quantità di tempo necessario per riempire il log di dimensioni diverse. Ad esempio, la velocità effettiva del disco dati di 50 MB/s causerà il wrapping del log di 120 GB in 120 GB/50 MB secondi oppure 2400 secondi o 40 minuti. Pertanto, la quantità di tempo per 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 eseguirà di nuovo blocchi di riproduzione tramite il log mappa di bit anziché il log principale. Le dimensioni del log non influiscono sulle prestazioni.

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

Replica archiviazione include tre configurazioni principali: cluster esteso, da cluster a cluster e da server a server. Vi sono diversi vantaggi per ognuna di esse.

La topologia del cluster esteso è ideale per i carichi di lavoro che richiedono il failover automatico con orchestrazione, ad esempio i cluster cloud privati Hyper-V e l'istanza del cluster di failover di SQL Server. Dispone anche di un'interfaccia grafica predefinita con Gestione cluster di failover. Usa l'architettura di archiviazione condivisa del cluster asimmetrico classica di Spazi di archiviazione, SAN, iSCSI e RAID tramite prenotazione permanente. È possibile eseguire questa operazione con un numero di nodi pari a 2.

La topologia da cluster a cluster usa due cluster separati ed è ideale per gli amministratori che vogliono eseguire il failover manuale, soprattutto quando viene effettuato il provisioning del secondo sito per il ripristino di emergenza e non per l'utilizzo quotidiano. L'orchestrazione è manuale. A differenza del cluster esteso, Spazi di archiviazione diretta può essere usato in questa configurazione (con alcune avvertenze: vedere le domande frequenti su Replica di archiviazione e la documentazione per l'approccio da cluster a cluster). È possibile eseguire questa operazione con un numero di nodi pari a 4.

La topologia da server a server è ideale per i clienti che eseguono hardware che non possono 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 di file server protetti da DFSR usati per scenari di ripristino di emergenza a master singolo.

In tutti i casi, le topologie supportano sia l'esecuzione su hardware fisico che su macchine virtuali. Quando si trova in macchine virtuali, l'hypervisor sottostante non richiede Hyper-V; può essere VMware, KVM, Xen e così via.

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

Sì, la deduplicazione dati è supportata con Replica archiviazione. Abilitare la Deduplicazione dati in un volume nel server di origine e durante la replica il server di destinazione riceve una copia deduplicata del volume.

Sebbene sia necessario installare Deduplicazione dati nei server di origine e di destinazione (vedere Installazione e abilitazione di 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.

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 esistente continuerà a funzionare.

Tuttavia, per ottenere le prestazioni di replica migliorate di Windows Server 2019, tutti i membri della partnership devono eseguire Windows Server 2019 ed è 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 con il cmdlet New-SRPartnership).

Per assistenza tecnica relativa a Replica di archiviazione, è possibile pubblicare un post nei forum di Microsoft. È anche possibile inviare un'e-mail a srfeed@microsoft.com per le domande su Replica archiviazione. 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 è una tecnologia di replica unidirezionale, che eseguirà la replica solo dall'origine alla destinazione in base al volume. Questa direzione può essere invertita in qualsiasi momento, ma è ancora monodirezionale. Ciò non significa tuttavia che non sia 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, è necessario configurare la replica da server a server. Server1 e Server2 hanno lettere di unità L:, M:, N: e O: e si desidera replicare l'unità M: da Server1 a Server2 ma si replica invece l'unità O: da Server2 a Server1. Questa operazione può essere eseguita fino a quando sono presenti unità di log separate per ognuno dei gruppi. Ad es.

• Unità di origine Server1 M: con l'unità di log di origine L: che effettua la replica nell'unità di destinazione Server2 M: con l'unità L: per il log di destinazione
• Unità di origine Server2 O: con l'unità di log di origine N: che effettua la replica nell'unità di destinazione Server1 O: con l'unità N: per il log di destinazione

Replica archiviazione impedisce a tutti i dischi del cluster di accedere alla modalità di manutenzione. Per le attività come l'abilitazione o la disabilitazione di Bitlocker, i dischi devono essere in modalità di manutenzione. Per eseguire attività che richiedono che i dischi siano in modalità di manutenzione, la relazione deve essere interrotta prima e creata di nuovo una volta completata.

• Panoramica di Replica di archiviazione
• Replica di un cluster esteso tramite risorse di archiviazione condivise
• Replica di archiviazione da server a server
• Replica di archiviazione da cluster a cluster
• Replica di archiviazione: problemi noti

• Panoramica dell'archiviazione
• Spazi di archiviazione diretta