Exchange Online la résilience des données dans Microsoft 365

Article
03/21/2023

Importante

Alors que nous continuons d’investir de différentes façons pour préserver le contenu de la boîte aux lettres, nous annoncions le retrait de In-Place Conservations dans le Centre d’administration Exchange (EAC) dans Exchange Online. À compter du 1er juillet 2020, vous ne pourrez pas créer de In-Place conservations. Toutefois, vous pourrez toujours gérer In-Place conservations dans le CAE ou à l’aide de l’applet de commande Set-MailboxSearch dans Exchange Online PowerShell. Toutefois, à compter du 1er octobre 2020, vous ne pourrez pas gérer In-Place conservations. Vous ne pourrez les supprimer que dans le CAE ou à l’aide de l’applet de commande Remove-MailboxSearch . L’utilisation de In-Place Holds in Exchange Server et des déploiements hybrides Exchange sera toujours prise en charge. Pour plus d’informations sur la mise hors service de In-Place Conservations dans Exchange Online, consultez La mise hors service des outils eDiscovery hérités.

Une conservation inaltérable conserve tout le contenu d’une boîte aux lettres, y compris les éléments supprimés et les versions originales des éléments modifiés. Tous ces éléments de boîte aux lettres sont renvoyés dans une recherche de Découverte électronique locale. Lorsque vous placez une In-Place En attente sur la boîte aux lettres d’un utilisateur, le contenu de la boîte aux lettres d’archive correspondante (si elle est activée) est également mis en attente et retourné dans une recherche eDiscovery.

Il existe deux types d’altération qui peuvent affecter une base de données Exchange : la corruption physique, qui est généralement causée par des problèmes matériels (en particulier, le matériel de stockage) et l’altération logique, qui se produit en raison d’autres facteurs. En règle générale, il existe deux types d’altération logique qui peuvent se produire dans une base de données Exchange :

Altération logique de la base de données : la somme de contrôle de la page de base de données correspond, mais les données de la page sont incorrectes logiquement. Cela peut se produire lorsque le moteur de base de données (le moteur de stockage extensible)) tente d’écrire une page de base de données et que, même si le système d’exploitation renvoie un message de réussite, les données ne sont jamais écrites sur le disque ou elles sont écrites au mauvais endroit. Il s’agit d’un vidage perdu. ESE inclut de nombreuses fonctionnalités et protections conçues pour empêcher la corruption physique d’une base de données et d’autres scénarios de perte de données. Pour empêcher les vidages perdus de perdre des données, ESE inclut un mécanisme de détection de vidage perdu dans la base de données ainsi qu’une fonctionnalité (restauration à une seule page) pour les corriger.
Stocker l’altération logique : les données sont ajoutées, supprimées ou manipulées d’une manière que l’utilisateur n’attend pas. Ces cas sont causés par des applications tierces. Il s’agit généralement d’une corruption dans le sens où l’utilisateur la considère comme une corruption. La banque d'informations Exchange considère la transaction qui est à l'origine de l'altération logique comme une série d'opérations MAPI valides. Les fonctionnalités de conservation sur place dans Exchange Online offrent une protection contre l’altération logique du magasin (car elles empêchent la suppression définitive du contenu par un utilisateur ou une application).

Exchange Online effectue plusieurs vérifications de cohérence sur les fichiers journaux répliqués lors de l’inspection des journaux et de la relecture des journaux. Ces vérifications de cohérence empêchent la réplication de l’altération physique par le système. Par exemple, pendant l’inspection des journaux, il existe une vérification de l’intégrité physique qui vérifie le fichier journal et vérifie que la somme de contrôle enregistrée dans le fichier journal correspond à la somme de contrôle générée en mémoire. En outre, l’en-tête du fichier journal est examiné pour s’assurer que la signature du fichier journal enregistrée dans l’en-tête de journal correspond à celle du fichier journal. Pendant la relecture du journal, le fichier journal fait l’objet d’un examen plus approfondi. Par exemple, l’en-tête de base de données contient également la signature de journal comparée à la signature du fichier journal pour s’assurer qu’elles correspondent.

La protection contre l’altération des données de boîte aux lettres dans Exchange Online est obtenue à l’aide d’Exchange Native Data Protection, une stratégie de résilience qui tire parti de la réplication au niveau de l’application sur plusieurs serveurs et plusieurs centres de données, ainsi que d’autres fonctionnalités qui permettent de protéger les données contre la perte en raison d’une altération ou d’autres raisons. Ces fonctionnalités incluent des fonctionnalités natives gérées par Microsoft ou l’application Exchange Online elle-même, telles que :

Groupes de disponibilité des données
Correction de bits uniques
Analyse de base de données en ligne
Détection des vidages perdus
Restauration d’une page unique
Service de réplication de boîte aux lettres
Vérifications des fichiers journaux
Déploiement sur un système de fichiers résilient

Pour plus d’informations sur les fonctionnalités natives répertoriées précédemment, sélectionnez les liens hypertexte et consultez les informations suivantes pour plus d’informations et pour plus d’informations sur les éléments sans liens hypertexte. Outre ces fonctionnalités natives, Exchange Online inclut également des fonctionnalités de résilience des données que les clients peuvent gérer, par exemple :

Groupes de disponibilité de base de données

Chaque base de données de boîte aux lettres dans Microsoft 365 est hébergée dans un groupe de disponibilité de base de données (DAG) et répliquée dans des centres de données géographiquement distincts au sein de la même région. La configuration la plus courante est quatre copies de base de données dans quatre centres de données ; toutefois, certaines régions ont moins de centres de données (les bases de données sont répliquées vers trois centres de données en Inde et deux centres de données en Australie et au Japon). Mais dans tous les cas, chaque base de données de boîte aux lettres a quatre copies distribuées entre plusieurs centres de données, garantissant ainsi que les données de boîte aux lettres sont protégées contre les défaillances logicielles, matérielles et même de centre de données.

Sur ces quatre copies, trois d’entre elles sont configurées comme hautement disponibles. La quatrième copie est configurée en tant que copie de base de données en retard. La copie de base de données en retard n’est pas destinée à une récupération de boîte aux lettres ou à une récupération d’élément de boîte aux lettres individuelle. Son objectif est de fournir un mécanisme de récupération pour les rares événements de corruption logique catastrophique à l’échelle du système.

Les copies de base de données en retard dans Exchange Online sont configurées avec un délai de réexécution du fichier journal de sept jours. En outre, le Gestionnaire de décalage Exchange Replay est activé pour fournir une lecture dynamique des fichiers journaux pour les copies en retard afin d’autoriser les copies de base de données en retard à réparer et à gérer automatiquement la croissance des fichiers journaux. Bien que les copies de base de données en retard soient utilisées dans Exchange Online, il est important de comprendre qu’il ne s’agit pas d’une sauvegarde dans le temps garantie. Les copies de base de données en retard dans Exchange Online ont un seuil de disponibilité, généralement d’environ 90 %, en raison de périodes où le disque contenant une copie en retard est perdue en raison d’une défaillance du disque, de la copie en retard devenant une copie hautement disponible (en raison d’une lecture automatique), ainsi que des périodes pendant lesquelles la copie de base de données en retard reconstruit la file d’attente de relecture du journal.

Résilience du transport

Exchange Online comprend deux principales fonctionnalités de résilience du transport : La redondance d’ombre et Safety Net. La redondance fantôme conserve une copie redondante d’un message pendant qu’il est en transit. Safety Net conserve une copie redondante d’un message une fois le message remis.

Avec la redondance fantôme, chaque serveur de transport Exchange Online effectue une copie de chaque message qu’il reçoit avant de confirmer la réception du message au serveur d’envoi. Cela rend tous les messages du pipeline de transport redondants pendant le transit. Si Exchange Online détermine que le message d’origine a été perdu en transit, une copie redondante du message est remise.

Safety Net est une file d’attente de transport associée au service de transport sur un serveur de boîtes aux lettres. Cette file d'attente stocke des copies des messages qui ont été correctement traités par le serveur. Lorsqu’une base de données de boîte aux lettres ou une défaillance du serveur nécessite l’activation d’une copie obsolète de la base de données de boîte aux lettres, les messages de la file d’attente Safety Net sont automatiquement réinscrits à la nouvelle copie active de la base de données de boîte aux lettres. Safety Net est également redondant, éliminant ainsi le transport comme point de défaillance unique. Il utilise le concept d’un filet de sécurité primaire et d’un filet de sécurité fantôme dans lequel, si le filet de sécurité principal n’est pas disponible pendant plus de 12 heures, les demandes de renvoi deviennent des demandes de renvoi d’ombre et les messages sont remis à partir de Shadow Safety Net.

