Affidabilità in Spostamento archiviazione di Azure

Questo articolo descrive il supporto per l'affidabilità in Archiviazione di Azure Mover e illustra sia la resilienza all'interno dell'area con le zone di disponibilità che il ripristino di emergenza tra aree e la continuità aziendale. Per una panoramica più dettagliata dei principi di affidabilità in Azure, vedere affidabilità di Azure.

Supporto della zona di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di ogni area di Azure. In caso di errore di una zona, i servizi possono eseguire il failover in una delle zone rimanenti.

Per altre informazioni sulle zone di disponibilità in Azure, vedere Che cosa sono le zone di disponibilità?

Archiviazione di Azure Mover supporta un modello di distribuzione con ridondanza della zona.

Quando si distribuisce una risorsa Archiviazione di Azure Mover, è necessario selezionare una determinata area in cui vengono archiviati i metadati dell'istanza della risorsa.

Se l'area supporta le zone di disponibilità, i metadati dell'istanza vengono replicati automaticamente in più zone di disponibilità all'interno di tale area.

Importante

Archiviazione di Azure metadati dell'istanza di Mover includono progetti, endpoint, agenti, definizioni dei processi e cronologia di esecuzione dei processi, ma non include i dati effettivi di cui eseguire la migrazione. Gli account di archiviazione di Azure usati come destinazioni di migrazione hanno il proprio supporto per l'affidabilità.

Prerequisiti

• Per eseguire la distribuzione con il supporto della zona di disponibilità, è necessario scegliere un'area che supporti le zone di disponibilità. Per visualizzare le aree che supportano le zone di disponibilità, vedere l'elenco delle aree supportate.

• (Facoltativo) Se l'account di archiviazione di destinazione non supporta le zone di disponibilità e si vuole eseguire la migrazione dell'account al supporto az, vedere Eseguire la migrazione degli account Archiviazione di Azure al supporto della zona di disponibilità.

Esperienza di inattività della zona

Durante un'interruzione a livello di zona non è necessaria alcuna azione durante il ripristino della zona. Archiviazione di Azure Mover è progettato per auto-guarire e ri-bilanciare se stesso per sfruttare automaticamente la zona sana.

Qualsiasi account di archiviazione di destinazione della migrazione può richiedere i propri passaggi di ripristino. Questo requisito dipende dalle opzioni di ridondanza scelte per ogni account di archiviazione. Vedere la guida al ripristino di emergenza dell'account di archiviazione per determinare se sono necessari altri passaggi.

Se è stata scelta una risorsa di archiviazione locale al posto delle opzioni di ridondanza, potrebbe essere necessario creare un nuovo account di archiviazione da usare nelle migrazioni durante l'interruzione.

Ripristino di emergenza e continuità aziendale tra aree

Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.

Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per questi servizi, si è responsabili della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il piano di ripristino di emergenza.

Quando viene registrato un agente di Spostamento archiviazione, si connette all'area in cui è registrata la risorsa di Spostamento archiviazione. Se si verifica un'interruzione dell'area di Azure di un agente, l'agente stesso non è interessato, ma le operazioni di gestione che si basano su Azure potrebbero non essere in grado di completare. Inoltre, eventuali migrazioni di dati attive agli account di archiviazione che si trovano all'interno dell'area interessata potrebbero non riuscire.

Storage Mover supporta due forme di ripristino di emergenza:

• Ripristino di emergenza avviato da Azure
• Ripristino di emergenza avviato dal cliente

Importante

Il ripristino di emergenza per le origini dati locali è responsabilità del cliente.

Ripristino di emergenza avviato da Azure

Il ripristino di emergenza avviato da Azure è applicabile solo alle aree con coppie di aree. Quando viene usata la replica tra aree, i metadati dell'istanza vengono replicati in ogni area, ma non è mai consentito lasciare l'area geografica.

Archiviazione di Azure Mover usa Cosmos DB per archiviare i metadati dell'istanza. La perdita di dati può verificarsi solo con un'emergenza irreversibile in Azure Cosmos DB. Per altre informazioni vedere Interruzioni dell'area. Il ripristino avviato da Azure è attivo-passivo e il ripristino completo di un'area può richiedere fino a 24 ore.

Ripristino di emergenza avviato dal cliente

Il ripristino di emergenza avviato dal cliente non è limitato alle aree abbinate.

Prima che si verifichi un'interruzione a livello di area:

• Distribuire uno spostamento di archiviazione con ridondanza della zona creando risorse di Storage Mover in un'area che supporta le zone di disponibilità.

• Periodicamente, in base a una pianificazione o dopo aver apportato modifiche sostanziali, creare uno snapshot delle risorse di Storage Mover. L'archiviazione degli snapshot tramite un sistema di controllo della versione è un buon modo per archiviare e tenere traccia della cronologia degli snapshot. Si userà l'ultimo snapshot valido in caso di emergenza in cui è necessario ripristinare le risorse in una nuova area.

Durante un'interruzione a livello di area:

È possibile eseguire una delle due operazioni seguenti:

• Scegliere di attendere che Azure ripristini l'area.
• Ridurre al minimo i tempi di inattività ridistribuendo le risorse in un'area diversa. Poiché l'accesso alle risorse potrebbe essere interessato durante un'interruzione, è consigliabile usare l'ultimo snapshot valido delle risorse.

Suggerimento

Una di queste strategie potrebbe comunque richiedere ulteriori passaggi prima di un'emergenza, quindi assicurarsi di rivedere e pianificare di conseguenza.

Distribuire le risorse in un'area diversa

Vedere la documentazione sull'esportazione dei modelli per altre istruzioni sull'esportazione delle risorse come modello di Azure Resource Manager (ARM).

Se lo spostamento archiviazione e le risorse correlate risiedono in un contenitore senza risorse aggiuntive, è necessario eseguire un'esportazione del gruppo di risorse per acquisire lo stato corrente. Tuttavia, se il gruppo di risorse contiene risorse non correlate, potrebbe essere necessario rimuovere o escludere in altro modo le risorse dal modello.

Gli agenti esistenti non possono essere ridistribuiti in un'area diversa. Se l'area in cui sono state originariamente configurate si verifica un'interruzione, potrebbe non essere possibile annullare completamente la registrazione e registrare nuovamente l'agente. Questo documento presuppone che i nuovi agenti siano registrati all'interno di una nuova area.

Per usare il modello esportato per il ripristino di emergenza, sono necessarie alcune modifiche al modello.

• Rimuovere prima di tutto le Microsoft.StorageMover/agents risorse e Microsoft.HybridCompute/machines dal modello. Assicurarsi di rimuovere anche i riferimenti alle dipendenze a queste risorse.
• Rimuovere quindi la agentResourceId proprietà da tutte le definizioni di processo. Sarà necessario assegnarli a un nuovo agente dopo la distribuzione.
• Dopo aver rimosso tutti i riferimenti alle risorse del computer di calcolo ibrido e dell'agente, aggiornare la proprietà location della risorsa di spostamento archiviazione di primo livello. Sostituire il nome dell'area attualmente distribuita con il nome della nuova area.
• Determinare infine se mantenere l'ID risorsa dell'account di archiviazione esistente. Se necessario, sostituirlo con un account di archiviazione diverso.

Dopo aver completato i passaggi precedenti e aver verificato che i parametri del modello siano corretti, il modello è pronto per la distribuzione in una nuova area. È necessario distribuire il modello in un nuovo gruppo di risorse con la stessa area predefinita della proprietà location nel modello.

Registrazione del nuovo agente

Seguire la procedura descritta nell'articolo Distribuire un agente Archiviazione di Azure Mover per registrare un nuovo agente nella nuova risorsa di spostamento archiviazione.

Assegnazione dell'agente alle definizioni di processo

Dopo che il nuovo agente è stato registrato e segnalato come online, usare il portale di Azure o PowerShell per associare le definizioni di processo esistenti al nuovo agente. Per praticità, viene fornito l'esempio di PowerShell seguente.

Per indicazioni su come accedere alle definizioni dei processi per il progetto, vedere definire un nuovo processo di migrazione .

## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

Concessione dell'accesso dell'agente al contenitore di archiviazione di destinazione

Per eseguire correttamente un processo di migrazione, è necessario assegnare il ruolo collaboratore ai dati all'identità gestita. Assegnare all'identità gestita del sistema della risorsa di calcolo ibrido l'accesso alla risorsa dell'account di archiviazione di destinazione. L'articolo assegnare un'identità gestita a una risorsa fornisce indicazioni su come concedere l'accesso alla risorsa di destinazione.

A questo punto è possibile avviare i processi di migrazione usando le risorse di Storage Mover appena distribuite.

Passaggi successivi

• Affidabilità in Azure
• Ripristino di emergenza dell'account di archiviazione