Etapes pour monter un DAG :
la console Exchange ou Powershell, vous devrez créer un DAG, c'est-à-dire, le nom du regroupement des serveurs. C’est lors de cette étape qu’il est demandé le nom du FSW ainsi que le serveur qui l’hébergera.
Dans ce cas, il est conseillé de configurer les disques des serveurs en RAID afin de sécuriser les disques. En effet, si vous ne sécurisez pas les disques, en cas de problème sur l’un des disques d’un serveur, il n’y aura plus qu’une seule réplique avant de perdre les informations.
Par contre, si vous disposez d’au moins trois serveurs dans le DAG, vous pouvez choisir d’avoir trois copies des bases. Dans ce cas, le RAID n’est plus nécessaire car en cas de panne d’un disque, il restera deux copies dans le DAG. En résumé, le RAID est remplacé par les multiples répliques. Dans un DAG, tous les serveurs sont actifs. En cas de problème sur une base, seule la base défectueuse démarre sur un des serveurs du DAG disposant d’une réplique. Les autres bases qui sont hébergées sur le serveur où la base a eu un problème continent à fonctionner comme si rien ne s’était passé. Il existe au niveau d’un DAG, un processus tournant sur chaque serveur chargé de la gestion des états des bases.
Ce processus est actif (alors appelé SAM) sur le serveur disposant de la ressource cluster group. Sur les autres serveurs du DAG, ce processus est passif (PAM). Le SAM surveille en permanence l’état des bases et, en cas de problème sur l’une d’entre elle, il détermine la copie qui doit démarrer. En ce qui concerne l’impact côté client, nous en parlerons un peu plus tard. Une base d’un DAG ne peut être répliquée qu’à l’intérieur du même DAG. Il n’y a aucun échange entre les serveurs de deux DAGs différents. Chaque serveur Exchange 2010 peut héberger 100 bases. Les noeuds d’un DAG peuvent être sur un même site physique ou sur un site distant sur un sous réseau différent.
La seule limite connue à ce jour, sachant que nous sommes sur une version bêta, est le débit réseau entre les noeuds des DAGs pour permettre une réplication. Nous n’avons pas de chiffres actuellement concernant ce réseau. Par contre, à la différence de ce qui se passe pour la réplication d’un CCR ou SCR Exchange 2007, les logs sont compressés lors de la réplication afin de limiter la bande passante nécessaire. Il est possible de spécifier des préférences d’ordre de basculement entre les copies.
Ceci se paramètre au niveau de chaque copie. Ainsi, si vous avez trois copies d’une base sur un site physique principal et deux copies sur un site de secours, vous pouvez configurer les copies pour qu’en cas de problème sur la base active, le basculement se fasse en priorité sur une des copies du site principal et de ne basculer sur le site de secours que si aucune copie du site principal n’est disponible. Voir Figures 2 et 3.
Vous avez peut-être remarqué un peu plus haut, que je vous ai dit que les serveurs pouvaient héberger l’ensemble des rôles. En effet, les rôles HUB et CAS sont maintenant supportés sur les mêmes serveurs que les MBX même s’ils sont configurés dans un DAG. Ce point est important car il signifie qu’il est maintenant possible d’avoir une infrastructure Exchange 2010 hautement disponible avec seulement deux serveurs au lieu de quatre avec Exchange 2007.
Cela permettra aux PME d’augmenter la disponibilité de leur messagerie à moindre coût et de façon plus efficace qu’avec le LCR proposé par Exchange 2007, ce qui explique également sa disparition dans Exchange 2010. Vous vous dites sans doute que toutes ces copies de bases Exchange vont nécessiter beaucoup d’espace disque.
Oui, vous avez raison, mais c’est aussi l’une des raisons qui ont poussé l’équipe de Redmond à travailler autant sur les optimisations de JET pour stocker les données sur de très gros disques, peu coûteux. Changements autour du rôle CAS Maintenant que vous allez avoir plusieurs copies d’une même base Exchange dans le DAG, et que potentiellement, n’importe laquelle peut devenir active, vous vous demandez certainement comment le client Outlook s’y retrouve et se connecte au bon serveur.
C’est là qu’intervient le plus gros changement apporté au rôle CAS. Jusqu’à présent, le CAS avait pour rôle la gestion des clients dit « Internet » : OWA, POP, IMAP, ActiveSync et RPC/HTTP. Seuls les clients MAPI, se connectaient aux serveurs MBX. Avec Exchange 2010, tous les clients, sans exception, se connectent sur le CAS.
Les serveurs MBX ne sont accédés que par les CAS et les HUB. Quand Outlook construit son profil, il récupère le nom du CAS ou de la ferme de CAS qui correspond au site dans laquelle sa boîte aux lettres est active. Chaque échange d’Outlook se fait donc avec le CAS. Le CAS dispose d’un service qui lui permet de connaître le nom du serveur du DAG qui détient la base active. Ce service est informé de l’état des bases grâce aux SAM et PAM qui fonctionnent sur chaque noeud du DAG.
Le CAS redirige donc les requêtes du client Outlook vers le serveur MBX détenant la base active de l’utilisateur. Quand un problème survient sur la base active et qu’une copie de cette base redémarre sur un autre serveur du DAG, le PAM du serveur faisant fonctionner la nouvelle base active envoie cette information aux CAS du site. Ainsi, la prochaine requête du client Outlook sera dirigée vers cette nouvelle base de façon transparente pour l’utilisateur.
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
