Replica di archiviazione da server a server
È possibile usare Replica di archiviazione per configurare due server per la sincronizzazione dei dati, in modo che ciascuno disponga di una copia identica dello stesso volume. Questo argomento offre informazioni generali sulla replica di archiviazione da server a server, oltre a indicazioni per la configurazione e la gestione dell'ambiente.
Per gestire Replica archiviazione, è possibile usare Windows Admin Center o PowerShell.
Ecco un video di panoramica sull'uso di Replica archiviazione in Windows Admin Center.
Prerequisiti
- Foresta di Active Directory Domain Services (non è necessario eseguire Windows Server 2016).
- Due server che eseguono Windows Server 2019 o Windows Server 2016, Datacenter Edition. Se si esegue Windows Server 2019, è invece possibile usare Standard Edition se si sta eseguendo la replica di un solo volume di dimensioni fino a 2 TB.
- Due set di risorse di archiviazione che usano JBOD SAS, SAN Fibre Channel, destinazione iSCSI o archiviazione SATA o SCSI locale. L'archivio deve contenere una combinazione di supporti SSD e HDD. Ogni set di risorse di archiviazione verrà resa disponibile a un solo server senza accesso condiviso.
- Ogni set di risorse di archiviazione deve consentire la creazione di almeno due dischi virtuali, uno per i dati replicati e uno per i registri. L'archiviazione fisica deve avere le stesse dimensioni di settore su tutti i dischi di dati. L'archiviazione fisica deve avere le stesse dimensioni di settore su tutti i dischi dei registri.
- Almeno una connessione Ethernet/TCP su ogni server per la replica sincrona, ma preferibilmente RDMA.
- Regole firewall e router appropriate per consentire ICMP, SMP (porta 445 più 5445 per SMB diretto) e traffico bidirezionale WS-MAN (porta 5985) tra tutti i nodi.
- Una rete tra i server con larghezza di banda sufficiente per contenere il carico di lavoro di scrittura delle operazioni di I/O e una latenza media di andata e ritorno di =5 ms, per la replica sincrona. La replica asincrona non dispone di un'indicazione di latenza.
Se si esegue la replica tra server locali e macchine virtuali di Azure, è necessario creare un collegamento di rete tra i server locali e le macchine virtuali di Azure. A tale scopo, usare ExpressRoute, una connessione gateway VPN da sito a sito o installare il software VPN nelle macchine virtuali di Azure per connetterli alla rete locale. - L'archiviazione replicata non può trovarsi nell'unità che contiene la cartella del sistema operativo Windows.
Importante
In questo scenario ogni server deve trovarsi in un'ubicazione fisica o logica differente. Ogni server deve essere in grado di comunicare con l'altro tramite una rete.
Molti di questi requisiti possono essere determinati mediante il Test-SRTopology cmdlet
. Se si installano le funzionalità Replica archiviazione o Strumenti di gestione di Replica archiviazione in almeno un server è possibile accedere a questo strumento. Non è necessario configurare Replica archiviazione perché usi questo strumento, ma è necessario installare il cmdlet. Altre informazioni sono incluse nei passaggi seguenti.
Requisiti di Windows Admin Center
Per usare replica di archiviazione e Windows Admin Center insieme, sono necessari gli elementi seguenti:
Sistema | Sistema operativo | Necessario per |
---|---|---|
Due server (qualsiasi combinazione di hardware, macchine virtuali e macchine virtuali cloud locali, incluse le macchine virtuali di Azure) |
Windows Server 2019, Windows Server 2016 o Windows Server (Canale semestrale) | Replica archiviazione |
Un PC | Windows 10 | Windows Admin Center |
Nota
Al momento non è possibile usare Windows Admin Center in un server per gestire Replica archiviazione.
Terms
Questa procedura dettagliata usa l'ambiente seguente come esempio:
Due server, denominati SR-SRV05 e SR SRV06.
Una coppia di "siti" logici che rappresentano due centri dati diversi, uno chiamato Redmond e l'altro Bellevue.
Figura 1: Replica da server a server
Passaggio 1: Installare e configurare Windows Admin Center nel PC
Se si usa Windows Admin Center per gestire Replica archiviazione, seguire questa procedura per preparare il PC per gestire Replica archiviazione.
Scaricare e installare Windows Admin Center.
Scaricare e installare gli strumenti di amministrazione remota del server.
- Se si usa Windows 10 versione 1809 o successiva, installare il modulo "RSAT: Replica di archiviazione per Windows PowerShell" da Funzionalità su richiesta.
Aprire una sessione di PowerShell come amministratore selezionando il pulsante Start, digitando PowerShell, facendo clic con il pulsante destro del mouse su Windows PowerShell e quindi selezionando Esegui come amministratore.
Immettere il comando seguente per abilitare il protocollo WS-Management nel computer locale e configurare la configurazione predefinita per la gestione remota nel client.
winrm quickconfig
Digitare Y per abilitare i servizi WinRM e abilitare l'eccezione del firewall WinRM.
Passaggio 2: effettuare il provisioning del sistema operativo, delle funzionalità, dei ruoli, dell'archiviazione e della rete
Installare Windows Server in entrambi i nodi del server con un tipo di installazione di Windows Server (Esperienza desktop).
Per usare una macchina virtuale di Azure connessa alla rete tramite ExpressRoute, vedere Aggiunta di una macchina virtuale di Azure connessa alla rete tramite ExpressRoute.
Nota
A partire da Windows Admin Center versione 1910, è possibile configurare automaticamente un server di destinazione in Azure. Se si sceglie questa opzione, installare Windows Server nel server di origine e quindi passare a Passaggio 3: configurare la replica da server a server.
Aggiungere informazioni di rete, aggiungere i server allo stesso dominio del PC di gestione di Windows 10 (se usato) e quindi riavviare i server.
Nota
Da questo momento, accedere sempre a tutti i server come utente di dominio, ovvero un membro del gruppo amministratore incorporato. Ricordarsi di elevare i prompt di PowerShell e CMD futuro durante l'esecuzione in un'installazione server con interfaccia grafica o in un computer Windows 10.
Collegare il primo set di alloggiamenti di archiviazione JBOD, la destinazione iSCSI, SAN FC o l'archiviazione su disco a dimensione fissa locale (DAS) server nel sito Redmond.
Collegare il secondo set di risorse di archiviazione ai server nel sito Bellevue.
Se necessario, installare il sistema di archiviazione del fornitore e il firmware dell'enclosure più recente, i driver HBA del fornitore più recenti, i firmware BIOS o UEFI del fornitore più recenti, i driver di rete del fornitore più recenti e driver dei chipset della scheda madre più recenti in entrambi i nodi. Se necessario riavviare i nodi.
Nota
Per la configurazione dell'archiviazione condivisa e dell'hardware di rete, consultare la documentazione del fornitore hardware.
Assicurarsi che le impostazioni BIOS/UEFI dei server abilitati consentano alte prestazioni, ad esempio la disabilitazione dei C-State, l'impostazione della velocità QPI, l'abilitazione di NUMA e l'impostazione della frequenza di memoria massima. Assicurarsi che il risparmio energia in Windows Server sia impostato su prestazioni elevate. Riavviare se necessario.
Configurare i ruoli come indicato di seguito:
Metodo di Windows Admin Center
- In Windows Admin Center passare a Server Manager e quindi selezionare uno dei server.
- Andare a Ruoli e funzionalità.
- Selezionare Funzionalità>Replica archiviazionee quindi fare clic su Installa.
- Ripetere l'operazione sull'altro server.
Metodo Server Manager
Eseguire ServerManager.exe e creare un gruppo di server aggiungendo tutti i nodi del server.
Installare i ruoli e le funzionalità File Server e Replica archiviazione in ciascuno dei nodi e riavviarli.
Metodo di Windows PowerShell
In un computer di gestione remota o SR-SRV06, eseguire il comando seguente nella console di Windows PowerShell per installare i ruoli e funzionalità necessarie e riavviarli:
$Servers = 'SR-SRV05','SR-SRV06' $Servers | ForEach { Install-WindowsFeature -ComputerName $_ -Name Storage-Replica,FS-FileServer -IncludeManagementTools -restart }
Per altre informazioni su questi passaggi, vedere Installazione o disinstallazione di ruoli, servizi ruolo o funzionalità
Configurare lo spazio di archiviazione come indicato di seguito:
Importante
- È necessario creare due volumi in ciascuna enclosure: uno per i dati e uno per i registri.
- I dischi di dati e registro devono essere inizializzati come GPT, non come MBR.
- I due volumi di dati devono avere le stesse dimensioni.
- I due volumi di registro devono avere le stesse dimensioni.
- Tutti i dischi di dati replicati devono avere le stesse dimensioni del settore.
- Tutti i dischi di registro devono avere le stesse dimensioni del settore.
- I volumi di registro devono usare un'archiviazione basata su flash, ad esempio le unità SSD. Microsoft consiglia di velocizzare l'archiviazione dei log rispetto all'archiviazione dei dati. I volumi di log non devono mai essere usati per altri carichi di lavoro.
- I dischi di dati possono usare HDD, SSD o una combinazione a più livelli e spazi con mirroring o di parità o RAID 1 o 10, oppure RAID 5 o RAID 50.
- Il volume di log deve essere di almeno 9 GB per impostazione predefinita e può essere superiore o inferiore in base ai requisiti del log.
- Il ruolo File Server è necessario solo per il funzionamento di Test-SRTopology, in quanto apre le porte del firewall necessarie per il test.
Per le enclosure JBOD:
Assicurarsi che ogni server possa visualizzare solo gli alloggiamenti di archiviazione del sito e che le connessioni SAS siano configurate correttamente.
Effettuare il provisioning dell'archiviazione mediante Spazi di archiviazione seguendo i passaggi 1-3 indicati in Distribuire Spazi di archiviazione in un server autonomo usando Windows PowerShell o Server Manager.
Per l'archiviazione iSCSI:
Verificare che ogni cluster sia in grado di visualizzare solo gli alloggiamenti di archiviazione di tale sito. Se si usa iSCSI, è necessario usare più di una singola scheda di rete.
Effettuare il provisioning dell'archiviazione usando la documentazione del fornitore. Se si usa la destinazione iSCSI basata su Windows, consultare iSCSI Target Block Storage, How To (Procedura per l'archiviazione a blocchi nella destinazione iSCSI).
Per l'archiviazione FC SAN:
Assicurarsi che ogni cluster sia in grado di vedere solo gli alloggiamenti di archiviazione di tale sito e che gli host siano stati suddivisi correttamente in zone.
Effettuare il provisioning dell'archiviazione usando la documentazione del fornitore.
Per l'archiviazione su disco fisso locale:
Verificare che l'archiviazione non contenga un volume di sistema, file di paging o file dump.
Effettuare il provisioning dell'archiviazione usando la documentazione del fornitore.
Avviare Windows PowerShell e usare il cmdlet Test-SRTopology per determinare se siano stati soddisfatti tutti i requisiti di Replica archiviazione. È possibile usare il cmdlet in modalità dedicata ai requisiti per un rapido test, oppure in modalità di valutazione delle prestazioni a esecuzione prolungata.
Ad esempio, per convalidare i nodi proposti che presentano un volume F: e G: ed eseguire il test per 30 minuti:
MD c:\temp Test-SRTopology -SourceComputerName SR-SRV05 -SourceVolumeName f: -SourceLogVolumeName g: -DestinationComputerName SR-SRV06 -DestinationVolumeName f: -DestinationLogVolumeName g: -DurationInMinutes 30 -ResultPath c:\temp
Importante
Quando si usa un server di prova privo di carichi di operazioni I/O di scrittura nel volume di origine specificato durante il periodo di valutazione, considerare l'aggiunta di un carico di lavoro o non verrà generato un report utile. È necessario eseguire il test con carichi di lavoro simili alla produzione per poter visualizzare i numeri reali e le dimensioni consigliate del registro. In alternativa, è sufficiente copiare alcuni file nel volume di origine durante il test o scaricare ed eseguire DISKSPD per generare operazioni di I/O di scrittura. Ad esempio, un campione con un carico di lavoro di I/O di scrittura basso per dieci minuti per il volume D: come mostrato di seguito:
Diskspd.exe -c1g -d600 -W5 -C5 -b8k -t2 -o2 -r -w5 -i100 -j100 d:\test
Esaminare il report testSrTopologyReport.html illustrato nella figura 2 per assicurarsi di soddisfare i requisiti della replica di archiviazione.
Figura 2: Report della topologia di replica di archiviazione
Passaggio 3: Configurare la replica da server a server
Uso di Windows Admin Center
Aggiungere il server di origine.
- Seleziona il pulsante Aggiungi.
- Selezionare Aggiungi connessione server.
- Digitare il nome del server e quindi selezionare Invia.
Nella pagina Tutte le connessioni selezionare il server di origine.
Selezionare Replica di archiviazione nel pannello Strumenti.
Selezionare Nuovo per creare una nuova partnership. Per creare una nuova macchina virtuale di Azure da usare come destinazione per la partnership:
- In Eseguire la replica con un altro server selezionare Usare una nuova macchina virtuale di Azure e quindi selezionare Avanti. Se questa opzione non viene visualizzata, assicurarsi di usare Windows Admin Center versione 1910 o successiva.
- Specificare le informazioni sul server di origine e il nome del gruppo di replica e quindi selezionare Avanti.
Viene avviato un processo che seleziona automaticamente una macchina virtuale di Azure di Windows Server 2019 o Windows Server 2016 come destinazione per l'origine della migrazione. Il Servizio di migrazione archiviazione consiglia le dimensioni delle macchine virtuali in modo che corrispondano all'origine, ma è possibile eseguire l'override selezionando Visualizzare tutte le dimensioni. I dati di inventario vengono usati per configurare automaticamente i dischi gestiti e i relativi file system, nonché aggiungere la nuova macchina virtuale di Azure al dominio di Active Directory. - Dopo che Windows Admin Center ha creato la macchina virtuale di Azure, specificare un nome del gruppo di replica e quindi selezionare Crea. Windows Admin Center avvia quindi il normale processo di sincronizzazione iniziale di Replica archiviazione per iniziare a proteggere i dati.
Ecco un video che illustra come usare la Replica di archiviazione per eseguire la migrazione in macchine virtuali di Azure.
Specificare i dettagli della partnership e quindi selezionare Crea (come illustrato nella figura 3).
Figura 3: Creazione di una nuova relazione
Nota
La rimozione della relazione da Replica di archiviazione in Windows Admin Center non rimuove il nome del gruppo di replica.
Tramite Windows PowerShell
Ora è necessario configurare la replica da server a server con PowerShell. Tutti i passaggi seguenti possono essere eseguiti sui nodi direttamente oppure da un computer di gestione remota che contiene gli strumenti di amministrazione remota del server di Windows Server.
Assicurarsi di usare una console di PowerShell con privilegi elevati in qualità di amministratore.
Configurare la replica da server a server, specificando i dischi di origine e di destinazione, i registri di origine e di destinazione, i nodi di origine e di destinazione e le dimensioni del registro.
New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName f: -SourceLogVolumeName g: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName f: -DestinationLogVolumeName g: -LogType Raw
Output:
DestinationComputerName : SR-SRV06 DestinationRGName : rg02 SourceComputerName : SR-SRV05 PSComputerName :
Importante
La dimensione predefinita del registro è 8 GB. In base ai risultati del cmdlet
Test-SRTopology
, è possibile decidere di usare - LogSizeInBytes con un valore superiore o inferiore.Per ottenere lo stato di origine e destinazione della replica, usare
Get-SRGroup
eGet-SRPartnership
come indicato di seguito:Get-SRGroup Get-SRPartnership (Get-SRGroup).replicas
Output:
CurrentLsn : 0 DataVolume : F:\ LastInSyncTime : LastKnownPrimaryLsn : 1 LastOutOfSyncTime : NumOfBytesRecovered : 37731958784 NumOfBytesRemaining : 30851203072 PartitionId : c3999f10-dbc9-4a8e-8f9c-dd2ee6ef3e9f PartitionSize : 68583161856 ReplicationMode : synchronous ReplicationStatus : InitialBlockCopy PSComputerName :
Determinare lo stato della replica come indicato di seguito:
Nel server di origine eseguire il comando seguente, quindi esaminare gli eventi 5015, 5002, 5004, 1237, 5001 e 2200:
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica -max 20
Nel server di destinazione, eseguire il comando seguente per visualizzare gli eventi di Replica archiviazione che mostrano la creazione della relazione. Questo evento indica il numero di byte copiati e il tempo impiegato. Esempio
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica | Where-Object {$_.ID -eq "1215"} | fl
Ecco un esempio di output:
TimeCreated : 4/8/2016 4:12:37 PM ProviderName : Microsoft-Windows-StorageReplica Id : 1215 Message : Block copy completed for replica. ReplicationGroupName: rg02 ReplicationGroupId: {616F1E00-5A68-4447-830F-B0B0EFBD359C} ReplicaName: f:\ ReplicaId: {00000000-0000-0000-0000-000000000000} End LSN in bitmap: LogGeneration: {00000000-0000-0000-0000-000000000000} LogFileId: 0 CLSFLsn: 0xFFFFFFFF Number of Bytes Recovered: 68583161856 Elapsed Time (ms): 117
Nota
Replica archiviazione smonta i volumi di destinazione e i relativi punti di montaggio o lettere dell'unità. Questo si verifica per motivi strutturali.
In alternativa, il gruppo del server di destinazione per la replica indica in qualsiasi momento il numero di byte rimanenti da copiare, inoltre è possibile eseguire query tramite PowerShell. Ad esempio:
(Get-SRGroup).Replicas | Select-Object numofbytesremaining
Come esempio dello stato di avanzamento (che non terminerà):
while($true) { $v = (Get-SRGroup -Name "RG02").replicas | Select-Object numofbytesremaining [System.Console]::Write("Number of bytes remaining: {0}`r", $v.numofbytesremaining) Start-Sleep -s 5 }
Nel server di destinazione, eseguire il comando seguente ed esaminare gli eventi 5009, 1237, 5001, 5015, 5005 e 2200 per comprendere lo stato di avanzamento dell'elaborazione. Non dovrebbe essere presente alcun avviso di errori in questa sequenza. Ci saranno molti eventi 1237, perché questi indicano lo stato di avanzamento.
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica | FL
Passaggio 4: gestire la replica
Ora, proseguire con la gestione e l'uso dell'infrastruttura replicata da server a server. Tutti i passaggi seguenti possono essere eseguiti sui nodi direttamente oppure da un computer di gestione remota che contiene gli strumenti di amministrazione remota del server di Windows Server.
Usare
Get-SRPartnership
eGet-SRGroup
per determinare l'origine e la destinazione di replica attuale e il relativo stato.Per misurare le prestazioni della replica, usare il cmdlet
Get-Counter
nei nodi di origine e di destinazione. I nomi dei contatori sono:\Statistiche I/O partizione Replica archiviazione(*)\Numero di sospensioni scaricamento
\Statistiche I/O partizione Replica archiviazione(*)\Numero di I/O in attesa di scaricamento
\Statistiche I/O partizione Replica archiviazione(*)\Numero richieste ultima scrittura log
\Statistiche I/O partizione Replica archiviazione(*)\ Lunghezza media coda scaricamento
\Statistiche I/O partizione Replica archiviazione(*)\Lunghezza coda scaricamento corrente
\Statistiche I/O partizione Replica archiviazione(*)\Numero richieste scrittura applicazione
\Statistiche I/O partizione Replica archiviazione(*)\ Numero medio di richieste per scrittura di log
\Statistiche I/O partizione Replica archiviazione(*)\ Latenza media scrittura app
\Statistiche I/O partizione Replica archiviazione(*)\ Latenza media lettura app
\Statistiche Replica archiviazione(*)\RPO destinazione
\Statistiche Replica archiviazione(*)\RPO corrente
\Statistiche Replica archiviazione(*)\ Lunghezza media coda log
\Statistiche Replica archiviazione(*)\Lunghezza coda log corrente
\Statistiche Replica archiviazione(*)\Totale byte ricevuti
\Statistiche Replica archiviazione(*)\Totale byte inviati
\Statistiche Replica archiviazione(*)\ Latenza media invio rete
\Statistiche Replica archiviazione(*)\Stato replica
\Statistiche Replica archiviazione(*)\ Latenza media round trip messaggio
\Statistiche Replica archiviazione\Tempo trascorso ultimo ripristino
\Statistiche Replica archiviazione(*)\Numero di transazioni di ripristino scaricate
\Statistiche Replica archiviazione(*)\Numero di transazioni di ripristino
\Statistiche Replica archiviazione(*)\Numero di transazioni di replica scaricate
\Statistiche Replica archiviazione(*)\Numero di transazioni di replica
\Statistiche Replica archiviazione(*)\Quantità massima di numeri di sequenza del file di log
\Statistiche Replica archiviazione(*)\Numero di messaggi ricevuti
\Statistiche Replica archiviazione(*)\Numero di messaggi inviati
Per altre informazioni sui contatori delle prestazioni in Windows PowerShell, vedere Get-Counter.
Per spostare la direzione di replica da un sito, usare il cmdlet
Set-SRPartnership
.Set-SRPartnership -NewSourceComputerName sr-srv06 -SourceRGName rg02 -DestinationComputerName sr-srv05 -DestinationRGName rg01
Avviso
Windows Server impedisce il cambio di ruolo durante la sincronizzazione iniziale, ma questa operazione può causare la perdita di dati se si prova a effettuare il cambio prima del completamento della replica iniziale. Non forzare il cambio delle direzioni fino al completamento della sincronizzazione iniziale.
Controllare i registri eventi per visualizzare la direzione della modalità di modifica e ripristino della replica e quindi risolvere le differenze. Le operazioni di I/O di scrittura possono essere effettuate nell'archiviazione di proprietà nel nuovo server di origine. La modifica la direzione di replica blocca le operazioni di I/O di scrittura nel computer di origine precedente.
Per rimuovere la replica, usare
Get-SRGroup
,Get-SRPartnership
,Remove-SRGroup
eRemove-SRPartnership
su ciascun nodo. Assicurarsi di eseguire il cmdletRemove-SRPartnership
solo sull'origine della replica corrente, non nel server di destinazione. EseguireRemove-SRGroup
su entrambi i server. Ad esempio, per rimuovere completamente la replica dai due server:Get-SRPartnership Get-SRPartnership | Remove-SRPartnership Get-SRGroup | Remove-SRGroup
Sostituzione di Replica DFS con Replica archiviazione
Molti clienti Microsoft distribuiscono Replica DFS come soluzione di ripristino di emergenza per i dati utente non strutturati, come home directory e condivisioni di reparto. Replica DFS è disponibile in Windows Server 2003 R2 e in tutti i sistemi operativi successivi e opera su reti a larghezza di banda ridotta. Risulta quindi interessante per gli ambienti di modifica a bassa e alta latenza con più nodi. Come soluzione di replica dei dati, tuttavia, Replica DFS presenta limitazioni significative:
- Non replica file in uso o aperti.
- Non viene replicato in modo sincrono.
- La latenza di replica asincrona può durare molti minuti, ore o persino giorni.
- Si basa su un database che può richiedere verifiche di coerenza di lunga durata dopo un'interruzione dell'alimentazione.
- Viene in genere configurata come multimaster che consente di apportare modifiche al flusso in entrambe le direzioni, eventualmente sovrascrivendo i dati più recenti.
Replica archiviazione non presenta alcuna di queste limitazioni. Tuttavia, presenta diversi problemi che potrebbero renderla meno interessante in alcuni ambienti:
- Consente solo la replica uno a uno tra i volumi. È possibile replicare volumi diversi tra più server.
- Se da un lato supporta la replica asincrona, dall'altro non è stata progettata per le reti a latenza elevata e a larghezza di banda ridotta.
- Non consente l'accesso ai dati protetti nella destinazione durante l'esecuzione della replica
Se questi fattori non rappresentano un limite, Replica di archiviazione consente di sostituire i server di Replica DFS con questa tecnologia più recente. Il processo è così suddiviso a un livello elevato:
Installare Windows Server in due server e configurare l'archiviazione. Questo potrebbe comportare l'aggiornamento di un set esistente di server o la relativa installazione.
Verificare l'esistenza di tutti i dati che si desidera replicare in uno o più volumi di dati e non sull'unità C:. a. È inoltre possibile effettuare il seeding dei dati sull'altro server per risparmiare tempo usando un backup o copie del file, oppure sfruttare l'archiviazione con thin provisioning. A differenza di Replica DFS, non è necessario che la sicurezza analoga a quella dei metadati corrisponda perfettamente.
Condividere i dati nel server di origine e renderli accessibili tramite uno spazio dei nomi DFS. Questa azione è importante per garantire che gli utenti possano comunque accedervi se il nome del server viene modificato in un sito di emergenza. a. È possibile creare condivisioni corrispondenti nel server di destinazione, che non sarà disponibile durante le normali operazioni, b. Non aggiungere il server di destinazione allo spazio dei nomi DFS oppure, se si esegue tale operazione, verificare che tutte le destinazioni cartella siano disabilitate.
Abilitare la replica di Replica archiviazione e completare la sincronizzazione iniziale. La replica può essere sincrona o asincrona. a. Tuttavia, è consigliabile la replica sincrona per garantire la coerenza dei dati di I/O nel server di destinazione. b. È consigliabile abilitare il servizio Copia Shadow del volume ed eseguire periodicamente gli snapshot con VSSADMIN o altri strumenti. Ciò garantisce che le applicazioni scarichino i propri file di dati su disco in modo coerente. In caso di emergenza, è possibile ripristinare i file dagli snapshot nel server di destinazione che potrebbe essere stato parzialmente replicato in modo asincrono. Gli snapshot vengono replicati insieme ai file.
Usare normalmente fino a quando non si verifica una situazione di emergenza.
Fare in modo che il server di destinazione diventi la nuova origine, la quale riflette i volumi replicati agli utenti.
Se si usa la replica sincrona, il ripristino dei dati non sarà necessario a meno che l'utente non stia usando un'applicazione che sta scrivendo i dati senza la protezione delle transazioni, indipendentemente dalla replica, durante la perdita del server di origine. Se si usa la replica asincrona la necessità di un montaggio snapshot VSS sarà maggiore, ma è consigliabile usare VSS in tutte le circostanze per gli snapshot coerenti con l'applicazione.
Aggiungere il server e le sue azioni come destinazione cartella spazio dei nomi DFS.
Gli utenti possono quindi accedere ai dati.
Nota
La pianificazione del ripristino di emergenza è un argomento complesso e che richiede particolare attenzione ai dettagli. È consigliabile creare runbook ed eseguire annualmente le esercitazioni di failover in tempo reale. Quando si verifica un'emergenza effettiva, regnerà il caos e il personale esperto potrebbe non essere disponibile.
Aggiunta di una macchina virtuale di Azure connessa alla rete tramite ExpressRoute
Creare un'istanza di ExpressRoute nel portale di Azure.
Dopo l'approvazione di ExpressRoute, alla sottoscrizione viene aggiunto un gruppo di risorse. Passare a Gruppi di risorse per visualizzare questo nuovo gruppo. Prendere nota del nome della rete virtuale.Figura 4: Le risorse associate a un ExpressRoute, prendere nota del nome della rete virtuale
Aggiungere un gruppo di sicurezza di rete. Durante la creazione, selezionare l'ID sottoscrizione associato a ExpressRoute creato e selezionare anche il gruppo di risorse appena creato.
Aggiungere le regole di sicurezza in ingresso e in uscita necessarie al gruppo di sicurezza di rete. Ad esempio, potrebbe essere necessario consentire l'accesso Desktop remoto alla macchina virtuale.Creare una macchina virtuale di Azure con le impostazioni seguenti (illustrata nella figura 5):
- Indirizzo IP pubblico: nessuno
- Rete virtuale: selezionare la rete virtuale di cui si è preso nota dal gruppo di risorse aggiunto con ExpressRoute.
- Gruppo di sicurezza di rete (firewall): selezionare il gruppo di sicurezza di rete creato in precedenza. Figura 5: Creazione di una macchina virtuale durante la selezione delle impostazioni di rete di ExpressRoute
Dopo aver creato la macchina virtuale, vedere Passaggio 2: effettuare il provisioning del sistema operativo, delle funzionalità, dei ruoli, dell'archiviazione e della rete.