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

  • Article

Importante

À mesure que nous continuons à investir de différentes manières pour préserver le contenu de la boîte aux lettres, nous annonçons la mise hors service de In-Place conservations dans le Centre d’administration Exchange (EAC) dans Exchange Online. À compter du 1er juillet 2020, vous ne pourrez plus créer de In-Place conservations. Toutefois, vous serez toujours en mesure de gérer In-Place conservation dans le Centre d’administration Exchange ou à l’aide de l’applet de commande Set-MailboxSearch dans Exchange Online PowerShell. Toutefois, à compter du 1er octobre 2020, vous ne pourrez plus gérer In-Place conservations. Vous ne pourrez les supprimer que dans le Centre d’administration Exchange ou à l’aide de l’applet de commande Remove-MailboxSearch . L’utilisation de In-Place conservations dans les déploiements hybrides Exchange Server et Exchange est toujours prise en charge. Pour plus d’informations sur la mise hors service de In-Place conservation dans Exchange Online, consultez 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’archivage correspondante (s’il est activé) est également mis en attente et renvoyé dans une recherche eDiscovery.

Il existe deux types d’altération qui peuvent affecter une base de données Exchange : l’altération physique, qui est généralement due à 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 :

  • Corruption 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 (ESE)) tente d’écrire une page de base de données et même si le système d’exploitation retourne un message de réussite, les données ne sont jamais écrites sur le disque ou 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 l’altération 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 d’une seule page) pour la corriger.
  • Corruption logique du stockage : les données sont ajoutées, supprimées ou manipulées d’une manière que l’utilisateur ne s’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 endommagée. 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 pendant l’inspection des journaux et la relecture du journal. Ces vérifications de cohérence empêchent la réplication de l’altération physique par le système. Par exemple, lors de l’inspection du journal, il existe un case activée d’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 approfondi. Par exemple, l’en-tête de base de données contient également la signature du journal qui est 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 de la protection des données natives Exchange, 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 protègent contre la perte de données 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 d’un seul bit
  • Analyse de base de données en ligne
  • Détection de vidage perdu
  • Restauration d’une page unique
  • Service de réplication de boîtes 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 lien hypertexte. En plus de ces fonctionnalités natives, Exchange Online inclut également des fonctionnalités de résilience des données que les clients peuvent gérer, telles que :

Groupes de disponibilité de base de données

Chaque base de données de boîtes 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 dans 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îtes aux lettres a quatre copies qui sont distribuées sur 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 du 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 avec décalage. La copie de base de données en retard n’est pas destinée à la récupération d’une boîte aux lettres individuelle ou à la récupération d’éléments de boîte aux lettres. Son objectif est de fournir un mécanisme de récupération pour les rares cas de corruption logique catastrophique à l’échelle du système.

Les copies de base de données différées dans Exchange Online sont configurées avec un délai de relecture de fichier journal de sept jours. En outre, exchange Replay Lag Manager est activé pour fournir une lecture dynamique du fichier journal pour les copies différées afin de permettre aux copies de base de données différées de réparer elles-mêmes et de gérer 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 à un instant dans le temps garantie. Les copies de base de données retardées dans Exchange Online ont un seuil de disponibilité, généralement d’environ 90 %, en raison des périodes où le disque contenant une copie retardée est perdu en raison d’une défaillance du disque, la copie retardée devient une copie hautement disponible (en raison de la lecture automatique), ainsi que des périodes où la copie de base de données retardée reconstruit la file d’attente de relecture du journal.

Résilience du transport

Exchange Online comprend deux principales fonctionnalités de résilience de transport : la redondance de l’ombre et le filet de sécurité. La redondance de l’ombre conserve une copie redondante d’un message pendant qu’il est en transit. Le service Safety Net conserve une copie redondante d’un message une fois le message remis.

Avec la redondance de l’ombre, chaque serveur de transport Exchange Online effectue une copie de chaque message qu’il reçoit avant d’accuser réception du message sur le serveur d’envoi. Cela rend tous les messages du pipeline de transport redondants pendant leur transit. Si Exchange Online détermine que le message d’origine a été perdu en transit, une copie redondante du message est redélisée.

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. Quand une base de données de boîtes 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îtes aux lettres, les messages de la file d’attente Safety Net sont automatiquement soumis à la nouvelle copie active de la base de données de boîtes aux lettres. Le filet de sécurité est également redondant, ce qui élimine le transport comme point de défaillance unique. Il utilise le concept d’un filet de sécurité principal et d’un shadow safety net dans lequel, si le réseau de sécurité principal n’est pas disponible pendant plus de 12 heures, les demandes de soumission de nouveau deviennent des demandes de resoumettre des ombres et les messages sont redélidés à partir du shadow safety net.

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

