Exchange your Mind

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archives de la catégorie ‘Exchange 2010 Service Pack 1’

RDM or not RDM

Publié par Anthony Costeseque le juin 29, 2012


Là est la question !

Bonjour à tous,

La question qui revient régulièrement lorsque l’on parle de vitaliser Exchange 2010 et que le choix se porte sur l’hyperviseur de VMware vSphere, c’est quelle enveloppe utiliser pour le stockage.

RDM : Raw Device Mapping (accès direct au stockage présenté)

OU

VMFS : un Datastore formaté avec le système de fichier propriétaire de VMware, le VMFS (celui contiendra des fichiers à plat de disque dur de type .vmdk)

Détruisons tout de suite le mythe qui remonte à VMware 3.5 et précédant ! Et qui est incrusté dans l’inconscient collectif ;)

Il n’y a plus de différences de performances entre VMFS et RDM, vous ne gagnerez pas en performance en utilisant du RDM !

(Le gain ne sera absolument pas perceptible !)

Maintenant faisons une comparaison entre les deux :

RDM :

  • Mapper 1 LUN vers 1 virtual machine, donc nous avons une isolation des I/O
  • En fonction du nombre de LUNs necessaires, la limite des 256 LUNs sera rapidement atteinte !
  • Permet d’utiliser les outils de backup/réplication fournie par la baie de stockage reposant sur Volume Shadow Copy Service (VSS)
  • Support pour les disques partagés en cluster
  • Support pour l’utilisation avec VMware Site Recovery Manager
  • Support de volumes jusqu’à 64TB (RDM en mode physique)

VMFS :

  • Solution préférée, utilise tous les avantages des fonctionnalités liées au stockage présente (elle celles futures)
  • Un volume (Datastore) peut contenir plusieurs VMs (ou être dédié à une VM)
  • Augmente l’utilisation du stockage, fourni une meilleur flexibilité, une administration et un management plus simple
  • Non supporté pour les disques partagés en cluster
  • Support pour l’utilisation avec VMware Site Recovery Manager
  • Disque virtuel .vmdk limité à 2TB

 

Bilan : VMFS recommandé :)

Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE

Publié dans 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 1 Comment »

Exchange et le Stockage – Partie 11

Publié par Anthony Costeseque le décembre 4, 2011


Bonjour,

Dans la prochaine série de billet sur le stockage dans Exchange, nous verrons les bonnes pratiques chez chaque constructeur de stockage « intelligent ».

Et nous allons commencer aujourd’hui avec EMC².

Chacun d’entre vous pourra trouver les repères dont il a besoin en fonction du constructeur avec qui il travaillera :)

Par conséquent nous n’expliquerons pas ce qui se passe derrière chaque concept (nom technique) des technologies propres à chaque constructeur.

Pour toute questions ou point qui ne vous ne semblerez pas clair n’hésitez pas à laisser des commentaires.

  1. Commençons par le commencement le type de la baie !

Il est évident que le model sera conditionné par la taille de votre future infrastructure : Le nombre d’utilisateurs et la taille des boîtes aux lettres étant les principaux facteurs.

Chez EMC² nous parlerons maintenant de VNX (nouvelle baie unifiées (Block & File)).

Le standard sera une VNX5300 et pour les déploiements plus importants on passera sur un VNX5500 (le plus important étant le nombre maximum de disque supporté)

VNX5300 : 125 disks

VNX5500 : 250 disks

VNX5700 : 500 disks

En règle générale sur un déploiement d’au moins 10000 utilisateurs on a souvent 2 salles (voir 2 sites) pour la Haute Disponibilité et donc 2 VNX5300 font parfaitement l’affaire.

  1. Ensuite vient le type de disque

Les VNX supportent FC/SAS/NL-SAS/SATA/Flash(SSD)

Nous l’avons vu dans les précédents billets, Exchange est optimisé du côté des IO permettant l’utilisation de disque 7200tr/m donc la règle est la suivante :

Faible IOs requis et large capacité de boîtes aux lettres (2Go) -> On utilisera du NL-SAS (ou encore du SATA) 7200 tr/m

Important IOs requis et faible capacité de boites aux lettres (<1Go) -> On utilisera du FC ou du SAS 10000 tr/m voir 15000 tr/m (si besoin)

Jusqu’à maintenant j’ai toujours vu du NL-SAS 7200 tr/m de 2To pour les déploiements que j’ai fait.

Je ne parle pas ici de Flash(SSD) nous en parlerons plus tard :)

  1. Puis le type de RAID

Attention cette étape est très importante.

Sur les VNX nous pouvons choisir entre RAID 1/0 (striping + mirroring), RAID 5 (striping + parity), and RAID 6 (striping + double parity), une fois de plus dans les précédents billets nous en avons déjà parlé (performance/pénalité RAID/Ratio Data utile/Data parité/etc)

Nous choisirons dans 95% des cas du RAID 10 pour éviter une pénalité RAID forte en écriture et fournir les IOs nécessaires pour soutenir les bases de données ainsi que les logs !

  1. Le type de connexion

Stockage « intelligent » donc pas de DAS que du SAN en FC ou iSCSI.

Je vous recommande du FC pour les 8Gb/s de bande passante (2 ports FC de 4Gb/s en roud robin)
ainsi que la faible latence !

