Déplacement de serveurs dans le même bâtiment

Voici mon scénario: Je suis un développeur qui a hérité (à mon insu) de trois serveurs situés dans mon bureau. J'ai également hérité du travail d'administrateur des serveurs avec un manque flagrant de connaissances en administration de serveur et de google / ServerFault comme point de référence. Heureusement, je n'ai jamais eu à entrer en contact physique avec les machines ni à régler les problèmes, car elles ont toujours fonctionné.

Les trois machines sont situées dans la même salle informatique et remplissent les fonctions suivantes:

Machine1- IIS 8.0 hébergeant plusieurs applications internes
Machine2- Magasin de données SQL Server 2008 R2 pour les applications internes
Machine3- Magasin miroir de SQL Server 2008 R2Machine2

Tous les trois ont des disques durs externes connectés qui effectuent des sauvegardes fréquemment.

On m'a informé que tous les trois devaient passer d'une salle informatique à une autre dans les mêmes locaux. Je ne terminerai pas le déplacement physique du matériel, qui sera géré par un déménageur compétent.

Outre la sauvegarde complète de chacun, quelles considérations dois-je prendre en compte avant d'appuyer de façon hypothétique sur l'interrupteur d'alimentation et de regarder mon monde évoluer?

^{Je suis conscient du fait qu’il est loin d’être idéal d’avoir tous les trois situés dans la même pièce / locaux, mais c’est au-delà de la portée de cette question.}

Question vraiment intéressante, bien posée :)

Avant ce déménagement, vous devez vérifier certaines choses, certaines faciles, d'autres difficiles.

Alimentation - Vérifiez que la nouvelle salle dispose non seulement du nombre correct de prises électriques, mais également du type approprié - comme dans le type de connecteur physique et si l'emplacement actuel permet à différentes phases d'alimentation par serveur de se protéger contre les pannes monophasées, Je vous encourage vivement à le reproduire également dans le nouvel emplacement.

Refroidissement - vous devez vérifier qu'il n'y aura pas d'accumulation de chaleur immédiate ou progressive qui pourrait entraîner une surchauffe et un arrêt potentiel du serveur. Vous pouvez généralement rechercher la puissance maximale (en watts) ou la chaleur (en BTU) que chaque serveur peut extraire du site Web du fabricant. Informez-en votre gestionnaire d'immeuble et obtenez une confirmation écrite de sa part indiquant que le refroidissement de cet emplacement sera suffisant. .

La mise en réseau - c’est le plus difficile - non seulement le même nombre de ports doit être répliqué entre l’ancien et le nouvel emplacement, mais il en va de même de leur type, de leur vitesse et, plus important, de leur configuration. Ce dernier point est la clé - il fut un temps où presque tous les ports d’un réseau étaient à peu près égaux - je suis assez vieux pour me souvenir de cette époque! mais ces jours-ci, le nombre de configurations de ports et l'emplacement dans lequel un port peut être situé est astronomique, vous devez vous assurer que les personnes de votre réseau répliquent TOUT pour être identiques de l'ancien au nouveau - réécrivez-le par écrit, car ceci ce n'est pas facile. Si quelque chose se passe mal avec ce déménagement, je mettrais de l'argent sur les ports du réseau, car ils ne sont pas identiques, cela arrive tout le temps.

"Autres connexions" - savez-vous si vos serveurs ont d'autres connexions que l'alimentation et la mise en réseau? peut-être ont-ils des liens Fibre Channel vers le stockage partagé, des liens KVM vers un écran de gestion partagé - là encore, vous devez les répliquer à l'identique.

Autre que cela, n'hésitez pas à revenir ici avec des questions plus spécifiques, et j'espère que le déménagement va bien.

D'autres réponses couvrent les aspects techniques du déménagement. Vous devrez peut-être également envisager d'autres choses.

Assurez-vous que les utilisateurs savent que leurs applications seront en panne pendant le déplacement. Vous voudrez planifier le déménagement, peut-être en dehors des heures de travail, afin de minimiser le nombre de personnes touchées.

Demandez à une personne bien informée (ou à des personnes) de tester les applications après avoir installé les serveurs. Demandez-leur de faire quelques vérifications pour vous assurer que les applications fonctionnent comme prévu.

Après le test, dites à vos utilisateurs que le déplacement est terminé et demandez-leur de vous faire savoir s'ils ont des problèmes.

C'est assez difficile à dire et à la limite "trop ​​large" pour notre format. La chose la plus importante à vérifier est de savoir si vous devez reconfigurer votre réseau pour pouvoir continuer à fonctionner avec les mêmes adresses. Même s'ils peuvent conserver les mêmes adresses, assurez-vous qu'ils ne sont pas configurés via DHCP et / ou que le serveur DHCP sera disponible au nouvel emplacement.

