Así migramos nuestro viejo servidor web con VMware a uno nuevo con Proxmox sin un minuto de caída y multiplicando por 4 su rendimiento

De dónde partimos antes de llevar a cabo la migración

Nuestras circunstancias

GEEKNETIC y PRONETIC, los buques insignia de nuestra pequeña editorial y donde actualmente estás leyendo este artículo, son webs de alto tráfico que requieren de muchos recursos para funcionar y que el acceso a los artículos publicados sea rápido para el lector. Eso significa que con un simple hosting no basta, necesitamos algo mucho más potente.

Además, como ambas son publicaciones técnicas sobre informática, GEEKNETIC para consumo y PRONETIC para empresas, todos los redactores y la mayoría del equipo somos ingenieros o técnicos informáticos. Esto nos permite tener los conocimientos y experiencia necesarios para administrar nuestra propia infraestructura de servidores, sin tener que depender de terceros.

El hecho de tener nuestra propia infraestructura, aparte de ahorrar costes, también nos permite poder adaptarlo a todas nuestras necesidades. Una de esas necesidades es tener la potencia necesaria para poder dar acceso a millones de lectores cada mes a nuestros artículos (y eso sin contar con los bots que también nos hacen consumir recursos).

Además, somos una empresa pequeña y nuestros recursos son limitados, algo como tener un rack entero para nosotros o disponer de una estructura de servidores Enterprise es impensable.

El viejo servidor que vamos a reemplazar

Disponemos de varios servidores dedicados, algunos en propiedad y otros alquilados, repartidos en distintos CPDs. El servidor en cuestión que queremos reemplazar es uno que tenemos en propiedad, y es nuestro servidor más importante. Es el servidor web que sirve las webs de GEEKNETIC y PRONETIC y gestiona todos los servicios y bases de datos dedicados al Front-end de estas webs.

Es un servidor Dell PowerEdge R515 que compramos en enero de 2014, y como no puede ser de otra manera, le hicimos una buena review antes de hacer el despliegue, puedes leerla aquí. Dispone de 2 CPUs AMD Opteron 4300, 128GB de memoria DDR3 ECC registrada, conectividad 1Gbps dual y 12 frontales hot-swap de 3,5 pulgadas.

El almacenamiento estaba gobernado por una controladora RAID Dell PERC H700, con 1GB de caché propia. Con ella montamos un RAID 10 compuesto por 4 discos duros de 2TB cada uno dando un volumen de 4TB en total.

Con el paso de los años le hemos hecho unas cuantas actualizaciones, desde más almacenamiento, sustitución por SSDs y más memoria RAM.

Entorno de Virtualización y Máquinas Virtuales

El hypervisor que elegimos en su día fue ESXi 5.5, inicialmente la Community Edition. Es una versión que requería de instalar vSphere en el Windows cliente para poder administrarlo, no es como las versiones modernas que tienen el interfaz web.

Poco después adquirimos la licencia de VMWare, empujados principalmente por la necesidad de hacerlo compatible con Nakivo, la solución que elegimos en su día para copias de seguridad, tal como explico en el siguiente apartado.

Las máquinas virtuales, en el momento de realizar la migración se componen de lo siguiente:

• 1 x MV Windows Server con IIS para ejercer de servidor web
• 1 x MV Linux con Apache para ejercer de servidor web
• 2 x MV Linux con bases de datos MySQL en distintas versiones
• 1 x MV pfSense que genera una red interna y nos hace de router y firewall

El ESXi es stand alone, es decir, no hay vCenter, no hay orquestación ni, balanceo, ni nada por el estilo.

Copias de seguridad

Las copias de seguridad están gestionadas por NAKIVO. En lugar de ser copias de seguridad al uso, son clonaciones exactas de las máquinas virtuales hechas en caliente y con registro incremental.

Esto lo hacemos así porque, al menos en nuestro despliegue y con el sistema de NAKIVO, si necesitamos rescatar una copia de seguridad, el tiempo en obtener la copia y levantarla era mucho más lento de lo deseado. Sin embargo, los clones no tenemos más que arrancarlos en el servidor de copias, cambiar el DNS y ya tenemos todo funcionando de nuevo con relativa rapidez.

Los clones se guardan en otro servidor dedicado que tenemos en un CPD completamente distinto en otra ciudad. Así evitamos que si ocurre algún desastre que geográficamente afecte uno de los CPDs no afecte al otro. Al fin y al cabo, no es la primera vez que un CPD entero se incendia, y sino que se lo digan a OVH. Cuando tienes un negocio que depende de internet y de lo que tienes en el CPD, toda precaución es poca.

Desencadenantes que provocan la necesidad de migración