L’iSCSI est bien aussi mais demande tout de même des switch dédiés pour le trafic stockage (optimisés iSCSI si possible) mais le problème vient surtout de la bande passante disponible ! De façon classique nous avons 2Gb/s (2 ports Ethernet de 1Gb/s en roud robin) qui peuvent vite représenter un goulot d’étranglement sur des infrastructures importantes ! (rappelez-vous le background database maintenance (BDM) et son besoin en bande passante !). Les ports iSCSI 10Gb/s existent pour les VNX et peuvent représenter une alternative intéressante mais vos switch Ethernet devront les supporter !

Si vous pensez mettre en place une infrastructure FCoE (10Gb) alors pas de problèmes du moment que toute la chaine est prévue pour ! (switch Nexus etc).

  1. Enfin les recommandations générales

Si votre baie est multi usage (pas uniquement Exchange) :

  • Taille des pages du cache 8KB
  • Utiliser un set de disques uniquement pour exchange (pas de mix avec des luns pour d’autres applications)
  • Commencer par vérifier les IOs nécessaires avant la capacité nécessaire
  • Si vous n’utilisez pas de système de réplication, ne placer pas une database et ses logs sur le même set de disques !
    • Le but ici sera de placer des databases avec les logs d’autre databases (de façon croisée)
  • Si vous utiliser un DAG ou autre système de réplication (non recommandé) vous pouvez mettre database et ses logs sur le même set de disques
  • Attention rappel ! sans DAG vous ne pouvez pas utiliser de bases > à 200Go
  • Les copies des databases dans le DAG ne doivent pas être sur le même set de disques (pour une même base)
  • Bien repartir la charge sur les Storage Processor des baies
  • Windows NTFS file système formaté en taille d’unité d’allocation de 64KB
  • Si RAID 5 est utilisé, ne pas utiliser de metaLUNs sur plusieurs RAID Group !!

Si votre baie est à usage unique pour Exchange :

  • Taille des pages du cache 16KB
  • Le reste pareil
  1. Un exemple de découpage


10000 utilisateurs à 1,5Go de boîte aux lettres (principe de séparation des bases de données et des logs)

  1. Considérations particulière VNX

Parlons un peu du Flash (SSD), EMC² utilise le Flash avec 2 concepts : FAST Cache & FAST VP

Est-ce que FAST Cache améliore les performances pour Exchange 2010 ?

Et bien non ! FAST Cache n’a pas d’impacts sur Exchange (ni bonne ni mauvaise)

Si vous voulez tout de même l’utiliser, activer le uniquement sur les LUNs des bases de données (pas sur les logs).

De plus ça n’aidera pas sur le passage des tests Jetstress ! :p

Et maintenant est ce que FAST VP a un intérêt pour Exchange ?

Et bien non aussi ! Et même qu’ici il a un mauvais effet sur la technologie ! tout cela à cause de background database maintenance (BDM) (encore lui ;) ) qui fausse les statiques pour le déplacement des chunk de 1Go dans le pool.

Donc à éviter !!

Est-ce que les Thin LUNs peuvent être utilisées ?

Ce n’est pas recommandé pour le moment (les thin LUN ne sont pas recommandés lorsque l’on recherche des performances !)

Si vous voulez des informations sur le design dans des baies VMAX ou encore VPLEX, envoyez moi un mail.

Documents de références disponibles sur PowerLink :

h8127-deployment-exchange-unified-wp.pdf

h8888-Exchange2010-EMC-storage-best-practices-wp.pdf

h8849-VNX5300-20Kusers-Exchange2010.pdf

Bonne lecture

Anthony COSTESEQUE

Publié dans Exchange 2010 Service Pack 1, Exchange Server 2010, Performance-2010, Stockage-2010 | 1 Comment »

Exchange : Correctif KB2550886 pour Windows 2008 R2 / R2SP1

Publié par Teruin laurent le novembre 23, 2011


KB2550886 – A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working

Le correctif proposé corrige des problèmes de de verrouillage de cluster en cas de problématique réseau. Il est vivement conseillé sur des infrastructures étendues sur deux sites distants. Dans le cas contraire le patch est malgré tout recommandé mais moins vital que pour les infrastructures réparties sur deux centres de données.

Dans le cas ou des perturbations réseaux sont rencontrées par Windows Failover cluster, la logique de reconnexion des nœuds du cluster engendrerai un blocage de la base de données du cluster ayant pour conséquence une perte des services de basculement.

Les équipes de Microsoft confirment avoir rencontré ces scénarios de blocage lors de perte de connexion réseau avoisinant les 60 Secondes. La résultante étant un blocage complet (deadLock) de l’intégralité du cluster avec pour conséquence un arrêt de toutes les bases de données.

Comme il n’est pas évident de déterminer quels nœuds du cluster sont effectivement bloqués (deadlockés) la seule solution est de redémarrer l’ensemble des membres du DAG afin de résoudre ce "verrou mortel".

Le patch ainsi délivré permet de résoudre ce problème et comprend les correctifs suivants:

http://support.microsoft.com/kb/2549472 – Cluster node cannot rejoin the cluster after the node is restarted or removed from the cluster in Windows Server 2008 R2
http://support.microsoft.com/kb/2549448 – Cluster service still uses the default time-out value after you configure the regroup time-out setting in Windows Server 2008 R2
http://support.microsoft.com/kb/2552040 – A Windows Server 2008 R2 failover cluster loses quorum when an asymmetric communication fail

