Nous avons vu dans un précédent message qu’un article sur l’installation du SP3 de WSS V3 est en ligne :
Cette documentation est celle qui a été suivie pour la mise à jour de deux grosses fermes de production :
- Plus de 300 Collections de sites chacune
- La taille des Collections allant de 1 MB a 30 GB
- env. 600 GB de contenu au total
Le retour est plutôt positif, sauf un détail qui a donc provoqué quelques soucis. Voici donc un retour sur cette mise en place.
DownTime à prévoir
La mise à jour est à faire sur chaque machine Web Front End quoi qu’en dise le message, il faut exécuter l’assistant sur chaque frontal, ce qui double le DownTime à prévoir (env 30 min d’installation par WFE). Il ne faut surtout pas qu’un des Frontaux soit actif pendant que l’autre exécute l’assistant, car il y a des modifications faites sur les bases de données.
Assistant particulièrement long
Lors de l’exécution de l’assistant, de mise à jour, on voit apparaître un message relatif aux 9 étapes. Les 7 premières se déroulent sans soucis, mais la huitième est extrèmement longue. J’ai eu jusque 25 minutes d’attente pour chaque frontal.
Raison du temps d’exécution long sur les grosses fermes de production
La raison est à trouver dans le fichier de LOG de la mise à jour :
- C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\Upgrade.Log
En effet, vers les lignes 400 (pour mon cas), on trouve ce bloc de messages :
[SearchQFE21038DatabaseAction] [12.2.9.0] [DEBUG] [11/17/2011 6:24:00 PM]: Begin Initialize()
[SearchQFE21038DatabaseAction] [12.2.9.0] [DEBUG] [11/17/2011 6:24:00 PM]: End Initialize()
[SearchQFE21038DatabaseAction] [12.2.9.0] [DEBUG] [11/17/2011 6:24:00 PM]: Begin Upgrade()
[SearchQFE21038DatabaseAction] [12.2.9.0] [DEBUG] [11/17/2011 6:24:00 PM]: Applying script SearchDataDBTableChangesBugQFE21038 to WSS_Search_XXXXX database.
Cette étape exécute un script sur la base de recherche dont l’exécution peut être conséquente sur une ferme de production, on trouve d’ailleurs une référence de soucis :
Solution appliquée dans mon cas
Dans mon cas, la solution pour limiter la casse fut de stopper la Mise à jour en plein process (au bout de 25 min), pour stopper le Search, supprimer la base de données de recherche WSS V3. Ensuite exécuter la commande sur chaque frontal :
- PSConfig.exe -cmd upgrade -inplace b2b -force
Puis redémarrer chaque machine, et reconfigurer le moteur de recherche WSS V3, suivant la documentation ici (ne pas oublier le paramétrage pour les PDF) :
La réindexation s’est déroulée toute la nuit et ce matin tout est OK avec mes deux fermes de production avec le Service Pack 3 de Windows SharePoint Services V3 (code version 12.0.0.6608).
Attention pour l’application du SP3 pour MOSS
Selon le message juste plus haut (Problems updating), il semble que cette étape soit aussi présente pour l’application du patch pour MOSS et son moteur de recherche.
Pour des grosses fermes de recherche (dans mon cas, env. 10 millions de records), cela peut rapidement être problématique, car les fichiers de transaction de log de cette base croissent de manière inconsidéré.
Selon la personne, passage de 512 Kb à 32 GB pour le fichier TRN de SQL Server en 3 heures.
Il faut donc prévoir ce risque de temps de DowTime et surtout prévoir la croissance de ce fichier sur votre serveur SQL.
Je reviendrai la dessus lorsque j’aurai effectué cette application sur notre environnement de production MOSS (Portail publishing, env. 13000 MySites, env. 10 Millions de record dans le search, env. 40 000 profils utilisateurs, …)
Prochaine étape, mise à jour des 15 autres fermes WSS, en espérant que d’autre soucis n’appareîtront pas.
Romelard Fabrice [MVP]
Commentaires
Enregistrer un commentaire