Questions-Réponses Exchange Deuxième tour d'horizon sur les fonctionnalités et améliorations dans Exchange 2010

Henrik Walther

Dans cet article, je continuer là où j'ai laissé dans mon dernier article, autrement dit, répondant aux questions davantage aux nouvelles fonctionnalités très intéressantes Exchange 2010. Mais j'ai également place pour quelques questions de Exchange Server 2007.

Q Nous déployez un cluster Exchange 2007 SP1 multisite en utilisant la réplication continue en cluster (CCR). Les nœuds du deux cluster seront situés dans différents centres de données. Exchange s'exécute sur Windows Server 2008 SP2 et nous comptons avoir les interfaces publiques et privées situées dans des sous-réseaux différents dans chaque centre de données. Comme vous le savez, cela signifie que nous doit utiliser le routage entre les nœuds du cluster.

Nous n'avons aucun problème de configuration de l'interface publique conformément aux instructions dans la section CCR de Microsoft TechNet. Mais lorsque nous configurez la passerelle par défaut sur l'interface privée, nous le message Avertissement illustré à la figure 1.

fig01.gif

Figure 1 Spécification de plusieurs passerelles par défaut sur un ordinateur Windows Server 2008.

En fonction de ce message d'avertissement, nous suspectez choses ne fonctionnera pas correctement si nous spécifier plusieurs passerelles par défaut sur chaque nœud dans notre multisite cluster CCR. Ceci nous conduit à notre question : Comment doit nous configurer l'interface réseau privée dans ce type de scénario ?

R Je suis heureux que cette question avant de continuer, car la spécification de plusieurs passerelles par défaut dans un cluster CCR multisite entraîne problèmes majeurs. La configuration correcte nécessite itinéraires persistants, statiques pour chaque interface privée.

Pour commencer, assurez-vous que l'interface publique est répertorié en premier dans la liste ordre de connexion sous Paramètres avancés dans le Panneau de configuration Connexions réseau. Ensuite, vérifiez que vous avez spécifié une passerelle par défaut sur l'interface réseau public pour chaque nœud du cluster.

Enfin, configurer les itinéraires les interfaces privées afin que tout le trafic ne correspond pas à l'itinéraire créé utilisent la passerelle par défaut de l'interface publique. Imaginons que 192.168.100.x/24 sous-réseau avec une passerelle réseau à l'adresse IP 192.168.100.1 est l'interface privée nœud 1. L'interface de réseau privé nœud 2 est sur le sous-réseau 192.168.200.x/24 avec une passerelle réseau à l'adresse IP 192.168.200.1. Dans ce cas, vous devrez créer cet itinéraire sur le nœud 1 : ROUTE ADD 192.168.200.0 masque 255.255.255.0 192.168.100.1 – p, ce qui suit Router sur le nœud 2 : ROUTE ADD 192.168.100.0 MASQUE 255.255.255.0 192.168.200.1 – P.

Le paramètre – p Spécifie que les itinéraires créés sont permanentes et ne sont pas être effacés après un redémarrage.

Cette configuration garantit réseau appropriée pour chaque interface dans les nœuds du cluster. Pour plus d'informations sur comment configurer l'interface privée lors de l'aide de routage entre les réseaux, consultez le blog de par mon ami Tim McMichael.

Sur une note finale, je vous recommande également de que configurer le réseau privé comme un réseau mixte afin que la cmdlet Enable-ContinuousReplicationHostName puisse être utilisée pour diriger les activités de réplication sur le réseau redondant. Pour plus d'informations sur cette applet de commande, consultez How to Enable réseaux du cluster redondants pour l'envoi de journaux et d'amorçage sur Windows Server 2003.

Q J'ai une question concernant la nouvelle fonctionnalité de base de données Availability Group (DAG) dans Exchange Server 2010. Plus précisément, ma question est liée à journal fichier copie et l'amorçage entre les bases de données actifs et passifs. Exchange Server 2010 offrira des modifications ou améliorations de la manière fichier journal de copie et d'amorçage produit avec la réplication continue locale (LCR), réplication continue en cluster (CCR) et réplication continue de secours (SCR) dans Exchange Server 2007 ?

R Qui est une question très. Bien que la technologie de réplication asynchrone utilisé dans Exchange 2007 fonctionne très bien, qui ne signifie qu'il ne peut pas être améliorée, droite ? Je suis heureux de vous informer que le groupe produit Exchange a effectué plusieurs modifications intéressantes et les améliorations apportées à la technologie de réplication asynchrone avec Exchange 2010.

Dans Exchange 2007, le service de réplication de Microsoft Exchange copie les fichiers journaux en copie passive de la base de données (LCR), nœud de cluster passif (CCR) ou cible SCR sur SMB Server Message Block (), ce qui signifie que vous devez ouvrir le port 445 dans n'importe quel pare-feu entre les nœuds de cluster CCR (en général lorsque déploiement CCR multisite clusters) ou source SCR et cibles. Les administrateurs à ouvrir le port 445/TCP entre deux centres de données une extrême ceux d'entre vous qui fonctionnent pour ou avec une grande entreprise connaissent ce persuadant réseau à partir d'un exercice trivial. Avec la fonctionnalité Exchange 2010 DAG, la technologie de réplication asynchrone s'appuie plus sur SMB. Exchange 2010 utilise TCP/IP pour le fichier journal de copie et l'amorçage et mieux encore, fournit la possibilité de spécifier quel port à utiliser pour la réplication du fichier journal. Par défaut, DAG utilise le port 64327, mais vous pouvez spécifier un autre port si nécessaire. Pour ce faire, utilisez la commande suivante :

Set-DatabaseAvailabilityGroup -identity <DAG name> -ReplicationPort <port number>

En outre, la fonctionnalité Exchange 2010 DAG prend en charge l'utilisation du cryptage tandis que les fichiers journaux dans Exchange 2007 sont copiés sur un canal non crypté, sauf si IPsec a été configuré. Plus précisément, DAG exploite les fonctionnalités de cryptage de Windows Server 2008, autrement dit, DAG utilise l'authentification Kerberos entre chaque membre de serveur de boîtes aux lettres de DAG respectif. Cryptage réseau est une propriété de DAG lui-même, et non sur le réseau DAG. Paramètres de propriété de cryptage de DAG réseau sont les suivants : Désactivé (cryptage réseau pas d'utilisation), activé (cryptage réseau activé pour l'amorçage et la réplication sur tous les réseaux existants dans un DAG), InterSubnetOnly (paramètre cryptage réseau signification en cours d'utilisation sur DAG réseaux sur le même sous-réseau par défaut) et SeedOnly (cryptage réseau utilisé pour l'amorçage sur tous les réseaux dans un DAG). Vous pouvez activer cryptage réseau à l'aide la DatabaseAvailabilityGroupcmdlet ensemble. Par exemple, si vous souhaitez activer le cryptage pour journal de copie et l'amorçage, vous devez exécuter la commande :

Set-DatabaseAvailabilityGroup -identity <DAG name> -NetworkEncryption Enabled.

Enfin, avec Exchange 2010 DAGs vous pouvez activer la compression pour l'amorçage et la réplication sur un ou plusieurs réseaux dans un DAG. Ceci est une propriété de DAG lui-même, et non sur un réseau DAG. Le paramètre par défaut est InterSubnetOnly et possède les mêmes paramètres que ceux de la propriété de cryptage réseau. Pour activer la compression réseau pour fichier journal de copie et d'amorçage sur tous les réseaux dans un DAG, utilisez la commande : Jeu DatabaseAvailabilityGroup –Identity < DAG nom >-NetworkCompression activé. Pour connaître l'état du port, paramètres de cryptage et de compression pour un DAG, utilisez la commande –status Get DatabaseAvailabilityGroup comme dans figure 2.

fig02.gif

Figure 2 Database disponibilité groupe réseau cryptage, la compression et la réplication de paramètres de port.

Q Dans votre précédente file d'attente Exchange &Une colonne, vous abordé une réduction significative d'e/S dans Exchange 2010 par rapport à Exchange 2003 et 2007. Pouvez-vous expliquer les modifications spécifiques et les améliorations apportées au groupe produit Exchange pour obtenir une telle optimisation des performances de stockage dans Exchange 2010 ?