Il est à noter que ce correctif concerne également les clusters répartis en environnement Exchange 2007 reposant sur les technologies SCC et CCR. Par contre ne sont concerné que ceux fonctionnant dans l’environnement Windows 2008 R2 ou Windows 2008 R2 SP1.

A l’installation nous avons rencontré le problème suivant : Installer Encountered an error : 0X80070422


Ceci est dû au fait que les services BIT et Windows Update étaient arrêtés

Cordialement
Laurent Teruin

 

Publié dans 1-EXCHANGE 2010, Cluster-2007, Cluster-2010, Exchange 2010 Service Pack 1, Windows Server 2008 R2 | Leave a Comment »

Un patch pour les DAG

Publié par Anthony Costeseque le novembre 22, 2011


Bonjour,

Voici un patch qu’il est fortement recommandé d’installer sur vos serveurs MBX en cluster (DAG).

Sur tout destiné aux configurations multisites, il ne fera cependant pas de mal à toutes les configurations (DAG).

Le patch est à télécharger ici : KB2550886 – A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working

Plus de détails ici : http://blogs.technet.com/b/exchange/archive/2011/11/20/recommended-windows-hotfix-for-database-availability-groups-running-windows-server-2008-r2.aspx

Cordialement,

Anthony COSTESEQUE

Publié dans Cluster-2010, Exchange 2010 Service Pack 1, Exchange Server 2010 | Leave a Comment »

Exchange et le Stockage – Partie 10

Publié par Anthony Costeseque le novembre 20, 2011


Bonjour,

Déjà 10 parties ! Ça passe vite !! Si ce sujet (le stockage et Exchange) vous intéresse n’hésitez pas à laisser des commentaires (vous pouvez me proposer des thèmes que vous souhaiteriez approfondir).

Exchange et le Stockage – Partie 1

Exchange et le Stockage – Partie 2

Exchange et le Stockage – Partie 3

Exchange et le Stockage – Partie 4

Exchange et le Stockage – Partie 5

Exchange et le Stockage – Partie 6

Exchange et le Stockage – Partie 7

Exchange et le Stockage – Partie 8

Exchange et le Stockage – Partie 9

Nous allons parler aujourd’hui de « background database maintenance (BDM) ou encore Checksumming (contrôle de parité) ».

Mais quelle est donc cette fonctionnalité ? Pour les personnes qui font du design coté stockage pour les bases de données, ce terme n’est pas inconnu il est présent dans la feuille de calcul au niveau des résultats de l’onglet « Role Requirements » tout en bas …


Si on fait un tour sur Technet on trouve sur cette page http://technet.microsoft.com/fr-fr/library/ee832791.aspx on trouve la définition de la fonctionnalité :

Les E/S de maintenance de la base de données en arrière-plan sont des E/S de fichier de bases de données séquentielles associées au contrôle de parité des copies de base de données actives et passives. La maintenance de base de données en arrière-plan présente les caractéristiques suivantes :

  • Sur les bases de données actives, elle peut être configurée pour s’exécuter 24 × 7 ou pendant la fenêtre de maintenance en ligne. La maintenance de base de données en arrière-plan (contrôle de parité) s’exécute sur les copies de base de données passives 24 × 7. Pour en savoir plus, voir « Analyse de bases de données en ligne » dans la rubrique Nouvelles fonctionnalités de banque d’informations principales dans Exchange.
  • Lit environ 5 Mo par seconde pour chaque base de données à analyse active (copies actives et passives). Les E/S sont séquentielles à 100 %, ce qui permet au sous-système de stockage de traiter les E/S de manière efficace.
  • Arrête d’analyser la base de données si le contrôle de parité s’effectue en moins de 24 heures.
  • Émet un événement d’avertissement si l’analyse ne se termine pas dans un délai de 3 jours (non configurable).

L’analyse de base de données en ligne (également appelée Contrôle de parité de la base de données) a également été modifiée. Dans Exchange 2007 Service Pack 1 (SP1), vous pouviez utiliser la moitié du délai de défragmentation en ligne pour ce processus d’analyse de base de données (pour s’assurer qu’Exchange lisait chaque page de votre base de données dans un délai donné afin de détecter toute corruption). Cette E/S est séquentielle à 100 % (et donc facile sur le disque) et revient sur la plupart des systèmes à un taux de parité d’environ 5 mégaoctets (Mo)/s.

Dans Exchange 2010, l’analyse de base de données en ligne contrôle simplement la parité de la base de données et exécute des opérations de blocage de banque Exchange 2010. L’espace peut être perdu en raison des blocages, l’analyse de base de données en ligne recherche et récupère l’espace perdu. Le système présent dans Exchange 2010 est conçu en considérant que chaque base de données est intégralement analysée une fois tous les trois jours. Un événement d’avertissement est déclenché si les bases de données ne sont pas analysées. Dans Exchange 2010, il existe désormais deux nœuds pour exécuter l’analyse de base de données en ligne sur les copies de base de données actives :

  • Exécuter en tant que dernière tâche dans le processus de maintenance de la base de données de boîtes aux lettres. Vous pouvez configurer la durée d’exécution en modifiant la planification de la maintenance de la base de données de boîtes aux lettres. Cette option fonctionne mieux pour les plus petites bases de données dont la taille ne dépasse pas 1 téraoctet (To).
  • Exécuter en arrière-plan 24h/24 et 7j/7, comportement par défaut. Cette option fonctionne bien pour les bases de données volumineuses, jusqu’à 2 To, où vous avez besoin de plus de temps pour contrôler la parité des bases de données. Exchange analyse la base de données une seule fois par jour et déclenche un événement d’avertissement si l’analyse ne se termine pas dans un délai de sept jours.

