Microsoft Exchange 2010 : Établissement d'un centre de données Exchange 2010 virtuel
Il est recommandé de suivre certaines pratiques lors de la planification et du déploiement d'une infrastructure Exchange virtuelle.
Brien M. Posey
Virtualisation de serveur est devenue la norme, mais la planification de la virtualisation est toujours quelque chose d'une forme d'art. Cela est particulièrement vrai lorsque vous prévoyez de virtualiser Exchange Server. Vous devez déployer Exchange avec la performance et la tolérance de panne à l'esprit. Ajouter le défi, c'est le fait que la plupart des déploiements Exchange Server s'étendent sur plusieurs serveurs.
Il faut noter toutes les recommandations présentées ici sont basées sur la technologie Hyper-V, comme la plate-forme de virtualisation. Ce n'est pas de dire que vous ne pouvez pas utiliser autres plates-formes de virtualisation. L'officiel Microsoft soutien politique dit vous pouvez exécuter Exchange sur « toute tierce partie hyperviseur qui a été validé dans le cadre du programme de Validation Windows Server Virtualization. » À l'heure actuelle, Citrix Systems Inc., VMware Inc. et un certain nombre d'autres fournisseurs de virtualisation participe à ce programme.
La Partition parente
Lors de la planification et le déploiement d'une infrastructure virtuelle d'Exchange Server, il est important d'allouer suffisamment de ressources pour la partition parente (qui va de la gestion des OS). Omettant de réserver des ressources adéquates peut impacter tous vos serveurs virtuels s'exécutant sur un serveur hôte.
Microsoft recommande de réserver au moins 1 Go de mémoire pour la partition parente et la gestion des OS. Si vous exécutez Hyper-V d'une installation complète de Windows Server 2008 ou Windows Server 2008 R2, vous devriez envisager de réserver 2 Go de mémoire pour la gestion des OS pour s'assurer de l'OS jamais s'exécute faible sur les ressources.
Microsoft recommande également dédiant un contrôleur d'interface réseau (NIC) à des fins de gestion. Si vous prévoyez utiliser Migration Live, vous devez consacrer une carte réseau pour le processus de migration live. Il est à noter que Microsoft ne supporte pas la migration live pour le rôle serveur de boîtes aux lettres si le serveur de boîtes aux lettres est membre d'un groupe de base de données de disponibilité (DAG).
Configuration de disque virtuel
Exchange Server et Hyper-V sont assez souple vis-à-vis de provisionnement du stockage. Malgré tout, il y a certaines des pratiques exemplaires recommandées par Microsoft concernant la configuration de stockage pour les serveurs Exchange virtualisés.
Hyper-V crée les disques durs virtuels (VHD) finement configurés par défaut. Cela signifie indépendamment de gros comment vous créez votre VHD, Hyper-V créera initialement un fichier VHD est inférieure à un gigaoctet de taille. Ce fichier VHD étend dynamiquement comme les données sont ajoutées.
Bien que le provisionnement peut aider à réduire la consommation d'espace disque, finement configurés les disques durs virtuels n'exécutent pas ainsi que les disques de longueur fixe. Cela étant, Microsoft recommande que vous utilisez uniquement des disques de longueur fixe pour les serveurs Exchange virtualisés.
La configuration du disque réelle, vous devez utiliser variera selon le rôle de serveur, mais il y a quelques lignes directrices générales qui s'appliquent pour tous les rôles de serveur. Pour commencer, Microsoft recommande de que vous consacrer un disque physique (LUN) à la gestion des OS. Cela assure la gestion QU'OS pas concurrence pour les ressources de disque avec les machines virtuelles (SSN).
Microsoft recommande également de fournir un LUN dédié à l'OS sur chacun de vos serveurs virtuels. Le VHD contenant la système d'exploitation invité doit être assez grand pour stocker le fichier de la page et de Windows Server. La taille de fichier de page est généralement le même que la quantité de mémoire allouée à la machine virtuelle.
Ainsi, la recommandation de Microsoft est de donner le guest OS 15 GB, plus l'équivalent de l'espace à la quantité de mémoire allouée à la machine virtuelle. Par conséquent, un serveur Exchange virtuel avec 4 Go de RAM devrait théoriquement environ 19 Go d'espace disque pour le volume contenant le système d'exploitation.
Avant de commencer réellement allouer des ressources de disque, il y a quelques éléments à considérer. Vous remarquerez que je n'ai pas mentionné l'espace consommée par les fichiers binaires Exchange Server. L'exigence de 15 Go tienne compte de cela. Windows Server 2008 nécessite un minimum de 10 Go d'espace disque. Initialement, l'installation par défaut de Exchange Server multirôle consomme environ environ 2,5 GB d'espace disque (ce qui peut changer comme vous déplacez les choses).
C'est toujours une bonne idée de faire vos volumes de système d'exploitation invité un peu plus gros pour deux raisons. Tout d'abord, la recommandation 15 Go remplit uniquement les exigences minimum de disque du Windows Server 2008. Le exigences système pour Windows Server 2008 spécifiquement recommander 40 Go ou plus. Machines avec plus de 16 Go de RAM nécessitera l'espace disque supplémentaire de pagination, hibernation et vider les fichiers.
Planification à l’avance
Serveurs virtuels sont très souples en termes d'allocation de matériel. Vous pouvez ajouter la mémoire d'un serveur virtuel sur un coup de tête. Cela étant, c'est une bonne idée de commencer avec un plus grand VHD que vous avez vraiment besoin afin de vous pouvez accueillir facilement expansion future de mémoire. Ces recommandations s'appliquent à la VHD contenant la machine invité OS et les binaires Exchange. Microsoft recommande également de créer un ou plusieurs VHD supplémentaire pour le stockage de données.
Par exemple, si vous créez un serveur de transport hub, vous souhaitez créer un VHD secondaire pour accommoder les files d'attente de messages. Pour un serveur de boîtes aux lettres virtuel, vous devez créer deux disques durs virtuels supplémentaires — l'un pour les bases de données de boîtes aux lettres et un pour les fichiers journaux de transactions.
Microsoft ne semble pas mettre l'accent sur le matériel de stockage réelle, sauf à l'égard des serveurs de boîtes aux lettres. Dans ce cas, Microsoft recommande d'utiliser virtual SCSI. La méthode préférée consiste à utiliser la répercussion de la SCSI, mais les disques fixes sont aussi acceptables.
Exchange prend également en charge les stockage iSCSI pour les serveurs de boîtes aux lettres. Si vous choisissez de stockage iSCSI, Microsoft recommande de que vous configurez l'initiateur iSCSI au sein de la direction OS, plutôt que sur les machines de l'invité. Microsoft prend en charge à l'aide de l'initiateur iSCSI dans une machine de l'invité, mais cela élimine donc soutien de trames jumbo. Il en résulte également plus faible rendement que vous obtiendriez si vous avez exécuté l'initiateur iSCSI dans la partition parente.
Lorsque vous définissez l'initiateur iSCSI dans la partition parente, vous pouvez présenter les cibles iSCSI attaché à invité OSes. Ceux qui doivent être configurés pour traiter les cibles iSCSI comme les disques SCSI authentification unique.
Tolérance de pannes
Hyper-V et échange 2010 chaque offrent leur propre faute des mécanismes de tolérance. Hyper-V prend en charge les clusters de basculement basé sur l'hôte. Exchange 2010 offre GCD. Ces solutions tolérant aux deux pannes travaillent de façon complètement différente, il est donc important de choisir la solution tolérant aux pannes qui fonctionne le mieux pour votre organisation.
Si vous n'êtes pas familier avec le GCD, celles-ci sont un mécanisme d'échange 2010 dans lequel vous pouvez combiner jusqu'à 16 serveurs de boîtes aux lettres en un seul groupe. Vous pouvez répliquer bases de données de boîtes aux lettres individuelles à l'un des membres du DAG, offrant ainsi la protection en cas de défaillance.
En revanche, Hyper-V basé sur l'hôte clustering œuvres de relier plusieurs serveurs de Hyper-V à un cluster partage volume. En cas d'une défaillance du serveur hôte, les VMs résidant sur l'hôte défaillant peuvent basculement d'un hôte.
Alors quelle solution tolérant aux pannes devrait utiliser ? La première chose à considérer est le niveau de protection que chacune fournit. GCD offre Native Protection des données Exchange, qui fournit un contrôle de basculement automatique au niveau de la base de données. Comme tel, GCD peut protéger contre les pannes de serveur, de réseau et de base de données.
Hyper-V Host-Based Failover Clustering opère au niveau de l'hôte de virtualisation. Il n'est pas une solution Exchange-aware, donc il ne peut vous protéger contre une défaillance de la base de données. Il ne peut protéger contre un serveur ou une défaillance du réseau. Sa dépendance sur un volume de cluster partagé signifie que, selon les circonstances, le stockage partagé pourrait devenir un point unique de défaillance.
Alors que ces facteurs peuvent favoriser l'utilisation de GCD, il y a des autres considérations. L'une est que GCD ne peut accueillir que des serveurs de boîtes aux lettres — ils n'offrent aucune protection à toute autres rôles serveur Exchange.Ce n'est pas de dire que vous ne peut atteindre un degré de tolérance de pannes du niveau de l'échange pour les autres rôles de serveur. Exchange utilise automatiquement de serveurs de transport hub redondants disponibles. Vous pouvez charger balance un serveur de Transport Edge et accès Client serveur (CAS) à l'aide d'un DNS tour d'installation robin, mais il n'existe pas vraiment une bonne échange-niveau faute tolérante solution pour ces rôles.
Compte tenu de la vulnérabilité des serveurs de non-boîte aux lettres Exchange, votre meilleure option pourrait être double. Créer un DAG pour les serveurs de boîtes aux lettres et utiliser basé sur l'hôte Failover Clustering pour protéger les autres rôles de serveur Exchange. Toutefois, la réalisation de ce type de protection pas aussi simple.
Lorsque vous démarrez virtualiser membres DAG, vous rencontrerez quelques restrictions. D'une part, vous ne peut pas héberger un membre DAG virtualisé sur un serveur Hyper-V est membre d'un Cluster de basculement basé sur l'hôte. Exchange ne vous empêcher de faire cela, mais il n'est pas une configuration prise en charge. En fait, Microsoft déconseille mélange GCD et basé sur l'hôte des Clusters de basculement.
L'autre chose, c'est que vous vraiment ne peut impunément mettre plusieurs membres de DAG sur un serveur hôte unique. Ce faisant minerait complètement la protection que fournit la DAG. Si le serveur hôte devait échouer, chaque serveur de boîtes aux lettres sur l'hôte échouerait aussi. Dans cette configuration, le serveur hôte devient un point unique de défaillance qui pourrait potentiellement forcer tout le DAG hors connexion.
Il n'existe aucune fermes directives de Microsoft au sujet de l'arrangement de la virtualisation des serveurs Exchange pour fournir la meilleure tolérance de pannes, mais il existe plusieurs alternatives. Essayez de créer un Cluster de basculement basé sur l'hôte et l'utiliser pour héberger votre serveur de Transport Edge et les CAS. Si vous devez fournir à ces rôles de serveur d'équilibrage de charge, envisager créant des Clusters de basculement basé sur l'hôte supplémentaires et hébergement d'un serveur de Transport Edge et un CAS dans chacune des grappes. Vous pouvez utiliser une combinaison de DNS round robin et redondants enregistrements MX pour équilibrer la charge entre les serveurs virtuels disponibles.
Vous n'avez peut-être remarqué aucune mention de messagerie unifiée. Droit maintenant, Microsoft ne supporte pas virtualisées Unified Messaging serveurs. Cependant, Exchange 2010 SP2 ajoutera ce soutien.
Vous pouvez aussi envisager de création non cluster de serveurs de Hyper-V. Chacun de ces serveurs non clusterisés doit héberger un serveur de boîtes aux lettres et un serveur de Transport Hub. Faire de chaque serveur de boîtes aux lettres membre DAG et créer au moins deux serveurs de Transport Hub virtualisée pour chaque site Active Directory.
Avec cette configuration, les GCD protégera contre le serveur de boîtes aux lettres ou l'échec de base de données de boîtes aux lettres individuelles. Les serveurs de Transport Hub redondants de niveau transport redondance.
La seule chose qui manque de cette architecture est un serveur de dossiers publics. Pendant un certain temps, Microsoft a été disant que les dossiers publics vont plus loin. Si vous le pouvez, ce serait le moment idéal pour commencer leur élimination progressive. Si vous devez continuer à l'aide de dossiers publics, vous devez comprendre pourquoi un DAG ne peut pas protéger les bases de données de dossiers publics. La seule façon de fournir la tolérance de panne pour les serveurs de dossiers publics est pour répliquer les dossiers publics sur plusieurs serveurs de boîtes aux lettres.
Comme vous pouvez le voir, il y a beaucoup de planification qui va dans la construction d'une infrastructure virtualisée Exchange, avec vos principales considérations étant la tolérance allocation et faute de matériel. Compte tenu de ces facteurs aidera à vous orienter au développement d'une infrastructure solide et fiable.
.jpg)
**Brien M. Posey**est un Microsoft plus précieux professionnel et technique pigiste avec des milliers d'articles et des dizaines de livres à son crédit. Vous pouvez visiter son site Web à brienposey.com.
Contenu associé