Aunque hemos estirado la vida del servidor todo lo que hemos podido, y de hecho hace tiempo que debería haber finalizado su vida útil teniendo en cuenta que era nuestro servidor web principal, ha habido una serie de razones que nos han empujado más si cabe a llevar a cabo la migración.

Por un lado, en enero de 2025 lanzamos esta segunda publicación: PRONETIC. Al ser una publicación hermanada con GEEKNETIC, donde ya tratábamos muchos temas de servidor en el pasado, no nos ha sido difícil hacerlo crecer. Nuestro enfoque mucho más técnico y práctico nos ha permitido llenar un importante hueco que existía entre el público hispanohablante. Así, a mitad de 2025 con solo unos meses de vida PRONETIC ya se había consolidado como uno de los medios más visitados sobre tecnología para empresas. Esa oleada de tráfico nuevo constante y creciente ha puesto más presión sobre un servidor que ya estaba llegando al límite sirviendo el tráfico para los lectores de GEEKNETIC.

Por otro lado, en GEEKNETIC tenemos un nuevo proyecto que es el Comparador de Precios. Se trata de una herramienta gratuita para el usuario que permite comparar componentes, periféricos, portátiles y PCs con filtros muy avanzados y precios en tiempo real para encontrar el producto ideal que encaje con lo que estás buscando. Al mismo tiempo en cada producto se muestra el precio en tiempo real de todas las tiendas que lo ofrecen en España.

Para poder ofrecer los precios en tiempo real, las tiendas con las que colaboramos nos facilitan un feed XML, JSON o CSV con todos sus productos que nuestro servidor lee 8 veces al día. No solo es cuestión de leer esos feeds, se tienen que procesar y actualizar nuestra base de datos para mostrar al usuario los precios actualizados para cada producto. Esto es algo que ocurre entre bastidores, pero cada vez que nuestro servidor actualiza precios se tira 2 horas.

Para un comparador de precios que aspira a ofrecer precios en tiempo real, 2 horas de retraso es inaceptable, pero es lo que era capaz de hacer nuestro viejo servidor. Una de las ideas era contratar un servidor externo que procesara los datos y luego se vertieran en el servidor de producción, pero eso hacía que todo fuera mucho más complejo.

Finalmente, si juntamos todos los condicionantes, la decisión más acertada era jubilar el viejo servidor Dell PowerEdge y comprar y montar otro mucho más potente y moderno que se ajuste mejor a nuestras decisiones actuales.

El Nuevo Servidor

El Hardware

Hoy en día para una empresa pequeña montarte tu propio servidor nuevo comprando un barebone es relativamente accesible y sencillo, si tienes la capacidad técnica para hacerlo, como es nuestro caso. Alternativamente puedes irte a un integrador de servidores como PC Specialist.

Irte a Dell, HPE o similares sigue siendo una opción, pero aparte de que el precio se dispara, es más apropiado para empresas más grandes. Es por ese motivo que hemos seleccionado un servidor de Gigabyte, que ofrece unas soluciones excelentes para servidores de todo tipo. Servidores que ellos mismos fabrican.

En cualquier caso, el modelo exacto no se puede elegir sin tener en cuenta el tipo de CPU que deseas. Nosotros nos hemos decantado por 2 CPUS AMD EPYC 9374F (Genoa) de 32 núcleos y 64 hilos cada uno. La variante F es ideal porque la frecuencia turbo es considerablemente más alta, alcanzando 4,3 GHz. Esto es especialmente importante para el procesamiento mono-hilo que requiere el procesamiento de los feeds del comparador de precios y también lo hace tremendamente rápido para servir webs. Esta familia de CPUs es la primera de AMD compatible con el socket SP5 y nos permite usar PCIe 5.0 y DDR5.

Ya que nuestro servidor no es para IA ni nada por el estilo, un servidor Rack 2U de última generación compatible con estas CPUs es lo más apropiado. El que hemos elegido es exactamente el Gigabyte Rack Server R283-Z96-AAE1. Es un servidor fantástico, con su propio BMC-IPMI, nos viene con fuentes de alimentación redundantes y con la refrigeración para ambas CPUs.

El servidor originalmente viene con 2 puertos RJ45 a 1Gbps, pero hemos adquirido una tarjeta de red Gigabyte CLNCB22 con 2 conectores SFP de 10Gbps cada uno.

La RAM está compuesta por 12 módulos G.Skill G5 Neo F5-6000R3036G16GQ4-G5N de 16GB cada uno para un total de 192 GB. Son memorias RDIMM DDR5 ECC registradas que gracias a sus perfiles AMD EXPO nos dan 6000 MT/s con una latencia CAS de 34.