Vous pouvez configurer l’analyse de la base de données en ligne afin qu’elle ne s’exécute pas 24h/24 et 7j/7 en désactivant la case à cocher (si vous ne voulez pas de surcharge d’E/S pendant une période de pointe). Dans ce cas, la dernière partie de la fenêtre d’analyse de la base de données en ligne sert à contrôler la parité de la base de données et à récupérer l’espace perdu.

Pour plus d’informations sur la configuration de la maintenance de base de données, consultez la rubrique Gérer des bases de données de boîtes aux lettres.

 

Que faut-il retenir ? Et bien :

  1. Le process peut être ajusté (la plage d’exécution) sur les bases de données actives.
  2. Le process ne peut pas être ajusté sur les bases de données passives !!
  3. Ce sont uniquement des IOs séquentielles en lecture d’une taille supérieure à ceux des bases de données ! ils font 256KB contre 32KB pour les databases.
  4. Chaque base (active ou passive) doit être intégralement vérifiée tous les 3 jours
  5. Il faut compter 5MB/s par bases de données dans les calculs de bande passante entre les serveurs et le stockage
  6. On en déduit que plus les bases sont grandes plus on réduit le nombre de bases et donc moins on est touché par le background database maintenance !
  7. Si on est pas en mode HA pour utiliser des bases de 2To on est obligé d’utiliser des bases de 200Go max, on voit vite que le nombre de bases va augmenter et donc on sera beaucoup plus touché par le background database maintenance !!

 

Passons à un exemple, dans mon billet Partie 9 nous avons vu un design pour 22000 utilisateurs.

En version JBOD RAID-Less nous avions calculé 40 bases de données actives et 120 bases de données passives pour un total de 160 bases de données (sur 4 serveurs)

Le calcul est simple … 160*5=800MB/s ce n’est pas négligeable … !! Vous voyez maintenant l’importance de cette fonctionnalité en termes de charge !

Pour être sur que tout le monde voit bien, on parle ici de MB, Mega Byte, pas de Mega bite ! En Mb cela nous donne environ 8000Mb/s (soit environ 8Gb/s).

Maintenant je pense que tout le monde se pose des questions ;) comment est-ce possible ?

Tout d’abord il faut ramener le ration à « par serveur » donc /4, ce qui nous donne 200MB/s soit environ 2Gb/s

Dans notre scenario JBOD RAID-Less nous aurions pu utiliser des baies de stockage HP MDS600 en attachement SAS 6Gb/s.

Un serveur est double attaché (à un switch SAS) à 1 MDS600 donc il a potentiellement 2x6Gb/s soit 12Gb/s de bande passante possible.

Donc tout va bien :) nous avons 4 serveurs avec chacun 1 MDS600 donc la charge est supportée ! (nous sommes en attachement directe SAS (l’idée du JBOD RAID-Less))

Maintenant passons à la version RAID ! Nous avions calculé 28 bases de données actives et 28 bases de données passives pour un total de 56 bases de données (sur 4 serveurs)

Le calcul reste le même 56*5=280MB/s soit environ 2800Mb/s (environ 2,8Gb/s)

Ramenons le à « par serveur » donc /4, nous avons par serveur 70MB/s donc environ 700Mb/s à soutenir.

Nos serveurs sont double attachés en fibre à des switch FC, en règle général les équipements fibres sont en 4Gb/s (le 8Gb/ est chère et moins rependu) nous avons donc 2x4Gb/s soit 8Gb/s de disponible.

Jusqu’ici tout va bien on soutien largement la charge ! Mais attention, en règle générale dans ce type de configuration, nous ne ciblons qu’une seul baie de stockage ! Souvent reliée à 2 fabric SAN par 4 fibres 4Gb/s (2 Chemins par fabric).

Donc nos 4 serveurs vont charger les 4 ports de la baie. Si vous avez bien designez votre infra (bien reparti les LUN sur les 2 contrôleurs, etc) les 2,8Gb/s ne vous poserons pas de problèmes !

 

Vous ferez donc plus attention à l’avenir lors de vos design sur la partie bande passante à soutenir :p

Pour toutes questions n’hésitez pas !

Bon calculs :)

Anthony COSTESEQUE

Publié dans Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 2 Comments »

Exchange 2010 SP1 : Répartition de charge 1/2

Publié par Teruin laurent le octobre 30, 2011


Introduction

La venue de Microsoft Exchange 2010 a fortement nécessité l’acquisition ainsi que la mise en place de répartiteur de charge matériel. Bien sûr me direz-vous, la répartition Windows est toujours là, mais est-ce vraiment jouable ? Comment répartir correctement la charge réseau dans un environnement exchange 2010 avec ce type de procédé. C’est ce que je vous propose de regarder.

