> Mobilité > Dossier Exchange Server : Exchange 2010 et la haute disponibilité (2/2)

Dossier Exchange Server : Exchange 2010 et la haute disponibilité (2/2)

Mobilité - Par Laurent Teruin - Publié le 26 novembre 2010
email

La détection des corruptions de base est assurée par l’active Manage.

Celui-ci se décompose en deux modules séparés PAM et SAM (Principal Active Manager et Standby Active Manager).

Dossier Exchange Server : Exchange 2010 et la haute disponibilité (2/2)

Le premier s’exécute sur le noeud du cluster qui héberge le cluster, le second sur chaque serveur faisant partie du DAG.

Les fonctions assurées par le PAM sont les suivantes (Extrait Microsoft Technet)

  • décide quelle copie de base de données est active ou passive ;
  • détecte les changements de topologie ;
  • réagit aux pannes de serveur.


Les fonctions assurées par le SAM sont les suivantes :

  • fournit les informations concernant les serveurs détenteurs des bases actives au client PAM à savoir les serveurs de d’accès client et de transport ;
  • détecte les pannes de base locales à la machine ;
  • réagit aux pannes par une requête au PAM pour initialisation d’un basculement.


Haute disponibilité de la couche transport

Assez parlé des DAG qui de toute façon feront sûrement l’objet d’articles complémentaires. Intéressons-nous à la couche transport. Là aussi, quelques nouveautés sont à préciser.

Trois nouvelles fonctionnalités sont à l’affiche.

  • Shadowing de messages
  • Automated Server Recovery
  • Benne de transport (Dumpster 2.0)


Shadowing de messages

La fonctionnalité est relativement simple à expliquer. Le principe pour un serveur de transport est de garder dans une file d’attente particulière les messages qu’il va délivrer soit vers des serveurs Edge, soit vers des serveurs tiers comme des serveurs relais de type Ironport, Fortimail, Proofpoint etc… Le but du jeu est donc de s’assurer, par des requêtes régulières gérées par le composant Shadow Redudancy Manager (SRM) s’exécutant sur chaque serveur de transport Exchange 2010, que les messages soumis au serveur suivant sont correctement acheminés. Dans le cas d’une non-remise ou d’une perte de connexion entre le serveur de transport, son edge ou son serveur de relais de messagerie, les messages seront soumis à un autre serveur permettant leur acheminement. Le délai de non connexion admis par le serveur de transport avec son serveur suivant (Next Hop) est par défaut de 300 secondes.

Cette nouvelle disponibilité devrait permettre de fiabiliser la remise de messages et même si en pratique, elle peut autoriser la remise en double, les utilisateurs que nous sommes tous, apprécieront, plutôt que de ne rien recevoir, ce nouveau dispositif. Je pense notamment à certains usages critiques qui ont lieu dans certaines entreprises où l’arrivée d’un message est directement liée à des processus métier (commandes, facturation, départ de camions, bateaux etc..).

Nous reviendrons bien sûr dans nos articles futurs sur le fonctionnement intrinsèque de ces dispositifs et notamment les modes de fonctionnement dans le cas de produits ne supportant pas ces fonctionnalités.

Téléchargez gratuitement cette ressource

Guide de Services Cloud Managés

Guide de Services Cloud Managés

Accélérer votre transformation digitale, protéger et sécuriser vos environnements Cloud avec les offres de support, d'accompagnement et de services managés. Découvrez le TOP 3 des Services Managés pour accompagner la transformation de vos environnements Cloud, gagner en agilité et en sécurité dans un monde d'incertitudes.

Mobilité - Par Laurent Teruin - Publié le 26 novembre 2010