Para el almacenamiento nos hemos decantado por 4 SSDs KIOXIA CD8P-V de 6,4 TB cada uno. Son discos en formato U.2 compatibles con PCIe 5.0, que dan gran rendimiento gracias a sus chips BiCS Flash TLC de 5ª generación.

Para el RAID hemos adquirido la controladora de GRaid Technology SupremeRAID SR-1010. Es una controladora bastante innovadora que usa una GPU NVIDIA RTX 2000 integrada en la propia solución para ejecutar el RAID en ella, en lugar de cargar la CPU con el procesamiento. Así liberamos la CPU del procesamiento necesario para el RAID, que en tiempos actuales en que las lecturas y escrituras en un SSD PCIe 5.0 empieza a notarse en la CPU.

En este caso también hemos montado un RAID 10 con un único volumen para los 4 discos, lo cual simplifica considerablemente nuestra operativa al tiempo que añadimos velocidad y seguridad.

En total el servidor en esta configuración tuvo un coste aproximado de 20.000 Euros. Digo tuvo porque se adquirió todo en octubre de 2025 cuando la memoria y los SSDs todavía no habían subido tanto de precio. Hoy en día estimamos al menos 5.000 euros más.

Como no puede ser de otra manera, hemos publicado una review independiente de cada uno de los componentes. Puedes leerlas aquí:

• Servidor Barebone Gigabyte Rack Server R283-Z96-AAE1
• CPUs AMD EPYC 9374F (Genoa)
• Memoria RAM G.SKILL G5 Neo F5-6000R3036G16GQ4-G5N
• SSDs KIOXIA CD8P-V
• Controladora RAID GRaid Technology SupremeRAID SR-1010

El servidor fue montado y testeado por mi compañero Javier Rodriguez, jefe de nuestro laboratorio de Torrejón y la persona que está al frente de todas las reviews de servidores y workstations. Seguro que habréis leído muchos de sus artículos aquí en PRONETIC y en GEEKNETIC.

El entorno de virtualización

Como entorno de virtualización, lo más limpio hubiera sido seguir con VMWare ESXi y clonar las VMs fácilmente, sin embargo, hay una serie de cosas que nos lo dificultan.

• Para empezar VMWare desde que la compró Broadcom ya no es la plataforma amigable que era, la edición Community ya no existe y comprar licencias ya no es tan fácil como antes. Buena parte del sector está migrando a otras soluciones o está eligiendo otras soluciones en sus nuevos despliegues cuando las circunstancias se lo permiten.
• Por otro lado, nuestra nueva controladora RAID de GRaid Technology no es compatible con VMWare ESXi porque no hay drivers que lo soporten. No sabemos exactamente a qué se debe, pero no sería sorprendente que el hecho de que Broadcom sea la actual propietaria de VMWare y Broadcom tenga en su catálogo controladoras RAID, no lo hayan facilitado.

Las opciones compatibles con GRaid que nos quedan son:

• Proxmox VE
• Microsoft Hyper-V
• KVM/QEMU nativo en Linux.

Lo cierto es que nos ha sido muy fácil decantarnos por Proxmox VE. Es una plataforma madura, con gran soporte, con una comunidad enorme detrás, tremendamente estable, compatible al 100% con todos los componentes del nuevo servidor y con gran versatilidad. Además, tiene su propio sistema de backups nativo llamado PBS. Otro factor a tener en cuenta es la facilidad para importar discos virtuales VMDK de ESXi.

También hemos tenido en cuenta la soberanía digital, que con los tiempos que corren no puede ignorarse. Proxmox es una compañía de Austria, en plena Unión Europea, y de esta forma dejamos de depender de una compañía americana para nuestro entorno de virtualización.

Así, tras finalizar todas las pruebas en el laboratorio, se lleva a cabo una instalación limpia de Proxmox lista para el despliegue y migración.

Instalación del servidor en el centro de datos

Traslado

Nuestro laboratorio de pruebas para servidores se encuentra en Torrejón de Ardoz, en Madrid, sin embargo, el centro de datos donde quedará instalado está en Barcelona.

Para toda empresa pequeña como la nuestra los 20 mil euros que ha costado este servidor son mucho dinero. Además, los que trabajamos aquí vivimos de las revistas online GEEKNETIC y PRONETIC, por lo que este nuevo servidor es de suma importancia, así que tenemos que minimizar riesgos y protegerlo a toda costa. Es por este motivo por el que decidí no confiar en las agencias de transporte para trasladar el servidor una vez montado y yo mismo fui a Torrejón con mi propio vehículo a recogerlo y llevarlo personalmente al centro de datos.

Netcloudify: nuestro proveedor de co-ubicación en Barcelona