En premier lieu, et par déontologie, je vous propose un petit retour sur les solutions possibles que vous pourriez mettre en place. A ce jour 3 choix sont envisageables.

  • Répartition de charge NLB
  • Répartition de charge Round Robin
  • Répartition de charge matérielle
  1. Répartition de charge Windows NLB ou WNLB.

Cette répartition de charge est présente dans n’importe quels serveurs Windows, qu’il soit en version standard ou en version Entreprise. Comme dans quasi-totalité des cas, vos serveurs de transport HUB ou vos serveurs d’accès clients s’exécutent sur des serveurs possédant la licence Standard, Cette solution est activable nativement.

Seulement, si elle fait partie de la licence serveur, la couche NLB n’as pas grand rapport avec l’environnement Exchange. Cette couche logicielle ne va pas par exemple, vérifier si les services publiés derrière l’adresse IP NLB sont en ordre de marche. Ainsi, si pour une raison quelconque un serveur IIS s’arrête, le NLB continuera à distribuer ce serveur comme destination aux clients de messagerie. En fait, tant que votre serveur répond via TCPIP alors le service NLB considère qu’il est valide, et ce même si tous les services Exchange sont arrêtés. D’autre part la mise en place de l’environnement NLB s’avère également complexe dans des environnements géographiquement étendus comme le sont de plus en plus les environnements Exchange.

La couche WNLB est également limitée par plusieurs facteurs comme le nombre de nœud quelle peut supporter, 8 au maximum. De plus, elle est incompatible avec des serveurs Exchange qui exécutent la couche Windows Failover clustering. Dans les environnements possédant un nombre de boites aux lettres important, elle va poser problème en raison du nombre de port limité à 65 000 depuis une seule et unique adresse IP. Mais nous allons expliciter cela. Pour finir, l’ajout ou la suppression d’un nœud au sein d’un cluster IP va provoquer la déconnexion des utilisateurs. Ce qui va de facto limiter son usage dans le cas des opérations de maintenance. Voici donc résumé les limitations de cette répartition de charge, qui vous l’aurez compris ne retient que peu mon attention dans la construction d’architecture Exchange redondantes. Son principal avantage ?… il est d’être gratuit.

  1. Répartition de charge Round Robin.

La répartition de charge Round Robin distribue le flux grâce aux fonctionnements DNS. Le principe est simple. Créez deux enregistrements DNS portant le même nom de domaine (nom de votre Client Access Array) et attribuez-lui deux adresses IP différentes. Activez le mode RoundRobin dans le server DNS (Par défaut dans Windows Server) et le tour est joué. Un coup sur deux, le DNS va renvoyer l’adresse 1 ou l’adresse 2. Enfantin, pas cher, simple, sauf que … c’est nettement insuffisant pour l’environnement Exchange 2010.

Comme WNLB, le round Robin n’a aucune idée de l’état des services Windows et même si le serveur est arrêté, il continuera à renvoyer au client l’adresse IP en question. Quant aux chances de connexion du client, sur un serveur hors service…… elles seront faibles.

En réalité ces deux modes de répartition de charge, sont relativement obsolètes et non pas évolués au fur et à mesure de l’évolution de l’environnement Windows. Conçus pour de la répartition de charge TSE ou de simple connexion IP, ils s’avèrent totalement dépassés dans l’environnement Exchange.

Mais est-ce vraiment si compliqué que cela de faire de la répartition de charge Exchange correctement. ? Et bien … cela dépend ! Comme un jour m’a dit un jour une personne de Microsoft, Exchange 2007 vous a fait découvrir les coulisses des certificats, Exchange 2010 vous fera découvrir les sous-sols de la répartition de charge matérielle. Alors c’est parti !

  1. Répartiteur de charge matériel (HLB ou ADC).

En opposition avec les deux protocoles que je vous ai présenté, les répartiteurs de charges matériels offrent beaucoup plus de possibilité et notamment la répartition de charge selon plusieurs critères. Car une des questions à se poser c’est sur quels critères votre répartiteur de charge va se baser pour répartir le flux clients vers les serveurs Exchange

La première possibilité est l’adresse IP du client. Lorsque le répartiteur de charge matériel identifie un client avec son adresse Ip (ex : 192.168.1.1) , il le connecte sur le serveur Exchange Numéro 1. Pour une autre adresse IP (ex : 192.168.1.2) , il le positionnera sur le numéro 2 , etc etc . L’avantage de cette répartition est de garantir que pour une session IP, le client à l’adresse 192.168.1.1, sera toujours affecté au serveur Exchange 1.

Pour quelle raison ? Pour tout simplement garantir par exemple dans OWA que l’utilisateur n’ait pas à se reconnecter lorsqu’il demande à voir le message suivant. C’est effectivement ce qui se passerait si pour une même session IP Owa, le répartiteur de charge acheminait le client vers un autre serveur d’accès client. Tout cela pour maintenir la persistance de session. Deux termes qu’il nous faut définir.

  1. Session et persistance

