Tengo 23 servidores web, necesito borrar todos los servidores, sin pérdida de servicio en ningún sitio alojado en ellos.

De acuerdo, es un desafío y tengo problemas para planificarlo principalmente debido a la falta de experiencia. Sin embargo, se ha convertido en una tarea en mi trabajo y lo hago principalmente solo con una mano extra.

Me siento cómodo con Linux y todos estos servidores son Debian o CentOS. Algunos son VPS, hosts compartidos y otros son máquinas virtuales en la nube. Soy nuevo en la empresa y solo he tenido tiempo en los últimos meses para hacer un balance de los problemas pendientes. Todos corren plesk o cpanel.

Encontré que estos servidores nunca se configuraron, solo se compraron y se lanzaron sitios con administración muy básica en los últimos dos años (limpieza de espacio en disco y tareas de administración de dominio / hosting en su mayoría). No se configuraron iptables ni se tomaron precauciones de seguridad, por lo que estos servidores están enigmáticos. Me imagino que la mejor solución aquí es comenzar de nuevo y consolidar nuestro alojamiento a menos servidores, ya que acaban de comprar nuevos servidores compartidos por completo. Siento que podemos apoyar a toda nuestra base de clientes en aproximadamente 1/4 de nuestro clúster.

Mi problema es que no estoy seguro de cómo planificar este movimiento. Se requerirán MUCHOS sitios móviles y cambios de DNS. Creo que sería prudente buscar el consejo de cualquier asistente que se ocupe de este tipo de cosas regularmente o al menos tenga la experiencia para orientarme en la dirección correcta.

Barro

No hay una solución simple para esto: probablemente será un camino largo y molesto para que todo se mueva. Comenzaría con algunas cosas, pero el libro que recomendé en los comentarios probablemente incluye algunos detalles. Veo cuatro etapas principales aquí: inventario, redistribución, prueba y aceptación.

• ¿Qué estoy alojando ahora?

Si aún no lo ha hecho, haga un inventario completo de lo que tiene y lo que está usando ahora. Identifique cuáles son los recursos críticos y qué están ahí sentados. Esta pregunta sobre SF puede ser un buen comienzo, aunque, naturalmente, deberá ajustarla para un entorno debianisque, tal vez así . Esta es la etapa más crítica .

Los servidores 'web' no son todos iguales: verifique si está ejecutando algún proceso que ejecute su propio servidor web (como django) o si es un servidor web independiente como apache.

• reevaluar la configuración actual para las mejores prácticas

¿Está utilizando versiones EOLed de su sistema operativo y otro software? ¿Puedes migrar? ¿Qué problemas enfrentarías? ¿Hay algún riesgo de seguridad conocido? ¿Puedo estandarizar todo a una única versión de todo mi software? ¿Puedo automatizar mis procesos de implementación y hasta qué punto? (Ver títeres y chef).

• crear un conjunto de pruebas para cada servidor

Haga una lista de lo que debe funcionar y cómo lo va a probar

• decide a qué te estás mudando

De esa manera, puede elegir el mejor proceso P2V o V2V para sus necesidades.

• decide qué consolidar

Puede elegir ejecutar varios conjuntos de servicios que estaban separados antes en un servidor. También puede optar por ejecutar máquinas virtuales. Tanto la ejecución de máquinas virtuales muy específicas de la tarea (puede reiniciar una sin afectar otras cosas) como la agrupación de tareas similares (para que tenga menos sistemas lógicos que mantener) tienen ventajas

• configurar un entorno de prueba aislado

De esta manera, puede configurar y probar un movimiento del sistema sin que se interponga en la producción. Es probable que pueda hacer esto en un único servidor que ejecute máquinas virtuales.

• tener un área de preparación para sistemas probados

Mueva las máquinas virtuales al área de ensayo y pruébelas por última vez

• Utilice ventanas de mantenimiento para pasar a los nuevos sistemas.

Establezca un breve dns ttl para sistemas que se han migrado con éxito y cambie el nombre de dominio y otras configuraciones relevantes durante una ventana de mantenimiento. Prueba de nuevo. Esté atento a cualquier error una vez que se haya implementado el nuevo servidor

• No destruya las instalaciones antiguas del servidor hasta que pueda verificar que el nuevo funciona

Cúbrase. Si algo sale mal, en el corto plazo, siempre puede recurrir al servidor anterior.