Note latérale: Comme vous l'avez déjà indiqué, disposer du serveur SQL et de son miroir est loin d'être idéal. Cependant, avoir les disques de sauvegarde au même endroit est vraiment dangereux. Vous devez avoir votre sauvegarde dans un emplacement physique différent.

D'autres réponses ont de bonnes considérations avant le déménagement. Cependant, vous devriez également planifier la manière dont vous organisez le déménagement. Du fait que Machine3 est un miroir de Machine2 , il semble que la disponibilité est une considération importante pour la ou les bases de données SQL Server 2008 R2. Le fait que ce soit un miroir vous offre une opportunité. La raison de l'existence d'un miroir doit être disponible lorsque le serveur principal ne l'est pas. Cela inclut le fait de ne pas être disponible pour des raisons de maintenance, ce qui inclut le déménagement.

Établissez un plan:
Vous devez établir un plan écrit pour la manière dont le déménagement sera effectué. Vous devrez peut-être être en mesure de fournir ce plan, ou une partie de celui-ci, à des personnes manipulant des parties du travail (par exemple, les déménageurs). Ce plan doit inclure toutes les activités préalables au déménagement, le déplacement réel et les actions postérieures au déplacement (vérification de la fonctionnalité, par exemple).

Déplacer les bases:

1. Déplacer Machine3 (le miroir SQL Server): Obtenez-le pleinement opérationnel. Vérifiez la resynchronisation.
2. Move Machine2 : Obtenez le complètement opérationnel.
3. Move Machine1 : Obtenez le complètement opérationnel.

Description plus détaillée du déménagement:

Vous trouverez ci-dessous deux méthodes (chemins A et B) d’utilisation de Machine3 pour tester les connexions de Machine1 et / ou Machine2 . Vous ne devriez utiliser qu'une seule méthode. La manière de le faire, ou même de l’utiliser, dépend des informations qui ne figurent pas dans la question (par exemple, la séparation physique des emplacements finaux des machines, la taille physique des machines, la longueur des câbles réseau / d’alimentation, la disponibilité des extensions pour ceux-ci, similarité des configurations des ports réseau, besoins en disponibilité, etc.). L'utilisation de Machine3 pour tester ces connexions permet potentiellement une disponibilité plus longue pour Machine2 , mais en particulier pour Machine1 , qui n'a pas de miroir. Vous pouvez choisir d’utiliser l’une ou l’autre méthode.

1. Déplacez Machine3 en premier.

   • Laissez Machine1 et Machine2 en place pour le moment.
   • Sauvegardez Machine3 , puis fermez-le
   • Get Machine3 complètement déplacé vers le nouvel emplacement.
   • [Chemin d'accès B: Inutilisé si vous souhaitez utiliser l'étape facultative n ° 2.] Si les configurations réseau et alimentation de toutes les machines sont identiques: Placez Machine3 sur lequel il est prévu que Machine1 finisse par utiliser les connexions destinées à Machine1 .
   • Faites redémarrer Machine3 . Dans le nouvel emplacement, vérifiez qu'il fonctionne normalement en tant que miroir de Machine2 . Cela permettra de vérifier physiquement que la configuration de tous les problèmes (alimentation, réseau, etc.) fonctionne dans le nouvel emplacement.
   • Résolvez tous les problèmes qui surviennent.
   • Vérifiez que Machine3 est complètement resynchronisé avec Machine2 avant de poursuivre.

2. Chemin A: (facultatif):

   • Utilisez Machine3 pour tester toutes les installations destinées à Machine2 et Machine1 .
   • Arrêtez Machine3 et déplacez / passez à l'aide de la position / connexions pour Machine2 (vérifiez la resynchronisation), puis Machine1 (vérifiez la resynchronisation). Si vous avez prévu de le faire, alors Machine3 aurait d' abord été mis en place avec les connexions destinées à l' utilisation finale par Machine1 ou Machine2 , donc vous mettre pas en premier dans l'emplacement de fin pour Machine3 puis changer 3 fois, mais seulement 2 en commençant par les installations de l’une des autres machines.
   • Vérifiez que Machine3 est complètement resynchronisé avec Machine2 avant de poursuivre.

3. Déplacez Machine2 .

   • Votre pratique avec Machine3 devrait rendre cela beaucoup plus fluide.
   • Sauvegardez Machine2 , puis éteignez-le
   • Déplacez Machine2 vers le nouvel emplacement. faire toutes les connexions
   • Résolvez tous les problèmes qui surviennent.
   • Vérifiez que Machine2 est complètement resynchronisé avec Machine3 avant de continuer.