Les problèmes de persistance de sessions viennent entre du fait que par nature, le protocole HTTP n’a pas été conçu pour à l’origine pour être de type applicatif mais plutôt orienté lecture et récupération de document. De ce fait, le protocole HTTP ne maintient pas de connexion (Stateless) en permanence avec les serveurs Web qu’il consulte. Parallèlement, l’usage de ce protocole à évolué, et il est utilisé aujourd’hui pour comme un frontal applicatif (Exchange OWA par exemple, Site d’achat en ligne etc..) usage qui demande nécessairement la persistance de session (Statefull).

Une des solutions et qui fonctionne correctement pour mettre en place une notion de session entre le client et le serveur est l’usage de Cookie qui, stocké sur le poste client permet à l’applicatif de retrouver les éléments des sessions (SessionID). C’est par ailleurs grâce à ce mécanisme que nous arrivons à maintenir les sessions Outlook Web Access.

L’exemple ci-dessous donne une idée de ce que l’on peut trouver dans un Coolie de session et notamment la notion d’Id de session.

Cookie: JSESSIONID=9879876473431
Cache-Control: no-cache
Host: 127.0.0.1:8080
Connection: Keep-Alive

 Une fois la session créée par le biais de Session ID et de cookie, les répartiteurs de charges ou plutôt les ADC (Application Delivery Controller) vont se charger de récupérer cette session ID de chaque client de façon à orienter les requêtes d’un client toujours sur le même serveur. On parle alors de persistance. Plusieurs solutions sont possibles. La première est de se baser sur L’ID SSL d’une session HTTPS (généré par le serveur dans la phase de négociation) par exemple. La seconde est simplement d’utiliser un cookie de session transféré dans l’entête HTTP et généré par le serveur Web.

Autre solution alternative consiste pour garantir la notion de session, à ce baser sur l’adresse IP du client. Ce baser sur l’adresse IP c’est bien, mais à condition que vos clients en possèdent une toutes différentes ! Je m’explique. Si vos clients viennent d’un sous réseau naté de votre entreprise ou si ils utilisent un serveur proxy d’agence, ils posséderont virtuellement la même adresse IP et votre répartiteur de charge sera bien incapable de répartir la charge. Résultat vous vous retrouverez, avec tous les clients connectés sur le même serveur Exchange.

En réalité tout dépend de la façon dont vous allez implémenter votre répartiteur de charge matériel et comment se dernier agira sur les flux clients vis-à-vis de votre infrastructure Exchange d’accès client.

Snat / Dnat

La mise en place d’un répartiteur de charge ou ADC va en partie conditionner la façon dont ce dernier doit agir avec vos serveurs Exchange. La première possibilité est de placer votre Répartiteur de charge en coupure de vos infrastructures Parefeux


 

La seconde est de le placer sur le réseau de l’entreprise.


Dans le cas où le répartiteur de charge est en coupure, il est évident que le flux entrant et sortant (réponse des serveurs d’accès client) passera par le répartiteur de charge. Dans Le cas contraire, ou le répartiteur de charge est sur le réseau local, il est possible que le flux entrant passe alors par le répartiteur de charge mais que le serveur réponde directement aux clients.

En fait tout dépend d dont la translation d’adresse est faite et dont le réseau est organisé. Un petit tour vers les notions de Snat et Dnat s’impose donc.

  1. SNAT ou Source NAT

Le Source NAT (translation d’adresse source) correspond à la modification de l’adresse source dans un paquet translaté. Dans ce cas, votre répartiteur de charge va changer l’adresse source du paquet client par une adresse IP positionnée sur votre répartiteur que vous aurez désignée. Le but de cette opération est par conséquent de s’assurer que votre serveur CAS, renvoi la réponse de facto à votre répartiteur de charge au lieu de le renvoyer directement au client originel. Vous noterez que dans ce cas précis, le répartiteur de charge n’a même pas besoin d’être en coupure physique. Pour effectuer cette opération vous aurez plusieurs choix et notamment le choix de faire une simple translation d’adresse vers un adresse ip unique ou alors, vers un pool d’adresse IP positionné sur votre répartiteur. Dans le premier cas on parlera de SNAT Standard dans le second de SNAT pool.

 


Ce mode de translation peut être utile car d’un point de vue firewall seul le Répartiteur de charge est concerné. Par contre dans Exchange les choses se compliquent un peu.

 

