Banque gérée
S’applique à : Exchange Server 2013
Toutes les versions antérieures d'Exchange Server, d'Exchange Server 4.0 à Exchange Server 2010, prennent en charge l'exécution d'une seule instance du processus de la banque d'informations (Store.exe) sur le rôle serveur de boîte aux lettres. Cette instance de banque unique héberge toutes les bases de données sur le serveur : actives, passives, retardées et de récupération. Dans les architectures Exchange précédentes, il existe peu d’isolation, voire aucune, entre les différentes bases de données hébergées sur un serveur de boîtes aux lettres. Un problème avec une seule base de données de boîtes aux lettres peut avoir un impact négatif sur toutes les autres bases de données, et les incidents résultant d'un endommagement de boîte aux lettres peuvent influer sur le service pour tous les utilisateurs dont les bases de données sont hébergées sur ce serveur.
Un autre défi avec un seul store instance dans les versions précédentes d’Exchange est que le moteur de stockage extensible (ESE) est bien mis à l’échelle vers 8 à 12 cœurs de processeur, mais au-delà de ce seuil, les problèmes de communication interprocesseur et de synchronisation du cache entraînent une mise à l’échelle négative. Étant donné les serveurs plus grands d’aujourd’hui, avec plus de 16 systèmes de cœurs disponibles, cela signifierait imposer le défi administratif de gérer l’affinité de 8 à 12 cœurs pour ESE et d’utiliser les autres cœurs pour les processus non-Store (par exemple, Assistants, Search Foundation, Managed Availability, etc.). De plus, l’architecture précédente restreignait le scale-up pour le processus store.
Le processus Store.exe a considérablement évolué au fil des années, car Exchange Server lui-même a évolué, mais en tant que processus unique, sa scalabilité est limitée et représente un point de défaillance unique. En raison de ces limites, Store.exe a été supprimé dans Exchange 2013 et remplacé par le magasin géré.
Banque gérée
La banque gérée est le nom des processus de la banque d’informations (c’est-à-dire la banque) dans Exchange Server 2013. Elle utilise un modèle de processus contrôleur/de travail qui permet d'isoler les processus de stockage et d'accélérer le basculement de base de données. La banque gérée comprend également un nouveau mécanisme de mise en cache de base de données statique qui remplace l'algorithme de tampon dynamique dans les versions précédentes d'Exchange Server. Dans le modèle multiprocesseur utilisé par le magasin géré, il existe un processus de contrôleur de service de magasin unique (dans ce cas, Microsoft.Exchange.Store.Service.exe alias MSExchangeIS) et un processus worker (dans ce cas, Microsoft.Exchange.Store.Worker.exe) pour chaque base de données montée. Lorsqu'une base de données est montée, un nouveau processus de travail desservant uniquement cette base de données est instancié. Lorsqu'une base de données est démontée, le processus de travail de cette base de données est arrêté.
Par exemple, si 40 bases de données sont montées sur un serveur, il y aura 41 processus exécutés pour la banque gérée, un pour chaque base de données et un pour le contrôleur de processus de service de la banque.
Le contrôleur de processus de service de magasin est mince et fiable, mais s’il meurt ou est arrêté, tous ses processus de travail meurent (ils détectent que le processus du contrôleur de service a disparu et s’arrête). Le contrôleur de processus du magasin surveille l’intégrité de tous les processus worker du magasin sur le serveur. Un arrêt forcé ou inattendu de l'Microsoft.Exchange.Store.Service.exe provoque un basculement immédiat de toutes les copies de base de données actives. Le magasin géré est également étroitement intégré au service de réplication Microsoft Exchange (MSExchangeRepl.exe) et à Active Manager. Le processus du contrôleur, les processus de travail et le service de réplication fonctionnent ensemble pour offrir une plus grande disponibilité et une plus grande fiabilité :
Processus du service de réplication Microsoft Exchange (MSExchangeRepl.exe)
Responsable de l'émission des opérations de montage et de démontage dans la banque
Lance une action de récupération en cas de défaillances de stockage ou de base de données signalées par la banque, le moteur de stockage extensible (ESE) et les répondeurs de disponibilité gérée.
Détecte les défaillances de base de données inattendues.
Fournit l'interface d'administration pour les tâches de gestion.
Contrôleur/processus de service de banque (Microsoft.Exchange.Store.Service.exe)
Gère la durée de vie de chaque processus de travail en fonction des opérations de montage et de démontage envoyées par le service de réplication.
Gère les demandes entrantes émanant du Gestionnaire de contrôle des services Windows.
Enregistre les éléments en échec lors de la détection de problèmes de processus de travail de banque (par exemple, blocage ou arrêt inattendu).
Met fin aux processus de travail de banque en cas d'événement de basculement de réponse.
Processus de travail de banque (Microsoft.Exchange.Store.Worker.exe)
Responsable de l'exécution des opérations RPC pour les boîtes aux lettres sur une base de données
L'instance de point de terminaison RPC au sein du processus de travail est le GUID de la base de données.
Fournit un cache de base de données.
Algorithme de mise en cache de base de données statique
L’algorithme de mise en cache de base de données appelé allocation de mémoire tampon dynamique, introduit dans Exchange Server 5.5 et également utilisé par la banque d’informations dans Exchange 2000 Server, Exchange Server 2003, Exchange Server 2007 et Exchange Server 2010, a également disparu d’Exchange 2013. Exchange 2013 utilise un algorithme simple et direct pour déterminer le cache de base de données. La banque gérée ne réalloue plus dynamiquement le cache entre les bases de données en cas de basculement, ce qui simplifie fortement la gestion du cache interne. Au lieu de cela, la mémoire allouée pour chaque cache de base de données (par exemple, chaque processus worker de magasin) est basée sur le nombre de copies de base de données locales et la valeur de MaximumActiveDatabases, si configuré. Si la valeur de MaximumActiveDatabases est supérieure au nombre de copies de base de données actuelles, le calcul du cache est basé sur le nombre de copies de base de données.
L'algorithme statique utilisé par Exchange 2013 alloue de la mémoire pour le cache ESE de chaque processus de travail de banque en fonction de la mémoire vive physique. Cette mémoire est appelée cible maximale de cache d’une base de données. Le quart de la mémoire totale du serveur est alloué au cache ESE. Cette proportion de mémoire est appelée cible de taille du cache du serveur.
Remarque
La cible de taille du cache du serveur et, par conséquent, la quantité de mémoire allouée au cache Store pour ESE peuvent être remplacées à l’aide de l’attribut msExchESEParamCacheSizeMax de l’objet InformationStore dans Active Directory (la valeur configurée est le nombre de pages de 32 Ko à allouer sur tous les processus de magasin).
Une quantité statique de ce cache est allouée aux copies actives et passives. La cible de cache maximale sera allouée au processus de travail de banque uniquement lors du traitement d'une copie de base de données active. Les copies de bases de données passives bénéficient de 20 % de la cible de cache maximale. Le reste est conservé par la banque et alloué au processus de travail si la base de données passive devient active.
La cible de cache maximale est calculée uniquement au démarrage de la banque. Par conséquent, si vous ajoutez ou supprimez des bases de données ou des copies de bases de données, vous devez redémarrer le service de contrôleur de banque (MSExchangeIS) afin que le cache puisse être ajusté. Si le service n’est pas redémarré, les bases de données nouvellement créées ont une cible de cache plus petite que les bases de données créées avant le démarrage du service. Dans ce cas, la somme des tailles cible de cache de base de données dépassera probablement la taille cible de cache du serveur avant le redémarrage de MSExchangeIS.
Exemples de calculs de cache de base de données
Voici des exemples de calculs de mise en cache de base de données effectués selon la configuration de la mémoire et de la base de données d'un serveur de boîtes aux lettres.
Exemple 1
Dans cet exemple, le serveur de boîtes aux lettres possède une mémoire de 48 Go et il héberge deux bases de données actives et deux bases de données passives. En outre, le paramètre MaximumActiveDatabases n’est pas configuré. Dans cette configuration, la quantité de cache de base de données est de 3 Go pour chaque processus de travail de copie de base de données active et de 0,6 Go pour chaque processus de travail de copie de base de données passive. Voici comment ces valeurs ont été obtenues.
Pour obtenir la taille cible de cache de serveur, multipliez la quantité de mémoire par 25 % :
48 Go X 25 % = 12 Go
Pour obtenir la cible de cache maximale de base de données, divisez la taille cible de cache de serveur par le nombre total de bases de données actives et passives :
12 Go/4 bases de données = 3 Go
Pour déterminer la quantité de mémoire utilisée pour les copies de bases de données passives, multipliez la cible de cache maximale de base de données par 20 % :
3 Go X 20 % = 0,6 Go
Sur les 12 Go de mémoire alloués à la taille cible de cache de serveur, 7,2 Go seront utilisés par les processus de travail de base de données, et 4,8 Go seront réservés par la banque d'informations pour les deux copies de bases de données passives, au cas où elles deviendraient des copies actives. Dans ce cas, ils utiliseront leur cible de cache maximale de 3 Go.
Exemple 2
Dans cet exemple, le serveur de boîtes aux lettres dispose également de 48 Go de mémoire et héberge deux bases de données actives et deux bases de données passives ; Toutefois, le paramètre MaximumActiveDatabases est configuré avec la valeur 2. Dans cette configuration, la quantité de cache de base de données est de 5 Go pour chaque processus de travail de copie de base de données actif et de 0,2 Go pour chaque processus de travail de copie de base de données passif. Voici comment ces valeurs ont été obtenues.
Pour obtenir la taille cible de cache de serveur, multipliez la quantité de mémoire par 25 % :
48 Go X 25 % = 12 Go
Pour obtenir la cible maximale du cache de base de données, divisez la cible de taille du cache du serveur par le nombre total de bases de données actives plus le nombre total de bases de données passives multipliées par 20 % :
12 Go/(2A + (2P X 20 %)) = 5 Go
Pour déterminer la quantité de mémoire utilisée pour les copies de bases de données passives, multipliez la cible de cache maximale de base de données par 20 % :
5 Go X 20 % = 1 Go
Sur les 12 Go de mémoire affectés à la cible de taille du cache du serveur, 12 Go seront utilisés par les processus worker de base de données et aucune mémoire n’est réservée par le magasin d’informations pour les deux copies de base de données passives, car elles ne peuvent pas devenir des copies actives dans cette configuration (car MaximumActiveDatabases est configuré avec la valeur 2, et il y a déjà 2 copies de base de données actives sur le serveur).