Exchange Online resilienza dei dati in Microsoft 365

  • Articolo

Importante

Mentre continuiamo a investire in modi diversi per conservare il contenuto delle cassette postali, annunciamo il ritiro dei blocchi In-Place nell'interfaccia di amministrazione di Exchange in Exchange Online. A partire dal 1° luglio 2020, non sarà possibile creare nuovi blocchi In-Place. Sarà comunque possibile gestire In-Place blocchi nell'interfaccia di amministrazione di Exchange o usando il cmdlet Set-MailboxSearch in Exchange Online PowerShell. Tuttavia, a partire dal 1° ottobre 2020, non sarà possibile gestire In-Place blocchi. Sarà possibile rimuoverli solo nell'interfaccia di amministrazione di Exchange o usando il cmdlet Remove-MailboxSearch . L'uso di In-Place blocchi nelle distribuzioni ibride di Exchange Server ed Exchange continuerà a essere supportato. Per altre informazioni sul ritiro dei blocchi In-Place in Exchange Online, vedere Ritiro degli strumenti legacy di eDiscovery.

Un blocco In-Place mantiene tutto il contenuto delle cassette postali, inclusi gli elementi eliminati e le versioni originali degli elementi modificati. Tutti questi elementi delle cassette postali vengono restituiti in una ricerca di eDiscovery in locale. Quando si inserisce un blocco In-Place nella cassetta postale di un utente, anche il contenuto nella cassetta postale di archiviazione corrispondente (se abilitata) viene messo in attesa e restituito in una ricerca di eDiscovery.