Explication : Dans le cas du SNAT, et vous l’aurez compris, vous perdez (coté Exchange) la notion d’adresse client, puisque toutes les adresses IP du client sont modifiées par l’adresse ou les adresses sélectionnées (Snat Pool) dans votre répartiteur de charge. De ce fait, et si vous faites cela pour l’environnement SMTP interne par exemple, vous perdez notamment la possibilité dans les connecteurs de réception de limiter le relai par adresses IP.
Pour rappel, voir set-receiveconnector et le paramètre RemoteIprange des connecteurs de réception. (http://technet.microsoft.com/fr-fr/library/bb125140.aspx)

Limitation du SNAT

.

Les fonctionnalités de SNAT sont intéressantes mais limitées, car le nombre de port ouverts maximum pour une seule adresse Ip est de 65,535 par destination. Ce qui peut être très vite atteint (environ 6000 utilisateurs). Dans ce cas il faudra privilégier l’utilisation des fonctions de SNAT pool pour dépasser cette limite.
Par contre, si vous projetez d’utiliser les fonctions de SNAT Pool et que vos serveurs d’accès client doivent recevoir des flux Mapi RPC (Je ne parle pas de Outlook anywhere ici mais de connexion MAPI Outlook) alors, il faudra que le répartiteur de charge adresse vers le serveur CAS toujours la même adresse source par connexion RPC. En gros si un client Mapi se connecte sur un HLB effectuant du SNAT pool, il faut que cette connexion garde toujours la même adresse IP de sortie vers le serveur Cas.

DNAT ou Destination NAT
Le Destination NAT correspond à la modification de l’adresse destination dans un paquet translaté. Il est utilisé pour la NAT statique, lorsqu’on veut accéder à un serveur sur un réseau local. Cette solution consiste à garder l’adresse IP du client mais cacher les adresses IP local du serveur d’accès client Exchange.

Bon vous voilà paré pour la seconde partie plus axée sur l’environnement Exchange 2010

Cordialement
Laurent Teruin

Publié dans Cas-2010, Exchange 2010 Service Pack 1, Publication-2010 | 3 Comments »

Exchange 2010 SP1 Rollup 6 disponible !

Publié par David PEKMEZ le octobre 29, 2011


Bonjour, le rollup 6 d’Exchange 2010 SP1 est disponible !

Description : http://support.microsoft.com/kb/2608646

Téléchargement : http://www.microsoft.com/download/en/details.aspx?id=27849

Warning:

Managing RBAC roles might display warnings or errors if Exchange 2010 SP1 RU6 is partially deployed in the organization

http://support.microsoft.com/kb/2638351

Bonnes mises à jour !

David Pekmez

Publié dans Exchange 2010 Service Pack 1, Mise-a-jour-2010 | Leave a Comment »

Exchange 2010 SP2: Changement de cap pour le mode hébergé

Publié par Teruin laurent le octobre 14, 2011


Avec la venue du SP1, Microsoft à implémenté un mode hosted qui pouvait être activé en utilisant lors de l’installation du produit le commutateur /Hosting Mode (Voir article : http://technet.microsoft.com/en-us/library/ff923251.aspx). L’objectif de ce mode d’installation est de permettre une complète séparation des annuaires dans le cas où les services exchange doivent abriter plusieurs sociétés qui ne devaient pas se voir au sein de la même organisation. Cette configuration de facto s’adresse aux hébergeurs afin de mutualiser leurs ressources Exchange.
Ce mode n’offrait pas d’outils supplémentaires mais avait pour fonction d’offrir aux hébergeurs une complète séparation des carnets d’adresses.

Cependant les fonctionnalités suivantes dans ce mode d’installation ne sont pas présentes. Ce qui au vu de ces dernières pouvaient représenter un handicap certain

  • Exchange Management Console
  • Public Folders
  • Unified Messaging Server role
  • Edge Transport Server role
  • GalSync 2007
  • Active Directory Federated Services
  • Business-to-Business features such as cross-premises message tracking and calendar sharing
  • IRM
  • Outlook 2003 support (EnableLegacyOutlook)
  • Same forest upgrade from Exchange 2007
  • Resource forest
  • Parent-child domains
  • Discontiguous namespace
  • Disjoint namespace

.Ainsi les équipes produits Microsoft ont décidé d’y mettre fin (à terme) et de fournir une solution autre via l’arrivée du Service Pack2 Exchange 2010

Le nouveau mode pour l’installation d’un mode Hosté se basera donc sur l’utilisation d’un mode on Premise classique
Avec l’arrivée sur SP2, le mode hosté (/hosting mode) sera toujours présent mais ne bénéficiera pas de fonctionnalité supplémentaire et de facto sera supporté par les équipes MS. Ce Mode continuera par conséquent d’être disponible. Le nouveau mode Hosté (Hébergement partagé) sera donc présent supporté uniquement en version Exchange 2010 SP2 et la migration d’un environnement Exchange 2010 /Hosting Mode vers Exchange 2010 SP2 hébergement partagé demandera le déploiement d’une forêt séparée.

Les équipes de Microsoft se sont engagées à fournir un guide pour permettre la mise en place d’un mode hébergement partagé et un guide de migration étape par étape pour la mise à jour d’un environnement Exchange 2007 HMC ou EXchange 2010 SP1 / Hosting Mode vers Exchange 2010 SP2. Des outils d’automatisation et des solutions de panneau de contrôle seront également fournies aux partenaires hébergeurs.

Ce changement de cap va donc permettre aux hébergeurs Exchange de pouvoir fournir une large gamme de fonctionnalité actuellement indisponibles mais également pas mal de travail de migration ;-)). Un des avantages sera notamment de permettre l’intégration de Lync 2010 Serveur dans l’environnement Exchange et l’activation des services UM notamment.

Du travail en perspective mais à terme l’accès aux fonctionnalités de base.

Cordialement
Laurent TERUIN

Article original de Kevin Allison :
http://blogs.technet.com/b/exchange/archive/2011/10/13/future-of-hosting-mode.aspx

Publié dans 1-EXCHANGE 2010, Exchange 2010 Service Pack 1 | Leave a Comment »

Exchange et le Stockage – Partie 8

Publié par Anthony Costeseque le octobre 9, 2011


Les précédents billets sur le stockage dans Exchange :

Exchange et le Stockage – Partie 1

Exchange et le Stockage – Partie 2

Exchange et le Stockage – Partie 3

Exchange et le Stockage – Partie 4

