Modifier

Exécuter une batterie de serveurs SharePoint Server 2016 hautement disponible dans Azure

Azure ExpressRoute
Azure Disques managés
Machines virtuelles Azure
Réseau virtuel Azure
Passerelle VPN Azure

Cette architecture de référence présente des pratiques éprouvées pour déployer une batterie de serveurs SharePoint Server 2016 hautement disponible sur Azure à l’aide de la topologie MinRole et de groupes de disponibilité Always On SQL Server. La batterie de serveurs SharePoint est déployée dans un réseau virtuel sécurisé sans aucun point de terminaison ou présence exposé à Internet.

Architecture

Architecture diagram that shows a highly available SharePoint Server 2016 farm in Azure.

Téléchargez un fichier Visio de cette architecture.

Cette architecture repose sur celle décrite dans l’article Exécuter des machines virtuelles Windows pour une application multiniveau. Elle déploie une batterie de serveurs SharePoint Server 2016 à haute disponibilité dans un réseau virtuel Azure. Cette architecture est adaptée à un environnement de test ou de production, une infrastructure hybride de SharePoint avec Microsoft 365, ou comme base pour un scénario de reprise d’activité après sinistre.

Composants

  • Les groupes de ressources sont des conteneurs qui contiennent des ressources Azure associées. Un groupe de ressources est utilisé pour les serveurs SharePoint et un autre groupe de ressources est utilisé pour les composants d’infrastructure qui sont indépendants des machines virtuelles, tels que le réseau virtuel et les équilibreurs de charge.

  • Le réseau virtuel Azure est le composant fondamental pour vos réseaux privés dans Azure. Les machines virtuelles sont déployées dans un réseau virtuel avec un espace d’adressage intranet unique. Le réseau virtuel est en outre subdivisé en sous-réseaux.

  • Les machines virtuelles sont des ressources informatiques évolutives à la demande et disponibles avec Azure. Les machines virtuelles sont déployées dans le réseau virtuel, les adresses IP statiques privées sont affectées à toutes les machines virtuelles. Les adresses IP statiques sont recommandées pour les machines virtuelles exécutant SQL Server et SharePoint Server 2016, afin d’éviter les problèmes liés à la mise en cache des adresses IP et les changements d’adresses après un redémarrage.

  • Les groupes à haute disponibilité sont des regroupements logiques de machines virtuelles. Placez les machines virtuelles pour chaque rôle SharePoint dans différents groupes de disponibilité et configurez au moins deux machines virtuelles pour chaque rôle. Cette configuration rend les machines virtuelles éligibles à un contrat SLA plus élevé.

  • Azure Load Balancer distribue le trafic de requête SharePoint du réseau local aux serveurs web front-end de la batterie de serveurs SharePoint. Cette solution utilise un équilibreur de charge interne. Comme alternative au trafic HTTP, Azure Application Gateway peut être utilisé.

  • Les groupes de sécurité réseau filtrent le trafic dans un réseau virtuel Azure. Pour chaque sous-réseau contenant des machines virtuelles, un groupe de sécurité réseau est créé. Utilisez des groupes de sécurité réseau pour limiter le trafic réseau au sein d’un réseau virtuel et pour isoler les sous-réseaux.

  • Azure ExpressRoute ou un VPN de site à site, tel que la passerelle VPN Azure, fournit une connexion entre votre réseau local et le réseau virtuel Azure. Pour plus d’informations, consultez Connecter un réseau local à Azure.

  • Les contrôleurs de domaine Windows Server Active Directory (AD) authentifient les utilisateurs au sein d’un domaine. Les contrôleurs de domaine de cette architecture de référence s’exécutent dans le réseau virtuel Azure et ont une relation d’approbation avec la forêt locale Windows Server AD. Les requêtes web des clients pour les ressources de la batterie de serveurs SharePoint sont authentifiées sur le réseau virtuel, au lieu d’envoyer le trafic d’authentification via la connexion de passerelle vers le réseau local. Des enregistrements sont créés dans DNS, intranet A ou CNAME, afin que les utilisateurs de l’intranet puissent résoudre le nom de la batterie de serveurs SharePoint à l’adresse IP privée de l’équilibreur de charge interne.

    SharePoint Server 2016 prend également en charge l’utilisation de Microsoft Entra Domain Services. Microsoft Entra Domain Services fournit des services de domaine managé, afin que vous n’ayez pas besoin de déployer ni de gérer les contrôleurs de domaine dans Azure.

  • Les groupes de disponibilité Always On fournissent une solution de haute disponibilité et de récupération d’urgence. Nous les recommandons pour une haute disponibilité de la base de données SQL Server. Deux machines virtuelles sont utilisées pour SQL Server. L’une contient le réplica de base de données primaire et l’autre le réplica secondaire.

  • Une machine virtuelle de nœud majoritaire permet au cluster de basculement d’établir le quorum. Pour plus d’informations, consultez Présentation des configurations de quorum dans un cluster de basculement.

  • SharePoint Server fournit une plateforme d’accès partagé. Les serveurs SharePoint effectuent le service web frontal, la mise en cache, l’application et la recherche des rôles.

  • Un serveur de rebond, également appelée hôte bastion, est une machine virtuelle sécurisée sur le réseau que les administrateurs utilisent pour se connecter à d’autres machines virtuelles. Le serveur de rebond a un groupe de sécurité réseau qui autorise le trafic distant provenant uniquement d’adresses IP publiques figurant sur une liste verte. Le groupe de sécurité réseau doit autoriser le trafic RDP (Remote Desktop).