Esistono due tipi di danneggiamento che possono influire su un database di Exchange: il danneggiamento fisico, che è in genere causato da problemi hardware (in particolare hardware di archiviazione) e il danneggiamento logico, che si verifica a causa di altri fattori. In genere, all'interno di un database di Exchange possono verificarsi due tipi di danneggiamento logico:

  • Danneggiamento logico del database: corrisponde al checksum della pagina del database, ma i dati nella pagina non sono logici. Ciò può verificarsi quando il motore di database (ESE (Extensible Storage Engine) tenta di scrivere una pagina di database e, anche se il sistema operativo restituisce un messaggio di esito positivo, i dati non vengono mai scritti sul disco o scritti nella posizione errata. Questo viene definito rilevamento flush. ESE include numerose funzionalità e misure di sicurezza progettate per prevenire il danneggiamento fisico di un database e altri scenari di perdita di dati. Per evitare che gli scaricamenti persi perdano dati, ESE include un meccanismo di rilevamento dello scaricamento perso nel database insieme a una funzionalità (ripristino a pagina singola) per correggerli.
  • Danneggiamento logico dell'archivio: i dati vengono aggiunti, eliminati o modificati in modo non previsto dall'utente. Questi casi sono causati da applicazioni di terze parti. In genere si tratta di un danneggiamento nel senso che l'utente lo considera come danneggiamento. L'archivio di Exchange considera la transazione che ha causato il danneggiamento della partizione logica come una serie di operazioni MAPI valide. Le funzionalità di blocco sul posto in Exchange Online offrono protezione dal danneggiamento logico dell'archivio (perché impedisce l'eliminazione definitiva del contenuto da parte di un utente o di un'applicazione).

Exchange Online esegue diversi controlli di coerenza sui file di log replicati durante l'ispezione del log e la riproduzione del log. Questi controlli di coerenza impediscono la replica del danneggiamento fisico da parte del sistema. Ad esempio, durante l'ispezione del log, viene eseguito un controllo dell'integrità fisica che verifica il file di log e verifica che il checksum registrato nel file di log corrisponda al checksum generato in memoria. Viene inoltre esaminata l'intestazione del file di log per assicurarsi che la firma del file di log registrata nell'intestazione del log corrisponda a quella del file di log. Durante la riesecuzione del log, il file di log viene sottoposto a un ulteriore esame. Ad esempio, l'intestazione del database contiene anche la firma del log confrontata con la firma del file di log per assicurarsi che corrispondano.

La protezione dal danneggiamento dei dati delle cassette postali in Exchange Online viene ottenuta usando Exchange Native Data Protection, una strategia di resilienza che sfrutta la replica a livello di applicazione tra più server e più data center insieme ad altre funzionalità che consentono di proteggere i dati dalla perdita a causa di danneggiamenti o altri motivi. Queste funzionalità includono funzionalità native gestite da Microsoft o dall'applicazione Exchange Online stessa, ad esempio:

  • Gruppi di disponibilità dati
  • Correzione a bit singolo
  • Analisi del database online
  • Rilevamento scaricamento perso
  • Ripristino a pagina singola
  • Servizio replica cassette postali
  • Controlli file di log
  • Distribuzione nel file system resiliente

Per altre informazioni sulle funzionalità native elencate in precedenza, selezionare i collegamenti ipertestuali e vedere quanto segue per altre informazioni e per informazioni dettagliate sugli elementi senza collegamenti ipertestuali. Oltre a queste funzionalità native, Exchange Online include anche funzionalità di resilienza dei dati che i clienti possono gestire, ad esempio:

Gruppi di disponibilità del database

Ogni database delle cassette postali in Microsoft 365 è ospitato in un gruppo di disponibilità del database (DAG) e replicato in data center geograficamente separati all'interno della stessa area. La configurazione più comune è quattro copie di database in quattro data center; tuttavia, alcune aree hanno meno data center (i database vengono replicati in tre data center in India e due data center in Australia e Giappone). In tutti i casi, tuttavia, ogni database delle cassette postali dispone di quattro copie distribuite tra più data center, assicurando in tal modo che i dati delle cassette postali siano protetti da errori software, hardware e persino di data center.

Di queste quattro copie, tre di esse sono configurate come a disponibilità elevata. La quarta copia viene configurata come copia di database ritardata. La copia ritardata del database non è destinata al ripristino di singole cassette postali o al ripristino degli elementi della cassetta postale. Il suo scopo è fornire un meccanismo di ripristino per il raro evento di danneggiamento logico catastrofico a livello di sistema.

Le copie di database in ritardo in Exchange Online sono configurate con un ritardo di riproduzione del file di log di sette giorni. Inoltre, Gestione ritardo riesecuzione di Exchange è abilitato per fornire il riproduzione dinamica del file di log per le copie in ritardo per consentire alle copie ritardate del database di autoriparazione e gestire l'aumento dei file di log. Anche se le copie di database in ritardo vengono usate in Exchange Online, è importante comprendere che non si tratta di un backup temporizzato garantito. Le copie di database in ritardo in Exchange Online hanno una soglia di disponibilità, in genere intorno al 90%, a causa dei periodi in cui il disco contenente una copia ritardata viene perso a causa di un errore del disco, la copia ritardata diventa una copia a disponibilità elevata (a causa del play-down automatico), nonché i periodi in cui la copia ritardata del database ricompila la coda di riesecuzione del log.

Resilienza del trasporto

Exchange Online include due funzionalità principali di resilienza del trasporto: Ridondanza shadow e Rete di sicurezza. La ridondanza shadow mantiene una copia ridondante di un messaggio mentre è in transito. Safety Net mantiene una copia ridondante di un messaggio dopo che il messaggio è stato recapitato correttamente.

Con ridondanza shadow, ogni server di trasporto Exchange Online crea una copia di ogni messaggio ricevuto prima di confermare la ricezione del messaggio al server di invio. In questo modo tutti i messaggi nella pipeline di trasporto vengono ridondanti durante il transito. Se Exchange Online determina che il messaggio originale è stato perso durante il transito, una copia ridondante del messaggio viene rivisiata.

Safety Net è una coda di trasporto associata al servizio Trasporto in un server Cassette postali. Questa coda archivia copie dei messaggi elaborati correttamente dal server. Quando un errore del server o del database delle cassette postali richiede l'attivazione di una copia non aggiornata del database delle cassette postali, i messaggi nella coda safety net vengono inviati automaticamente alla nuova copia attiva del database delle cassette postali. Anche Safety Net è ridondante, eliminando così il trasporto come singolo punto di guasto. Usa il concetto di rete di sicurezza primaria e di rete di sicurezza shadow in cui, se la rete di sicurezza primaria non è disponibile per più di 12 ore, le richieste di nuovo invio diventano richieste di reinvio shadow e i messaggi vengono recapitati dalla rete di sicurezza shadow.

Le reinvie di messaggi da Safety Net vengono avviate automaticamente dal componente Active Manager del servizio Replica di Microsoft Exchange che gestisce i gruppi di disponibilità del database e le copie del database delle cassette postali. Non sono necessarie azioni manuali per inviare di nuovo i messaggi da Safety Net.

Correzione a bit singolo

ESE include un meccanismo per rilevare e risolvere gli errori CRC a bit singolo (noti anche come capovolgimenti a bit singolo) che sono il risultato di errori hardware (e di conseguenza rappresentano il danneggiamento fisico). Quando si verificano questi errori, ESE li corregge automaticamente e registra un evento nel registro eventi.

Analisi del database online

L'analisi online del database (nota anche come riepilogo del controllo del database) è il processo in cui un ESE usa un controllo di coerenza del database per leggere ogni pagina e verificare il danneggiamento della pagina. Lo scopo principale è rilevare il danneggiamento fisico e gli scaricamenti persi che potrebbero non essere rilevati dalle operazioni transazionali. L'analisi del database esegue anche operazioni di arresto anomalo dopo l'archiviazione. Lo spazio può essere perso a causa di arresti anomali e l'analisi del database online trova e recupera lo spazio perso. Il sistema è progettato con l'aspettativa che ogni database venga completamente analizzato una volta ogni sette giorni.

Rilevamento scaricamento perso

Uno scaricamento perso si verifica quando un'operazione di scrittura del database restituita dal sottosistema/sistema operativo del disco come completato non è stata effettivamente scritta su disco o è stata scritta nel percorso errato. Gli eventi imprevisti di scaricamento persi possono causare il danneggiamento logico del database, quindi per evitare che gli scaricamenti persi possano causare la perdita di dati, ESE include un meccanismo di rilevamento dello scaricamento perso. Quando le pagine di database vengono scritte in copie passive, viene eseguito un controllo per gli scaricamenti persi nella copia attiva. Se viene rilevato uno scaricamento perso, ESE può ripristinare il processo usando un processo di applicazione di patch di pagina.

Ripristino a pagina singola

Il ripristino a pagina singola, noto anche come applicazione di patch di pagina, è un processo automatico in cui le pagine di database danneggiate vengono sostituite da copie integre da una replica integra. Il processo di ripristino per una pagina danneggiata dipende dal fatto che la copia del database sia attiva o passiva. Quando una copia di database attiva rileva una pagina danneggiata, può copiare una pagina da una delle relative repliche, a condizione che la pagina copiata sia aggiornata. Questo processo viene eseguito inserendo una richiesta per la pagina nel flusso di log, che è la base della replica del database delle cassette postali. Non appena una replica rileva la richiesta di pagina, risponde inviando una copia della pagina alla copia del database richiedente. Il ripristino a pagina singola fornisce anche un meccanismo di comunicazione asincrono per consentire all'oggetto attivo di richiedere una pagina dalle repliche, anche se le repliche sono attualmente offline.

In caso di danneggiamento in una copia passiva del database, inclusa una copia ritardata del database, poiché queste copie sono sempre dietro la copia attiva, è sempre sicuro copiare qualsiasi pagina dalla copia attiva a una copia passiva. Una copia passiva del database è per natura a disponibilità elevata, quindi durante il processo di applicazione di patch alla pagina la riproduzione dei log viene sospesa, ma la copia del log continua. La copia passiva del database recupera una copia della pagina danneggiata dalla copia attiva, attende fino a quando il file di log che soddisfa il requisito massimo di generazione del log richiesto viene copiato e controllato e quindi applica patch alla pagina danneggiata. Dopo che la pagina è stata applicata una patch, la riesecuzione dei log riprende. Il processo è lo stesso per la copia ritardata del database, ad eccezione del fatto che il database in ritardo riproduce per la prima volta tutti i file di log necessari per ottenere uno stato patchable.

Servizio replica cassette postali

Lo spostamento delle cassette postali è una parte fondamentale della gestione di un servizio di posta elettronica su larga scala. Sono sempre disponibili tecnologie e aggiornamenti hardware e delle versioni sempre aggiornati, quindi avere un sistema solido e limitato che consenta ai nostri ingegneri di eseguire questo lavoro mantenendo la cassetta postale trasparente per gli utenti (assicurandosi che rimangano online durante tutto il processo) è fondamentale e assicurandosi che il processo aumenti normalmente man mano che le cassette postali diventano sempre più grandi.

Il servizio replica cassette postali di Exchange (MRS) è responsabile dello spostamento di cassette postali tra database. Durante lo spostamento, MRS esegue un controllo di coerenza su tutti gli elementi all'interno della cassetta postale. Se viene rilevato un problema di coerenza, MRS correggerà il problema o ignorerà gli elementi danneggiati, rimuovendo così il danneggiamento dalla cassetta postale.

Poiché MRS è un componente di Exchange Online, è possibile apportare modifiche al codice per risolvere le nuove forme di danneggiamento rilevate in futuro. Ad esempio, se si rileva un problema di coerenza che MRS non è in grado di risolvere, è possibile analizzare il danneggiamento, modificare il codice MRS e correggere l'incoerenza (se si capisce come farlo).

Controlli file di log

Tutti i file di log delle transazioni generati da un database di Exchange vengono sottoposti a diverse forme di controlli di coerenza. Quando viene creato un file di log, viene scritto un modello di bit e quindi viene eseguita una serie di scritture di log. Questa struttura consente Exchange Online di eseguire una serie di controlli (scaricamento perso, CRC e altri controlli) per convalidare ogni file di log durante la scrittura e di nuovo durante la replica.

Distribuzione nel file system resiliente

Per evitare che si verifichino danneggiamenti a livello di file system, Exchange Online viene distribuito nelle partizioni ReFS (Resilient File System) per offrire funzionalità di ripristino migliorate. ReFS è un file system in Windows Server 2012 e versioni successive progettato per essere più resiliente al danneggiamento dei dati, ottimizzando così la disponibilità e l'integrità dei dati. In particolare, ReFS introduce miglioramenti nel modo in cui vengono aggiornati i metadati, che offre una migliore protezione per i dati e riduce i casi di danneggiamento dei dati. Usa anche i checksum per verificare l'integrità dei dati e dei metadati dei file, garantendo che il danneggiamento dei dati sia facilmente individuabile e riparato.

Exchange Online sfrutta diversi vantaggi di ReFS:

  • Una maggiore resilienza nell'integrità dei dati comporta un minor numero di eventi imprevisti di danneggiamento dei dati. La riduzione del numero di eventi imprevisti di danneggiamento comporta un minor numero di reinvii di database non necessari.
  • Checksum in esecuzione sui metadati che abilita il rilevamento dei casi di danneggiamento prima e in modo più deterministico, consentendoci di correggere il danneggiamento dei dati dei clienti prima che si verifichino errori grigi nei volumi di dati.
  • Progettato per funzionare correttamente con set di dati di grandi dimensioni, petabyte e dimensioni maggiori, senza alcun impatto sulle prestazioni
  • Supporto per altre funzionalità usate da Exchange Online, ad esempio la crittografia BitLocker.

Exchange Online trae vantaggio anche da altre funzionalità reFS:

  • Integrità (flussi di integrità): ReFS archivia i dati in modo da proteggerli da molti degli errori comuni che in genere possono causare la perdita di dati. Microsoft 365 Search usa i flussi di integrità per facilitare il rilevamento del danneggiamento del disco e i checksum del contenuto del file. La funzionalità riduce anche gli eventi imprevisti di danneggiamento causati da "Scritture strappate" (quando un'operazione di scrittura non viene completata a causa di interruzioni dell'alimentazione e così via).
  • Disponibilità (salvataggio): ReFS assegna la priorità alla disponibilità dei dati. Storicamente, i file system erano spesso soggetti al danneggiamento dei dati che richiedeva che il sistema venisse portato offline per la riparazione. Anche se raro, se si verifica un danneggiamento, ReFS implementa il salvataggio, una funzionalità che rimuove i dati danneggiati dallo spazio dei nomi in un volume attivo e garantisce che i dati validi non siano influenzati negativamente da dati danneggiati non ripristinabili. L'applicazione della funzionalità di salvataggio e l'isolamento del danneggiamento dei dati ai volumi di database Exchange Online significa che è possibile mantenere integri i database non interessati in un volume danneggiato tra il momento del danneggiamento e l'azione di ripristino. Questa struttura aumenta la disponibilità dei database che in genere sarebbero interessati da tali problemi di danneggiamento del disco.