Exchange et le Stockage – Partie 5

Exchange et le Stockage – Partie 6

Exchange et le Stockage – Partie 7

 

Comment Microsoft fait pour supporter plus d’un billion d’emails par jour ?

C’est que nous allons voir aujourd’hui.

 

Le 22 septembre Chris Jones SVP Windows Live écrit un billet sur "A petabyte per week"

http://windowsteamblog.com/windows_live/b/windowslive/archive/2011/09/22/a-petabyte-per-week.aspx

Décrivant les changements qui vont se mettre en place chez Microsoft autour du stockage de la messagerie Hotmail.

 

Historiquement Hotmail repose sur du RAID, à l’heure ou Microsoft prône le JBOD/RAID-Less avec Exchange 2010 il était temps qu’ils montrent l’exemple :)

 

On quitte le RAID


 

Jusqu’à maintenant un mail d’un utilisateur se trouve sur plusieurs RAID Group, ce qui permet dans le cas de la perte d’une grappe complète (pire scenario) de ne pas perdre ce mail.

Cela était intéressant jusqu’à l’arrivé des disques de grande capacité (supérieur à 1To).

 

On passe au JBOD (Just a Bunch of Disks)


L’unité n’est plus la LUN (Logical Unit) compose de X Disques mais le disque.

Les problèmes doivent maintenant être traité par le software, là ou avant c’était le contrôleur qui s’en chargé.

Sur tout du côté des erreurs sur les disques qui corrompt les données ! Avec du RAID, grâce à la parité (sur du RAID5 par exemple) la donnée peut être reconstruite. Sans RAID il faut que la partie software soit captable de corriger ce type de problèmes.

Tout comme Exchange 2010 le code pour Hotmail scan en permanence les disques pour vérifier qu’il n’y a pas de corruptions et le cas échéant, les corrige.

Maintenant que l’intelligence est dans le software, à tout moment on sait combien de copie d’un mail sont disponibles, s’il est trop faible des copies sont créées ailleurs, etc.

Il y a aussi la partie metadata du mail (l’état lu/non lu, classement dans un répertoire, etc) qui sont-elles stockées séparément du mail.

 

Le problème du JBOD se situe surtout sur la rapidité et le nombre d’actions (IOPS) dont il est capable.

Dans le contexte d’Hotmail cela représente un vrai goulot d’étranglement !

D’out l’ajout d’une partie SSD (Solid State Drive) ou encore Flash Storage pour limiter cette effet.

Etant donnée le prix de ces disques encore très élevé, ils ne servent qu’à aider et ne peuvent remplacer le JBOD.

 

En fait ce qui représente le plus de charge sur les disques sont la metadata lié aux mails ! L’état d’un mail lu / non lu, son classement dans les répertoires, les conversations (position des mails dans une conversation), synchronisation des téléphones mobiles, etc

Ces données représentent une quantité minime par rapport aux mails eux-mêmes.

 

Le but sera donc de mettre les metadatas sur du SSD et les mails sur du JBOD.

 


La migration a déjà commencé, il y a environ 30 Millions de personnes sur le JBOD et 100 Millions qui vont être migrées dans les prochains mois.

 

Anthony COSTESEQUE.

Publié dans 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 3 Comments »

Administration distante – Windows Srv 8

Publié par Anthony Costeseque le septembre 25, 2011


Aujourd’hui nous allons avoir un avant-gout des nouveautés introduites dans Windows Serveur 8 du côté de PowerShell (qui passe en v3).

J’ai ajouté dans mon domaine une machine sous Windows Server 8 Preview.

Et la première chose qui attire l’œil du côté des fonctionnalités est :


Windows PowerShell Web Access !


Une fois l’installation terminée, que s’est-il passé ?


Un répertoire est créé dans la webdirectory racine de IIS.


Un script setup.ps1 est disponible

Nous activons la prise en charge des scripts avec la cmdlet :

Set-ExecutionPolicy RemoteSigned

Puis nous lançons le setup.ps1


Une webapp et un PoolApplicatif sont créés.


Il faut maintenant importer un certificat SSL ou en créer un nouveau (SelfSigned si besoin)


Puis « binder » le certificat sur le Default Web Site



On redemarre IIS


IISreset /noforce

Et on test cette nouvelle WebApp !! en allant sur l’URL https://fqdnDeVotreServeur/pswa


Il nous reste plus qu’à ce logger



Nous sommes connectés en local sur notre serveur et nous pouvons l’administrer.

Mais ce n’est pas tout, cette fonctionnalité permet de servir de passerelle pour aller se connecter sur les autres serveurs de l’infrastructure.

Pour cela il suffira que le Remote administration soit activité (Enable-PSRemoting).

Je l’active sur mon serveur Exchange 2010 :


Enable-PSRemoting



Me voilà sur mon serveur Exchange 2010, il ne reste plus qu’à charger la PSSnapin d’Exchange 2010 pour l’administrer.


Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010


Je peux faire un Test-ServiceHealth pour avoir un aperçu de l’état des rôles Exchange de ce serveur

Le but étant de pouvoir se connecter depuis n’importe où, je vous confirme le support sur iPad et iPhone ;)



Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE.

Publié dans Administration-2010, Exchange 2010 Service Pack 1, Powershell-2010 | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 223 followers