Traslado de servidores dentro del mismo edificio

Este es mi escenario: soy un desarrollador que heredó (sin saberlo) tres servidores ubicados dentro de mi oficina. También heredé el trabajo de ser el administrador de los servidores con una clara falta de conocimiento de la administración del servidor y google / ServerFault como punto de referencia. Afortunadamente, nunca he tenido que entrar en contacto físico con las máquinas ni abordar ningún problema, ya que siempre han "funcionado".

Las tres máquinas están ubicadas dentro de la misma sala de datos y tienen el siguiente propósito:

Machine1- IIS 8.0 que aloja una serie de aplicaciones internas
Machine2- Almacén de datos de SQL Server 2008 R2 para las aplicaciones internas
Machine3- Almacén espejo de SQL Server 2008 R2 deMachine2

Los tres tienen discos duros externos conectados que completan las copias de seguridad con frecuencia.

Me han informado que los tres necesitan moverse de una sala de datos a otra dentro de las mismas instalaciones. No completaré el movimiento físico del hardware, que será manejado por un transportista competente.

Además de completar una copia de seguridad completa de cada uno, ¿qué consideraciones debo hacer antes de presionar hipotéticamente el interruptor de encendido y ver cómo se mueve mi mundo?

^{Soy consciente de que está lejos de ser ideal tener los tres ubicados en la misma habitación / local, pero eso está fuera del alcance de esta pregunta.}

Pregunta genuinamente interesante, bien hecha :)

Hay algunas cosas que debe verificar antes de este movimiento, algunas fáciles, otras difíciles.

Alimentación : compruebe que la nueva sala no solo tiene la cantidad correcta de tomas de corriente, sino que son del tipo correcto, como en el tipo de conector físico y si la ubicación actual permite diferentes fases de alimentación por servidor para proteger contra fallas de una sola fase, entonces yo Le recomiendo encarecidamente que reproduzca eso también en la nueva ubicación.

Enfriamiento : debe verificar que no habrá una acumulación inmediata o gradual de calor que conduzca al sobrecalentamiento y al posible apagado del servidor. Por lo general, puede buscar la potencia máxima (en vatios) o el calor (en BTU) que cada servidor puede extraer del sitio web del fabricante; informe al administrador de su edificio y obtenga una confirmación por escrito de ellos indicando que el enfriamiento en esa ubicación hará frente .

Redes : esta es la difícil: no solo es necesario replicar la misma cantidad de puertos entre la ubicación antigua y la nueva, sino también su tipo, velocidad y, lo que es más importante, configuración. Este último punto es la clave: hubo un momento en que casi todos los puertos de una red eran prácticamente iguales: ¡tengo la edad suficiente para recordar esos tiempos! pero en estos días, el número de configuraciones de puertos y el lugar en la red en el que puede estar cualquier puerto es astronómico, debe asegurarse de que la gente de su red haya replicado TODO para que sea idéntico de lo antiguo a lo nuevo. No es fácil Si algo sale mal con este movimiento, pondría dinero en los puertos de red que no son idénticos, sucede todo el tiempo.

'Otras conexiones' : ¿sabe si sus servidores tienen otras conexiones además de la alimentación y las redes? tal vez tienen enlaces de canal de fibra para almacenamiento compartido, enlaces KVM a una pantalla de administración compartida; de nuevo, si es necesario, debe replicarlos de manera idéntica.

Aparte de eso, siéntase libre de regresar aquí con preguntas más específicas, y espero que el movimiento vaya bien.

Otras respuestas cubren los aspectos técnicos del movimiento. También es posible que tenga que considerar algunas otras cosas.

Asegúrese de que los usuarios sepan que sus aplicaciones estarán inactivas durante el traslado. Deberá programar la mudanza, tal vez fuera del horario laboral, para minimizar la cantidad de personas afectadas.

Haga que una persona con conocimiento (o personas) pruebe las aplicaciones después de abrir los servidores. Pídales que realicen algunos controles de sanidad para asegurarse de que las aplicaciones funcionen como se espera.

Después de la prueba, dígale a sus usuarios que el movimiento ha finalizado y pídales que le informen si tienen algún problema.

