Exporter (0) Imprimer
Développer tout

Conception détaillée et processus de spécification système pour une batterie de serveurs virtuelle SharePoint 2013

 

S’applique à : SharePoint Server 2013, SharePoint Foundation 2013

Dernière rubrique modifiée : 2013-12-18

Résumé : implémentez un processus visant à créer une conception de topologie détaillée et une spécification de configuration requise pour la batterie de serveurs SharePoint 2013 et les ordinateurs hôtes Hyper-V.

Cet article contient un exemple qui vous permet de créer une architecture détaillée et une configuration requise pour une batterie de serveurs SharePoint 2013 virtualisée. Cette architecture comprend les ordinateurs virtuels utilisés pour les rôles serveur de la batterie de serveurs, les ordinateurs physiques éventuellement utilisés comme serveurs de la batterie, ainsi que les ordinateurs hôtes de virtualisation. Votre conception détaillée est le reflet de la dualité d’un environnement virtuel. Elle doit tenir compte des contraintes et des besoins des ordinateurs virtuels, des ordinateurs hôtes de virtualisation, de la gestion réseau et du stockage.

Votre conception détaillée doit répondre à l’ensemble des critères (et attentes) professionnels et techniques de la nouvelle batterie de serveurs SharePoint dans un environnement de production. Une bonne conception tient également compte de la gestion des opérations, des activités de maintenance en cours et des futures mises à niveau.

Contenu de cet article :

Cet article suit les meilleures pratiques communément admises pour décrire les étapes du processus visant à créer une topologie de batterie de serveurs détaillée, une architecture de virtualisation, ainsi que les spécifications système des ordinateurs virtuels et des ordinateurs basés sur la Technologie Hyper-V de Windows Server 2008. Nous vous recommandons d’utiliser l’approche décrite dans la section d’identification des besoins relatifs à la batterie de serveurs virtuelle de la rubrique Créer un plan de virtualisation pour SharePoint 2013. Considérez la topologie et les serveurs de la même manière que la conception d’une batterie de serveurs déployée sur une plateforme physique. Comme les besoins relatifs à SharePoint 2013 ne dépendent pas d’une technologie spécifique, il n’est pas nécessaire de traiter les éléments de virtualisation tant que vous n’avez pas suffisamment d’informations pour étendre la topologie et les spécifications système à la couche virtuelle sous-jacente. Nous vous conseillons également d’utiliser un processus itératif pour créer et affiner votre conception. Cela commence par l’identification des besoins incontournables et importants, par exemple la disponibilité et les performances. Il s’agit d’une technique fréquemment utilisée et éprouvée, qui permet d’obtenir les informations nécessaires pour affiner et mener à bien une conception.

Dans le cadre du processus de conception, vous devez également établir des critères d’évaluation afin de déterminer si la topologie de la batterie de serveurs et les spécifications système sont acceptables pour la première phase de déploiement en pré-production. Cela correspond généralement à une preuve de concept ou un environnement pilote.

RemarqueRemarque :
En ce qui concerne les performances, cet article ne fournit pas d’informations détaillées sur la façon de créer et d’exécuter des tests de référence. Aucune aide relative à l’analyse et l’interprétation des données de référence n’est donnée ici.

Après avoir identifié vos besoins, poursuivez le processus de conception et de spécification en vous basant sur la séquence d’étapes suivante.

  1. Utilisez l’aide relative à l’architecture et à la solution SharePoint 2013 pour créer la topologie la plus adaptée en fonction de la solution que vous souhaitez déployer.

  2. Utilisez le projet de conception de topologie pour déterminer le nombre de serveurs nécessaires dans la batterie, ainsi que pour documenter la configuration minimale requise pour chaque serveur en fonction de son rôle. N’oubliez pas qu’il s’agit d’un point de départ. Il ne s’agit pas de la conception finale de la batterie de serveurs, ni de la spécification définitive de sa configuration.

  3. Étendez la topologie de votre batterie de serveurs afin d’inclure l’infrastructure de virtualisation. N’oubliez pas de recourir aux publications d’aide disponibles pour déterminer la répartition optimale des rôles serveur de la batterie de serveurs sur plusieurs ordinateurs hôtes de virtualisation. Dans le cadre de cette étape, évaluez les ressources dont chaque ordinateur hôte a besoin pour prendre en charge les ordinateurs virtuels que vous envisagez de déployer sur l’hôte.

    RemarqueRemarque :
    L’architecture doit refléter les fonctionnalités et les limites des ordinateurs hôtes de virtualisation.
  4. Continuez à affiner la topologie jusqu’à ce que vous disposiez d’une conception qui permette de déployer une batterie de serveurs de test dans un environnement de pré-production. Pendant que vous affinez la topologie, vous pouvez ajuster les spécifications système si vous obtenez des informations supplémentaires sur la configuration requise pour les ordinateurs virtuels de la batterie de serveurs ou les ordinateurs hôtes. À moins que vous ne disposiez de données de référence provenant d’un déploiement précédent, les spécifications système ne sont qu’une évaluation. En effet, ce sont vos tests de référence qui permettront d’effectuer des ajustements significatifs.

Le processus et les conseils indiqués dans cet article se concentrent sur l’installation et la configuration des Produits SharePoint à l’aide d’une solution basée sur une Technologie Hyper-V de Windows Server 2008. Toutefois, vous pouvez appliquer notre stratégie à toutes les solutions de virtualisation validées par le programme SVVP (Server Virtualization Validation Program). Pour plus d’informations, voir le FAQ du programme SVVP (Server Virtualization Validation Program).

Cet article ne fournit pas d’informations détaillées sur la façon d’installer et de configurer un ordinateur hôte de virtualisation, ni sur les ordinateurs virtuels nécessaires pour une batterie de serveurs à base de Produits SharePoint. Pour plus d’informations, voir Utiliser des configurations recommandées pour les ordinateurs virtuels SharePoint 2013 et l’environnement Hyper-V.

RemarqueRemarque :
Pour cette version de SharePoint 2013, les modifications et les fonctionnalités relatives à la virtualisation dans Windows Server 2012 ne sont pas prises en charge.

Les sujets suivants sont abordés à des degrés divers dans cet article. Toutefois, les informations détaillées relatives à chaque sujet sont fournies dans des articles distincts.

  • Continuité des activités - Haute disponibilité et récupération d’urgence pour un environnement virtuel

  • Sécurité - Meilleures pratiques pour la sécurisation d’ordinateurs hôtes de virtualisation Hyper-V

  • Performances et capacité

  • Maintenance et opérations

