Exporter (0) Imprimer
Développer tout

Solutions Exchange 2010 testées : 32 400 boîtes aux lettres dans trois sites exécutant Hyper-V sur des serveurs lames Unified Compute System de Cisco et le dispositif de stockage EMC CLARiiON

 

Dernière rubrique modifiée : 2012-03-05

Rob Simpson, directeur de programme, Microsoft Exchange ; Boris Voronin, ingénieur solutions principal, Exchange Solutions Engineering, EMC ; Mike Mankovsky, architecte solutions Microsoft, Cisco

juin 2011

Dans les Solutions testées pour Exchange 2010, Microsoft et les partenaires serveur, stockage et réseau participants examinent les scénarios client courants et les points clés de décision du processus de conception auxquels sont confrontés les clients désireux de déployer Microsoft Exchange Server 2010. Dans cette série de livres blancs, nous fournissons des exemples de solutions Exchange 2010 clairement conçues et rentables déployées sur le matériel proposé par certains de nos partenaires serveur, stockage et réseau.

Vous pouvez télécharger ce document à partir du Centre de téléchargement Microsoft.

Microsoft Exchange Server 2010 avec Service Pack 1 (SP1)

Windows Server 2008 R2

Windows Server 2008 R2 Hyper-V

Sommaire

Ce document fournit un exemple de procédure à suivre pour concevoir, tester et valider une solution Exchange Server 2010 exécutant la technologie Windows Server 2008 R2 Hyper-V sur un environnement client composé de 32 400 boîtes aux lettres déployées sur des serveurs lames Cisco Unified Computing System et des solutions de stockage EMC CLARiiON. L’un des principaux défis de la conception d’environnements Exchange 2010 plus vastes consiste à examiner les options de serveur et de stockage actuellement disponibles et à faire les bons choix matériels offrant le meilleur rapport qualité-prix sur toute la durée de vie prévue de la solution. À l’issue de la méthodologie par étapes fournie dans ce document, nous aborderons les points de décision importants du processus de conception qui permettent de relever ces défis tout en veillant à répondre aux principaux besoins de l’entreprise cliente. Après avoir déterminé la solution optimale pour ce client, la solution est soumise à un processus de validation standard pour assurer sa résistance à des charges de travail de production simulées dans des conditions normales de fonctionnement, ainsi que des situations de maintenance et de défaillance.

Return to top

Les tableaux suivants résument les principaux composants Exchange et matériels de cette solution.

Composants Exchange

Composant Exchange Valeur ou description

Nombre de boîtes aux lettres cible

32 400

Taille moyenne de boîte aux lettres cible