Es bastante difícil de distinguir y limita con "demasiado amplio" para nuestro formato. Lo más importante que debe verificar es si necesita reconfigurar su red de alguna manera o si pueden seguir ejecutándose con las mismas direcciones. Incluso si pueden mantener las mismas direcciones, asegúrese de que no estén configuradas a través de DHCP y / o verifique que el servidor DHCP esté disponible en la nueva ubicación.

Nota al margen: como ya dijo, tener el servidor SQL y su espejo está lejos de ser ideal. Sin embargo, tener las unidades de respaldo en la misma ubicación es realmente peligroso. Necesita tener su copia de seguridad en una ubicación física diferente.

Otras respuestas tienen buenas consideraciones previas al movimiento. Sin embargo, también debe planificar cómo organizar el movimiento real. Por el hecho de que Machine3 es un espejo de Machine2 , parece que el tiempo de actividad es una consideración importante para las bases de datos SQL Server 2008 R2. El hecho de que sea un espejo te brinda una oportunidad. La razón de la existencia de un espejo debe estar disponible cuando el servidor primario no lo está. Eso incluye no estar disponible debido a mantenimiento, que incluye mudanza.

Haga un plan:
debe hacer un plan escrito sobre cómo se llevará a cabo el movimiento. Es posible que deba proporcionar este plan, o partes de él, a las personas que manejan partes del trabajo (por ejemplo, los que se mudan). Este plan debe incluir todas las actividades previas al movimiento, el movimiento real y las acciones posteriores al movimiento (por ejemplo, verificación de la funcionalidad).

Movimientos básicos:

1. Move Machine3 (el espejo de SQL Server): póngalo en pleno funcionamiento. Verifique la resincronización.
2. Move Machine2 : póngalo en pleno funcionamiento.
3. Move Machine1 : póngalo en pleno funcionamiento.

Descripción más detallada de la mudanza:

Lo siguiente incluye dos métodos (Ruta A y B) de usar Machine3 para probar las conexiones de Machine1 y / o Machine2 . Solo debes usar un método. La forma de hacerlo, o incluso si se usa, depende de la información no contenida en la pregunta (por ejemplo, separación física de las ubicaciones finales de las máquinas, tamaño físico de las máquinas, longitud de la red / cables de alimentación, disponibilidad de extensiones para las mismas, similitud de configuraciones de puertos de red, necesidades de tiempo de actividad, etc.). El uso de Machine3 para probar estas conexiones potencialmente permite un mayor tiempo de actividad para Machine2 , pero particularmente para Machine1 , que no tiene espejo. Puede elegir usar cualquiera de los métodos o ninguno.

1. Mueva Machine3 primero.

   • Deje Machine1 y Machine2 en su lugar por ahora.
   • Backup Machine3 , luego apáguelo
   • Obtenga Machine3 completamente movido a la nueva ubicación.
   • [Ruta B: no se utiliza si va a utilizar el paso opcional n.º 2]. Si las configuraciones de red y alimentación para todas las máquinas son idénticas: coloque Machine3 donde Machine1 está previsto que termine utilizando las conexiones destinadas a Machine1 .
   • Haga que Machine3 vuelva a funcionar. En la nueva ubicación, verifique que esté funcionando normalmente como un espejo de Machine2 . Esto proporcionará una verificación física de que la configuración de todos los problemas (alimentación, red, etc.) son funcionales en la nueva ubicación.
   • Resuelva cualquier problema que surja.
   • Verifique que Machine3 se haya sincronizado completamente con Machine2 antes de continuar.

2. Ruta A: (Opcional):

   • Use Machine3 para probar todas las instalaciones destinadas a Machine2 y Machine1 .
   • Apague Machine3 y mueva / cambie a usar la posición / conexiones para Machine2 , (verifique la sincronización) y luego Machine1 (verifique la sincronización). Si planeaba hacer esto, entonces Machine3 debería haberse configurado inicialmente con las conexiones destinadas al uso final de Machine1 o Machine2 , por lo que no debe configurarlo primero en la ubicación final de Machine3 y luego cambiarlo 3 veces, pero solo 2 comenzando con él utilizando las instalaciones de una de las otras máquinas.
   • Verifique que Machine3 se haya sincronizado completamente con Machine2 antes de continuar.

3. Mover la máquina 2 .

   • Su práctica con Machine3 debería hacer esto mucho más suave.
   • Backup Machine2 , luego apáguelo
   • Mueva Machine2 a la nueva ubicación; hacer todas las conexiones
   • Resuelva cualquier problema que surja.
   • Verifique que Machine2 se haya sincronizado completamente con Machine3 antes de continuar.