Le point de départ de la création d’une conception détaillée consiste à établir, vérifier et hiérarchiser les besoins fonctionnels, techniques et opérationnels de SharePoint 2013 et de l’infrastructure de virtualisation appropriée. Vous devez établir des priorités, car il existe des priorités concurrentes en fonction des parties prenantes. Il existe également des écarts importants entre les besoins (les attentes, en fait) des différentes unités d’organisation. Par exemple, les utilisateurs s’attendent toujours à un temps de réponse rapide alors que le groupe de sécurité informatique nécessite une conception qui réduit le risque d’intrusion dans le système.

Quand vous vous concentrez sur le processus pour identifier et hiérarchiser les besoins, vous devez également élaborer des critères de notation afin de déterminer si la conception est appropriée pour le déploiement d’une batterie de serveurs dans un environnement de pré-production.

Il existe de nombreuses approches et de nombreux outils que vous pouvez utiliser pour hiérarchiser vos besoins. Il n’y a pas de meilleure méthode ou de méthode recommandée pour un scénario donné. Par exemple, une approche répandue consiste à catégoriser les besoins incontournables, très importants, etc. Une autre approche consiste à utiliser un système de pondération ou d’échelle de classement pour établir des priorités. Quelle que soit la méthode, choisissez une approche qui vous permet d’établir des priorités crédibles et appliquez-la invariablement quand vous identifiez et affinez vos besoins.

Nous vous conseillons de regrouper vos besoins en catégories générales, puis de diviser chaque catégorie afin de détailler les besoins spécifiques. Par exemple, la sécurité est une catégorie générale : il est très important de disposer d’informations détaillées sur les niveaux d’autorisation nécessaires aux utilisateurs ou aux personnes autorisées à accéder aux fonctionnalités de la batterie de serveurs ou des composants pour comprendre, concevoir et implémenter correctement un système sécurisé.

RemarqueRemarque :
La catégorisation des besoins vous permet de mieux vous concentrer sur les détails pertinents et vous aide à réduire les risques d’oubli. Toutefois, les catégories ne sont pas isolées. Il existe toujours des chevauchements ou des dépendances. Vous devez avoir une approche de conception globale qui reconnaît et intègre ces chevauchements et ces dépendances clés.

Contenu de cet article, nous utilisons quatre grandes catégories pour regrouper les besoins en matière de conception. Ces catégories sont les suivantes par ordre de priorité :

  • Haute disponibilité

  • Sécurité

  • Performances

  • Capacité

RemarqueRemarque :
Nous reconnaissons qu’il existe une interdépendance entre les performances et la capacité, mais nous avons décidé de séparer ces deux catégories pour des raisons de commodité de lecture.

La première étape de conception en matière de haute disponibilité consiste à déterminer le niveau de disponibilité de SharePoint nécessaire à votre organisation dans son domaine d’activité. En règle générale, les besoins de haute disponibilité d’une organisation sont définis par le type d’activité, le degré de globalisation, les clients et les partenaires. D’un point de vue interne, vous devez documenter le niveau de disponibilité nécessaire à l’ensemble de l’organisation et ses divisions.

RemarqueRemarque :
La haute disponibilité et la récupération d’urgence sont des sous-ensembles d’une stratégie et d’un processus de gestion de la continuité des opérations. Cet article se concentre sur les éléments de conception immédiats qui sont nécessaires à la mise en production d’une batterie de serveurs. Les besoins en matière de récupération d’urgence sont très importants. Ils ne doivent pas être ignorés durant le processus de conception de l’architecture. Nous avons décidé de traiter la récupération d’urgence comme une activité distincte, postérieure au déploiement, afin de détailler davantage les besoins relatifs à la récupération d’urgence, les meilleures pratiques et les options possibles.

Les prochaines étapes consistent à évaluer tous les composants de la batterie de serveurs afin de déterminer leur effet potentiel sur la disponibilité, examiner les options spécifiques aux composants à haute disponibilité, puis choisir la meilleure option pour votre architecture.

RemarqueRemarque :
Les coûts sont toujours un facteur important pour les organisations. Cependant, vous devez comparer ces coûts à l’effet potentiel d’une réduction de disponibilité dans votre entreprise.

Nous conseillons, au minimum, d’évaluer les composants de batterie de serveurs suivants dans une perspective de haute disponibilité :

  • bases de données SharePoint ;

  • serveurs d’applications ;

  • serveurs web frontaux ;

  • services et fonctionnalités SharePoint tels que la recherche ;

  • ordinateurs virtuels utilisés pour la batterie de serveurs ;

  • répartition des rôles serveur de la batterie de serveurs sur les ordinateurs hôtes de virtualisation ;

  • ordinateurs hôtes de virtualisation ;

  • éléments d’infrastructure tels que les routeurs et les systèmes d’équilibrage de charge d’alimentation.

La virtualisation introduit une autre couche de sécurité qui doit être prise en compte. L’ordinateur hôte de virtualisation fournit un point d’accès unique aux ordinateurs virtuels qu’il héberge, ce qui augmente l’exposition aux attaques. En outre, la gestion du réseau virtuel présente des défis supplémentaires pour la sécurisation du réseau de la batterie de serveurs.

Votre organisation dispose déjà de stratégies, de procédures et d’outils pour gérer la sécurité et l’authentification des systèmes informatiques et leur infrastructure. Vous devez sécuriser votre serveur de virtualisation à l’aide des mesures que vous prendriez pour protéger un serveur qui exécute Windows Server 2008 ou Windows Server 2008 R2. Vous devez également mettre en œuvre des mesures supplémentaires pour contribuer à sécuriser les ordinateurs virtuels, les fichiers de configuration et les données. Pour plus d’informations sur la sécurisation des charges de travail Windows Server 2008, voir le guide de sécurité de Windows Server 2008.

SharePoint 2013 fournit des fonctionnalités nouvelles, repensées et étendues. Ainsi, les besoins en matière de performances des serveurs de la batterie et les besoins spécifiques aux ressources ne sont pas les mêmes que pour les Produits SharePoint 2010. Il est nécessaire de voir en profondeur quelles sont les modifications apportées à SharePoint 2013 pour identifier clairement les besoins en ressources de chaque serveur de la batterie. La perception des effets de ces modifications est particulièrement importante dans un scénario où vous avez l’intention de baser les spécifications système de la batterie de serveurs sur des données historiques : profils d’utilisation ou données de performances. Pour plus d’informations sur les performances, voir Planifier la gestion des performances et de la capacité dans SharePoint Server 2013.

Données d’utilisation

