Le précédent message nous expliquait comment effectuer une mise à jour de l’infrastructure à moindre coûts.
La raison de ce choix est de rester compliant avec l’obligation d’utiliser des solutions professionnelles supportées par l’éditeur. Ceci sans pour autant changer la version de l’application qui est encore supportées pour quelques années (SharePoint 2007 est encore supporté jusqu’en Octobre 2017).
La situation est principalement liée la fin de support d’autres parties encore en place dans de nombreuses fermes SharePoint 2007:
- SQL Server 2000 - Fin du Support étendu : 09 Avril 2013
- Windows 2003 Server (R1 ou R2) - Fin du Support étendu : 14 Juillet 2015
- SQL Server 2005 - Fin du Support étendu : 12 Avril 2016
- Pour rappel, SharePoint 2007 - Fin du Support étendu : 10 Octobre 2017
Ainsi, les fermes SharePoint 2007 faisant fonctionner en leurs seins des systèmes d’exploitation Windows Server 2003 ou des moteurs SQL Server 2005 (voir SQL Server 2000) sont concernés par ce second sujet, le précédent concernait uniquement les serveurs Web ou applicatifs:
Nous verrons dans ce sujet la méthode la plus simple permettant de faire la mise à jour en limitant autant que possible les effets de bords. Pour information, le changement d’OS du noeud SQL Server dans une ferme est transparent, si vous n’utilisez pas la partie Business Intelligence.
Migration des serveurs de base de données SQL Server
Cette partie est donc très certainement la plus sensible, car le coeur de tout l’environnement SharePoint se trouve en Base de données. Si ce serveur est stoppé toutes les applications Web le sont aussi.
Toujours dans cette logique de simplification de la procédure, je suis partisan de suivre la méthode du remplacement discret. En effet, SharePoint gère sa connection SQL Sans prendre en compte le détail de la machine (GUID Windows par exemple), il est d’ailleurs conseillé d’utiliser les ALIAS SQL Server et non le nom de machine ou l’IP.
Quoi qu’il en soit la procédure est expliquée sur le site de Microsoft:
Première étape: Préparation
Contrairement à la migration de serveur Web ou Applicatif qui peut se faire de manière totalement transparente, la migration du Server SQL exige une coupure totale du service.
La procédure ne peut donc pas se faire sans communication et information aux utilisateurs. Il faut une organisation plus poussée que la précédente méthode.
1.1- Définir une date
La méthode la terre brulée est rarement bien perçue par les utilisateurs et le premier pas à franchir est de définir une période de coupure de service qui vous permette:
- D’avoir toutes les ressources techniques disponibles en cas de besoin (et cela arrive)
- De privilégier la période la plus calme pour les utilisateurs
Pour une entreprise mondialisée, il n’y a jamais de jour ou d’heure sans utilisateurs, et de ce fait, le choix du Mercredi Midi (coupure de 2 à 4 Heures suivant le volume) est possible, sinon un week-end est plus classique.
1.2 - Communiquer cette interruption de service
Il convient donc d’informer:
- Les équipes de support (qui recevront les calls)
- Les plus gros Site Owners
- Les Super Users (si vous avez des évangélistes internes, c’est le moment de les impliquer)
- Les managers IT
- Tous ceux qui sont amenés à se servir de la plateforme (Via une News ou un Email)
Il est préférable de suivre cet ordre pour permettre à chacun de se sentir confortable dans son rôle.
Le ton doit rester sobre sans être alarmiste, car il ne s’agit que d’une tache banale que l’IT maîtrise parfaitement.
Il ne faut pas être trop précis pour ne pas perdre les utilisateurs, mais aussi parce que vous ne savez pas ce qui peut se passer de votre côté. Dites-vous que les serveurs ont une “âme” et qu’ils n’ont aucune envie d’être mis au rebus sans se défendre.
Si vous utilisez une solution de répartition de charge, il est probable que vous puissiez mettre en place une page de maintenance à partir de cette plateforme. Je vous encourage à le faire, car l’utilisateur qui n’aurait pas eu la communication pourra au moins comprendre que la solution est Offline pour un certain temps et ne cherchera pas désespérément une solution à son message d’erreur 404.
1.3 - Préparation de la nouvelle machine SQL Server
Le remplacement correspond à:
- Monter une nouvelle machine fraiche
- OS: Windows 2012 R2 X64
- Il ne faut pas que le serveur soit entré dans le domaine de la ferme
- Il faut lui attribuer une IP temporaire
- Etant donnée les configuration matérielles actuelles et la puissance des sous-jacents, une VM (HyperV ou vmWare) convient parfaitement. 4 vCPU et 8 ou 16 GB de RAM suivant la charge de votre ferme
- Donner le même nom que la machine en cours d’utilisation (sans le domaine)
- Installer et configurer SQL Server
- SQL Server 2008 R2, 2012 ou 2014
- Il faut vérifier la compatibilité avec vos applications autres
- Il faut contrôler le licensing pour cette machine
- Installer et configurer les outils standards de votre Datacenter
- Appliquer tous les patches nécessaires (Windows ou SQL Server)
- Copier à travers le réseau les autres fichiers présents sur le serveur d’origine (Backup, tools, scripts, solutions, …)
- Créer les comptes SQL Server s’il en existe dans le serveur d’origine
1.4 - Création des scripts nécessaires
Afin de garder toute le calme nécessaire à la bonne réussite de ce remplacement, il est bien mieux de scripter les taches suivantes :
- A appliquer sur l’ancien serveur SQL
- Script TSQL de détach des bases de données
- A exécuter sur le nouveau serveur SQL
- Script PowerShell ou MSDOS de copie des fichiers de l’ancien serveur vers le nouveau en placant chaque fichier dans le répertoire associé (LDF, MDF et NDF)
- Script TSQL d’attach de chaque base de données
- Script TSQL d’ajout des comptes NT du domaine avec les droits adaptés sur les bases
Même si cette vision est idillique, elle vous permet de garder en tête la procédure qui devra être appliquée contre vents et marées.
Seconde étape: Migration
Cette fois, nous somme au jour J et au moment T, ainsi les étapes à suivre sont les suivantes:
- Mettre en place la page de maintenance (si vous en avez la possibilité)
- Eteindre physiquement tous les serveurs Web ou Applicatifs connectés à votre ferme
- Ne vous embettez pas avec les services, le plus rapide est le Power Off
- Lancer le script TSQL de Detach des bases de données sur l’ancien serveur
- Lorsque toutes les bases de données sont détachées
- Lancer le script de copie des fichiers de bases de données (LDF, MDF et NDF)
- Une fois tous les fichiers copiés
- Stopper l’ancien serveur SQL (c’est sa fin de service)
Notre ancien serveur est etteint, nous devons alors travailler sur le nouveau, mais pour cela il faut le référencer dans le Domaine Active Directory:
- Faire un Reset de l’objet “Computer” au nom de l’ancien serveur, sans le supprimer, il servira de container AD pour la nouvelle machine
- Affecter l’adresse IP de l’ancienne machine à la nouvelle
- Ajouter la nouvelle machine dans le domaine Active Directory
- Redémarrez la nouvelle machine
Une fois le serveur redémarré, il faut :
- Ajouter les groupes, comptes de services, ou comptes admin dans les groupes de sécurité Windows associés
- Ajouter les comptes de domaines admin SQL (comptes de Service SharePoint)
- Lancer le script TSQL pour attacher les bases de données
- Appliquer les permissions SQL Server sur les bases avec le script TSQL préparé
Nous pouvons faire un dernier tour de la configuration des bases de données pour valider notre travail.
Dernière étape: validation de la migration
Pour terminer cette migration, il suffit alors de:
- Redémarrer les serveurs Web et Applicatifs
- Supprimer la page de maintenance et laisser les utilisateurs travailler
Vous pouvez alors surveiller les différents serveurs de la ferme et informer vos utilisateurs de la fin de votre migration.
Conclusion
Prenez en compte chaque feedback, car il peut s’agir d’un détail de configuration non finalisé (par exemple: Alternate access mapping ou encore WSS Search …).
Il ne reste plus qu’à laisser l’ancien serveur quelques jours avant de réellement le supprimer, votre migration est alors terminée avec succès.
Au final, votre environnement reconfiguré vous permettera de tenir le temps nécessaire à une migration vers une version plus récente ou vers le Cloud.
Romelard Fabrice [MBA Risk Management]
Commentaires
Enregistrer un commentaire