Quelqu'un a essayé le processus de mise à niveau de Windows 2003 x64 vers Windows 2008 x64 ?
En général, il est préférable de ne jamais mettre à niveau un système d'exploitation Windows, mais peut-être que, comme il s'agit d'un système d'exploitation pour serveur, le chemin de mise à niveau a été affiné ?
La réinstallation/reconfiguration serait vraiment longue avec un temps d'arrêt trop long ; je préfère éviter cette voie...
Nous n'avons pas encore de systèmes Windows Server 2008 en production, mais j'ai mis à niveau environ 6 serveurs de test (1 32 bits, 5 64 bits) et le processus a été presque sans faille. Cependant, comme la plupart de ces serveurs étaient des VM hébergées par VMware, les problèmes de pilotes ne sont pas très importants. La seule chose que j'ai dû faire est de désinstaller/réinstaller McAfee VirusScan 8.5 après la mise à niveau.
Je pense que Microsoft a eu beaucoup de temps pour améliorer le processus de mise à niveau depuis l'époque NT4->Windows 2000. J'ai fait beaucoup plus de mises à niveau Windows 2000->2003 que NT4->W2K, c'est certain. Je ne recommanderai que les mises à niveau (en cas de nécessité absolue) de W2K3 x64 -> W2K8 x64. Je ne veux pas utiliser W2K8 32-bit en production comme meilleure pratique.
Je ne pense pas que le chemin du serveur pour les mises à jour soit meilleur que celui de la station de travail. C'est le même produit de base après tout. Ce que vous pourriez avoir, cependant, eh bien nous espérons avoir Il y a moins de "trucs bizarres" sur le système qui pourraient déclencher une mise à jour.
Vous devez prendre une image d'entraînement, éventuellement dans une machine virtuelle, et tester comment la mise à niveau se déroule pour vous, voir comment vos applications se comportent sur un système mis à niveau et décider si le temps pris pour mettre à niveau le serveur, mettre à niveau vos applications et déboguer est inférieur au temps pris pour construire un nouveau système et migrer à travers.
Oh oui, à moins que vous sont En virtualisant la machine de production, vérifiez que le matériel est compatible avec Win 2008. Ce serait un vrai problème.
Quant à un plan de retour en arrière, comme le suggère Chopper3, c'est aussi très important. Assurez-vous de ne pas lancer le processus de mise à niveau avant d'être sûr de pouvoir restaurer une sauvegarde du serveur Windows 2003 que vous mettez à niveau.
Si le temps d'arrêt minimal est votre principale préoccupation, copier les disques du système, effectuer une mise à niveau, tester la mise à niveau, puis revenir en arrière si quelque chose ne va pas, n'est pas la solution. Non pas parce que la mise à niveau pourrait poser des problèmes, mais parce qu'il existe d'autres plans qui entraîneront probablement beaucoup moins de temps d'arrêt du point de vue des utilisateurs.
Pour un temps d'arrêt minimum, je vous suggère :
De cette façon, le seul temps d'arrêt est le temps nécessaire pour effectuer la synchronisation finale avant de basculer (étapes 5 et 6) - cela peut prendre un certain temps si la synchronisation finale inclut la copie de fichiers volumineux (tels qu'une ou plusieurs bases de données importantes), mais cela prendra moins de temps que la prise d'une image de sauvegarde complète et la mise à niveau, et présente l'avantage de ne pas entraîner d'arrêt en cas d'échec (car il suffit d'abandonner la nouvelle configuration sans jamais éteindre l'ancienne).
Bien sûr, ce plan implique d'avoir un deuxième serveur dans le même établissement pour construire, ce qui ne sera pas gratuit, donc si vous payez une bonne partie de votre serveur/hébergement ou si vous avez un budget serré, cela pourrait être un facteur prohibitif...
Nous avons mis à niveau des systèmes non critiques sur 32 bits sans réel problème. En revanche, je n'envisagerais pas de mettre à niveau Windows pour une application critique, principalement en raison des temps d'arrêt que cela entraînerait. Lors de la mise à niveau d'une application critique, nous achetons généralement un nouveau serveur pour le nouveau système d'exploitation, puis nous migrons l'application de l'un à l'autre. L'ancien serveur peut alors être revendu ou réaffecté ailleurs.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
