miércoles, 7 de noviembre de 2018

¿Cómo es hacer un migrado de servidores?

Mi trabajo ahora mismo está siendo el de migrar los servidores de un proyecto de banca alemana, y eso, como os podréis imaginar es algo que lleva su tiempo y paciencia. Pero si os fijáis, he dicho tiempo y paciencia y no "es complicado".


Voy a dejar el apartado de qué equipos utilizar físicamente, ya que eso es algo que yo simplemente no me encargado, así que os comentaré de lo que me he encargado y algunas cosas en las que he ayudado. Ya veréis como no es tan complicado hacerlo, por lo que la excusa de "es difícil y pueden darse errores graves" no es más que eso, una excusa, ya que yo lo he hecho en un entorno bancario grande y en PROD.

Lo primero por supuesto es que si vamos a hacer un migrado de servidores, el SO sea el más actualizado. Yo siempre recomiendo Debian, y sino CentOS o RedHat para entornos de servidores ya grandes. Muy interesante sobre todo que en las últimas versiones de RedHat ya tenemos Btrfs como sistema de archivos. Esto es algo que suma.

Después es muy importante el cómo se va a instalar el SO ¿Cuántas particiones? ¿Vas a dejar cada directorio principal en una partición distinta? Estas son preguntas que se tienen que hacer, ya que dejar una instalación por defecto es algo que, aunque no lo creáis, dará problemas antes o después.

Pero bueno, tenemos instalado nuestro sistema ¿qué más? Pues aquí dependerá de las características del proyecto, ya que te pueden decir que dejes una estructura igual que la anterior o que utilices los mismos datos pero con una arquitectura del sistema de archivos distinta. Yo voy con la segunda que es "más difícil".

Lo que tenemos que hacer ahora es realizar la arquitectura que se nos pida y ojo, que si ahora queremos cambiar que, por ejemplo las llaves SSH no estén en $HOME/.ssh/authorized_keys tendremos que especificarlo debidamente en el archivo de configuración. Cuando tengamos toda la arquitectura montada, que por lo general suele ser fácil, más que nada tocar ficheros de configuración y asignando valor a variables del sistema con export. Esto es algo recomendable para mejorar la seguridad de nuestros servidores con técnicas de seguridad por oscuridad.

Tras esto, lo que tendremos que hacer es pasar los datos, tanto de usuarios. Ojo, que los usuarios de un proyecto grande son muchos. Imaginad mi caso, un caso en el que tienes que hacer el migrado de los servidores en los que hay usuarios de Italia, España, Alemania, Portugal, India, Reino Unido e Italia. Esto no puedes ir uno por uno. Para eso, previamente has tenido que hacer los deberes y agregar a cada usuario a un netgroup de Linux. Así ya lo único que tendríamos que hacer será añadir el netgrop al servidor NIS nuevo vía Web GUI y después añadir el netgroup al archivo /etc/groups del servidor{es} nuevo{s}.

Os juro que es mejor añadir 10 netgroups que 10000 usuarios, además que ya tendríamos creados los usuarios y se crearían automáticamente sus home directories conforme hagan login. También tendríamos guardados sus permisos dentro del sistema, el group al que pertenece,etc. Vamos, que hemos ahorrado mucho trabajo.

No sé si os dais cuenta que ya lo que nos queda es algo tan tonto como ver qué datos necesitamos migrar sí o sí, meterlos en un contenedor con tar -cvzf, enviarlo con scp o incluso rsync y finalmente hacer un tar -xvzf. Y ya está. 

Bueno, ni que decir tiene que debemos tener previamente instalados todos los programas necesarios, y además he dicho de pasar los archivos por scp, pero si utilizamos claves ssh, antes de enviar los datos, tenemos que añadir esas claves (tan difícil como hacer otro tar y enviarlo con un usuario que ya tenga su clave ssh o que sepa su contraseña -normalmente este usuario suele ser root-). Añadimos cada clave del authorized_keys del antiguo servidor al nuevo y además la id_rsa.pub de cada usuario para poder hacer el scp, ya que una cosa es que pueda acceder al servidor y otra muy distinta que pueda o no enviar archivos.

Yo recomiendo utilizar el from clause (stanza) para no liarnos, por ejemplo

from="servidor_viejo" [Llave SSH]  [usuario]

Y así con cada llave ssh. Esto no es necesario, pero es simplemente para saber a quién pertenece cada llave. No os preocupéis porque el from y el usuario son tratados como meros comentarios, lo que importa es que la ssh key esté correcta.

And that's all. Ahora en serio ¿Lo veis tan complicado como dicen? Por supuesto pueden ocurrir problemas, a mí me han surgido problemas, pero cuando los analizas ves que no son gran cosa. Ni que decir tiene que si tenemos un Apache, tendríamos que configurarlo también, aunque si ya lo hicimos de forma correcta y tal y como conté en "El server me sabe a poco", pues ya es un poco menos de trabajo que tenemos que hacer, aunque recomiendo que se revisen todos los archivos de configuración de todos los servicios por si acaso.

Pero no es tan difícil como se suele hacer ver. Simplemente hay que ponerse y dedicarle horas, ya está, no hay otro secreto. Si ocurre un error, toca analizarlo y ver qué solución tiene, pero ya está. Es cierto que depende mucho de que anteriormente se haya hecho un trabajo medianamente bueno, pero ni aún así, no hay excusas, somos administradores de sistemas y estamos para esto.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...