R Comme indiqué, nous avons vu une réduction significative en e/S par seconde dans la migration d'Exchange 2003 vers Exchange 2007. Réductions de 70 % ne sont pas rares. Il peut l'attribut principalement à l'utilisation d'une architecture 64 bits pour Exchange 2007. En tant que tel, Exchange 2007 peut accéder à davantage de mémoire et ainsi utiliser caches de mémoire supérieures que son prédécesseur. Les plus de données Exchange peut récupérer directement à partir de l'espace d'adresse mémoire virtuelle, le fewerI/OS nécessaires sur les disques dans le sous-système de stockage sous-jacent.

Cela permet une utilisation beaucoup plus efficace de système de stockage existant (généralement un coûteux Storage Area Network) ou une excuse idéal pour atteindre le moins cher direct-attached storage. Les exigences d'e/S réduites activer l'hébergement de nombreuses plusieurs boîtes aux lettres (5,000-plus) par serveur de boîtes aux lettres Exchange 2007 qu'avec Exchange 2003. Afin d'éviter la fragmentation de mémoire virtuelle, Exchange 2003 était généralement limitée à 4 000 boîtes aux lettres par serveur de boîtes aux lettres. (Oui, je sais ce depended sur type de serveurs, profils utilisateur de stockage et infrastructure Exchange.)

Le moteur ESE (Extensible Storage Engine) est la technologie de base de données dans Exchange depuis la première version, Exchange 4.0, publié en juin 1996. Jusqu'à ce que Exchange 2007 SP1, le groupe produit Exchange efforcé de bon de réglages et optimiser le moteur ESE pour le stockage performance.For mieux dans Exchange 2010, le groupe produit Exchange concentré sur remise importante (+ 10 Go), rapide des boîtes aux lettres tout en tirant profit de stockage bon marché. En raison des modifications de ESE apportées dans cette version, vous avez désormais la possibilité d'utiliser des disques peu performant comme les disques SATA bureau type (c'est-à-dire des disques SATA ou niveau 2). Oui, je suis parler environ 7 200 disques SATA, comme celles de votre station de travail ! Si vous utilisez la fonctionnalité groupe de disponibilité de base de données pour une haute disponibilité (copie de base de données de trois ou plus), vous pouvez même utiliser, par exemple, un disque unique 7200RPM stocker une base de données et les journaux de transaction au lieu de configurations RAID coûteuses.

Réalisation de ces améliorations signifie modifier considérablement le schéma de magasin. En fait, le groupe produit Exchange souhaitait éloigner, de nombreuses e/S aléatoire, petit à moins, séquentiel, e/S grande. Déplacement d'aléatoire vers e/S séquentielles modifications considérables l'architecture de table banque d'informations requises.

Dans Exchange 2007 et les versions antérieur, chaque base de données avait une table de boîte aux lettres (stockée boîtes aux lettres tout dans la base de données), table de dossiers (dossiers de boîte aux lettres stockée pour toutes les boîtes aux lettres dans la base de données), table des messages (messages stockées), table jointe (pièces jointes stockées pour toutes les boîtes aux lettres dans la base de données) et message/dossier table (vues de dossier stockées pour toutes les boîtes aux lettres dans la base de données) .dans cette architecture, qui n'a pas changé beaucoup depuis Exchange 4.0, beaucoup d'e/S aléatoires devait effectuer par rapport à la base de données. Un des avantages avec cette architecture était stockage d'instance unique (SIS) dans lequel une seule copie d'un message a été conservée — un arrière grand avantage lorsque relativement petits disques ont été par pour le cours. Mais aujourd'hui, avec 500 Go SAS et disques SATA de 2 à notre disposition, cette architecture rend plus logique.

Dans Exchange 2010, le magasin de schéma a changé afin que toutes les données dans une boîte aux lettres soient stockées dans tables proche à l'autre de la base de données. En fait, chaque boîte aux lettres possède son propre dossier, en-tête de message corps et afficher la table. Par conséquent, SIS n'existe plus dans Exchange bases de données. En conséquence de la suppression de SIS Exchange, une base de données peut gonflements d'environ 20 pour cent. Pour résoudre ce problème, le groupe produit Exchange compressées les bases de données (plus précisément, les en-têtes de message et texte ou corps HTML). En attribuant à chaque boîte aux lettres de son propre ensemble de tables, les e/S effectuée sur une base de données sont principalement séquentielles.

Autres modifications intéressantes : l'espace de base de données est attribué de manière contiguë ;continuité de la base de données est conservée au fil du temps ;la taille de page de la base de données a été augmentée de 8KBto 32 Ko ;et fonctionnalité de lecture asynchrone a été améliorée. Priorité de cache le Groupis de produit Exchange travaillant également sur l'augmentation l'efficacité du cache en modifiant la profondeur point de contrôle à 100 Mo pour les configurations haute disponibilité, à l'aide de mettre en cache la compression et de la base de données.

Tant que résultat de toutes les modifications dans Exchange 2010, vous pouvez prévoir des 70 pour cent de réduction e/s par rapport à Exchange 2007.

Vous avez uniquement effleurer le lorsqu'il s'agit optimisations de stockage dans Exchange 2010. Si vous souhaitez comprendre très ainsi que les tout gestionnaire détails sur les améliorations stockage dans Exchange 2010, je recommande fortement de vous saisissez une nouvelle tasse de café et regarder l'enregistrement de la session Tech·Ed 2009 sur Exchange 2010 stockage présenté par Matt Gossage, membre de l'équipe groupe produit Exchange responsable de la base de données ESE. Il effectue un grand travail d'expliquer ce sujet complexe Level 300 en clair. Regarder à en ligne (inutile d'avoir assisté à Tech·Ed Visionnez-le).

