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

Question

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'être l'administrateur des serveurs avec un manque évident de connaissances en administration de serveur et google/ServerFault comme point de référence. Heureusement, je n'ai jamais eu à entrer en contact physique avec les machines ou à résoudre des problèmes car elles ont toujours "juste fonctionné".

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

Machine1 - IIS 8.0 hébergeant un certain nombre d'applications internes
Machine2 - Magasin de données SQL Server 2008 R2 pour les applications internes
Machine3 - Magasin miroir SQL Server 2008 R2 de Machine2

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

J'ai été informé que les trois doivent passer d'une salle de données à 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.

En plus de terminer une sauvegarde complète de chacun, quelles considérations dois-je prendre avant d'appuyer hypothétiquement sur l'interrupteur d'alimentation et de regarder mon monde bouger?

^{Je suis conscient que c'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.}

Chopper3 · Accepted Answer

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

Il y a quelques choses que vous devez vérifier avant ce déménagement, certaines faciles, d'autres difficiles.

Alimentation - vérifiez que la nouvelle salle dispose non seulement de la bonne quantité de prises de courant, mais également du bon type - comme dans le type de connecteur physique et si l'emplacement actuel permet différentes phases d'alimentation par serveur pour protéger contre les défaillances monophasées, je vous invite fortement à reproduire cela également dans le nouvel emplacement.

Refroidissement - vous devez vérifier qu'il n'y aura pas d'accumulation immédiate ou progressive de chaleur qui entraînera 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 tirer du site Web du fabricant - faites-le savoir à votre gestionnaire de bâtiment et obtenez une confirmation écrite de sa part indiquant que le refroidissement à cet endroit fonctionnera .

Networking - 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 aussi leur type, leur vitesse et surtout 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 m'en souvenir! mais ces jours-ci, le nombre de configurations de ports et la place dans le réseau dans laquelle un port peut se trouver est astronomique, vous devez vous assurer que les personnes de votre réseau ont TOUT répliqué pour être identiques de l'ancien au nouveau - encore une fois, écrivez ceci comme ceci n'est pas facile. Si quelque chose se passe mal avec cette décision, je mettrais de l'argent sur les ports réseau qui ne sont pas identiques, cela se produit 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 qu'ils ont des liens Fibre Channel vers un stockage partagé, KVM liens vers un écran de gestion partagé - encore une fois s'ils ont besoin de les répliquer de manière identique.

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

chue x · Answer

D'autres réponses couvrent les aspects techniques du déménagement. Vous devrez peut-être également tenir compte d'autres éléments.

Assurez-vous que les utilisateurs savent que leurs applications seront arrêtées pendant le déplacement. Vous voudrez peut-être planifier le déménagement, peut-être pendant les heures non travaillées, afin de minimiser le nombre de personnes affectées.

Demandez à une ou plusieurs personnes bien informées de tester les applications après avoir installé les serveurs. Demandez-leur de faire quelques vérifications d'intégrité pour s'assurer que les applications fonctionnent comme prévu.

Après le test, informez vos utilisateurs que le déménagement est terminé et demandez-leur de vous informer s'ils ont des problèmes.

Sven · Answer

C'est assez difficile à dire et limite "trop large" pour notre format. La chose la plus importante que vous devez vérifier est de savoir si vous devez reconfigurer votre réseau de quelque manière que ce soit, s'il peut 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 vérifiez que le serveur DHCP sera disponible au nouvel emplacement.

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

Makyen · Answer

D'autres réponses ont de bonnes considérations avant le déménagement. Cependant, vous devez également planifier la façon dont vous organisez le déménagement. Du fait que Machine3 est un miroir de Machine2 , il ressemble à la disponibilité est une considération importante pour les bases de données SQL Server 2008 R2. Le fait qu'il s'agisse d'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 en raison de la maintenance, qui comprend le déplacement.

Faites un plan:
Vous devez établir un plan écrit sur la façon dont le déménagement sera effectué. Vous devrez peut-être être en mesure de fournir ce plan, ou des parties de celui-ci, aux personnes manipulant des parties du travail (par exemple les déménageurs). Ce plan doit inclure toutes les activités avant le déménagement, le déplacement réel et les actions après le déménagement (par exemple, vérification de la fonctionnalité).

Déplacer les bases:

Déplacer Machine3 (le miroir SQL Server): le rendre pleinement opérationnel. Vérifiez la resynchronisation.
Déplacer Machine2 : le rendre pleinement opérationnel.
Déplacer Machine1 : le rendre pleinement opérationnel.

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

Ce qui suit comprend deux méthodes (chemin A et B) d'utilisation de Machine3 pour tester les connexions pour Machine1 et/ou Machine2 . Vous ne devez utiliser qu'une seule méthode. La manière de le faire, ou même d'utiliser l'un ou l'autre, dépend des informations non contenues dans la question (par exemple, séparation physique des emplacements finaux des machines, taille physique des machines, longueur des câbles réseau/d'alimentation, disponibilité d'extensions pour ces derniers, similitude des configurations des ports réseau, des besoins de disponibilité, etc.). L'utilisation de Machine3 pour tester ces connexions permet potentiellement une disponibilité plus élevée 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, ou aucune.

Déplacez Machine3 en premier.
- Laissez Machine1 et Machine2 en place pour l'instant.
- Sauvegardez Machine3 , puis arrêtez-le
- Obtenez Machine3 complètement déplacé vers le nouvel emplacement.
- [Chemin B: non utilisé si vous allez utiliser l'étape facultative n ° 2.] Si les configurations de réseau et d'alimentation pour toutes les machines sont identiques: Put Machine3 où Machine1 devrait finir par utiliser les connexions prévues pour Machine1 .
- Obtenez Machine3 de nouveau opérationnel. Dans le nouvel emplacement, vérifiez qu'il fonctionne normalement comme un miroir de Machine2 . Cela permettra de vérifier physiquement que la configuration de tous les problèmes (alimentation, réseau, etc.) est fonctionnelle dans le nouvel emplacement.
- Résolvez tous les problèmes qui surviennent.
- Vérifiez que Machine3 s'est complètement resynchronisé avec Machine2 avant de continuer.
Chemin A: (Facultatif):
- Utilisez Machine3 pour tester toutes les installations destinées à Machine2 et Machine1 .
- Arrêtez Machine3 vers le bas et déplacez/passez en utilisant la position/les connexions pour Machine2 , (vérifier la resynchronisation) puis Machine1 (vérifier la resynchronisation). Si vous avez prévu de le faire, alors Machine3 aurait dû être initialement configuré avec les connexions destinées à être utilisées par Machine1 ou Machine2 , afin de ne pas le configurer en premier à l'emplacement de fin pour Machine3 puis changez-le 3 fois, mais seulement 2 en commençant par utiliser les fonctionnalités de l'une des autres machines.
- Vérifiez que Machine3 s'est complètement resynchronisé avec Machine2 avant de continuer.
Déplacer Machine2 .
- Votre pratique avec Machine3 devrait rendre cela beaucoup plus fluide.
- Sauvegardez Machine2 , puis arrêtez-le
- Déplacez Machine2 vers le nouvel emplacement; faire toutes les connexions
- Résolvez tous les problèmes qui surviennent.
- Vérifiez que Machine2 s'est complètement resynchronisé avec Machine3 avant de continuer.
[Chemin B: Pas nécessaire si vous avez testé toutes les connexions avec Machine3 à l'étape facultative # 2] Si vous avez maintenant Machine3 où Machine1 doit finir:
- Arrêtez Machine3 .
- Déplacez-le à l'endroit où il est prévu de se retrouver (hors de l'emplacement que vous souhaitez Machine1 se trouver).
- Résolvez tous les problèmes qui surviennent.
- Vérifiez que Machine3 s'est complètement resynchronisé avec Machine2 avant de continuer.
Déplacer Machine1 .
- Après avoir déplacé à la fois Machine2 et Machine3 (et, espérons-le, testé les connexions réelles Machine1 utilisera en faisant Machine3 les utiliser temporairement), cela devrait être le plus doux des mouvements.
- Sauvegardez Machine1 , puis arrêtez-le
- 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ù Machine3 est maintenant localisé. J'espère que vous avez déjà pu tester toutes les installations dans la position Machine1 en la faisant déjà utiliser par Machine3 pendant un certain temps (Chemin A ou Chemin B).

chugadie · Answer

Si l'une des adresses IP des serveurs change alors et que les connexions sont établies avec la boîte 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 à SQL Server via IP, NetBIOS ou DNS?
Les comptes d'utilisateurs 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 reporting, si oui, 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 aurez besoin d'un accès pour modifier le code source ou les fichiers de configuration pour toutes les applications qui se connectent au serveur SQL. Les gens pourraient s'appuyer sur un accès SQL direct et non documenté pour des rapports ad hoc.

Software_Programineer · Answer

Utilisez vos serveurs "Disaster Recovery". Passez à eux pour gérer la charge pendant que vous déplacez vos serveurs de production. Avec un équipement DR correctement configuré, vous pouvez faire le déplacement au milieu de la journée sans voir beaucoup de temps d'arrêt (jusqu'à 15 minutes). Comme les serveurs de reprise après 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 fortement de vous en procurer.

Pensez-y de cette façon: pendant que votre corvette se met au point, utilisez votre mini-fourgonnette pour passer la journée.

mm759 · Answer

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

Les applications sont-elles liées à d'autres par e. g. échange nocturne de données par fichier ou par le biais de services Web? Quelles sont les conséquences lorsque les applications ne sont pas disponibles? Les applications connexes peuvent-elles y faire face ou échouent-elles ou produisent-elles même des résultats erronés en raison du manque d'informations de 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 de retour en arrière. Vous pouvez l'utiliser en cas de problème qui ne peut pas être résolu rapidement, e. g. un problème de réseau. Vous devrez probablement garder le déménageur disponible pour le cas de la remise du matériel.
Vos applications conduisent-elles à un trafic réseau élevé et le réseau doit-il être préparé à cela (probablement un problème beaucoup plus improbable que des problèmes d'adresses et de 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 s'insérer dans le rack de serveurs si vous en avez un.

caletron · Answer

Je ne pense pas qu'une chose ait é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? Y a-t-il une sécurité adéquate (systèmes d'alarme, caméras, etc.).