Recommandations

Vos exigences peuvent différer de celles de l’architecture décrite ici. Utilisez ces recommandations comme point de départ.

Recommandations pour les groupes de ressources

Nous vous recommandons de séparer les groupes de ressources en fonction du rôle de serveur et d’avoir un groupe de ressources distinct pour les composants d’infrastructure qui sont des ressources globales. Dans cette architecture, les ressources SharePoint forment un groupe, alors que le serveur SQL Server et les autres composants de l’utilitaire en forment un autre.

Recommandations pour les réseaux virtuels et les sous-réseaux

Utilisez un sous-réseau pour chaque rôle SharePoint, ainsi qu’un sous-réseau pour la passerelle et un autre pour la jumpbox.

Le sous-réseau de passerelle doit être nommé GatewaySubnet. Attribuez l’espace d’adressage du sous-réseau passerelle à partir de la dernière partie de l’espace d’adressage du réseau virtuel. Pour plus d’informations, consultez Connecter un réseau local à Azure à l’aide d’une passerelle VPN.

Recommandations pour les machines virtuelles

Cette architecture nécessite au moins 44 cœurs :

  • 8 serveurs SharePoint sur Standard_DS3_v2 (4 cœurs chacun) = 32 cœurs
  • 2 contrôleurs de domaine Active Directory sur Standard_DS1_v2 (1 cœur chacun) = 2 cœurs
  • 2 machines virtuelles SQL Server sur Standard_DS3_v2 = 8 cœurs
  • 1 nœud majoritaire sur Standard_DS1_v2 = 1 cœur
  • 1 serveur d’administration sur Standard_DS1_v2 = 1 cœur

Pour tous les rôles SharePoint, à l’exception de l’indexeur de recherche, l’utilisation de la taille de machine virtuelle Standard_DS3_v2 est recommandée. L’indexeur de recherche doit être de taille Standard_DS13_v2 au minimum. Pour plus d’informations, consultez Configuration matérielle et logicielle requise pour une solution SharePoint Server 2016. Pour les machines virtuelles SQL Server, nous vous recommandons un minimum de 4 cœurs et 8 Go de RAM. Pour plus d’informations, consultez l’article Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server).

Recommandations de groupe de sécurité réseau

Nous vous recommandons d’avoir un groupe de sécurité réseau pour chaque sous-réseau contenant des machines virtuelles afin d’activer l’isolement des sous-réseaux. Si vous souhaitez configurer l’isolement de sous-réseaux, ajoutez des règles de groupe de sécurité réseau qui définissent le trafic entrant ou sortant autorisé ou refusé pour chaque sous-réseau. Pour plus d’informations, consultez Filtrer le trafic réseau avec les groupes de sécurité réseau.

N’attribuez pas de groupe de sécurité réseau au sous-réseau de passerelle, ou la passerelle cessera de fonctionner.

Recommandations de stockage