4. [Chemin d'accès B: inutile si vous avez testé toutes les connexions avec Machine3 à l'étape facultative n ° 2]. Si vous disposez maintenant de Machine3 sur laquelle Machine1 doit se terminer:

   • Arrêtez Machine3 .
   • Déplacez-le là où il est prévu de se retrouver (en dehors de l'emplacement où vous souhaitez que Machine1 soit localisé).
   • Résolvez tous les problèmes qui surviennent.
   • Vérifiez que Machine3 est complètement resynchronisé avec Machine2 avant de poursuivre.

5. Déplacer la Machine1 .

   • Après avoir déplacé à la fois Machine2 et Machine3 (et, espérons-le, testé les connexions réelles que Machine1 utilisera en les faisant utiliser temporairement par Machine3 ), il devrait s'agir du plus fluide des déplacements.
   • Sauvegarder la machine1 , puis l'éteindre
   • Déplacez Machine1 vers le nouvel emplacement. faire toutes les connexions
   • Résolvez tous les problèmes qui surviennent.
   • Si quelque chose ne va pas avec les installations dans la position que Machine1 est censée occuper, vous avez la possibilité d’utiliser les installations où se trouve actuellement Machine3 . J'espère que vous avez déjà pu tester toutes les installations de la position Machine1 en les faisant déjà utiliser par Machine3 pendant un certain temps (chemin A ou chemin B).

Si l'une des adresses IP des serveurs change alors, et que des connexions sont établies avec la boîte de dialogue SQL via la résolution DNS, vous devrez planifier une modification des enregistrements DNS en même temps que le déplacement.

Ce que vous devez savoir sur le logiciel intranet et les bases de données:

• Le logiciel intranet se connecte-t-il au serveur SQL via IP, NetBIOS ou DNS?
• Les comptes d'utilisateur SQL Server utilisés par le logiciel intranet ont-ils une authentification limitée au trafic provenant d'une adresse IP?
• Les employés de votre entreprise accèdent-ils directement à SQL Server à partir de feuilles de calcul ou d’outils de génération de rapports; le cas échéant, comment définissent-ils le DSN?

Si vous n'obtenez pas exactement les mêmes adresses IP ou si vous vous retrouvez sur un sous-réseau différent, vous devez avoir un accès pour modifier le code source ou les fichiers de configuration de toutes les applications qui se connectent au serveur SQL. Les utilisateurs peuvent s’appuyer sur un accès SQL direct et non documenté pour la création de rapports ad-hoc.

Utilisez vos serveurs de "récupération après sinistre". Basculez-vous sur eux pour gérer la charge lorsque vous déplacez vos serveurs de production. Avec un équipement DR correctement configuré, vous pouvez effectuer le déménagement en milieu de journée sans trop de temps d'immobilisation (jusqu'à 15 minutes). Les serveurs de reprise sur sinistre doivent être configurés de la même manière que les serveurs de production. Si vous n'avez pas d'équipement DR, je vous recommande vivement de vous en procurer.

Pensez-y de cette façon: pendant que votre corvette s'améliorera, utilisez votre fourgonnette pour passer la journée.

Une chose que je ne pense pas qui a été mentionnée est la sécurité physique de la nouvelle maison des serveurs. À quoi servait la pièce auparavant et qui a les clés? La sécurité est-elle suffisante (systèmes d'alarme, caméras, etc.)?

Quelques considérations en plus des autres réponses:

• Les applications sont-elles liées à d’autres par exemple par un échange nocturne de données par fichier ou par l’utilisation de services Web? Quelles sont les conséquences lorsque les applications ne sont pas disponibles? Les applications associées peuvent-elles y faire face ou échouent-elles voire produisent-elles des résultats erronés en raison du manque d'informations dans vos applications?

• Un temps d'arrêt est-il acceptable pour vos utilisateurs, votre entreprise ou même vos clients? Combien de temps cela peut-il être?

• Je pense que c'est une bonne idée d'avoir un plan pour un retour en arrière. Vous pouvez l'utiliser en cas de problème qui ne peut pas être résolu rapidement, par exemple un problème de réseau. Vous aurez probablement besoin de garder le déménageur disponible pour le cas de la récupération du matériel.

• Vos applications entraînent-elles un trafic réseau élevé et le réseau doit-il être préparé à ce problème (problème probablement beaucoup moins probable que celui lié aux adresses et aux pare-feu)? Si vous avez des applications en temps réel (par exemple, un logiciel de vidéoconférence), les latences seront importantes.

• Les serveurs doivent tenir dans le rack du serveur, si vous en avez un.