Partager via


Étapes de mise à jour corrective sans temps d’arrêt de SharePoint Server

S’APPLIQUE À :no-img-132013 oui-img-162016 oui-img-192019 oui-img-seÉdition d’abonnement no-img-sopSharePoint dans Microsoft 365

La mise à jour corrective sans temps d’arrêt (ZDP) est disponible dans SharePoint Server 2016, SharePoint Server 2019 et SharePoint Server Édition d’abonnement. Laissez les utilisateurs continuer à travailler sur, enregistrer et rechercher des documents à mesure que vous corrigez votre batterie de serveurs SharePoint Server.

La mise à jour corrective sans temps d’arrêt est une méthode de mise à jour corrective et de mise à niveau développée dans SharePoint dans Microsoft 365. Elle permet aux administrateurs de corriger le service pendant que les utilisateurs continuent à utiliser leurs abonnements. Autrement dit, cette méthode testée est conçue pour permettre la mise à jour corrective pendant que des personnes utilisent activement leurs fichiers, recherchent des analyses et affichent des résultats sur la batterie de serveurs SharePoint Server. C'est la signification de « sans interruption ».

Voici quelques remarques concernant la correction sans interruption (ces éléments seront présentés plus loin dans cet article).

Il est important de se rappeler que l'objectif de ZDP est de maintenir la disponibilité pour vos utilisateurs. Par conséquent, dans cet article, toutes les décisions relatives à la mise à jour corrective et au redémarrage de votre batterie de serveurs seront effectuées dans cette optique.

Importante

Même si tous les serveurs de votre batterie de serveurs SharePoint Server ont été configurés pour utiliser le rôle « Personnalisé », vous pouvez toujours configurer manuellement une batterie de serveurs hautement disponible. Il existe des articles qui vous aideront à construire des batteries de serveurs hautement disponibles, et les principes de tolérance de panne (disposer d’un matériel redondant) et de haute disponibilité (avoir des systèmes et des logiciels en place pour prendre en charge le basculement et la continuité de la durée de fonctionnement) sont les mêmes. N’oubliez pas que dans les batteries de serveurs hautement disponibles ou personnalisées plus complexes, vous devez prendre un soin particulier pour corriger les serveurs de recherche d’une manière qui prend en charge la haute disponibilité, par exemple, corriger un réplica d’index à la fois et ne jamais corriger ou mettre à niveau les réplicas d’index à partir de la même partition en même temps.

Processus ZDP

Cet exemple utilise ZDP sur une configuration de batterie de serveurs SharePoint Server à l’aide de MinRole. L'exemple d'environnement ressemble à ce qui suit :

The environment for this article has 8 servers: 4 required server roles in column 1 (SPWeb01, SPApp01, SPDch01, SPSrch01) and 4 redundant server roles in column 2 (SPWeb02, SPApp02, SPDch02, SPSrch02).

Pour décomposer cette structure, deux sites web frontaux (WFE) (SPWeb01 et 02) sont connectés à un équilibrage de charge, les deux présentent des demandes à ce stade. Il existe deux serveurs d'applications (SPApp01 et 02), deux serveurs de cache distribué (SPDCH01 et 02) et deux serveurs de recherche (SPSRCH01 et 02). Derrière cette structure, mais pas directement inclus dans le processus ZDP, se trouve un cluster SQL Server (par exemple, SQL Server Always-On).

D'un point de vue idéologique, vous pouvez tracer un trait au milieu de la batterie de serveurs dans ce diagramme, de haut en bas. D'un côté de la ligne se trouvent tous les serveurs se terminant par '01' (colonne 1), et de l'autre côté se situent les serveurs redondants dans '02' (colonne 2). Nous allons utiliser cette construction double afin que la batterie de serveurs reste en marche pour les utilisateurs pendant la mise à jour corrective.

La plupart du temps, tout ce que vous réalisez d'un côté de la ligne (sur les serveurs 01) doit être répété sur 02. Parmi toutes les étapes du processus ZDP à deux phases relativement simples, celles prises avec les WFE (SPWeb01 et 02) sont les plus complexes. Nous allons commencer par là.

Notes