Les données d’utilisation historiques vous aident à établir plus facilement des paramètres de test que vous pouvez utiliser pour des tests de référence. Toutefois, quand vous évaluez ces données, faites-le dans le contexte des nouvelles fonctionnalités de SharePoint 2013. Déterminez de quelle façon ces fonctionnalités peuvent affecter les modèles de comportement des utilisateurs. Par exemple :

  • En règle générale, quand des améliorations sont apportées à une fonctionnalité existante, celle-ci est employée plus souvent par un plus grand nombre d’utilisateurs et sur de plus longues périodes.

  • Les fonctionnalités nouvelles ou étendues ont le même effet que les fonctionnalités améliorées, notamment quand elles répondent à l’absence de fonctionnalités très demandées ; cela se traduit par une augmentation importante de l’utilisation de SharePoint.

  • Une augmentation significative du nombre d’utilisateurs, à la suite d’une fusion ou d’une acquisition par exemple, affecte également le profil d’utilisation.

Les changements de modes d’utilisation, par exemple les variations du nombre de connexions simultanées ou du temps de connexion moyen, peuvent avoir un effet significatif sur les besoins globaux du système.

Données de performances

Les données de performances permettent de mesurer la façon dont un serveur gère la charge de travail SharePoint en fonction de son rôle. Elles permettent également d’évaluer les ressources informatiques utilisées (UC ou mémoire) pendant que le système effectue ses tâches. (Vous pouvez également utiliser le débit global d’un groupe de serveurs de batterie comme une mesure de performance supplémentaire.) Pour permettre l’obtention de performances optimales, les ressources informatiques disponibles doivent être suffisantes pour gérer la charge de travail. Les spécifications système, à l’exclusion des logiciels prérequis, doivent identifier la configuration de chaque serveur afin de gérer la charge attendue pour le rôle serveur. La configuration finale est le résultat des tests itératifs (tests de référence ou benchmarks) qui collectent les données de performances quand des tâches prédéterminées sont effectuées selon différentes charges. Les testeurs de votre équipe projet comparent les données des tests aux informations de référence afin d’évaluer l’effet de la charge et des tâches sur les performances. Si des données historiques sont disponibles, il est plus facile de créer les données de référence des tests de performances.

ImportantImportant :
Assurez-vous que les performances de toutes les fonctionnalités repensées ou mises à jour sont testées minutieusement et que leurs effets sur les performances globales du système sont clairement identifiés. Certaines de ces fonctionnalités n’augmentent pas forcément de manière significative ou visible les besoins en matière de performances. Toutefois, la charge imposée par une fonctionnalité peut être déplacée vers un autre rôle serveur de la batterie de serveurs. Toutes les hypothèses dont vous disposez pour un rôle particulier doivent être validées par de nouveaux tests de référence.

Si la batterie de serveurs SharePoint est le premier déploiement de votre organisation, vous ne pouvez pas recourir à des données historiques comme point de référence en matière de performances. Vous devez créer une référence à partir des conseils et limites indiqués pour SharePoint 2013. Quelle que soit la façon dont vous établissez votre référence, vous devez exécuter différents tests de référence pour collecter des données spécifiques afin d’affiner votre conception de l’architecture et vos spécifications système.

ImportantImportant :
Les tests et les analyses de performances pour chaque rôle serveur doivent être combinés afin de créer un profil de performances pour l’ensemble des performances de la batterie de serveurs. Cela rend plus facile l’identification des goulots d’étranglement en matière de performances dans la batterie de serveurs.

Une fois que vous avez déterminé les besoins en capacité d’une batterie de serveurs SharePoint 2013, la prochaine étape concerne le dimensionnement de la batterie de serveurs, de ses serveurs et de l’infrastructure de virtualisation. Les deux principaux domaines sur lesquels se concentrent les architectes de batteries de serveurs sont le stockage de contenu et les performances. Pour plus d’informations sur la capacité, voir Gestion et dimensionnement de la capacité pour SharePoint Server 2013.

SharePoint 2013 est connu pour sa capacité à gérer divers types de contenu, lesquels vont des simples fichiers texte aux fichiers multimédias volumineux. Cette capacité comprend, de manière non exhaustive, la création et l’édition de contenu, le partage collaboratif, le stockage à court et à long terme, ainsi que l’archivage. Du point de vue de la taille, votre conception doit être suffisante pour gérer les besoins à court terme. Au fur et à mesure de l’accroissement de la base de données de contenu, vous pouvez étendre la batterie de serveurs afin de répondre à cette croissance.

La capacité d’une batterie de serveurs à atteindre ou dépasser régulièrement le niveau de performances requis est le deuxième aspect important. La capacité est généralement définie et évaluée comme le type de charge placé sur les serveurs de la batterie par rapport à un ensemble prédéfini de seuils. Les seuils sont des limites configurables utilisées pour définir les charges acceptables, ainsi que les charges qui affectent l’intégrité de la batterie de serveurs en cas de dépassement d’une limite. Pour plus d’informations, voir Limitations et frontières logicielles pour SharePoint 2013.

RemarqueRemarque :
En règle générale, la capacité inclut également des mesures de diffusion du contenu, par exemple le temps de chargement des pages.

La capacité de la batterie de serveurs est déterminée par la taille de cette dernière, en fonction de la ou des solutions prises en charge et des caractéristiques de nombreux composants de la batterie de serveurs. Voici quelques exemples non exhaustifs de ces composants : serveurs de la batterie de serveurs, bande passante et latence réseau, conception des pages, code personnalisé, etc.

Comme pour les performances, votre stratégie de planification de capacité varie selon que la batterie de serveurs représente ou non le premier déploiement de SharePoint 2013 pour votre organisation.

Une architecture bien définie pour une batterie de serveurs virtuelle (englobant la couche matérielle) comprend les ordinateurs hôtes de virtualisation, l’infrastructure réseau, le système de stockage, ainsi que les ordinateurs virtuels qui font partie de l’environnement SharePoint 2013. (Une conception d’architecture hétérogène comprend les serveurs physiques de la batterie de serveurs.) Utilisez l’illustration de conception que nous vous proposons comme repère pour définir votre propre processus et vos propres critères lors de la création d’une architecture détaillée et des spécifications système. Adaptez votre approche en fonction des besoins de votre organisation et des besoins de la solution à base de Produits SharePoint que vous envisagez de déployer dans un environnement virtuel.

Notre stratégie de conception utilise la modélisation et l’itération pour parvenir à une architecture de batterie de serveurs virtuelle et des spécifications système destinés à des tests grandeur nature.

La modélisation est un outil de visualisation très utile qui vous permet de voir tous les composants d’un déploiement de batterie de serveurs à base de Produits SharePoint pour votre solution. Si le modèle inclut des spécifications système, cela vous permet également de vérifier que toutes les spécifications requises sont identifiées et documentées. Dans la mesure où le modèle est un document de taille réduite, il est facile de le transmettre aux parties prenantes, qui peuvent ainsi l’examiner et le commenter.

