Exporter (0) Imprimer
Développer tout

SharePoint 2013 sur les services d'infrastructure Windows Azure

Mis à jour: avril 2014

Grâce aux services Machine virtuelle et Réseau virtuel de Azure, il est maintenant possible de déployer et d'exploiter une batterie de serveurs Microsoft SharePoint 2013 accessible via Internet avec SQL Server AlwaysOn dans Azure. La figure suivante montre un exemple de configuration.

Cette rubrique présente les principales considérations de conception, l'architecture et les opérations nécessaires pour cela. Elle suppose que vous avez une connaissance de base de SharePoint Server 2013 et que vous êtes familiarisé avec les services proposés par Azure.

Microsoft propose et concède sous licence deux catégories de solutions de batterie de serveurs SharePoint. Ces solutions sont dans le cloud (SharePoint Online avec Office 365) et locales (SharePoint 2013).

SharePoint 2013 utilise les licences et l'installation de logiciel traditionnelles. Vous pouvez installer et configurer SharePoint pour déployer une batterie de serveurs sur des ordinateurs physiques ou dans un environnement virtuel. Vous pouvez également déployer et exploiter une batterie de serveurs dans votre propre centre de données ou sur une infrastructure fournie par un service d'hébergement. Cet ensemble de documents décrit le déploiement d'une batterie de serveurs SharePoint 2013 pour des utilisateurs sur Internet avec SQL Server AlwaysOn dans les services d’infrastructure Azure.

SharePoint Server 2013 fournit un ensemble complet de fonctionnalités pour prendre en charge un large éventail d'activités de collaboration pour une organisation. Toutefois, ces fonctionnalités et fonctions peuvent rendre la planification et la conception difficiles pour les raisons suivantes :

  • Il n'existe pas de taille de batterie de serveurs générique universelle. Les batteries déployées dans différentes organisations peuvent sembler similaires et avoir le même nombre de serveurs. Cependant, un examen minutieux révèlera qu'il existe des différences essentielles entre deux batteries de serveurs quelconques. Plus loin dans cet article nous allons décrire les modèles génériques de topologie qui vous aideront à concevoir une batterie de serveurs.

  • Bien qu'il existe plusieurs façons d'évaluer la capacité requise pour la batterie et les serveurs afin d'estimer la taille, il n'existe pas de formule unique globale pour générer une conception de batterie détaillée complète avec le nombre de serveurs et leur capacité.

L'importance de la planification et de la conception d'une batterie de serveurs SharePoint ne peut pas être surestimée. Une planification inadaptée et en conséquence, une mauvaise conception de la batterie de serveurs, est la principale raison pour laquelle les batteries de serveurs SharePoint ne répondent pas aux attentes des utilisateurs ni aux objectifs d'une organisation. Les problèmes de planification et de conception contribuent également à un nombre important d'appels au support technique liés à la capacité et aux performances.

Une planification complète et rigoureuse est essentielle pour garantir qu'une batterie de serveurs SharePoint est déployée avec succès et fournit les fonctionnalités attendues.