Q Nous avons plusieurs serveurs de boîtes aux lettres basées sur continu réplication CCR Exchange 2007 cluster déployés au sein de notre organisation. Le réseau privé sur tous les nœuds de fichiers et partage d'imprimantes pour les réseaux Microsoft désactivé (voir la figure 3). Nous sommes que cela a été recommandé lorsque nous avons déployé Exchange 2007.

fig03.gif

Figure 3 Fichier partage et d'imprimantes pour les réseaux Microsoft désactivé.

Mais ceci diffère de l'aide fournie avec documentation Exchange 2007. Maintenant la recommandation consiste à activer le fichier et partage d'imprimantes pour les réseaux Microsoft sur l'interface réseau privé comme il se trouve sur l'interface réseau publique. Pouvez-vous expliquer pourquoi ce guide été modifiée après la publication de Exchange 2007 SP1 ?

R Vous êtes un correct. Avant la version de Exchange Server 2007 SP1, désactiver le fichier partage et d'imprimantes pour les réseaux Microsoft sur l'interface réseau privée a été recommandé. Mais dans Exchange 2007, une nouvelle fonctionnalité vous permet répliquer les fichiers journaux sur plusieurs interfaces réseau, et ainsi rendre les réseaux redondants, plus réduisant la quantité de données via l'interface réseau publique. Dans release to manufacturing (RTM) version d'Exchange 2007, tous les fichiers journaux copie et l'amorçage s'est produite via l'interface réseau publique.

Dans une note associée, si vous utilisez des machines fonctionnant sous Windows Server 2008, assurez-vous qu'Activer NetBIOS sur toutes les interfaces de réseau que vous souhaitez utiliser pour le fichier journal de copie et d'amorçage. Si NetBIOS est désactivé, la commande Activer ContinuousReplicationHostNames échouera.

La cmdlet Enable-ContinuousReplicationHostNames permet de spécifier les interfaces réseau doivent être utilisés pour fichier journal de copie et d'amorçage. Mais n'oubliez pas que vous devez modifier le réseau privé à un réseau mixte dans la console de cluster de basculement Windows afin d'utiliser de fichier journal de copie et l'amorçage.

Voir la rubrique de documentation d'Exchange 2007 pour plus d'informations.

Q Dans Exchange 2007, Microsoft a-t-il une recommandation expliquant comment arrêter mailflow depuis et vers un serveur de boîtes aux lettres Exchange 2007, comme dans le cas d'un virus attaque similaire ? Nous aimerions les utilisateurs pourront se connecter à leurs boîtes aux lettres, mais ne pas pouvoir envoyer et recevoir des messages électroniques dans ces circonstances.

R Pour ce faire, vous pouvez arrêter le service de Transport Microsoft Exchange sur les serveurs de Transport Hub Exchange 2007.

Si vous souhaitez que tous les messages remis sans autoriser de nouveaux messages dans la file d'attente en file d'attente, simplement suspendre le service Transport Microsoft Exchange.

Notez que cette opération au niveau du serveur de boîtes aux lettres nécessite que vous arrêtez le service dépôt du courrier de Microsoft Exchange sur les serveurs de boîtes aux lettres Exchange 2007 impliqués.

Q J'a eu une fermeture, examinez la nouvelle fonctionnalité de boîte aux lettres archive de Exchange Server 2010 et avoir quelques questions. J'ai remarqué que lorsque vous activez la fonctionnalité de boîte aux lettres d'archivage pour une boîte aux lettres d'utilisateur, il est accessible et fonctionne comme prévu via Outlook Web Access 2010 et 2010 Outlook mais pas via Outlook 2003 ou 2007. Nous pourront faire utilisation de la nouvelle fonctionnalité de boîte aux lettres archive avant de nous mettre à niveau vers Outlook 2010 ?

En outre, nous voulons déplacer la boîte aux lettres archive pour un utilisateur respectif vers une autre base de données de boîtes aux lettres. Mais autant que vous le voyez, ce n'est pas possible. Si la boîte aux lettres archive ne peut pas atteindre une autre base de données de boîtes aux lettres, quel est l'avantage de la boîte aux lettres archive ?

R En ce qui concerne à votre première question que vous voyez est le comportement attendu (même si nous atteignions Exchange 2010 RTM). Vous pourrez plus accéder à une boîte aux lettres (ou autre) archive via Outlook Web Access 2010 ou Outlook 2010. Accéder à cette boîte aux lettres via hérité (legacy) Outlook 2003 ou 2007 clients n'est pas pris en charge possible

Pour répondre à votre deuxième question, vous pouvez stocker la boîte aux lettres archive uniquement dans la même base de données boîte aux lettres que celui dans lequel vous avez stocké votre boîte aux lettres principale. Mais comme vous pouvez utiliser niveau 2 disques (c'est-à-dire SATA bureau comme disques) pour vos bases de données de boîtes aux lettres et les journaux dans Exchange 2010, déplacer la boîte aux lettres archive au sous-système de stockage un autre n'est pas vraiment. Qui dit, voici quelques avantages de la fonctionnalité de boîte aux lettres d'archive :

Vous pouvez fournir plus grandes boîtes aux lettres aux utilisateurs finaux sans affecter les performances des dossiers de chemin critique dans la boîte aux lettres principale (boîte aux lettres principale = active des données, boîte aux lettres d'archive = les données à froid) même si les bases de données de boîtes aux lettres sont stockés sur des disques SATA/niveau 2. Vous pouvez fournir grandes boîtes aux lettres (+ 10 Go) sans synchronisation toutes les données vers fichier .ost de l'utilisateur en mode mis en cache (une boîte aux lettres d'archive est accessible uniquement en mode en ligne).

La boîte aux lettres archive est un remplacement pour les fichiers .pst. Comme vous le savez déjà, la boîte aux lettres archive est inaccessible uniquement via Outlook 2010, mais Outlook Web Access 2010. Cela signifie que vous devez plus à vous soucier de sauvegarder vos fichiers .pst et ainsi de suite.

Henrik Walther est un Microsoft Certified Master : Exchange 2007 et MVP Exchange plus de 15 ans d'expérience de l'entreprise informatique. Il travaille comme architecte de technologie pour Trifork Infrastructure Consulting (un partenaire Microsoft Gold Certified Partner basé au Danemark) et comme rédacteur technique pour Biblioso Corp. (une société américaine spécialisée dans managé services documentation et de localisation).