C’est à vous de décider de la quantité de détails à utiliser dans un modèle. Le modèle que nous utilisons pour illustrer le processus de conception comprend les serveurs de la batterie de serveurs, les composants de Produits SharePoint installés et configurés sur chaque serveur, ainsi que les spécifications système de chaque serveur. Nous avons décidé de ne pas inclure les flux de travail des Produits SharePoint, ni l’infrastructure réseau, afin de conserver un modèle aussi simple et utile que possible.

La conception itérative est une approche répandue et éprouvée en matière de conception d’applications et de systèmes. La conception itérative offre plusieurs avantages, dont voici quelques exemples :

  • Elle vous permet d’identifier les informations manquantes ou incorrectes.

  • Elle facilite l’identification des éléments de conception ou des spécifications système discutables qui nécessitent un examen plus approfondi.

La liste de tâches suivantes décrit les étapes clés pour créer, configurer et déployer une batterie de serveurs virtuelle avec l’infrastructure de prise en charge :

  1. Créez un modèle d’architecture et des spécifications système pour une batterie de serveurs déployée sur des serveurs physiques.

  2. Utilisez l’architecture physique et les spécifications système comme modèle pour créer l’architecture de batterie de serveurs virtuelle préliminaire et la plateforme physique de prise en charge nécessaire.

    ConseilConseil :
    Recueillez des informations techniques de référence détaillées (par exemple des livres blancs techniques et des articles de base de connaissances) pour SharePoint 2013, SQL Server et Hyper-V. Utilisez ces informations pour créer une base de connaissances techniques dont vous pouvez vous servir comme outil de conception. Cette base de connaissances est très utile lors des tests de pré-production quand l’équipe de test doit déterminer la meilleure façon de résoudre un problème de performances et identifier la meilleure solution.
  3. Ajoutez les ordinateurs hôtes de virtualisation et leurs spécifications système au modèle.

  4. Démarrez le processus de conception itérative. Analysez le modèle d’architecture pour vérifier s’il identifie tous les éléments nécessaires à la solution de batterie de serveurs. Testez de manière raisonnable les spécifications système de chaque serveur de la batterie de serveurs. Identifiez et obtenez les informations manquantes ou incomplètes afin de pouvoir les utiliser pour ajuster la conception ou les spécifications de la batterie de serveurs.

  5. Affinez l’architecture en fonction des résultats de votre analyse et en incorporant les informations nouvelles ou mises à jour.

  6. Démarrez une autre boucle itérative : examen, révision, examen. Continuez à évaluer et affiner l’architecture, ainsi que les spécifications, jusqu’à ce que tous les aspects de la batterie de serveurs virtuelle répondent à vos critères afin de déployer et tester la batterie de serveurs dans un environnement de pré-production tel qu’un environnement de preuve de concept ou un environnement pilote limité.

  7. Déployez la batterie de serveurs.

Créez un modèle de l’architecture physique, soit à l’aide de données historiques (si elles sont disponibles), soit à partir des besoins et conseils relatifs à SharePoint 2013. Si vous utilisez des données historiques, nous vous conseillons de les compléter par les besoins et conseils (nouveaux ou mis à jour) relatifs à SharePoint afin que votre conception couvre toutes les fonctionnalités nouvelles ou mises à jour.

ImportantImportant :
Nous vous recommandons de consacrer autant de temps et de faire preuve d’autant de rigueur que pour l’installation et la configuration de Produits SharePoint sur des serveurs physiques. Ces efforts se révèlent payants quand vous adaptez la conception physique et les spécifications système à un environnement virtuel. Cela vous permet également d’éviter les modifications inutiles en matière de topologie et de dimensionnement pour les ordinateurs virtuels et les ordinateurs hôtes de virtualisation.

Une fois que vous êtes convaincu que ce modèle est solide et qu’il répond de manière appropriée aux besoins de la nouvelle batterie de serveurs, vous pouvez mapper l’aspect physique à un environnement virtuel.

Notre exemple de batterie de serveurs

Afin d’illustrer le processus de création et d’affinement de la conception et des spécifications système d’une batterie de serveurs, nous avons recours à une batterie de serveurs de petite/moyenne taille configurée pour utiliser le service de recherche. Par souci de clarté, nous n’avons pas inclus d’autres applications de service à prendre en compte dans votre conception.

La figure suivante illustre notre exemple de batterie de serveurs déployée sur des ordinateurs physiques. Il s’agit de notre point de départ pour l’élaboration d’une architecture de batterie de serveurs virtuelle et la définition de spécifications système adaptées à un déploiement de batterie de serveurs de type preuve de concept ou pilote.

Figure 1. Batterie de serveurs de petite/moyenne taille déployée sur des ordinateurs physiques

Architecture pour la batterie de serveurs sur les serveurs physiques
RemarqueRemarque :
Les étiquettes numérotées (1X - 6X) dans la figure 1 identifient les composants de batterie de serveurs ou les configurations de serveurs qui doivent faire l’objet d’un examen approfondi.

Servez-vous de la conception topologique et des spécifications système de la batterie de serveurs physique pour modéliser l’environnement virtuel, qui comprend les ordinateurs hôtes Hyper-V.

RemarqueRemarque :
Veillez à ce que les fonctionnalités et les limites potentielles des ordinateurs hôtes de virtualisation soient bien comprises et incluses dans votre plan de conception.

Appuyez-vous sur la séquence de tâches suivantes pour développer votre modèle virtuel :

  1. Procédez à un examen final du modèle physique et des spécifications système pour vous assurer que vous fondez le modèle virtuel sur une conception et un dimensionnement fiables.

    Avant de transférer les spécifications du modèle physique, notez les configurations qui se démarquent pour pouvoir contrôler les besoins de SharePoint 2013 et vérifier les configurations (exactitude des informations, par exemple). À partir de notre exemple, notez les points suivants :

    1. Chacun des serveurs web frontaux (FE-1, FE-2) est configuré pour utiliser 24 Go de mémoire RAM. Au premier abord, cette configuration de la mémoire semble élevée, surtout si on la compare aux serveurs d’applications qui hébergent les composants de recherche.

    2. Deux des serveurs d’applications (SA-1 et SA-2) sont dédiés à l’hébergement des composants de recherche. La configuration de la mémoire RAM semble raisonnable. Toutefois, la capacité du disque dur pour l’index risque de ne pas être suffisante.

    3. Le troisième serveur d’applications (AP-1) héberge les composants de recherche restants en plus des autres rôles d’application pour la batterie de serveurs. Il n’existe aucun approvisionnement pour la haute disponibilité.

    4. Le serveur d’applications AP-1 dispose de suffisamment de mémoire. Toutefois, la capacité du disque dur risque d’être insuffisante.

    5. Les serveurs de bases de données (SQ-1 et SQ-2) manquent d’informations sur les besoins des disques durs et la configuration de la mémoire semble trop faible.

    6. Il existe un besoin en bases de données à haute disponibilité. Toutefois, aucune information spécifique à la solution à haute disponibilité n’est fournie.

  2. Identifiez le nombre d’ordinateurs virtuels nécessaires et définissez le rôle de chaque ordinateur virtuel pour le serveur correspondant dans le modèle physique.

  3. Utilisez les spécifications du serveur physique pour documenter la configuration de chaque ordinateur virtuel (nombre de processeurs, quantité de mémoire et espace disque). Pendant que vous transférez les spécifications du modèle physique, notez les configurations qui se démarquent pour pouvoir contrôler les besoins de SharePoint 2013 et vérifier les configurations discutables.

    RemarqueRemarque :
    N’oubliez pas de contrôler les besoins de SQL Server pendant que vous vérifiez les spécifications des serveurs de la batterie de serveurs SharePoint 2013.
  4. Déterminez la répartition des ordinateurs virtuels sur les ordinateurs hôtes. Tenez compte des facteurs suivants quand vous déterminez la répartition des ordinateurs virtuels sur les ordinateurs hôtes : besoins en disponibilité de la batterie de serveurs, recommandations de répartition des rôles pour des performances optimales, nombre minimal d’ordinateurs hôtes et capacité de l’hôte (si elle est connue).

  5. Examinez la répartition des services de batterie de serveurs parmi les ordinateurs hôtes de virtualisation pour déterminer si l’un de ces services présente un risque en cas de défaillance de l’ordinateur hôte.

  6. À partir des besoins en termes de capacité de l’ordinateur virtuel, déterminez les spécifications système minimales de l’ordinateur hôte (nombre de cœurs, mémoire, disques durs locaux ou stockage réseau).

    RemarqueRemarque :
    Utilisez les configurations recommandées pour les ordinateurs virtuels et les ordinateurs hôtes de virtualisation. Pour plus d’informations, voir Utiliser des configurations recommandées pour les ordinateurs virtuels SharePoint 2013 et l’environnement Hyper-V.
  7. Identifiez les besoins généraux en matière de gestion réseau, de stockage et d’alimentation, en tenant compte des objectifs de conception suivants : disponibilité, performances et capacité.

    Comme nous l’avons indiqué dans la section « Choisir une stratégie de conception et identifier les tâches principales », nous faisons en sorte de conserver un modèle aussi simple que possible. Ainsi, les besoins en matière de gestion réseau et de stockage ne sont pas traités.

  8. Examinez l’architecture et les spécifications système, puis identifiez les ressources non validées sur chacun des ordinateurs hôtes Hyper-V. L’extension de capacité des ordinateurs hôtes détermine la limite de montée en puissance par unité des ordinateurs virtuels sur un ordinateur hôte, ou la limite de montée en charge de la batterie de serveurs via l’ajout d’un ordinateur virtuel à un ordinateur hôte.

Une fois que vous avez terminé la première version du modèle de l’architecture virtuelle et des spécifications système, nous vous recommandons de démarrer le processus itératif afin d’affiner l’architecture et les spécifications système. L’objectif est de valider les besoins en matière de conception, ainsi que les hypothèses utilisées. Ce processus vous permet également d’examiner les besoins fonctionnels (pour la solution et la batterie de serveurs) afin de vérifier qu’il n’y a pas de modifications à prendre en considération avant d’affiner le modèle. Enfin, s’il existe de nouvelles données de référence ou des mises à jour de spécifications du produit, vous pouvez incorporer ces informations dans un modèle révisé.

Durant le processus d’analyse de l’architecture et des spécifications système de la batterie de serveurs SharePoint 2013, n’oubliez pas que la topologie de la batterie de serveurs et les configurations des serveurs changent avant et, dans une certaine mesure, après le déploiement de la batterie de serveurs dans l’environnement de production. L’étendue et le degré des modifications varient en fonction de la solution. Toutefois, tenez compte du fait qu’il y a des changements et que cela doit faire partie de votre stratégie d’analyse de la conception.

L’illustration suivante montre la première version de notre architecture virtuelle basée sur la topologie et les spécifications système créées pour la batterie de serveurs physique. Le même nombre de serveurs de batterie de serveurs sont implémentés en tant qu’ordinateurs virtuels et se voient attribuer les mêmes rôles que les serveurs physiques. Les ordinateurs virtuels sont répartis sur deux serveurs hôtes Hyper-V. Au minimum, deux hôtes Hyper-V sont nécessaires pour correspondre à la conception de haute disponibilité utilisée dans le modèle physique.

ImportantImportant :
Les spécifications système des ordinateurs virtuels et des ordinateurs hôtes Hyper-V figurant dans le schéma suivant sont données à titre indicatif. Elles ne sont pas normatives.
Les ordinateurs virtuels sont configurés en fonction des besoins minimaux de chaque rôle serveur, comme indiqué dans l’article Configuration matérielle et logicielle requise pour SharePoint 2013.

Figure 2. Topologie de batterie de serveurs virtuelle avec deux ordinateurs hôtes Hyper-V

Architecture initiale pour batterie de serveurs virtualisée
RemarqueRemarque :
Les étiquettes numérotées (1X - 5X) dans la figure 2 identifient les composants de batterie de serveurs ou les configurations de serveurs qui doivent faire l’objet d’un examen approfondi.

Dans le présent article, notre approche en matière d’examen de la conception se compose de trois phases (ou catégories), ce qui fournit une structure de base pour la conception. Appuyez-vous sur les étapes suivantes pour élaborer votre propre processus d’examen de la conception.

  1. Procédez à un examen de la conception de l’architecture de la batterie de serveurs virtuelle et de la plateforme physique de prise en charge.

  2. Analysez les spécifications système des ordinateurs virtuels et des ordinateurs hôtes de virtualisation.

  3. Examinez l’architecture et les spécifications système sous forme d’une seule entité.

    RemarqueRemarque :
    Subdivisez les principales étapes ou catégories de l’examen afin d’obtenir le niveau de détail nécessaire pour affiner l’architecture ou les spécifications système.

Évaluation de la conception des architectures virtuelle et physique

L’architecture virtuelle implémente la stratégie de disponibilité des rôles serveur spécifiques de la batterie de serveurs sous forme de modèle physique. La redondance du serveur web frontal est conservée, ainsi que les besoins en haute disponibilité des bases de données. La disponibilité est également conservée pour les deux serveurs d’applications (SA-1, SA-2) qui hébergent les composants d’index de recherche et de requêtes de recherche.

RemarqueRemarque :
Bien que l’architecture virtuelle conserve la disponibilité de l’architecture physique, elle n’améliore pas cette disponibilité. Cela doit faire partie d’une stratégie de virtualisation.

La décision d’utiliser deux ordinateurs hôtes et de répartir les rôles serveur de la batterie de serveurs entre ces hôtes a deux conséquences. Tout d’abord, cela permet de s’assurer que la plupart des serveurs de la batterie de serveurs ne sont pas vulnérables en un point de défaillance unique. Deuxièmement, la répartition des rôles permet de répartir également la charge de travail, ce qui contribue à l’obtention de meilleures performances globales pour la batterie de serveurs.

Défauts de conception

Les aspects suivants de la conception doivent être traités :

  • Le niveau de redondance des serveurs frontaux est adapté aux environnements de pré-production mais doit être réévalué avant la mise en production de la batterie de serveurs. La perte d’un serveur web frontal réduit de 50 % la capacité de la batterie de serveurs à fournir du contenu. Il n’existe aucune option de haute disponibilité pour les ordinateurs hôtes de virtualisation. En cas de défaillance sur HÔTE-2, la batterie de serveurs peut continuer à fonctionner. Cependant, cela n’est pas le cas si HÔTE-1 rencontre une défaillance.

  • Aucune haute disponibilité n’est fournie pour l’ensemble des serveurs d’applications. Les composants d’administration de la recherche et d’analyse de la recherche sur AP-1 sont vulnérables, car les deux instances s’exécutent sur le même hôte Hyper-V.

  • Il n’existe aucune option de haute disponibilité pour les ordinateurs hôtes de virtualisation. En cas d’échec sur Hôte-2, la batterie de serveurs continue de fonctionner sans perte de services. Toutefois, si Hôte-1 tombe en panne, les services clés tels que l’analyse du contenu ou le traitement de l’analyse ne sont pas disponibles.

Analyse des spécifications système des ordinateurs virtuels

Les spécifications système des ordinateurs virtuels sont basées sur les configurations des serveurs du modèle physique. Après avoir examiné ces spécifications, nous constatons que deux configurations ne répondent pas à nos critères de test raisonnables. Des informations supplémentaires sont requises pour les serveurs suivants :

  • Serveurs web frontaux. Après une nouvelle vérification des besoins de SharePoint 2013, nous avons réduit la configuration de la mémoire à 8 Go, ce qui est le minimum recommandé pour un système fournisseur de contenu. Un autre aspect de la configuration des serveurs web concerne le nombre de processeurs virtuels (nous devons nous assurer que ces serveurs nécessitent quatre processeurs virtuels).

  • Serveurs de bases de données. La spécification de mémoire semble faible pour ces serveurs. Cependant, le modèle ne fournit aucune information sur le volume des transactions ou les types de transaction de base de données attendus.

  • Le stockage est un autre domaine qui nécessite un examen plus approfondi. Pour les serveurs de bases de données, les seules informations nécessaires concernent le disque système. Il n’y a aucune information sur les besoins en capacité des autres disques durs de base de données.

Analyse des spécifications système des ordinateurs hôtes Hyper-V

Le tableau suivant (Spécifications système des ordinateurs hôtes Hyper-V (Hôte-1 et Hôte-2)) présente une analyse des performances des ordinateurs hôtes de virtualisation basée sur des critères tels que la mémoire, la configuration du processeur et l’extensibilité.

Spécifications système des ordinateurs hôtes Hyper-V (Hôte-1 et Hôte-2)

Spécifications Analyse

Mémoire

Hôte-1 : 96 Go de mémoire RAM

Le besoin total en mémoire est de 68 Go (4 Go sont alloués pour la charge de traitement et 64 Go sont alloués pour les ordinateurs virtuels), ce qui laisse 28 Go de mémoire RAM disponible pour la montée en puissance par unité des ordinateurs virtuels ou la montée en charge de la batterie de serveurs.

RemarqueRemarque :
L’allocation de mémoire pour la charge de traitement d’un ordinateur hôte de virtualisation Hyper-V est généralement estimée à 2 Go. Cependant, pour un environnement virtualisé à base de Produits SharePoint, nous vous recommandons d’utiliser 4 Go pour la charge de traitement lors du calcul des besoins en mémoire.

Hôte-2 : 96 Go de mémoire RAM

Le besoin total en mémoire est de 48 Go (4 Go sont alloués pour la charge de traitement et 44 Go sont alloués pour les ordinateurs virtuels), ce qui laisse 48 Go de mémoire RAM disponible pour la montée en puissance par unité des ordinateurs virtuels ou la montée en charge de la batterie de serveurs.

Processeurs

Le ratio entre l’UC virtuelle et l’UC logique est de 2:1 sur l’Hôte-1 et de 1,5:1 sur l’Hôte-2. Ces ratios se situent dans des limites acceptables.

RemarqueRemarque :
Dans un environnement virtualisé à base de Produits SharePoint, l’allocation de mémoire aux ordinateurs virtuels a un effet bien plus important sur les performances qu’une UC saturée de demandes sur l’ordinateur hôte de virtualisation.

Extensibilité

Les deux ordinateurs hôtes disposent de ressources suffisantes pour une montée en puissance par unité des ordinateurs virtuels ou une montée en charge via l’ajout d’ordinateurs virtuels.

RemarqueRemarque :
Architecture de l’UC des ordinateurs hôtes Hyper-V
La saturation en demandes de l’CPU sur les hôtes Hyper-V n’est pas un problème. Toutefois, il peut être utile de savoir si l’architecture de l’UC de l’hôte de virtualisation prend en charge la technologie Hyper-Threading, car cette fonctionnalité améliore véritablement les performances.

Notre examen fait ressortir la nécessité d’obtenir plus d’informations pour permettre une mise à jour adéquate de l’architecture et des spécifications système. La prochaine étape consiste à obtenir des informations sur les aspects suivants de la batterie de serveurs :

  • Besoins en capacité des bases de données

    La taille de la base de données de la batterie de serveurs, en particulier la base de données de contenu, est un facteur déterminant pour estimer le nombre de fichiers de bases de données à utiliser et leur répartition sur le système de stockage. Il existe d’autres éléments d’information importants : les types de données qui seront stockés (documents, éléments multimédias), les activités de base de données prédominantes (lecture, mise à jour, etc.), la gouvernance, ainsi que les besoins de croissance attendus.

  • Besoins de stockage locaux et partagés

    En règle générale, des informations supplémentaires sont nécessaires pour traiter la question du stockage. À ce stade, nous ne savons pas si l’ensemble du stockage s’effectue localement ou si le but est d’utiliser un stockage local et un stockage réseau partagé. Les serveurs web frontaux et les serveurs d’applications de recherche (SA-1, SA-2) semblent disposer d’un espace de stockage suffisant pour l’index et les fichiers binaires des Produits SharePoint. Toutefois, les besoins de stockage des composants de recherche et de tous les autres services de l’autre serveur d’applications (AP-1) doivent être vérifiés.

    Nous devons également comprendre la stratégie de stockage globale afin de déterminer les besoins de stockage des ordinateurs hôtes de virtualisation (Hôte-1, Hôte-2). D’après le modèle, il semble que seul le stockage local soit utilisé, ce qui affecte la disposition du disque dur et la sélection élective des ordinateurs virtuels.

  • Configurations des disques durs virtuels

    Les configurations des disques durs virtuels affectent directement les configurations et les besoins en matière de stockage des ordinateurs hôtes. Par exemple, si un hôte a recours à un mode de stockage local, à savoir un disque physique connecté directement (également appelé disque pass-through), la configuration réserve la totalité du disque dur à l’ordinateur virtuel. Les configurations des disques durs d’ordinateurs virtuels affectent également les options de sauvegarde et de restauration telles que les instantanés SAN et peuvent affecter la configuration de la haute disponibilité pour les ordinateurs hôtes de virtualisation.

     

  • Haute disponibilité

    Nous avons besoin de plus d’informations pour faire face au manque de haute disponibilité des serveurs d’applications. La haute disponibilité est identifiée comme un besoin pour les serveurs de bases de données, mais il nous faut des détails précis sur la solution qui est utilisée (clustering ou mise en miroir, par exemple), car cela affecte l’architecture et très probablement les spécifications système des bases de données.

Modifications supplémentaires du modèle

Le champ d’application et l’étendue des modifications apportées à l’architecture et aux spécifications système sont déterminés par les résultats de l’examen de conception et de l’analyse des spécifications système effectués initialement.

Votre implémentation peut également jouer un rôle dans le processus, car elle peut servir à déterminer les changements à mettre en œuvre, ainsi que la priorité de chaque changement. Il est possible que les scénarios suivants ne nécessitent pas de modifications, surtout en l’absence d’avantages significatifs et quantifiables. Par exemple :

  • L’architecture préliminaire convient pour un test initial, lors des étapes d’un déploiement de type preuve de concept ou d’un déploiement pilote.

  • Les ordinateurs hôtes de virtualisation ne sont utilisés qu’à des fins de test. Le but est de les utiliser en remplacement des tests d’acceptation utilisateur. Cela élimine la nécessité de résoudre les problèmes d’extensibilité et de disponibilité.

  • La batterie de serveurs est destinée à être utilisée à des fins de test ou d’évaluation. Elle est mise hors service quand ces activités sont terminées.

ConseilConseil :
Archivez les ordinateurs virtuels afin de pouvoir recréer la batterie de serveurs pour des tests futurs.

Après avoir effectué le suivi des recommandations et des demandes d’informations résultant de l’examen de la conception et des spécifications système, nous pouvons mettre à jour le modèle et les spécifications système.

L’illustration suivante montre un modèle révisé qui intègre les modifications recommandées, ainsi que les informations et détails manquants. L’illustration suivante montre une architecture révisée qui convient mieux pour une batterie de serveurs de production.

Figure 3. Architecture révisée pour la batterie de serveurs virtuelle

Architecture révisée pour batterie de serveurs virtualisée

Évaluation de la conception des architectures virtuelle et physique

La révision des architectures virtuelle et physique implémente plusieurs modifications en réponse aux questions soulevées lors de l’examen précédent. Dans l’architecture révisée, nous avons décidé d’effectuer une montée en charge de la plateforme hôte de virtualisation au lieu d’une montée en puissance par unité des deux hôtes du premier modèle.

RemarqueRemarque :
La décision d’effectuer une montée en charge ou une montée en puissance par unité des ordinateurs hôtes de virtualisation est déterminée par la stratégie de gestion matérielle de votre organisation. Cette stratégie est basée sur des facteurs tels que les normes informatiques, les objectifs opérationnels et le budget. Les deux approches en matière d’augmentation de capacité sont valables. Par ailleurs, il existe des aspects positifs et négatifs pour chaque choix d’extensibilité.

La nouvelle architecture est également conçue pour répondre aux objectifs suivants :

  • fournir une haute disponibilité à tous les serveurs de la batterie de serveurs et augmenter le niveau de disponibilité ;

  • améliorer l’extensibilité en permettant une montée en puissance par unité ou une montée en charge de la batterie de serveurs et de ses composants ;

  • offrir plus de souplesse en matière de déplacement d’ordinateurs virtuels entre les hôtes Hyper-V afin de rééquilibrer la charge de travail (si nécessaire) et de permettre une migration dynamique en cas de réduction des fonctionnalités virtuelles des ordinateurs hôtes pour des raisons de capacité ou à la suite d’une défaillance matérielle.