Les résubmissions de messages de Safety Net sont lancées automatiquement par le composant Active Manager du service de réplication Microsoft Exchange qui gère les D DAG et les copies de base de données de boîte aux lettres. Aucune action manuelle n’est requise pour renvoyer des messages à partir de Safety Net.

Correction de bits uniques

ESE inclut un mécanisme permettant de détecter et de résoudre les erreurs CRC à bit unique (également appelées retournements à bits uniques) qui sont le résultat d’erreurs matérielles (et en tant que telles qu’elles représentent une altération physique). Lorsque ces erreurs se produisent, ESE les corrige automatiquement et journalise un événement dans le journal des événements.

Analyse de base de données en ligne

L’analyse de base de données en ligne (également appelée somme de vérification de base de données) est le processus dans lequel un ESE utilise un vérificateur de cohérence de base de données pour lire chaque page et rechercher l’altération de la page. L’objectif principal est de détecter l’altération physique et les vidages perdus qui peuvent ne pas être détectés par les opérations transactionnelles. L’analyse de base de données effectue également des opérations d’incident post-magasin. L’espace peut être divulgué en raison d’incidents, et l’analyse de base de données en ligne recherche et récupère l’espace perdu. Le système est conçu avec l’attente que chaque base de données soit entièrement analysée une fois tous les sept jours.

Détection des vidages perdus

Un vidage perdu se produit lorsqu’une opération d’écriture de base de données que le sous-système de disque/système d’exploitation retourné comme terminé n’a pas réellement été écrite sur le disque ou qu’elle a été écrite au mauvais emplacement. Les incidents de vidage perdus peuvent entraîner une altération logique de la base de données, de sorte que pour empêcher les vidages perdus de se traduire par des données perdues, ESE inclut un mécanisme de détection de vidage perdu. Lorsque les pages de base de données sont écrites dans des copies passives, une vérification est effectuée pour les vidages perdus sur la copie active. Si un vidage perdu est détecté, ESE peut réparer le processus à l’aide d’un processus de mise à jour corrective de page.

Restauration d’une page unique

La restauration d’une page unique, également appelée mise à jour corrective de page, est un processus automatique dans lequel les pages de base de données endommagées sont remplacées par des copies saines à partir d’un réplica sain. Le processus de réparation d’une page endommagée varie selon que la copie de base de données est active ou passive. Lorsqu’une copie de base de données active rencontre une page endommagée, elle peut copier une page à partir de l’un de ses réplicas, à condition que la page qu’elle copie soit à jour. Pour ce faire, vous pouvez placer une demande de page dans le flux de journal, qui est la base de la réplication de la base de données de boîte aux lettres. Dès qu’un réplica rencontre la demande de page, il répond en envoyant une copie de la page à la copie de base de données demandée. La restauration d’une page unique fournit également un mécanisme de communication asynchrone pour que l’actif demande une page aux réplicas, même si les réplicas sont actuellement hors connexion.

En cas d’altération d’une copie de base de données passive, y compris une copie de base de données en retard, car ces copies sont toujours derrière leur copie active, il est toujours sûr de copier n’importe quelle page de la copie active vers une copie passive. Une copie de base de données passive est par nature hautement disponible. Par conséquent, pendant le processus de mise à jour corrective des pages, la relecture des journaux est suspendue, mais la copie des journaux continue. La copie de base de données passive récupère une copie de la page endommagée à partir de la copie active, attend que le fichier journal qui réponde à l’exigence de génération de journal maximale requise soit copié et inspecté, puis corrige la page endommagée. Une fois la page mise à jour corrective, la relecture du journal reprend. Le processus est le même pour la copie de base de données en retard, sauf que la base de données en retard relit d’abord tous les fichiers journaux nécessaires pour obtenir un état corrective.

Service de réplication de boîte aux lettres

Le déplacement de boîtes aux lettres est un élément clé de la gestion d’un service de messagerie à grande échelle. Il existe toujours des technologies mises à jour et des mises à niveau matérielles et de version à gérer. Il est donc essentiel de disposer d’un système robuste et limité qui permet à nos ingénieurs d’accomplir ce travail tout en gardant la boîte aux lettres transparente pour les utilisateurs (en s’assurant qu’elles restent en ligne tout au long du processus) et en veillant à ce que le processus s’adapte correctement à mesure que les boîtes aux lettres sont de plus en plus volumineuses.

Le service de réplication des boîtes aux lettres Exchange (MRS) est responsable du déplacement des boîtes aux lettres entre les bases de données. Pendant le déplacement, MRS effectue une vérification de cohérence sur tous les éléments de la boîte aux lettres. Si un problème de cohérence est détecté, MRS corrige le problème ou ignore les éléments endommagés, ce qui supprime l’altération de la boîte aux lettres.

Étant donné que MRS est un composant de Exchange Online, nous pouvons apporter des modifications dans son code pour résoudre les nouvelles formes de corruption détectées à l’avenir. Par exemple, si nous détectons un problème de cohérence que MRS n’est pas en mesure de résoudre, nous pouvons analyser l’altération, modifier le code MRS et corriger l’incohérence (si nous comprenons comment le faire).

Vérifications des fichiers journaux

Tous les fichiers journaux des transactions générés par une base de données Exchange subissent plusieurs formes de vérification de cohérence. Lorsqu’un fichier journal est créé, la première chose à faire est qu’un modèle de bits est écrit, puis une série d’écritures de journaux est effectuée. Cette structure permet à Exchange Online d’exécuter une série de vérifications (vidage perdu, CRC et autres vérifications) pour valider chaque fichier journal au fur et à mesure de son écriture, puis à mesure qu’il est répliqué.

Déploiement sur un système de fichiers résilient

Pour éviter toute altération au niveau du système de fichiers, Exchange Online est déployé sur des partitions ReFS (Resilient File System) afin de fournir des fonctionnalités de récupération améliorées. ReFS est un système de fichiers dans Windows Server 2012 et ultérieur qui est conçu pour être plus résilient contre la corruption des données, ce qui optimise la disponibilité et l’intégrité des données. Plus précisément, ReFS apporte des améliorations dans la façon dont les métadonnées sont mises à jour, ce qui offre une meilleure protection des données et réduit les cas d’altération des données. Il utilise également des sommes de contrôle pour vérifier l’intégrité des données de fichier et des métadonnées afin de s’assurer que l’altération des données est facilement trouvée et réparée.

Exchange Online tire parti de plusieurs avantages ReFS :

Une résilience accrue de l’intégrité des données signifie moins d’incidents d’altération des données. La réduction du nombre d’incidents d’altération signifie moins de reseeds de base de données inutiles.
Somme de contrôle s’exécutant sur les métadonnées permettant de détecter les cas d’altération plus tôt et plus déterministe, ce qui nous permet de corriger l’altération des données client avant que des défaillances grises ne se produisent sur les volumes de données.
Conçu pour fonctionner correctement avec des jeux de données volumineux (pétaoctets et plus grands) sans impact sur les performances
Prise en charge d’autres fonctionnalités utilisées par Exchange Online, telles que le chiffrement BitLocker.

Exchange Online bénéficie également d’autres fonctionnalités ReFS :

Intégrité (flux d’intégrité) : ReFS stocke les données d’une manière qui les protège contre de nombreuses erreurs courantes qui peuvent normalement entraîner une perte de données. La recherche Microsoft 365 utilise les flux d’intégrité pour faciliter la détection précoce de l’altération des disques et les sommes de contrôle du contenu de fichier. La fonctionnalité réduit également les incidents d’altération provoqués par les « écritures déchirées » (lorsqu’une opération d’écriture ne se termine pas en raison de pannes de courant, etc.).
Disponibilité (récupération) : ReFS hiérarchise la disponibilité des données. Historiquement, les systèmes de fichiers étaient souvent exposés à une altération des données qui nécessitait que le système soit mis hors connexion pour réparation. Bien que rare, si une altération se produit, ReFS implémente la récupération, une fonctionnalité qui supprime les données endommagées de l’espace de noms sur un volume actif et garantit que les bonnes données ne sont pas affectées par des données endommagées non réparables. L’application de la fonctionnalité de récupération et l’isolation de la corruption des données aux volumes de base de données Exchange Online signifie que nous pouvons conserver les bases de données non affectées sur un volume endommagé en bonne santé entre le moment de l’altération et de l’action de réparation. Cette structure augmente la disponibilité des bases de données qui seraient normalement affectées par de tels problèmes d’altération de disque.