Netcloudify es una empresa que se dedica a ofrecer servicios de housing y administración de servidores a terceros. Su principal cartera de clientes está formada por operadores de fibra, a los cuales Netcloudify administra y opera los servidores que ejercen de núcleo para dichos operadores y gobiernan la conectividad de los usuarios de fibra. Netcloudify también ofrece servicios cloud, servicios IT y de co-ubicación.

Uno de los centros de datos en los cuales Netcloudify dispone de racks propios es Templus Barcelona, conocido antiguamente como Bitnap. Aquí es donde Netcloudify nos ofrece el servicio de co-ubicación en uno de sus racks para nuestro viejo servidor, y también donde colocaremos el nuevo.

Netcloudify se caracteriza por ser una empresa muy cercana, un trato muy personal y agradable y un acompañamiento continuo al tiempo de que disponen de equipamientos y conectividad a la altura de los tiempos que corren, con todo tipo de redundancias para garantizar que los servicios siempre estén operativos.

Lo primero que hemos pedido a Netcloudify es que nos asigne un nuevo rango de IPs para el nuevo servidor y que dejen estas activas ya en su router. De esta forma, antes de recoger el servidor en el laboratorio de Torrejón de Ardoz, pudimos preconfigurar las nuevas IPs para evitar tener que hacerlo al instalarlo en el centro de datos.

Instalación del servidor en el rack

Tras venir de Madrid cargado con el servidor, el siguiente paso es instalarlo en el rack de Netcloudify en el CPD de Templus. Me acompaña el gerente de Netcloudify para dar soporte y ayudar en toda la operación.

El servidor de Gigabyte ya viene con los raíles, como es habitual. Montamos los raíles primero. Acto seguido viene la complicada tarea de fijar el servidor en los raíles a pulso y asegurarlo para que quede seguro y bien sostenido.

Con el servidor ya en el rack, nos queda conectar los cables de corriente a las fuentes redundantes, los cables RJ45 al BMC/IPMI y los RJ45 a la tarjeta de red.

Un pequeño imprevisto es que la tarjeta de red de 2 x 10Gbps Gigabyte CLNCB22 no llego a tiempo, por lo que se tuvo que instalar posteriormente. No es un gran problema ya que nuestro servidor Gigabyte viene con un puerto posterior para tarjetas OCP 3.0 como la CLNCB22 con conectividad PCIe Gen5 de 16 líneas. Esto significa que no hay que sacar ni abrir el servidor, basta con quitar la tapa del puerto OCP posterior, insertarlo y fijarlo con los tornillos. Hecho esto podemos conectar los conectores SFP que vienen del router y retirar los RJ45 de la tarjeta de red que venía integrada con el servidor.

El servidor viejo, que en el momento de instalar el nuevo aún sigue sirviendo las webs lo dejaremos un tiempo en su sitio para ejecutar la migración.

Con la instalación del servidor en el rack ya completa, y tras comprobar con una red externa que tenemos acceso a administrar tanto el Proxmox VE como el IPMI, podemos marcharnos y continuar el resto del proceso en remoto.

Preparaciones previas a la migración

Definiendo el método de migración

Las máquinas virtuales que vamos a mover contienen webs en vivo cuyo funcionamiento es lo que da de comer a unas cuantas personas (y familias) que trabajan aquí, yo mismo incluido, por lo que no es algo para tomarse a la ligera. Que GEEKNETIC o PRONETIC dejen de funcionar durante horas suponen miles de euros en pérdidas y puede tener también un impacto a largo plazo. Tenemos que hacer la migración sin que ninguno de los sitios web dejen de funcionar.

Teniendo esto en cuenta tenemos que hacer varios simulacros de migración para dar con el método ideal y calcular la duración del proceso, al tiempo de que nos aseguramos de que la migración funcionará y tendremos las máquinas virtuales funcionando correctamente en el servidor nuevo de forma estable. Un proceso que dura varios meses.

De buenas a primeras nos encontramos con una serie de limitaciones. La licencia de soporte de Nakivo hacía unos años que la habíamos dejado expirar, debido a que ya teníamos intención de pasarnos a un sistema nuevo y no necesitábamos actualizar las nuevas versiones ya que no nos aportaban nada nuevo que necesitáramos, hasta que nos hemos encontrado con la necesidad de migrar a Proxmox VE, y nuestra versión de Nakivo no lo soporta.

El problema de esto es que no puedes comprar una licencia de soporte nueva y listo, te obligan a pagar por todo el tiempo en que no has tenido el servicio de soporte activo, y la cifra era astronómica. Teniendo en cuenta que solo necesitamos usarlo para la migración y después dejaríamos de usar Nakivo del todo, no tenía sentido.