2 gigaoctets (Go) (alloués dynamiquement à une taille initiale de 600 mégaoctets (Mo)

Profil de message moyen cible

100 messages par jour

Nombre de copies de bases de données

3

Sauvegarde VSS (Volume Shadow Copy Service)

Aucun

Résilience de site

Oui

Nombre de sites

3

Modèle de DAG (Groupe de disponibilité de base de données)

Distribution active/active (plusieurs DAG)

Virtualisation

Hyper-V

Nombre de serveurs Exchange

4 machines virtuelles

Nombre de serveurs physiques

2

Composants matériels

Composant matériel Valeur ou description

Partenaire solutions serveur

Cisco

Modèle de serveur

M200

Type de serveur

Lame

Processeur

Intel Xeon X5570

Partenaire solutions de stockage

Console de gestion Exchange (EMC)

Modèle de stockage

CX4-480

Type de stockage

Réseau SAN (Storage Area Network)

Type de disque

SAS 3,5" 450 Go de 15 000 tr/mn

Partenaire solutions d’équilibrage de charge

Cisco

Modèle d’équilibrage de charge matérielle

Ace

Return to top

L’une des premières étapes décisives du processus de conception de la solution Exchange est de résumer avec précision les exigences commerciales et techniques essentielles pour prendre les bonnes décisions de conception. Les sections suivantes décrivent les exigences du client concernant cette solution.

Return to top

Déterminez les exigences concernant le profil de boîte aux lettres de façon aussi précise que possible car ces dernières pourront avoir un impact sur tous les autres composants de la conception. Si vous n’avez jamais utilisé Exchange, vous devrez probablement formuler des hypothèses éclairées. Si vous travaillez déjà dans un environnement Exchange, vous pouvez utiliser l’outil Microsoft Exchange Server Profile Analyzer pour vous aider à rassembler la plupart de ces informations. Les tableaux suivants résument les exigences du profil de boîte aux lettres pour cette solution.

Exigences relatives au nombre de boîtes aux lettres

Exigence relative au nombre de boîtes aux lettres Valeur

Nombre de boîtes aux lettres (nombre total de boîtes aux lettres, notamment les boîtes aux lettres de ressources)

30 000

Pourcentage de croissance prévue (%) du nombre de boîtes aux lettres (augmentation prévue du nombre de boîtes aux lettres sur toute la durée de vie de la solution)

8 %

% de simultanéité prévue des boîtes aux lettres (nombre maximal de boîtes aux lettres actives à un moment donné)

100 %

Nombre de boîtes aux lettres cible (nombre de boîtes aux lettres, notamment la croissance x simultanéité prévue comprises)

32 400

Exigences relatives à la taille de boîte aux lettres

Exigence relative à la taille de boîte aux lettres Valeur

Taille moyenne de boîte aux lettres en Mo

600 MB

Taille moyenne de boîte aux lettres d’archivage en Mo

Non applicable

Croissance prévue (%) de la taille de boîte aux lettres en Mo (augmentation prévue de la taille des boîtes aux lettres sur toute la durée de vie de la solution)

230 %

Taille moyenne de boîte aux lettres cible en Mo

2 048 MB

Exigences relatives au profil de boîte aux lettres

Exigence relative au profil de boîte aux lettres Valeur

Profil de message cible (nombre total moyen de messages envoyés et reçus quotidiennement par utilisateur)

100 messages par jour

Taille moyenne de message cible en kilo-octets (Ko)

75

% en mode de mise en cache MAPI

100

% en mode en ligne MAPI

0

% en mode de mise en cache Outlook Anywhere

0

% dans Microsoft Office Outlook Web App (Outlook Web Access dans Exchange 2007 et versions précédentes)

0

% dans Exchange ActiveSync

0

Return to top

Bien comprendre la répartition des utilisateurs de boîtes aux lettres et des centres de données est essentielle lors de la prise de décisions de conception en matière de haute disponibilité et de résilience de site.

Le tableau suivant décrit la répartition géographique des futurs utilisateurs du système Exchange.

Répartition géographique des utilisateurs

Exigence relative au site utilisateur de boîte aux lettres Valeur

Nombre de sites importants comptant des utilisateurs de boîtes aux lettres

3

Nombre d’utilisateurs de boîtes aux lettres sur le site 1

10 800

Nombre d’utilisateurs de boîtes aux lettres sur le site 2

10 800

Nombre d’utilisateurs de boîtes aux lettres sur le site 3

10 800

Le tableau suivant décrit la répartition géographique des centres de données susceptibles de prendre en charge l’infrastructure de messagerie Exchange.

Répartition géographique des centres de données

Exigence relative au site du centre de données Valeur

Nombre total de centres de données

3

Nombre de boîtes aux lettres actives à proximité du centre de données 1

10 800

Nombre de boîtes aux lettres actives à proximité du centre de données 2

10 800

Nombre de boîtes aux lettres actives à proximité du centre de données 3

10 800

Résidence d’Exchange dans plusieurs centres de données

Oui

Return to top

Il est également important de définir les exigences de protection des serveurs et des données dans l’environnement car elles permettront d’orienter les décisions de conception en matière de haute disponibilité et de résilience de site.

Le tableau suivant identifie les exigences de protection des serveurs.

Exigences de protection des serveurs

Exigence de protection de serveur Valeur

Nombre de défaillances simultanées des serveurs et des machines virtuelles sur le site

1

Nombre de pannes simultanées des serveurs ou des machines virtuelles lors d’une défaillance de site

0

Le tableau suivant identifie les exigences de protection des données.

Exigences de protection des données

Exigence de protection des données Valeur ou description

Obligation de conserver une sauvegarde des bases de données Exchange en dehors de l’environnement Exchange (par exemple, solution de sauvegarde tierce)

Non

Obligation de conserver des copies des bases de données Exchange dans l’environnement Exchange (par exemple, protection native des données Exchange)

Oui

Obligation de conserver plusieurs copies des données de boîtes aux lettres dans le centre de données principal

Oui

Obligation de conserver plusieurs copies des données de boîtes aux lettres dans un centre de données secondaire

Non

Obligation de conserver une copie retardée de toutes les bases de données Exchange

Non

Période de copie retardée en jours

Non applicable

Nombre cible de copies de bases de données

3

Fenêtre de rétention du dossier des éléments supprimés en jours

14

Return to top

Cette section contient des informations qui ne sont pas habituellement recueillies dans le cadre de l’analyse des besoins du client, mais qui demeurent néanmoins essentielles à la conception et à l’approche de validation adoptée pour cette dernière.

Return to top

Le tableau suivant décrit les objectifs d’utilisation processeur en période de pointe dans des conditions normales de fonctionnement et des situations de défaillance ou de maintenance du serveur de site.

Objectifs d’utilisation du serveur

Principe de conception pour l’utilisation cible du processeur du serveur Valeur

Conditions normales de fonctionnement pour les serveurs de boîtes aux lettres

<70 %

Conditions normales de fonctionnement pour les serveurs d’accès au client

<70 %

Conditions normales de fonctionnement pour les serveurs de transport Hub

<70 %

Conditions normales de fonctionnement pour plusieurs rôles serveur (serveurs d’accès au client, de transport Hub et de boîtes aux lettres)

<70 %

Conditions normales de fonctionnement pour plusieurs rôles serveur (serveurs d’accès au client et de transport Hub)

<70 %

Défaillance de nœud pour les serveurs de boîtes aux lettres

<80 %

Défaillance de nœud pour les serveurs d’accès au client

<80 %

Défaillance de nœud pour les serveurs de transport Hub

<80 %

Défaillance de nœud pour plusieurs rôles serveur (serveurs d’accès au client, de transport Hub et de boîtes aux lettres)

<80 %

Défaillance de nœud pour plusieurs rôles serveur (serveurs d’accès au client et de transport Hub)

<80 %

Défaillance de site pour les serveurs de boîtes aux lettres

<80 %

Défaillance de site pour les serveurs d’accès au client

<80 %

Défaillance de site pour les serveurs de transport Hub

<80 %

Défaillance de site pour plusieurs rôles serveur (serveurs d’accès au client, de transport Hub et de boîtes aux lettres)

<80%

Défaillance de site pour plusieurs rôles serveur (serveurs d’accès au client et de transport Hub)

<80 %

Return to top

Les tableaux suivants résument certains principes de configuration et d’entrée/sortie (E/S) des données formulés lors de la conception de la configuration du stockage.

Principes de configuration des données

Principe de configuration des données Valeur ou description

Facteur de croissance des données

20 %

Nombre de déplacements de boîtes aux lettres par semaine

1 %

Maintenance dédiée ou restauration du numéro d’unité logique (LUN)

Non

Espace disponible du LUN

20 %

Compression de l’envoi de journaux activée

Oui

Chiffrement de l’envoi de journaux activé

Oui

Principes de configuration des E/S

Principe de configuration des E/S Valeur ou description

Facteur de croissance des E/S

20 %

Exigences supplémentaires relatives aux E/S

Aucun

Return to top

La section suivante présente une méthodologie par étapes pour concevoir cette solution. Cette méthodologie tient compte des exigences du client et des principes de conception, et examine les principales décisions de conception qui doivent être prises lors de la conception d’un environnement Exchange 2010.

Return to top

Lors de la conception d’un environnement Exchange 2010, de nombreuses décisions en matière de conception de stratégies haute disponibilité ont une incidence sur d’autres composants. Le processus de conception doit commencer de préférence par la définition d’une stratégie haute disponibilité. La consultation des informations suivantes avant de procéder à cette étape est vivement conseillée :

Si vous disposez de plusieurs centres de données, vous devez choisir entre un déploiement de l’infrastructure Exchange dans un seul centre de données ou sa répartition sur deux ou plusieurs centres de données. Les contrats de niveau de service (SLA) de récupération de votre organisation doivent définir le niveau de service requis suite à une défaillance du centre de données principal. Cette information doit servir de base à cette décision.

*Point de décision de conception*

Dans cette solution, il existe trois emplacements de centre de données physique. Le SLA indique qu’une résilience du centre de données est nécessaire pour tous les services essentiels, notamment la messagerie. La conception d’Exchange 2010 reposera sur un déploiement multisite avec résilience de site pour le service et les données de messagerie.

Dans cette étape, nous déterminons si tous les utilisateurs de boîtes aux lettres sont principalement situés sur un site ou répartis sur plusieurs sites, et si ces derniers sont associés à des centres de données. S’ils sont répartis sur plusieurs sites auxquels plusieurs centres de données sont associés, vous devez déterminer si un lien doit être maintenu entre les utilisateurs de boîtes aux lettres et le centre de données associé à ce site.

*Point de décision de conception*

Dans cet exemple, chacun des trois centres de données se trouve au même emplacement que les succursales. Il est souhaitable de maintenir un lien entre l’emplacement des utilisateurs et celui de la copie active principale de leur boîte aux lettres dans des conditions normales de fonctionnement.

Le client ayant décidé de déployer l’infrastructure Exchange à plusieurs emplacements physiques, il doit définir le modèle de distribution de bases de données le mieux adapté aux besoins de l’organisation. Il existe trois modèles de distribution de bases de données :

  • Distribution active/passive   Les copies de bases de données de boîtes aux lettres actives sont déployées dans le centre de données principal et seules les copies de bases de données passives sont déployées dans un centre de données secondaire. Le centre de données secondaire sert de centre de secours et aucune boîte aux lettres active n’est hébergée dans le centre de données dans des conditions normales de fonctionnement. Dans l’éventualité d’une panne affectant le centre de données principal, un basculement manuel vers le centre de données secondaire est effectué et les bases de données actives y sont hébergées jusqu’à la reconnexion du centre de données principal.

    Distribution active/passive

    Distribution de base de données active/passive
  • Distribution active/active (un seul DAG)   Les bases de données de boîtes aux lettres actives sont déployées dans les centres de données principal et secondaire. Une copie passive correspondante est située dans l’autre centre de données. Tous les serveurs de boîtes aux lettres sont membres d’un seul DAG. Dans ce modèle, la connexion WAN (Wide Area Network) entre deux centres de données constitue potentiellement un point de défaillance unique. L’interruption de la connexion WAN entraîne la mise hors service des serveurs de boîtes aux lettres de l’un des centres de données en raison d’une perte de quorum.

    Distribution active/active (un seul DAG)

    Distribution de base de données active/active avec DAG unique
  • Distribution active/active (plusieurs DAG)   Ce modèle exploite plusieurs DAG afin de remédier au point de défaillance unique que représente la connectivité WAN. Un DAG unique place les copies de bases de données actives dans le premier centre de données et les copies de bases de données passives correspondantes dans le deuxième centre de données. Le deuxième DAG place les copies de bases de données actives dans le second centre de données et les copies de bases de données passives correspondantes dans le premier centre de données. En cas de perte de la connectivité WAN, les copies actives sur chaque site continuent d’assurer la disponibilité de la base de données pour les utilisateurs de boîtes aux lettres.

    Distribution active/active (plusieurs DAG)

    Distribution active/active avec plusieurs DAG

*Point de décision de conception*

Dans cet exemple, du fait que les bases de données de boîtes aux lettres actives seront déployées à chacun des trois emplacements de centre de données, le modèle de distribution des bases de données sera actif/actif avec plusieurs DAG. Trois aspects de conception supplémentaires doivent être pris en compte lors du déploiement d’un modèle de distribution de bases de données active/active avec plusieurs DAG. Nous les aborderons plus loin.

Exchange 2010 inclut plusieurs fonctionnalités nouvelles et des changements majeurs qui, lorsqu’elles sont correctement déployées et configurées, assurent une protection native des données qui vient à bout des sauvegardes de données traditionnelles. Les sauvegardes sont habituellement utilisées pour la récupération d’urgence, la récupération d’éléments supprimés accidentellement, le stockage de données à long terme et la récupération de bases de données jusqu’à une date et une heure. Exchange 2010 peut traiter tous ces scénarios sans avoir besoin d’effectuer des sauvegardes traditionnelles :

  • Récupération d’urgence   En cas de défaillance logicielle ou matérielle, de nombreuses copies de bases de données dans un DAG assurent une disponibilité élevée et un basculement rapide sans perte de données. Les groupes de disponibilité peuvent être étendus à de nombreux sites et peuvent fournir une résilience par rapport aux échecs du centre de données.

  • Récupération des éléments supprimés accidentellement   Grâce au nouveau dossier Éléments récupérables d’Exchange 2010 et à la stratégie de rétention qui peut lui être appliquée, il est possible de conserver toutes les données supprimées et modifiées pendant une période donnée. Ainsi, la récupération de ces éléments est plus simple et plus rapide. Pour plus d’informations, voir Stratégie et conformité de messagerie, Présentation des éléments récupérables et Présentation des balises et stratégies de rétention.

  • Stockage de données à long terme   Parfois, les sauvegardes sont également utilisées à des fins d’archivage. En règle générale, une bande magnétique est utilisée pour conserver des clichés ponctuels de données pendant de longues périodes du fait d’exigences de confidentialité. Les nouvelles fonctionnalités d’archivage, de recherche de boîtes aux lettres multiples et de rétention de messages d’Exchange 2010 fournissent un mécanisme pour conserver efficacement les données de manière à les rendre accessibles à l’utilisateur pendant de longues périodes. Pour plus d’informations, voir Présentation des archives personnelles, Présentation de la recherche dans plusieurs boîtes aux lettres et Présentation des balises et stratégies de rétention.

  • Cliché de base de données ponctuel   Si une copie ponctuelle antérieure des données de la boîte aux lettres est requise pour votre organisation, Exchange offre la possibilité de créer une copie retardée dans un environnement DAG. Cette opération peut être utile au cas rare où une altération logique se réplique dans toutes les bases de données du groupe de disponibilité de base de données, impliquant de revenir au moment précédent. Cette opération peut également être utile si un administrateur supprime accidentellement des boîtes aux lettres ou les données d’un utilisateur.

Plusieurs raisons techniques et problèmes doivent être pris en compte avant d’utiliser les fonctionnalités intégrées à Exchange 2010 en remplacement des systèmes de sauvegarde traditionnels. Avant de prendre cette décision, reportez-vous à la section Présentation de la sauvegarde, de la restauration et de la récupération d'urgence.

*Point de décision de conception*

Dans l’implémentation Exchange actuelle illustrée dans cet exemple, la solution de sauvegarde traditionnelle a pour principal objectif de récupérer des éléments de messagerie accidentellement supprimés. Quatre-vingt pour cent des demandes de récupération d’élément unique concernent les messages datant de moins de 15 jours. Par conséquent, la période de rétention des éléments supprimés est fixée à 14 jours. Parce que les sauvegardes VSS traditionnelles ne sont pas nécessaires pour restaurer un élément unique et qu’elles ne répondent pas à l’objectif de temps de récupération, les fonctionnalités de protection native des données et de rétention du dossier des éléments supprimés d’Exchange seront utilisées comme stratégie de résilience de base de données.

La deuxième décision importante à prendre lors de la définition de votre stratégie de résilience de base de données concerne le nombre de copies de bases de données à déployer. Il est vivement recommandé de déployer au moins trois copies d’une base de données de boîtes aux lettres avant d’éliminer les formes classiques de protection de la base de données, telles que les sauvegardes RAID (Redundant Array of Independent Disks) ou VSS traditionnelles.

Avant de prendre cette décision, reportez-vous à la section Présentation des copies de bases de données de boîtes aux lettres.

*Point de décision de conception*

Étant donné que cet exemple, une solution de sauvegarde VSS traditionnelle n’est pas déployée, au moins trois copies de bases de données seront déployées pour s’assurer que les exigences en termes d’objectif de temps de récupération et d’objectif de point de récupération sont satisfaites. Deux copies seront situées dans le centre de données principal et une troisième copie sera placée dans un autre centre de données pour assurer la résilience de site.

Il existe deux types de copies de base de données :

  • Copie de base de données haute disponibilité   Cette copie de base de données est configurée sans aucun délai d’attente de relecture. Comme leur nom l’indique, les copies de bases de données haute disponibilité sont maintenues à jour par le système, peuvent être activées automatiquement par le système et sont utilisées pour assurer une disponibilité élevée du service et des données de messagerie.

  • Copie de base de données retardée   Cette copie de base de données est configurée pour retarder la relecture du journal des transactions pendant un laps de temps. Les copies de base de données retardées sont conçues pour offrir une protection ponctuelle contre l’altération logique de la banque d’informations, les erreurs administratives (par exemple, la suppression ou la purge d’une boîte aux lettres déconnectée) et les erreurs d’automatisation (telles que la purge en bloc des boîtes aux lettres déconnectées).

*Point de décision de conception*

Dans cet exemple, les trois copies de bases de données de boîtes aux lettres seront déployées sous forme de copies haute disponibilité. Le contrat de niveau de service ne requiert pas une copie retardée des données. Dans la mesure où aucune altération logique n’a été auparavant observée et où aucune autre application manipulant des données de messagerie n’est utilisée, une copie retardée n’est pas nécessaire. Le seul autre argument justifiant l’utilisation d’une copie retardée serait de pouvoir récupérer des éléments uniques supprimés. Cependant, cette exigence peut être beaucoup plus facilement et efficacement satisfaite à l’aide de la fonctionnalité de rétention du dossier Éléments supprimés.

Exchange 2010 a été repensé pour la résilience de boîte aux lettres. Une protection automatique contre le basculement est maintenant proposée au niveau de la base de données de boîtes aux lettres et non plus au niveau du serveur. Vous pouvez distribuer les copies de bases de données actives et passives de façon stratégique sur les serveurs de boîtes aux lettres au sein d’un DAG. La définition du nombre de copies de bases de données à activer pour chaque serveur constitue l’un des aspects clés de la planification des capacités d’Exchange 2010. Vous pouvez déployer différents modèles de distribution de bases de données. Toutefois, nous recommandons l’un des modèles suivants :

  • Modèle pour toutes les copies activées   Dans ce modèle, le rôle serveur de boîte aux lettres est dimensionné pour permettre l’activation de toutes les copies de bases de données sur le serveur. Par exemple, un serveur de boîtes aux lettres peut héberger quatre copies de bases de données. Dans des conditions normales de fonctionnement, le serveur peut avoir deux copies de bases de données actives et deux copies de bases de données passives. Lors d’une défaillance ou d’une opération de maintenance, les quatre copies de bases de données deviendraient actives sur le serveur de boîtes aux lettres. Cette solution est généralement déployée par paire. Par exemple, si quatre serveurs sont déployés, la première paire est constituée des serveurs MBX1 et MBX2, et la deuxième paire se compose des serveurs MBX3 et MBX4. En outre, lors de la conception de ce modèle, vous dimensionnerez chaque serveur de boîtes aux lettres pour un pourcentage maximal de 40 % des ressources disponibles dans des conditions normales de fonctionnement. Lors d’un déploiement de résilience de site avec trois copies de bases de données et six serveurs, ce modèle peut être déployé par groupes de trois serveurs, le troisième serveur résidant dans le centre de données secondaire. Ce modèle fournit un bloc de construction composé de trois serveurs pour les solutions utilisant un modèle de résilience de site active/passive.

    Il peut être utilisé dans les scénarios suivants :

    • Configuration multisite active/passive dans laquelle les domaines de défaillance (par exemple, racks, boîtiers de lames et baies de stockage) requièrent un isolement facile des copies de bases de données dans le centre de données principal

    • Configuration multisite active/passive dans laquelle la croissance prévue peut garantir un ajout facile d’unités d’échelle logiques

    • Configurations qui ne sont pas nécessaires pour surmonter la perte simultanée de l’un des deux serveurs de boîtes aux lettres dans le DAG

    Ce modèle requiert le déploiement des serveurs par paires pour les déploiements de site unique et par groupes de trois pour les déploiements multisite. Le tableau suivant fournit un exemple d’agencement de base de données pour ce modèle.

    Modèle pour toutes les copies activées

    Stratégie de résilience du serveur de boîtes aux lettres

    Dans le tableau précédent, la règle suivante s’applique :

    • C1 = copie active (valeur 1 de préférence d’activation) dans des conditions normales de fonctionnement

    • C2 = copie passive (valeur 2 de préférence d’activation) dans des conditions normales de fonctionnement

    • C3 = copie passive (valeur 3 de préférence d’activation) lors d’une défaillance de site

  • Modèle pour les scénarios de défaillance ciblés   Dans ce modèle, le rôle serveur de boîte aux lettres est conçu pour permettre l’activation d’un sous-ensemble de copies de bases de données sur le serveur. Le nombre de copies de bases de données dans le sous-ensemble varie selon le scénario de défaillance ciblé par la conception. L’objectif principal de ce modèle est de distribuer la charge de base de données active sur les autres serveurs de boîtes aux lettres du DAG.

    Ce modèle doit être utilisé dans les scénarios suivants :

    • Toutes les configurations de site unique comportant au moins trois copies de bases de données

    • Configurations requises pour surmonter la perte simultanée de l’un des deux serveurs de boîtes aux lettres dans le DAG

    La conception de DAG pour ce modèle requiert entre 3 et 16 serveurs de boîtes aux lettres. Le tableau suivant fournit un exemple d’agencement de base de données pour ce modèle.

    Conception pour les scénarios de défaillance ciblés

    Stratégie de résilience du serveur de boîtes aux lettres

    Dans le tableau précédent, la règle suivante s’applique :

    • C1 = copie active (valeur 1 de préférence d’activation) dans des conditions normales de fonctionnement

    • C2 = copie passive (valeur 2 de préférence d’activation) dans des conditions normales de fonctionnement

    • C3 = copie passive (valeur 3 de préférence d’activation) dans des conditions normales de fonctionnement

*Point de décision de conception*

Dans une étape précédente, il a été décidé de déployer un modèle de distribution de base de données active/active avec plusieurs DAG. Étant donné que chaque DAG de ce modèle présente une configuration active/passive avec seulement deux copies de bases de données haute disponibilité dans le centre de données principal, une stratégie de résilience de serveur de boîtes aux lettres conçue pour toutes les copies activées est une solution idéale.

Un DAG est le composant de base de l’architecture de haute disponibilité et de résilience de site intégrée à Exchange 2010. Un DAG est un groupe composé de 16 serveurs de boîtes aux lettres qui héberge un ensemble de bases de données répliquées et qui assure la récupération automatique au niveau de la base de données à la suite de défaillances affectant des bases de données ou des serveurs individuels.

Un DAG tient lieu de cadre pour la réplication de bases de données de boîtes aux lettres, le basculement et la permutation de bases de données et de serveurs et pour un composant interne appelé Active Manager. Active Manager est un composant d’Exchange 2010 qui gère les basculements et les permutations. Il s’exécute sur chaque serveur d’un DAG.

D’un point de vue de la planification, vous devez essayer de limiter le nombre de DAG déployés. Vous ne devez envisager plusieurs DAG que si :

  • Vous déployez plus de 16 serveurs de boîtes aux lettres.

  • Les utilisateurs de boîtes aux lettres actives sont répartis sur plusieurs sites (configuration de site active/active).

  • Des limites administratives distinctes doivent être définies au niveau du DAG.

  • Vos serveurs de boîtes aux lettres sont exécutés dans des domaines distincts. (Le DAG est lié au domaine.)

*Point de décision de conception*

Dans une étape précédente, il a été décidé de déployer un modèle de distribution de base de données active/active. Un DAG unique dont les utilisateurs de boîtes aux lettres actives sur répartis sur chaque site pourrait être déployé. Cependant, si les membres du DAG d’un site perdent temporairement la connexion avec ceux d’un autre site, le cluster de ce site perdra le quorum et cessera de fonctionner correctement. Pour cette raison, trois DAG seront déployés. Chaque DAG contiendra les serveurs de boîtes aux lettres du centre de données principal qui hébergera les copies de bases de données principale et secondaire. Chaque DAG contiendra également les serveurs de l’un des autres centres de données qui hébergera la troisième copie de base de données. La conception qui en résulte est donc de trois DAG actifs/passifs, chaque centre de données hébergeant les copies principale et secondaire d’un DAG, ainsi que les trois copies d’un autre DAG.

Dans cette étape, vous devez déterminer le nombre minimal de serveurs de boîtes aux lettres nécessaires pour prendre en charge la conception de DAG. Ce nombre peut différer du nombre de serveurs nécessaires pour supporter la charge de travail. La décision finale quant au nombre de serveurs à utiliser est prise ultérieurement.

*Point de décision de conception*

Dans une étape précédente, il a été décidé de déployer trois DAG actifs/passifs et d’élaborer une stratégie de résilience de serveur pour toutes les copies activées. Chaque DAG doit être déployé par incréments de trois serveurs (deux sur le site principal et un sur un autre site). Étant donné que trois DAG sont déployés, au moins neuf serveurs sont nécessaires pour prendre en charge la conception de DAG. La solution englobera 9, 18 ou 27 serveurs, selon le nombre de serveurs nécessaires pour supporter la charge de travail. Le tableau suivant décrit les configurations possibles.

Nombre de serveurs de boîtes aux lettres par DAG

Centre de données principal du DAG1 Centre de données secondaire du DAG1 Centre de données principal du DAG2 Centre de données secondaire du DAG2 Centre de données principal du DAG3 Centre de données secondaire du DAG3 Nombre total de serveurs de boîtes aux lettres

2

1

2

1

2

1

9

4

2

4

2

4

2

18

6

3

6

3

6

3

27

RemarqueRemarque :
Dans un modèle de DAG à trois nœuds, si vous perdez les deux nœuds dans le centre de données principal, le cluster perdra le quorum et l’activation automatique. La troisième copie du centre de données secondaire assurera la disponibilité des données supplémentaires, mais la récupération du service dans le centre de données secondaire sera une opération manuelle.

Return to top

Plusieurs facteurs influencent les besoins en capacité de stockage pour le rôle serveur de boîtes aux lettres. Pour de plus amples informations, nous vous invitons à consulter la section Présentation des facteurs de capacité des journaux et des bases de données de boîtes aux lettres.

Les étapes suivantes expliquent comment calculer les besoins en capacité des boîtes aux lettres. Ces besoins serviront ensuite à prendre des décisions sur les options de solution de stockage répondant le mieux aux exigences de capacité. Dans une autre section, nous aborderons les calculs supplémentaires nécessaires pour définir correctement la configuration de stockage sur la plate-forme choisie.

Microsoft a créé un Calculateur des besoins en stockage du rôle serveur de boîtes aux lettres qui se chargera d’une bonne partie de ce travail à votre place. Pour télécharger le calculateur, reportez-vous à la section Calculateur des besoins en stockage du rôle serveur de boîtes aux lettres E2010. Pour de plus amples informations sur le calculateur, reportez-vous à la section Calculateur des besoins en stockage du rôle serveur de boîtes aux lettres Exchange 2010.

Avant d’essayer d’évaluer tous vos besoins en stockage, vous devez identifier quelle sera la taille de boîte aux lettres sur le disque. Une boîte aux lettres pleine limitée à 1 Go requiert un espace disque de plus d’1 Go, car il faut prendre en compte la limite d’interdiction d’envoi/de réception, le nombre de messages que l’utilisateur envoie ou reçoit par jour, la fenêtre de rétention du dossier des éléments supprimés (avec ou sans activation des fonctionnalités de journalisation de la version du calendrier et de récupération d’élément unique), et les variations quotidiennes moyennes de base de données par boîte aux lettres. Le Calculateur des besoins du rôle serveur de boîtes aux lettres effectue ces calculs à votre place. Vous pouvez également utiliser les informations suivantes pour effectuer les calculs manuellement.

Les calculs suivants permettent de déterminer la taille de boîte aux lettres sur le disque pour une boîte aux lettres limitée à une taille de 2 Go dans cette solution :

  • Espace blanc = 100 messages par jour × 75 ÷ 1 024 Mo = 7,3 Mo

  • Benne = (100 messages par jour × 75 ÷ 1 024 Mo × 14 jours) + (2 048 Mo x 0,012) + (2 048 Mo x 0,058) = 246 Mo

  • Taille de boîte aux lettres sur le disque = limite de boîte aux lettres + espace blanc + benne

    = 2 048 + 7,3 + 246

    = 2 301 Mo

Dans cette étape, la capacité de stockage de haut niveau requise pour toutes les bases de données de boîtes aux lettres est déterminée. La capacité calculée inclut la taille de la base de données, la taille de l’index de catalogue et un espace disponible de 20 pour cent.

Pour déterminer la capacité de stockage requise pour toutes les bases de données, utilisez les formules suivantes :

  • Taille de la base de données = (nombre de boîtes aux lettres × taille de boîte aux lettres sur le disque × facteur de croissance supplémentaire de la base de données) + (facteur de croissance des données de 20 %)

    = (32 400 × 2 301 × 1) + (14 910 480)

    = 89 462 880 Mo

    = 87 366 Go

  • Taille de l’index de base de données = 10 % de la taille de la base de données

    = 87 366 × 0,10

    = 8 737 Go

  • Capacité totale de la base de données = (taille de la base de données) + (taille de l’index) ÷ 0,80 pour ajouter 20 % d’espace de volume disponible

    = (87 366 + 8 737) ÷ 0,8

    = 120 128 Go

Pour s’assurer que le serveur de boîtes aux lettres ne maintient aucune interruption due à des problèmes d’attribution d’espace, la taille des fichiers journaux des transactions doit également être définie de manière à s’adapter à tous les fichiers journaux qui seront générés au cours du jeu de sauvegardes. Sous réserve que cette architecture exploite les fonctionnalités de résilience de boîte aux lettres et de récupération d’élément unique, la capacité des journaux doit couvrir trois fois le pourcentage de génération quotidienne de journaux au cas où la copie endommagée ne serait pas réparée pendant trois jours. (Toute copie endommagée empêche la troncature des journaux.) Si le serveur n’est pas reconnecté dans les trois jours, il est préférable de supprimer temporairement la copie pour permettre la troncature.

Pour déterminer la capacité de stockage requise pour tous les journaux de transactions, utilisez les formules suivantes :

  • Taille des fichiers journaux = (taille de fichier journal × nombre de journaux quotidiens par boîte aux lettres × nombre de jours requis pour remplacer l’infrastructure défaillante × nombre d’utilisateurs de boîtes aux lettres) + (traitement du déplacement de boîtes aux lettres de 1 %)

    = (1 Mo × 20 × 4 × 32 400) + (32 400 × 0,01 × 2 048 Mo)

    = 3 255 552 Mo

    = 3 179 Go

  • Capacité totale du journal = taille des fichiers journaux ÷ 0,80 pour ajouter 20 % d’espace de volume disponible

    = (3 179) ÷ 0,80

    = 3 974

Le tableau suivant résume les besoins en termes de capacité de stockage de haut niveau pour cette solution. Nous utiliserons plus loin ces informations pour déterminer la solution de stockage à déployer. Vous examinerez ensuite en détail les besoins de stockage spécifiques.

Résumé des besoins en capacité de stockage

Espace disque requis Valeur

Taille moyenne de boîte aux lettres sur le disque (Mo)

2 301

Capacité de base de données requise (Go)

120 128

Capacité de journal requise (Go)

3 974

Capacité totale requise (Go)

124 102

Capacité totale requise pour trois copies de bases de données (Go)

372 306

Capacité totale requise pour trois copies de bases de données (téraoctets)

364

Capacité totale requise pour chaque site (téraoctets)

122

Return to top

Lors de la conception d’un environnement Exchange, il est essentiel de bien comprendre les facteurs de performance des bases de données et des journaux. Il est recommandé de consulter la rubrique Présentation des facteurs de performance des journaux et des bases de données.

Cette métrique constituant l’un des indicateurs clés d’E/S transactionnelles nécessaires au dimensionnement adéquat du stockage, il est essentiel de comprendre la quantité d’E/S de base de données par seconde (Ops ES/s) utilisées par chaque utilisateur de boîte aux lettres. Les opérations d’E/S séquentielles pures ne sont pas prises en compte dans le calcul du serveur de boîtes aux lettres par Ops ES/s car les sous-systèmes de stockage peuvent prendre en charge les E/S séquentielles de manière bien plus efficace que les E/S aléatoires. Ces opérations incluent la maintenance de la base de données en arrière-plan, les E/S de journal transactionnelles et les E/S de réplication des journaux. Dans cette étape, vous calculez le nombre total d’opérations d’E/S par seconde nécessaire pour prendre en charge tous les utilisateurs de boîtes aux lettres à l’aide de la formule suivante :

  • Ops ES/s estimées par utilisateur de boîte aux lettres = 0,10

  • Nombre total d’Ops ES/s requises = Ops ES/s par utilisateur de boîte aux lettres × nombre de boîtes aux lettres × facteur de croissance des E/S

    = 0,10 × 32 400 × 1,2

    = 3 888

RemarqueRemarque :
Pour déterminer le profil d’Ops ES/s pour un autre profil de message, reportez-vous au tableau « Cache de base de données et Ops ES/s estimées par boîte aux lettres en fonction de l’activité de messagerie » de la section Présentation des facteurs de performance des journaux et des bases de données.

S’agissant d’un déploiement multisite, vous devez réfléchir aux besoins en Ops ES/s par site afin de dimensionner correctement la solution de stockage pour chaque site. Dans une étape précédente, il a été décidé que chaque site hébergerait les copies de bases de données principale et secondaire du DAG principal et la troisième copie de base de données d’un autre DAG. Dans ce modèle, le pire scénario serait une défaillance de site unique où 10 800 boîtes aux lettres du DAG principal et 10 800 boîtes aux lettres du DAG secondaire sont actives sur le système de stockage de ce site. Effectuez le calcul suivant :

  • Nombre total d’Ops ES/s requises par site = Ops ES/s par utilisateur de boîte aux lettres × nombre de boîtes aux lettres × facteur de croissance des E/S

    = 0,10 × 21 600 × 1,2

    = 2 592

Return to top

Exchange 2010 intègre des améliorations en termes de performances, de fiabilité et de haute disponibilité qui permettent aux organisations d’exécuter Exchange sur une vaste palette d’options de stockage.

Lors de l’analyse des options de stockage disponibles, trouver un juste équilibre entre performances, capacité, complexité et impératifs de coûts est essentiel à la réalisation d’une solution de stockage réussie pour Exchange.

Pour plus d’informations sur le choix d’une solution de stockage pour Exchange 2010, reportez-vous à la section Conception du stockage de serveur de boîtes aux lettres.

Return to top

Il existe une multitude d’options de stockage pour Exchange 2010. La liste des options disponibles peut être réduite en optant entre le déploiement d’une solution DAS (Direct-Attached Storage) (notamment l’utilisation d’un disque local) et celui d’une solution SAN. Les raisons de choisir l’une au détriment d’une autre sont nombreuses et vous devez travailler en collaboration avec votre fournisseur privilégié de solutions de stockage pour identifier la solution répondant aux besoins de votre entreprise tout en réduisant le coût total de possession.

*Point de décision de conception*

Dans cet exemple, une infrastructure SAN est déployée et utilisée pour stocker toutes les données dans l’environnement. Une solution de stockage SAN continuera d’être utilisée et les options de déploiement d’Exchange 2010 seront étudiées en détail.

Return to top

Pour choisir une solution de stockage, suivez les étapes ci-dessous.

Dans cet exemple, le stockage ECM a été utilisé pendant de nombreuses années et une solution de stockage ECM sera utilisée pour le déploiement d’Exchange 2010. EMC Corporation propose des baies de stockage à hautes performances, telles que CLARiiON et Symmetric.

La gamme de solutions EMC CLARiiON fournit plusieurs niveaux de stockage, tels que les lecteurs flash d’entreprise, Fibre Channel et Serial ATA (SATA), qu’il est possible de gérer via une interface de gestion unique, permettant ainsi une réduction significative des coûts.

CLARiiON Virtual Provisioning offre des avantages allant bien au-delà du provisionnement dynamique traditionnel, notamment une fonctionnalité de gestion simplifiée du stockage et une utilisation améliorée des capacités. Vous pouvez présenter un volume de capacités important à un hôte, puis utiliser l’espace nécessaire à partir d’un pool partagé.

La série CLARiiON CX4 fournit quatre modèles offrant des niveaux flexibles de capacité, de fonctionnalité et de performance. Les fonctionnalités de chaque modèle sont décrites dans le tableau suivant.

Fonctionnalités de la série CLARiiON CX4

Fonctionnalité CX4 modèle 120 CX4 modèle 240 CX4 modèle 480 CX4 modèle 960

Nombre maximal de disques

120

240

480

960

Processeurs de stockage

2

2

2

2

Mémoire physique par processeur de stockage

3 GB

4 GB

8 GB

16 GB

Taille maximale du cache d’écriture

600 MB

1,264 GB

4,5 GB

10,764 GB

Nombre maximal d’initiateurs par système

256

512

512

1024

Hôtes haute disponibilité

128

256

256

512

Taille minimale du facteur de forme

6U

6U

6U

9U

Nombre maximal de LUN standard

1 024

1 024

4 096

4 096

Instantanés SnapView

Oui

Oui

Oui

Oui

Clones SnapView

Oui

Oui

Oui

Oui

Copie SAN

Oui

Oui

Oui

Oui

MirrorView/S

Oui

Oui

Oui

Oui

MirrorView/A

Oui

Oui

Oui

Oui

RecoverPoint/S

Oui

Oui

Oui

Oui

RecoverPoint/A

Oui

Oui

Oui

Oui

Dans cet exemple, des disques Fibre Channel 450 Go de 15 000 tr/mn sont sélectionnés. Ces derniers offrent de bonnes performances et capacités d’E/S pour répondre aux besoins initiaux des utilisateurs Exchange.

RemarqueRemarque :
Depuis les tests, les disques 600 Go de 10 000 tr/mn sont devenus plus abordables et constitueraient également un excellent choix pour ce déploiement.

Dans cet exemple, la solution doit offrir une capacité de stockage utilisable de 22 téraoctets et 2 592 Ops ES/s. L’une des options décrites dans le tableau précédent répondra aux besoins en Ops ES/s. La décision sera donc basée sur les besoins en capacité. Le modèle 240 CLARiiON CX4 n’offre une capacité exploitable approximative de 100 téraoctets qu’avec des disques de 450 Go dans une configuration RAID-5. Le modèle 480 EMC CLARiiON CX4 est retenu car il offre la capacité et les performances d’E/S nécessaires pour satisfaire toutes les conditions requises d’Exchange 2010.

Return to top

Un dimensionnement adéquat de la mémoire est une étape essentielle de la conception d’un environnement Exchange sain. Il est recommandé de consulter les sections Présentation des configurations mémoire et des performances Exchange et Présentation du cache de la base de données de boîtes aux lettres.

Return to top

Le moteur ESE (Extensible Storage Engine) utilise le cache de base de données pour réduire les opérations d’E/S. En règle générale, plus la quantité disponible de cache de base de données est élevée, plus le nombre d’E/S générées sur un serveur de boîtes aux lettres Exchange 2010 est réduit. Cependant, vient un moment où l’ajout d’un cache de base de données supplémentaire ne permet plus de réduire le nombre d’Ops ES/s de manière significative. Par conséquent, l’ajout de quantités importantes de mémoire physique à votre serveur Exchange sans déterminer la quantité optimale de cache de base de données requise peut engendrer une augmentation des coûts sans aucun avantage réel en termes de performances.

Les estimations du nombre d’Ops ES/s que vous avez effectuées précédemment supposent une quantité minimale de cache de base de données par boîte aux lettres. Ces quantités minimales sont résumées dans le tableau « Ops ES/s estimées par boîte aux lettres en fonction de l’activité de messagerie et du cache de base de données de boîte aux lettres » de la section Présentation du cache de la base de données de boîtes aux lettres.

Le tableau suivant décrit le cache de base de données par utilisateur pour divers profils de message.

Cache de base de données par utilisateur

Messages envoyés ou reçus quotidiennement par boîte aux lettres (taille moyenne de message d’environ 75 Ko) Cache de base de données par utilisateur (Mo)

50

3 MB

100

6 MB

150

9 MB

200

12 MB

Dans cette étape, vous déterminez la configuration de mémoire de haut niveau requise pour l’intégralité de l’environnement. Plus loin, vous utiliserez ce résultat pour identifier la quantité de mémoire physique nécessaire pour chaque serveur de boîtes aux lettres. Effectuez le calcul suivant :

  • Cache de base de données = cache de base de données spécifique au profil × nombre d’utilisateurs de boîtes aux lettres

    = 6 Mo × 32 400

    = 194 400 Mo

    = 190 Go

Return to top

La planification de la capacité du serveur de boîtes aux lettres a évolué considérablement depuis les versions précédentes d’Exchange en raison du nouveau modèle de résilience de base de données de boîtes aux lettres fourni dans Exchange 2010. Pour de plus amples informations, reportez-vous à la section Planification des capacités du processeur du serveur de boîtes aux lettres.

Dans les étapes suivantes, vous calculez les besoins en mégacycles de haut niveau pour les copies de bases de données actives et passives. Ces besoins serviront ultérieurement à déterminer le nombre de serveurs de boîtes aux lettres nécessaires pour supporter la charge de travail. Notez que le nombre de serveurs de boîtes aux lettres requis varie également en fonction du modèle de résilience de serveur de boîtes aux lettres et de la disposition des copies de bases de données.

L’identification, à partir des besoins en mégacycles, du nombre d’utilisateurs de boîtes aux lettres qu’un serveur de boîtes aux lettres Exchange peut prendre en charge n’est pas une science exacte. Un certain nombre de facteurs peut produire des résultats de mégacycle inattendus dans les environnements de test et de production. Les mégacycles ne doivent être utilisés que pour obtenir une estimation du nombre d’utilisateurs de boîtes aux lettres pouvant être pris en charge par un serveur de boîtes aux lettres Exchange. Mieux vaut être prudent qu’audacieux en ce qui a trait au volet de planification des capacités du processus de conception.

Les calculs suivants sont basés sur les estimations de mégacycles publiées, résumées dans le tableau suivant.

Estimations des mégacycles

Messages envoyés ou reçus par boîte aux lettres par jour Mégacycles par boîte aux lettres pour la base de données de boîtes aux lettres active Mégacycles par boîte aux lettres pour la base de données de boîtes aux lettres passives Mégacycles par boîte aux lettres pour les boîtes aux lettres passives locales

50

1

0.1

0.15

100

2

0.2

0.3

150

3

0.3

0.45

200

4

0.4

0.6

Dans cette étape, vous calculez les mégacycles nécessaires pour prendre en charge les copies de bases de données actives, à l’aide de la formule suivante :

  • Mégacycles de boîtes aux lettres actives requis = mégacycles spécifiques à un profil × nombre d’utilisateurs de boîtes aux lettres

    = 2 × 32 400

    = 64 800

Dans une conception comprenant trois copies de chaque base de données, une surcharge du processeur est associée à l’envoi des journaux nécessaires pour gérer les copies de bases de données sur les serveurs distants. Cette surcharge représente généralement 10 pour cent des mégacycles de boîtes aux lettres actives pour chaque copie distante traitée. Calculez les besoins à l’aide de la formule suivante :

  • Mégacycles de copies distantes requis = mégacycles spécifiques à un profil × nombre d’utilisateurs de boîtes aux lettres × nombre de copies distantes

    = 0,1 × 32 400 × 2

    = 6 480

Dans une conception comprenant trois copies de chaque base de données, une surcharge du processeur est associée à la gestion des copies passives locales de chaque base de données. Les mégacycles de haut niveau nécessaires pour prendre en charge les copies de bases de données passives locales seront calculés dans cette étape. Ces données seront affinées ultérieurement afin de les faire correspondre à la stratégie de résilience de serveur et à la disposition des copies de bases de données. Calculez les besoins à l’aide de la formule suivante :

  • Mégacycles de boîtes aux lettres passives locales requis = mégacycles spécifiques à un profil × nombre d’utilisateurs de boîtes aux lettres × nombre de copies passives

    = 0,3 × 32 400 × 2

    = 19 440

Calculez les besoins totaux à l’aide de la formule suivante :

Nombre total de mégacycles requis = boîte aux lettres active + passive distante + passive locale

= 64 800 + 6 480 + 19 440

= 90 720

Nombre moyen de mégacycles par boîte aux lettres = 90 720 ÷ 32 400 = 2,8

Return to top

Le tableau suivant résume le nombre approximatif de mégacycles et le cache de base de données nécessaires pour cet environnement. Ces informations seront utilisées ultérieurement pour identifier les serveurs qui seront déployés dans la solution.

Résumé de la configuration de boîte aux lettres requise

Besoins en processeur des boîtes aux lettres Valeur

Nombre total de mégacycles requis pour tout l’environnement

97200

Cache de base de données total requis pour tout l’environnement

190 GB

Return to top

Vous pouvez suivre les étapes ci-dessous pour déterminer le modèle de serveur.

Dans cette solution, la plate-forme de serveur préférée est Cisco Unified Computing System, une plate-forme de centre de données qui regroupe des fonctionnalités de calcul, réseau, de stockage et de virtualisation dans un système unique conçu pour réduire le coût total de possession et accroître la souplesse. Le système intègre une structure réseau unifiée 10-gigabit Ethernet à faible latence composée de serveurs d’une architecture x86 de classe entreprise. Grâce à une approche systémique de l’architecture, des technologies, des partenariats et des services, Cisco Unified Computing System rationalise les ressources du centre de données, adapte les prestations de services et réduit le nombre de périphériques exigeants en configuration, gestion, alimentation, refroidissement et câblage.

Cisco Unified Computing System est un système de serveur lame comprenant quatre composants système principaux. Ces composants système sont les modules d’interconnexion de structure, les châssis, les modules d’extension de structure (modules d’E/S) et les serveurs lames.

Les modèles de serveur lame suivants sont des options possibles pour cette solution.

Option 1 : Serveur lame B200

Le serveur lame B200 Cisco Unified Computing System est un serveur lame demi-largeur à deux sockets. Ce système utilise deux processeurs de série 5500 ou 5600 Intel Xeon, jusqu’à 96 Mo de mémoire DDR3, deux disques durs SAS de petit format échangeables à chaud en option et une carte mezzanine unique pour un débit d’E/S pouvant atteindre 20 gigabits par seconde (Gbits/s). Ce serveur allie simplicité, performances et densité pour une virtualisation au niveau de la production et d’autres charges de travail standard du centre de données.

Option 2 : Serveur lame B250

Le serveur lame à extension de mémoire B250 Cisco Unified Computing System est un serveur lame pleine largeur à deux sockets intégrant la technologie d’extension de mémoire Cisco. Ce système prend en charge deux processeurs de série 5500 ou 5600 Intel Xeon, jusqu’à 384 Mo de mémoire DDR3, deux disques durs SAS de petit format en option et deux cartes mezzanine pour un débit d’E/S pouvant atteindre 40 gigabits par seconde (Gbits/s). Le serveur optimise les performances et les capacités pour la virtualisation et les charges de travail importantes.

Option 3 : Serveur lame B440

Le serveur lame B440 Cisco Unified Computing System a été conçu pour accroître la puissance des applications d’entreprise, telles que les jeux de données volumineux et les bases de données riches en transactions, les progiciels de gestion intégrée et les systèmes de support de décision (DSS). S’appuyant sur les fonctionnalités performantes, fiables et évolutives des processeurs série 7500 Intel Xeon, le serveur B440 Cisco Unified Computing System permet d’élargir la portée de la virtualisation des charges de travail et centralise les applications autonomes exigeantes dans une infrastructure intégrée et simplifiée. Le serveur B440 Cisco Unified Computing System prend en charge jusqu’à 32 cœurs de traitement et une mémoire principale de 256 Go combinée à un débit d’E/S pouvant atteindre 40 Gbits/s.

Le serveur lame B200 Cisco Unified Computing System doté des processeurs Intel Xeon X5570 a été retenu car il dosait subtilement puissance de traitement, capacité de mémoire et facteur de forme pour ce déploiement. La plate-forme de serveur à deux sockets constitue généralement un excellent choix pour les déploiements d’Exchange 2010, sur la base de tous les facteurs pertinents, notamment l’évolutivité et les coûts. Le serveur B250 Cisco Unified Computing System offre une configuration de mémoire et un débit d’E/S supérieurs, même si cela n’est pas essentiel pour la solution.

RemarqueRemarque :
Depuis les tests, les disques 600 Go de 10 000 tr/mn sont devenus plus abordables et constitueraient également un excellent choix pour ce déploiement.

Return to top

Dans les étapes précédentes, vous avez calculé les mégacycles nécessaires pour prendre en charge le nombre d’utilisateurs de boîtes aux lettres actives. Dans les étapes suivantes, vous calculerez le nombre de mégacycles pouvant être pris en charge par le modèle et le processeur du serveur afin de déterminer la capacité de prise en charge de boîtes aux lettres actives pour chaque serveur.

Parce que les besoins en mégacycles reposent sur un modèle de serveur et de processeur de référence, vous devez ajuster les mégacycles disponibles pour le serveur par rapport à cette référence. Pour cela, des critères d’évaluation de performances indépendants gérés par SPEC (Standard Performance Evaluation Corporation) sont utilisés. SPEC est une organisation à but non lucratif qui a été créée dans le but d’établir, de gérer et d’adopter un ensemble normalisé de critères pertinents pouvant être appliqués à la dernière génération d’ordinateurs hautes performances.

Pour simplifier le processus d’identification de la valeur de référence pour votre serveur et processeur, nous vous recommandons d’utiliser l’outil de recherche de processeur Exchange. Cet outil automatise les étapes manuelles pour déterminer la fréquence SPECint 2006 du processeur prévu. Pour exécuter cet outil, votre ordinateur doit être connecté à Internet. L’outil de recherche utilise votre modèle de processeur prévu comme donnée de départ, puis effectue une recherche sur le site Web de Standard Performance Evaluation Corporation afin de renvoyer toutes les données de test correspondantes. Il calcule également une fréquence SPECint 2006 moyenne selon le nombre de processeurs que vous envisagez d’utiliser dans chaque serveur de boîtes aux lettres. Effectuez le calcul suivant :

  • Processeur = Intel X5570 2,93 gigahertz (GHz)

  • Fréquence SPECint_rate2006 = 256

  • Fréquence SPECint_rate2006 par cœur de processeur = 256 ÷ 8

    = 32

Dans les étapes précédentes, vous avez calculé les mégacycles requis pour l’intégralité de l’environnement d’après les estimations des mégacycles par boîte aux lettres. Ces estimations ont été mesurées sur un système de base (HP DL380 G5 x5470 3,33 GHz, 8 cœurs) doté d’une fréquence SPECint_rate2006 de 150 (pour un serveur à 8 cœurs), soit de 18,75 par cœur.

Dans cette étape, vous devez ajuster les mégacycles disponibles pour le serveur et le processeur par rapport au processeur de base afin que les mégacycles requis puissent être utilisés lors de la planification des capacités.

Pour déterminer les mégacycles de la plate-forme Cisco B200-M1 Intel X5570 2,93 GHz, utilisez les formules suivantes :

  • Mégacycles ajustés par cœur = (valeur par cœur de la nouvelle plate-forme) × (nombre d’hertz par cœur de la plate-forme de base) ÷ (valeur de base par cœur)

    = (32 × 3 330) ÷ 18,75

    = 5 683

  • Mégacycles ajustés par serveur = mégacycles ajustés par cœur × nombre de cœurs

    = 5 683 × 8

    = 45 466

Maintenant que les mégacycles ajustés par serveur sont identifiés, vous devez ajuster l’utilisation maximale cible du processeur. Dans une section précédente, il a été décidé de ne pas dépasser une utilisation de processeur de 80 pour cent en période de pointe ou lors de scénarios de défaillance. Effectuez le calcul suivant :

  • Mégacycles disponibles ajustés = mégacycles disponibles par serveur × utilisation maximale cible du processeur

    = 45 466 × 0,80

    = 36 372

Chaque serveur possède une capacité exploitable de 36 372 mégacycles.

Return to top

Vous pouvez suivre les étapes ci-dessous pour déterminer le nombre de serveurs de boîtes aux lettres physiques requis.

Pour déterminer le nombre de boîtes aux lettres actives prises en charge par un serveur de boîtes aux lettres, effectuez le calcul suivant :

  • Nombre de boîtes aux lettres actives = mégacycles disponibles par serveur ÷ mégacycles par boîte aux lettres

    = 36 372 ÷ 2.8

    = 12 990

Chaque DAG comprend 10 800 boîtes aux lettres actives. Pour déterminer le nombre minimal de serveurs de boîtes aux lettres requis pour prendre en charge toutes les boîtes aux lettres d’un DAG, effectuez le calcul suivant :

  • Nombre de serveurs requis = nombre total de boîtes aux lettres par DAG ÷ boîtes aux lettres actives par serveur

    = 10 800 ÷ 12 990

    = 0,83

Au moins un serveur de boîtes aux lettres est nécessaire à chaque DAG pour supporter la charge de travail de 10 800 boîtes aux lettres.

Dans une étape précédente, il a été décidé de concevoir une solution pour toutes les copies activées dans un DAG actif/passif. Ce modèle nécessite le déploiement de rôles serveur de boîtes aux lettres par groupes de trois pour chaque DAG.

Nombre de serveurs de boîtes aux lettres et DAG

Centre de données principal du DAG1 Centre de données secondaire du DAG1 Centre de données principal du DAG2 Centre de données secondaire du DAG2 Centre de données principal du DAG3 Centre de données secondaire du DAG3 Nombre total de serveurs de boîtes aux lettres

2

1

2

1

2

1

9

4

2

4

2

4

2

18

6

3

6

3

6

3

27

En fonction de la conception de DAG, au moins trois serveurs de boîtes aux lettres physiques dans chaque DAG ou un total de neuf serveurs de boîtes aux lettres physiques pour les trois DAG sont nécessaires.

Return to top

Vous pouvez suivre les étapes ci-dessous pour déterminer le nombre de boîtes aux lettres actives par serveur de boîtes aux lettres dans des conditions normales de fonctionnement et des scénarios de défaillance.

Pour déterminer le nombre de boîtes aux lettres actives hébergées par chaque serveur de boîtes aux lettres dans des conditions normales de fonctionnement, effectuez le calcul suivant :

  • Nombre de boîtes aux lettres par serveur = nombre total de boîtes aux lettres dans le DAG ÷ nombre de serveurs de boîtes aux lettres dans le centre de données principal

    = 10 800 ÷ 2

    = 5 400

Dans l’éventualité d’une défaillance d’un serveur de boîtes aux lettres dans le centre de données principal, les 5 400 boîtes aux lettres actives sur le serveur défaillant deviendront actives sur l’autre serveur. Dans ce scénario, le serveur de boîtes aux lettres restant contiendra 10 800 boîtes aux lettres actives.

En cas de déconnexion du centre de données principal, les 10 800 boîtes aux lettres actives dans le centre de données principal seront activées dans le centre de données secondaire. Dans ce scénario, le seul serveur du centre de données secondaire contiendra 10 800 boîtes aux lettres actives.

Return to top

Lors de la définition du nombre de rôles serveur d’accès au client et de transport Hub à déployer dans des environnements composés d’un nombre réduit de serveurs, vous pouvez envisager de déployer les deux rôles sur le même ordinateur physique. Cela réduit le nombre d’ordinateurs physiques à gérer, le nombre de systèmes d’exploitation de serveur à mettre à jour et à gérer, et le nombre de licences Windows et Exchange que vous avez besoin d’acheter. La combinaison des rôles serveur d’accès au client et de transport Hub a pour autre avantage de simplifier le processus de conception. Lors du déploiement de rôles isolés, il est recommandé de déployer un processeur logique de serveur de transport Hub pour chaque groupe de quatre processeurs logiques de serveur de boîtes aux lettres et trois processeurs logiques de serveur d’accès au client pour chaque groupe de quatre processeurs logiques de boîte aux lettres. Ce système peut prêter à confusion, notamment lorsque vous envisagez de prévoir suffisamment de serveurs d’accès au client et de transport Hub lors de scénarios de défaillance ou de maintenance de plusieurs serveurs physiques. Lors du déploiement de serveurs d’accès au client et de transport Hub et de serveurs de boîtes aux lettres sur des serveurs physiques ou des machines virtuelles similaires, vous pouvez installer une combinaison de serveurs Accès au client/Transport Hub pour chaque serveur de boîtes aux lettres sur le site.

*Point de décision de conception*

Dans cette solution, il a été décidé de faire coexister les rôles serveur de transport Hub et d’accès au client sur le même ordinateur physique. Cela réduira le nombre de systèmes d’exploitation à gérer et simplifiera également la planification de la résilience de serveur.

Return to top

Dans une étape précédente, vous avez déterminé que trois serveurs de boîtes aux lettres étaient nécessaires sur chaque site (deux serveurs de boîtes aux lettres du DAG hébergeant les boîtes aux lettres actives pour ce site et un serveur de boîtes aux lettres d’un autre DAG prenant en charge la résilience de site en cas de défaillance du centre de données principal pour ce DAG).

Il est recommandé de déployer une combinaison de serveurs Accès au client/Transport Hub pour chaque serveur de boîtes aux lettres, comme indiqué dans le tableau suivant.

Nombre de serveurs combinés Accès au client/Transport Hub physiques requis

Configuration du rôle serveur Rapport de coeurs de processeur recommandé

Boîtes aux lettres:rôle serveur combiné Accès au client/Transport Hub

1:1

Lorsque plusieurs DAG sont représentés sur le même site, vous devez examiner le scénario de défaillance le plus défavorable avant de pouvoir déterminer le nombre de serveurs combinés Accès au client/Transport Hub requis. Dans cette solution, le pire scénario de défaillance serait de perdre l’un des deux serveurs de boîtes aux lettres dans le DAG principal et d’être confronté à une défaillance de site simultanée qui obligerait à héberger les boîtes aux lettres actives d’un autre site sur le même site. Dans ce cas, 21 600 boîtes aux lettres actives du site seront exécutées sur deux serveurs de boîtes aux lettres et vous aurez donc besoin d’au moins deux serveurs combinés Accès au client/Transport Hub sur chaque site, comme indiqué dans la figure suivante.

Serveurs d’accès au client et de transport Hub

à déterminer

Return to top

Jusqu’à présent, vous avez établi que 15 serveurs physiques sont nécessaires pour prendre en charge les rôles serveur d’accès au client, de transport Hub et de boîtes aux lettres pour 32 400 boîtes aux lettres actives dans trois centres de données, comme indiqué dans la figure suivante.

Nombre de serveurs physiques requis

à déterminer

Return to top

Plusieurs facteurs doivent être pris en compte lorsque vous envisagez d’utiliser la virtualisation de serveur pour Exchange. Pour de plus amples informations sur les configurations prises en charge pour la virtualisation, reportez-vous à la section Configuration requise pour Exchange 2010.

Songez à utiliser la virtualisation avec Exchange pour les raisons suivantes :

  • Si vous pensez que les capacités du serveur seront sous-exploitées et anticipez une meilleure utilisation, vous pouvez acheter moins de serveurs à la suite d’une virtualisation.

  • Vous pouvez utiliser la fonctionnalité d’équilibrage de charge réseau (NLB) Windows lors du déploiement de rôles serveur d’accès au client, de transport Hub et de boîtes aux lettres sur le même serveur physique.

  • Si votre organisation utilise la virtualisation sur l’intégralité de l’infrastructure serveur, vous pouvez utiliser la virtualisation avec Exchange conformément à la stratégie standard de l’entreprise.

Pour déterminer si la virtualisation doit être utilisée dans cet environnement, essayez d’anticiper l’utilisation du processeur et évaluez le risque de sous-exploitation des serveurs.

Pour déterminer l’utilisation du processeur de 5 400 boîtes aux lettres actives sur un serveur de boîtes aux lettres unique, effectuez le calcul suivant :

  • Pourcentage d’utilisation du processeur (conditions normales de fonctionnement en période de pointe) = mégacycles requis ÷ mégacycles disponibles

    = (5400 × 2.8) ÷ 45466

    = 33.2%

Pour déterminer le taux d’utilisation du processeur de 10 800 boîtes aux lettres actives sur un serveur de boîtes aux lettres unique, effectuez le calcul suivant :

  • Pourcentage d’utilisation du processeur (conditions de défaillance en période de pointe) = mégacycles requis ÷ mégacycles disponibles

    = (10800 × 2.8) ÷ 45466

    = 66.5%

*Point de décision de conception*

Comme le taux d’utilisation du serveur devrait être inférieur à l’objectif de 80 pour cent pour le pire scénario de défaillance, il est possible de réduire le nombre de serveurs à l’aide de la virtualisation. Cette possibilité sera abordée plus loin en détail.

Return to top

Dans les étapes suivantes, vous déterminerez si la virtualisation peut être utilisée pour réduire le nombre de serveurs physiques requis dans cette solution. Microsoft Hyper-V sera utilisé comme plate-forme de virtualisation.

À la date de réalisation des tests, Microsoft Hyper-V prend en charge jusqu’à quatre processeurs virtuels par machine virtuelle. Lors de la conception physique, le rôle serveur de boîtes aux lettres pour le DAG principal a été déployé sur deux serveurs physiques avec un total de 16 processeurs logiques. Grâce à la virtualisation, le rôle serveur de boîtes aux lettres pour le DAG principal est maintenant déployé sur quatre machines virtuelles, chacune dotée de quatre processeurs virtuels pour un total de 16 processeurs virtuels.

Lors de la conception physique, le rôle serveur de boîtes aux lettres pour le DAG secondaire a été déployé sur un serveur physique unique doté de 8 processeurs logiques. Grâce à la virtualisation, le rôle serveur de boîtes aux lettres pour le DAG secondaire est maintenant déployé sur deux machines virtuelles, chacune comportant quatre processeurs virtuels pour un total de huit processeurs virtuels.

Lors de la conception physique, le serveur combiné Accès au client/Transport Hub a été déployé sur deux serveurs physiques avec un total de 16 processeurs logiques. Grâce à la virtualisation, les serveurs combinés Accès au client/Transport Hub sont maintenant déployés sur quatre machines virtuelles, chacune dotée de quatre processeurs virtuels pour un total de 16 processeurs virtuels.

Lors de l’utilisation de serveurs racine Hyper-V à huit processeurs logiques, il est recommandé de déployer une machine virtuelle de serveur de boîtes aux lettres et une machine virtuelle de serveur combiné Accès au client/Transport Hub sur chaque serveur racine Hyper-V.

La solution comporte à présent 10 machines virtuelles exécutées sur cinq serveurs physiques dans chaque site, comme indiqué dans la figure suivante.

Machines virtuelles

à déterminer

Selon les calculs effectués aux étapes précédentes, vous estimez que les besoins en mégacycles de la charge de travail la plus lourde peuvent être satisfaits avec quatre serveurs physiques. Dans cette étape, vous passerez de cinq à quatre serveurs physiques et redistribuerez les serveurs de boîtes aux lettres du DAG secondaire vers les quatre serveurs physiques restants. Pour maintenir la symétrie sur les quatre serveurs physiques, vous devrez remplacer les deux machines virtuelles du serveur de boîtes aux lettres (comportant quatre processeurs virtuels) par quatre machines virtuelles de serveur de boîtes aux lettres.

Cela se traduit par l’exécution de 12 machines virtuelles sur quatre serveurs physiques dans chaque site, comme indiqué dans les figures suivantes.

Machines virtuelles

à déterminer

Machines virtuelles

à déterminer

Dans cette étape, vous évaluerez le nombre de processeurs virtuels requis pour chaque machine virtuelle. Dans les étapes suivantes, vous effectuerez les calculs pour vérifier les hypothèses formulées.

Chacune des quatre machines virtuelles du serveur de boîtes aux lettres présentes dans le DAG principal prendra en charge 25 pour cent des 10 800 boîtes aux lettres actives du DAG dans des conditions normales de fonctionnement ou 2 700 boîtes aux lettres. En cas de défaillance d’un serveur, la machine virtuelle de serveur de boîtes aux lettres restante devra prendre en charge 5 400 boîtes aux lettres actives.

En cas de défaillance d’un site, chacune des quatre machines virtuelles du serveur de boîtes aux lettres présentes dans le DAG principal prendra en charge 25 pour cent des 10 800 boîtes aux lettres actives du DAG ou 2 700 boîtes aux lettres. Dans ce scénario, les boîtes aux lettres seront exécutées sur la troisième et dernière copie de la base de données. Dans l’éventualité d’une défaillance de serveur ou de machine virtuelle, la machine virtuelle restante devra prendre en charge 5 400 boîtes aux lettres actives. Le nombre maximal de boîtes aux lettres sera toujours de 2 700.

Il est logique que les machines virtuelles du DAG secondaire ne comptent que la moitié des processeurs des machines virtuelles du DAG principal. Dans cette solution, affectez quatre processeurs virtuels aux machines virtuelles du DAG principal et deux processeurs virtuels aux machines virtuelles du DAG secondaire.

Si vous maintenez un ratio de processeurs virtuel/logique de 1:1, il reste deux processeurs virtuels pour chaque serveur combiné Accès au client/Transport Hub. Parce que vous souhaitez maintenir un ratio de cœurs de serveur de boîtes aux lettres/serveur combiné Accès au client/Transport Hub de 1:1, affectez quatre processeurs virtuels à chaque serveur combiné Accès au client/Transport Hub. Cela donne lieu à un scénario où le nombre de processeurs virtuels dépasse celui des processeurs physiques sur le serveur racine. C’est ce que l’on appelle la sursollicitation. Dans la plupart des cas, il est déconseillé d’utiliser la sursollicitation. Toutefois, dans cette solution, les machines virtuelles du serveur de boîtes aux lettres dans le DAG secondaire ne seront utilisées qu’en cas de défaillance d’un site. Compte tenu de la faible probabilité d’occurrence de cet événement, une légère sursollicitation est acceptable.

Le tableau suivant présente les affectations de processeur virtuel proposées.

Affectation de processeur virtuel

Machine virtuelle Nombre de processeurs virtuels

Combinaison de serveurs d’accès au client/Transport Hub

3

Boîte aux lettres (DAG principal)

4

Boîte aux lettres (DAG secondaire)

2

Total

9

Return to top

Dans les étapes précédentes, vous avez calculé les mégacycles nécessaires pour prendre en charge le nombre d’utilisateurs de boîtes aux lettres actives. Dans les étapes suivantes, vous calculerez le nombre de mégacycles disponibles pouvant être pris en charge par le modèle et le processeur de serveur afin de déterminer la capacité de prise en charge de boîtes aux lettres actives pour chaque serveur.

Return to top

Lors du déploiement de machines virtuelles sur le serveur racine, vous devez tenir compte des mégacycles nécessaires pour prendre en charge l’hyperviseur et la pile de virtualisation. Cette surcharge varie d’un serveur à un autre et en fonction des charges de travail. Une estimation prudente de 10 pour cent de mégacycles disponibles sera utilisée, comme indiqué dans le calcul suivant :

  • Mégacycles disponibles ajustés = mégacycles disponibles × 0,90

    = 45 466 × 0,90

    = 40 919

Chaque serveur offre une capacité exploitable pour les machines virtuelles de 40 919 mégacycles.

La capacité exploitable par processeur logique est de 5 115 mégacycles.

Return to top

Dans une étape précédente, vous avez déterminé l’affectation de processeur virtuel pour les trois types de machines virtuelles, comme indiqué dans le tableau suivant.

Affectation de processeur virtuel

Machine virtuelle Nombre de processeurs virtuels

Combinaison de serveurs d’accès au client/Transport Hub

3

Boîte aux lettres (DAG principal)

4

Boîte aux lettres (DAG secondaire)

2

Total

9

Du fait que neuf processeurs virtuels sont exécutés sur un serveur racine comportant huit processeurs logiques, la capacité en mégacycles d’un processeur virtuel n’est pas égale à la capacité en mégacycles d’un processeur logique. Dans cette étape, vous calculez les mégacycles disponibles par processeur virtuel :

  • Mégacycles par processeur virtuel = mégacycles par processeur logique × (nombre de processeurs logiques ÷ nombre de processeurs virtuels)

    = 5 115 × (8 ÷ 9)

    = 4 547

Dans cette étape, pour déterminer les mégacycles disponibles par machine virtuelle, consultez le tableau suivant.

Mégacycles disponibles par machine virtuelle

Machine virtuelle Nombre de processeurs virtuels Mégacycles par processeur virtuel Mégacycles disponibles

Combinaison de serveurs d’accès au client/Transport Hub

3

4547

13641

Boîte aux lettres (DAG principal)

4

4547

18188

Boîte aux lettres (DAG secondaire)

2

4547

9094

Comme les principes de conception recommandent de ne pas dépasser le taux d’utilisation du processeur de 80 pour cent, ajustez les mégacycles disponibles pour répondre à l’objectif de 80 pour cent, comme indiqué dans le tableau suivant.

Mégacycles disponibles cibles par machine virtuelle

Machine virtuelle Mégacycles disponibles Taux d’utilisation maximal du processeur Mégacycles disponibles cibles

Combinaison de serveurs d’accès au client/Transport Hub

13641

80%

10913

Boîte aux lettres (DAG principal)

18188

80%

14550

Boîte aux lettres (DAG secondaire)

9094

80%

7275

Return to top

Pour vérifier la capacité du processeur des machines virtuelles du serveur de boîtes aux lettres principal, suivez les étapes ci-dessous.

La charge de travail la plus lourde pour le serveur de boîtes aux lettres principal est observée lors d’une défaillance ou d’une maintenance du serveur où 5 400 boîtes aux lettres sont actives sur le serveur de boîtes aux lettres principal et les deuxième et troisième copies distantes font l’objet d’une maintenance (par exemple, suite à un événement de récupération au cours duquel les copies passives sont mises à jour sans que les boîtes aux lettres actives n’aient été redéplacées vers le serveur cible). Dans cette étape, vous déterminez les besoins en mégacycles pour la machine virtuelle du serveur de boîtes aux lettres principal à l’aide du calcul suivant :

  • Mégacycles de boîtes aux lettres requis = (nombre d’utilisateurs de boîtes aux lettres × mégacycles spécifiques à un profil) + nombre de copies de bases de données distantes × (nombre d’utilisateurs de boîtes aux lettres × mégacycles spécifiques à un profil × 10 %)

    = (5400 × 2) + 2 × (5 400 × 2 × 0,1)

    = 10 800 + 2 160

    = 12 960

Dans cette étape, vous déterminez si les mégacycles disponibles sont plus nombreux que les mégacycles exigés. Vous nécessitez de 12 960 mégacycles et disposez de 14 550 mégacycles de sorte que la machine virtuelle du serveur de boîtes aux lettres principal dispose d’une capacité suffisante pour prendre en charge 5 400 boîtes aux lettres actives.

Return to top

Pour vérifier la capacité du processeur des machines virtuelles du serveur de boîtes aux lettres secondaire, suivez les étapes ci-dessous.

La charge de travail la plus lourde pour le serveur de boîtes aux lettres secondaire est observé lors d’une défaillance du site où 2 700 boîtes aux lettres sont actives sur le serveur de boîtes aux lettres secondaire et les deuxième et troisième copies distantes font l’objet d’une maintenance (par exemple, suite à une reconnexion du site d’origine au cours de laquelle les copies principale et secondaire d’origine sont mises à jour sans que les boîtes aux lettres actives n’aient été redéplacées vers le site d’origine). Dans cette étape, pour déterminer les besoins en mégacycles pour la machine virtuelle du serveur de boîtes aux lettres secondaire, utilisez le calcul suivant :

  • Mégacycles de boîtes aux lettres requis = (nombre d’utilisateurs de boîtes aux lettres × mégacycles spécifiques à un profil) + nombre de copies de bases de données distantes × (nombre d’utilisateurs de boîtes aux lettres × mégacycles spécifiques à un profil × 10 %)

    = (2700 × 2) + 2 × (2700 × 2 × 0.1)

    = 5400 + 1080

    = 6480

Dans cette étape, vous déterminez si les mégacycles disponibles sont plus nombreux que les mégacycles exigés. Vous nécessitez de 6 480 mégacycles et disposez de 7 275 mégacycles de sorte que la machine virtuelle du serveur de boîtes aux lettres secondaire dispose d’une capacité suffisante pour prendre en charge 2 700 boîtes aux lettres actives.

Return to top

Vous pouvez suivre les étapes ci-dessous pour déterminer la mémoire requise par machine virtuelle de serveur de boîtes aux lettres principal.

Dans une étape précédente, nous avons déterminé que les besoins en cache de base de données pour toutes les boîtes aux lettres étaient de 190 Go et que le cache moyen requis par boîte aux lettres active était de 6 Mo.

Pour concevoir une solution adaptée au pire scénario de défaillance, vous calculez le cache de base de données requis en sachant que 5 400 boîtes aux lettres actives résident sur les autres machines virtuelles de serveur de boîtes aux lettres :

  • Mémoire requise pour le cache de base de données = nombre de boîtes aux lettres actives × cache moyen par boîte aux lettres

    = 5 400 × 6 Mo

    = 32 400 Mo

    = 31,6 Go

Dans cette étape, reportez-vous au tableau suivant pour déterminer la configuration de mémoire recommandée.

Configuration requise de la mémoire

Mémoire physique de serveur (RAM) Taille du cache de base de données (rôle serveur boîtes aux lettres uniquement)

24 GB

17,6 GB

32 GB

24,4 GB

48 GB

39,2 GB

La configuration mémoire recommandée pour prendre en charge un cache de base de données de 31,6 Go pour un rôle serveur de boîtes aux lettres est de 48 Go.

Return to top

Vous pouvez suivre les étapes ci-dessous pour déterminer la mémoire requise par machine virtuelle de serveur de boîtes aux lettres secondaire.

Dans une étape précédente, nous avons déterminé que les besoins en cache de base de données pour toutes les boîtes aux lettres étaient de 190 Go et que le cache moyen requis par boîte aux lettres active était de 6 Mo.

Pour concevoir une solution adaptée au pire scénario de défaillance, vous calculez le cache de base de données requis en sachant que 2 700 boîtes aux lettres actives résident sur les machines virtuelles du serveur de boîtes aux lettres secondaire :

  • Mémoire requise pour le cache de base de données = nombre de boîtes aux lettres actives × cache moyen par boîte aux lettres

    = 2 700 × 6 Mo

    = 16 200 Mo

    = 15,8 Go

Dans cette étape, reportez-vous au tableau suivant pour déterminer la configuration de mémoire recommandée.

Configuration requise de la mémoire

Mémoire physique de serveur (RAM) Taille du cache de base de données (rôle serveur boîtes aux lettres uniquement) Taille du cache de base de données (plusieurs rôles serveur, par exemple, rôles serveur de boîtes aux lettres et de transport Hub)

24 GB

17,6 GB

14 GB

32 GB

24,4 GB

20 GB

48 GB

39,2 GB

32 GB

La configuration mémoire recommandée pour prendre en charge un cache de base de données de 15,8 Go pour un rôle serveur de boîtes aux lettres est de 24 Go.

Return to top

Pour déterminer la configuration de mémoire pour la machine virtuelle du serveur combiné Accès au client/Transport Hub, reportez-vous au tableau suivant.

Configurations de mémoire pour les serveurs Exchange 2010 basées sur les rôles serveur installés

Rôle de serveur Exchange 2010 Minimum pris en charge Configuration maximale recommandée

Rôle serveur combiné Accès au client/Transport Hub (rôles serveur d’accès au client et de transport Hub exécutés sur le même serveur physique)

4 GB

2 Go par cœur (8 Go minimum)

Comme la machine virtuelle du serveur combiné Accès au client/Transport Hub inclut trois processeurs virtuels, 6 Go de mémoire sont affectés à chaque machine virtuelle de serveur combiné.

Return to top

Pour déterminer la mémoire requise par serveur racine Hyper-V, effectuez le calcul suivant :

  • Mémoire du serveur racine = mémoire du système d’exploitation racine + mémoire de la machine virtuelle du serveur combiné Accès au client/Transport Hub + mémoire de la machine virtuelle du serveur de boîtes aux lettres principal + mémoire de la machine virtuelle du serveur de boîtes aux lettres secondaire

    = 4 Go + 6 Go + 48 Go + 24 Go

    = 82 Go

La mémoire physique requise pour le serveur racine est de 82 Go. Pour être conforme aux configurations de mémoire physique recommandées, nous ajouterons 96 Go au serveur.

Return to top

Dans une étape précédente, vous avez déterminé que la solution contiendrait trois DAG et que chacun d’eux occuperait deux des trois emplacements physiques. Maintenant que vous avez identifié le nombre de serveurs de boîtes aux lettres nécessaires pour supporter la charge de travail et répondre aux besoins du DAG, vous pouvez passer à l’étape de conception du DAG.

Conception du DAG

à déterminer

Return to top

Pour concevoir une disposition des copies de bases de données, suivez les étapes ci-dessous.

Pour déterminer le nombre optimal de bases de données Exchange à déployer, utilisez le Calculateur des besoins en stockage du rôle serveur de boîtes aux lettres Exchange 2010. Entrez les informations appropriées dans l’onglet de saisie, puis sélectionnez Yes (Oui) pour l’option Automatically Calculate Number of Databases / DAG (Calculer automatiquement le nombre de bases de données/DAG). Dans le champ de taille limite de base de données, utilisez le quota de boîte aux lettres entièrement configurée de 2 048 Mo.

Bases de données Exchange dans le DAG

à déterminer

Le nombre recommandé de bases de données est affiché dans l’onglet Configuration requise pour le rôle. Pour cette solution, le calculateur recommande que chaque DAG ait au moins 24 bases de données uniques.

*Point de décision de conception*

Suite aux recommandations du calculateur, 24 bases de données par DAG seront déployés.

Puisqu’il existe 24 bases de données uniques par DAG et huit serveurs dans le DAG, chacun des quatre serveurs du site principal hébergera six copies de bases de données actives dans des conditions normales de fonctionnement.

Commencez par ajouter les copies de bases de données actives aux quatre serveurs, comme indiqué dans le tableau suivant.

Disposition des bases de données dans des conditions normales de fonctionnement

Base de données MBX1 MBX2 MBX3 MBX4

DB1-6

A1

DB7-12

A1

DB13-18

A1

DB19-24

A1

Dans le tableau précédent, la règle suivante s’applique :

  • A1 = copie de base de données active

Dans une étape précédente, vous avez déterminé que la stratégie de résilience du serveur de boîtes aux lettres serait élaborée pour assurer l’efficacité des opérations. Les serveurs de boîtes aux lettres seraient déployés par paire.

Le DAG comportant quatre serveurs de boîtes aux lettres, les serveurs 1 et 2 formeront une paire et les serveurs 3 et 4, une autre paire. Dans cette étape, vous ajoutez les copies de bases de données passives (P1) au serveur secondaire dans chaque paire, comme indiqué dans le tableau suivant.

Disposition des bases de données dans des conditions normales de fonctionnement avec des copies passives

Base de données MBX1 MBX2 MBX3 MBX4

DB1-6

A1

P1

DB7-12

P1

A1

DB13-18

A1

P1

DB19-24

P1

A1

Dans le tableau précédent, la règle suivante s’applique :

  • A1 = copie de base de données active

  • P1 = copie de base de données passive

Lors d’un événement de défaillance ou de maintenance du serveur, les copies P1 sont activées sur le serveur secondaire. Le tableau suivant illustre cette situation lorsque MBX2 et MBX4 sont arrêtés pour maintenance.

Disposition des copies de bases de données dans des conditions de défaillance ou de maintenance du serveur sur le site

à déterminer

Dans le tableau précédent, la règle suivante s’applique :

  • A1 = copie de base de données active

  • P1 = copie de base de données passive

Dans cette étape, ajoutez une troisième copie de base de données aux membres du DAG du centre de données secondaire pour assurer la résilience de site, comme indiqué dans le tableau suivant.

Copies de bases de données ajoutées au centre de données secondaire pour prendre en charge la résilience de site

Base de données MBX1 site A MBX2 site A MBX3 site A MBX4 site A MBX5 site B MBX6 site B MBX7 site B MBX8 site B

DB1-6

A1

P1

P2

DB7-12

P1

A1

P2

DB13-18

A1

P1

P2

DB19-24

P1

A1

P2

Dans le tableau précédent, la règle suivante s’applique :

  • A1 = copie de base de données active

  • P1 = copie de base de données passive locale

  • P2 = copie de base de données passive distante

Dans l’éventualité d’une défaillance du centre de données principal, les copies P2 seront activées sur le site secondaire, comme indiqué dans le tableau suivant. Notez que tant que le site principal n’est pas reconnecté à Internet, une seule copie de la base de données sera conservée.

Disposition des bases de données dans des conditions de défaillance du site

à déterminer

Dans le tableau précédent, la règle suivante s’applique :

  • A1 = copie de base de données active

  • P1 = copie de base de données passive

  • P2 = copie de base de données passive

Return to top

Le mode DAC (Datacenter Activation Coordination, coordination de l’activation du centre de données) est utilisé pour contrôler le comportement d’activation d’un groupe de disponibilité de base de données lorsqu’une panne grave affectant le groupe de disponibilité de base de données se produit (par exemple, panne complète de tous les centres de données). Lorsque le mode de coordination de l’activation du centre de données est désactivé et qu’une défaillance affectant plusieurs serveurs se produit dans le groupe de disponibilité de base de données, ce dernier redémarre et tente de monter les bases de données une fois la majorité des membres du groupe restaurée après la défaillance. Dans une configuration multipliant les centres de données, ce comportement pourrait provoquer un syndrome de « split-brain », une situation qui se produit lorsque tous les réseaux sont défaillants et que les membres du groupe de disponibilité de base de données ne peuvent pas échanger des signaux de pulsations. Le syndrome de « split brain » peut également se produire lorsque la connectivité réseau est défaillante entre les centres de données. Ce syndrome peut être évité en exigeant toujours qu’une majorité des membres du groupe de disponibilité de base de données (et dans le cas des groupes de disponibilité de base de données ayant un nombre de membres pair, le serveur témoin du groupe de disponibilité de base de données) soient disponibles et en interaction pour que le groupe de disponibilité de base de données soit opérationnel. Pour plus d’informations, consultez la rubrique Présentation du mode coordination de l’activation du centre de données.

*Point de décision de conception*

Le mode DAC sera activé pour les trois DAG dans l’environnement afin d’éviter la survenue du syndrome de « split brain ».

Return to top

Dans Exchange 2010, le DAG utilise un nombre minime de composants du clustering avec basculement Windows. L’un de ces composants est la ressource quorum, qui fournit un dispositif d’arbitrage lorsque vous déterminez l’état du cluster et prenez des décisions relatives à l’appartenance. Il est fondamental que chaque membre du DAG ait une vue cohérente de la configuration du cluster sous-jacent du groupe. Le quorum agit comme le référentiel définitif pour toutes les informations de configuration relatives au cluster. Le quorum est utilisé pour départager les nœuds afin d’éviter le syndrome de « split brain ». Le syndrome de « split brain » est une situation qui se produit lorsque les membres du DAG ne peuvent pas communiquer entre eux bien qu’ils soient disponibles et opérationnels. Ce syndrome est évité en exigeant toujours qu’une majorité des membres du DAG (et dans le cas de DAG comportant un nombre de membres pair, le serveur témoin du DAG) soient disponibles et en interaction pour que le DAG soit opérationnel.

Un serveur témoin est un serveur extérieur à un DAG qui héberge le témoin de partage de fichiers. On l’utilise pour obtenir et maintenir le quorum lorsque le DAG comporte un nombre de membres pair. Les groupes de disponibilité de base de données ayant un nombre de membres impair n’utilisent pas de serveur témoin. Lors de la création d’un DAG, le témoin de partage de fichiers est ajouté par défaut à un serveur de transport Hub (qui ne possède pas de rôle serveur de boîte aux lettres installé) sur le même site que le premier membre du DAG. Si votre serveur de transport Hub est exécuté sur une machine virtuelle résidant sur le même serveur racine que celles qui exécutent le rôle serveur de boîtes aux lettres, il est recommandé de déplacer le témoin de partage de fichiers vers un autre serveur ayant une disponibilité élevée. Vous pouvez déplacer le témoin de partage de fichiers vers un contrôleur de domaine. Toutefois, il convient de n’effectuer cette opération qu’en dernier recours en raison des risques potentiels pour la sécurité.

Dans les solutions où le DAG occupe plusieurs sites, il est recommandé de définir un autre témoin de partage de fichiers pour le site secondaire. Cela permettra au cluster de maintenir le quorum en cas de défaillance d’un site avec le mode DAC activé.

*Point de décision de conception*

Parce qu’il a été décidé de déployer trois DAG et que leurs membres seront répartis sur plusieurs sites, vous devez définir trois répertoires témoins principaux et trois autres répertoires témoins. Ces répertoires seront situés sur les serveurs de fichiers au sein de chaque site.

Return to top

Lors de la planification de votre organisation Exchange 2010, l’une des décisions les plus importantes à prendre porte sur l’organisation de l’espace de noms externe à votre organisation. Un espace de noms est une structure logique généralement représentée par un nom de domaine dans le DNS (Domain Name System). Lorsque vous définissez votre espace de noms, vous devez tenir compte des différents emplacements de vos clients et des serveurs qui hébergent leurs boîtes aux lettres. Outre l’emplacement physique des clients, vous devez évaluer leur mode de connexion à Exchange 2010. Les réponses à ces questions permettront de déterminer le nombre d’espaces de noms dont vous avez besoin. Vos espaces de noms sont généralement adaptés à votre configuration DNS. Il est recommandé que chaque site Active Directory d’une région comportant un ou plusieurs serveurs d’accès au client connectés à Internet dispose d’un espace de noms unique. Cela est généralement représenté dans le DNS par un enregistrement de type A, par exemple mail.contoso.com ou mail.europe.contoso.com.

Pour plus d'informations, consultez la rubrique Présentation des espaces de noms de serveur d’accès au client.

Vos espaces de noms externes peuvent être organisés de différentes manières. Toutefois, vos besoins peuvent être généralement satisfaits avec l’un des modèles d’espace de noms suivants :

  • Modèle de centre de données consolidé   Ce modèle se compose d’un seul site physique. Tous les serveurs sont situés sur le site et il n’existe qu’un seul espace de noms, par exemple mail.contoso.com.

  • Espace de noms unique avec sites proxy   Ce modèle comprend plusieurs sites physiques. Seul un site contient un serveur d'accès au client connecté à Internet. Les autres sites ne sont pas connectés à Internet. Il n'existe qu'un espace de noms pour les sites de ce modèle, par exemple mail.contoso.com.

  • Espace de noms unique avec plusieurs sites   Ce modèle comprend plusieurs sites physiques. Chaque site peut contenir un serveur d’accès au client connecté à Internet. Aussi, il est possible d’avoir un site unique contenant plusieurs serveurs d’accès au client connectés à Internet. Il n'existe qu'un espace de noms pour les sites de ce modèle, par exemple mail.contoso.com.

  • Espaces de noms par pays   Ce modèle se compose de plusieurs sites physiques et de plusieurs espaces de noms. Par exemple, un site implanté à New York posséderait l’espace de noms mail.usa.contoso.com, un autre à Toronto aurait l’espace de noms mail.canada.contoso.com et un site basé à Londres recevrait l’espace de noms mail.europe.contoso.com.

  • Plusieurs forêts   Ce modèle comporte plusieurs forêts dotées d’espaces de noms multiples. Une organisation utilisant ce modèle peut être constituée de deux entreprises partenaires, par exemple Contoso et Fabrikam. Les espaces de noms peuvent inclure mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.fabrikam.com et mail.europe.fabrikam.com.

*Point de décision de conception*

Pour ce scénario, le modèle d’espace de noms régional est retenu car il convient mieux aux organisations dans lesquelles les boîtes aux lettres actives sont réparties sur plusieurs sites.

L’avantage de ce modèle tient à la réduction du transfert par proxy car un pourcentage plus élevé d’utilisateurs pourront se connecter à un serveur d’accès au client sur le même site Active Directory que celui où se trouve leur serveur de boîtes aux lettres. Cela améliore l'expérience de l'utilisateur final, ainsi que les performances. Les utilisateurs dont les boîtes aux lettres sont sur un site ne disposant pas d'un serveur d'accès au client connecté à Internet sont quand même transférés par proxy.

Cette solution exige également la configuration suivante :

  • Il est nécessaire de gérer plusieurs enregistrements DNS.

  • Il est nécessaire d'obtenir, configurer et gérer plusieurs certificats.

  • La gestion de la sécurité est plus complexe car chaque site connecté à Internet requiert un ordinateur disposant de Microsoft Forefront Threat Management Gateway ou autre solution de proxy inversé ou de pare-feu.

  • Les utilisateurs doivent se connecter à l’espace de noms de leur propre pays. Cela peut engendrer un nombre supplémentaire d’appels du service d’assistance utilisateur et une formation plus importante.

Return to top

Dans Exchange 2010, les services d’accès au client RPC et de carnet d’adresses Exchange ont été introduits dans le rôle serveur d’accès au client pour optimiser l’expérience des utilisateurs de boîtes aux lettres lorsque la copie de base de données de boîtes aux lettres actives est déplacée vers un autre serveur de boîtes aux lettres (par exemple, lors de défaillances de la base de données de boîtes aux lettres et d’opérations de maintenance). Les points finaux de connexion d’accès aux boîtes aux lettres à partir de Microsoft Outlook ou d’autres clients MAPI ont été déplacés du rôle serveur de boîtes aux lettres vers le rôle serveur d’accès au client. Les connexions Outlook internes et externes doivent donc être maintenant équilibrées sur tous les serveurs d’accès au client du site pour obtenir une tolérance de pannes. Pour associer le point final MAPI à un groupe de serveurs d’accès au client plutôt qu’à un serveur d’accès au client spécifique, vous pouvez définir un groupe de serveurs d’accès au client. Vous ne pouvez configurer qu’un seul groupe par site Active Directory et un groupe ne peut occuper plus d’un site Active Directory. Pour plus d'informations, consultez les rubriques Présentation de l'accès au client RPC et Understanding Load Balancing in Exchange.

*Point de décision de conception*

Ce déploiement englobant trois sites sur lesquels quatre serveurs exécutent le rôle serveur d’accès au client, on obtient au total trois groupes de serveurs d’accès au client. Une solution d’équilibrage de charge matérielle sera utilisée pour distribuer la charge sur les groupes de serveurs d’accès au client de chaque site.

Return to top

Pour déterminer un modèle d’équilibrage de charge matérielle, suivez les étapes ci-dessous.

Dans cet exemple, le fournisseur préféré est Cisco car sa gamme de produits ACE (Application Control Engine) est compatible avec Cisco Unified Computing System, qui a été choisi pour les composants de connexion serveur, réseau et de stockage de cette solution.

La gamme de produits ACE de Cisco fournit une solution de centre de données haute disponibilité et évolutive dont l’environnement applicatif Exchange 2010 peut tirer profit. Les produits ACE de Cisco sont interopérables et offrent les avantages suivants :

  • performances, évolutivité, débit et disponibilité des applications

  • Conception normalisée

  • Architecture virtuelle avec partitionnement des périphériques

  • Administration basée sur les rôles et gestion centralisée

  • Services de sécurité via une inspection approfondie des paquets, listes de contrôle d’accès (ACL), recherche par chemin inverse unicast et traduction des adresses réseau (NAT)/traduction des adresses de port

La gamme de produits ACE de Cisco propose deux modèles d’équilibrage de charge matérielle différents qui répondent aux besoins de la solution de centre de données haute disponibilité et évolutive faite pour l’environnement applicatif Exchange 2010 : le système Cisco ACE 4710 et le module de services intégré des plates-formes de routage Cisco Catalyst 6500/Cisco 7600.

le système Cisco ACE 4710 assure un débit maximal de 4 Gbits/s dans un format d’une unité de rack (1RU), pouvant être mis à niveau à l’aide de licences logicielles et offrant une protection et une évolutivité de l’investissement à long terme. À la base, le 4710 est un châssis d’une unité de rack doté d’une carte accélératrice Cavium Nitrox Octeon qui inclut quatre ports Gigabit Ethernet pouvant être regroupés à l’aide de la technologie Cisco EtherChannel et connectés à un commutateur. Par défaut, le système Cisco ACE 4710 prend en charge la virtualisation avec un périphérique administrateur et cinq périphériques utilisateur, une bande passante d’1 Gbits/, 1 000 transactions SSL (Secure Sockets Layer) par seconde et une compression de 100 mégabits par seconde (Mbits/s). Cette solution peut être étendue sans qu’il soit nécessaire d’acheter un nouvel équipement, grâce aux mises à niveau des licences logicielles suivantes :

  • Débit   Le débit par défaut d’1 Gbits/s peut être augmenté à 2 ou 4 Gbits/s.

  • Périphériques virtuels   Le nombre de périphériques virtuels peut être augmenté de 5 à 20.

  • Transactions SSL par seconde   Le nombre de transactions SSL par seconde peut être augmenté d’1 000 à 5 000 ou 7 500.

  • Compression   La compression peut être augmentée à un débit de 500 Mbits/s ou d’1 ou 2 Gbits/s.

  • Contrôle d’accès basé sur les rôles   La gestion centralisée et basée sur les rôles est assurée via l’interface utilisateur graphique ou de l’interface de ligne de commande d’Application Network Manager.

  • Haute disponibilité Les configurations redondantes (à l’intérieur du système et intercontextuelles) sont prises en charge.

Le module Cisco ACE des commutateurs série 6500 Cisco Catalyst ou des routeurs série 7600 Cisco offre un débit pouvant atteindre 16 Gbits/s dans un module à emplacement unique, qui, comme le système ACE 4710, peut être mis à niveau via des licences logicielles. Vous pouvez installer jusqu’à quatre modules Cisco ACE dans un seul commutateur série 6500 Cisco Catalyst ou routeur série 7600 Cisco. Chacun peut prendre en charge les processus métier de plusieurs unités de gestion indépendantes en tirant profit d’une vaste palette d’options de connexion disponibles sur le commutateur ou le routeur. L’administrateur système détermine la configuration requise de l’application et affecte les services réseau appropriés sous forme de contextes virtuels. Chaque contexte contient un ensemble de stratégies, d’interfaces, de ressources et d’administrateurs qui lui est propre :

  • Débit   Les services d’équilibrage de charge offrent un débit maximal de 16 Gbits/s et 345 000 connexions de couche 4 par seconde.

  • Périphériques virtuels   Le nombre de périphériques virtuels peut être augmenté de 5 à 250.

  • Transactions SSL par seconde   Le nombre de transactions SSL par seconde peut être augmenté à 15 000 sessions SSL avec des licences sur les modules ACE20 et à 30 000 sessions sur les modules ACE30.

  • Compression La compression peut être augmentée à 6 Gbits/s sur les modules ACE30.

  • Contrôle d’accès basé sur les rôles   La gestion centralisée et basée sur les rôles est assurée via l’interface utilisateur graphique ou l’interface de ligne de commande d’Application Network Manager.

  • Haute disponibilité Les configurations redondantes (à l’intérieur du châssis, inter-châssis et intercontextuelles) sont prises en charge.

Le système Cisco ACE 4710 a été retenu car il assure une disponibilité maximale et une sécurité totale des applications, une architecture virtualisée, ainsi qu’une valorisation et une protection de l’investissement :

  • Disponibilité maximale des applications   Cisco ACE 4710 assure la continuité de l’entreprise et le service aux utilisateurs finaux en améliorant la disponibilité via des fonctionnalités d’équilibrage de charge de couche 4 et de commutation du contenu de couche 7 hautement évolutives, qui réduisent également l’impact des défaillances d’applications ou de périphériques.

  • Sécurité totale des applications   Cisco ACE 4710 agit comme une ligne de défense ultime des serveurs, en les protégeant contre les menaces d’applications et les attaques de refus de service (DoS) à l’aide de fonctionnalités, telles que l’inspection approfondie des paquets, la sécurité réseau et protocole, et des options de contrôle d’accès hautement évolutives.

  • Architecture virtualisée   L’architecture virtualisée est un élément de conception phare de Cisco ACE et une offre unique par rapport à d’autres solutions du marché. Les responsables de services informatiques peuvent configurer jusqu’à 20 périphériques virtuels sur un seul système Cisco ACE 4710. Cela a pour avantage de réduire le nombre de périphériques à gérer à mesure que les déploiements d’applications augmentent, de réduire les dépenses énergétiques et de refroidissement, et d’accélérer les délais de traitement des nouvelles applications.

Return to top

Une solution de stockage bien conçue est un aspect essentiel d’un déploiement réussi des rôles serveur de boîtes aux lettres Exchange 2010. Pour plus d'informations, consultez la rubrique Conception du stockage de serveur de boîtes aux lettres.

Le tableau suivant résume les besoins de stockage qui ont été calculés ou déterminés dans une étape de conception précédente.

Résumé de l’espace disque requis

Espace disque requis Valeur

Taille de boîte aux lettres sur le disque pour une boîte aux lettres de 2 Go (Mo)

2 301

Capacité totale de base de données requise (Go)

120 128

Capacité totale de journal requise (Go)

3 974

Capacité totale requise (Go)

124 102

Capacité totale requise pour trois copies de bases de données (Go)

372 306

Capacité totale requise pour trois copies de bases de données (téraoctets)

364

Capacité totale requise par site (téraoctets)

122

De nombreux clients souhaitent augmenter leurs quotas de boîte aux lettres de façon significative lorsqu’ils migrent vers Exchange 2010. Toutefois, les boîtes aux lettres peuvent nécessiter un certain temps pour croître de quelques centaines de mégaoctets à plusieurs gigaoctets. Dans ce cas, il peut être profitable pour certaines organisations d’essayer de reporter autant que possible les achats de systèmes de stockage supplémentaires à une période où ils sont susceptibles d’être moins onéreux.

De nombreux fournisseurs de solutions de stockage proposent différentes options de provisionnement dynamique qui vous permettent d’accroître les capacités physiques disponibles du serveur Exchange, et d’ajouter ensuite des ressources de stockage physique de façon dynamique pour répondre à la demande croissante sans interruption de l’activité ou temps d’arrêt. Ces dernières abaissent le coût total de possession en réduisant l’affectation initiale de la capacité de stockage et simplifient la gestion en réduisant le nombre d’étapes nécessaires au soutien de la croissance.

La mise en œuvre du provisionnement dynamique de la solution de stockage unifié EMC est assurée par sa fonctionnalité de provisionnement virtuel, qui prend en charge le hot sparing, le remplacement proactif, l’expansion de pools dynamiques sans interruption et la possibilité de migrer entre des LUN dynamiques et des LUN de taille fixe traditionnels sans temps d’arrêt. Cette souplesse différencie le provisionnement virtuel de la solution de stockage unifié EMC des solutions de provisionnement dynamique classiques.

*Point de décision de conception*

L’implémentation Exchange actuelle dispose d’un quota de boîte aux lettres défini à 200 Mo. Après la migration vers Exchange 2010, on estime que les tailles de boîtes aux lettres augmenteront d’environ 300 pour cent au cours des 12 à 18 premiers mois. L’objectif est d’acheter une solution de stockage suffisante pour accueillir une boîte aux lettres d’une taille moyenne de 600 Mo. Pendant la durée de vie de l’implémentation Exchange 2010, la taille moyenne de boîte aux lettres devrait être proche de 2 Go. Les quotas de boîtes aux lettres de 2 Go représentant un coût considérable, le provisionnement dynamique sera mis en œuvre afin qu’un quota initial de boîte aux lettres de 600 Mo puisse être déployé. Le stockage physique sous-jacent sera étendu lors des cycles budgétaires ultérieurs pour faire face à la demande escomptée.

Lors de l’exploitation du provisionnement dynamique dans une solution de stockage unifié EMC pour les déploiements Exchange 2010, il est recommandé de séparer les fichiers journaux des fichiers de base de données. Si vous prévoyez une croissance de la taille des boîtes aux lettres mais pas du profil de message (messages envoyés/reçus par jour), vous devrez alors augmenter progressivement les LUN de bases de données et non les LUN de journaux. Il ne sera peut-être pas utile de placer les journaux sur des LUN alloués de façon dynamique.

La séparation des LUN de bases de données et de journaux permet également de les placer sur différents types de disques ou d’utiliser différents niveaux de RAID.

*Point de décision de conception*

Suite à une pratique recommandée d’EMC, les bases de données et les journaux seront placés sur des LUN différents. Étant donné que le profil de message devrait rester relativement stable au cours des trois prochaines années, il n’y a aucun avantage à placer les journaux sur des LUN alloués de façon dynamique.

Les sauvegardes et les restaurations VSS fonctionnant au niveau du LUN, le nombre de bases de données par LUN est généralement déterminé par la stratégie de sauvegarde. Dans une étape précédente, il a été décidé d’exclure les sauvegardes VSS de la stratégie de résilience de base de données. La décision sur le nombre de base de données par LUN dépendra d’autres facteurs. Il est généralement recommandé de déployer une seule base de données par LUN. Le regroupement de plusieurs bases de données sur un LUN pourrait avoir les conséquences suivantes :

  • Surcharge d’une base de données affectant une base de données saine

  • Opération d’amorçage sur une base de données affectant une base de données saine

  • E/S de base de données passive affectant les bases de données actives

*Point de décision de conception*

Comme il n’est pas obligatoire de déployer plusieurs bases de données sur un LUN, la conception de stockage reposera sur un modèle de base de données unique par LUN.

Dans une étape précédente, vous avez établi que chaque serveur de boîtes aux lettres principal prendrait en charge six bases de données actives et six bases de données passives. Il y a aura au total 24 LUN pour chaque serveur de boîtes aux lettres du centre de données principal, comme décrit dans le tableau suivant.

Nombre de LUN requis par serveur de boîtes aux lettres

Types de LUN LUN par serveur

LUN de bases de données actives

6

LUN de journaux actifs

6

LUN de bases de données passives

6

LUN de journaux passifs

6

Nombre total de LUN

24

Dans une étape précédente, vous avez déterminé que chaque serveur de boîtes aux lettres secondaire prendrait en charge six bases de données passives. Il y a aura au total 12 LUN pour chaque serveur de boîtes aux lettres du centre de données secondaire, comme décrit dans le tableau suivant.

Nombre de LUN requis par serveur de boîtes aux lettres

Types de LUN LUN par serveur

LUN de bases de données passives

6

LUN de journaux passifs

6

Nombre total de LUN

12

Pour simplifier les dernières étapes de conception du stockage, utilisez l’approche du bloc de construction. Dans cette solution, chaque base de données prend en charge 450 boîtes aux lettres actives. Chaque serveur de boîtes aux lettres prend en charge 6 bases de données ou 2 700 boîtes aux lettres actives sur 6 LUN de bases de données et 6 LUN de journaux. Un bloc de construction de 12 LUN capable de gérer des augmentations de 2 700 boîtes aux lettres sera utilisé.

Dans cette étape, calculez le nombre d’Ops ES/s transactionnelles nécessaires pour prendre en charge les 2 700 utilisateurs de boîtes aux lettres dans le bloc de construction. Ultérieurement, vous déterminerez, à partir des besoins en Ops ES/s, le nombre minimal et maximal de piles à déployer pour le bloc de construction en fonction du quota de boîte aux lettres initial et entièrement configuré. Effectuez le calcul suivant :

  • Nombre total d’Ops ES/s transactionnelles requises pour le bloc de construction = Ops ES/s par utilisateur de boîte aux lettres × nombre de boîtes aux lettres × facteur de croissance des E/S

    = 0,10 × 2 700 × 20 %

    = 324 E/S par seconde

Dans une étape précédente, vous avez déterminé que la taille de boîte aux lettres sur le disque était de 2 301 Mo pour une limite de quota de boîte aux lettres de 2 048 Mo. Étant donné que nous utiliserons le provisionnement dynamique, calculez la taille initiale de boîte aux lettres sur le disque. Cette valeur sera ultérieurement utilisée pour déterminer les besoins initiaux en termes de capacité.

Les calculs suivants sont utilisés pour déterminer la taille initiale de boîte aux lettres sur le disque pour cette solution sur la base d’un quota de boîte aux lettres de 600 Mo :

  • Espace blanc = 100 messages par jour × 75 ÷ 1 024 Mo = 7,3 Mo

  • Benne = (100 messages par jour × 75 ÷ 1 024 Mo × 14 jours) + (600 Mo x 0,012) + (600 Mo x 0,058) = 144,2 Mo

  • Taille de boîte aux lettres sur le disque = limite de boîte aux lettres + espace blanc + benne

    = 600 Mo + 7,3 Mo + 144,2 Mo

    = 752 Mo

Pour déterminer la capacité de stockage initiale requise pour 2 700 boîtes aux lettres avec un quota de boîte aux lettres initial de 600 Mo, effectuez les calculs suivants :

  • Capacité des fichiers de base de données = (nombre de boîtes aux lettres × taille de boîte aux lettres sur le disque × facteur de croissance supplémentaire de la base de données) + (facteur de croissance des données de 20 %)

    = (2 700 × 752 × 1) + (406 080)

    = 2 436 480 Mo

    = 2 379 Go

  • Capacité du catalogue de bases de données = 10 % de la capacité des fichiers de base de données

    = 238 Go

  • Capacité totale de la base de données = (taille des fichiers de base de données) + (taille de l’index) ÷ 0,80 pour ajouter 20 % d’espace de volume disponible

    = (2379 + 238) ÷ 0.8

    = 3 271 Go

Les six bases de données du bloc de construction requièrent une capacité de stockage initiale de 3 271 Go.

Pour déterminer la capacité de stockage entièrement configurée qui est requise pour 2 700 boîtes aux lettres avec un quota de boîte aux lettres de 2 048 Mo, effectuez les calculs suivants :

  • Capacité des fichiers de base de données = (nombre de boîtes aux lettres × taille de boîte aux lettres sur le disque × facteur de croissance supplémentaire de la base de données) + (facteur de croissance des données de 20 %)

    = (2700 × 2301 × 1) + (1242540)

    = 7 455 240 Mo

    = 7 281 Go

  • Capacité du catalogue de bases de données = 10 % de la capacité des fichiers de base de données

    = 728 Go

  • Capacité totale de la base de données = (taille des fichiers de base de données) + (taille de l’index) ÷ 0,80 pour ajouter 20 % d’espace de volume disponible

    = (7 281 + 728) ÷ 0,8

    = 10 011 Go

Les six bases de données du bloc de construction requièrent une capacité de stockage entièrement configurée de 10 011 Go.

Pour déterminer la capacité de stockage des journaux requise pour les 2 700 boîtes aux lettres du bloc de construction, effectuez les calculs suivants :

  • Capacité requise des journaux du bloc de construction = nombre d’utilisateurs de boîtes aux lettres × nombre de journaux quotidiens par boîte aux lettres × taille du journal × (nombre de jours requis pour remplacer l’infrastructure défaillante) + (pourcentage de traitement du déplacement de boîtes aux lettres)

    = (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)

    = 216 054 Mo

    = 211 Go

  • Capacité totale des journaux = capacité des journaux ÷ 0,80 pour obtenir 20 % d’espace de volume disponible

    = 211 ÷ 0.80

    = 264

Les six ensembles de journaux du bloc de construction requièrent une capacité de stockage de 264 Go.

RemarqueRemarque :
Les volumes de journaux n’étant pas alloués de façon dynamique, la capacité de stockage calculée représente les besoins en termes de capacité des journaux d’un environnement entièrement configuré.

Dans cette étape, déterminez le nombre de piles nécessaires pour répondre aux besoins en Ops ES/s. Dans l’étape suivante, vous déterminerez le nombre de piles répondant aux besoins en capacité.

Il a été précédemment déterminé que 324 Ops ES/s étaient nécessaires pour prendre en charge le bloc de construction de 2 700 boîtes aux lettres. Dans cette étape, calculez le nombre de disques nécessaires pour répondre aux besoins en Ops ES/s, à l’aide de la formule suivante :

  • Nombre de disques = (Ops ES/s par utilisateur × ratio de lecture) + pénalité d’écriture × (Ops ES/s par utilisateur × ratio d’écriture) ÷ capacité du type de disque choisi en termes d’Ops ES/s

    = (324 × 0,6) + 4 × (324 × 0,4) ÷ 155

    = 4,6

Les besoins en Ops ES/s peuvent être satisfaits avec cinq disques dans une configuration RAID 5.

RemarqueRemarque :
Ces calculs sont spécifiques à cette solution EMC. Pour savoir combien de piles sont nécessaires pour la solution de stockage que vous avez choisie, adressez-vous à votre fournisseur de solutions de stockage.

Dans une étape précédente, vous avez déterminé que le bloc de construction de 2 700 boîtes aux lettres pour une boîte aux lettres initialement configurée de 600 Mo exigeait une capacité de 3 271 Go. La capacité exploitable par pile de 450 Go dans une configuration RAID 5 sur le modèle 480 CX4 est d’environ 402 Go. Pour déterminer le nombre de disques requis, effectuez le calcul suivant :

  • Nombre de disques = (capacité totale requise) ÷ (capacité exploitable par pile avec RAID 5)

    = 3 271 Go ÷ 402 Go

    = 8,1

Les besoins en capacité initiale des bases de données peuvent être satisfaits avec neuf disques.

Les pratiques recommandées de l’EMC pour le déploiement d’une solution de stockage sur le stockage unifié EMC avec le provisionnement dynamique préconisent de configurer des pools dynamiques RAID 5 par groupes de cinq disques. Affectez 10 disques à un bloc de construction de 2 700 boîtes aux lettres. Il vous restera encore de l’espace pour une croissance future.

Dans une étape précédente, vous avez déterminé que le bloc de construction de 2 700 boîtes aux lettres pour une boîte aux lettres initialement configurée de 2 048 Mo exigeait une capacité de 10 011 Go. La capacité exploitable par pile de 450 Go dans une configuration RAID 5 sur le modèle 480 CX4 est d’environ 402 Go. Pour déterminer le nombre de disques requis, effectuez le calcul suivant :

  • Nombre de disques = (capacité totale requise) ÷ (capacité exploitable par pile avec RAID 5)

    = 10 011 Go ÷ 402 Go

    = 24,9

Les besoins en capacité des bases de données entièrement configurées peuvent être satisfaits avec 25 disques.

Dans une étape précédente, vous avez déterminé que le bloc de construction de 2 700 boîtes aux lettres exigeait une capacité de stockage de journaux de 264 Go. L’utilisation de deux lecteurs de 450 Go dans une configuration RAID-1/0 sur un système CX4-480 permet d’obtenir une capacité de stockage exploitable de 402 Go. La configuration à deux disques proposée répond aux besoins en capacité des journaux du bloc de construction de 2 700 boîtes aux lettres.

Maintenant que le nombre de piles nécessaires pour répondre aux besoins en Ops ES/s et en capacité du bloc de construction a été déterminé, vous devez définir le meilleur moyen de configurer les LUN sur le volume pour ce bloc de construction lors de l’utilisation du provisionnement virtuel ou dynamique.

Trois modèles principaux sont disponibles lors de la conception de pools dynamiques destinés à être utilisés pour Exchange :

  • Pool de stockage unique  Un pool de stockage de grande taille pour l’ensemble des bases de données et journaux Exchange est la méthode la plus simple et permet une utilisation optimale de l’espace. Cependant, l’utilisation d’un pool dynamique unique est déconseillée lorsque plusieurs copies de la même base de données sont situées sur la même baie physique.

  • Un pool de stockage par serveur   Un pool de stockage pour chaque serveur de boîtes aux lettres Exchange offre une plus grande précision lors de l’agencement des LUN sur la baie. Si ce pool est correctement conçu, il assurera l’isolement des copies de bases de données dans des ensembles de piles distincts et peut minimiser les problèmes de contention des disques susceptibles de se produire lors d’activités, telles que l’amorçage/le réamorçage, la sauvegarde et la maintenance en ligne (maintenance de base de données en arrière-plan). Toutefois, selon le nombre de serveurs de boîtes aux lettres concerné, ce modèle peut engendrer un grand nombre de pools dynamiques, ce qui peut être plus difficile à gérer.

  • Un pool de stockage par copie de base de données   Un pool de stockage pour chaque copie de base de données permet d’assurer l’isolement de chaque copie dans un ensemble de piles différent sur la baie. Du fait que la plupart des organisations déploient entre deux à quatre copies de bases de données, le nombre de pools dynamiques est limité à un nombre gérable. Dans ce modèle, plusieurs serveurs de boîtes aux lettres ont des LUN de bases de données dans le même pool dynamique. Il est possible que les activités, telles que l’amorçage/le réamorçage, la sauvegarde et la maintenance en ligne (maintenance de base de données en arrière-plan) réalisées sur un serveur de boîtes aux lettres ralentissent les performances sur un autre serveur de boîtes aux lettres.

*Point de décision de conception*

Même si un modèle de pool de stockage unique par serveur comporte certains avantages, il nous obligerait à créer huit pools dynamiques sur chaque site, soit un total de 24 pools dynamiques. Pour simplifier les choses, le modèle de pool de stockage unique par copie de base de données sera utilisé, ce qui engendrera la création de trois pools dynamiques sur chaque site et garantira que chaque copie de base de données réside sur un ensemble de piles unique. Cela permettra également d’assurer le maintien de l’isolement des piles de copies de bases de données chaque fois que des ressources de stockage supplémentaires doivent être ajoutées pour faire face à la croissance.

Le premier pool dynamique contiendra un bloc de construction de 2 700 boîtes aux lettres provenant de chacun des quatre serveurs de boîtes aux lettres du centre de données principal sur le site. Dans une étape précédente, il a été déterminé que 10 piles étaient nécessaires pour répondre aux besoins en Ops ES/s et en capacité du bloc de construction. Le premier pool dynamique prenant en charge 10 800 boîtes aux lettres actives exigera 40 piles.

Le deuxième pool dynamique contiendra également un bloc de construction de 2 700 boîtes aux lettres provenant de chacun des quatre serveurs de boîtes aux lettres du centre de données principal sur le site. Le deuxième pool dynamique prenant en charge 10 800 boîtes aux lettres passives exigera 40 piles.

Le troisième pool dynamique contiendra également un bloc de construction de 2 700 boîtes aux lettres provenant de chacun des quatre serveurs de boîtes aux lettres du centre de données secondaire sur le site (les serveurs d’un autre DAG qui prennent en charge les copies de bases de données à résilience de site). Le troisième pool dynamique prenant en charge 10 800 boîtes aux lettres passives exigera 40 piles.

Au total, 120 piles par site sont nécessaires pour répondre aux besoins en capacité initiale des bases de données.

Le premier pool dynamique contiendra un bloc de construction de 2 700 boîtes aux lettres provenant de chacun des quatre serveurs de boîtes aux lettres du centre de données principal sur le site. Dans une étape précédente, il a été déterminé que 25 piles étaient nécessaires pour répondre aux besoins en Ops ES/s et en capacité entièrement configurée du bloc de construction. Le premier pool dynamique prenant en charge 10 800 boîtes aux lettres actives exigera 100 piles.

Le deuxième pool dynamique contiendra également un bloc de construction de 2 700 boîtes aux lettres provenant de chacun des quatre serveurs de boîtes aux lettres du centre de données principal sur le site. Le deuxième pool dynamique prenant en charge 10 800 boîtes aux lettres passives exigera 100 piles.

Le troisième pool dynamique contiendra également un bloc de construction de 2 700 boîtes aux lettres provenant de chacun des quatre serveurs de boîtes aux lettres du centre de données secondaire sur le site (les serveurs d’un autre DAG qui prennent en charge les copies de bases de données à résilience de site). Le troisième pool dynamique prenant en charge 10 800 boîtes aux lettres passives exigera 100 piles.

Au total, 300 piles par site sont nécessaires pour répondre aux besoins en capacité des bases de données entièrement configurées.

Dans une étape précédente, il a été déterminé que chaque bloc de construction de 2 700 boîtes aux lettres nécessitait deux piles pour répondre aux besoins en LUN de journaux.

Quatre blocs de construction prennent en charge les bases de données de boîtes aux lettres actives sur les serveurs de boîtes aux lettres du centre de données principal. Le LUN de journaux prenant en charge 10 800 boîtes aux lettres actives exigera huit piles.

Quatre blocs de construction prennent en charge les bases de données de boîtes aux lettres passives sur les serveurs de boîtes aux lettres du centre de données principal. Le LUN de journaux prenant en charge 10 800 boîtes aux lettres passives exigera huit piles.

Quatre blocs de construction prennent en charge les bases de données de boîtes aux lettres passives sur les serveurs de boîtes aux lettres du centre de données secondaire. Le LUN de journaux prenant en charge 10 800 boîtes aux lettres passives exigera huit piles.

Pour répondre aux besoins en LUN de journaux sur un seul site, 24 piles sont nécessaires.

Dans cette étape, vérifiez que le nombre total de piles nécessaires peut être pris en charge par la baie de stockage qui a été choisie, en effectuant le calcul suivant :

  • Nombre total de piles requises par site = piles requises pour les LUN de bases de données + piles requises pour les LUN de journaux

    = 120 + 24

    = 144

Un système CX4-480 comprenant 10 boîtiers de baies de disques possède 150 piles et répond aux besoins.

Dans cette étape, calculez le nombre total de piles nécessaires pour soutenir l’environnement entièrement configuré, à l’aide de la formule suivante :

  • Nombre total de piles requises par site = piles requises pour les LUN de bases de données + piles requises pour les LUN de journaux

    = 300 + 24

    = 324

Un système CX4-480 comprenant 22 boîtiers de baies de disques possède 330 piles et répond aux besoins.

Return to top

La section précédente contenait des informations sur les décisions de conception qui ont été prises lors de l’étude d’une solution Exchange 2010. La section qui suit fournit un aperçu de la solution.

Return to top

Cette solution comprend au total 36 serveurs Exchange déployés dans une topologie multisite. Douze des 36 serveurs exécutent les rôles serveurs d’accès au client et de transport Hub. Les 24autres serveurs exécutent le rôle serveur de boîtes aux lettres. Chaque site compte un groupe de serveurs d’accès au client composé de quatre serveurs combinés Accès au client/Transport Hub. Il y a trois DAG, chacun comportant huit serveurs de boîtes aux lettres. Les serveurs de fichiers de chaque site hébergent les serveurs témoins de partage de fichiers principal et secondaire pour chaque DAG.

Schéma logique de la solution

à déterminer

Return to top

Chacun des trois sites contient quatre serveurs lames Cisco B200 connectés à une baie de stockage modèle 480 EMC CLARiiON CX4 via les commutateurs redondants Cisco Fabric Interconnect 6120 et Cisco MDS 9134. Les commutateurs Ethernet redondants Cisco Nexus 5010 fournissent l’infrastructure réseau sous-jacente. La charge du trafic client est équilibrée entre le groupe de serveurs d’accès au client sur chaque site par les dispositifs d’équilibrage de charge Cisco ACE 4710.

Schéma physique de la solution

à déterminer

Return to top

Le tableau suivant résume le matériel du serveur physique utilisé dans cette solution.

Résumé du système Cisco Unified Computing

Élément Description

Serveur lame

4 × B200 M1

Processeurs

2 × Intel Zeon x 5570 (2,93 GHz)

Mémoire

96 Go de RAM (12 × 8 Go DIMM)

Carte réseau convergé

M71KR-Q (2 × 10 Gigabit Ethernet et 2 × 4 Gbits/s Fibre Channel)

Stockage de lame interne

2 × disque SAS 146 Go de 10 000 tr/mn (RAID-1)

Châssis

5108 (6RU)

Module d’extension de structure

2 × 2104XP

Module d’interconnexion de structure

2 × 6120XP

Module d’expansion de l’interconnexion de structure

2 × 8 ports Fibre Channel 4 Gbits/s

Le tableau suivant résume le matériel de stockage et réseau utilisé dans cette solution.

Commutateurs LAN et SAN

Élément Description

Commutateur 10 Gigabit Ethernet (GbE)

2 × Nexus 5010 (8 ports fixes 1 GbE/10 GbE, 12 ports fixes 10 GbE, pontage du centre de données)

Commutateur Fibre Channel

2 × MDS 9134 (32 ports fixes 4 Gbits/s)

Le tableau suivant contient des informations sur les logiciels utilisés dans cette solution.

Résumé des logiciels pour la solution

Élément Description

Serveurs hôtes de l’hyperviseur

Windows Server 2008 R2 Hyper-V Enterprise

Machines virtuelles Exchange Server

Windows Server 2008 R2 Enterprise

Rôle serveur de boîtes aux lettres Exchange Server 2010

Enterprise Edition RU2

Rôle serveur de d’accès au client et de transport Hub Exchange Server 2010

Standard Edition RU2

Chemins d’accès multiples et équilibrage des E/S

EMC PowerPath

Return to top

Le tableau suivant résume la configuration du serveur combiné Accès au client/transport Hub utilisée dans cette solution.

Configuration du serveur d’accès au client et de transport Hub

Composant Valeur ou description

Physique ou virtuel

Machine virtuelle Hyper-V

Processeurs virtuels

3

Mémoire

8 GB

Stockage

Disque dur virtuel sur le volume du système d’exploitation du serveur racine

Système d’exploitation

Windows Server 2008 R2

Version d’Exchange

Exchange Server 2010 Standard Edition

Niveau de mise à jour Exchange

Correctif cumulatif de mise à jour 2 Exchange 2010

Logiciel tiers

Aucun

Return to top

Le tableau suivant résume la configuration du serveur de boîtes aux lettres principal (hébergeant les copies de bases de données principale et secondaire sur le site principal pour le DAG) utilisée dans cette solution.

Configuration du serveur de boîtes aux lettres principal

Composant Valeur ou description

Physique ou virtuel

Machine virtuelle Hyper-V

Processeurs virtuels

4

Mémoire

53 GB

Stockage

Disque dur virtuel sur le volume du système d’exploitation du serveur racine

   

Système d’exploitation

Windows Server 2008 R2

Version d’Exchange

Exchange Server 2010 Enterprise Edition

Niveau de mise à jour Exchange

Correctif cumulatif de mise à jour 2 Exchange 2010

Logiciel tiers

Aucun

Le tableau suivant résume la configuration du serveur de boîtes aux lettres secondaire (hébergeant la troisième copie de base de données du site secondaire pour le DAG) utilisée dans cette solution.

Configuration du serveur de boîtes aux lettres secondaire

Composant Valeur ou description

Physique ou virtuel

Machine virtuelle Hyper-V

Processeurs virtuels

2

Mémoire

24 GB

Stockage

Disque dur virtuel sur le volume du système d’exploitation du serveur racine

Système d’exploitation

Windows Server 2008 R2

Version d’Exchange

Exchange Server 2010 Enterprise Edition

Niveau de mise à jour Exchange

Correctif cumulatif de mise à jour 2 Exchange 2010

Logiciel tiers

Aucun

Return to top

Les schémas suivants résument la disposition des copies de bases de données utilisée dans cette solution dans des conditions normales de fonctionnement.

Disposition des copies de bases de données : 1

à déterminer

Disposition des copies de bases de données : 2

à déterminer

Disposition des copies de bases de données : 3

à déterminer

Return to top

Le tableau suivant contient des informations sur le matériel de stockage utilisé dans cette solution.

Stockage unifié EMC NS-480 (CLARiiON CX4-480 intégré)

Élément Description

Stockage

3 CLARiiON CX4-480 (1 par site)

Connectivité de la solution de stockage (Fibre Channel, SAS, SATA, iSCSI)

Fibre Channel

Cache de stockage

32 Go (cache de lecture de 600 Mo et cache d’écriture de 10 160 Mo par port de stockage)

Nombre de contrôleurs de stockage

2 par image de stockage

Nombre de ports de stockage disponibles ou utilisés

8 (4 par port de stockage) disponibles par image de stockage, 4 utilisés (2 par port de stockage)

Bande passante maximale de connectivité de la solution de stockage à l’hôte

8 × 4 Gbits/s

Nombre total de disques testés dans la solution

432 (360 pour les bases de données et 72 pour les journaux sur 3 sites)

Nombre maximal de piles pouvant être hébergées dans la solution de stockage

480 dans une seule baie de stockage

Return to top

Chacune des baies de stockage CX4 modèle 480 utilisées dans la solution ont été configurées comme indiqué dans le tableau suivant.

Configuration du stockage

Composant Valeur ou description

Nombre total de boîtiers de stockage

3

Nombre total de boîtiers de stockage par site

1

Nombre total de disques par boîtier

150

Nombre total de pools de stockage par boîtier

3

Nombre total de disques par pool de stockage (initial)

40

Nombre total de disque par LUN de base de données (initial)

10

Nombre total de disques par LUN de journal

2

Nombre total de disques utilisés par boîtier

144

Taille de LUN pour les bases de données (initiale)

4 020 GB

Taille de LUN pour les journaux

402 GB

Niveau RAID pour les bases de données

5

Niveau RAID pour les journaux

1/0

Le tableau suivant illustre la manière dont le stockage disponible a été conçu et affecté entre les systèmes de stockage CX4 modèle 480.

Configuration du stockage entre les systèmes de stockage CX4 modèle 480

Centre de données DAG Base de données Baie 1 Baie 2 Baie 3

1

1

DB1-24

C1, C2

C3

2

2

DB25-48

C3

C1, C2

3

3

DB49-72

C3

C1, C2

Return to top

Avant de déployer une solution Exchange dans un environnement de production, vérifiez que la solution a été conçue, dimensionnée et configurée correctement. Cette validation doit inclure des tests fonctionnels pour vous certifier que le système fonctionne comme prévu, ainsi que des tests de performances pour vérifier que le système est capable de supporter la charge utilisateur désirée. Cette section décrit l’approche et la méthodologie de test utilisée pour valider la conception du serveur et du stockage pour cette solution. Les tests ci-dessous seront notamment définis en détail :

  • Tests de performances

    • Validation des performances de stockage (Jetstress)

    • Validation des performances du serveur (Loadgen)

  • Tests fonctionnels

    • Validation de la permutation de base de données

    • Validation de la permutation de serveur

    • Validation du basculement de serveur

    • Validation de la permutation de centre de données

Return to top

Le niveau de performances et de fiabilité du sous-système de stockage connecté au rôle serveur de boîtes aux lettres Exchange a un impact considérable sur l’intégrité globale du déploiement Exchange. En outre, de faibles performances de stockage engendrent une latence de transaction élevée, qui se traduit principalement par des problèmes d’accès du client au système Exchange. Pour une utilisation optimale du client, validez le dimensionnement et la configuration du stockage en suivant la méthode décrite dans cette section.

Pour la validation du dimensionnement et de la configuration du stockage Exchange, nous vous recommandons d’utiliser l’outil Microsoft Exchange Server Jetstress. L’outil Jetstress a été conçu pour simuler une charge de travail d’E/S Exchange au niveau de la base de données en interagissant directement avec l’ESE, également connu sous le nom de Jet. L’ESE est la technologie de base de données utilisée par Exchange pour stocker les données de messagerie sur le rôle serveur de boîtes aux lettres. Jetstress peut être configuré pour tester le débit maximal d’E/S disponible dans votre sous-système de stockage dans les limites de performances requises pour Exchange. Jetstress peut également accepter un profil cible de nombre d’utilisateurs et d’Ops ES/s par utilisateur, et vérifier que le sous-système de stockage est capable de maintenir un niveau de performances acceptable avec ce profil. La durée du test peut être ajustée. Aussi, le test peut être exécuté sur une courte période pour valider les performances adéquates ou sur une longue période pour valider également la fiabilité du sous-système de stockage.

L’outil Jetstress est disponible sur le Centre de téléchargement de Microsoft, aux emplacements suivants :

La documentation accompagnant le programme d’installation de Jetstress explique la procédure de configuration et d’exécution d’un test de validation Jetstress sur le matériel de votre serveur.

Il existe deux grands types de configurations de stockage :

  • Scénarios DAS ou de disque interne

  • Scénarios SAN

Dans les scénarios DAS ou de disque interne, un seul serveur accède au sous-système de disque. Les performances du sous-système de stockage peuvent donc être validées de façon isolée.

Dans les scénarios SAN, le stockage utilisé par la solution peut être partagé entre de nombreux serveurs et l’infrastructure qui connecte les serveurs au système de stockage peut également être une dépendance partagée. Cela exige des tests supplémentaires, car l’impact des autres serveurs sur l’infrastructure partagée doit être correctement simulé pour valider les performances et les fonctionnalités.

Les cas de test de validation de stockage suivants ont été exécutés sur la solution et doivent être considérés comme point de départ à la validation du stockage. Des déploiements spécifiques peuvent imposer d’autres critères de validation qu’il est possible de satisfaire avec des tests supplémentaires. Cette liste ne prétend donc pas être exhaustive :

  • Validation du pire scénario de permutation de base de données   Dans ce cas de test, le niveau d’E/S est censé être traité par le sous-système de stockage dans un scénario de permutation pessimiste (plus grand nombre possible de copies actives sur un minimum de serveurs). Selon que le sous-système de stockage est DAS ou SAN, il est possible que ce test doive être exécuté sur plusieurs hôtes pour s’assurer que la charge de la solution de bout en bout sur le sous-système de stockage peut être supportée.

  • Validation des performances de stockage dans un scénario de défaillance et de récupération du système de stockage (par exemple, remplacement et rétablissement d’un disque défaillant)   Dans ce test, les performances du sous-système de stockage lors d’un scénario de défaillance et de rétablissement sont évaluées pour s’assurer que le niveau de performances nécessaire est maintenu pour une utilisation optimale du client Exchange. La même condition s’applique à un déploiement DAS par rapport à un déploiement SAN : si plusieurs hôtes dépendent d’un sous-système de stockage partagé, le test doit inclure leur charge pour simuler l’impact total de la défaillance et du rétablissement.

L’outil Jetstress génère un fichier de rapport à la fin de chaque test. Pour obtenir de l’aide sur l’analyse du rapport, suivez les recommandations contenues dans la section Jetstress 2010 Test Summary Reports.

Vous devez notamment observer les recommandations fournies dans le tableau suivant lors de l’analyse des données du tableau Résultats des tests du rapport.

Analyse des résultats JetStress

Instance du compteur de performance Recommandations relatives au test de performances

Latence moyenne des lectures de base de données d’E/S (ms)

La valeur moyenne doit être inférieure à 20 millisecondes (ms) (0,020 s) et les valeurs maximales doivent être inférieures à 50 ms.

Latence moyenne des écritures de journal d’E/S (ms)

Les écritures de journal sont séquentielles. Les latences d’écriture moyennes doivent donc être inférieures à 10 ms, mais en aucun cas supérieures à 50 ms.

% Temps processeur

La moyenne doit être inférieure à 80 % et la valeur maximale doit être inférieure à 90 %.

Pages de transition avec nouvel objet/s (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2)

La moyenne doit être inférieure à 100.

Le fichier de rapport signale diverses catégories d’E/S effectuées par le système Exchange :

  • Performances d’E/S transactionnelles   Ce tableau signale les E/S qui représentent l’activité utilisateur dans la base de données (par exemple, E/S générées par Outlook). Ces données sont générées en soustrayant les E/S de maintenance en arrière-plan et les E/S de réplication des journaux du nombre total d’E/S mesurées pendant le test. Ces données indiquent les Ops ES/s de base de données réelles générées avec les mesures de latence d’E/S requises pour déterminer si un test de performances Jetstress a réussi ou échoué.

  • Performances d’E/S de maintenance de base de données en arrière-plan   Ce tableau indique les E/S générées en raison d’une maintenance continue de base de données ESE en arrière-plan.

  • Performances d’E/S de réplication des journaux   Ce tableau répertorie les E/S générées à partir d’une réplication simulée des journaux.

  • Performances des E/S totales   Ce tableau dresse la liste du nombre total d’E/S générées lors du test Jetstress.

Return to top

Une fois les performances et la fiabilité du sous-système de stockage validées, assurez-vous que les fonctionnalités, les performances et l’évolutivité de tous les composants du système de messagerie sont validées ensemble. Pour cela, vous devez remonter dans la pile afin de valider l’interaction logicielle du client avec le produit Exchange ainsi qu’avec tous les produits côté serveur interagissant avec Exchange. Pour vous assurer que l’utilisation du client de bout en bout est acceptable et que l’intégralité de la solution peut supporter la charge utilisateur désirée, vous pouvez appliquer la méthode décrite dans cette section pour valider la conception du serveur.

Pour la validation des performances et de l’évolutivité de la solution de bout en bout, il est recommandé d’utiliser l’outil Microsoft Exchange Server Load Generator (Loadgen). Loadgen a été conçu pour produire une charge de travail client simulée sur un déploiement Exchange. Cette charge de travail peut être utilisée pour évaluer les performances du système Exchange, mais également pour évaluer l’impact de diverses modifications apportées à la configuration de la solution globale lorsque le système est soumis à une charge. Loadgen est capable de simuler l’activité du client Microsoft Office Outlook 2007 (en ligne et mis en cache), Office Outlook 2003 (en ligne et mis en cache), POP3, IMAP4, SMTP, ActiveSync et Outlook Web App (plus connu sous le nom d’Outlook Web Access dans Exchange 2007 et versions antérieures). Il peut être utilisé pour générer une charge de travail à protocole unique ou ces protocoles client peuvent être combinés pour générer une charge de travail à plusieurs protocoles.

L’outil Loadgen est disponible sur le Centre de téléchargement de Microsoft, aux emplacements suivants :

La documentation fournie avec le programme d’installation de Loadgen décrit la procédure de configuration et d’exécution d’un test Loadgen sur un déploiement Exchange.

Lors de la validation de la conception du serveur, testez le scénario le plus défavorable sous la charge de pointe prévue. Sur la base d’un certain nombre d’ensembles de données de Microsoft IT et d’autres clients, la charge de pointe est généralement égale au double de la charge de travail moyenne durant le reste de la journée. C’est ce que l’on appelle le ratio de charge de travail maximale/moyenne.

Analyseur de performances

Capture d’écran de l’Analyseur de performances

Dans cet instantané de l’analyseur de performances, qui présente divers compteurs représentant le volume de travail Exchange effectué au fil du temps sur un serveur de boîtes aux lettres de production, la valeur moyenne des opérations RPC par seconde (ligne mise en surbrillance) est en moyenne de 2 386 sur toute la journée. La moyenne de ce compteur durant la période de pointe entre 10 et 11 heures est d’environ 4 971, ce qui donne un ratio de charge de travail maximale/moyenne de 2,08.

Pour vous assurer que la solution Exchange est capable de supporter la charge de travail générée aux heures de pointe, modifiez les paramètres de Loadgen pour générer une charge constante au niveau de pointe moyen, plutôt que de répartir la charge de travail sur toute la journée de travail simulée. Les modules de simulation basés sur les tâches de Loadgen (comme les modules de simulation Outlook) utilisent un profil de tâche qui définit le nombre de fois que chaque tâche se produira pour un utilisateur moyen au cours d’une journée simulée.

Le nombre total de tâches à exécuter pendant une journée simulée est calculé comme suit : nombre d’utilisateurs multiplié par la somme des tâches dans le profil de tâche configuré. Loadgen détermine ensuite la vitesse à laquelle il doit exécuter les tâches pour l’ensemble d’utilisateurs configuré en divisant le nombre total de tâches à exécuter au cours de la journée simulée par la durée du jour simulé. Par exemple, si Loadgen doit exécuter 1 000 000 tâches au cours d’une journée simulée et qu’un jour simulé compte 8 heures (28 800 secondes), Loadgen doit exécuter 1 000 000 ÷ 28 800 = 34,72 tâches par seconde pour supporter la charge de travail requise. Pour augmenter la charge à la valeur maximale désirée, divisez la durée du jour simulé par défaut (8 heures) par le ratio de charge maximale/moyenne (2) et utilisez le résultat comme nouvelle durée de jour simulé.

En reprenant l’exemple de vitesse des tâches, on obtient 1 000 000 ÷ 14 400 = 69,44 tâches par seconde. Cela divise par deux la durée du jour simulé, ce qui permet de doubler la charge de travail réelle sur le serveur et d’atteindre notre objectif de charge de travail moyenne en période de pointe. Vous n’ajustez pas la durée d’exécution du test dans la configuration de Loadgen. La durée d’exécution indique la durée du test et n’affecte pas la vitesse à laquelle les tâches seront exécutées sur le serveur Exchange.

Les cas de test de validation de conception du serveur ont été exécutés sur la solution et doivent être considérés comme point de départ à la validation de la conception du serveur. Des déploiements spécifiques peuvent imposer d’autres critères de validation qu’il est possible de satisfaire avec des tests supplémentaires. Cette liste ne prétend donc pas être exhaustive :

  • Conditions normales de fonctionnement   Dans ce cas de test, la conception de base de la solution est validée avec tous les composants en bon état de fonctionnement (aucune défaillance simulée). La charge de travail désirée est générée sur la solution et les performances globales de la solution sont validées par rapport aux métriques suivantes.

  • Défaillance de serveur unique ou maintenance de serveur unique (sur site)   Dans ce cas de test, un seul serveur est arrêté pour simuler une défaillance inattendue du serveur ou une opération de maintenance planifiée du serveur. La charge de travail qui serait normalement traitée par le serveur indisponible est à présent gérée par d’autres solutions de la topologie de solution, et les performances globales de la solution sont validées.

Les données de performance Exchange peuvent varier légèrement au sein des tests et d’un test à un autre. Il convient de prélever la moyenne de plusieurs tests pour atténuer cette variation. Pour les solutions testées Exchange, au moins trois tests distincts d’une durée de huit heures ont été réalisés. Les données relatives aux performances ont été recueillies pour la durée totale de huit heures du test. Les données récapitulatives des performances ont été recueillies sur une période stable de trois à quatre heures (excepté les deux premières heures et la dernière heure du test). Pour chaque rôle serveur Exchange, une moyenne des données récapitulatives des performances a été établie entre les serveurs pour chaque test, en indiquant une valeur moyenne unique pour chaque point de données. Une moyenne des valeurs pour chaque test a ensuite été établie, en indiquant un point de données unique pour tous les serveurs d’un rôle serveur similaire dans tous les tests.

Avant d’examiner les compteurs de performance ou de commencer votre analyse de validation des performances, vérifiez que la charge de travail que vous envisagiez d’exécuter était identique à celle que vous avez réellement exécutée. Même s’il existe plusieurs manières de déterminer si la charge de travail simulée correspondait à la charge prévue, la méthode la plus simple et la plus cohérente consiste à analyser la vitesse de remise des messages.

Chaque profil de message comprend la somme du nombre moyen de messages envoyés par jour et du nombre moyen de messages reçus par jour. Pour calculer la vitesse de remise des messages, sélectionnez le nombre moyen de messages reçus par jour dans le tableau suivant.

Vitesse maximale de remise des messages

Profil de message Messages envoyés par jour Messages reçus par jour

50

10

40

100

20

80

150

30

120

200

40

160

L’exemple suivant suppose que chaque serveur de boîtes aux lettres contient 5 000 boîtes aux lettres actives dotées d’un profil de 150 messages par jour (30 messages envoyés et 120 messages reçus par jour).

Vitesse maximale de remise des messages pour 5 000 boîtes aux lettres actives

Description Calcul Valeur

Profil de message

Nombre de messages reçus par jour

120

Nombre de boîtes aux lettres actives par serveur de boîtes aux lettres

Non applicable

5 000

Nombre total de messages reçus quotidiennement par serveur de boîtes aux lettres

5 000 × 120

600 000

Nombre total de messages reçus par seconde par serveur de boîtes aux lettres

600 000 ÷ 28 800

20,83

Nombre total de messages ajustés pour la charge de pointe

20,83 × 2

41,67

Vous prévoyez que 41,67 messages par seconde soient remis sur chaque serveur de boîtes aux lettres exécutant 5 000 boîtes aux lettres actives dotées d’un profil de message de 150 messages par jour lors d’une pointe de charge.

La vitesse réelle de remise des messages peut être mesurée à l’aide du compteur suivant sur chaque serveur de boîtes aux lettres : Boîte aux lettres MSExchangeIS(_Total)\Messages remis/s. Si la vitesse de remise des messages mesurée est d’un ou deux messages par seconde par rapport à la vitesse cible, vous pouvez être sûr que le profil de charge désiré a été exécuté avec succès.

Cette section décrit les compteurs et les seuils d’analyse de performances utilisés pour déterminer si l’environnement Exchange a été dimensionné correctement et s’il est capable de fonctionner dans un état sain sur des périodes de pointe prolongées. Pour plus d’informations sur les compteurs pertinents pour les performances d’Exchange, reportez-vous à la section Compteurs et seuils de performances et d’évolutivité.

Pour valider les critères de performance et d’intégrité d’un serveur racine Hyper-V et les applications exécutées sur les machines virtuelles, vous devez avoir cerné les principes de base de l’architecture Hyper-V et son impact sur l’analyse des performances.

Hyper-V inclut trois composants principaux : la pile de virtualisation, l’hyperviseur et les périphériques. La pile de virtualisation traite les périphériques émulés, gère les machines virtuelles et les E/S des services. L’hyperviseur planifie les processeurs virtuels, gère les interruptions et les minuteurs, et contrôle d’autres fonctions au niveau du microprocesseur. L’hyperviseur ne gère pas les périphériques ni les E/S (par exemple, il n’existe aucun pilote d’hyperviseur). Les périphériques font partie du serveur racine ou sont installés sur des serveurs invités dans le cadre des services d’intégration. Étant donné que le serveur racine dispose d’une vue complète du système et contrôle les machines virtuelles, il fournit également des informations d’analyse via les compteurs WMI (Windows Management Instrumentation) et de performance.

Processeur

Pour la validation de l’utilisation du processeur physique sur le serveur racine (ou dans la machine virtuelle invitée), le compteur Processeur virtuel\% Temps processeur n’est pas très utile.

Il est préférable d’examiner le compteur Processeur logique de l’hyperviseur Hyper-V\% de la durée totale d’exécution. Ce compteur indique le pourcentage de temps processeur passé à l’exécution de l’invité et de l’hyperviseur, et doit être utilisé pour mesurer l’utilisation totale du processeur pour l’hyperviseur et toutes les machines virtuelles sur le serveur racine. Ce compteur ne doit pas dépasser 80 pour cent ou la cible d’utilisation maximale que vous avez définie.

 

Compteur Cible

Processeur logique de l’hyperviseur Hyper-V\% de la durée totale d’exécution

<80%

Si vous souhaitez connaître le pourcentage de temps processeur passé à traiter les machines virtuelles invitées, vous pouvez examiner le compteur Processeur logique de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité. Si vous souhaitez connaître le pourcentage de temps processeur passé dans l’hyperviseur, vous pouvez examiner le compteur Processeur logique de l’hyperviseur Hyper-V\% de la durée d’exécution de l’hyperviseur. Ce compteur doit être inférieur à 5 pour cent. Le compteur Processeur virtuel racine de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité indique le pourcentage de temps processeur passé dans la pile de virtualisation. Ce compteur doit également être inférieur à 5 pour cent. Ces deux compteurs permettent également de déterminer le pourcentage du temps processeur physique disponible utilisé pour prendre en charge la virtualisation.

 

Compteur Cible

Processeur logique de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<80%

Processeur logique de l’hyperviseur Hyper-V\% de la durée d’exécution de l’hyperviseur

<5%

Processeur virtuel racine de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<5%

Mémoire

Vous devez vérifier que le serveur racine Hyper-V dispose d’une mémoire suffisante pour prendre en charge la mémoire allouée aux machines virtuelles. Hyper-V réserve automatiquement 512 Mo (cela peut varier en fonction des différentes versions d’Hyper-V) au système d’exploitation racine. Si vous ne disposez pas d’une quantité de mémoire suffisante, Hyper-V empêchera le démarrage de la dernière machine virtuelle. En règle générale, vous n’aurez pas à valider la mémoire sur un serveur racine Hyper-V. Préoccupez-vous plutôt d’allouer une quantité de mémoire suffisante aux machines virtuelles pour prendre en charge les rôles Exchange.

Intégrité des applications

Un moyen simple de déterminer si toutes les machines virtuelles sont dans un état sain consiste à examiner les compteurs Résumé de l’intégrité de la machine virtuelle Hyper-V.

 

Compteur Cible

Résumé d’intégrité de l’ordinateur virtuel Hyper-V\Intégrité valide

1

Résumé d’intégrité de l’ordinateur virtuel Hyper-V\Intégrité critique

0

Serveurs de boîtes aux lettres

Lors de la vérification du dimensionnement adéquat d’un serveur de boîtes aux lettres, concentrez-vous sur le processeur, la mémoire, le stockage et l’intégrité des applications Exchange. Cette section décrit l’approche de validation de chacun de ces composantes.

Processeur

Lors du processus de conception, vous avez calculé la capacité des mégacycles ajustés de la plate-forme de serveur ou de processeur. Vous avez ensuite déterminé le nombre maximal de boîtes aux lettres actives qui pourraient être prises en charge par le serveur sans dépasser 80 pour cent de la capacité des mégacycles disponibles. Vous avez également établi que l’utilisation estimée du processeur doit s’effectuer dans des conditions normales de fonctionnement et lors de divers scénarios de maintenance ou de défaillance du serveur.

Durant le processus de validation, vérifiez que la charge de travail la plus lourde ne dépasse pas 80 pour cent des mégacycles disponibles. Par ailleurs, vérifiez que le taux d’utilisation réel du processeur diffère peu de l’utilisation prévue dans des conditions normales de fonctionnement et dans divers scénarios de maintenance ou de défaillance du serveur.

Pour les déploiements Exchange physiques, utilisez le compteur Processeur(_Total)\% Temps processeur et vérifiez que ce compteur est en moyenne inférieur à 80 pour cent.

 

Compteur Cible

Processeur(_Total)\% Temps processeur

<80%

Pour les déploiements Exchange virtuels, le compteur Processeur(_Total)\% Temps processeur est mesuré dans la machine virtuelle. Dans ce cas, le compteur ne mesure pas l’utilisation du processeur physique, mais l’utilisation du processeur virtuel fourni par l’hyperviseur. Par conséquent, il ne fournit pas une lecture exacte du processeur physique et ne doit pas être utilisé pour valider la conception. Pour de plus amples informations, reportez-vous à l’article Hyper-V: Clocks lie... which performance counters can you trust (en anglais).

Pour valider les déploiements Exchange exécutés sur Microsoft Hyper-V, utilisez le compteur Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité. Ce dernier fournit une valeur plus précise du taux d’utilisation du processeur physique par le système d’exploitation invité. Ce compteur doit être en moyenne inférieur à 80 pour cent.

 

Compteur Cible

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<80%

Mémoire

Lors du processus de conception, vous avez calculé la quantité de cache de base de données nécessaire pour prendre en charge le nombre maximal de bases de données actives sur chaque serveur de boîtes aux lettres. Vous avez ensuite déterminé la configuration de mémoire physique optimale pour répondre aux besoins en cache de base de données et en mémoire système.

Vérifier si un serveur de boîtes aux lettres Exchange dispose d’une quantité de mémoire suffisante pour supporter la charge de travail cible n’est pas une mince affaire. L’utilisation des compteurs de mémoire disponibles pour connaître la quantité de mémoire physique restante n’est pas utile car le gestionnaire de mémoire Exchange est conçu pour solliciter la quasi-totalité de la mémoire physique disponible. La banque d’informations (store.exe) réserve une grande partie de la mémoire physique au cache de base de données. Le cache de base de données est utilisé pour garder les pages de la base de données en mémoire. Lorsque vous accédez à une page en mémoire, il n’est pas nécessaire de récupérer les informations du disque, ce qui permet de réduire les E/S de lecture. Le cache de base de données permet également d’optimiser les E/S d’écriture.

Lorsqu’une page de base de données est modifiée (appelée page impropre), elle reste dans le cache pendant un certain temps. Plus elle reste longtemps dans le cache, et plus elle risque d’être modifiée plusieurs fois avant que ces modifications ne soient écrites sur le disque. La conservation de pages impropres dans le cache entraîne par ailleurs l’écriture de plusieurs pages sur le disque au cours de la même opération (processus appelé fusion d’écriture). Exchange utilise autant que possible la mémoire disponible du système, ce qui explique les faibles quantités de mémoire disponibles sur un serveur de boîtes aux lettres Exchange.

Il n’est pas facile de savoir si la configuration de la mémoire sur votre serveur de boîtes aux lettres Exchange est sous-dimensionnée. Dans la plupart des cas, le serveur de boîtes aux lettres sera toujours opérationnel, mais votre profil d’E/S peut être plus élevé que prévu. Un nombre élevé d’E/S peut engendrer une augmentation des latences de lecture et d’écriture du disque, ce qui risque d’avoir un impact sur l’intégrité des applications et l’expérience de l’utilisateur sur le client. Dans la section des résultats, aucune référence n’est faite aux compteurs de mémoire. Les problèmes potentiels de mémoire seront identifiés dans les sections de résultats de validation du stockage et d’intégrité des applications, où les problèmes liés à la mémoire sont plus aisément détectés.

Stockage

Si votre serveur de boîtes aux lettres Exchange affiche de faibles performances, il est possible que des problèmes de stockage en soient la cause. Les problèmes de stockage peuvent être dus à un nombre insuffisant de disques pour répondre aux besoins en E/S cibles, à la surcharge ou à une mauvaise conception de l’infrastructure de connectivité du système de stockage, ou encore à des facteurs altérant le profil d’E/S cible, tels qu’une mémoire insuffisante, comme indiqué plus haut.

La première étape du processus de validation du stockage consiste à vérifier que les latences de base de données sont inférieures aux seuils cibles. Dans les versions précédentes, les compteurs des disques logiques déterminaient la latence de lecture et d’écriture du disque. Dans Exchange 2010, il est probable que le serveur de boîtes aux lettres Exchange analysé inclue une combinaison de copies de bases de données de boîtes aux lettres actives et passives. Les caractéristiques d’E/S des copies de bases de données actives et passives sont différentes. Dans la mesure où la taille de l’E/S est supérieure à celle des copies passives, les latences sur les copies passives sont généralement plus élevées. Les valeurs cibles de latence pour les bases de données passives sont de l’ordre de 200 ms, soit 10 fois plus que les valeurs cibles pour les copies de bases de données actives. Cela n’est pas très important car des latences élevées sur les bases de données passives n’ont aucune incidence sur l’utilisation du client. Toutefois, si vous utilisez les compteurs de disques logiques traditionnels pour mesurer les latences, vous devez vérifier chacun des volumes et séparer les volumes contenant les bases de données actives et passives. Nous vous recommandons plutôt d’utiliser les nouveaux compteurs Base de données MSExchange d’Exchange 2010.

Lors de la validation des latences sur les serveurs de boîtes aux lettres Exchange 2010, il est recommandé d’utiliser les compteurs décrits dans le tableau suivant pour les bases de données actives.

 

Compteur Cible

Base de données MSExchange\Latence moyenne des lectures (attachées) dans la base de données E/S

<20 ms

Base de données MSExchange\Latence moyenne des écritures (attachées) dans la base de données E/S

<20 ms

Base de données MSExchange\Latence moyenne des écritures dans le journal des E/S

<1 ms

Il est recommandé d’utiliser les compteurs décrits dans le tableau suivant pour les bases de données passives

 

Compteur Cible

Base de données MSExchange\Latence moyenne des lectures (récupération) dans la base de données E/S

<200 ms

Base de données MSExchange\Latence moyenne des écritures (récupération) dans la base de données E/S

<200 ms

Base de données MSExchange\Latence moyenne des lectures dans le journal des E/S

<200 ms

RemarqueRemarque :
Pour afficher ces compteurs dans l’analyseur de performances, vous devez activer les compteurs de base de données avancés. Pour de plus amples informations, consultez la rubrique Procédure d’activation des compteurs de performance étendus ESE.

Lorsque vous validez les latences de disque pour des déploiements Exchange exécutés sur Microsoft Hyper-V, rappelez-vous que les compteurs Latence moyenne de base de données d’E/S (comme de nombreux compteurs temporels) peuvent manquer de précision car la notion de temps dans la machine virtuelle diffère de celle du serveur physique. L’exemple suivant montre que la latence moyenne des lectures (attachées) de base de données d’E/S est de 22,8 dans la machine virtuelle et de 17,3 sur un serveur physique pour la même charge de travail simulée. Si les valeurs des compteurs temporels sont supérieures aux seuils cibles, votre serveur fonctionne probablement correctement. Vérifiez tous les critères d’intégrité avant de prendre une décision concernant l’état du serveur lorsque votre rôle serveur de boîtes aux lettres est déployé dans une machine virtuelle.

Valeurs des compteurs de latence de disque pour les serveurs de boîtes aux lettres virtuels et physiques

Compteur Serveur de boîtes aux lettres virtuel Serveur de boîtes aux lettres physique

Base de données MSExchange/

Lectures (attachées) base de données E/S / Latence moyenne

22.792

17.250

Lectures (attachées) base de données E/S / s

17.693

18.131

Lectures (récupération) base de données E/S / Latence moyenne

34.215

27.758

Écritures (récupération) base de données E/S / s

10.829

  8.483

Écritures (attachées) base de données E/S / Latence moyenne

  0.944

  0.411

Écritures (attachées) base de données E/S / s

10.184

10.963

MSExchangeIS

   

Latence RPC moyenne

   1.966

   1.695

Opérations RPC/s

334.371

341.139

Paquets RPC / s

180.656

183.360

Boîtes aux lettres MSExchangeIS

Messages remis / s

2.062

2.065

Messages envoyés / s

0.511

0.514

Outre les latences de disque, examinez le compteur Base de données\Blocages d’anomalies de pages de bases de données/s Ce compteur indique le taux d’erreurs de page impossibles à corriger en raison de l’absence de pages pouvant être affectées à partir du cache de base de données. Ce compteur doit être égal à 0 sur un serveur sain.

 

Compteur Cible

Base de données\Blocages d’anomalies de pages de bases de données/s

<1

Examinez également le compteur Base de données\Enregistrements journal inachevés/s, qui indique le nombre d’enregistrements de journal qui ne peuvent pas être ajoutés aux tampons de journal par seconde parce que ces derniers sont pleins. Ce compteur doit être en moyenne inférieur à 10.

 

Compteur Cible

Base de données\Enregistrements journal inachevés/s

<10

Intégrité des applications Exchange

Même s’il n’existe à première vue aucun problème au niveau du processeur, de la mémoire et du disque, il est recommandé d’analyser les compteurs standard d’intégrité des applications pour s’assurer que le serveur de boîtes aux lettres Exchange est dans un état sain.

Le compteur MSExchangeIS Client\Latence RPC moyenne fournit une excellente indication quant à l’impact réel des latences de base de données élevées sur l’intégrité et l’utilisation du client Exchange. Souvent, des latences RPC moyennes élevées sont associées à un nombre important de demandes RPC, qui ne doivent en aucun cas être supérieures à 70.

 

Compteur Cible

MSExchangeIS\Latence RPC moyenne

<10 ms en moyenne

MSExchangeIS\Demandes RPC

<70 dans tous les cas

Ensuite, assurez-vous que la couche de transport est saine. Tous les problèmes de transport ou les problèmes en aval du transport qui affectent la couche de transport peuvent être détectés à l’aide du compteur Boîte aux lettres MSExchangeIS(_Total)\Messages mis en file d’attente d’envoi. Le compteur ne doit en aucun cas être supérieur à 50. Des augmentations temporaires de ce compteur peuvent être observées. Cependant, la valeur du compteur ne doit pas augmenter au fil du temps et ne doit pas être maintenue pendant plus de 15 minutes.

 

Compteur Cible

Boîte aux lettres MSExchangeIS(_Total)\Messages mis en file d’attente d’envoi

<50 dans tous les cas

Ensuite, assurez-vous que la maintenance des copies de bases de données est dans un état sain. Tous les problèmes liés à l’expédition ou la relecture des journaux peuvent être identifiés à l’aide des compteurs Réplication MSExchange(*)\CopyQueueLength et Réplication MSExchange(*)\ReplayQueueLength. La longueur de la file d’attente de copie indique le nombre de fichiers journaux de transactions en attente d’être copiés dans le dossier du fichier journal de copie passive et doit être toujours inférieure à 1. La longueur de la file d’attente de relecture indique le nombre de fichiers journaux de transactions en attente d’être relus dans la copie passive et doit être inférieure à 5. Des valeurs plus élevées n’ont pas d’incidence sur l’utilisation du client, mais engendrent des délais de montage de banque plus longs lorsqu’un transfert, un basculement ou une activation est effectué.

 

Compteur Cible

Réplication MSExchange(*)\CopyQueueLength

<1

Réplication MSExchange(*)\ReplayQueueLength

<5

Serveurs d’accès au client

Pour savoir si un serveur d’accès au client est sain, vérifiez l’intégrité du processeur, de la mémoire et de l’application. Pour obtenir une liste détaillée des compteurs importants, reportez-vous à la section Compteurs de serveurs d’accès au client.

Processeur

Pour les déploiements Exchange physiques, utilisez le compteur Processeur(_Total)\% Temps processeur. Ce compteur doit être en moyenne inférieur à 80 pour cent.

 

Compteur Cible

Processeur(_Total)\% Temps processeur

<80%

Pour valider les déploiements Exchange exécutés sur Microsoft Hyper-V, utilisez le compteur Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité. Ce dernier fournit une valeur précise du taux d’utilisation du processeur physique par le système d’exploitation invité. Ce compteur doit être en moyenne inférieur à 80 pour cent.

 

Compteur Cible

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<80%

Intégrité des applications

Pour savoir si l’utilisation du client MAPI est acceptable, utilisez le compteur MSExchange RpcClientAccess\Latence RPC moyenne. Ce compteur doit être inférieur à 250 ms. Des latences élevées peuvent être associées à un grand nombre de demandes RPC. Le compteur MSExchange RpcClientAccess\Demandes RPC doit être en moyenne inférieur à 40.

 

Compteur Cible

MSExchange RpcClientAccess\Latence RPC moyenne

<250 ms

MSExchange RpcClientAccess\Demandes RPC

<40

Serveurs de transport

Pour savoir si un serveur de transport est sain, vérifiez l’intégrité du processeur, du disque et des applications. Pour obtenir une liste détaillée des compteurs importants, reportez-vous à la section Compteurs de serveurs de transport.

Processeur

Pour les déploiements Exchange physiques, utilisez le compteur Processeur(_Total)\% Temps processeur. Ce compteur doit être en moyenne inférieur à 80 pour cent.

 

Compteur Cible

Processeur(_Total)\% Temps processeur

<80%

Pour valider les déploiements Exchange exécutés sur Microsoft Hyper-V, utilisez le compteur Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité. Ce dernier fournit une valeur précise du taux d’utilisation du processeur physique par le système d’exploitation invité. Ce compteur doit être en moyenne inférieur à 80 pour cent.

 

Compteur Cible

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<80%

Disque

Pour déterminer si les performances des disques sont acceptables, utilisez les compteurs Disque logique/physique(*)\Moy. disque s/lecture et écriture pour les volumes contenant les journaux et la base de données de transport. Ces deux compteurs doivent être inférieurs à 20 ms.

 

Compteur Cible

Disque logique(*)\Moy. disque s/lecture

<20 ms

disque logique(*)\Moy. disque s/écriture

<20 ms

Intégrité des applications

Pour savoir si un serveur de transport Hub est dimensionné correctement et exécuté dans un état sain, examinez les compteurs Files d'attentes de MSExchangeTransport décrits dans le tableau suivant. Toutes ces files d’attente contiendront des messages à différentes heures. Vous voulez vous assurer que la longueur de la file d’attente n’est pas maintenue et ne grandit pas sur une période donnée. Si les files d’attente s’allongent, cela peut indiquer une surcharge du serveur de transport Hub. Cette croissance des files d’attente peut être également due à problèmes réseau ou une surcharge du serveur de boîtes aux lettres qui ne parvient pas à recevoir de nouveaux messages. Vous devrez vérifier d’autres composants de l’environnement Exchange pour le savoir.

 

Compteur Cible

Files d’attente de MSExchangeTransport(_total)Remise d’agrégation

<3000

Files d'attente de MSExchangeTransport(_total)\Longueur des files d'attente de remise distante actives

<250

Files d’attente de MSExchangeTransport (_total)\Longueur de la file d’attente de remise dans la boîte aux lettres active

<250

Files d’attente de MSExchangeTransport(_total)\Longueur de la file d’attente de nouvelle tentative de remise dans la boîte aux lettres

<100

Files d'attente de MSExchangeTransport(_total)\Longueur de la file d'attente de soumission

<100

Return to top

Vous pouvez utiliser les informations contenues dans les sections suivantes pour les tests de validation fonctionnels.

Return to top

Une permutation de base de données est le processus par lequel une base de données active individuelle est permutée vers une autre copie de base de données (copie passive), qui est ensuite définie comme nouvelle copie de base de données active. Les permutations de base de données peuvent se produire dans un centre de données et entre plusieurs centres de données. Une permutation de base de données peut être effectuée via la console de gestion Exchange (EMC) ou l’environnement de ligne de commande Exchange Management Shell.

Pour vérifier qu’une copie passive d’une base de données peut être activée avec succès sur un autre serveur, exécutez la commande suivante.

Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>

Critères de réussite : La base de données de boîtes aux lettres actives est montée sur le serveur cible spécifié. Ce résultat peut être confirmé en exécutant la commande suivante.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Return to top

Une permutation de serveur est le processus par lequel toutes les bases de données actives sur un membre du DAG sont activées sur un ou plusieurs membres du DAG. Comme dans la permutation de base de données, une permutation de serveur peut se produire tant au sein d’un centre de données qu’entre plusieurs centres de données, et peut être lancée par la console de gestion Exchange ou l’environnement de ligne de commande Exchange Management Shell.

  • Pour vérifier que toutes les copies passives de bases de données sur un serveur peuvent être activées avec succès sur d’autres serveurs hébergeant une copie passive, exécutez la commande suivante.

    Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>
    

    Critères de réussite : Les bases de données de boîtes aux lettres actives sont montées sur le serveur cible spécifié. Ce résultat peut être confirmé en exécutant la commande suivante.

    Get-MailboxDatabaseCopyStatus <DatabaseName>
    
  • Pour vérifier qu’une copie de chacune des bases de données actives seront activées avec succès sur un autre serveur de boîtes aux lettres hébergeant des copies passives des bases de données, arrêtez le serveur en effectuant l’opération suivante.

    Arrêtez le serveur actif actuel.

    Critères de réussite : Les bases de données de boîtes aux lettres actives sont montées sur un autre serveur de boîtes aux lettres du DAG. Ce résultat peut être confirmé en exécutant la commande suivante.

    Get-MailboxDatabaseCopyStatus <DatabaseName>
    

Return to top

Un basculement de serveur se produit lorsque le membre du DAG ne parvient plus à réparer le réseau MAPI, ou lorsque le service de cluster sur un membre du DAG ne peut plus contacter les autres membres du DAG.

Pour vérifier qu’une copie de chacune des bases de données actives sera activée avec succès sur un autre serveur de boîtes aux lettres hébergeant des copies passives des bases de données, arrêtez le serveur en effectuant l’une des opérations suivantes :

  • Appuyez sur la touche d’alimentation du serveur en la maintenant enfoncée jusqu’à l’arrêt complet du serveur.

  • Débranchez les câbles d’alimentation du serveur. Le serveur est alors mis hors tension.

Critères de réussite : Les bases de données de boîtes aux lettres actives sont montées sur un autre serveur de boîtes aux lettres du DAG. Ce résultat peut être confirmé en exécutant la commande suivante.

Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus

Return to top

La défaillance d’un centre de données ou d’un site ne se gère pas de la même façon que les types de pannes susceptibles de provoquer un basculement de serveur ou de base de données. Dans une configuration à haute disponibilité, la récupération automatique est initiée par le système et la défaillance n’a généralement aucun impact sur la fonctionnalité du système de messagerie. En revanche, une défaillance du centre de données est considérée comme un événement de récupération d’urgence. En tant que tel, la récupération doit être effectuée et terminée manuellement pour que le service du client soit restauré et la panne résolue. Ce processus est appelé permutation de centre de données. Comme dans de nombreux scénarios de récupération d’urgence, la planification et la préparation préliminaires d’une permutation de centre de données permettent de simplifier le processus de récupération et de réduire la durée de la panne.

Pour de plus amples informations, notamment sur les étapes détaillées de la procédure de permutation d’un centre de données, reportez-vous à la section Switchovers de centre de données.

Une opération de permutation de centre de données s'articule en quatre étapes principales, une fois que vous avez décidé d'activer le deuxième centre de données :

  1. Fermeture d’un centre de données (défaillant) exécuté partiellement.

  2. Validation et vérification des conditions requises pour le deuxième centre de données.

  3. Activation des serveurs de boîtes aux lettres.

  4. Activation des serveurs d’accès au client.

Les sections suivantes décrivent les étapes à suivre pour valider une permutation de centre de données.

Lorsque le DAG est en mode DAC (coordination d’activation de la base de données), les actions permettant d’arrêter les autres membres du DAG dans le centre de données principal dépendent de l’état du centre de données défaillant. Effectuez l'une des opérations suivantes :

  • Si les serveurs de boîtes aux lettres du centre de données défaillant sont toujours accessibles (ce qui n’est généralement pas le cas), exécutez la commande suivante sur chaque serveur de boîtes aux lettres.

    Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>
    
  • Si les serveurs de boîtes aux lettres du centre de données défaillant ne sont pas disponibles, mais qu’Active Directory fonctionne dans le centre de données principal, exécutez la commande suivante sur un contrôleur de domaine.

    Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
    
RemarqueRemarque :
Si vous n’arrêtez pas les serveurs de boîtes aux lettres dans le centre de données défaillant ou si vous n’exécutez pas correctement la commande Stop-DatabaseAvailabilityGroup sur les serveurs, un syndrome de « split brain » peut se produire dans les deux centres de données. Il se peut alors que vous deviez arrêter individuellement les ordinateurs via les appareils de gestion de l'alimentation pour satisfaire cette exigence.

Critères de réussite : Tous les serveurs de boîtes aux lettres du site défaillant sont à l’état d’arrêt. Vous pouvez vérifier ce résultat en exécutant la commande suivante à partir d’un serveur dans le centre de données défaillant.

Get-DatabaseAvailabilityGroup | Format-List

Le deuxième centre de données doit être mis à jour pour représenter les serveurs du centre de données principal qui sont arrêtés. À partir d’un serveur du centre de données secondaire, exécutez la commande suivante.

Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly

Cette étape vise à informer les serveurs du centre de données secondaire des serveurs de boîtes aux lettres qui peuvent être utilisés pour restaurer le service.

Critères de réussite : Tous les serveurs de boîtes aux lettres du centre de données défaillant sont à l’état d’arrêt. Pour vérifier ce résultat, exécutez la commande suivante à partir d’un serveur du centre de données secondaire.

Get-DatabaseAvailabilityGroup | Format-List

Avant d’activer les membres du DAG dans le centre de données secondaire, vérifiez que les services d’infrastructure du centre de données secondaire sont prêts pour l’activation du service de messagerie.

Lorsque le DAG est en mode DAC, pour terminer l’activation des serveurs de boîtes aux lettres dans le deuxième centre de données, procédez comme suit :

  1. Arrêtez le service de cluster sur chaque membre du DAG dans le centre de données secondaire. Vous pouvez utiliser la cmdlet Stop-Service pour arrêter le service (par exemple, Stop-Service ClusSvc), ou bien net stop clussvc à partir d’une invite de commandes avec élévation de privilèges.

  2. Pour activer les serveurs de boîtes aux lettres dans le centre de données secondaire, exécutez la commande suivante.

    Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>
    

    Si cette commande réussit, les critères du quorum sont réduits aux serveurs du centre de données secondaire. Si les serveurs de ce centre de données existent en nombre pair, le DAG utilisera l'autre serveur témoin identifié par le paramètre sur l'objet DAG.

  3. Pour activer les bases de données, exécutez l’une des commandes suivantes.

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>
    

    ou 

    Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>
    
  4. Vérifiez les journaux d’événements et examinez tous les messages d’erreur et d’avertissement pour vous assurer que le site secondaire est sain. Tous les problèmes signalés doivent être suivis et résolus avant de monter les bases de données.

  5. Pour monter les bases de données, exécutez la commande suivante.

    Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database
    

Critères de réussite : Les bases de données de boîtes aux lettres actives sont montées sur les serveurs de boîtes aux lettres du site secondaire. Pour vérifier ce résultat, exécutez la commande suivante.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Les clients se connectent à des points de terminaison de service pour accéder aux services et aux données Exchange. Par conséquent, l'activation de serveurs d'accès au client côté Internet implique la modification des enregistrements DNS afin qu'ils pointent vers les nouvelles adresses IP qui seront configurées pour les nouveaux points de terminaison de service. Les clients se connectent ensuite automatiquement aux nouveaux points de terminaison de service d'une des manières suivantes :

  • Les clients poursuivront leur tentative de connexion et doivent se connecter automatiquement une fois que la durée de vie (TTL, Time to Live) a expiré pour l’entrée DNS d’origine et que l’entrée a expiré dans leur cache DNS. Les utilisateurs peuvent également exécuter la commande ipconfig /flushdns à partir d’une invite de commandes pour effacer manuellement leur cache DNS. Si vous utilisez Outlook Web App, le navigateur Web devra éventuellement être fermé et redémarré pour effacer le cache DNS qu’il utilise. Dans Exchange 2010 SP1, ce problème de mise en cache du navigateur peut être minimisé en configurant le paramètre FailbackURL dans le répertoire virtuel owa d’Outlook Web App.

  • Les clients qui démarrent ou redémarrent effectuent une recherche DNS au démarrage et obtiennent la nouvelle adresse IP pour le point de terminaison de service, qui représente un serveur ou un groupe de serveurs d'accès au client du deuxième centre de données.

Pour valider le scénario avec Loadgen, effectuez les opérations suivantes :

  1. Modifiez l’entrée DNS du groupe de serveurs d’accès au client afin qu’elle pointe vers l’adresse IP virtuelle de l’équilibrage de charge matérielle dans le site secondaire.

  2. Exécutez la commande ipconfig /flushdns sur tous les serveurs Loadgen.

  3. Redémarrez le test Loadgen.

  4. Vérifiez que les serveurs d’accès au client du site secondaire supportent maintenant la charge.

Pour valider le scénario avec un client Outlook 2007, effectuez les opérations suivantes :

  1. Modifiez l’entrée DNS du groupe de serveurs d’accès au client afin qu’elle pointe vers l’adresse IP virtuelle de l’équilibrage de charge matérielle dans le site secondaire.

  2. Exécutez la commande ipconfig /flushdns sur le client ou patientez jusqu’à l’expiration de la durée de vie.

  3. Attendez que le client Outlook se reconnecte.

Return to top

Le processus de restauration du service dans un centre de données précédemment défaillant s'appelle une restauration. Les étapes de restauration d'un centre de données défaillant sont similaires à celles d'une permutation de centre de données. La seule différence significative est que les restaurations de centres de données sont planifiées et la panne est souvent d'une durée beaucoup plus courte.

Il est important que la restauration soit effectuée une fois les dépendances de l’infrastructure Exchange réactivées, opérationnelles, stables et validées. Si ces dépendances ne sont pas disponibles ou saines, il est probable que le processus de restauration provoque une panne plus longue que nécessaire et que le processus échoue.

Le rôle serveur de boîtes aux lettres doit être le premier rôle restauré dans le centre de données principal. Les étapes suivantes décrivent en détail le processus de restauration du rôle serveur de boîtes aux lettres (en supposant que le DAG est en mode DAC).

  1. Pour réintégrer les membres du DAG dans le site principal, exécutez la commande suivante.

    Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>
    
  2. Pour vérifier l’état des copies de bases de données dans le centre de données principal, exécutez la commande suivante.

    Get-MailboxDatabaseCopyStatus
    

Une fois que les serveurs de boîtes aux lettres du centre de données principal ont été intégrés dans le DAG, ils ont besoin de temps pour synchroniser leurs copies de base de données. Selon la nature de l'erreur, la durée de la panne et les actions menées par un administrateur durant la panne, un réamorçage des copies de base de données peut s'avérer nécessaire. Par exemple, si au cours de la panne, vous supprimez les copies de bases de données du centre de donnés principal défaillant pour permettre la troncature des fichiers journaux pour les copies actives valides dans le centre de données secondaire, un réamorçage sera nécessaire. À ce stade, chaque base de données peut être synchronisée individuellement. Une fois qu’une copie de base de données répliquée du centre de données principal est saine, vous pouvez passer à l’étape suivante.

  1. Lors du processus de permutation du centre de données, le DAG a été configuré pour utiliser un autre serveur témoin. Pour reconfigurer le DAG afin qu’il utilise un serveur témoin dans le centre de données principal, exécutez la commande suivante.

    Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>
    
  2. Les bases de données réactivées dans le centre de données principal doivent maintenant être démontées dans le centre de données secondaire. Exécutez la commande suivante :

    Get-MailboxDatabase | Dismount-Database
    
  3. Une fois les bases de données démontées, les URL du serveur d'accès au client doivent être déplacées du centre de données secondaire vers le centre de données principal. Pour cela, vous devez modifier l’enregistrement DNS des URL afin qu’il pointe vers le serveur d’accès au client ou le groupe de serveurs d’accès au client dans le centre de données principal.

    ImportantImportant :
    Ne passez à l'étape suivante qu'une fois que les URL du serveur d'accès au client ont été déplacées et que les entrées du cache DNS et TTL ont expirée. L’activation des bases de données dans le centre de données principal avant le déplacement des URL du serveur d’accès au client vers le centre de données invalidera la configuration (par exemple, une base de données montée ne comportant aucun serveur d’accès au client dans son site Active Directory).
  4. Pour activer les bases de données, exécutez l’une des commandes suivantes.

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>
    

    ou 

    Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
    
  5. Pour monter les bases de données, exécutez la commande suivante.

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database
    

Critères de réussite : Les bases de données de boîtes aux lettres actives sont correctement montées sur les serveurs de boîtes aux lettres du site principal. Pour vérifier ce résultat, exécutez la commande suivante.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Return to top

Les tests ont été réalisés dans les installations du Centre technique d’entreprise Microsoft (EEC), un laboratoire de validation de solutions d’entreprise de pointe situé sur le campus principal de Microsoft, à Redmond, Washington.

Avec plus de 125 millions de dollars en matériel et de solides partenariats de longue date avec les principaux fabricants de matériel d’origine (OEM), l’EEC peut répliquer virtuellement n’importe quel environnement de production. L’EEC offre un environnement permettant une collaboration étroite avec les clients, les partenaires et les ingénieurs produits de Microsoft. Cet environnement veille à ce que les solutions de bout en bout de Microsoft répondent aux attentes élevées des clients.

Return to top

La section suivante récapitule les résultats des tests de validation des fonctionnalités et des performances.

Return to top

Le tableau suivant résume les résultats des tests de validation des fonctionnalités.

Résultats de validation des fonctionnalités

Cas de test Résultat Commentaires

Basculement de base de données

Réussi

Effectué sans erreurs

Serveur de basculement

Réussi

Effectué sans erreurs

défaillance d'un serveur ;

Réussi

Effectué sans erreurs

Défaillance de site

Réussi

Effectué sans erreurs

Return to top

Les tests réalisés sur tous les disques pour chacun des sites sur une seule image de stockage montrent que le système CX4-480 traite un peu plus de 8 000 Ops ES/s transactionnelles Exchange 2010 sur huit machines virtuelles Exchange configurées avec un profil utilisateur de 150 messages à 0,15 Ops ES/s et un espace supplémentaire de 20 pour cent. Les performances ont dépassé la référence cible de 5 832 Ops ES/s nécessaires pour cette configuration et ont permis de libérer de l’espace supplémentaire pour les charges de pointe. Les latences de disque étaient toutes comprises dans des limites acceptables conformément aux pratiques recommandées de Microsoft en matière de performances Exchange 2010.

Résultats de validation de la conception du stockage

E/S de base de données Valeurs cibles 4 serveurs de boîtes aux lettres dans des conditions normales de fonctionnement (2 700 utilisateurs par serveur de boîtes aux lettres) 4 serveurs de boîtes aux lettres dans une situation de basculement (5 400 utilisateurs par serveur de boîtes aux lettres) Total

Nombre d’Ops ES/s transactionnelles réalisées (lectures de base de données E/S/s + écritures de base de données E/S/s)

1944 / 3888

3576 Ops ES/s

4488 Ops ES/s

8064 Ops ES/s

Lectures base de données E/S/s

Non applicable

2193

2729

4922

Écritures base de données E/S/s

Non applicable

1439

1703

3142

Latence moyenne des lectures de base de données d’E/S (ms)

<20 ms

14

18

16

Latence moyenne écritures base de données E/S (ms)

Ne constitue pas un bon indicateur de la latence client car les écritures de base de données sont asynchrones

14

18

16

   

Écritures journal E/S/s

Non applicable

1238

1560

2798

Latence moyenne lectures journal E/S (ms)

<10 ms

2

2

2

Return to top

Les sections suivantes résument les résultats de validation de la conception du serveur pour les cas de test.

Validation LoadGen : scénarios de test

Test Description

Conditions normales de fonctionnement

Une charge simultanée de 100 pour cent pour 10 800 utilisateurs a été simulée sur un site, où chaque serveur de boîtes aux lettres gère 2 700 utilisateurs.

Défaillance de serveur unique ou maintenance de serveur unique (sur le site)

La défaillance d’un serveur hôte Hyper-V unique par site a été simulée. Une charge simultanée de 100 pour cent a été exécutée sur un hôte Hyper-V unique, avec une machine virtuelle gérant 5 400 utilisateurs. Seuls trois serveurs combinés Accès au client/Transport Hub ont traité la charge.

Défaillance de site

Une défaillance de site a été simulée, et les images secondaires sur les machines virtuelles du serveur de boîtes aux lettres de secours ont été activées. Une charge simultanée de 100 pour cent a été exécutée sur 21 600 utilisateurs dans un seul site.

Ce cas de test représente la charge de travail maximale dans des conditions normales de fonctionnement. Les conditions normales de fonctionnement désignent un état dans lequel toutes les bases de données actives et passives résident sur les serveurs sur lesquelles elles sont supposées être exécutées. Étant donné que ce cas de test ne représente pas la pire charge de travail, il ne constitue pas le principal test de validation des performances. Il fournit une bonne indication de la façon dont cet environnement doit être exécuté en dehors d’une défaillance ou d’un événement de maintenance du serveur. L’objectif de ce test était de valider l’intégralité de l’environnement Exchange dans des conditions normales de fonctionnement avec une charge de pointe. Toutes les machines virtuelles Exchange ont fonctionné normalement. Loadgen a été configuré pour simuler une charge de pointe. Le profil d’action de 150 messages exécuté en mode de pointe était censé générer deux fois plus de messages envoyés et remis par seconde.

La vitesse de remise des messages vérifie que la charge de travail testée correspondait à la charge cible. La vitesse de remise des messages est légèrement supérieure à la valeur cible, ce qui entraîne une augmentation sensible de la charge par rapport au profil désiré.

 

Compteur Cible Résultat testé

Vitesse de remise des messages par boîte aux lettres

15.0

15.2

Les tableaux suivants présentent les résultats de validation des machines virtuelles de serveurs de boîtes aux lettres principaux.

Processeur

Le taux d’utilisation du processeur est inférieur à 70 pour cent, comme prévu.

 

Compteur Cible Résultat testé

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<70%

69

Stockage

Les résultats de stockage sont satisfaisants. Toutes les latences sont inférieures aux valeurs cibles.

 

Compteur Cible Résultat testé

Base de données MSExchange\Latence moyenne des lectures (attachées) dans la base de données E/S

<20 ms

19

Base de données MSExchange\Latence moyenne des écritures (attachées) dans la base de données E/S

<20 ms

<Moyenne des lectures

18

Base de données\Blocages d’anomalies de pages de bases de données/s

0

0

Base de données MSExchange\Latence moyenne des écritures dans le journal des E/S

<20 ms

5

Base de données\Enregistrements journal inachevés/s

0

0

Intégrité des applications

Exchange est parfaitement sain et tous les compteurs utilisés pour déterminer l’intégrité des applications sont bien inférieurs aux valeurs cibles.

 

Compteur Cible Résultat testé

MSExchangeIS\Demandes RPC

<70

3.0

MSExchangeIS\Latence RPC moyenne

<10 ms

2.0

Boîte aux lettres MSExchangeIS(_Total)\Messages mis en file d’attente d’envoi

0

2.0

Les tableaux suivants présentent les résultats de validation des machines virtuelles de serveurs de boîtes aux lettres secondaires.

Processeur

La taux d’utilisation du processeur est inférieur à 70 pour cent, comme prévu.

 

Compteur Cible Résultat testé

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<70%

26

Stockage

Les résultats de stockage sont satisfaisants. Toutes les latences sont inférieures aux valeurs cibles.

 

Compteur Cible Résultat testé

Base de données MSExchange\Latence moyenne des lectures (récupération) dans la base de données E/S

<100 ms

0

Base de données MSExchange\Latence moyenne des écritures (récupération) dans la base de données E/S

<100 ms

<Moyenne des lectures

16

Base de données\Blocages d’anomalies de pages de bases de données/s

0

0

Base de données MSExchange\Latence moyenne des écritures dans le journal des E/S

<20 ms

3

Base de données\Enregistrements journal inachevés/s

0

0

Intégrité des applications

Les serveurs de boîtes aux lettres secondaires ne conservent que les troisièmes copies de bases de données passives. Les indicateurs d’intégrité des applications Exchange ne sont donc pas applicables à ce scénario.

 

Compteur Cible Résultat testé

MSExchangeIS\Demandes RPC

<70

Non applicable

MSExchangeIS\Latence RPC moyenne

<10 ms

Non applicable

Boîte aux lettres MSExchangeIS(_Total)\Messages mis en file d’attente d’envoi

0

Non applicable

Les tableaux suivants présentent les résultats de validation des machines virtuelles de serveurs d’accès au client et de transport Hub.

Processeur

L’utilisation du processeur est faible, comme prévu.

 

Compteur Cible Résultat testé

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<70%

48

Stockage

Les résultats de stockage semblent satisfaisants. Les latences très faibles ne devraient avoir aucun impact sur le transfert des messages.

 

Compteur Cible Résultat testé

Disque logique/physique(*)\Moyenne disque s/lecture

<20 ms

0.001

Disque logique/physique(*)\Moyenne disque s/écriture

<20 ms

0.005

Intégrité des applications

Les faibles valeurs de latence RPC moyenne confirment l’intégrité du serveur d’accès au client sans aucun impact sur l’utilisation du client.

 

Compteur Cible Résultat testé

MSExchange RpcClientAccess\Latence RPC moyenne

<250 ms

8

MSExchange RpcClientAccess\Demandes RPC

<40

3

Les compteurs Files d’attente de transport sont bien inférieurs à la cible, confirmant ainsi l’intégrité du serveur de transport Hub et sa capacité à traiter et à remettre les messages nécessaires.

 

Compteur Cible Résultat testé

\Files d'attentes de MSExchangeTransport(_total)\Longueur globale des files d'attente de remise (toutes les files d'attente)

<3000

2.5

\Files d'attentes de MSExchangeTransport(_total)\Longueur des files d'attente de remise distante actives

<250

0

\Files d'attentes de MSExchangeTransport (_total)\Longueur des files d'attente de remise des boîtes aux lettres actives

<250

2.3

\Files d'attentes de MSExchangeTransport(_total)\Longueur de la file d'attente de soumission

<100

0

\Files d'attentes de MSExchangeTransport(_total)\Longueur des files d'attente de remise des boîtes aux lettres de nouvelle tentative

<100

0.3

Les tableaux suivants présentent les résultats de la validation du serveur racine Hyper-V.

Processeur

Comme prévu, l’utilisation du processeur est très faible et bien inférieure aux seuils cibles.

 

Compteur Cible Résultat testé

Processeur logique de l’hyperviseur Hyper-V(_total)\% de la durée d’exécution de l’invité

<75%

66

Processeur logique de l’hyperviseur Hyper-V(_total)\% de la durée d’exécution de l’hyperviseur

<5%

2

Processeur logique de l’hyperviseur Hyper-V(_total)\% de la durée totale d’exécution

<80%

68

Processeur virtuel racine de l’hyperviseur Hyper-V(_total)\% de la durée d’exécution de l’invité

<5%

3

Intégrité des applications

Les compteurs récapitulatifs de l’intégrité des machines virtuelles indiquent que toutes les machines virtuelles sont dans un état sain.

 

Compteur Cible Résultat testé

Résumé d’intégrité de l’ordinateur virtuel Hyper-V\Intégrité critique

0

0

L’objectif de ce test était de valider l’intégralité de l’environnement Exchange dans des situations de défaillance ou de maintenance du serveur racine Hyper-V avec une charge de pointe. Toutes les machines virtuelles exécutées sur l’un des serveurs racine Hyper-V du site ont été arrêtées pour simuler une situation de maintenance de l’hôte. Cela s’est traduit par un déplacement des images (copies) de base de données vers d’autres machines virtuelles du serveur de boîtes aux lettres, qui a abouti à une situation de 5 400 utilisateurs par machine virtuelle de serveur de boîte aux lettres. Seule la moitié des serveurs combinés Accès au client/Transport Hub a traité l’accès au client et la remise des messages.

L’objectif en termes de vitesse réelle de remise des messages a été atteint.

 

Compteur Cible Résultat testé

Vitesse de remise des messages par serveur

30

30

Les tableaux suivants présentent les résultats de validation des machines virtuelles de serveurs de boîtes aux lettres principaux.

Processeur

L’utilisation du processeur est légèrement supérieure à la valeur cible. Ce cas de test représente un scénario de défaillance ou de maintenance lors d’une pointe de charge, c’est-à-dire un événement à faible occurrence. Il n’est pas souhaitable de maintenir un taux d’utilisation de processeur aussi élevé sur une longue période.

 

Compteur Cible Résultat testé

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<80%

83

Stockage

Les résultats de stockage semblent acceptables. La latence de lecture moyenne est légèrement supérieure à la cible. La latence moyenne d’écriture de base de données est supérieure à la valeur recommandée. Cette valeur est obtenue lors du pire scénario de défaillance avec une charge de pointe, c’est-à-dire un événement à faible occurrence. Les latences élevées ne plaçant pas les compteurs d’intégrité des applications au-dessus de la valeur cible, l’utilisation du client est toujours acceptable. Il n’est pas souhaitable de maintenir des latences aussi élevées sur une longue période.

 

Compteur Cible Résultat testé

Base de données MSExchange\Latence moyenne des lectures (attachées) dans la base de données E/S

<20 ms

20.5

Base de données MSExchange\Latence moyenne des écritures (attachées) dans la base de données E/S

<20 ms

23

Base de données\Blocages d’anomalies de pages de bases de données/s

0

0

Base de données MSExchange\Latence moyenne des écritures dans le journal des E/S

<20 ms

8

Base de données\Enregistrements journal inachevés/s

0

0

Intégrité des applications

Les compteurs montrent qu’Exchange est toujours raisonnablement sain. Une mise en file d’attente des messages sous une charge de pointe commence à se produire. Il faut éviter que cette situation ne dure trop longtemps.

 

Compteur Cible Résultat testé

MSExchangeIS\Demandes RPC

<70

9.0

MSExchangeIS\Latence RPC moyenne

<10 ms

2.0

Boîte aux lettres MSExchangeIS(_Total)\Messages mis en file d’attente d’envoi

0

77

Les tableaux suivants présentent les résultats de validation des machines virtuelles de serveurs de boîtes aux lettres secondaires.

Processeur

La taux d’utilisation du processeur est inférieur à 70 pour cent, comme prévu.

 

Compteur Cible Résultat testé

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<70%

21

Stockage

Les résultats de stockage sont satisfaisants. Toutes les latences sont inférieures aux valeurs cibles.

 

Compteur Cible Résultat testé

Base de données MSExchange\Latence moyenne des lectures (récupération) dans la base de données E/S

<100 ms

0

Base de données MSExchange\Latence moyenne des écritures (récupération) dans la base de données E/S

<100 ms

<Moyenne des lectures

21

Base de données\Blocages d’anomalies de pages de bases de données/s

0

0

Base de données MSExchange\Latence moyenne des écritures dans le journal des E/S

<20 ms

3

Base de données\Enregistrements journal inachevés/s

0

0

Intégrité des applications

Les serveurs de boîtes aux lettres secondaires ne conservent que les troisièmes copies de bases de données passives. Les indicateurs d’intégrité des applications Exchange ne sont donc pas applicables à ce scénario.

 

Compteur Cible Résultat testé

MSExchangeIS\Demandes RPC

<70

Non applicable

MSExchangeIS\Latence RPC moyenne

<10 ms

Non applicable

Boîte aux lettres MSExchangeIS(_Total)\Messages mis en file d’attente d’envoi

0

Non applicable

Les tableaux suivants présentent les résultats de validation des machines virtuelles de serveurs d’accès au client et de transport Hub.

Processeur

Le taux d’utilisation du processeur est inférieur à 80 pour cent, comme prévu.

 

Compteur Cible Résultat testé

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<80%

74

Stockage

Les résultats de stockage semblent satisfaisants. Les latences très faibles ne devraient avoir aucun impact sur le transfert des messages.

 

Compteur Cible Résultat testé

Disque logique/physique(*)\Moyenne disque s/lecture

<20 ms

0.001

Disque logique/physique(*)\Moyenne disque s/écriture

<20 ms

0.008

Intégrité des applications

Les faibles valeurs de latence RPC moyenne confirment l’intégrité du serveur d’accès au client sans aucun impact sur l’utilisation du client.

 

Compteur Cible Résultat testé

MSExchange RpcClientAccess\Latence RPC moyenne

<250 ms

18

MSExchange RpcClientAccess\Demandes RPC

<40

14

Les compteurs Files d’attente de transport sont bien inférieurs à la cible, confirmant ainsi l’intégrité du serveur de transport Hub et sa capacité à traiter et à remettre les messages nécessaires.

 

Compteur Cible Résultat testé

\Files d'attentes de MSExchangeTransport(_total)\Longueur globale des files d'attente de remise (toutes les files d'attente)

<3000

49

\Files d'attentes de MSExchangeTransport(_total)\Longueur des files d'attente de remise distante actives

<250

0

\Files d'attentes de MSExchangeTransport (_total)\Longueur des files d'attente de remise des boîtes aux lettres actives

<250

43

\Files d'attentes de MSExchangeTransport(_total)\Longueur de la file d'attente de soumission

<100

53

\Files d'attentes de MSExchangeTransport(_total)\Longueur des files d'attente de remise des boîtes aux lettres de nouvelle tentative

<100

4

Les tableaux suivants présentent les résultats de la validation du serveur racine Hyper-V.

Processeur

Le taux d’utilisation du processeur est proche des seuils cibles, ce qui est prévu dans un scénario de défaillance ou de maintenance sous une charge de pointe.

 

Compteur Cible Résultat testé

Processeur logique de l’hyperviseur Hyper-V(_total)\% de la durée d’exécution de l’invité

<75%

77

Processeur logique de l’hyperviseur Hyper-V(_total)\% de la durée d’exécution de l’hyperviseur

<5%

2

Processeur logique de l’hyperviseur Hyper-V(_total)\% de la durée totale d’exécution

<80%

79

Processeur virtuel racine de l’hyperviseur Hyper-V(_total)\% de la durée d’exécution de l’invité

<5%

3

Intégrité des applications

Les compteurs récapitulatifs de l’intégrité des machines virtuelles indiquent que toutes les machines virtuelles sont dans un état sain.

 

Compteur Cible Résultat testé

Résumé d’intégrité de l’ordinateur virtuel Hyper-V\Intégrité critique

0

0

Ce cas de test simule une défaillance de site en faisant basculer les bases de données actives sur le site principal vers les bases de données passives du site secondaire, ce qui entraîne le regroupement de 21 600 boîtes aux lettres sur un seul site. Les quatre machines virtuelles principales du serveur de boîtes aux lettres du site restant gèrent chacune une charge de travail normale de 2 700 boîtes aux lettres actives. Les quatre machines virtuelles des serveurs de boîtes aux lettres secondaires du site restant gèrent à présent chacune 2 700 boîtes aux lettres actives. Chaque serveur racine Hyper-V héberge 5 400 boîtes aux lettres actives.

La vitesse de remise des messages est légèrement supérieure à la valeur cible, ce qui entraîne une augmentation sensible de la charge par rapport au profil désiré.

 

Compteur Cible Résultat testé

Vitesse de remise des messages par serveur

15

15.1

Les tableaux suivants présentent les résultats de validation des machines virtuelles de serveurs de boîtes aux lettres principaux.

Processeur

Les machines virtuelles des serveurs de boîtes aux lettres principaux gèrent une charge de travail normale et présentent des valeurs inférieures au taux d’utilisation cible du processeur, comme prévu.

 

Compteur Cible Résultat testé

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<70%

63

Stockage

Les résultats de stockage sont satisfaisants. Toutes les latences sont inférieures aux valeurs cibles.

 

Compteur Cible Résultat testé

Base de données MSExchange\Latence moyenne des lectures (attachées) dans la base de données E/S

<20 ms

12

Base de données MSExchange\Latence moyenne des écritures (attachées) dans la base de données E/S

<20 ms

13

Base de données\Blocages d’anomalies de pages de bases de données/s

0

0

Base de données MSExchange\Latence moyenne des écritures dans le journal des E/S

<20 ms

4

Base de données\Enregistrements journal inachevés/s

0

0

Intégrité des applications

Exchange est parfaitement sain et tous les compteurs utilisés pour déterminer l’intégrité des applications sont bien inférieurs aux valeurs cibles.

 

Compteur Cible Résultat testé

MSExchangeIS\Demandes RPC

<70

3.0

MSExchangeIS\Latence RPC moyenne

<10 ms

2.0

Boîte aux lettres MSExchangeIS(_Total)\Messages mis en file d’attente d’envoi

0

3

Les tableaux suivants présentent les résultats de validation des machines virtuelles de serveurs de boîtes aux lettres secondaires.

Processeur

Le taux d’utilisation du processeur est légèrement supérieur à la cible de 80 pour cent. Cette valeur est supérieure à celle qui est recommandée, mais ne semble pas avoir d’impact sur d’autres compteurs d’intégrité Exchange. Parce que ce test représente une charge de pointe lors d’un événement de défaillance de site à faible occurrence, le résultat est acceptable. Il n’est pas souhaitable de maintenir ce niveau d’utilisation de processeur sur une longue période.

 

Compteur Cible Résultat testé

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<80%

84

Stockage

Les résultats de stockage sont satisfaisants. Toutes les latences sont inférieures aux valeurs cibles.

 

Compteur Cible Résultat testé

Base de données MSExchange\Latence moyenne des lectures (attachées) dans la base de données E/S

<20 ms

17

Base de données MSExchange\Latence moyenne des écritures (attachées) dans la base de données E/S

<20 ms

<Moyenne des lectures

12

Base de données\Blocages d’anomalies de pages de bases de données/s

0

0

Base de données MSExchange\Latence moyenne des écritures dans le journal des E/S

<20 ms

3

Base de données\Enregistrements journal inachevés/s

0

0

Intégrité des applications

Les compteurs montrent qu’Exchange est sain. Une faible quantité de messages en file d’attente est observée.

 

Compteur Cible Résultat testé

MSExchangeIS\Demandes RPC

<70

3

MSExchangeIS\Latence RPC moyenne

<10 ms

2

Boîte aux lettres MSExchangeIS(_Total)\Messages mis en file d’attente d’envoi

0

106

Les tableaux suivants présentent les résultats de validation des machines virtuelles de serveurs d’accès au client et de transport Hub.

Processeur

La taux d’utilisation du processeur est inférieur à 80 pour cent, comme prévu.

 

Compteur Cible Résultat testé

Processeur virtuel de l’hyperviseur Hyper-V\% de la durée d’exécution de l’invité

<70%

63

Stockage

Les résultats de stockage semblent satisfaisants. Les latences très faibles ne devraient avoir aucun impact sur le transfert des messages.

 

Compteur Cible Résultat testé

Disque logique/physique(*)\Moyenne disque s/lecture

<20 ms

0.002

Disque logique/physique(*)\Moyenne disque s/écriture

<20 ms

0.003

Intégrité des applications

Les faibles valeurs de latence RPC moyenne confirment l’intégrité du serveur d’accès au client sans aucun impact sur l’utilisation du client.

 

Compteur Cible Résultat testé

MSExchange RpcClientAccess\Latence RPC moyenne

<250 ms

9

MSExchange RpcClientAccess\Demandes RPC

<40

7

Les compteurs Files d’attente de transport sont bien inférieurs à la cible, confirmant ainsi l’intégrité du serveur de transport Hub et sa capacité à traiter et à remettre les messages nécessaires.

 

Compteur Cible Résultat testé

\Files d'attentes de MSExchangeTransport(_total)\Longueur globale des files d'attente de remise (toutes les files d'attente)

<3000

5

\Files d'attentes de MSExchangeTransport(_total)\Longueur des files d'attente de remise distante actives

<250

0

\Files d'attentes de MSExchangeTransport (_total)\Longueur des files d'attente de remise des boîtes aux lettres actives

<250

4

\Files d'attentes de MSExchangeTransport(_total)\Longueur de la file d'attente de soumission

<100

0

\Files d'attentes de MSExchangeTransport(_total)\Longueur des files d'attente de remise des boîtes aux lettres de nouvelle tentative

<100

1

Les tableaux suivants présentent les résultats de la validation du serveur racine Hyper-V.

Processeur

Le taux d’utilisation du processeur est supérieur à la cible de 80 pour cent. Parce que ce test représente une charge de pointe lors d’un événement de défaillance de site à faible occurrence, le résultat est acceptable. Il n’est pas souhaitable de maintenir ce niveau d’utilisation de processeur sur une longue période.

 

Compteur Cible Résultat testé

Processeur logique de l’hyperviseur Hyper-V(_total)\% de la durée d’exécution de l’invité

<75%

85

Processeur logique de l’hyperviseur Hyper-V(_total)\% de la durée d’exécution de l’hyperviseur

<5%

2

Processeur logique de l’hyperviseur Hyper-V(_total)\% de la durée totale d’exécution

<80%

87

Processeur virtuel racine de l’hyperviseur Hyper-V(_total)\% de la durée d’exécution de l’invité

<5%

3

Intégrité des applications

Les compteurs récapitulatifs de l’intégrité des machines virtuelles indiquent que toutes les machines virtuelles sont dans un état sain.

 

Compteur Cible Résultat testé

Résumé d’intégrité de l’ordinateur virtuel Hyper-V\Intégrité critique

0

0

Return to top

Ce livre blanc contient un exemple de procédure à suivre pour concevoir, tester et valider une solution Exchange 2010 pour les environnements client composés de 32 400 boîtes aux lettres sur plusieurs sites déployés sur du matériel Cisco et EMC. La méthodologie par étapes décrite dans le présent document aborde les décisions de conception importantes qui permettent de relever les principaux défis tout en veillant à répondre aux principaux besoins de l’entreprise.

Return to top

Pour obtenir la documentation complète d’Exchange 2010, consultez la rubrique Exchange Server 2010.

Pour des informations complémentaires sur Cisco et EMC, consultez les ressources suivantes :

Le présent document est fourni « en l’état ». Les informations contenues dans ce document, y compris les adresses URL et les autres références à des sites Internet, pourront faire l’objet de modifications sans préavis. Vous assumez tous les risques d’utilisation.

Ce document ne vous fournit pas de droits légaux pour la propriété intellectuelle des produits Microsoft. Vous pouvez copier et utiliser ce document à des fins internes et de référence.

Return to top

 
Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft