Migrar servidor en vivo

Estoy en problemas , tengo un servidor en ejecución con los servicios habituales (httpd, mail, sql), y parece que debo ser realmente rápido para evitar la pérdida total de datos (mi matriz RAID falló, así que estoy dependiendo de un solo HDD ahora).

Todo el sistema construido sobre los howtoForge's howto y mientras leo el de Squeeze , ¿parece que puedo fácilmente? migrar mis usuarios (virtuales) al nuevo cuadro.

Realmente sé que este es un problema muy específico, pero ¿podría decirme algún punto importante de todo el proceso de migración? ¿Qué cosas pueden ser complicadas, dónde debo concentrarme como máximo? ¿Cómo iniciarías el proceso?

Algunas informaciones de fondo:

• Los dos servidores están a 200 km de distancia, por lo que la migración debe realizarse por Internet.
• Ambos servidores serán Debian, el antiguo es Etch, el nuevo será Squeeze
• El servicio crítico es el correo, los sitios web pueden suspenderse por algún tiempo
• RAID significa dos discos en RAID 1 (ambas máquinas)
• El cuadro anterior es el DNS1 para todos los dominios alojados.

Mi (realmente) esquema básico:

• Creación de un sistema similar al anterior (estructura de correo virtual similar, contraseñas almacenadas con el mismo tipo de cifrado, porque no puedo distinguir las anteriores)
• crear un dominio donde pueda verificar que todo esté bien (dns, correo electrónico, www están bien)
• Migre dominio tras dominio hasta que el anterior no haga nada

Mis puntos ciegos

• No puedo encontrar una breve descripción sobre cómo hacer un RAID-1 en Squeeze (¿será suficiente un tutorial de Lenny?)
• ¿Cómo copiar carpetas específicas (por ejemplo, carpetas de correo de los usuarios) con derechos de usuario específicos cuando sea necesario? (rsync hará esto?)
• Cómo configurar DNS en la nueva máquina (la anterior es DNS1) (¿la nueva máquina también debería ser DNS y los dominios migrados deberían usarse como DNS1?)
• ¿Cómo puedo evitar la pérdida de correo electrónico (debido al tiempo de actualización de DNS) (necesito configurar la nueva máquina como MX?)

Su esquema básico es más o menos correcto.

El instalador de squeeze hará un RAID de software muy bien. Un punto de diferencia es que squeeze usa grub2 por defecto; Lenny usó grub-legacy (0.9 creo). Esto hace que la administración de grub sea algo diferente, especialmente para garantizar que grub se inicie desde ambos discos en caso de falla. Siempre puedes volver al legado de grub, que es lo que terminé haciendo la última vez que me enfrenté a este problema. Sin embargo, pagaría probar lo que sea que esté haciendo, para asegurarse de que puede reiniciar si alguno de los discos falla.

Para copiar datos, use rsync con seguridad. Me aseguraría de que las cuentas correctas estén configuradas primero, con los mismos uids / gids, luego rsync, pero siempre puedes arreglar esto después. rsync -avPHAX debería obtener todo (-a obtiene la mayoría de las cosas, excepto -H [enlaces ardientes] -A [CLs] y -X [atributos tendidos], por lo que esto es útil.

Dado que está haciendo una actualización efectiva al mismo tiempo, prepárese para que los servicios se rompan de manera sutil. Las configuraciones cambiarán ligeramente. Habiendo hecho algo similar recientemente, creo que preferiría hacer una migración similar a>, luego actualizar el host final en algún momento después del hecho, ya que migrar todo y administrar las actualizaciones al mismo tiempo lo convirtió en una tarea gigantesca.

Actualizado para sus puntos de dolor adicionales:

Para DNS, movería todo el alojamiento de DNS a la nueva máquina en un solo paso. Deje los registros como están para comenzar, pero establezca la actualización (10 minutos más o menos). Esto le permite mover registros DNS a la nueva máquina a medida que completa el movimiento de cada dominio. Mover su DNS puede requerir la actualización de los registros whois de cualquier dominio que aloje, así que tenga esto en cuenta. Establezca la actualización para todos los dominios en este momento, de hecho, antes de comenzar cualquier otra cosa, nada peor que tener un resultado mal almacenado en caché que causa problemas.

Con respecto a la pérdida de correo electrónico: a medida que mueve el correo al nuevo servidor, asegúrese de que los registros DNS se hayan actualizado para apuntar el MX primario al nuevo servidor, y asegúrese de que el servidor anterior todavía esté configurado para permitir la retransmisión de sus dominios. Mientras sus servidores antiguos y nuevos tengan vistas actualizadas de DNS, su servicio de correo en el servidor anterior funcionará, ya no es el MX primario y reenviará cualquier correo electrónico al nuevo primario. El correo también se ocupará de demoras breves en la entrega, por lo que podría cerrar o cortafuegos todo el acceso de correo electrónico a ambas máquinas, mover todo de una vez, probarlo en la nueva máquina, luego mover los registros MX y abrir el correo en la nueva máquina . SMTP está diseñado para hacer frente a interrupciones, y cualquier interrupción razonablemente corta (creo que menos de 4 horas) ni siquiera generará notificaciones de error temporales.

Actualizado para agregar:

Otra posibilidad es crear una VM en su nuevo servidor y sincronizar todo el antiguo servidor en la imagen de disco de esta nueva VM. Luego puede encender la VM y actualizar las direcciones IP, etc., y tener una réplica completamente funcional del servidor original dentro de esta VM. Potencialmente, mucho menos esfuerzo, pero si no está familiarizado con las pilas de VM como KVM o Virtualbox, entonces puede que no valga la pena.