Correction d’un seul bit

ESE inclut un mécanisme permettant de détecter et de résoudre les erreurs CRC mono bits (également appelées flips mono bits) qui sont le résultat d’erreurs matérielles (et en tant que telles, elles représentent une altération physique). Lorsque ces erreurs se produisent, ESE les corrige automatiquement et enregistre 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 case activée de base de données) est le processus dans lequel un environnement ESE utilise un vérificateur de cohérence de base de données pour lire chaque page et case activée en cas d’altération de page. L’objectif principal est de détecter les altérations physiques 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 de blocage post-magasin. L’espace peut être divulgué en raison d’incidents, et l’analyse de base de données en ligne détecte et récupère l’espace perdu. Le système est conçu dans l’attente que chaque base de données soit entièrement analysée une fois tous les sept jours.

Détection de vidage perdu

Une perte de vidage 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 été réellement écrite sur le disque ou a été écrite au mauvais emplacement. Les incidents de vidage perdu peuvent entraîner une altération logique de la base de données. Par conséquent, pour empêcher les vidages perdus d’entraîner la perte de données, 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 case activée 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 d’un réplica sain. Le processus de réparation d’une page endommagée varie selon que la copie de la 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. Ce processus s’effectue en plaçant une demande pour la page dans le flux de journaux, 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 seule page fournit également un mécanisme de communication asynchrone permettant à l’actif de demander une page à partir de réplicas, même si les réplicas sont actuellement hors connexion.

En cas d’altération dans une copie de base de données passive, y compris une copie de base de données en retard, étant donné que ces copies se trouvent 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 passive de base de données étant par nature hautement disponible, pendant le processus de mise à jour corrective des pages, la relecture des journaux est suspendue, mais la copie des journaux se poursuit. La copie passive de la base de données récupère une copie de la page endommagée à partir de la copie active, attend que le fichier journal qui répond à la spécification maximale requise pour la génération du journal soit copié et inspecté, puis corrige la page endommagée. Une fois la page corrigée, la relecture du journal reprend. Le processus est le même pour la copie de base de données différée, sauf que la base de données différée relecture d’abord tous les fichiers journaux nécessaires pour obtenir un état corrective.

Service de réplication de boîtes 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 mises à jour des technologies et des mises à niveau de matériel 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 assurant la transparence des déplacements de la boîte aux lettres pour les utilisateurs (en veillant à ce qu’ils restent en ligne tout au long du processus) et en veillant à ce que le processus soit correctement mis à l’échelle à mesure que les boîtes aux lettres deviennent de plus en plus volumineuses.

Le service de réplication de 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 case activée 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 traiter 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 sont soumis à 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 journal 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 qu’il est écrit, puis à nouveau à 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) pour fournir des fonctionnalités de récupération améliorées. ReFS est un système de fichiers dans Windows Server 2012 et versions ultérieures, conçu pour être plus résilient contre l’altération 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 pour les 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, ce qui garantit que l’altération des données est facilement trouvée et réparée.

Exchange Online tire parti de plusieurs avantages reFS :

  • Une plus grande résilience dans l’intégrité des données signifie moins d’incidents d’altération des données. La réduction du nombre d’incidents d’endommagement signifie moins de réinitations inutiles de la base de données.
  • Somme de contrôle exécutée sur les métadonnées permettant de détecter les cas d’altération plus rapidement et de manière 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 volumineux) 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 la plupart des erreurs courantes qui peuvent normalement entraîner une perte de données. Microsoft 365 Recherche utilise des flux d’intégrité pour faciliter la détection précoce des altérations de disque et les sommes de contrôle du contenu du fichier. La fonctionnalité réduit également les incidents d’endommagement causé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, en cas d’altération, 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 données correctes 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 l’altération des données aux volumes de base de données Exchange Online signifient 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 du disque.