La solución más viable sin apagar las máquinas virtuales era clonarlas con Nakivo dentro del mismo servidor viejo, y después transferir las copias al servidor nuevo por ethernet. Una vez en el servidor nuevo convertimos las máquinas virtuales de VMWare a Proxmox, se hacen todos los ajustes necesarios y levantamos. Con la migración finalizada se cambian las DNS a las IPs del servidor nuevo y listo. Todo esto suena fácil y sencillo, pero no está exento de problemas y retos.

El servidor viejo dispone de una conectividad de 2Gbps, lo que en teoría debería darnos una velocidad de transferencia efectiva por ethernet máxima de 250 MB/s. Esto para 2 TB de datos hubieran sido aproximadamente 2 horas y 20 minutos en total. El caso es que, para copiar las máquinas virtuales de un host a otro, la forma más efectiva de hacerlo sin software de terceros es a través de la consola de administración de ambos entornos de virtualización. En el caso del Proxmox VE no hay problema, pero el ESXi 5.5 limita la velocidad de red del entorno de gestión, sea por vSphere o SSH a una fracción de la velocidad disponible, en nuestro caso a 22MB/s. Esto es una limitación por diseño del ESXi 5.5 que no puede eliminarse y está pensado para que en servidores viejos, la parte de gestión y administración del host no consuma demasiados recursos de los que necesitan las máquinas virtuales para funcionar. Al final esto supone que copiar los 2TB de discos virtuales de un host a otro lleva 26 horas y 30 minutos aproximadamente, suponiendo que no hay problemas durante la migración.

La alternativa hubiera sido acudir al CPD en persona y copiar los clones usando almacenamiento externo. El problema, aparte de que vivo a 4 horas del centro de datos, es que en el momento de realizar la migración el CPD se encuentra en obras y tienen restringido el acceso, por lo que no queda otra que continuar en remoto.

Ante un periodo de migración tan largo conviene planificar cada paso con mucha más antelación y hacer simulaciones para confirmar que todo funcionará tras finalizar la migración.

Tras las pruebas se determinó que el método más efectivo era mediante el comando rsync desde la propia consola Shell del ESXi. Al final tan solo necesitamos clonar los discos virtuales, ya que los componentes de la máquina virtual como la RAM, la CPU, la red, van muy casados con el host y entorno de virtualización que se está usando. Proxmox además tiene un sistema de migración de discos virtuales de VMWare que funciona realmente bien. Así, podíamos crear y definir la máquina virtual de destino directamente en el proxmox e importar el disco virtual una vez ha sido copiado y usarlo directamente como disco de arranque de la nueva máquina.

Resolviendo la integridad de los datos

Como hemos dicho, el plan es mantener en vivo las máquinas en el servidor viejo durante la clonación de forma que GEEKNETIC y PRONETIC sean funcionales y accesibles y en cuanto estén las copias levantadas en el servidor nuevo, se cambian las DNS. De esta forma el cambio para el lector es imperceptible y el downtime o tiempo sin servicio es literalmente cero.

El problema de hacer esto durante una ventana de casi 30 horas es que si hay escrituras o cambios durante esas 30 horas en las máquinas levantadas en el servidor viejo, es posible que dichos cambios no se vean reflejados en el servidor nuevo, con el riesgo de perder dichos cambios para siempre.

La solución por tanto requiere de preparativos y planificación que garanticen la integridad de los datos. En GEEKNETIC y PRONETIC la mayoría de los redactores trabajan entre semana en horario laboral. Por lo tanto, una de las soluciones es llevar a cabo la migración en fin de semana y dejar claro a todo el equipo que durante el periodo que dure la migración no pueden publicar ni modificar artículo alguno. De forma preventiva además se bloquea el acceso al sistema de gestión de contenidos o CMS de nuestras publicaciones durante el proceso de migración.

Existen otros datos que también podrían escribirse o perderse como los comentarios en nuestros artículos, mensajes o posts en el foro, subscripciones al newsletter, características del comparador de precios como suscribirte a ofertas de producto etc.

Por ese motivo nuestro equipo de programación preparo durante las semanas previas la opción de activar un bloqueo total a todo lo que pueda generar cambios en la web, mostrando al mismo tiempo el típico mensaje de “función no disponible por motivos de mantenimiento”.

Al mismo tiempo no es agradable dejar a los usuarios sin poder comentar, sin poder escribir en el foro y sin poder usar ciertas funciones del comparador durante el fin de semana elegido para la migración. No obstante, es un pequeño precio a pagar, y al menos los artículos, reviews, guías y noticias y posts del foro podían seguir siendo accesibles y legibles durante ese tiempo.

Configuración previa del DNS con TTLs bajos

Algo adicional a tener en cuenta es el TTL del DNS. Al final tu servidor DNS es la copia original del dominio donde están configuradas todas las reglas y el resto de los servidores DNS del mundo leen de tu zona original y cachean el resultado. Tú en la zona DNS de tu dominio puedes especificar para cada regla un TTL, es decir, el tiempo que quieres que otros DNS cacheen la información de tu dominio. Tener un TTL alto hace que acceder a una web sea más rápido porque tu propio equipo o en su defecto el servidor DNS que estás usando, tiene cacheada la información y no tiene que hacer la consulta al servidor DNS del dominio cada vez.

Por el contrario, un TTL bajo hace que se tenga que consultar el DNS del dominio con mucha más frecuencia para obtener la IP a la que dirigir la petición.

En nuestro caso la migración contempla un cambio de IPs. En este escenario bajar los TTL de las zonas DNS días antes de la migración nos permite que una vez la migración esté completada la propagación del DNS sea mucho más rápida y los usuarios accedan al servidor nuevo lo antes posible.

Tras completar la migración y ver que todo funciona podemos volver a aumentar el TTL de las zonas DNS para que pueda ser cacheado durante más tiempo.

Ejecutando la migración

Con todas las pruebas realizadas y todos los preparativos listos, llegó el fin de semana elegido para la migración. Así, un viernes por la noche en torno a las 20:00 hora de España al tiempo que se publicaba la última noticia del día, comenzaba el arduo proceso de migración.

Lo primero es desactivar comentarios, desactivar el acceso al CMS a los redactores, desactivar la escritura y cambios en el Foro y desactivar las funciones del comparador de precios que requieren de escritura.

Tras comprobar que todo sigue en funcionamiento y que efectivamente no pueden producirse escrituras, procedemos a ejecutar la migración.

Los pasos fueron los siguientes para cada una de las máquinas virtuales:

1. Clonación de la máquina virtual encendida usando Nakivo dentro del mismo servidor viejo a un datastore distinto en otro disco interno.
2. Copia de los discos virtuales del clon recién creado al servidor nuevo usando rsync desde la Shell del ESXi.
3. Creación de la máquina virtual en el servidor nuevo con Proxmox VE.
4. Migración del disco virtual desde el formato VMDK al formato que usa Proxmox.
5. Integración del disco virtual ya migrado en la máquina virtual
6. Arranque de la máquina virtual
7. Comprobación de que todo está correcto.
8. Instalación de drivers de Proxmox y QEMU Guest Agent.
9. Asignación de IPs internas.
10. En el caso del pfSense, asignación de las IPs externas.

Te dejo aquí una guía sobre cómo se importa un disco VMDK de VMWare en Proxmox VE a fin de clonar o migrar la máquina virtual.

Una vez todas las máquinas están levantadas en el servidor nuevo y antes de hacer el cambio de DNS probamos a acceder a las webs GEEKNETIC y PRONETIC y comprobar que todo funciona correctamente, para ello forzamos en nuestro PC el mapeo de IP al nuevo servidor. Esto puede hacerse fácilmente modificando el archivo del sistema “hosts”, aunque una opción más fácil y cómoda, que básicamente hace lo mismo es usar software gratuito como “Hosts File Editor”.

Llevando el servidor nuevo a producción

Una vez nos hemos asegurado de que todo va a la perfección, llega el momento de llevar el servidor nuevo a producción. Tal y como se ha hecho la migración, las nuevas máquinas virtuales en el servidor nuevo siguen teniendo los mismos bloqueos a la escritura únicamente en el servidor nuevo: se restaura el acceso al CMS a los redactores, se rehabilitan los comentarios en artículos y noticias, se habilita la escritura y modificación de posts en el foro, se vuelve a habilitar la suscripción al newsletter y se restaura el uso de funciones del comparador que requieren escritura.

Hecho esto procedemos a realizar el cambio de DNS para que todas las URLs de la web apunten al servidor nuevo.

Comprobamos que los usuarios ya están usando el servidor nuevo y éste acepta la carga de trabajo sin despeinarse. Hay otros pasos que no forman parte de la migración en sí pero son igualmente importantes, se trata de los ajustes de rendimiento y el montaje del nuevo sistema de copias de seguridad, tal como explico en los próximos apartados.

Configuraciones Adicionales a la migración

Ajustes de Rendimiento

Con 112 hilos a nuestra disposición y 192 GB de memoria RAM tenemos que hacer el reparto de forma que tenga sentido para el uso que se le da a cada máquina virtual.

Las 5 VMs suman 176 GB, dejando 16GB adicionales para el Proxmox VE.

El problema más crítico no obstante está en el almacenamiento. Aquí hemos tenido que hacer muchísimas pruebas para dar con la configuración más rápida. La configuración de mayor rendimiento fue VirtIO SCSI Single, con iothread, AIO native, cache none y 8 colas de multiqueue.

Conseguimos pasar de 18.493 MiB/s a 27.859 MiB/s en lectura concurrente, lo que supone un 50% más de rendimiento de disco con respecto a usar VirtIO Block.

En escritura con alta concurrencia la mejora es aún superior, pasamos de 4.658 MiB/s en VirtIO Block a 10.770 MiB/s en VirtIO SCSI Single con 8 colas multiqueue, lo que es más del doble del rendimiento.

Hay que tener en cuenta que un entorno de virtualización siempre perjudicará el rendimiento en disco, pero dependiendo de la aplicación sigue saliendo a cuenta la versatilidad que ofrece frente al rendimiento del baremetal.

Copias de seguridad con Proxmox Backup Server

Proxmox ofrece su propio sistema de backups nativo llamado Proxmox Backup Server (PBS) y se integra directamente con el entorno de virtualización, de forma que desde el mismo Proxmox VE donde administras las máquinas virtuales, puedes gestionar las copias de seguridad. Tienes aquí una guía completa de instalación y configuración de Proxmox.

El PBS no tienes que ponerlo en el mismo host, de hecho, lo recomendable es tenerlo en un host aparte. Puede instalarse baremetal directo o como una máquina virtual en cualquier entorno de virtualización incluso en entornos de virtualización de terceros. Nosotros lo hemos llevado un paso más allá y no solo está en otro host, sino en otro CPD, en este caso de OVH, el mismo servidor alquilado donde guardábamos los clones hechos con Nakivo. En ese host el entorno de virtualización es VMWare y la máquina virtual con el PBS funciona a la perfección.

Con la máquina virtual del PBS instalada, el siguiente paso es asociarlo al entorno de virtualización Proxmox de nuestro nuevo servidor y configurar las copias de seguridad. Lo hemos configurado para hacer copias de seguridad cada día de madrugada, que es el momento de menos tráfico. También hemos configurado la eliminación de copias, manteniendo 1 copia semanal íntegra para las últimas 4 semanas más 1 copia incremental diaria para los últimos 7 días para todas las máquinas virtuales de producción. La eliminación de copias que no se desean mantener debe hacerse desde el propio PBS. Todo ello con sus correspondientes notificaciones por email que confirman a diario que las copias se han completado correctamente.

La primera sorpresa que nos llevamos es la velocidad con la que se producen las copias de seguridad. Estábamos acostumbrados a un proceso largo de varias horas a través de Nakivo, y resulta que en menos de 1 hora teníamos la primera copia integral hecha a todas las máquinas virtuales.

Medidas de Seguridad

Otra de las razones por las que nos hemos decantado por Proxmox VE es porque ofrece autenticación de múltiples factores o MFA con distintos sistemas y proveedores. Es lo lógico hoy en día en todo entorno crítico que se precie. Es lo primero que hemos activado en cuanto el servidor ha estado instalado en el CPD.

El BMC-IPMI desafortunadamente no ofrece esta opción, por lo que lo hemos tenido que proteger por VPN.

Para la red LAN interna gobernada por pfSense hemos instalado una VPN, de forma que todos los puertos quedan cerrados a excepción del 80 y el 443 que son los que se corresponden con http y https respectivamente. Todo lo que es desarrollo, administración remota de las máquinas virtuales y administración del pfSense como tal queda limitado al acceso por VPN a la LAN. Dicha restricción se replica adicionalmente en el firewall de cada una de las máquinas virtuales.

El PBS también queda protegido detrás de VPN en su correspondiente host.

Problemas durante la Migración

Como en todo proceso de despliegue complejo hay muchas cosas que no salen bien a la primera. A continuación, voy a detallar algunos de los problemas que nos hemos encontrado durante la migración y cómo los hemos resuelto.

Arranque de Windows Server en UEFI Shell

Uno de los problemas típicos al pasar de VMWare a Proxmox VE es que la configuración de BIOS/MBR no es compatible con el sistema por defecto de Proxmox: OVMF/UEFI. Ya en las pruebas previas a la migración vimos que haciendo esto el arranque de Windows se quedaba en la Shell UEFI.

La solución fue cambiar la configuración de la VM a SeaBIOS.

Pantallazo Azul en Windows Server al cambiar a VirtIO SCSI

El problema viene con el driver que se tiene cargado en Windows para el disco de arranque. En el servidor antiguo estaba configurado como SATA y en el servidor nuevo necesitamos que sea VirtIO SCSI para sacarle el mayor rendimiento. Cambiarlo simplemente en la configuración de la máquina provoca un pantallazo azul.

Para solucionarlo se usaron dos procedimientos que sí funcionaron en distintos momentos del ajuste: presentar primero un disco “dummy” VirtIO SCSI para forzar la detección del controlador y, en la optimización posterior, activar Modo Seguro con bcdedit, cambiar el disco a scsi0, arrancar una vez en modo seguro y después desactivar safeboot.

Hecho esto Windows arranca perfectamente y funciona con normalidad, sacándole todo el rendimiento que nos ofrece la controladora SupremeRaid y los discos SSD de Kioxia.

Kernel Panic en las VMs Debian Linux

Una de las máquinas Debian mostraba el siguiente mensaje: kernel panic - not syncing: attempted to kill init!

Tras descartar filesystem, UUID, initramfs y GRUB, se determinó que el kernel 4.9 antiguo fallaba al exponerse la nueva CPU del servidor nuevo, con características modernas para la que el Kernel de esta VM vieja no estaba preparada.

La solución fue cambiar temporalmente la CPU a kvm64 para poder arrancar, instalar un kernel compatible y después volver a cpu: host.

Hay que tener en cuenta que una VM antigua puede ser compatible con el disco migrado, pero aun así fallar por el cambio radical de CPU.

Windows se vuelve inestable en Proxmox debido a VMWare Tools

Es un problema típico que ya vimos en las pruebas previas a la ejecución de la migración. La cuestión es que retirar VMWare tools de forma previa mientras el servidor viejo con VMWare estaba en producción era un riesgo que no podemos correr.

Una vez se ha pasado la VM a Proxmox hay que retirar VMWare tools y limpiarlo completamente, de lo contrario la VM se vuelve inestable, incluso mantener una sesión de RDP sin que falle es complicado.

La limpieza de VMWare Tools es más compleja de lo que parece. Tuvimos que eliminar el autorun del VMware User Process, deshabilitar tareas/servicios residuales, drivers proporcionados por VMWare y desinstalar VMware Tools por completo.

Hecho esto ya se puede instalar el QEMU Guest Agent y desde ese momento ya va todo a la perfección.

Fin de la migración y retirada del viejo servidor

¿Qué hacemos con el servidor antiguo?

De buenas a primeras no nos atrevemos a retirar el servidor viejo durante los primeros meses, es una precaución por lo que pueda pasar. Desafortunadamente tampoco está a la altura como para hacer balanceado, y tampoco lo necesitamos por tanto no tiene sentido para nosotros mantenerlo en el CPD.

Su vida útil no obstante no ha llegado al final por lo que tenemos previsto trasladarlo a nuestro laboratorio de pruebas próximamente. Un servidor de estas características, aunque por su edad no lo usaría para tareas críticas sí que puede reaprovecharse para muchísimas cosas:

• NAS
• Servidor de Copias de seguridad
• Nube privada
• Entorno de virtualización para experimentos
• Servidor DNS
• Servidor VPN
• Controlador de dominio
• Servidor de IA agéntica

Este último, servidor de IA agéntica, es el uso que le tenemos previsto. Va a ser nuestro entorno de pruebas para IA agéntica e incorporar procesos de IA en nuestra organización. Muchas de nuestras pruebas las documentaremos igual que hicimos en esta guía de instalación y configuración de OpenClaw. Nuestra idea es que las automatizaciones que podamos demostrar viables desde este servidor se pondrán en marcha en un servidor de producción para IA agéntica que desplegaremos en el futuro.

Conclusiones Finales

Con la migración completada, todo funcionando al máximo de rendimiento y las copias de seguridad realizándose de forma rigurosa cada día, podemos dar por finalizado todo el proceso.

Han sido semanas de muchas pruebas, puestas a punto, resolución de problemas y finalmente el fin de semana dedicado a la migración. Para una empresa pequeña como la nuestra donde no tenemos sysadmins dedicados, ha sido un reto importante. El resultado no obstante ha valido la pena, la migración ha sido exitosa, todo funciona a la perfección y tenemos un rendimiento fantástico para nuestros sitios web, además de capacidad para seguir evolucionando y crecer.

Ha sido muy gratificante ver cómo el servidor nuevo respondía y el enorme salto de rendimiento que hemos obtenido, multiplicando la capacidad de procesamiento y reduciendo los tiempos de espera de procesamiento del servidor.

Sin ir más lejos el procesamiento de feeds del comparador de precios que con el servidor viejo tardaba 2 horas, ahora tarda 27 minutos. Hemos multiplicado por 4 la velocidad de procesamiento de los mismos.

Algo similar ha ocurrido con el procesamiento en vivo de páginas dinámicas en nuestros sitios webs. Antiguamente estábamos en unos 450 milisegundos por página de media y ahora estamos en 100 milisegundos.

Por mucho esfuerzo que nos haya costado estamos contentos con el resultado. Si estás en una situación similar te animo a que hagas lo mismo, siempre ejecutando la migración con tantas pruebas previas como te puedas permitir.

Fin del Artículo. ¡Cuéntanos algo en los Comentarios!