La configuration du stockage des machines virtuelles dans la batterie de serveurs doit correspondre aux meilleures pratiques appropriées, utilisées pour les déploiements locaux. Les serveurs SharePoint doivent avoir un disque distinct pour les journaux d’activité. Les serveurs SharePoint hébergeant les rôles des index de recherche nécessitent un espace disque supplémentaire pour stocker l’index de recherche. Pour SQL Server, la pratique courante consiste à séparer les données et les journaux d’activité. Ajoutez davantage de disques pour le stockage de sauvegarde de base de données et utilisez un disque distinct pour tempdb.

Pour une meilleure fiabilité, nous recommandons l’utilisation de disques managés Azure. Les disques managés assurent que les disques des machines virtuelles au sein d’un groupe à haute disponibilité sont isolés afin d’éviter des points de défaillance uniques.

Utilisez des disques managés Premium pour toutes les machines virtuelles SQL Server et SharePoint. Vous pouvez utiliser des disques managés standard pour le serveur de nœud majoritaire, les contrôleurs de domaine et le serveur d’administration.

Recommandations relatives à SharePoint Server

Avant de configurer la batterie de serveurs SharePoint, assurez-vous que vous avez un compte de service Windows Server Active Directory par service. Pour cette architecture, vous devez au minimum disposer des comptes au niveau du domaine suivants pour isoler les privilèges par rôle :

  • Compte de service SQL Server
  • Compte de configuration d’utilisateur
  • Compte de batterie de serveurs
  • Compte Search Service
  • Compte d’accès au contenu
  • Comptes de Pool d’applications web
  • Comptes de Pool d’applications de service
  • Compte de super utilisateur de cache
  • Compte de super lecteur de cache

Pour satisfaire à l’exigence de prise en charge pour un débit de disque de 200 Mo par seconde au minimum, assurez-vous de planifier l’architecture de recherche. Consultez Planifier l’architecture de recherche d’entreprise dans SharePoint Server 2013. Suivez également les instructions contenues dans Bonnes pratiques d’analyse dans SharePoint Server 2016.

De plus, stockez les données de composant de recherche sur un volume de stockage distinct ou sur une partition avec des performances élevées. Pour réduire la charge et améliorer le débit, configurez les comptes d’utilisateur de cache d’objets, qui sont requis dans cette architecture. Fractionnez les fichiers de système d’exploitation Windows Server, les fichiers programme SharePoint Server 2016 et les journaux de diagnostic sur trois volumes de stockage distincts ou sur des partitions avec des performances normales.

Pour plus d’informations sur ces recommandations, consultez Comptes d’administration et de service de déploiement initial dans SharePoint Server 2016.

Charges de travail hybrides

Cette architecture de référence déploie une batterie de serveurs SharePoint Server 2016 qui peut être utilisée comme environnement hybride SharePoint, c’est-à-dire pour étendre SharePoint Server 2016 à SharePoint Online. Si vous avez Office Online Server, consultez Prise en charge de Microsoft Office Web Apps et Office Online Server dans Azure.

Les applications de service par défaut de cette solution sont conçues pour prendre en charge les charges de travail hybrides. Vous pouvez déployer toutes les charges de travail hybrides SharePoint Server 2016 et Microsoft 365 sur cette batterie de serveurs sans changer l’infrastructure SharePoint, à une exception près : L’application du service de recherche hybride cloud ne doit pas être déployée sur les serveurs hébergeant une topologie de recherche existante. Par conséquent, une ou plusieurs machines virtuelles en fonction du rôle de recherche doivent être ajoutées à la batterie de serveurs pour prendre en charge ce scénario hybride.

Groupes de disponibilité SQL Server Always On

Cette architecture utilise des machines virtuelles SQL Server, car SharePoint Server 2016 ne peut pas utiliser Azure SQL Database. Pour prendre en charge la haute disponibilité dans SQL Server, nous recommandons d’utiliser des groupes de disponibilité Always On, qui spécifient un ensemble de bases de données qui basculent ensemble, ce qui les rend hautement disponibles et récupérables. Pour plus d’informations, consultez Créer le groupe de disponibilité et ajouter les bases de données SharePoint.

Nous recommandons également l’ajout d’une adresse IP d’écouteur au cluster, il s’agit de l’adresse IP privée de l’équilibreur de charge interne pour les machines virtuelles SQL Server.

Pour les tailles de machine virtuelle recommandées et d’autres recommandations relatives aux performances pour SQL Server s’exécutant dans Azure, consultez Bonnes pratiques pour les performances de SQL Server dans les machines virtuelles Azure. Suivez également les recommandations dans Bonnes pratiques pour SQL Server dans une batterie de serveurs SharePoint Server 2016.

Le serveur de nœud majoritaire devrait se trouver sur un ordinateur distinct des partenaires de réplication. Le serveur permet au serveur du partenaire de réplication secondaire dans une session de mode haute sécurité, de déterminer s’il faut initier un basculement automatique. Contrairement aux deux partenaires, le serveur de nœud majoritaire ne sert pas la base de données, mais au lieu de cela, il prend en charge le basculement automatique.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Extensibilité

Pour mettre à l’échelle les serveurs existants, modifiez la taille de machine virtuelle.

Avec la fonctionnalité MinRoles dans SharePoint Server 2016, vous pouvez effectuer un scale-out des serveurs basés sur le rôle de serveur et supprimer des serveurs à partir d’un rôle. Lorsque vous ajoutez des serveurs à un rôle, vous pouvez spécifier les rôles uniques ou l’un des rôles combinés. Si vous ajoutez des serveurs au rôle de recherche, toutefois, vous devez également reconfigurer la topologie de recherche à l’aide de PowerShell. Vous pouvez également convertir des rôles à l’aide de MinRoles. Pour plus d’informations, consultez Gestion d’une batterie de serveurs MinRole dans SharePoint Server 2016.

SharePoint Server 2016 ne prend pas en charge l’utilisation de groupes de machines virtuelles identiques pour la mise à l’échelle automatique.

Disponibilité

Cette architecture de référence prend en charge la haute disponibilité dans une région Azure, étant donné que chaque rôle dispose d’au moins deux machines virtuelles déployées dans un groupe à haute disponibilité.

Pour vous protéger contre une panne régionale, créez une batterie de serveurs de récupération d’urgence distincte dans une région Azure différente. Vos objectifs de délai de récupération (RTO) et les objectifs de point de récupération (RPO) déterminent la configuration requise. Pour plus d’informations, consultez Choisir une stratégie de reprise d’activité après sinistre pour SharePoint Server 2016. La région secondaire doit être une région jumelée avec la région primaire. En cas de panne étendue, la récupération d’une région est hiérarchisée pour chaque paire. Pour plus d’informations, consultez l’article Continuité des activités et récupération d’urgence (BCDR) : régions jumelées d’Azure.

Simplicité de gestion

Pour exploiter et maintenir les serveurs, les batteries de serveurs et les sites, suivez les pratiques recommandées pour les opérations SharePoint. Pour plus d’informations, consultez Opérations pour SharePoint Server 2016.

Les tâches à prendre en compte lors de la gestion de SQL Server dans un environnement SharePoint peuvent différer de celles généralement prises en compte pour une application de base de données. Une bonne pratique consiste à sauvegarder toutes les bases de données SQL chaque semaine avec des sauvegardes incrémentielles nocturnes. Sauvegardez les journaux d’activité des transactions toutes les 15 minutes. Une autre pratique consiste à implémenter des tâches de maintenance de SQL Server sur les bases de données lors de la désactivation de celles intégrées à SharePoint. Pour plus d’informations, consultez Planification et configuration de la capacité de SQL Server et du stockage.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Les comptes de service au niveau du domaine utilisés pour exécuter un serveur SharePoint 2016 nécessitent des contrôleurs de domaine Windows Server Active Directory ou Microsoft Entra Domain Services pour les processus de jonction de domaine et d’authentification. Toutefois, pour étendre l’infrastructure d’identité Windows Server Active Directory déjà en place dans l’intranet, cette architecture particulière utilise deux machines virtuelles comme contrôleurs de domaine réplica Windows Server Active Directory d’une forêt locale existante Windows Server Active Directory.

En outre, il est toujours conseillé de planifier le renforcement de la sécurité. Les autres recommandations sont les suivantes :

  • Ajouter des règles aux groupes de sécurité réseau pour isoler les sous-réseaux et les rôles.
  • N’affectez pas les adresses IP publiques aux machines virtuelles.
  • Pour la détection d’intrusion et l’analyse des charges utiles, envisagez d’utiliser une appliance virtuelle réseau devant les serveurs web frontaux à la place d’un équilibreur de charge interne Azure.
  • En option, utilisez les stratégies IPsec pour le chiffrement du trafic de texte en clair entre les serveurs. Si vous effectuez également l’isolement des sous-réseaux, mettez à jour vos règles de groupe de sécurité réseau pour autoriser le trafic IPsec.
  • Installez des agents de logiciels anti-programmes malveillants pour les machines virtuelles.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Utiliser la calculatrice de prix Azure pour estimer les coûts. Voici quelques facteurs pour optimiser les coûts de cette architecture.

Active Directory Domain Services

Envisagez d’utiliser Active Directory Domain Services en tant que service partagé entre plusieurs charges de travail pour réduire les coûts. Pour plus d’informations, consultez les tarifs d’Active Directory Domain Services.

Passerelle VPN

Le modèle de facturation est basé sur la durée pendant laquelle la passerelle est provisionnée et disponible. Reportez-vous aux prix de la passerelle VPN.

Tout le trafic entrant est gratuit. Tout le trafic sortant est facturé. Les coûts de la bande passante Internet sont appliqués au trafic VPN sortant.

Réseau virtuel

Le service Réseau virtuel est gratuit. Chaque abonnement est autorisé à créer jusqu’à 50 réseaux virtuels dans toutes les régions. Tout le trafic provenant d’un réseau virtuel est gratuit. La communication entre deux machines virtuelles dans le même réseau virtuel est donc gratuite.

Cette architecture repose sur celle déployée dans l’article Exécuter des machines virtuelles Windows pour une application multiniveau.

Pour plus d’informations, consultez la section sur les coûts dans Microsoft Azure Well-Architected Framework.

DevOps

Envisagez d’utiliser des groupes de ressources distincts pour les environnements de production, de développement et de test. Des groupes de ressources distincts simplifient la gestion des déploiements, la suppression des déploiements de tests et l’attribution des droits d’accès. D’une façon générale, placez les ressources dotées d’un même cycle de vie dans un même groupe de ressources. Utilisez le niveau Développeur pour les environnements de développement et de test. Pour réduire les coûts durant la préproduction, déployez un réplica de votre environnement de production, exécutez vos tests, puis arrêtez.

Utilisez les modèles Azure Resource Manager ou les modèles Azure Bicep pour la définition de l’infrastructure. Dans les deux cas, vous suivez la pratique de l’infrastructure en tant que code (IaC, Infrastructure as Code) pour déployer les ressources. Pour automatiser le déploiement de l'infrastructure, vous pouvez utiliser Azure DevOps Services ou d'autres solutions CI/CD. Le processus de déploiement est également idempotent, c’est-à-dire reproductibles pour obtenir les mêmes résultats. Azure Pipelines fait partie d'Azure DevOps Services et exécute des builds, tests et déploiements automatisés.

Structurez vos modèles de déploiement en suivant les critères de la charge de travail, identifiez des unités individuelles de travail et incluez-les dans son propre modèle. Dans ce scénario, au moins sept charges de travail sont identifiées et isolées dans leurs propres modèles : le réseau virtuel et la passerelle VPN Azure ; le serveur de rebond (jumpbox) de gestion ; les contrôleurs de domaine AD ; les machines virtuelles SQL Server ; le cluster de basculement, le groupe de disponibilité et les autres machines virtuelles restantes ; le nœud principal SharePoint ; le cache SharePoint et les règles de groupe de sécurité réseau. L’isolation des charges de travail facilite l’association des ressources spécifiques de la charge de travail à une équipe afin que cette dernière puisse gérer de manière indépendante tous les aspects de ces ressources. Cet isolement permet à DevOps d'effectuer une intégration et une livraison continues (CI/CD). Cette configuration permet également la mise en lots de vos charges de travail, à savoir le déploiement à différentes étapes et l’exécution de validations à chaque étape avant de passer à la suivante. Vous pourrez ainsi envoyer les mises à jour de vos environnements de production de manière hautement contrôlée et limiter les problèmes de déploiement imprévus.

Pensez à utiliser Azure Monitor pour analyser et optimiser les performances de votre infrastructure, et pour superviser et diagnostiquer les problèmes de réseau sans vous connecter à vos machines virtuelles.

Pour plus d'informations, consultez la section DevOps d'Azure Well-Architected Framework.

Étapes suivantes

Pour plus d’informations sur les différents éléments de l’architecture d’une solution, consultez les rubriques suivantes :