4. [Ruta B: No es necesario si probó todas las conexiones con Machine3 en el paso opcional # 2] Si ahora tiene Machine3 donde Machine1 va a terminar:

   • Apague la máquina 3 .
   • Muévalo a donde está previsto que termine (fuera de la ubicación en la que desea que se ubique Machine1 ).
   • Resuelva cualquier problema que surja.
   • Verifique que Machine3 se haya sincronizado completamente con Machine2 antes de continuar.

5. Mover la máquina 1 .

   • Después de haber movido tanto Machine2 como Machine3 (y esperamos haber probado las conexiones reales que Machine1 usará haciendo que Machine3 las use temporalmente), este debería ser el más suave de los movimientos.
   • Backup Machine1 , luego apáguelo
   • Mueva Machine1 a la nueva ubicación; hacer todas las conexiones
   • Resuelva cualquier problema que surja.
   • Si algo sale mal con las instalaciones en la posición que se supone que Machine1 debe ocupar, tiene la opción de utilizar las instalaciones donde ahora se encuentra Machine3 . Esperemos que ya haya podido probar todas las instalaciones en la posición de Machine1 haciendo que Machine3 ya lo haya usado durante un tiempo (Ruta A o Ruta B).

Si alguna de las direcciones IP de los servidores cambiará y se realizan conexiones al cuadro SQL mediante resolución DNS, deberá programar un cambio en los registros DNS al mismo tiempo que la mudanza.

Cosas que debe saber sobre el software y las bases de datos de la intranet:

• ¿El software de intranet se conecta al servidor SQL a través de IP, NetBIOS o DNS?
• ¿Las cuentas de usuario de SQL Server utilizadas por el software de la intranet tienen autenticación limitada al tráfico proveniente de una IP?
• ¿Los empleados de su empresa acceden al SQL Server directamente desde cualquier hoja de cálculo o herramienta de informes? De ser así, ¿cómo definen el DSN?

Si no obtiene exactamente las mismas IP, o si termina en una subred diferente, necesitará acceso para cambiar el código fuente o los archivos de configuración para cualquier aplicación que se conecte al servidor SQL. La gente podría confiar en el acceso SQL indocumentado y directo para informes ad-hoc.

Utilice sus servidores de "Recuperación de desastres". Cambie a ellos para manejar la carga mientras mueve sus servidores de producción. Con el equipo DR configurado correctamente, puede hacer el movimiento a mitad del día sin ver mucho tiempo de inactividad (hasta 15 minutos). Como los servidores de recuperación ante desastres deben configurarse de la misma manera que los servidores de producción. Si no tiene equipo de DR, le recomiendo que los obtenga.

Piénselo de esta manera: mientras su corbeta se está afinando, use su minivan para pasar el día.

Una cosa que no creo que se haya mencionado es la seguridad física del nuevo hogar de los servidores. ¿Para qué se usaba la habitación antes y quién tiene las llaves? ¿Hay seguridad adecuada (sistemas de alarma, cámaras, etc.)?

Algunas consideraciones además de las otras respuestas:

• ¿Las aplicaciones están vinculadas a otras mediante, por ejemplo, el intercambio nocturno de datos por archivo o mediante el uso de servicios web? ¿Cuáles son las consecuencias cuando las aplicaciones no están disponibles? ¿Pueden las aplicaciones relacionadas hacer frente a esto o fallan o incluso producen resultados incorrectos debido a la falta de información de sus aplicaciones?

• ¿Es aceptable un tiempo de inactividad para sus usuarios, empresa o incluso clientes? ¿Cuánto tiempo puede ser?

• Creo que es una buena idea tener un plan para una reversión. Puede usarlo en caso de un problema que no se pueda resolver rápidamente, por ejemplo, un problema de red. Probablemente necesitará mantener el motor disponible para el caso de recuperar el hardware.

• ¿Sus aplicaciones conducen a un alto tráfico de red y la red tiene que estar preparada para esto (probablemente un problema mucho más improbable que problemas con direcciones y firewalls)? Si tiene aplicaciones en tiempo real (p. Ej., Software de videoconferencia), las latencias serán importantes.

• Los servidores deben caber en el bastidor del servidor si tiene uno.