Planification de SQL Server AlwaysOn et de Microsoft Azure pour la récupération d’urgence SharePoint Server
**Sapplique à :**SharePoint Server 2013, SharePoint Server 2016
**Dernière rubrique modifiée :**2018-02-16
Utilisez SQL Server 2014, les groupes de disponibilité SQL Server 2016 Always On et Microsoft Azure afin de créer un environnement de récupération d’urgence hybride pour votre batterie de serveurs locale SharePoint Server 2016 et SharePoint Server 2013. Cet article décrit la procédure de conception et d’implémentation de cette solution.
La solution contenue dans cet article s’applique à ce qui suit :
SharePoint Server 2013
Microsoft Azure
SQL Server 2014 Enterprise
Windows Server 2012 R2Centre de données
SharePoint Server 2016 Enterprise
SQL Server 2014 avec Service Pack 1 (SP1)
SQL Server 2016 Enterprise edition
Windows Server 2012 R2
Windows Server 2016 Datacenter edition
Acknowledgments: Cette solution de récupération d’urgence SharePoint Server a été conçue, testée et écrite par Tejinder Rai (MCS). Elle associe les meilleures pratiques Microsoft à des expériences utilisateur réelles et pratiques. David Williams et Matthew Robertshaw ont également contribué de manière significative à cet article de par leur travail sur les tests de récupération et d’automatisation du basculement SQL Server.
Contenu de cet article :
-
Présentation de la récupération d'urgence hybride pour SharePoint Server
-
Architecture et description de la solution de récupération d'urgence
-
Éléments requis pour la solution de récupération d'urgence SharePoint
-
Exigences en matière de configuration pour les deux batteries de serveur
-
Présentation des exigences en matière de base de données : SQL Server AlwaysOn et SharePoint Server
-
Création des batteries de serveurs de test en six phases
-
Récupération et basculement d'une batterie de serveurs de test
-
Conclusion
-
Annexe
Présentation de la récupération d’urgence hybride pour SharePoint Server
La configuration d’un environnement de récupération d’urgence approprié peut être un processus coûteux et très compliqué. Elle nécessite une planification minutieuse pour déployer et tester une solution qui répond aux objectifs de votre entreprise et qui permet de remettre en fonctionnement votre environnement de production, ainsi que vos applications.
En matière de récupération d’urgence, SharePoint Server complique la tâche et requiert une planification, une conception et des tests soignés. Parmi les contraintes à prendre en compte figurent les différents types de basculement pris en charge par SQL Server pour les réplicas de groupe de disponibilité, ainsi que le fait que plusieurs bases de données SharePoint ne prennent pas en charge la validation asynchrone dans un réplica et qu’une action spéciale est requise pour récupérer ces cas particuliers.
SharePoint Server Récupération de la recherche
La recherche SharePoint est l’un des cas qui nécessitent une approche différente et des techniques spéciales pour la récupération dans un scénario d’urgence. Cela s’explique par le fait qu’il n’est pas possible de conserver la fidélité de la base de données pour l’index de recherche et le système de fichiers si vous utilisez des groupes de disponibilité AlwaysOn avec une validation asynchrone d’un réplica secondaire.
Vous devez maîtriser les quatre options de récupération d’urgence disponibles pour la recherche dans une batterie de serveurs SharePoint Server. Chaque option présente des avantages et des inconvénients. La meilleure option est choisie en fonction des exigences de récupération et de continuité des activités. Pour plus d’informations sur les options prises en charge, qui comprennent une option hybride pour la récupération du service de recherche dans une batterie de serveurs hébergée dans une instance de cloud public, voir Matière de reprise après sinistre et les stratégies de recherche de SharePoint 2016.
Critères de récupération d’urgence
Avant l’apparition des technologies cloud, les organisations devaient configurer et tenir à jour un centre de données secondaire servant d’environnement de secours capable d’exécuter des systèmes stratégiques en cas d’urgence. Les coûts liés à la création et au fonctionnement d’un centre de données secondaire dissuadaient de nombreuses organisations de configurer un environnement de récupération d’urgence pour SharePoint.
La disponibilité et la maturité des services de plateforme et de l’infrastructure cloud font de Microsoft Azure une solution viable et rentable pour remplacer un centre de données secondaire.
En plus des coûts de base liés à un centre de données secondaire, les entreprises doivent également déterminer les exigences en matière de récupération des systèmes critiques et de leurs données. Ces exigences sont déterminées en répondant aux deux questions suivantes :
Combien de temps l’entreprise peut-elle rester hors connexion avant d’être affectée par des pertes importantes ? Par exemple, il peut s’agir de pertes liées au chiffre d’affaires, à des relations professionnelles dégradées ou à la crédibilité.
Quelle quantité de données l’entreprise peut-elle se permettre de perdre avant que ces pertes ne soient trop importantes ? Outre l’exemple de la perte de connexion dans des entreprises, certains secteurs dépendent entièrement de l’utilisation des données.
Dans le domaine de la récupération d’urgence, ces critères sont quantifiés en tant qu’objectifs de délai de récupération (RTO) et qu’objectifs de point de récupération (RPO).
Notes
L’un des objectifs connexes est l’objectif de niveau de récupération (RLO). Cet objectif définit la granularité avec laquelle vous devez pouvoir récupérer des données : la batterie de serveurs entière, une application web, une collection de sites, un site, une liste, une bibliothèque ou un élément. Pour plus d’informations, voir Planifier la sauvegarde et la récupération dans SharePoint Server.
Le coût d’une solution de récupération d’urgence dépend de ces objectifs. En réalité, de meilleurs RTO et RPO vont coûter plus cher. L’objectif et le niveau de coût déterminent également l’environnement de récupération sélectionné. La terminologie du secteur pour trois environnements de récupération d’urgence de base est la suivante : reprise progressive, secours semi-automatique et serveur de secours. Il existe bien sûr des variations en fonction du secteur d’activité.
Pour plus d’informations sur les solutions de récupération d’urgence, voir Concepts relatifs à la haute disponibilité et à la récupération d’urgence dans SharePoint Server et Choisir une stratégie de récupération d’urgence pour SharePoint Server.
Cet article fournit une infrastructure que vous pouvez utiliser pour déployer une solution de récupération d’urgence hybride pour SharePoint Server.
Informations non comprises dans cet article
Les sujets suivants ne sont pas abordés dans cet article :
Création d’une continuité des activités et du plan de récupération d’urgence associé
Exigences de niveau de service pour les RTO et RPO
Évaluation des coûts en fonction des exigences de niveau de service
Procédure détaillée pour les opérations suivantes :
Configuration d’un cluster de basculement Windows Server (WSFC)
Mise en service d’un environnement Azure (comptes de stockage, réseaux virtuels, services cloud, groupes à haute disponibilité et machines virtuelles)
Configuration d’un tunnel VPN d’une batterie de serveurs locale vers un environnement de récupération Azure
Architecture et description de la solution de récupération d’urgence
Notre solution hybride utilise une topologie qui fournit une redondance intercontinentale en Amérique du Nord. Les batteries de serveurs de test suivantes sont déployées dans deux endroits :
Une batterie de serveurs de production locale exécutée dans un centre de données à Redmond (côte ouest).
Une batterie de serveurs de récupération déployée sur Microsoft Azure. Cette batterie de serveurs est hébergée dans un centre de données de l’est des États-Unis. Elle est configurée pour fonctionner comme un environnement de récupération de secours semi-automatique.
La solution décrite utilise des groupes de disponibilité SQL Server AlwaysOn en tant que solution de bout en bout qui fournit une haute disponibilité et une récupération du basculement d’urgence. En plus de fournir une haute disponibilité dans un environnement de production, SQL Server AlwaysOn améliore les RTO. En effet, les instances SQL Server dans le centre de données secondaire contiennent un réplica des bases de données du centre de données principal.
Les conditions et l’environnement de test sont conçus pour représenter le type de batterie de serveurs de production SharePoint et la solution de récupération d’urgence élaborés par les utilisateurs standard.
Architecture logique
La figure suivante (figure 1) présente l’architecture logique de cette solution et met en évidence l’utilisation de réplicas de groupes de disponibilité sur site et dans Azure.
Figure 1 - Architecture logique d’un environnement hybride
.png "This image shows the logical architecture for SharePoint Server 2013 hybrid disaster recovery. Read the following paragraph for more detials.")
Architecture détaillée
La figure suivante (figure 2) représente l’architecture détaillée d’une batterie de serveurs de test locale. La batterie de serveurs est configurée comme une batterie de serveurs hautement disponible avec recherche de contenu d’entreprise.
Notes
Toutes les étiquettes de diagramme reposent sur la convention d’affectation de noms utilisée pour créer et tester ce scénario de récupération d’urgence. Elles fournissent des points de référence pour l’article.
Figure 2 - Batterie de serveurs de production locale
.png "This image shows the SharePoint Server 2013 hybrid disaster recovery details on-premises architecture. For more information read the following paragraph.")
La figure suivante (figure 3) illustre la topologie détaillée de la batterie de serveurs de secours semi-automatique déployée dans Azure.
Figure 3 - Batterie de serveurs de récupération de secours semi-automatique
.png "This diagram shows the SharePoint Server 2013 hybrid disaster recovery detailed recovery architecture for the Azure environment. For more details read the following paragraph.")
Éléments requis pour cette solution de récupération d’urgence SharePoint Server
Utilisez les exigences suivantes comme guide pour commencer à planifier le déploiement de cette solution.
Infrastructure and general configuration
La liste suivante constitue un résumé des exigences en matière de configuration générale et d’infrastructure pour la batterie de serveurs locale et la batterie de serveurs de récupération :
Deux batteries de serveurs SharePoint Server. Une batterie de serveurs de production dans votre centre de données principal et une batterie de serveurs de secours semi-automatique qui utilise Azure comme centre de données secondaire. L’un des autres avantages offerts par Azure est qu’il n’est pas nécessaire d’utiliser du matériel identique dans les deux batteries de serveurs.
Chaque batterie de serveurs est en ligne dans les deux centres de données.
Versions de logiciel et niveaux de correctif. Les deux batteries de serveurs utilisent les mêmes versions de logiciel et niveaux de correctif pour :
Windows Server 2012 R2 ou Windows Server 2016
SQL Server 2014 ou SQL Server 2016
SharePoint Server 2016 ou SharePoint Server 2013
Les deux batteries de serveur sont configurées pour utiliser les mêmes comptes de service afin d’administrer SharePoint.
Les bases de données de contenu et celles d’application de service sont réparties dans un ou plusieurs groupes de disponibilité SQL Server.
Utilisez le mode de validation synchrone pour les réplicas dans l’environnement local. Il s’agit de la configuration de haute disponibilité classique pour une batterie de serveurs SharePoint, car elle prend en charge le basculement automatique et réduit au maximum la perte de données.
Utilisez le mode de validation asynchrone pour le réplica dans l’environnement de récupération. Bien que le basculement automatique ne soit pas pris en charge, le débit de données est généralement meilleur, ce qui peut être un facteur très important lorsque la distance entre les batteries de serveurs de production et de récupération est considérable.
Notes
Pour certains cas, la validation synchrone dans un réplica d’un environnement de récupération a été testée et implémentée, car le débit est le même qu’en cas d’utilisation de la validation asynchrone dans un réplica de récupération. Toutefois, cette pratique n’est pas largement acceptée ou recommandée.
Chaque batterie de serveurs dispose de ses propres applications de service qui comportent des bases de données synchronisées entre les deux environnements. Étant donné que les bases de données en lecture seule sont utilisées pour les applications de service dans la batterie de serveurs de récupération d’urgence, les applications de service n’ont pas besoin d’être remises en service lors du basculement de la batterie de serveurs de production.
Recherchez l’analyse avec des bases de données en lecture seule dans l’instance de récupération d’urgence. Si cela est obligatoire, vous devez configurer une application de service de recherche distincte pour la batterie de serveurs de récupération. Pour plus d’informations, voir Options de haute disponibilité et de récupération d’urgence prises en charge pour les bases de données SharePoint.
Conseil
Utilisez l’automatisation lorsque cela est possible. La configuration et le déploiement scriptés assurent la cohérence de la configuration et réduisent les erreurs causées par la saisie de commande ou la navigation via l’interface utilisateur pour configurer la batterie de serveurs.
Exigences obligatoires en matière de configuration pour les deux batteries de serveurs
Les technologies suivantes sont requises pour déployer la solution de récupération d’urgence décrite dans cet article :
Windows Server 2012 R2 ou Windows Server 2016
SharePoint Server 2016 ou SharePoint Server 2013 avec Service Pack 1 et la mise à jour cumulative de mai 2014
SQL Server 2014 ou SQL Server 2016
Une connexion sécurisée entre le centre de données principal et la batterie de serveurs de récupération dans Azure. Nous avons utilisé une connexion VPN, mais si ExpressRoute est disponible dans votre zone, vous pouvez l’utiliser.
Présentation des exigences en matière de base de données : SQL Server AlwaysOn et SharePoint Server
Le centre de données principal utilisera des réplicas de validation synchrone de groupes de disponibilité pour atteindre une haute disponibilité dans la batterie de serveurs principale. Le centre de données secondaire doit utiliser les réplicas de validation asynchrone. Ceci est dû à la latence sur le réseau entre les centres de données principal et secondaire. Il est important de surveiller la latence de relecture des mémoires tampon de journal sur la batterie de serveurs de récupération d’urgence pendant le test.
Dépendances, conditions préalables et meilleures pratiques
Passez en revue les dépendances, les conditions préalables et les meilleures pratiques suivantes avant de créer des batteries de serveurs de test.
Cluster de basculement Windows Server (WSFC)
Le cluster WSFC couvre deux centres de données. Tous les nœuds dans le centre de données local et dans l’environnement de récupération appartiennent au même cluster WSFC.
Configuration de SQL Server pour SharePoint
Créez des volumes SQL Server pour séparer les bases de données SQL, les bases de données de batterie de serveurs, les fichiers journaux de base de données, ainsi que les bases de données tempdb et les fichiers journaux correspondants.
Distribuez les bases de données de batterie de serveurs sur les volumes conformément à la vitesse de lecture/d’écriture. Définissez les priorités en les classant de la plus rapide à la plus lente pour obtenir la distribution classique suivante :
Fichiers journaux de transactions et de données tempdb
Fichiers journaux de transactions de base de données
Fichiers de base de données de recherche
Bases de données de contenu
Configurez les comptes pour le service SQL Server et le service SQL Agent.
Utilisez les configurations dans le tableau suivant lorsque vous déployez SQL Server pour les batteries de serveurs SharePoint.
| Composant | Paramètres |
|---|---|
Port |
Bloquez le port UDP 1434. Il est recommandé de bloquer le port TCP 1433 et de réaffecter le port utilisé par l’instance par défaut à un port différent. Toutefois, ceci n’est pas obligatoire. Assurez-vous que le numéro de port qui doit être affecté à l’instance par défaut ne fait pas partie des ports inscrits. Reportez-vous au registre de numéros de port de protocole de transport et de noms de service pour éviter d’utiliser le port inscrit. Veillez à suivre les instructions de sécurité suivantes dans Configurer la sécurité SQL Server pour SharePoint Server. Règles de pare-feu : créez des règles entrantes pour le port autre que celui par défaut utilisé par l’instance SQL Server. Masquer l’instance : masquez l’instance SQL Server sur les ordinateurs clients. |
Verrouillage de pages en mémoire |
Autorisez le compte de service SQL Server à verrouiller les pages en mémoire. Pour plus d’informations, voir Activer le verrouillage des pages en mémoire (Windows) et Mémoire du serveur (options de configuration de serveur). |
Désactivation de la création automatique des statistiques |
Do not pas la création automatique des statistiques sur SQL Server. Cette option n’est pas prise en charge pour SharePoint Server. Pour plus d’informations, voir Meilleures pratiques pour SQL Server dans une batterie de serveurs SharePoint Server. |
Définition du degré maximal de parallélisme |
Définissez le degré maximal de parallélisme (MAXDOP) sur 1 pour les instances SQL Server hébergeant les bases de données SharePoint Server hôtes. Notes L’installation de SharePoint Server sur SQL Server échoue automatiquement, sauf si le compte du programme d’installation dispose des autorisations permettant de la modifier. Pour plus d’informations, voir Meilleures pratiques pour SQL Server dans une batterie de serveurs SharePoint Server. |
Indicateurs de trace |
Ajoutez les indicateurs de trace 1222 (renvoyer des ressources et des types de verrous impliqués dans un blocage) et 3226 (supprimer les entrées de sauvegarde des journaux dans le journal des erreurs SQL). DBCC TRACEON (1222,-1) DBCC TRACEON (3226,-1) |
Historique des travaux SQLAgent |
Assurez-vous que SQLAgent possède ces paramètres (Jobhistory_max_rows = 50000 et Jobhistory_max_rows_per_job = 10000). |
Mémoire minimale |
Mémoire minimale = 512 Mo. (Toutefois, cette valeur repose sur notre configuration de test et peut ne pas s’appliquer à votre installation SQL Server. Vous devez donc calculer la valeur appropriée.) Pour plus d’informations, voir les articles relatifs à la mémoire du serveur (options de configuration de serveur) et à l’option de configuration du serveur de la mémoire minimale par requête. |
Mémoire maximale |
Définissez la mémoire maximale pour SQL Server d’après la formule suivante : Taille totale de RAM du serveur (Go) - 4 Go = [mémoire maximale du serveur] (14 - 4 = 10) Pour plus d’informations, voir l’article relatif à la mémoire du serveur (options de configuration de serveur). |
Alias DNS |
Nous vous recommandons de créer des alias DNS pour toutes les instances SQL Server. Ainsi, la maintenance est plus simple. Par exemple, vous pouvez déplacer plus facilement des bases de données vers un autre serveur. Par exemple, la batterie de serveurs SharePoint dans le centre de données de récupération d’urgence Azure se connecte directement aux noms d’instance SQL Server. Vous devez créer un alias DNS plutôt que de configurer la batterie de serveurs directement avec les noms d’instance. Notes L’alias client et l’alias DNS doivent correspondre afin de s’assurer que les clients qui n’utilisent pas d’alias client SQL peuvent également contacter des serveurs SQL. Pour plus d’informations, voir Meilleures pratiques pour SQL Server dans une batterie de serveurs SharePoint Server. |
Classement de bases de données |
Latin1_General_Cl_AS_KS_WS Le classement de base de données SQL Server doit être configuré de sorte à ne pas respecter la casse, mais à prendre en compte les accents, les kanas et la largeur. Cela permet de s’assurer que le caractère unique du nom de fichier est cohérent avec le système d’exploitation Windows. |
Éléments à prendre en compte et exigences en matière de conception
Chaque instance SQL Server qui fait partie d’un groupe de disponibilité AlwaysOn doit également faire partie du même cluster WSFC. Un groupe de disponibilité comporte un réplica principal, qui comporte les données les plus récentes, et des réplicas secondaires qui reçoivent des mises à jour à partir du réplica principal. Chaque réplica de disponibilité doit se trouver sur un nœud différent d’un cluster de basculement Windows Server (WSFC) unique. Tous les nœuds SQL Server, qui font partie d’un cluster de basculement Windows Server unique, doivent disposer de leur propre stockage, contrairement aux instances de cluster de basculement SQL Server.
Pour plus d’informations sur les conditions préalables, les restrictions, les recommandations et l’utilisation générale pour les groupes de disponibilité, voir :
Groupes de disponibilité AlwaysOn (SQL Server)
La figure suivante (figure 4) représente l’infrastructure de réplica de groupe de disponibilité utilisée pour les bases de données SharePoint.
Figure 4 - Infrastructure de réplica de groupe de disponibilité
.png "This image shows the distributeion of SharePoint databases on the AlwaysOn Availaability Groups. For more details read the paragraph below.")
Dans l’infrastructure illustrée dans la figure 4, une pratique courante consiste à placer les serveurs de base de données dans l’environnement de récupération sur un sous-réseau distinct, qui doit être pris en compte lors de la configuration des écouteurs WSFC et de groupe de disponibilité.
Vous devez également planifier et tester la latence du réseau entre la batterie de serveurs locale et l’environnement de récupération. La latence entre réplicas a une incidence sur votre objectif de point de récupération (RPO).
Enfin, envisagez de mettre en service les serveurs de base de données dans l’environnement de récupération dans leur propre service cloud Azure, ce qui correspond à la façon dont l’environnement de test a été créé. Les services cloud vous permettent de regrouper des rôles serveur afin de gérer des machines virtuelles Azure comme une entité unique. Pour plus d’informations, voir l’article Dois-je choisir les services cloud ou autre chose ?.
Comme dans SharePoint Server, il est plus facile de concevoir l’architecture au préalable, plutôt que de devoir concevoir à nouveau les services de plateforme d’Azure ultérieurement.
Types de basculement et modes de validation de groupes de disponibilité
Il est important que vous compreniez l’incidence des modes de validation sur les différents types de basculement pour chaque configuration de groupe de disponibilité, car ils auront une influence sur la récupération de la batterie de serveurs. Le tableau suivant est extrait de la documentation de SQL Server. Le tableau suivant résume les types de basculement pris en charge dans différents modes de basculement et de disponibilité. Pour chaque association, les modes de basculement et de disponibilité efficaces sont déterminés par l’intersection des modes des réplicas principaux plus les modes d’un ou de plusieurs réplicas secondaires. Pour plus d’informations, voir Basculement et modes de basculement (groupes de disponibilité AlwaysOn).
| Type de basculement | Mode de validation synchrone avec le mode de basculement automatique | Mode de validation synchrone avec le mode de basculement manuel | Mode de validation asynchrone |
|---|---|---|---|
Automatic failover |
Oui |
Non |
Non |
Planned manual failover |
Oui |
Oui |
Non |
Forced failover |
Oui* |
Oui |
Oui |
*****Si vous lancez une commande de basculement forcé sur un réplica secondaire synchronisé, celui-ci se comporte de la même façon qu’en cas de basculement manuel.
La durée d’indisponibilité de la base de données pendant un basculement dépend du type de basculement et de sa cause.
Options de haute disponibilité et de récupération d’urgence prises en charge pour les bases de données SharePoint
Les tableaux dans cette section résument les options de récupération d’urgence et de haute disponibilité prises en charge pour les bases de données SharePoint Server. Pour plus d’informations, voir Options de haute disponibilité et de récupération d’urgence prises en charge pour les bases de données SharePoint.
| Nom de la base de données | Haute disponibilité (prise en charge synchrone) | Récupération d’urgence (prise en charge asynchrone) |
|---|---|---|
SharePoint Config |
Oui |
Non |
SharePoint Admin Content |
Oui |
Non |
State Service |
Oui |
Non |
WSS Content X |
Oui |
Oui |
| Nom de la base de données | Haute disponibilité (prise en charge synchrone) | Récupération d’urgence (prise en charge asynchrone) |
|---|---|---|
App Management |
Oui |
Oui |
Business Connectivity Services |
Oui |
Oui |
Managed Metadata |
Oui |
Oui |
PerformancePoint |
Oui |
Oui |
PowerPivot |
Oui |
Oui |
Project (SharePoint Server 2013 uniquement) |
Oui |
Oui |
Secure Store |
Oui |
Oui |
Subscription Settings |
Oui |
Oui |
Machine Translation Services |
Oui |
Oui |
UPS Profile |
Oui |
Oui |
UPS Social |
Oui |
Oui |
UPS Sync |
Oui |
Non |
Usage |
Oui |
Non |
Word Automation |
Oui |
Oui |
| Nom de la base de données | Haute disponibilité (prise en charge synchrone) | Récupération d’urgence (prise en charge asynchrone) |
|---|---|---|
Search Admin |
Oui |
Non |
Search Crawl |
Oui |
Non |
Search Link Store |
Oui |
Non |
Search Analytics Store |
Oui |
Non |
Création des batteries de serveurs de test en six phases
Il existe plusieurs phases pour créer un environnement SharePoint qui fournit la haute disponibilité et la récupération d’urgence. Les étapes de configuration des batteries de serveurs locales et de récupération sont réparties selon les phases suivantes :
Phase de création 1 : configurez le cluster de basculement Windows Server et SQL Server AlwaysOn pour l’environnement local.
Phase de création 2 : installez et configurez SharePoint Server pour créer la batterie de serveurs locale.
Phase de création 3 : configurez le cluster de basculement Windows Server et SQL Server dans l’environnement de récupération.
Phase de création 4 : installez et configurez SharePoint Server pour créer la batterie de serveurs de récupération.
Phase de création 5 : terminez la configuration du point de terminaison de récupération et répliquez les bases de données dans la batterie de serveurs de récupération.
Phase de création 6 : Terminez la configuration de SharePoint Server sur la batterie de serveurs de récupération.
Tâches de préparation avant de commencer
Le tableau suivant répertorie les composants d’infrastructure clés pour ce scénario de récupération d’urgence. Nous avons identifié les conditions préalables et fourni des conseils concernant la configuration.
| Composant d’infrastructure | Remarques |
|---|---|
Contrôleur de domaine |
Pour notre environnement de test local, nous avons déployé un contrôleur de domaine et créé le domaine corp.adventureworks.com. Si vous décidez d’exécuter la preuve de concept de scénario de récupération d’urgence, vous pouvez utiliser le nom de domaine de votre organisation. Notes Après avoir configuré le domaine, nous avons également mis en service toutes les machines virtuelles que nous avons utilisées pour la batterie de serveurs et corrigé le système d’exploitation au même niveau. Il était plus simple de procéder ainsi, plutôt qu’étape par étape. |
Clustering de basculement 2016 Windows Server 2012 R2 et Windows Server 2016 |
Windows Server 2012 R2 ou Windows Server 2016 sur chaque batterie de serveurs configuré conformément aux meilleures pratiques (Windows Server et SharePoint Server). Pour plus d’informations, voir l’article Clustering de basculement Windows Server (WSFC) avec SQL Server. La fonctionnalité Cluster de basculement et la gestion du cluster de basculement MMC doivent être installées sur chaque serveur qui sera un nœud de cluster. Un partage de fichiers pour le quorum WSFC. Conformément aux meilleures pratiques, cela doit être configuré dans un site tiers accessible via le site local et le site de récupération. Documentez et tenez-vous en à une convention d’affectation de noms cohérente pour le cluster. |
Groupes de disponibilité AlwaysOn et configuration de la base de données SQL Server |
SQL Server 2014 ou SQL Server 2016 configuré conformément aux meilleures pratiques et aux exigences SharePoint identifiées dans la section « Dépendances, conditions préalables et meilleures pratiques ». Les bases de données utilisent un modèle de récupération complet. Pour plus d’informations, voir l’article Modèles de récupération (SQL Server). Noms d’instance SQL Server. (Nous avons utilisé le nom de l’instance par défaut, qui est pris en charge dans cette conception sur tous les nœuds de cluster.) Chemins d’accès au fichier identiques pour les emplacements de fichiers journaux et de base de données pour chaque instance SQL Server. Nous avons utilisé les configurations suivantes pour les lecteurs, (System (L:\) pour les bases de données SQL et SharePoint), (User (S:\) pour les fichiers journaux et les bases de données tempdb) et (Local disk (T:\) pour les sauvegardes SharePoint SQL). Documentez et tenez-vous en à une convention d’affectation de noms cohérente pour les groupes de disponibilité, les réplicas et les écouteurs. |
Réseau |
Nœuds de cluster : trois adresses IP de cluster statiques (deux pour la batterie de serveurs locale et une pour la batterie de serveurs de récupération). Écouteurs de groupe de disponibilité : une adresse IP statique pour chaque écouteur. (Notre batterie de serveurs de test utilise quatre écouteurs.) |
Serveur de passerelle Microsoft Azure |
Serveur dans Azure qui fournit le point de terminaison de la connexion à la passerelle VPN à partir de la batterie de serveurs locale. Il est configuré avec des rôles de services de Services de domaine Active Directory (AD DS) et de services DNS. En outre, il est désigné en tant que serveur de catalogue global pour le domaine de test (corp.adventureworks.com). En cas d’urgence, ce serveur peut devenir le contrôleur de domaine principal. |
Passerelle VPN |
Réseau privé virtuel de site à site ou ExpressRoute configuré entre le centre de données principal et l’abonnement Windows Azure dans lequel la batterie de serveurs de récupération d’urgence sera configurée. Pour plus d’informations, voir l’article Créer un VNet avec une connexion site à site à l’aide du portail classique (classique) et Créer et modifier un circuit ExpressRoute à l’aide de PowerShell (classique). |
Microsoft Azure et environnement de récupération
Les premières étapes de la création de l’environnement de récupération consistent à déployer un serveur dans Azure, puis à établir une connexion VPN ou ExpressRoute entre la batterie de serveurs locale et le serveur Azure.
Le service IaaS d’Azure présente de nombreux points communs avec un cloud privé local utilisant la virtualisation Windows Server Hyper-V et System Center Virtual Machine Manager (VMM). Toutefois, même les professionnels de l’informatique dotés d’une grande expérience en matière de cloud privé ont du mal à distinguer les différences.
La feuille de données relative à la Annexe dans l’annexe vous aidera à planifier, déployer et exécuter SharePoint Server 2016 dans l’environnement Azure. Elle ne remplace pas la documentation Azure et l’expérience pratique, mais elle vous guidera dans le monde Azure avec une perspective SharePoint. Pour plus d’informations sur les solutions de récupération d’urgence Azure, voir l’article Répliquer une application multiniveau SharePoint pour une récupération d’urgence avec Azure Site Recovery et Azure Site Recovery.
Phase de création 1
.png "This image shows the steps in Build Phase 1 to configure WSFC and AlwaysOn for the on-premises farm")
Le tableau suivant fournit plus d’informations sur les étapes de la phase de création 1.
| Étape | Remarques et instructions |
|---|---|
1. Configuration d’un cluster WSFC à deux nœuds |
Utilisez l’article Windows Server, Créer un cluster de basculement pour créer un cluster à deux nœuds. Pour des informations sur Windows Server 2016, voir l’article Clustering de basculement dans Windows Server 2016. |
2. Configuration d’un témoin de partage de fichiers |
La configuration par défaut pour WSFC dans un environnement SharePoint consiste à utiliser un témoin de partage de fichiers et un nœud majoritaire. Les deux nœuds de cluster dans la batterie de serveurs locale disposent d’un vote de quorum. Le nœud de cluster dans la batterie de serveurs de récupération ne dispose pas de vote. Pour plus d’informations, voir Configurer et gérer le quorum dans un cluster de basculement Windows Server 2012. Pour Windows Server 2016, voir l’article Déployer un témoin de cloud pour un cluster de basculement. Utilisez la cmdlet Microsoft PowerShell suivante pour configurer un quorum de nœud majoritaire et de partage de fichiers : Utilisez la cmdlet PowerShell suivante pour attribuer des votes : Pour configurer un témoin de cloud, utilisez la syntaxe PowerShell suivante : J’ai trouvé cette commande PS dans l’une des rubriques SQL 2016. Je l’ai donc ajoutée. Faites-moi savoir si elle n’est pas utile. |
3. Installation de SQL Server sur chaque nœud de cluster Windows |
Installez SQL Server sur les deux nœuds de cluster Windows Server. Notez les points suivants : Do not pas le programme de configuration de SQL Server pour un cluster de basculement. Ces nœuds ne font pas partie d’un cluster d’instances de cluster de basculement SQL. Assurez-vous que les chemins des données SQL Server sont identiques pour chaque instance. Pour plus d’informations, voir l’article Installer SQL Server 2014 à partir de l’assistant d’installation (Configuration) ou Installer SQL Server 2014 à partir de l’invite de commandes. Consultez également l’article Installer SQL Server à partir de l’assistant d’installation (Configuration). |
4. Activer SQL Server AlwaysOn |
Utilisez les conseils fournis dans l’article Activer et désactiver les groupes de disponibilité AlwaysOn (SQL Server) afin d’activer AlwaysOn. Utilisez les SQL Serverinstructions 2016 disponibles dans l’article Activer et désactiver les groupes de disponibilité Always On (SQL Server). La section relative au regroupement de bases de données figurant après ce tableau indique comment regrouper logiquement des bases de données SharePoint et les mettre en correspondance avec des groupes de disponibilité différents afin de répondre à vos exigences de récupération d’urgence et de disponibilité. |
5. Configuration de la sécurité du compte de batterie de serveurs |
Configurez les autorisations appropriées dans chaque instance SQL Server pour le compte d’administrateur de la configuration SharePoint. Ce compte doit appartenir au rôle db_owner et être attribué aux rôles de sécurité securityadmin et dbcreatorSQL Server pendant l’installation et la configuration. Pour plus d’informations, voir Configurer la sécurité SQL Server pour SharePoint Server et Autorisations de compte et paramètres de sécurité dans SharePoint Server 2016. |
6. Création de groupes de disponibilité, de points de terminaison AlwaysOn et d’écouteurs de groupe de disponibilité |
Créez les groupes de disponibilité pour le mode de validation synchrone pour la haute disponibilité. (Il est courant de configurer les groupes de disponibilité logiquement pour le basculement logique de bases de données.) Après avoir créé les points de terminaison AlwaysOn, créez des écouteurs de groupe de disponibilité afin d’activer la connectivité cliente avec chaque groupe de disponibilité. Notes Vous pouvez créer les groupes de disponibilité avec des noms de base de données temporaires afin que SharePoint puisse utiliser les écouteurs une fois la batterie de serveurs configurée. Ainsi, les chaînes de connexion à la base de données pointent vers les entrées DNS appropriées créées par les écouteurs Nul besoin de reconfigurer les écouteurs ultérieurement. Pour plus d’informations, voir Configurer des groupes de disponibilité AlwaysOn SQL Server pour SharePoint Server. Pour obtenir des informations, voir Créer un point de terminaison de mise en miroir de bases de données pour les groupes de disponibilité AlwaysOn (SQL Server PowerShell). Pour obtenir des informations sur SQL Server 2016, voir Mise en miroir de bases de données - Groupes de disponibilité AlwaysOn - PowerShell. Pour obtenir des informations, voir Écouteurs de groupe de disponibilité, connectivité client et basculement d’application (SQL Server). Pour des informations relatives à SQL Server 2016, voir Écouteurs, Connectivité client, Basculement de l’application. Notes Si vous créez les écouteurs de groupe de disponibilité à l’aide de SQL Server Management Studio, vous devez ajouter une adresse IP pour le sous-réseau de récupération d’urgence pour chaque écouteur. Ce n’est pas obligatoire si vous mettez en service les écouteurs de groupe de disponibilité à l’aide de la cmdlet SQL Server |
Regroupement de base de données pour la récupération d’urgence
Nous vous recommandons de regrouper les bases de données SharePoint et de les affecter à des groupes de disponibilité différents en fonction de vos exigences en matière de récupération d’urgence.
Cette opération est nécessaire, car chaque groupe de disponibilité dispose d’un réplica de validation synchrone sur site pour la haute disponibilité et d’un réplica de validation asynchrone dans l’environnement de récupération d’urgence.
Comme indiqué dans la section Options de haute disponibilité et de récupération d'urgence prises en charge pour les bases de données SharePoint, les bases de données qui prennent en charge la validation synchrone ne prennent pas forcément en charge les réplicas asynchrones. Le tableau suivant montre comment regrouper des bases de données pour des groupes de disponibilité AlwaysOn spécifiques.
| Nom du groupe de disponibilité | bases de données SharePoint ; |
|---|---|
AG_SPConfig* |
Configuration de SharePoint, contenu d’administration SharePoint, Service d’état et synchronisation de l’onduleur (AG synchrone uniquement) |
AG_SPContent |
WSS Content X |
AG_SPServices |
Gestion de l’application, Business Connectivity Services, Métadonnées gérées, PerformancePoint, PowerPivot, Service Banque d’informations sécurisé, Paramètres d’abonnement, Services de traduction automatique, Profil UPS et UPS Social, Word Automation et Utilisation (cette base de données prend en charge uniquement la validation synchrone, et, du fait qu’elle conserve les données temporaires qui sont utilisées pour l’exploration de données, nous vous déconseillons de répliquer ces données dans un scénario de récupération d’urgence.)** |
AG_SPSearch |
Administration de la recherche, Analyse de la recherche, Lien de la recherche et Rapports de l’analyse de la recherche |
* Ces noms sont donnés à titre d’exemple uniquement. Vous pouvez utiliser votre propre convention d’affectation de noms.
** La base de données d’utilisation peut être créée indépendamment sur chaque instance SQL Server dans le cluster. En plus du stockage de données temporaires, elle comporte également des transactions très élevées, ce qui constitue une autre raison de ne pas la placer dans un groupe de disponibilité. Vous pouvez utiliser la cmdlet Set-SPUsageApplication pour créer la base de données dans l’instance SQL secondaire. Utilisez ensuite la cmdlet Set-SPUsageApplication avec l’option -FailoverDatabaseServer pour spécifier l’instance SQL secondaire dans l’environnement hautement disponible.
Le tableau suivant décrit notre configuration de test à la fin de la première phase de création.
| Nom du serveur | Description |
|---|---|
DC2 |
Contrôleur de domaine |
SP-WFE1, SP-WFE2 |
Serveurs de contenu web |
SP-APP1 à SP-APP6 inclus |
Serveurs d’applications (par exemple, Administration centrale, services et recherche) |
SP-SQL-HA1, SP-SQL-HA2 |
Ces serveurs sont configurés comme deux nœuds dans notre cluster WSFC (SPDRCluster), chacun disposant d’un vote. Hébergent les bases de données de batterie de serveurs, configurées avec des groupes de disponibilité AlwaysOn. SP-SQL-HA1 est doté du rôle de réplica principal et SP-SQL-HA2 du rôle de réplica secondaire. Ces groupes de disponibilité et les écouteurs sont configurés : Availability groups = PROD-AG1, PROD-AG2, PROD-AG3, PROD-AG4; Listeners = SQL-PROD-AG1, SQL-PROD-AG2, SQL-PROD-AG3, SQL-PROD-AG4 |
FS1 |
Ce serveur fournit le quorum du cluster de partage de fichiers (Hybrid5SPDRClusterQuorum) pour le cluster WSFC. Il est également utilisé comme point de logiciel de distribution partagé pour la batterie de serveurs de test. |
OP-FILESERVER (facultatif) |
Ce serveur fournit un point de terminaison de service de réplication du système de fichiers DFS pour l’environnement local. L’autre point de terminaison se trouve dans notre environnement Azure. La réplication du système de fichiers DFS a deux objectifs. Tout d’abord, nous l’utilisons pour stocker des sauvegardes SQL Server (incrémentielles et complètes) qui sont écrites sur un serveur (AZSP-FS1) dans Azure. Nous avons ainsi voulu simuler le stockage hors site. De plus, dans un scénario d’urgence, nous pouvons utiliser ces sauvegardes pour restaurer la recherche SharePoint. La configuration de la réplication du système de fichiers DFS nous permet également de déplacer des fichiers entre les deux batteries de serveurs assez facilement. |
Phase de création 2
.png "This image shows the steps in Build Phase 2 to deploy SharePoint Server and create the on-premises farm")
Le tableau suivant fournit plus d’informations sur les étapes de la deuxième phase de création.
| Étape | Remarques et instructions |
|---|---|
1. Création de scripts de compilation |
Nous vous recommandons de développer un ensemble de scripts de compilation pour installer SharePoint Server 2016. Ces scripts peuvent également être utilisés pour générer la batterie de serveurs de récupération (et les futures batteries de serveurs SharePoint). Étant donné que la batterie de serveurs de récupération comportera des applications de service identiques à celles dans la batterie de serveurs locale, il est recommandé d’utiliser des noms de base de données et d’application de service identiques. L’écriture de scripts permet de réduire les erreurs de configuration et d’assurer la cohérence de la configuration de batterie de serveurs. Notes Les applications de service font référence à leurs bases de données par le nom de la base de données, contrairement aux bases de données de contenu, qui ont également un ID de base de données stocké dans la base de données de configuration de SharePoint. Il existe plusieurs exemples d’installations de SharePoint scriptées dont vous pourriez tirer parti dans votre environnement. Par exemple, AutoSPInstaller est un programme open source de bout en bout disponible sur Codeplex. Assurez-vous que les bases de données d’application de service, les bases de données de contenu et la base de données de configuration de la batterie de serveurs pointent vers l’alias de l’instance SQL Server utilisée. Les bases de données SharePoint Server 2016 seront créées avec une chaîne de connexion mise en correspondance avec l’instance SQL Server. Par la suite, elles seront déplacées vers des groupes de disponibilité à l’aide de cmdlets SharePoint ServerPowerShell. Une fois les bases de données de configuration de batterie de serveurs créées, nous vous recommandons d’écrire le script des tâches courantes suivantes : Associer un serveur SharePoint Server à la batterie de serveurs à l’aide de la cmdlet Inscrire des comptes gérés à l’aide de la cmdlet Créer des applications web Créer des collections de sites Créer des applications de service Définir le préfixe et le domaine de l’application SharePoint |
2. Installation des composants requis et des fichiers binaires |
Pour plus d’informations, voir Installer les composants requis pour SharePoint Server 2016 à partir d’un partage réseau. |
3. Configuration des collections de sites, des applications web et des paramètres SMTP de la batterie de serveurs |
Utilisez la cmdlet |
4. Configuration d’applications de service |
Utilisez les cmdlets d’application de service dans Index des applets de commande Windows PowerShell pour SharePoint Server 2016 pour configurer les applications de service. |
5. Ajout des bases de données de la batterie de serveurs de production locale à des groupes de disponibilité et synchronisation des réplicas |
Une fois la configuration de la batterie de serveurs terminée, ajoutez les bases de données de batterie de serveurs aux groupes de disponibilité appropriés. Utilisez les cmdlets PowerShell suivantes pour ajouter les bases de données et vérifier qu’elles ont été ajoutées au groupe de disponibilité indiqué : Important Assurez-vous que vous activez le mode de récupération complète sur toutes les bases de données à ajouter à un groupe de disponibilité avant de les ajouter. Synchronisez les réplicas de groupe de disponibilité. Pour plus d’informations, voir l’article Sélectionner la page de synchronisation des données initiales (Assistants du groupe de disponibilité AlwaysOn). |
Phase de création 3
.png "This image shows the steps in Build Phase 3 to configure WSFC and SQL Server in the recovery environment")
Le tableau suivant fournit plus d’informations sur les étapes de la troisième phase de création.
| Étape | Remarques et instructions |
|---|---|
1. Ajout de deux nœuds au centre de données de récupération d’urgence Azure qui étendront le cluster WSFC local |
Configurez ces paramètres sur le serveur qui sera le nouveau nœud de cluster. Installez la fonctionnalité de clustering de basculement Windows, testez le cluster et supprimez le vote de quorum à partir du nouveau nœud. Ouvrez la ligne de commande Windows PowerShell en tant qu’administrateur et exécutez la cmdlet suivante pour installer la fonctionnalité de clustering de basculement Windows et les outils de gestion : Testez le cluster avec la cmdlet suivante : Supprimez le vote de quorum du serveur avec les commandes suivantes : Pour plus d’informations, voir Configurer et gérer le quorum dans un cluster de basculement Windows Server 2012. Pour des informations sur Windows Server 2016, voir l’article Déployer un témoin de cloud pour un cluster de basculement. Notes Si vous utilisez la même architecture que notre environnement de test, vous devrez effectuer ces étapes de configuration sur les deux instances SQL Server dans l’environnement de récupération. |
2. Installation des instances SQL Server |
Installez SQL Server sur les deux nœuds. Assurez-vous que les chemins de données sont exactement identiques pour chaque instance SQL et que les configurations sont identiques. Par exemple, les configurations de port, le classement de bases de données, etc. Pour plus d’informations, voir l’article relatif à l’installation de SQL Server 2012 à partir de l’Assistant Installation (configuration). Voir également l’article Installer SQL Server à partir de l’assistant d’installation (Configuration). |
3. Activation des groupes de disponibilité SQL Server AlwaysOn |
Utilisez le gestionnaire de configuration SQL Server pour activer les groupes de disponibilité SQL Server AlwaysOn. Pour plus d’informations, voir Activer et désactiver les groupes de disponibilité AlwaysOn (SQL Server). Pour les instructions SQL Server 2016, voir Activer et désactiver les groupes de disponibilité Always On (SQL Server). Reportez-vous au tableau de la première phase de création pour consulter des exemples de regroupement logique de bases de données SharePoint Server 2016 dans des groupes de disponibilité. |
4. Configuration de la sécurité du compte de batterie de serveurs |
Configurez les autorisations appropriées dans chaque instance SQL Server pour le compte d’administrateur de la configuration SharePoint. Ce compte doit appartenir au rôle db_owner et être attribué aux rôles de sécurité securityadmin et dbcreatorSQL Server pendant l’installation et la configuration. Pour plus d’informations, voir Configurer la sécurité SQL Server pour SharePoint Server, Autorisations de compte et paramètres de sécurité dans SharePoint Server 2016 et Autorisations de compte et paramètres de sécurité dans SharePoint 2013. |
Phase de création 4
.png "This image shows the steps in Build Phase 4 to deploy SharePoint in Azure and create the recovery farm")
Le tableau suivant fournit plus d’informations sur les étapes de la quatrième phase de création.
| Étape | Remarques et instructions |
|---|---|
1. Création de scripts de compilation |
Nous vous recommandons de développer un ensemble de scripts de compilation pour installer SharePoint Server. Ces scripts peuvent également être utilisés pour générer la batterie de serveurs de récupération (et les futures batteries de serveurs SharePoint). Étant donné que la batterie de serveurs de récupération comportera des applications de service identiques à celles dans la batterie de serveurs locale, il est recommandé d’utiliser des noms de base de données et d’application de service identiques. L’écriture de scripts permet de réduire les erreurs de configuration et d’assurer la cohérence de la configuration de batterie de serveurs. Notes Les applications de service font référence à leurs bases de données par le nom de la base de données, contrairement aux bases de données de contenu, qui ont également un ID de base de données stocké dans la base de données de configuration de SharePoint. Il existe plusieurs exemples d’installations de SharePoint scriptées qui utilisent PowerShell. Par exemple, AutoSPInstaller est un programme open source de bout en bout disponible sur Codeplex. Assurez-vous que les bases de données d’application de service, les bases de données de contenu et la base de données de configuration de la batterie de serveurs pointent vers l’alias de l’instance SQL Server utilisée. Les bases de données SharePoint Server seront créées avec une chaîne de connexion mise en correspondance avec l’instance SQL Server. Par la suite, elles seront déplacées vers des groupes de disponibilité à l’aide de cmdlets SharePoint PowerShell. Une fois les bases de données de configuration de batterie de serveurs créées, nous vous recommandons d’écrire le script des tâches courantes suivantes : Associer un serveur SharePoint Server à la batterie de serveurs à l’aide de la cmdlet |
2. Installation des composants requis et des fichiers binaires |
Pour plus d’informations, voir Installer les composants requis pour SharePoint Server 2016 à partir d’un partage réseau. |
3. Configuration des collections de sites, des applications web et des paramètres SMTP de la batterie de serveurs |
Utilisez la cmdlet |
4. Configuration d’applications de service |
Utilisez les cmdlets d’application de service dans Index des applets de commande Windows PowerShell pour SharePoint Server 2016 pour configurer les applications de service. Notes Les applications de service sont créées dans la batterie de serveurs de récupération d’urgence, avec exactement le même nom que la batterie de serveurs principale. Vérifiez que la base de données porte exactement le même nom que dans la batterie de serveurs principale. En effet, la base de données sera référencée par les applications de service dans la batterie de serveurs de récupération d’urgence, où les bases de données d’application de service seront créées par la suite en tant que réplicas. Dans le cadre du processus, les bases de données dans la batterie de serveurs de récupération d’urgence seront restaurées à partir des réplicas principaux, si les réplicas asynchrones sont ajoutés au groupe de disponibilité SQL. Les bases de données de contenu dans la batterie de serveurs de récupération d’urgence peuvent être supprimées de la configuration SharePoint, car les bases de données de contenu de la batterie de serveurs principale comporteront un réplica en lecture seule dans l’instance SQL Server de récupération d’urgence. Utilisez SharePoint 2016 Management Shell pour exécuter la cmdlet PowerShell suivante afin de démonter des bases de données de contenu dans la batterie de serveurs de récupération d’urgence Si des bases de données de contenu supplémentaires sont présentes sur les instances SQL Server de la batterie de serveurs de récupération d’urgence, supprimez-les toutes. Vous pouvez utiliser l’une de ces méthodes, DROP DATABASE (Transact-SQL), Database.Drop Method () ou Supprimer une base de données. |
5. Arrêt de la batterie de serveurs |
Une fois la configuration de SharePoint terminée, arrêtez la batterie de serveurs. À présent, vous pouvez créer des réplicas asynchrones pour les bases de données sur la batterie de serveurs locale. |
Phase de création 5
.png "This image shows the steps in Build Phase 5 to finish configuring the Azure endpoint and replicate databases to the recovery farm")
Le tableau suivant fournit plus d’informations sur les étapes de la cinquième phase de création.
| Étape | Remarques et instructions |
|---|---|
1. Vérification de la disponibilité de l’accès aux partages de sauvegardes et à la base de données pour l’instance SQL |
Chaque nœud dans un groupe de disponibilité doit avoir accès à un emplacement de sauvegarde commun. Ceci est obligatoire pour l’amorçage de la base de données initiale pendant le processus d’ajout de réplicas au groupe de disponibilité. Le compte SQL Server doit avoir accès à l’emplacement de sauvegarde commun. |
2. Création d’un point de terminaison SQL Server et octroi d’autorisations de connexion à ce dernier |
Vous devez créer une connexion sur l’instance SQL Server de récupération d’urgence afin de créer un réplica secondaire et d’ajouter les bases de données aux groupes de disponibilité. Pour plus d’informations, voir Configurer des comptes de connexion pour la mise en miroir de bases de données ou les groupes de disponibilité AlwaysOn (SQL Server) et Configurer des comptes de connexion - Mise en miroir de bases de données ou groupes de disponibilité AlwaysOn. Un point de terminaison SQL Server est requis sur le réplica principal pour que l’instance SQL puisse envoyer des tampons du journal aux réplicas secondaires. Utilisez le processus de l’article Créer un point de terminaison de mise en miroir de base de données pour les groupes de disponibilité AlwaysOn (SQL Server PowerShell) et Mise en miroir de bases de données - Groupes de disponibilité AlwaysOn - PowerShell pour créer le point de terminaison. Vous devez autoriser l’accès au point de terminaison au compte de service sur l’instance SQL Server principale afin de transmettre les mémoires tampons de journal aux instances de récupération d’urgence. L’autorisation de connexion est obligatoire. Pour plus d’informations, voir GRANT – octroi d’autorisations de point de terminaison (Transact-SQL). |
3. Création de réplicas secondaires de bases de données d’application de service et de contenu de l’utilisateur dans l’instance de batterie de serveurs de récupération. |
Chaque groupe de disponibilité nécessite un réplica secondaire dans la batterie de récupération d’urgence. Vous devez être connecté à l’instance SQL qui héberge le réplica principal pour pouvoir créer le réplica secondaire. Pour plus d’informations, voir Ajouter un réplica secondaire à un groupe de disponibilité (SQL Server). |
4. Vérification de la configuration d’un accès en lecture seule pour les réplicas dans la batterie de serveurs de récupération |
Les réplicas de disponibilité dans les instances SQL Server de récupération d’urgence sont configurés en tant que réplicas secondaires pouvant être lus. La batterie de serveurs de récupération d’urgence accédera aux bases de données de contenu et d’application de service en lecture seule. Cela s’explique par le fait que la batterie de serveurs de récupération fait déjà référence aux noms de base de données d’application de service. Ainsi, le RTO est réduit lors du basculement vers l’environnement de récupération d’urgence. Notes Si cela n’est pas correctement configuré, vous pouvez rencontrer des erreurs dans l’environnement de récupération. |
5. Copie des connexions à partir de l’instance SQL Server principale vers les instances SQL Server secondaires |
Vous devez copier les mots de passe et les connexions SQL à partir de l’instance principale vers les instances secondaires. SQL Server copie uniquement le contenu d’une base de données de groupe de disponibilité. Les connexions et les mots de passe ne sont pas copiés d’une instance à une autre. Pour plus d’informations, voir Comment faire pour transférer des noms d’accès et des mots de passe entre instances de SQL Server 2005 et Dépanner des utilisateurs orphelins (SQL Server). |
Phase de création 6
.png "This image shows the steps in Build Phase 6 to finish configuring SharePoint for the recovery farm")
Le tableau suivant fournit plus d’informations sur les étapes de la sixième phase de création.
| Étape | Remarques et instructions |
|---|---|
1. Tirer parti de la batterie de serveurs de récupération |
Maintenant que les bases de données de contenu et d’application de service sont disponibles en lecture seule dans les instances SQL de la batterie de serveurs de récupération, vous pouvez démarrer la batterie de serveurs SharePoint. |
2. Montage des bases de données de contenu sur les applications web |
Pour chaque base de données de contenu disposant d’un réplica en lecture seule dans l’instance SQL de récupération d’urgence (comportant le contenu le plus récent dans la batterie de serveurs principale), la base de données doit être montée dans les applications web appropriées dans la batterie de serveurs de récupération d’urgence. Vous pouvez utiliser la cmdlet |
3. Actualisation de sites dans la base de données de configuration |
Il est recommandé d’actualiser les sites dans la base de données de configuration de SharePoint. Utilisez l’exemple PowerShell suivant pour actualiser les sites pour chaque base de données de contenu. |
4. Vérification des services de la batterie de serveurs |
Vérifiez que tous les services de la batterie de serveurs fonctionnent comme prévu. |
5. Contrôle de l’intégrité de la batterie de serveurs |
Effectuez des contrôles de l’intégrité sur la batterie de serveurs pour vous assurer que cette dernière est stable et qu’elle fonctionne correctement. |
Récupération et basculement d’une batterie de serveurs de test
Les procédures décrites dans cette section expliquent comment simuler le basculement d’une batterie de serveurs, puis sa récupération. Après la récupération, utilisez les procédures pour effectuer une restauration automatique vers la batterie de serveurs locale.
Les applications de service sur la batterie de serveurs de récupération d’urgence ont été créées dans le cadre du processus de génération. Étant donné que les applications de service seront récupérées à partir d’une panne de site complète, elles seront en mode d’écriture dans le site de récupération d’urgence puisque la récupération des groupes de disponibilité SQL dans les instances SQL de récupération d’urgence deviendra le réplica principal une fois le basculement de récupération d’urgence terminé. Le déplacement de données vers les instances SQL Server dans le centre de données principal cessera et sera mis en pause tant qu’il ne sera pas redémarré manuellement. Lorsqu’une instance SQL héberge un réplica de groupe de disponibilité, tous les autres réplicas sont considérés comme des réplicas secondaires dans le groupe de disponibilité.
Suivez les étapes ci-après pour récupérer la batterie de serveurs SharePoint dans l’environnement de basculement lorsque vous démarrez un basculement.
Étape 1 basculement
Une décision de récupération d’urgence est généralement prise en fonction des décisions de gestion des propriétaires de services et des équipes de gestion de la continuité des opérations. La décision de récupération d’urgence est généralement envisagée lorsque le site principal n’est plus accessible. Les procédures suivantes permettent d’effectuer un basculement de la batterie de serveurs principale vers la batterie de serveurs de récupération d’urgence.
Étape 2 basculement
Start a cluster and availability group failover
Effectuez un basculement du cluster et des groupes de disponibilité à l’aide des cmdlets PowerShell répertoriés dans la liste suivante.
Arrêtez le service de cluster à l’aide de
Stop-Service Clussvc.Démarrez le nœud de cluster et corrigez le quorum à l’aide de la commande suivante :
Start-ClusterNode -Name <ACTIVE SQL NODE> -FixQuorumDéplacez le groupe de clusters vers un nœud SQL actif dans le centre de données de récupération d’urgence à l’aide de la commande suivante.
Move-ClusterGroup -Cluster <CLIUSTER GROUP> -node <ACTIVE SQL NODE>Vérifiez que le service de cluster est démarré à l’aide de la commande suivante.
Get-ClusterNode -Name "<NodeName>"Réglez les droits de vote pour le cluster. Des droits de vote de quorum doivent être affectés à tous les nœuds SQL Server dans le site de récupération d’urgence. Répétez la commande suivante pour chaque nœud de cluster dans le centre de données de récupération d’urgence.
(Get-ClusterNode -Name "NodeName").NodeWeight=1 Get-ClusterNode | fl Name, NodeWeightUne fois qu’un vote pour le quorum a été accordé au nœud, utilisez la commande suivante pour supprimer les votes des deux nœuds dans la batterie de serveurs locale.
(Get-ClusterNode -name "Node1").NodeWeight=0 (Get-ClusterNode -name "Node2").NodeWeight=0Utilisez la commande suivante pour vérifier les paramètres de poids du nœud.
Get-ClusterNode | fl Name,NodeWeightUne fois les poids de nœud appliqués, les groupes de disponibilité peuvent être déplacés vers les instances SQL Server appropriées dans la batterie de serveurs de récupération d’urgence à l’aide de la cmdlet SQL Server
Switch-SqlAvailabilityGroup. Vous devez utiliser le paramètre-AllowDataLosslorsque vous exécutez cette cmdlet. Par exemple :Switch-SqlAvailabilityGroup -Path SQLSERVER:\Sql\<SQLNODE>\<MSQLINSTANCE>\AvailabilityGroups\<AGName> -AllowDataLossEffectuez cette opération pour chaque groupe de disponibilité.
Pour plus d’informations, voir Exécuter un basculement manuel planifié d’un groupe de disponibilité (SQL Server).
Étape 3 basculement
SharePoint Content Databases
Montez toutes les bases de données de contenu SharePoint supplémentaires qui ne faisaient pas partie de la configuration de batterie de serveurs d’origine. Les bases de données de contenu supplémentaires ont probablement été créées depuis le déploiement initial et ajoutées à un groupe de disponibilité.
Important
Dans le cadre d’un processus opérationnel, il est très important que toute base de données de contenu créée dans la batterie de serveurs principale soit ajoutée aux groupes de disponibilité et montée dans la batterie de serveurs de récupération d’urgence.
Utilisez la cmdlet Mount-SPContentDatabase pour monter les vases de données de contenu.
Il est recommandé d’actualiser les sites dans la base de données de configuration de SharePoint. Pour chaque base de données de contenu, utilisez le code suivant pour actualiser les sites dans la base de données de configuration. Ainsi, vous êtes certain que le plan du site est à jour.
# Refresh sites in the configuration database
Get-SPContentDatabase -WebApplication http://webapplicationsitename | | ForEach {
Write-host "Refreshing sites in configuration database for database: " $_.Name
$_.RefreshSitesInConfigurationDatabase()
}
Étape 4 basculement
Service Applications
Connectez-vous en tant que membre du groupe SharePoint Administrateurs de batterie de serveurs et effectuez les tâches suivantes :
Vérifiez que les applications de service sont accessibles.
Démarrez le service de synchronisation de profil utilisateur sur un serveur dans la batterie de serveurs de récupération d’urgence.
Effectuez une importation complète des profils utilisateur.
Notes
-
Il se peut que le Service Banque d’informations sécurisé exige de l’administrateur de batterie de serveurs SharePoint d’actualiser la clé afin de déchiffrer les applications inscrites dans la Banque d’informations sécurisée. L’administrateur doit disposer des autorisations complètes sur la Banque d’informations sécurisée avant d’actualiser la clé. (Vous pouvez également utiliser la cmdlet
Update-SPSecureStoreApplicationServerKeypour mettre à jour la clé de la banque d’informations sécurisée.) -
Le travail du minuteur Synchronisation de profil utilisateur doit être réactivé et les importations de profil doivent être planifiées. Étant donné qu’après un basculement les bases de données sont en mode d’écriture, les importations doivent être planifiées en conséquence.
Étape 5 basculement
Configure DNS Redirection
Mettez à jour DNS afin de fournir les redirections suivantes :
Vers la batterie de serveurs de récupération pour les applications web et les collections de sites.
Vers la batterie de serveurs de récupération pour le domaine d’application.
Étape 6 basculement
Validate the recovery
Exécutez des scénarios de test dans votre environnement pour vous assurer que la récupération se déroule comme prévu.
Après avoir validé la récupération, effectuez les actions suivantes :
Activez le travail de minuteur Service de synchronisation de profil utilisateur.
Planifiez une sauvegarde complète de la batterie de serveurs de récupération.
Étape 7 basculement
Send out notifications
Une fois la validation de la récupération terminée, informez-en les parties prenantes concernées.
Conclusion
Après avoir effectué le basculement et validé la récupération, vous êtes prêt à démarrer la configuration de la batterie de serveurs en satisfaisant les exigences opérationnelles actuelles et futures (par exemple, la capacité et la haute disponibilité). Ces exigences sont déterminées par la durée du temps d’arrêt et de la récupération de la batterie de serveurs dans le centre de données local.
Pour terminer, vous devez examiner et valider votre plan de restauration automatique vers la batterie de serveurs locale lorsque celle-ci fonctionne à nouveau.
Annexe
Appendix 1: Getting started in Microsoft Azure
| Élément | Remarques |
|---|---|
Comptes de stockage et abonnements Azure |
Vous aurez besoin, au minimum, d’un abonnement pour créer la batterie de serveurs de récupération Azure. Lorsque vous disposez d’un abonnement, vous pouvez créer jusqu’à 100 comptes de stockage nommés de manière unique. Comme pour les autres services Azure, il existe des comptes de stockage standard et premium. Pour plus d’informations, voir Introduction à Microsoft Azure Storage. |
Services de cloud |
Lorsque vous créez le serveur pour la passerelle VPN, un service de cloud est créé pour la machine virtuelle. À ce stade, vous devez déterminer le nombre de services de cloud dont vous souhaitez disposer pour la batterie de serveurs de récupération. Bien sûr, il n’est pas nécessaire d’avoir un service de cloud pour chaque serveur dans la batterie de serveurs ; mais faut-il en utiliser un ou plusieurs ? Il existe des arguments solides en faveur des deux options. En regroupant les machines virtuelles dans des services de cloud distincts, vous pouvez travailler avec plusieurs serveurs sous forme d’une seule unité. Dans notre batterie de serveurs de test, nous avons utilisé quatre services de cloud. Le premier pour la passerelle VPN, puis un service de cloud pour chacun des niveaux suivants : serveurs web frontaux, serveurs d’applications et serveurs de base de données. Pour plus d’informations, voir l’article relatif à la décision concernant le choix d’un service de cloud. |
Réseau |
Les réseaux virtuels sont importants dans ce scénario de récupération d’urgence. Pour plus d’informations, voir la documentation relative au réseau virtuel. |
PowerShell |
Les cmdlets PowerShell Azure peuvent vous aider à automatiser les tâches dans votre environnement virtuel. Pour plus d’informations, voir Cmdlets Windows Azure PowerShell (v2.2.2). |
Automation |
Azure prend en charge l’utilisation de Runbook pour automatiser une large variété de tâches de mise en service et de gestion. Pour plus d’informations, voir Prise en main d’Azure Automation. |
Machines virtuelles, redimensionnement de machines |
Les machines virtuelles Azure sont disponibles dans plusieurs gammes qui présentent des caractéristiques de performance et de capacité différentes. Vous pouvez combiner et mettre en correspondance des machines en fonction de vos charges de travail et de vos niveaux de batterie de serveurs. Pour plus d’informations, voir Tailles de machines virtuelles Windows dans Azure. |
Groupes à haute disponibilité |
L’utilisation de groupes à haute disponibilité est recommandée, car cela permet de s’assurer que les machines virtuelles dans un groupe (au nombre minimal de deux) sont hébergées sur des racks différents pour la haute disponibilité. Leur utilisation est également requise si vous voulez tirer parti du contrat SLA Azure. En plus de la gestion de la disponibilité de vos machines virtuelles, les groupes à haute disponibilité fonctionnent avec l’équilibrage de charge et la mise à l’échelle du support pour un groupe de serveurs. Notes SharePoint Server 2016 ne prend pas en charge la montée ou la descente en puissance automatique des serveurs de la batterie. Pour plus d’informations, voir Gérer la disponibilité des machines virtuelles Windows dans Azure. |