Les éléments suivants sont fondamentaux pour planifier et concevoir une batterie de serveurs :

  • Fonctions et fonctionnalités : déterminez quelles sont les fonctions que la batterie de serveurs doit fournir, et identifiez les fonctionnalités nécessaires pour fournir les fonctions.

  • Services et applications de service : déterminez les services et les applications de service nécessaires pour les fonctionnalités que vous avez l'intention d'utiliser.

  • Utilisateurs de la batterie : déterminez comment, à quelle fréquence et quand vos utilisateurs utilisent les fonctions de la batterie de serveurs fournies.

  • Contenu de la batterie de serveurs : les types de contenu de la batterie (par exemple, des documents, des images, des vidéos, des listes et des articles web) et le volume (nombre d'éléments et taille) déterminent la capacité requise pour la base de données.

  • Utilisation prévue : l'objectif du déploiement d'une batterie de serveurs ou l'utilisation prévue détermine le niveau de planification et le type de conception nécessaires. Par exemple, une batterie de serveurs d'évaluation de produit, une batterie de serveurs de développement et une batterie de serveurs de test en préproduction ont une base d'utilisateurs différente, différentes configurations des fonctionnalités et différentes configurations de taille.

Les aspects précédents de la planification d'une batterie de serveurs sont les plus évidents. D'autres facteurs doivent également être inclus dans la planification de la batterie, tels que la sécurité, la haute disponibilité et l’évolutivité. Pour plus d'informations, consultez Planifier SharePoint 2013.

Après avoir identifié la configuration requise pour la batterie de serveurs, l'étape suivante consiste à concevoir son architecture. Cette architecture décrit la disposition logique de tous les composants qui fournissent les fonctionnalités et les services pour la batterie de serveurs. Cette architecture logique vous permet de créer une architecture physique, ou une topologie de batterie de serveurs qui identifie les éléments nécessaires pour implémenter l'architecture logique. Une topologie de batterie de serveurs SharePoint identifie le nombre et la distribution de serveurs nécessaires et comprend généralement des informations de taille pour chacun des serveurs. Pour plus d’information, consultez Planifier des architectures logiques pour SharePoint 2013.

Installez et configurez SharePoint sur un ou plusieurs serveurs pour prendre en charge les fonctionnalités que vous avez l'intention de fournir sur votre batterie de serveurs SharePoint. Pour toute batterie de serveurs donnée, le nombre de serveurs utilisés et la capacité de chaque serveur varient. Il existe de nombreux facteurs déterminants qui affectent une infrastructure de batterie de serveurs SharePoint. Par exemple, les fonctions et les fonctionnalités fournies par la batterie de serveurs, le nombre d'utilisateurs et le volume et le type de contenu qui est enregistré. Ces facteurs et de nombreux autres doivent être identifiés et évalués avant de définir la taille, d'acquérir et de déployer des serveurs pour la batterie.

Un diagramme de topologie de batterie utilise des couches, qui sont simplement un moyen pratique d'organiser ou classer les serveurs de la batterie par catégorie. L'appartenance à une couche est basée sur les rôles de serveur, qui décrivent les fonctionnalités ou les services fournis par un serveur. Il est important de noter que les serveurs d'une couche hébergent les mêmes services ou sous-ensembles de ce service. Cela est assez courant dans les batteries de serveurs SharePoint de très grande taille où haute disponibilité et équilibrage de charge sont des objectifs de conception. À l'exception des serveurs de la couche Base de données, les serveurs des autres couches sont faiblement couplés. Cela signifie qu'il est relativement simple de déplacer des serveurs entre les couches pour s'adapter aux pics de charge de travail ou pour remplacer un serveur défaillant.

Les couches et les rôles serveur suivants sont utilisés pour décrire chaque type de batterie de serveurs, notamment intranet d'entreprise ou sites Internet. Notez que la taille de la batterie elle-même n'est pas un facteur déterminant afin de décider du nombre de couches à utiliser dans une topologie de batterie. Toutefois, trois couches sont généralement incluses dans les batteries de serveurs SharePoint de taille moyenne et grande.

Habituellement appelés serveurs Web frontaux, le rôle de ces serveurs est de répondre aux demandes entrantes de contenu de l'utilisateur. Ces serveurs acheminent la demande vers un autre serveur, ou fournissent le contenu. Dans la plupart des cas, les serveurs sur le Web ont des configurations identiques ou très similaires pour être interchangeables et facilement échangées dans ou hors de la couche. Étant donné que les serveurs de la couche Web sont généralement équilibrés en charge et n'exécutent pas de nombreux services SharePoint, ils n'ont pas besoin d'une grande quantité de mémoire ou de stockage local.

Les serveurs de cette couche exécutent les services, les applications de service et les tâches qui prennent en charge les fonctionnalités SharePoint. Un serveur d'applications peut être dédié à l'hébergement d'un seul service, à la prise en charge d'un sous-ensemble d'une fonctionnalité ou à l'hébergement de plusieurs services. Selon la configuration de la batterie, plusieurs serveurs d'applications équilibrés en charge peuvent être utilisés pour distribuer les charges de travail et fournir une haute disponibilité.

Parfois appelés couche Base de données principale, les serveurs de cette couche sont dédiés à l'hébergement de l'instance du serveur de base de données qui traite chaque aspect du contenu de la batterie de serveurs SharePoint, des données de configuration de la batterie et des bases de données d'application de service.

SharePoint 2013 ne prend pas en charge l'utilisation d'une base de données Azure SQL à la place d'un serveur exécutant SQL Server.

noteRemarque
Il existe des cas où les organisations partagent le serveur de base de données avec plusieurs applications qui utilisent SQL Server. Comme cela peut entraîner des problèmes significatifs de performances et de capacité, il est recommandé d’utiliser un serveur de base de données dédié pour SharePoint.

Les exemples suivants montrent comment SharePoint peut être déployé sur un ou plusieurs serveurs en utilisant des topologies à plusieurs niveaux et des rôles de serveur pour implémenter une conception de batterie de serveurs qui répond à des objectifs spécifiques.

Il existe des scénarios où il est logique d'installer SharePoint sur un seul serveur. Une batterie d'un seul serveur est généralement utilisée pour présenter SharePoint, effectuer une évaluation superficielle des fonctionnalités de SharePoint ou comparer SharePoint 2013 avec des versions précédentes.

Dans une batterie de serveurs à deux niveaux (voir Figure 1), le serveur de base de données est installé sur un serveur et tous les autres rôles sont installés sur le deuxième serveur. Ce niveau de séparation est le minimum que nous recommandons pour déployer SharePoint sur Azure. Cette topologie est adaptée à l'évaluation approfondie du produit, au développement et au test ou aux environnements de production limités qui ont un petit nombre d'utilisateurs (tels qu'un déploiement pilote SharePoint) et pour lesquels la haute disponibilité n'est pas nécessaire.

Figure 1 – Batterie SharePoint à deux niveaux

La topologie à trois niveaux illustrée dans la Figure 2 comprend deux serveurs Web frontaux, un serveur d'applications et un serveur de base de données. Ce modèle fournit la base pour le déploiement d'une batterie de serveurs qui peut monter en puissance parallèle en réponse à des charges de travail accrues ou au développement d'une base de données.

Figure 2 – Batterie multi-serveur avec deux serveurs Web, un serveur d’applications et un serveur de base de données

Il fournit également l'infrastructure d'utilisation des serveurs redondants pour accroître la capacité et la disponibilité de la batterie (Figure 3). Pour fournir un service hautement disponible, vous avez besoin d'au moins deux serveurs dans chaque couche ou pour chaque rôle au sein d'une couche.

Figure 3 – Batterie multi-serveur avec haute disponibilité

Les batteries de serveurs SharePoint de grande taille très demandées qui prennent en charge un nombre élevé d'utilisateurs simultanés et un grand nombre d'éléments de contenu utilisent le regroupement de services dans le cadre de leur stratégie d'évolutivité. Cette approche implique l'exécution des services sur des serveurs dédiés, le regroupement de ces services, puis la montée en charge parallèle des serveurs en tant que groupe. La figure 4 montre un modèle de service et de regroupement de serveurs dans une batterie à trois niveaux.

Figure 4 - Grande batterie multi-serveur avec plusieurs groupes de serveurs

La taille est utilisée conjointement avec les topologies pour décrire l'architecture physique d'une batterie. Les batteries de serveurs SharePoint sont classées par catégorie (petite, moyenne et grande).

Une petite batterie de serveurs est constituée des éléments suivants :

  1. deux serveurs Web ;

  2. un serveur de base de données.

Un des serveurs Web héberge le site Administration centrale et les services et l'autre gère les tâches supplémentaires, telles que les demandes de contenu de client. Cette batterie peut monter en puissance avec trois couches à l'aide d'un serveur d'applications dédié. Consultez la figure 2 pour obtenir un exemple.

Une batterie de serveurs de taille moyenne inclut généralement les éléments suivants :

  1. plusieurs serveurs Web ;

  2. deux serveurs d’applications ;

  3. au moins deux serveurs de base de données.

Consultez la figure 3 pour obtenir un exemple.

Une batterie de serveurs de grande taille est le résultat de la montée en puissance parallèle d'une batterie de serveurs de taille moyenne pour répondre aux besoins de capacité et de performances ou en vue d'implémenter une solution SharePoint 2013. Une topologie à trois niveaux utilise généralement des serveurs dédiés sur chaque couche et les serveurs sont regroupés d'après leur rôle.

Consultez la figure 4 pour obtenir un exemple.

SharePoint Server est conçu pour prendre en charge la granularité des services et des applications de service, ce qui signifie que vous pouvez configurer une fonctionnalité pour exécuter ses services ou applications de service de prise en charge sur différents serveurs dans un niveau ou sur différents niveaux. Cette approche de conception fournit un niveau élevé de souplesse pour la montée en puissance parallèle d'une batterie de serveurs et peut être appliquée à chaque niveau.

La montée en puissance par unité ou la montée en puissance parallèle de la batterie de serveurs en ajoutant des serveurs sont deux solutions acceptables pour une batterie de serveurs SharePoint. En outre, les deux approches peuvent être appliquées aux serveurs physiques ou aux machines virtuelles. La décision visant à faire monter en puissance par unité ou parallèle une batterie de serveurs, comme la conception de la topologie de la batterie, dépend de plusieurs facteurs.

Le coût, la flexibilité et la rapidité de déploiement sont les principaux facteurs déterminants d'une décision de mise à l'échelle lorsque les serveurs physiques, les périphériques et les réseaux fournissent l'infrastructure. Il est plus rapide et moins onéreux de mettre à niveau le matériel que d'en ajouter.

Toutefois, avec Azure, il est plus efficace de faire monter en puissance parallèle en ajoutant des machines virtuelles dans la batterie. L'approvisionnement de nouveaux serveurs est plus rapide, ce qui permet une réponse plus rapide aux pics d'activité.

La montée en charge offre également deux autres avantages notoires : la disponibilité accrue et la réduction des temps mort (planifiés ou non planifiés). Du point de vue de la haute disponibilité, la flexibilité et le coût de la virtualisation rendent possible la création de serveurs et la redondance des services dans la conception de la batterie de serveurs SharePoint. Cette redondance réduit ou supprime des domaines d'échec. La possibilité d'ajouter rapidement des serveurs à n'importe quel niveau de la batterie réduit les temps mort lors de l'application des mises à jour logicielles au système d'exploitation, à SQL Server ou à SharePoint.

Azure prend en charge le déploiement des batteries de serveurs SharePoint 2013 avec des machines virtuelles et des réseaux virtuels.

Azure permet de créer une machine virtuelle exécutant Windows Server ou d’autres systèmes d’exploitation. Après avoir créé une machine virtuelle dans Azure, vous pouvez y accéder comme à tout autre serveur, puis la supprimer et la recréer si nécessaire. Vous pouvez utiliser une machine virtuelle dans Azure pour déployer un serveur Windows Server 2012 R2.

Les machines virtuelles Azure sont créées à partir de disques durs virtuels (VHD). Ces VHD sont les mêmes que les VHD utilisés par Hyper-V, et peuvent être transférés vers et depuis votre environnement existant. Azure vous permet aussi de créer plusieurs machines virtuelles, puis d'équilibrer le trafic Internet entre elles.

Azure fournit des combinaisons spécifiques de cœurs d'UC et de mémoire appelées tailles de machine virtuelle. Lorsque vous créez une machine virtuelle, vous devez sélectionner une taille spécifique. Cette taille peut être modifiée après le déploiement. Les tailles disponibles pour les machines virtuelles sont les suivantes :

  • Très petite (Cœur partagé, 768 Mo de mémoire)

  • Petite (1 cœur, 1,75 Go de mémoire)

  • Moyenne (2 cœurs, 3,5 Go de mémoire)

  • Grande (4 cœurs, 7 Go de mémoire)

  • Très grande (8 cœurs, 14 Go de mémoire)

  • A6 (4 cœurs, 28 Go de mémoire)

  • A7 (8 cœurs, 56 Go de mémoire)

Vous créez une machine virtuelle Azure à partir d'une image ou d'un disque. Toutes les machines virtuelles utilisent un disque de système d'exploitation, un disque local temporaire et éventuellement plusieurs disques de données. Toutes les images et tous les disques, sauf le disque local temporaire, sont créés à partir de fichiers VHD stockés sous forme d'objets blob de pages dans un compte de stockage Azure. Vous pouvez utiliser les images de plateforme disponibles dans Azure pour créer des machines virtuelles, ou télécharger vos propres images. Les disques créés à partir d'images sont également stockés dans le stockage Azure. Vous pouvez facilement créer des machines virtuelles à partir de disques existants.

Un fichier VHD est stocké en tant qu'objet blob de pages dans le stockage Azure et peut être utilisé pour créer des images, des disques de système d'exploitation ou des disques de données dans Azure. Téléchargez un fichier VHD vers Azure et gérez-le comme n'importe quel autre objet blob de pages. Les fichiers VHD peuvent être copiés ou déplacés. En outre, ils peuvent être supprimés tant qu'ils ne sont pas référencés par un disque. Un fichier VHD est stocké en tant qu'objet blob de pages dans le stockage Azure et peut être utilisé pour créer des images, des disques de système d'exploitation ou des disques de données. Téléchargez un fichier VHD vers Azure et gérez-le comme n'importe quel autre objet blob de pages. Les fichiers VHD peuvent être copiés ou déplacés. En outre, ils peuvent être supprimés tant qu'ils ne sont pas référencés par un disque. Pour plus d'informations sur les objets blob de pages, consultez les détails relatifs aux objets blob de blocs et objets blob de pages.

Le format d'un disque dur virtuel peut être soit fixe, soit dynamique, mais seul le format fixe des fichiers VHD est pris en charge dans Azure. Le format fixe définit la structure du disque logique de façon linéaire dans le fichier, afin que le décalage de disque X soit stocké au niveau du décalage d'objet blob X. À la fin de l'objet blob, un petit pied de page décrit les propriétés du disque dur virtuel. Bien souvent, le format fixe gaspille de l'espace, car la plupart des disques comportent de grandes plages inutilisées. Toutefois, dans Azure, les fichiers VHD fixes sont stockés dans un format épars, ce qui vous permet de bénéficier des avantages des disques fixes et dynamiques en même temps. Cela comprend le fait d'être facturé uniquement pour les bits utilisés. Pour plus d'informations sur les disques durs virtuels, consultez Prise en main des disques durs virtuels.

Une image est un fichier VHD que vous pouvez utiliser comme modèle pour créer une machine virtuelle. Une image est un modèle car elle n'a pas de paramètres spécifiques comme une machine virtuelle configurée, tels que les paramètres de nom d'ordinateur et de compte d'utilisateur. Imaginez-les comme des images préparées à l’aide de l’outil SysPrep. Vous pouvez utiliser les images de plateforme de la galerie d'images qui sont fournies par Microsoft pour créer des machines virtuelles, ou créer vos propres images.

Toutes les images Windows de la galerie ont désormais une taille de disque de système d'exploitation de 127 Go. Il existe également un certain nombre d'images de la galerie que vous pouvez utiliser pour créer des batteries de serveurs SharePoint 2013 comprenant plusieurs images SQL Server 2012. L’image de la version d’évaluation de SharePoint 2013 indique que SharePoint Server 2013 est installé, mais l'Assistant Configuration des produits et technologies SharePoint n’a pas été exécuté.

La figure 5 montre un exemple de la liste des images fournies par Azure.

Figure 5 – Exemple de la galerie d’images Azure

La licence d'évaluation de SharePoint 2013 peut être mise à niveau vers une version complète. Pour convertir un type de licence et entrer la clé de produit, procédez comme suit :

  1. Vérifiez que vous vous êtes connecté au serveur SharePoint en tant que membre du groupe Administrateurs de batterie de serveurs SharePoint sur l'ordinateur qui exécute l'Administration centrale.

  2. Sur le site Web Administration centrale, dans la section Mise à niveau et migration, cliquez sur Convertir le type de licence de la batterie.

  3. Sur la page Convertir le type de licence de la batterie, dans la zone Entrez la clé du produit, tapez votre clé du produit SharePoint 2013, puis cliquez sur OK.

Vous utilisez les disques de différentes façons avec une machine virtuelle dans Azure. Un disque de système d'exploitation est un disque dur virtuel que vous utilisez pour fournir un système d'exploitation à une machine virtuelle. Un disque de données est un disque dur virtuel que vous attachez à une machine virtuelle pour stocker des données d'application. Vous pouvez créer et supprimer des disques si nécessaire.

Vous disposez de plusieurs façons de créer des disques en fonction des besoins de votre application. Par exemple, une façon classique de créer un disque de système d'exploitation consiste à utiliser une image de la galerie d'images lorsque vous créez une machine virtuelle, ce qui entraîne la création d'un disque de système d'exploitation. Vous créez un disque de données en attachant un disque vide à une machine virtuelle, ce qui entraîne la création d'un disque de données. Vous pouvez également créer un disque à l'aide d'un fichier VHD téléchargé ou copié vers un compte de stockage dans votre abonnement. Vous ne pouvez pas utiliser le portail pour télécharger des fichiers VHD. Toutefois, vous pouvez utiliser d'autres outils compatibles avec le stockage Azure pour télécharger ou copier le fichier souhaité, notamment les commandes Azure PowerShell. Pour plus d’informations, consultez Azure PowerShell Cmdlets Now Supports Storage (Les applets de commande Azure PowerShell prennent désormais le stockage en charge).

Un disque de données est un disque dur virtuel qui peut être attaché à une machine virtuelle en cours d'exécution pour stocker de manière persistante des données d'application. Vous pouvez télécharger et attacher un disque de données qui contient déjà des données à la machine virtuelle, ou vous pouvez utiliser le Portail de gestion Azure pour attacher un disque vide à l'ordinateur. La taille maximale d'un disque de données est de 1 To et vous êtes limité dans le nombre de disques que vous pouvez attacher à une machine virtuelle en fonction de la taille de l'ordinateur. Les disques de données sont inscrits en tant que lecteurs SCSI et vous pouvez les rendre disponibles dans Windows à l’aide du Gestionnaire de serveur ou du composant logiciel enfichable Gestion des disques. Le tableau suivant répertorie le nombre de disques attachés qui sont autorisés pour chaque taille de machine virtuelle.

 

Taille Nombre maximal de disque attachés

Très petite

1

Petit

2

Moyen

4

Grande

8

Très grande

16

A6

8

A7

16

Chaque machine virtuelle que vous créez possède un disque local temporaire, nommé lecteur D. Ce disque est utilisé par les applications et les processus en cours d'exécution sur la machine virtuelle pour le stockage transitoire et temporaire des données. Il est également utilisé pour stocker les fichiers d'échange du système d'exploitation. Notez que cette lettre de lecteur ne peut pas être modifiée et qu'aucune donnée sur le lecteur D ne survivra à une défaillance d'ordinateur ou à toute autre opération nécessitant un déplacement de la machine virtuelle vers un autre élément matériel.

Le disque de système d'exploitation et le disque de données comportent un paramètre de mise en cache d'hôte (parfois appelé mode de cache d'hôte), qui permet d'améliorer les performances dans certaines circonstances. Toutefois, ces paramètres peuvent avoir des effets négatifs sur les performances dans d'autres circonstances, selon l'application. Les paramètres suivants sont définis par défaut :

  1. Pour les disques de données, le Caching d'hôte est désactivé pour les opérations de lecture et d'écriture.

  2. Pour les disques du système d'exploitation, le Caching d'hôte est activé par défaut pour les opérations de lecture et d'écriture.

Vous pouvez accéder à de nouvelles machines virtuelles sur Internet via le protocole RDP (Remote Desktop Protocol) et les sessions Windows PowerShell distantes. Par défaut, Azure ajoute des mappages entrants, appelés points de terminaison, pour les deux types de trafics lorsque vous créez la machine virtuelle. Ces points de terminaison autorisent les sessions RDP entrantes et les sessions Windows PowerShell distantes avec les informations d'identification appropriées.

Un réseau virtuel Azure est un conteneur logique qui peut héberger des machines virtuelles regroupées sur des sous-réseaux. Les machines virtuelles sur les sous-réseaux d'un réseau virtuel peuvent communiquer directement entre elles (comme sur les sous-réseaux intranet mais sans trafic sur Internet). Ce n’est pas le cas des machines virtuelles Azure non incluses dans un réseau virtuel : celles-ci ne peuvent pas communiquer entre elles sans trafic sur Internet.

Il existe deux types de réseaux virtuels :

  1. Réseau virtuel intersite : réseau virtuel connecté au réseau de votre organisation sur Internet via une connexion VPN de site à site. Les machines virtuelles au sein d’un réseau virtuel intersite agissent comme une extension du réseau de votre organisation, et fournissent des applications et services aux utilisateurs sur intranet et/ou Internet.

  2. Réseau virtuel sur le cloud uniquement : réseau virtuel non connecté au réseau de votre organisation. Les machines virtuelles dans un réseau virtuel sur le cloud uniquement fournissent des applications et services aux utilisateurs sur Internet.

Grâce aux réseaux virtuels intersite, les administrateurs peuvent étendre les réseaux locaux dans le cloud tout en contrôlant la topologie réseau et la configuration des plages d'adresses IP et serveurs DNS pour les machines virtuelles.

Vous devez toujours créer un réseau virtuel dans Azure avant de déployer de nouvelles machines virtuelles. La création d'un réseau virtuel vous permettra de regrouper vos machines virtuelles et de diviser et déterminer les plages d'adresses IP affectées à vos machines virtuelles.

Lorsque vous créez un réseau virtuel intersite, vous définissez une plage d’adresses IPv4 privées propres au réseau de votre organisation utilisables pour tous les sous-réseaux inclus dans le réseau virtuel. Vous définissez également une plage d’adresses IPv4 pour chaque sous-réseau. Lorsque vous créez une machine virtuelle et ajoutez celle-ci à un sous-réseau, Azure affecte une adresse de la plage d’adresses IPv4 pour le sous-réseau via le service DHCP. La durée sur le bail DHCP est définie au moins à 100 ans, à condition que la configuration des adresses soit stable.

Il est important de noter que Azure lui-même utilise plusieurs adresses de la plage d’adresses IPv4 pour chaque sous-réseau. La première machine virtuelle que vous ajoutez à un sous-réseau a généralement la quatrième adresse IP dans la plage. Par exemple, pour le sous-réseau associé à la plage d’adresses 10.0.0.0/24 (ou 10.0.0.0 avec le masque de sous-réseau 255.255.255.0), l’adresse IP de votre première machine virtuelle sera 10.0.0.4.

Pour connecter le réseau virtuel intersite dans Azure à votre réseau local, vous devez créer une connexion VPN de site à site. Un périphérique de passerelle VPN placé à la frontière de votre réseau local permet d’établir une connexion sécurisée à une passerelle VPN Azure à la périphérie de votre réseau virtuel. Pour vérifier que vous pouvez accéder aux machines virtuelles à partir de votre réseau local, vous devez configurer votre infrastructure de routage avec des itinéraires pour l'espace d'adressage du réseau virtuel de telle sorte qu’elle pointe vers votre périphérique de passerelle VPN.

Les connexions de site à site Azure utilisent la sécurité du protocole Internet (IPsec) standard pour fournir une connexion sécurisée entre votre périphérique de passerelle VPN et une passerelle VPN Azure placée à la frontière de votre réseau virtuel Azure. Vous pouvez contrôler l'accès réseau avec votre unité de sécurité locale. Vous pouvez également contrôler le trafic entre votre centre de données et les machines virtuelles qui s'exécutent dans Azure avec le pare-feu Windows standard basé sur l'hôte dans Windows Server.

Pour réduire la latence liée à l’authentification des informations d’identification des utilisateurs intranet relative à l’accès aux sites et ressources des batteries de serveurs SharePoint et à leur administration, vous devez déployer des contrôleurs de domaine de services de domaine Active Directory (AD DS) dans le réseau virtuel. Pour établir la redondance, vous devez en déployer au moins deux.

Pour plus d’informations, consultez Recommandations en matière de déploiement de Windows Server Active Directory sur des machines virtuelles Azure.

noteRemarque
SharePoint 2013 nécessite une appartenance au domaine AD DS pour le serveur qui l'exécute. Vous ne pouvez pas utiliser Azure Active Directory (AD) en remplacement de l'appartenance au domaine AD DS pour le serveur SharePoint 2013. En revanche, vous pouvez utiliser Azure AD pour assurer l'authentification d'utilisateurs accédant à des ressources SharePoint. Pour plus d'informations, consultez Azure Active Directory avec SharePoint 2013.

Lorsque vous définissez un réseau virtuel intersite, vous devez configurer Azure avec les adresses IP des serveurs DNS affectés aux machines virtuelles avec le service DHCP. Ces serveurs DNS peuvent être des serveurs DNS locaux existants ou des serveurs DNS que vous allez créer dans le réseau virtuel. Vous pouvez également héberger les serveurs DNS sur les contrôleurs de domaine AD DS dans le réseau virtuel.

noteRemarque
Vous ne devez pas modifier les connexions réseau des machines virtuelles dans un réseau virtuel Azure (par exemple, pour configurer les paramètres DNS ou un autre comportement). Vous devez laisser à Azure le soin de fournir la configuration des connexions réseau, sans quoi votre machine virtuelle pourrait devenir inaccessible.

Lorsque vous créez un réseau virtuel, vous pouvez créer un groupe d'affinités ou spécifier un groupe d'affinités créé précédemment. Lorsque vous créez des ressources telles que des comptes de stockage dans Azure, un groupe d'affinités indiquera à Windows Azure que vous souhaitez conserver ces ressources au sein du même centre de données régional Azure. Une fois que vous avez un groupe d'affinités, vous devez toujours le spécifier lorsque vous créez les ressources connexes.

Lorsque vous créez une machine virtuelle, elle est entièrement accessible à partir de chacune de vos autres machines virtuelles dans votre réseau virtuel. Tous les protocoles, tels que TCP, UDP et ICMP, etc., sont pris en charge dans le réseau virtuel local, en fonction des paramètres des pare-feux basés sur un hôte, tels que le pare-feu Windows dans Windows Server 2012.

Si vous voulez accéder à vos machines virtuelles depuis Internet ou rendre les ressources sur vos machines virtuelles accessibles aux utilisateurs sur Internet, vous devez utiliser le nom externe ou l'adresse IP publique du service de cloud computing dans lequel la réseau virtuel est inclus et configurer des points de terminaison. Les points de terminaison sont similaires aux règles de transfert ou de mappage de pare-feu et de port et peuvent être configurés pour les machines virtuelles dans le Portail de gestion Azure.

Par défaut, Azure configure des points de terminaison pour le trafic RDP et Remote PowerShell. Ces points de terminaison utilisent des numéros de port aléatoires pour les ports publics qui sont mappés aux numéros de port privé appropriés sur les machines virtuelles.

noteRemarque
Pour empêcher des utilisateurs malveillants sur Internet d’accéder à vos machines virtuelles via RDP ou Remote PowerShell, vous pouvez supprimer ces points de terminaison prédéfinis pour les réseaux virtuels intersite. Vous pouvez alors seulement administrer les machines virtuelles à partir du réseau local. Les administrateurs situés sur Internet doivent d’abord obtenir une connexion au réseau local (par exemple, avec une connexion d'accès à distance).

Pour le trafic Internet vers votre batterie de serveurs SharePoint, vous devez configurer des points de terminaison sur les machines virtuelles du serveur Web. Par exemple, vous pouvez configurer un point de terminaison pour le port TCP public 80, lequel est mappé à un port TCP privé 80 (pour le trafic web standard) ou au port TCP sur lequel le serveur SharePoint écoute.

Si vous avez configuré votre infrastructure de routage de façon à inclure l'espace d'adressage de votre réseau virtuel intersite, vous pouvez accéder aux machines virtuelles sur votre réseau virtuel intersite comme à n’importe quel autre ordinateur dans le réseau de votre organisation.

Azure vous permet également d'équilibrer le trafic réseau vers une adresse publique et un numéro de port public spécifique sur plusieurs machines virtuelles. La figure 6 montre un exemple avec deux serveurs web, qui écoutent tous les deux le trafic web entrant sur le port TCP privé 3456, dans une configuration appelée point de terminaison à charge équilibrée. Azure répartira le trafic entre les nœuds de façon aléatoire. Vous pouvez avoir au plus 50 machines virtuelles derrière un seul point de terminaison à charge équilibrée.

Figure 6 – Adresses et ports publics et privés avec des points de terminaison

Dans l’exemple de la figure 6, le programme d’équilibrage de charge Azure équilibre le trafic Internet entrant pour l’adresse IP publique du service de cloud computing et du port TCP 80 sur les deux machines virtuelles (10.2.0.4 et 10.2.0.5). Dans la figure 6, la première ligne est un point de terminaison à charge équilibrée.

Pour un point de terminaison à charge équilibrée, Azure répartit le trafic de façon aléatoire entre les machines virtuelles configurées. Vous pouvez avoir au plus 50 machines virtuelles pour un point de terminaison à charge équilibrée. Lorsque vous ajoutez des machines virtuelles à un point de terminaison à charge équilibrée, vous devez également créer un groupe à haute disponibilité.

Notez que vous pouvez seulement équilibrer le trafic Internet via un point de terminaison, lequel est mappé à l’adresse IP publique du service de cloud computing qui contient la machine virtuelle. Azure n’équilibre pas la charge entre les machines virtuelles pour les adresses IP et numéros de port privés.

Par exemple, si votre batterie de serveurs SharePoint permet également d’accéder à un intranet, les utilisateurs sur votre réseau accèderont aux serveurs de la batterie via leurs adresses IP privées. Si vous devez équilibrer la charge intranet entre les batteries de serveurs, vous devez déployer votre propre programme d’équilibrage de la charge.

Pour les charges de travail qui nécessitent une haute disponibilité, vous devez déployer plusieurs machines virtuelles pour chaque rôle spécifique. En utilisant plusieurs machines virtuelles, vous vous assurez que votre application reste disponible en cas de défaillance d’accessibilité du réseau local, de défaillance matérielle locale du disque et de tout temps d'arrêt planifié requis par la plateforme.

Vous gérez la disponibilité de votre application qui utilise plusieurs machines virtuelles en ajoutant des ordinateurs à un groupe à haute disponibilité. Les groupes à haute disponibilité sont directement associés aux domaines d'erreur et aux domaines de mise à jour. Un domaine d'erreur dans Azure est défini en évitant les points d'échec uniques, tels que le commutateur réseau ou l'unité d'alimentation d'un rack de serveurs. En fait, un domaine d'erreur est équivalent à un rack de serveurs physiques. Lorsque plusieurs machines virtuelles sont connectées ensemble dans un service cloud, un groupe à haute disponibilité peut être utilisé pour garantir que tous les ordinateurs du groupe ne sont pas arrêtés en même temps pendant la maintenance, ce qui réduit le risque de défaillance du groupe complet.

La figure 7 montre des serveurs dans des groupes à haute disponibilité dans des domaines d'erreur distincts.

Figure 7 – Domaines d'erreur et groupes à haute disponibilité

Azure met à jour périodiquement le système d'exploitation des machines virtuelles qui héberge les instances d'une application. Une machine virtuelle est arrêtée lorsqu'une mise à jour est appliquée. Un domaine de mise à jour est utilisé pour garantir que toutes les instances de machine virtuelle ne sont pas mises à jour en même temps. Lorsque vous attribuez plusieurs machines virtuelles à un groupe à haute disponibilité, Azure garantit que les ordinateurs sont affectés à différents domaines de mise à jour.

La figure 7 illustre deux machines virtuelles exécutant les services IIS dans des domaines distincts de mise à jour et deux machines virtuelles exécutant SQL Server également dans des domaines distincts de mise à jour.

ImportantImportant
L'abonné Azure est chargé d'installer les mises à jour sur les serveurs de la batterie SharePoint. Pour plus d'informations, consultez la section « Application de correctifs et mise à jour » dans cette rubrique.

Vous devez utiliser une combinaison de groupes à haute disponibilité et de points de terminaison d'équilibrage de charge pour veiller à ce que votre application soit toujours disponible et exécutée efficacement. Pour plus d'informations sur l'utilisation des points de terminaison à charge équilibrée, consultez Équilibrage de charge des machines virtuelles.

La montée en puissance parallèle est un principe de base fondamental de l'infrastructure Azure. Lorsque vous prévoyez une batterie de serveurs SharePoint hébergée sur Azure, vous concevez la topologie de la batterie du point de vue de l'utilisation de plusieurs serveurs de plus petite capacité plutôt que d'un nombre inférieur de serveurs de plus grande capacité.

L'exploitation d'une batterie de serveurs SharePoint dans Azure est similaire à celle d'une batterie de serveurs SharePoint partout ailleurs. Malgré la puissance et l'agilité que vous procure Azure, vous devez toujours gérer Windows Server, SharePoint et les dépendances. Les serveurs locaux utilisent une combinaison des outils d'administration Windows Server et SharePoint. Vous pouvez également gérer toute la batterie de serveurs via System Center. Vous pouvez utiliser les mêmes outils et procédures lorsque la batterie de serveurs est hébergée dans un réseau virtuel intersite Azure.

Pour plus d’informations, consultez Planifier la surveillance dans SharePoint 2013.

Vous êtes chargé d'appliquer les correctifs du système d'exploitation et vous avez le contrôle total sur la façon et le moment opportun. L'application de correctifs et la mise à jour de SharePoint 2013 peuvent être silencieuses selon la topologie. Pour plus d’informations, consultez Vue d’ensemble des mises à jour logicielles pour SharePoint 2013.

Azure peut vous aider à tester les mises à jour majeures. Étant donné que vous créez des ressources à la demande, vous pouvez créer un environnement en doublon dans Azure et tester votre stratégie et méthodologie de mise à jour ou d'application de correctifs avant de mettre à jour votre environnement de production.

La sauvegarde et la récupération des batteries de serveurs SharePoint dans Azure et des batteries de serveurs SharePoint locales sont encore une fois très semblables. Un élément à prendre en considération est que vous ne devez pas subir de temps mort significatif en raison d'une défaillance matérielle. Étant donné que Azure répare automatiquement et redéploye votre machine virtuelle, aucune intervention n'est nécessaire de votre part. Il y aura un temps mort du matériel qui sera automatiquement réparé. Assurez-vous que les personnalisations apportées ou les applications déployées peuvent gérer cette récupération automatique. Azure facilite le déploiement de machines virtuelles, ce qui rend possible la création d'une batterie hautement disponible.

Bien que vous puissiez utiliser l'image de la version d’évaluation de SharePoint 2013 fournie par Microsoft dans la galerie d’images de machine virtuelle Azure pour vos serveurs SharePoint, vous pouvez également créer votre propre image. Vous pouvez procéder ainsi si vous avez une configuration différente, ou si voulez précharger d'autres logiciels, tels que des applications SharePoint ou un logiciel antiprogramme malveillant.

Azure vous permet de créer des « images en or » en créant une image de disque à partir d'un disque dur virtuel existant. Cette image de disque contient le système d'exploitation et les personnalisations dont vous pouvez avoir besoin, par exemple l'installation du logiciel et les paramètres Windows personnalisés. Cette image de disque peut ensuite être utilisée pour créer de nouvelles machines virtuelles. L'utilisation d'une image de disque signifie que vous pouvez créer rapidement plusieurs copies du même serveur.

Pour créer une image en or, vous avez besoin d'une machine virtuelle sur laquelle repose l'image. Cette machine virtuelle est une machine virtuelle Azure standard qui a été personnalisée. Pour créer une base avec SharePoint 2013 installé, il est recommandé de ne pas effectuer l'installation SharePoint 2013 complète. Cela est dû à des incompatibilités avec l’outil SYSPREP, qui est une étape obligatoire pour préparer l'image de disque.

Voici le résumé des étapes de création de l’image :

  1. Créez une machine virtuelle basée sur l'image de Windows Server 2012 R2 Datacenter dans la galerie.

  2. Créez une connexion Bureau à distance vers le nouveau serveur.

  3. Sur le nouveau serveur, téléchargez les fichiers d’installation de SharePoint 2013.

  4. Installez les composants requis pour SharePoint 2013.

  5. Exécutez l'installation du logiciel SharePoint 2013, mais ne terminez pas l'Assistant Configuration des produits et technologies SharePoint. Vous devez installer SharePoint sur le lecteur du système d'exploitation, car les lecteurs de données ne sont pas capturés dans le cadre du processus SysPrep.

  6. Installez et configurez les personnalisations, y compris les applications SharePoint et le logiciel antiprogramme malveillant.

  7. Exécutez SysPrep et arrêtez la machine virtuelle.

  8. Dans le Portail de gestion Azure, cliquez sur Machines virtuelles dans le volet de navigation, sur En cours d'exécution dans la colonne État pour la machine virtuelle, puis sélectionnez Capturer pour lancer l’Assistant. Vous pouvez maintenant utiliser cette image comme modèle pour les nouvelles machines virtuelles.

Pour plus d’informations sur la capture d’une image, consultez How to Capture an Image of a Virtual Machine Running Windows Server (Capture d'une image d'une machine virtuelle exécutant Windows Server)

Toutes les opérations que vous exécutez sur des machines virtuelles ou des réseaux virtuels dans Azure peuvent être automatisées en utilisant PowerShell. Pour plus d’informations, consultez Azure PowerShell et les exemples pour Azure PowerShell.

Pour obtenir des instructions détaillées pour la configuration de SharePoint avec SQL Server AlwaysOn dans Azure avec huit machines virtuelles, consultez Déploiement de SharePoint avec SQL Server AlwaysOn dans Azure.

Pour plus d’informations sur SharePoint 2013, consultez les ressources suivantes :

Afficher:
© 2014 Microsoft