Des informations générales sur les mises à jour logicielles pour SharePoint Server sont disponibles ici. Notez que l’article est lié à la documentation sur les paramètres d’autorisations pour SharePoint Server. Consultez ces articles si besoin et gardez à l'esprit qu'une partie de la mise à jour corrective implique des mises à jour de la base de données. Si vous avez modifié les autorisations SQL Server pour les comptes SharePoint après l'installation, par exemple, vous devrez passer en revue ces articles.

Assurez-vous que vous avez redémarré et testé vos WFE avant de les extraire de l'équilibrage de charge afin d'éviter des situations dans lesquelles le WFE à corriger en premier quitte la rotation et d'autres WFE ne gèrent pas la charge résultante. Tous les serveurs dans la batterie de serveurs doivent être actualisés à partir d'un redémarrage et en bon état de marche avant la mise à jour corrective. Envisagez également d'arrêter les analyses de recherche et les importations de profils pendant la période de mise à niveau ou de mise à jour corrective.

Importante

L'exécution côte-à-côte garantit que tous les sites web frontaux dans la batterie de serveurs traitent le même contenu statique pendant la mise à niveau, même si les fichiers statiques sur un WFE donné sont mis à niveau ou remplacés. Côte à côte est intégré à PSCONFIG, mais doit être activé. Cette fonctionnalité vérifie que les utilisateurs ont la même expérience des sites lors de la navigation sur SharePoint et l'utilisation de leurs fichiers, même quand vous modifiez ou mettez à jour des fichiers du système de fichiers.

Pour activer la fonctionnalité côte à côte, exécutez le script PowerShell suivant une seule fois en utilisant l’URL de l’une des applications web de contenu :

$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()

À compter de KB3178672 (mise à jour de mars 2017) pour SharePoint Server 2016 et versions ultérieures, PSCONFIG copie automatiquement tous les fichiers .js, .css et .htm dans le 16-HIVE\TEMPLATE\LAYOUTS16-HIVE\TEMPLATE\LAYOUTS\<NEW BUILD NUMBER> dossier, nécessaires pour pouvoir basculer vers les nouveaux fichiers d’interface utilisateur et terminer le processus côte à côte, comme décrit plus loin dans cette rubrique dans phase 2 - Mise à niveau PSCONFIG (4).

Phase 1 - Installation du correctif

La première phase consiste à récupérer les fichiers binaires correctifs sur les serveurs et à les installer là.

  1. L’étape 1 du processus ZDP est affichée dans une illustration.

    Sortez le premier site web frontal (SPWeb01) de l'équilibrage de charge et corrigez-le avec les packages « STS » et « WSS ».
    Redémarrez le serveur une fois la mise à jour corrective terminée.
    Remettez le serveur en rotation dans l'équilibreur de charge.

  2. Étape 2 du processus ZDP.

    Sortez le deuxième site web frontal (SPWeb02) de l'équilibrage de charge et corrigez-le avec les packages « STS » et « WSS ».
    Redémarrez le serveur une fois la mise à jour corrective terminée.
    Laissez ce serveur hors de l'équilibrage de charge jusqu'à ce que l'intégralité de la mise à niveau soit terminée.

    Notes

    Si vous n’exécutez pas la mise à niveau lors d’une période de maintenance et que la batterie de serveurs présente une charge importante, vous pouvez renvoyer ce site web frontal vers l’équilibrage de charge réseau jusqu’à ce que vous soyez prêt à exécuter PSCONFIG.

  3. L’étape 3 du processus ZDP est affichée dans une illustration.

    Pour chaque serveur SPApp, SPDCH et SPSRCH dans la colonne 1, corrigez avec les packages « STS » et « WSS ».
    Redémarrez-les une fois l'opération terminée. (Le travail envoyé par SPWeb01 se trouve sur les serveurs dans la colonne 2).

  4. L’étape 4 du processus ZDP est affichée dans cette illustration.

    Répétez maintenant la procédure de mise à jour corrective et de redémarrage pour la colonne 2. Pour chaque serveur SPApp02, SPDCH02 et SPSRCH02 dans la colonne 2, corrigez avec les packages « STS » et « WSS ».
    Redémarrez-les une fois l'opération terminée. (Comme vous pouvez le voir, le travail envoyé par SPWeb01 se trouve maintenant sur des serveurs de la colonne 1.)

Phase 2 - Mise à niveau PSCONFIG

Les correctifs sont installés sur chaque nœud de la batterie de serveurs SharePoint Server et tous ont été redémarrés. Il est temps d'effectuer la mise à niveau de build à build.

Notes

[!REMARQUE] Au cours du processus ZDP, vous pouvez exécuter Upgrade-SPContentdatabase pour réduire le temps global nécessaire pour terminer l'exécution de PSCONFIG. Envisagez cette option si vous avez un grand nombre de bases de données ou si vous sélectionnez de grandes bases de données.

  1. L’étape 5 du processus ZDP est affichée dans un graphique.

    Revenez au WFE qui n’a plus de rotation à charge équilibrée (SPWeb02), ouvrez SharePoint Management Shell et exécutez la commande PSCONFIG suivante :

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
    

    Une fois la commande terminée, renvoyez le WFE (SPWeb02) vers l'équilibrage de charge. Ce serveur est entièrement corrigé et mis à niveau.

    Conseil

    [!CONSEIL] La dernière étape du processus PSCONFIG garantit que les mises à jour de l'interface utilisateur (IU) sont copiées à partir du dossier /Dispositions vers un dossier propre à la version. Cela fait partie de la mise à jour de l’interface utilisateur côte-à-côte qui permet aux utilisateurs naviguant dans votre batterie de serveurs d’utiliser l’interface utilisateur tant que la mise à niveau n’est pas terminée et que vous n’êtes pas prêt à basculer vers la nouvelle interface.
    Pour vous assurer que la copie côte-à-côte a réussi, vérifiez le fichier journal associé. Par défaut, il se trouve sous :
    C :\program files\common files\Microsoft shared\web server extensions\16\logs. (Votre lettre de lecteur racine peut varier.)
    Si, pour une raison quelconque, PSCONFIG n’a pas correctement copié les fichiers d’interface utilisateur, exécutez cette commande pour les copier manuellement Copy-SidebySideFiles !

  2. L’étape 6 du processus ZDP est illustrée dans cette illustration.

    Supprimez SPWeb01 de l'équilibrage de charge. > Ouvrez SharePoint Management Shell et exécutez la même commande PSCONFIG :

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install  
    

    Renvoyez ce WEF (SPWeb01) vers l'équilibrage de charge. Il est également entièrement corrigé et mis à niveau maintenant.

    Les deux WFE sont corrigées et mises à niveau. Passez au reste de la batterie de serveurs, mais assurez-vous que les commandes Microsoft PowerShell requises sont exécutées un serveur à la fois et non en parallèle. Cela signifie que, pour l’ensemble de la colonne 1, vous allez exécuter les commandes un serveur à la fois. Ensuite, vous les exécuterez, un serveur à la fois, pour les serveurs de la colonne 2 sans chevauchement. L’objectif final est de préserver la durée d’activité. L’exécution des commandes PSCONFIG en série est le moyen le plus sûr et le plus prévisible de terminer le processus ZDP. C’est donc ce que nous allons faire.

  3. L’étape 7 du processus ZDP est affichée dans cette illustration.

    Pour tous les serveurs restants dans la colonne 1 (SPApp01, SPDCH01, SPSRCH01), exécutez la même commande PSCONFIG dans SharePoint Management Shell. Faites-le sur chaque serveur, un à la fois, jusqu'à ce que tous les serveurs de la colonne 1 soient mis à niveau.

    Importante

    N'oubliez pas de correctement supprimer le cache distribué avant d'exécuter PSCONFIG et ajoutez de nouveau le cache distribué au serveur une fois l'opération terminée.

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
    
  4. L’étape 8 du processus ZDP est affichée dans cette illustration.

    Pour tous les serveurs restants dans la colonne 2 (SPApp02, SPDCH02, SPSRCH02), exécutez la même commande PSCONFIG dans SharePoint Management Shell. Faites-le sur chaque serveur, un à la fois, jusqu'à ce que tous les serveurs de la colonne 2 soient mis à niveau.

    Importante

    N'oubliez pas de correctement supprimer le cache distribué avant d'exécuter PSCONFIG et ajoutez de nouveau le cache distribué au serveur une fois l'opération terminée.

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
    

    Importante

    Une fois que tous les serveurs ont réussi à utiliser PSCONFIG, n’oubliez pas d’exécuter la commande SharePoint Management Shell ci-dessous pour basculer vers les nouveaux fichiers d’interface utilisateur et terminer le processus côte à côte :
    $webapp = Get-SPWebApplication <webappURL> $webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
    $webapp.WebService.update()

Vous avez maintenant terminé et la batterie de serveurs a été intégralement mise à niveau en cours d'utilisation et sans interruption de service.

Pourquoi l’option MinRole peut-elle vous aider ?

Lorsque vous parlez de ZDP, vous devez également aborder le concept de MinRole. MinRole est une option dans l’installation de SharePoint Server 2016, SharePoint Server 2019 et SharePoint Server Édition d’abonnement. Cette option divise la configuration d'une batterie de serveurs en rôles tels que Site web frontal (WFE), Serveur d'applications (application), Cache distribué (DCache), Recherche ou Personnalisé (pour les produits tiers ou le code personnalisé). Cette configuration vous fournira quatre serveurs en moyenne - deux WFE, deux serveurs d'applications, deux serveurs DCache et deux serveurs de recherche.

Par défaut, les WFE sont optimisés pour une faible latence et les serveurs d'applications pour un haut débit. De même, le regroupement des composants de recherche afin que les appels n'aient pas à quitter la zone d'où ils proviennent améliore l'efficacité des serveurs de recherche. L'un des principaux avantages de MinRole est que cette option intègre la tolérance de panne.

Pourquoi la haute disponibilité est-elle nécessaire ?

La haute disponibilité est un vaste sujet dans SharePoint. Il existe des livres blancs et des articles complets à ce sujet en ligne, tels que cette documentation. Pour simplifier le concept, au moins pour cet article, sachez que ZDP (et aussi MinRole) provient de SharePoint dans Microsoft 365. Dans SharePoint dans Microsoft 365, les serveurs virtualisés ont des redondances intégrées, de sorte que deux des mêmes rôles de serveur de la même batterie de serveurs SharePoint ne vivent pas sur le même hôte ou rack. Cela rend SharePoint plus tolérant aux pannes. Vous pouvez modéliser la même situation, en installant deux de chaque rôle SharePoint Server sur des hôtes distincts sur différents racks dans votre centre de données, avec un routeur partagé ou un câblage entre racks pour accélérer la communication. Vous pouvez également avoir simplement deux serveurs physiques pour chaque rôle SharePoint Server configuré dans un environnement de test (choisissez des barres de puissance distinctes pour chaque moitié de votre batterie de serveurs et assurez-vous que le routage entre l'ensemble des serveurs est rapide et, si possible, ignore le trafic réseau plus large de latence inférieure).

Les objectifs ici sont la haute disponibilité et la tolérance de panne. Cela signifie que les principales priorités séparent les rôles sur des racks ou des serveurs, ce qui garantit que vous avez deux de chaque rôle, facilite la rapidité du trafic réseau entre ces deux niveaux et garantit que votre configuration a des systèmes en place pour la surveillance et le basculement automatique des serveurs de base de données. En matière d'installation manuelle des services dans SharePoint (comme lorsque vous choisissez le rôle « Personnalisé »), il est important que les services soient redondants dans la batterie de serveurs. Par exemple, le cache distribué est mis en cluster, votre batterie de serveurs a plusieurs WFE et vous configurez des serveurs d'applications et de recherche par paires. Ainsi, si un serveur présente un problème grave, l'autre peut traiter la charge utilisateur.

Dans les exemples présents, nous avons utilisés des serveurs physiques pour que les concepts soient plus faciles à appréhender. Quand vient le temps de planifier le ZDP, vous devez dessiner votre propre environnement, où qu’il se trouve (avec des noms/numéros de rack et des noms de serveur où chaque rôle SharePoint Server se trouve). C’est une des méthodes les plus rapides pour isoler les violations des objectifs de redondance de rôle et de tolérance de panne qui pourraient s’être glissées dans votre configuration, quelle que soit la taille de cette dernière.

Vidéo de démonstration de la correction sans interruption dans SharePoint Server 2016