Estimer la durée du processus de mise à niveau et l’espace dont vous avez besoin (SharePoint Server 2010)
S’applique à : SharePoint Server 2010
Dernière rubrique modifiée : 2016-11-30
Une partie importante de la planification de la mise à niveau depuis Microsoft Office SharePoint Server 2007 vers Microsoft SharePoint Server 2010 consiste à déterminer la durée du processus de mise à niveau et la quantité d’espace de stockage nécessaire. Chaque environnement est unique et présente des possibilités matérielles et des caractéristiques de site spécifiques. L’espace et la durée dont vous avez besoin pour exécuter une mise à niveau varient considérablement en fonction de votre environnement. La meilleure approche pour estimer ces facteurs consiste à effectuer une mise à niveau de test, puis à passer en revue l’espace et la durée qui ont été nécessaires. Pour plus d’informations sur la façon d’exécuter une mise à niveau de test, voir Utiliser une mise à niveau d’évaluation pour rechercher les problèmes potentiels (SharePoint Server 2010).
Dans cet article :
Estimer l’espace dont vous avez besoin pour la mise à niveau
Estimer la durée de la mise à niveau
Estimer l’espace dont vous avez besoin pour la mise à niveau
Pendant une mise à niveau sur place et une mise à niveau avec liaison des bases de données, les bases de données sont susceptibles de croître. En outre, de nombreuses transactions ayant lieu pendant le processus de mise à niveau, vous devez vous assurer que les fichiers journaux disposent de suffisamment de place pour prendre en charge les modifications qui se produisent. Vous devez envisager un accroissement des bases de données et des fichiers journaux.
Lorsque vous planifiez votre mise à niveau, vérifiez que votre environnement actuel suit les meilleures pratiques en termes de stockage pour Office SharePoint Server 2007 de manière à optimiser le déroulement et les performances de la mise à niveau. Pour plus d’informations, voir Recommandations pour le stockage physique (Office SharePoint Server). Vous devez également passer en revue les meilleures pratiques pour SharePoint Server 2010 et apporter tout ajustement nécessaire à votre environnement mis à niveau.
En raison des modifications apportées aux structures des tables dans la nouvelle version, la taille des bases de données augmente provisoirement pendant que les données sont réorganisées. Cet espace peut être récupéré après la mise à niveau, mais vous devez vous assurer que la place disponible permette aux bases de données d’atteindre une taille pouvant représenter jusqu’à 50 % de leurs tailles actuelles pendant une mise à niveau sur place ou une mise à niveau avec liaison des bases de données (gardez à l’esprit qu’après la mise à niveau, vous pouvez de nouveau réduire la base de données pour récupérer la majeure partie de cet espace). Vous devez également vous assurer que l’espace disponible sur vos serveurs de bases de données permette à celles-ci de grandir au fil du temps dans le cadre d’une utilisation normale. Pour déterminer la taille actuelle de vos bases de données, utilisez Enterprise Manager dans Microsoft SQL Server. En plus d’espace pour les bases de données, vous devez disposer de place pour les éléments suivants :
Les bases de données temporaires. Vérifiez que vous disposez de suffisamment d’espace pour permettre la croissance rapide des bases de données temporaires. Si l’espace est insuffisant, il se peut que le processus de mise à niveau arrive à expiration et que la mise à niveau échoue.
Les fichiers journaux de mise à niveau.
les fichiers journaux de transactions des bases de données. Ces fichiers journaux doivent croître rapidement pour prendre en charge toutes les modifications qui se produisent dans les bases de données.
Notes
Dans les environnements très volumineux, il est possible que le taux de croissance par défaut des fichiers journaux de transactions (10 %) ne soit pas suffisant pour prendre en charge le processus de mise à niveau ; cela peut entraîner un délai d’attente. Là encore, une mise à niveau de test est le meilleur moyen pour déterminer si les fichiers journaux des transactions peuvent prendre en charge le processus de mise à niveau. Si votre environnement est très volumineux ou que le processus a expiré au cours d’une mise à niveau de test, envisagez d’accroître la taille des fichiers journaux de transactions SQL Server afin qu’il y ait suffisamment d’espace pour toutes les transactions à traiter. Pour plus d’informations sur la façon d’accroître la taille des journaux des transactions SQL Server, voir Développement d’une base de données (SQL Server 2005) (https://go.microsoft.com/fwlink/?linkid=182619&clcid=0x40C) ou Développement d’une base de données (SQL Server 2008) (https://go.microsoft.com/fwlink/?linkid=182620&clcid=0x40C).
Estimer la durée de la mise à niveau
À partir des estimations d’espace disque et de tests déjà menés, vous pouvez évaluer la durée approximative du processus de mise à niveau proprement dit. Les durées de mise à niveau varient considérablement suivant les environnements. Les performances d’une mise à niveau dépendent considérablement du matériel utilisé, de la complexité des sites et des caractéristiques de votre implémentation. Par exemple, si vous disposez d’un nombre élevé de bibliothèques de documents volumineuses, leur mise à niveau peut prendre plus de temps que celle d’un site plus simple.
Les facteurs qui influent sur les performances sont décrits dans le tableau suivant.
| Facteurs liés au contenu | Facteurs liés au matériel |
|---|---|
Le nombre de :
Plus la taille de la base de données globale proprement dite. |
|
La façon dont vos données sont structurées peut avoir une incidence sur la durée de leur mise à niveau. Par exemple, la mise à niveau de 10 000 listes de 10 éléments chacune sera plus longue que celle de 10 listes de 10 000 éléments. Les actions requises pour mettre à niveau l’infrastructure des listes doivent être réalisées pour chaque liste, indépendamment du nombre d’éléments ; par conséquent, un nombre élevé de listes signifie un nombre élevé d’actions. Il en va de même pour la plupart des éléments de la colonne des facteurs liés au contenu dans le tableau ci-dessus.
La structure de votre matériel peut également avoir une forte incidence sur les performances. Généralement, les performances des serveurs de bases de données sont plus importantes que celles des serveurs Web, mais un matériel insuffisamment puissant ou des problèmes de connectivité à l’un ou l’autre des niveaux peuvent affecter sensiblement les performances de la mise à niveau.
L’approche de mise à niveau que vous avez choisie aura également un impact important sur la durée du processus. La réalisation d’une mise à niveau avec liaison des bases de données est la méthode la plus rapide (cependant, les étapes antérieures et postérieures à la mise à niveau dans cette approche durent plus longtemps que dans une mise à niveau sur place). Une mise à niveau sur place dure un peu moins longtemps, car bien que vous mettiez à niveau l’environnement en plus des sites, vous n’avez pas besoin d’autant d’étapes antérieures et postérieures à la mise à niveau dans cette approche.
La meilleure façon d’estimer la durée globale consiste à effectuer une mise à niveau de test d’une petite partie de toutes les données, puis à consulter les fichiers journaux de mise à niveau. Les fichiers journaux indiquent la durée de la mise à niveau : recherchez la durée totale écoulée en bas du fichier journal de mise à niveau. À partir de cette durée, extrapolez une durée pour la totalité du contenu. Vous pouvez également utiliser les fichiers journaux pour vérifier votre progression au fil du processus de mise à niveau. Le fichier upgrade.log est situé à l’emplacement %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS.
L’estimation que vous obtenez à partir de votre mise à niveau de test concerne le processus de mise à niveau des données proprement dit ; elle n’inclut pas l’ensemble des étapes que vous devez suivre avant et après cette étape, qui peuvent prendre plus de temps que la mise à niveau des données elles-mêmes. Lors de l’évaluation de la durée de la mise à niveau, outre la durée nécessaire au traitement des données, vous devez estimer la durée des activités qui ont lieu au cours des étapes antérieures et postérieures à la mise à niveau.
Pour les étapes préalables à la mise à niveau, prenez en considération les facteurs suivants :
Création des éléments personnalisés La mise à niveau de composants WebPart ou le rétablissement de modèles personnalisés pour tirer parti de nouvelles fonctionnalités prennent un certain temps. Le processus de création des éléments personnalisés doit commencer tôt, pendant la phase d’évaluation de votre projet.
Sauvegarde des bases de données Dans le cas d’une mise à niveau sur place, vous devez effectuer une sauvegarde complète, pas une sauvegarde différentielle, de la totalité de l’environnement pour être certain de pouvoir effectuer une récupération dans l’hypothèse peu probable où la mise à niveau échouerait et où vous devriez régénérer votre batterie de serveurs. Pour les environnements volumineux, cette étape peut prendre beaucoup de temps. En particulier, si vous effectuez la sauvegarde sur un emplacement réseau, des problèmes de temps de réponse du réseau peuvent ralentir ce processus.
Pour les étapes postérieures à la mise à niveau, prenez en considération les facteurs suivants :
Vérification des sites et réalisation de modifications Accordez suffisamment de temps aux utilisateurs pour qu’ils puissent valider leurs sites après la mise à niveau. Cette opération peut prendre plusieurs jours. Pour plus d’informations, voir Vérifier la mise à niveau et passer en revue les sites mis à niveau (SharePoint Server 2010).
Création des applications de services et configuration des services Cette étape s’applique uniquement lors d’une mise à niveau avec liaison des bases de données (pendant une mise à niveau sur place, les applications de services sont créées en tant que parties intégrantes du processus de mise à niveau). La création des applications de services et la configuration des services ne prennent pas beaucoup de temps ; cependant, si vous devez contacter un administrateur de base de données pour qu’il crée préalablement les bases de données pour vous, un délai moyen d’un à deux jours peut être nécessaire.
Conversion de propriétés de profil en données de taxonomie et mise à jour du magasin de photos pour les services Profil utilisateur Vous devez convertir les propriétés de profil utilisateur qui incluent des listes de choix de façon à utiliser les fonctionnalités de taxonomie fournies par le service Métadonnées gérées. Selon le nombre de profils utilisateur dans votre environnement, ces étapes peuvent ajouter une ou plusieurs heures au processus de mise à niveau.
Exécution d’une analyse des utilisateurs Pour les organisations de grande taille, cette étape peut prendre plus de 24 heures.
Exécution d’une analyse de recherche sur tout le contenu Pour les sites de grande taille, cette étape peut prendre plus de 24 heures.
D’autres facteurs dans votre environnement peuvent également favoriser un allongement de la durée des mises à niveau, tels que les suivants :
Bibliothèques de documents très volumineuses La mise à niveau d’une bibliothèque de documents contenant plus de 250 000 documents uniquement à sa racine (et non dans des dossiers) prend beaucoup de temps et peut ne pas être couronnée de succès. Vous pouvez gérer la taille des bibliothèques en vous appuyant sur les recommandations Microsoft Office SharePoint Server 2007 relatives à l’utilisation de dossiers pour scinder les bibliothèques de documents volumineuses. Par exemple, si vous réorganisez la même bibliothèque de documents afin que les 250 000 documents soient répartis en 125 dossiers, sa mise à niveau devrait être plus facile.
Bases de données très volumineuses La mise à niveau des bases de données supérieures à 100 Go peut prendre beaucoup de temps.
Notes
Si vous avez des bases de données d’une taille supérieure à 100 Go et combinant divers types de site (tels que des sites Mon site et des sites d’équipe avec des sites publiés), il est recommandé de les diviser en bases de données de plus petite taille contenant un type de données cohérent avant d’exécuter la mise à niveau. Non seulement la mise à niveau des bases de données volumineuses peut prendre plus de temps, mais celles-ci peuvent compliquer une opération de récupération si la mise à niveau n’est pas couronnée de succès.
Vous pouvez utiliser l’opération mergecontentdbs ou les opérations backup et restore dans Stsadm.exe pour déplacer des sites entre des bases de données. Pour plus d’informations, voir Mergecontentdbs : opération Stsadm (Office SharePoint Server) et Sauvegarde et restauration : opérations Stsadm (Office SharePoint Server).En outre, si vous disposez d’une base de données très volumineuse (supérieure à 100 Go) que vous ne pouvez pas scinder parce que la majeure partie du contenu se trouve dans une seule collection de sites, vous pouvez reconsidérer votre approche de mise à niveau. Une approche de mise à niveau avec liaison des bases de données est plus difficile dans le cas des bases de données très volumineuses, du fait que la sauvegarde et la restauration de ces bases de données sont problématiques.
Avertissement
Veillez à respecter les recommandations sur la planification de la capacité spécifiques aux versions précédentes et nouvelles avant de procéder à la mise à niveau. Si vous êtes allé au-delà des recommandations afin d’obtenir de meilleures performances, le processus de mise à niveau peut prendre plus de temps ou il peut échouer (par exemple, le processus peut expirer à plusieurs reprises sur la même bibliothèque de documents volumineuse). Si votre déploiement ne satisfait pas aux recommandations sur la capacité, déterminez si, avant de procéder à la mise à niveau, vous devez effectuer certaines opérations afin de pallier cette situation. Là encore, une mise à niveau de test peut vous aider à prendre une décision.
Contraintes de communications
Vous devez informer vos utilisateurs et votre équipe de la planification de la mise à niveau et leur laisser le temps d’effectuer leurs tâches. Pour plus d’informations, voir Créer un plan de communication (SharePoint Server 2010).
Gestion des alertes et des alarmes de System Center
Vous devez surveiller les performances système pendant la mise à niveau, mais vous n’avez pas besoin de surveiller de fonctionnalités spécifiques. Suspendez toutes les alarmes et alertes superflues dans Microsoft Systems Center Operations Manager ou Microsoft Operations Manager, puis réactivez-les après la mise à niveau.
Activation/désactivation de la mise en miroir et de la copie des journaux de transaction SQL
Vous devez désactiver la mise en miroir et la copie des journaux de transaction avant d’effectuer la mise à niveau, puis les réactiver une fois que vous êtes sûr que votre environnement fonctionne correctement après la mise à niveau. Il est recommandé de ne pas exécuter la mise en miroir ou la copie des journaux de transaction pendant la mise à niveau, car cela crée une charge supplémentaire sur les serveurs exécutant SQL Server et se traduit par le gaspillage de ressources dans la mise en miroir ou la copie de données temporaires.
Testez votre processus de mise à niveau pour évaluer le temps qu’il peut prendre, puis créez une planification pour vos opérations de mise à niveau et testez-la afin de déterminer la chronologie. Vous devez inclure dans la chronologie des opérations la durée nécessaire à la réalisation des étapes préalables et postérieures à la mise à niveau : si, avant le démarrage de la mise à niveau, la sauvegarde de votre environnement prend 5 heures, vous devez inclure cette durée dans la plage d’indisponibilité. En outre, incluez la durée de la mise en mémoire tampon liée à une restauration ou récupération éventuelle : vous devez déterminer les chronologies d’arrêt planifié (cas réaliste) et d’arrêt d’urgence (cas le plus défavorable).