Ici est évoqué partiellement le fruit d'une triple expérience, le transfert d'un serveur IIS4 à un autre
IIS4 et le transfert d'un serveur IIS4 sur un IIS5, le transfert d'un serveur
IIS5 à l'identique sur un second pour mise en oeuvre d'un load balancing entre
les deux..
En ce qui me concerne, le transfert c'est fait chaque fois d'un ordinateur
contrôleur de domaine à un autre nouveau contrôleur du même domaine.
Certains concepts d'ordre général s'appliquent cependant à tout transfert
d'un ancien serveur web vers un nouveau quelle que soit la version considérée
et le type d'installation serveur. Certaines différences de situation seront
tout de même évoquées.
Voici la liste des choses à faire, que j'ai suivie, accompagnée
de variantes possibles.
- Installation des applications sur le nouveau serveur
- NT et IIS
Dans mon cas, il s'agissait de remplacer l'ancien
serveur par un nouveau, d'où l'installation nécessaire.
Si le nouveau serveur est dans le même domaine
que l'ancien, l'installer en BDC du domaine,
quitte à le promouvoir en PDC, plus tard si
c'est justement le rôle de celui qu'on remplace
et qu'il est amené à disparaître.
- Les pilotes de bases de données
adéquats, les sources ODBC et les serveurs de
BDD
Si vous aviez des applications de bases de données utilisant
ODBC,
il faut installer les pilotes de bases de données
adéquats, si nécessaire. Si votre langage de programmation sait
attaquer le serveur de base de données de façon
native, cette étape est superflue, par contre
penser à modifier la configuration de votre
serveur de BDD s'il fait des contrôles sur l'hôte
depuis lequel sont envoyées les requêtes (cas de scripts PHP
attaquant nativement un serveur MySQL, par exemple).
Pour rétablir les sources système ODBC, le
mieux que j'aie trouvé est d'extraire puis de réimporter
la clé :
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC
étant donné, par ailleurs, que mes
installations ODBC étaient quasi identiques sur
les deux machines.
Mais, si ce n'est pas le cas, alors
on peut extraire juste les fragments intéressants
et surtout :
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
C'est là que vous avez toutes
les définitions de Datasources.
- Les bons SP et hotfixes de NT
Appliquer, comme d'habitude, les services packes
et hotfixes adéquats.
Si possible les mêmes que
sur l'ancien serveur, afin d'éviter toute surprise, si vous
restez dans la même version de Windows (cette remarque ne
s'applique pas évidemment si vous passez d'un serveur NT à un
serveur 2000).
- Les correctifs IIS éventuels
De même que pour NT il existe des patches de sécurité
pour IIS. Pensez à aller visiter régulièrement
le site de mise à jour Microsoft, voire abonnez-vous
au Microsoft Security Bulletin.
- Transfert des fichiers avec les ACL
Vous avez deux solutions classiques pour transférer les
fichiers avec leurs ACL (primordial si vous continuer à accéder aux
ressources de votre serveur Web avec les mêmes comptes) plus la solution
du "IIS Migration Wizard" du Resource Kit dans le cas d'une
migration vers IIS5 (depuis IIS4 ou IIS5).
- Backup/Restore
Faire le backup du répertoire InetPub (au moins),
des répertoires de Bases de données si elles
sont sur le même serveur, et de tout répertoire
concerné peu ou prou par votre serveur IIS. Ca
c'est fonction de l'implémentation de chacun. Je
vous conseille de toujours tenir une liste à
jour de cette organisation. Prendre soin, si
c'est optionnel dans votre logiciel de backup, de
bien sauvegarder les ACL.
- scopy du Res. Kit
L'utilitaire scopy du Resource Kit permet de
faire directement la copie des fichiers d'un
serveur sur l'autre, en recopiant les ACL.
- robocopy du Res. Kit
L'utilitaire robocopy permet non seulement de transférer les ACL lors
de la copie mais offre de très nombreuses options évoluées de
synchronisation de répertoires. Attention il ne s'agit pas de
synchronisation temps réel ! Petite
présentation de robocopy ici.
- IIS Migration Wizard (Resource Kit Windows 2000
server ou en download)
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/iis_migration_wizard-o.asp
Permet de migrer les fichier avec ou sans les ACL. Notez toutefois que
vous aurez une recopie d'ACL à la mode Windows NT (comme avec les
deux techniques précédentes) et sans le bénéfice des permissions
de type héritées, permises par Windows 2000, ce qui peut être
dommage.
Cependant la situation peut différer de façon très important selon
le type de migration que vous allez effectuer. Les cas des serveurs
membres et des contrôleurs de domaine sont assez différents à ce sujet.
Si vous êtes organisé en contrôleur de domaine, le compte IUSR_nom_serveur
qui est par défaut le compte d'accès anonyme à votre serveur IIS est
donc un compte de domaine. Il peut être conservé comme compte d'accès
sur le nouveau serveur mais il faut alors penser à mettre à jour la
configuration IIS du nouveau serveur qui aura configuré par défaut un
nouveau compte IUSR_nouveau_serveur pour ce faire. C'est ce que
j'ai fait lors de ma première migration de IIS4 à IIS4. Je ne voulais
pas retravailler toutes les ACL des serveurs web et FTP pour cause de
changement du compte anonyme car il y avait de très nombreux changements
de droits dans l'arborescence (mélange important de parties publiques et
privées).
Plus tard, lors de ma grosse migration, IIS4 vers IIS5, j'ai profité
du fait que je ne travaillais pas dans l'urgence, comme la première fois,
et que je changeais tout le système d'ACL afin de bénéficier de
l'héritage des ACL Windows 2000, pour modifier ce compte. Et là j'ai
carrément choisi de créer un compte moi-même, à cet effet. Je
n'utilise donc plus du tout les comptes IUSR_nom_serveur pour mon
accès anonyme.
Note : il se peut que certains soucis non réglés
encore, à ce jour, avec les scripts d'interrogation du moteur de
recherche viennent de là mais je ne pense pas. Je penche plutôt pour les
suppressions trop draconiennes que j'ai faites dans les extensions de
scripts à la racine du serveur web (je voulais sécuriser davantage le
serveur en éliminant tous les types de scripts que je n'utilise jamais
sur ces serveurs) ou le changement de port du serveur par défaut IIS5.
- Recherche et remplacement de toutes les références
absolues à l'ancien serveur dans les pages html
- BKReplaceEm
On a beau dire aux webmestres de ne pas mettre de
référence absolue au serveur lui-même dans
leurs pages, il y en a toujours quelques uns pour
oublier.
Si votre serveur remplace l'ancien en gardant le
même nom d'hôte (ou alias), il n'y a aucun
problème et rien de spécial à faire.
Dans le cas contraire je vous conseille le très
bon BKReplaceEm pour faire des cherche/remplace
simples ou complexes (incluant les expressions régulières).
Attention ! Agissez sur la
nouvelle copie que vous venez de
faire. Et vérifiez tout de
suite le résultat sur quelques fichiers. Méfiez-vous
particulièrement des expressions régulières,
c'est extrêmement dangereux.
Vous pouvez télécharger BKReplaceEm depuis sa homepage.
- Changements éventuels de comptes dans les ACL
- subinacl du Res. Kit (changement de domaine ou de
compte anonyme)
- ou bien garder le même compte anonyme qu'avant
si le domaine reste le même
- Transfert de la configuration IIS
(Métabase de IIS)
J'ai détaillé un peu plus cette opération dans le cas du passage
d'IIS4 à IIS4 (ou IIS5 à IIS5) sur autre serveur semblable. Vous
trouverez la documentation ici.Pour le transfert d'IIS4 à IIS5, il y a un outil dans le
Resource Kit de Windows 2000 serveur qui m'a servi mais donné pas mal de soucis
également.
Quand vous lancez le CD du ResKit, il y a,
en plus de l'installation de base, des options pour produits complémentaires
d'origine Microsoft et produit complémentaires tierce partie. C'est dans
les produits complémentaires Microsoft que se trouve cet outil
de migration : IIS Migration Wizard. Si vous avez fait une documentation sur son utilisation, je
veux bien pointer l'URL voir la mettre en ligne s'il elle n'y est
pas (Me contacter). Cet outil permet
de migrer un site web IIS4 vers IIS5 ou IIS5 vers IIS5. J'ai testé les
deux et ça marche mais j'ai rencontré quelques difficultés dans
certains cas et il y a quelques remarques qui méritent d'être faites.
Personnellement je me bornerai à lister ici, sans ordre particulier,
quelques remarques concernant des difficultés rencontrées.
- L'objet de base de chaque action de migration est le site (au sens
IIS de site : "site web par défaut" et autres sites
éventuellement ajoutés à votre serveur). Et chaque site migré
donne naissance à un nouveau site sur le nouveau serveur. La
migration des caractéristiques du premier site web par défaut n'est
donc pas possible sauf à supprimer le site web par défaut
pré-existant sur le serveur de destination et le remplacer (en le
renommant, ou pas) par celui migré. Ceci me paraît inutilisable vu
la différence de structure, dans ce premier site web par défaut,
entre NT/IIS4 et 2000/IIS5, surtout si vous utilisez des outils
d'administration distante, le moteur de recherche, etc. Il y a trop de
différences de racines virtuelles nouvelles, etc.
J'en ai tiré, un peu tard (comme le corbeau de la fable :-), comme
conclusion pour l'avenir : ne plus jamais faire l'erreur
d'utiliser le site web par défaut pour mettre son ou ses espaces web.
- Si on décide d'utiliser l'assistant pour transférer également les
fichiers du site migré, il met les fichiers dans un répertoire
de destination qui porte le nom de l'URL du site web d'origine, ce que
l'on ne voudra pas forcément conserver. Si on renomme ou déplace ce
répertoire, ne pas oublier de modifier les propriétés du site
(Répertoire de base) pour que cela continue à fonctionner.
- Dans mon cas, le transfert des fichiers et/ou des ACL a buté sur un
problème d'accès à une ressource à transférer (mais j'ai mis deux
jours à trouver) sur une cochonnerie de répertoire (un truc dans le
style machin chouette phonebook, je n'ai plus le nom exact en tête).
Le pire, c'est que ce foutu répertoire avait exactement les mêmes
ACL que d'autres répertoires correctement traités. Quand j'ai enfin
trouvé (lors d'une tentative de scopy) j'ai carrément
supprimé le gêneur (qui était vide d'ailleurs), sans autre forme de
procès, et la moulinette a pu travailler jusqu'au bout (sur les ACL
seulement car entre-temps je m'étais impatienté et avais transféré
les fichiers par backup/restore). Si je n'avais pas tenté ce scopy,
je n'aurais probablement jamais trouvé. En effet, l'outil de
migration n'affiche que des points pendant son travail ; on ne
sait donc pas où il en est au moment où ça plante, d'autant qu'il
ne copie pas directement sur la destination. Il crée une archive
compactée intermédiaire où tout est stocké et d'où tout est
extrait, une fois la phase d'extraction accomplie, pour recopie sur le
nouveau serveur. Bref, processus totalement "opaque".
- Seuls les sites web sont transférés, pas les sites FTP. Comme j'en
avais peu, je les ai transférés "à la main" mais l'un
d'eux contenait beaucoup de répertoires virtuels, ce que j'avais
oublié. Cela m'a donc pris pas mal de temps. Par contre, lorsque j'ai
dû répliquer sur le second serveur IIS5 que j'ai mis en load
balancing avec le premier, là j'ai utilisé un autre outil
complémentaire Microsoft du Resource Kit qui est "IIS metabase
editor". Comme on peut le faire avec regedt32 ou regedit, on peut
enregistrer une clé et toute sa sous-arborescence et la recharger sur
l'autre machine. Cela a, apparemment, fort bien fonctionné pour le
transfert des racines virtuelles FTP. Je pense donc que j'aurais pu
l'utiliser dès le transfert d'IIS4 vers IIS5 pour peu que la
structure des clés de racines virtuelles n'ait pas changé, ce que je
n'ai pas vérifié.
- Load balancing de serveurs IIS et ODBC
Le load balancing pose un problème particulier avec les sources ODBC. En
effet, les sources DSN, utilisées pour un accès à travers IIS, sont
visiblement verrouillées dès le départ par IIS. Je n'ai pas réussi à
contourner cette contrainte. J'avais voulu déclarer une datasource locale
sur le premier serveur et distante sur le second, afin de pointer sur le
même fichier. Le deuxième arrivé se fait jeter pour cause de fichier
verrouillé. Peut-être quelque chose m'a-t-il échappé ; si c'est
le cas je suis preneur de la solution.
A partir du blocage constaté, il y a deux cas à envisager :
- Les applications dont les datas sont fixes, non modifiées par les
applications web. A ce moment, il suffit de répliquer sur les deux
serveurs les fichiers d'application, de base de données et les
sources DSN ODBC correspondantes.
- Les applications qui éditent la datasource ODBC. Là il n'est plus
possible, pour des raisons de consistance de la base, de dupliquer la
base sur les deux serveurs. On est alors obligé de modifier les URL
d'appel à l'application pour qu'elles pointent non plus sur l'URL du
"cluster" mais sur l'URL spécifique de l'une des machines
en WLBS que vous aurez choisie comme support des bases de données
ODBC éditables.
Bien entendu, ce discours ne s'applique qu'aux technologies que j'ai
testées et qui ont besoin d'une source DSN déclarée, tels que les
scripts PHP, les scripts IDC/HTX, etc.
Je n'ai pas fait l'essai avec les ASP et autres ADO qui déclarent
eux-même leur datasource dans le courant du script. Si quelqu'un l'a fait
dans le cadre d'un ensemble de serveurs IIS en WLBS, avec accès
concurrentiel en édition à la même datasource, cela m'intéresse de
savoir si ça marche. Vous pouvez me mettre un mot et j'ajouterai votre
expérience (à votre crédit, bien entendu) à cette page.