Les modifications suivantes répondent à nos objectifs :

  • Le nombre de serveurs web frontaux augmente et passe à quatre pour offrir un meilleur équilibrage de charge et fournir une plus grande disponibilité à ce rôle de batterie de serveurs spécifique.

  • Le nombre d’ordinateurs hôtes de virtualisation augmente et passe à quatre. En outre, la capacité de chacun de ces ordinateurs est augmentée à l’aide des configurations suivantes :

    • CPU : 16 cœurs + Hyper-Threading

    • Mémoire : 96 Go

  • La haute disponibilité du serveur de base de données est implémentée à l’aide des groupes de disponibilité AlwaysOn de SQL Server 2012.

    Avec deux ordinateurs hôtes de plus, la capacité est suffisante pour dédier un hôte Hyper-V (Hôte-3) au réplica principal (RP) du groupe de disponibilité GD-1. Le réplica secondaire (RS) est installé sur Hôte-2, qui est également dédié à l’exécution de SQL Server 2012. Cette stratégie accroît la capacité et les performances des serveurs de bases de données de la batterie de serveurs. Toutefois, il en résulte une sous-utilisation des ordinateurs hôtes de virtualisation. Après augmentation de la mémoire de l’ordinateur virtuel de la base de données à 32 Go, il reste 60 Go de mémoire non allouée. Le ratio entre le processeur virtuel et le processeur logique n’est que de 1:4, ce qui laisse les deux ordinateurs hôtes de virtualisation dans un état de déficit de demandes.

    Nous avons décidé d’opter pour une configuration de base de données qui fait un meilleur usage des hôtes Hyper-V, qui améliore les performances de base de données en équilibrant mieux la charge de travail et qui fournit une plus haute disponibilité. Cette configuration utilise deux groupes de disponibilité (GD-1 et GD-2). Le réplica principal de GD-2 partage Hôte-2 avec le réplica secondaire de GD-1 et le réplica secondaire de GD-2 partage Hôte-3 avec le réplica principal de GD-1.

    Un autre aspect de la révision de l’architecture et des spécifications système concerne la décision d’utiliser des disques pass-through pour les ordinateurs virtuels de bases de données. Cette configuration suit les meilleures pratiques en matière de configuration des disques durs d’un ordinateur virtuel qui exécute SQL Server. Le disque pass-through correspond à la configuration de disque Hyper-V recommandée pour les serveurs de bases de données. Bien que les disques pass-through n’offrent que des performances légèrement supérieures à celles des disques de taille fixe, les disques pass-through représentent un meilleur choix pour les disques de grande capacité, ainsi que pour les applications qui nécessitent de nombreuses E/S (entrées/sorties) disque, une caractéristique bien connue des bases de données de Produits SharePoint. En outre, les disques pass-through permettent d’éviter les contentions de disques, car les autres disques durs virtuels ne peuvent pas accéder au disque physique.

  • La montée en charge des hôtes de virtualisation offre plus de souplesse en matière d’équilibrage de la charge de travail des ordinateurs virtuels.

  • L’utilisation de quatre ordinateurs hôtes de virtualisation est une bonne base pour l’implémentation du clustering de basculement, ainsi que pour la migration rapide et la migration dynamique des ordinateurs virtuels. Pour plus d’informations, voir Présentation d’Hyper-V et des ordinateurs virtuels dans le contexte d’un cluster (http://technet.microsoft.com/fr-fr/library/dd759249.aspx).

Analyse des spécifications système des ordinateurs hôtes de virtualisation

Le tableau suivant (révision des spécifications système des ordinateurs hôtes de virtualisation (Hôte-1, Hôte-2, Hôte-3 et Hôte-4)) présente une analyse des performances des ordinateurs hôtes de virtualisation basée sur des critères tels que la mémoire, la configuration du processeur et l’extensibilité.

Révision des spécifications système des ordinateurs hôtes de virtualisation (Hôte-1, Hôte-2, Hôte-3 et Hôte-4)

Spécifications Analyse

Mémoire

Une fois que vous avez alloué 4 Go de mémoire RAM à chaque ordinateur hôte de virtualisation, la mémoire non allouée des ordinateurs hôtes Hyper-V se présente comme suit :

  • Hôte-1 : 36 Go

  • Hôte-2 : 28 Go

  • Hôte-3 : 28 Go

  • Hôte-4 : 36 Go

La mémoire non allouée sur l’ensemble des ordinateurs hôtes permet de disposer d’une capacité suffisante pour l’extensibilité ou la migration dynamique.

Processeurs

À la suite de la révision de l’architecture, les ratios entre processeurs virtuels et processeurs logiques sont les suivants :

  • Hôte-1 : le ratio virtuel/logique est de 1:1.

  • Hôte-2 : le ratio virtuel/logique est de 1:2.

  • Hôte-3 : le ratio virtuel/logique est de 1:2.

  • Hôte-4 : le ratio virtuel/logique est de 1:1.

Ces ratios se situent dans des limites acceptables.

Extensibilité

La révision de l’architecture prend en charge l’extensibilité dans l’ensemble de la batterie de serveurs et pour tous les composants de la batterie de serveurs.

Les modifications apportées à la conception de l’architecture et aux spécifications système sont une amélioration par rapport au premier modèle. Toutefois, une itération supplémentaire est nécessaire pour les tâches suivantes :

  • Fournir davantage de spécifications détaillées pour la stratégie de stockage (stockage local ou réseau partagé) pour les ordinateurs virtuels des serveurs de bases de données. Pour ce faire, des informations supplémentaires relatives à la taille et au type de contenu censé être stocké par la batterie de serveurs sont nécessaires.

  • Affiner les spécifications des serveurs web frontaux. Cela nécessite l’obtention d’informations sur l’utilisation prévue, par exemple le nombre de connexions simultanées ou la durée moyenne de connexion.

Il n’y a pas de nombre obligatoire ou optimal d’itérations d’examen et de révision. Continuez le cycle jusqu’à ce que vous arriviez à un stade où les révisions supplémentaires n’améliorent plus vraiment la conception ou les spécifications système. Il s’agit du moment où vous devez tester la batterie de serveurs dans un environnement réel.

Quelle que soit l’ampleur de vos efforts, l’architecture et les spécifications système restent théoriques jusqu’au déploiement de la batterie de serveurs dans un environnement de test de pré-production et jusqu’à l’exécution d’une série de tests de référence. Le nombre de tests de référence nécessaires dépend de votre stratégie matérielle. Si cette stratégie est basée sur les besoins spécifiés, les besoins en matière de tests de référence sont réduits.

ConseilConseil :
Comparez le coût et le temps nécessaires pour mener des tests de référence approfondis au coût d’un matériel supérieur en termes de capacité et de performances nécessaires. Selon votre situation, l’investissement dans du matériel peut représenter une meilleure option.

Les tests de référence fournissent les données dont vous avez besoin pour évaluer, puis implémenter les modifications de plateformes appropriées. Le premier ensemble de données de référence vous permet d’identifier l’ampleur, la nature et l’étendue des modifications nécessaires. En règle générale, les premières modifications prises en compte par les équipes de déploiement sont les suivantes (non classées par ordre de priorité) :

  • Modifiez l’architecture de la topologie de la batterie de serveurs afin de répartir la charge de travail.

  • Effectuez une montée en puissance par unité des ordinateurs virtuels ou une montée en charge de la batterie de serveurs en ajoutant des ordinateurs virtuels.

  • Effectuez une montée en puissance par unité des ordinateurs hôtes Hyper-V ou une montée en charge de la plateforme matérielle en ajoutant davantage d’ordinateurs hôtes.

L’équipe de déploiement doit déterminer la priorité, le gain potentiel et les effets de ces modifications. Comme les données disponibles peuvent s’avérer insuffisantes pour parvenir à des conclusions, des critères supplémentaires sont parfois nécessaires. Par ailleurs, vous pouvez être amené à changer les tests de référence afin d’obtenir les données que vous souhaitez.

RemarqueRemarque :
Nous vous recommandons de tester la stratégie (et les outils) d’analyse et de rapport que vous souhaitez utiliser pour l’environnement de production. La réalisation de tests sur les batteries de serveurs en pré-production vous permet de disposer d’éléments d’analyse et de rapport pleinement opérationnels lors de l’entrée en production de la batterie de serveurs.

En conclusion, votre architecture et vos spécifications système continueront d’évoluer au fil des étapes de pré-production et de production. Nous vous recommandons de continuer à exécuter des tests de référence jusqu’à ce que la batterie de serveurs soit stabilisée dans l’environnement de production.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft