{"id":18764,"date":"2026-06-09T19:40:56","date_gmt":"2026-06-09T19:40:56","guid":{"rendered":"https:\/\/made4it.com.br\/blog\/alternativas-a-vmware-en-2026-conozca-huawei-fusioncompute\/"},"modified":"2026-06-29T19:45:31","modified_gmt":"2026-06-29T19:45:31","slug":"alternativas-a-vmware-en-2026-conozca-huawei-fusioncompute","status":"publish","type":"post","link":"https:\/\/made4it.com.br\/es\/blog\/alternativas-a-vmware-en-2026-conozca-huawei-fusioncompute\/","title":{"rendered":"Alternativas a VMware en 2026: conozca Huawei FusionCompute"},"content":{"rendered":"\n

Quienes trabajan en el \u00e1mbito de la virtualizaci\u00f3n ya se han dado cuenta de que VMware se ha convertido en un tema distinto tras la adquisici\u00f3n por parte de Broadcom. El debate ha pasado de \u00ab\u00bfqu\u00e9 recursos necesito?\u00bb a \u00ab\u00bfcu\u00e1nto me va a costar esto en la pr\u00f3xima renovaci\u00f3n?\u00bb. En el caso de muchos clientes, esta conversaci\u00f3n ha dado pie a que surja Proxmox. Tiene sentido. Pero existe una tercera opci\u00f3n que casi nunca sale a relucir en las primeras reuniones: Huawei FusionCompute<\/strong>. <\/p>\n\n

La plataforma no es nueva ni experimental. Se encuentra en la versi\u00f3n 8.10, cuenta con una amplia documentaci\u00f3n t\u00e9cnica y casos de uso en empresas de telecomunicaciones, bancos y organismos gubernamentales de todo el mundo. <\/p>\n\n

En Brasil, todav\u00eda apenas se menciona en las conversaciones sobre la sustituci\u00f3n de VMware. Y quiz\u00e1 haya llegado el momento de analizarlo con m\u00e1s detenimiento. <\/p>\n\n

\u00bfQu\u00e9 es FusionCompute?<\/h2>\n\n

FusionCompute es la capa de virtualizaci\u00f3n de Huawei para centros de datos. Se ejecuta en servidores f\u00edsicos, proporciona m\u00e1quinas virtuales, gestiona la CPU, la memoria, la red y el almacenamiento, y forma parte de la soluci\u00f3n DCS de Huawei. <\/p>\n\n

La arquitectura gira en torno a dos componentes:<\/p>\n\n

CNA (Computing Node Agent):<\/strong> se ejecuta en cada servidor f\u00edsico, implementa el hipervisor UVP y gestiona las m\u00e1quinas virtuales de forma local.<\/p>\n\n

VRM (Virtual Resource Manager):<\/strong> El VRM es el cerebro central y se encarga de la gesti\u00f3n del cl\u00faster. Controla la programaci\u00f3n de recursos, el ciclo de vida de las m\u00e1quinas virtuales, la asignaci\u00f3n de direcciones IP y VLAN, y proporciona la interfaz web de administraci\u00f3n. Funciona en modo activo\/en espera con conmutaci\u00f3n autom\u00e1tica por error en un plazo de 1 a 2 minutos en caso de que el nodo activo deje de funcionar. <\/p>\n\n

El hipervisor UVP se basa en KVM, al igual que Proxmox, pero funciona en una arquitectura \u00abbare-metal\u00bb sin sistema operativo anfitri\u00f3n intermedio, de forma similar a ESXi.<\/p>\n\n

Tabla comparativa de las tres plataformas<\/h2>\n\n

<\/a> La tabla que figura a continuaci\u00f3n le ayudar\u00e1 a distinguir entre lo que constituye una diferencia real de arquitectura y lo que es simplemente una diferencia de presentaci\u00f3n comercial.<\/p>\n\n

Funcionalidad<\/th>VMware ESXi \/ vSphere 8<\/th>Proxmox VE 9.2<\/th>Huawei FusionCompute 8.10<\/th><\/tr><\/thead>
Tipo de hipervisor<\/strong><\/td>Bare-metal (ESXi)<\/td>Tipo 1 (KVM + QEMU)<\/td>Bare-metal (UVP\/KVM)<\/td><\/tr>
Hosts por cl\u00faster<\/strong><\/td>hasta 96<\/td>Sin l\u00edmite expl\u00edcito*<\/td>hasta 128<\/strong><\/td><\/tr>
M\u00e1quinas virtuales por cl\u00faster<\/strong><\/td>hasta 8.000<\/td>Sin l\u00edmite expl\u00edcito<\/td>hasta 8.000<\/strong><\/td><\/tr>
Licencias<\/strong><\/td>Suscripci\u00f3n obligatoria; m\u00ednimo 72 colores por CPU <\/td>C\u00f3digo abierto (asistencia t\u00e9cnica de pago opcional)<\/td>Licencia comercial de Huawei<\/td><\/tr>
VM HA<\/strong><\/td>\u2705<\/td>\u2705<\/td>\u2705 autom\u00e1tico, independiente del nodo de gesti\u00f3n<\/td><\/tr>
Migraci\u00f3n en vivo<\/strong><\/td>\u2705 vMotion<\/td>\u2705<\/td>\u2705<\/td><\/tr>
Migraci\u00f3n en vivo del almacenamiento<\/strong><\/td>\u2705 Storage vMotion<\/td>\u2705<\/td>\u2705<\/td><\/tr>
Equilibrado autom\u00e1tico de la carga<\/strong><\/td>\u2705 DRS (incluso en el paquete)<\/td>\u2705 Equilibrador de carga din\u00e1mico (a partir de PVE 9.2)<\/td>\u2705 DRS + DPM integrados<\/td><\/tr>
Ahorro autom\u00e1tico de energ\u00eda (DPM)<\/strong><\/td>\u2705<\/td>\u274c<\/td>\u2705 Desconecta autom\u00e1ticamente los hosts inactivos<\/td><\/tr>
Sobrecarga inteligente de memoria<\/strong><\/td>\u2705<\/td>\u2705 (globo)<\/td>\u2705 (ballooning + sharing + swapping; x86 y Arm)<\/td><\/tr>
Asignaci\u00f3n din\u00e1mica de recursos<\/strong><\/td>\u2705<\/td>\u2705<\/td>\u2705<\/td><\/tr>
Conmutador virtual distribuido<\/strong><\/td>\u2705 vDS (no incluido en el paquete de pago)<\/td>\u2705 OVS\/SDN<\/td>\u2705 DVS nativo<\/td><\/tr>
SR-IOV<\/strong><\/td>Limitado<\/td>\u2705<\/td>\u2705<\/td><\/tr>
Passthrough de GPU<\/strong><\/td>\u2705<\/td>\u2705<\/td>\u2705<\/td><\/tr>
Virtualizaci\u00f3n de GPU<\/strong><\/td>\u2705 (vGPU de NVIDIA)<\/td>\u2705 (vGPU de NVIDIA, a partir de 2025)<\/td>\u2705 (vGPU de Intel integrada)<\/td><\/tr>
Contenedores \/ K8s nativo<\/strong><\/td>\u274c (Tanzu, independiente y de pago)<\/td>\u2705 (LXC; sin K8s nativo)<\/td>\u2705 K8s integrado<\/td><\/tr>
Multitenencia completa<\/strong><\/td>\u2705 (con complementos)<\/td>\u274c<\/td>\u2705 (VPC, ECS, ELB, NAT, etc.)<\/td><\/tr>
DR orquestado<\/strong><\/td>\u2705 SRM (de pago)<\/td>\u274c<\/td>\u2705 UltraVR integrado<\/td><\/tr>
Copia de seguridad sin agente con CBT<\/strong><\/td>\u2705 (a trav\u00e9s de terceros)<\/td>\u2705 Proxmox Backup Server<\/td>\u2705 eBackup nativo<\/td><\/tr>
Compatibilidad con Arm<\/strong><\/td>\u274c<\/td>\u274c<\/td>\u2705<\/td><\/tr>
Caja negra de diagn\u00f3stico<\/strong><\/td>\u274c<\/td>\u274c<\/td>\u2705<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

La documentaci\u00f3n oficial de Proxmox no establece un l\u00edmite de nodos por cl\u00faster. El l\u00edmite pr\u00e1ctico depende del hardware de red y de la latencia; hay casos de cl\u00fasteres con m\u00e1s de 50 nodos en producci\u00f3n con hardware de nivel empresarial. <\/em><\/p>\n\n

Lo que llama la atenci\u00f3n de FusionCompute<\/h2>\n\n

Escala de cl\u00faster<\/h3>\n\n

FusionCompute admite 128 hosts y 8.000 m\u00e1quinas virtuales por cl\u00faster l\u00f3gico, con un m\u00e1ximo de 4.096 hosts y 80.000 m\u00e1quinas virtuales gestionadas por instancia. VMware alcanza los 96 hosts por cl\u00faster en vSphere 8. Proxmox no tiene un l\u00edmite m\u00e1ximo documentado, pero la estabilidad en cl\u00fasteres muy grandes depende en gran medida de c\u00f3mo se haya dise\u00f1ado la red de gesti\u00f3n. <\/p>\n\n

En el caso de los grandes centros de datos corporativos, la compatibilidad con 128 hosts por cl\u00faster, con una capacidad total de 80 000 m\u00e1quinas virtuales, supone una gran ventaja competitiva.<\/p>\n\n

DRS y DPM: programaci\u00f3n que ahorra energ\u00eda<\/h3>\n\n

El DRS de FusionCompute supervisa la carga de los hosts en tiempo real y migra autom\u00e1ticamente las m\u00e1quinas virtuales para equilibrar el uso de la CPU y la memoria en el cl\u00faster, sin necesidad de intervenci\u00f3n manual. Esto equivale a lo que ofrece VMware en el paquete de vSphere y a lo que Proxmox ha comenzado a ofrecer con el Dynamic Load Balancer de PVE 9.2. <\/p>\n\n

La ventaja distintiva de FusionCompute en este caso es el DPM (Dynamic Power Management)<\/strong>: cuando la carga del cl\u00faster disminuye, el sistema consolida las m\u00e1quinas virtuales en un menor n\u00famero de hosts y apaga autom\u00e1ticamente los servidores inactivos. Cuando la demanda aumenta, los hosts se vuelven a encender. Para entornos con una carga variable a lo largo del d\u00eda o de la semana, esto supone un ahorro energ\u00e9tico real sin necesidad de recurrir a la automatizaci\u00f3n externa. <\/p>\n\n

Sobrecarga de memoria en tres capas<\/h3>\n\n

FusionCompute combina el \u00abballooning\u00bb, el uso compartido de memoria (las p\u00e1ginas id\u00e9nticas entre m\u00e1quinas virtuales se consolidan en una \u00fanica copia f\u00edsica) y el intercambio de memoria para permitir que un servidor ofrezca m\u00e1s memoria virtual que la f\u00edsica disponible. Proxmox utiliza el \u00abballooning\u00bb, pero no implementa de forma nativa el uso compartido de memoria entre m\u00e1quinas virtuales. El resultado pr\u00e1ctico es una mayor densidad de m\u00e1quinas virtuales por host en FusionCompute, especialmente cuando las cargas tienen un perfil de uso de memoria similar. <\/p>\n\n

Esta funci\u00f3n es compatible tanto con x86 como con Arm, lo que supone una ventaja en entornos con servidores Kunpeng o similares.<\/p>\n\n

QoS de recursos por m\u00e1quina virtual con tres dimensiones<\/h3>\n\n

Mientras que Proxmox cuenta con controles b\u00e1sicos de cuotas y l\u00edmites de CPU, FusionCompute permite configurar tres par\u00e1metros independientes por m\u00e1quina virtual:<\/p>\n\n

Cuota:<\/strong> la proporci\u00f3n de CPU que recibe la m\u00e1quina virtual durante la competencia por los recursos entre m\u00e1quinas virtuales en el mismo host.<\/p>\n\n

Reserva:<\/strong> el m\u00ednimo garantizado de CPU que la m\u00e1quina virtual recibir\u00e1 siempre, incluso en condiciones de alta contenci\u00f3n.<\/p>\n\n

L\u00edmite:<\/strong> el l\u00edmite m\u00e1ximo absoluto de CPU que puede consumir la m\u00e1quina virtual, incluso cuando el host est\u00e1 inactivo.<\/p>\n\n

El mismo modelo se aplica a la memoria, la red y las IOPS de almacenamiento. Esto es importante cuando en un mismo cl\u00faster se combinan entornos de producci\u00f3n, validaci\u00f3n y cargas de trabajo menos predecibles. Sin una pol\u00edtica de recursos bien definida, una m\u00e1quina virtual que consume muchos recursos puede convertirse en un problema para otra \u00e1rea. <\/p>\n\n

Aislamiento de m\u00e1quinas virtuales en cinco capas<\/h3>\n\n

El hipervisor UVP implementa el aislamiento entre m\u00e1quinas virtuales en cinco dimensiones: recursos f\u00edsicos, programaci\u00f3n de vCPU (a trav\u00e9s de VMCS), memoria (con tres niveles de direccionamiento que impiden que las m\u00e1quinas virtuales accedan a la memoria de las dem\u00e1s), red interna (con VRF y filtrado de paquetes) y E\/S de disco.<\/p>\n\n

Adem\u00e1s, cada host cuenta con una \u00abcaja negra\u00bb<\/strong> integrada que registra informaci\u00f3n cr\u00edtica del n\u00facleo en memoria no vol\u00e1til cuando se produce una excepci\u00f3n. Ante cualquier fallo del sistema, los datos de diagn\u00f3stico se conservan para su an\u00e1lisis posterior, lo que simplifica considerablemente la resoluci\u00f3n de problemas en entornos de producci\u00f3n. <\/p>\n\n

La multitenencia como parte de la arquitectura<\/h3>\n\n

Proxmox no se ha dise\u00f1ado para el multitenancy. Las m\u00e1quinas virtuales de diferentes clientes pueden coexistir en el mismo cl\u00faster, pero el aislamiento de red y almacenamiento entre ellas es responsabilidad de quien realiza la configuraci\u00f3n, no de la plataforma. <\/p>\n\n

FusionCompute, integrado en la pila completa de DCS a trav\u00e9s de eDME, ofrece multitenencia nativa con una VPC por cliente, ECS con aislamiento completo, ELB, NAT, cortafuegos virtual y pol\u00edticas de almacenamiento independientes. Para quienes necesitan proporcionar recursos de TI como servicio a diferentes \u00e1reas de negocio o clientes, esta diferencia es de car\u00e1cter arquitect\u00f3nico. <\/p>\n\n

Copias de seguridad y recuperaci\u00f3n ante desastres dentro de la pila de Huawei<\/h3>\n\n

En Proxmox, Proxmox Backup Server gestiona bien las copias de seguridad, pero la recuperaci\u00f3n ante desastres (DR) coordinada entre sitios requiere soluciones de terceros. En VMware, Site Recovery Manager se encarga de ello, pero es un producto de pago adicional. <\/p>\n\n

En la pila DCS, UltraVR<\/strong> ofrece una recuperaci\u00f3n ante desastres (DR) orquestada compatible con topolog\u00edas de dos, tres o m\u00e1s centros de datos, con un RPO de cero en escenarios activos-activos y con conmutaci\u00f3n por error automatizada. eBackup<\/strong> realiza copias de seguridad incrementales permanentes de las m\u00e1quinas virtuales mediante CBT (Changed Block Tracking), sin necesidad de instalar un agente en cada m\u00e1quina virtual. <\/p>\n\n

\u00bfA qui\u00e9n le parece l\u00f3gico?<\/h2>\n\n

FusionCompute no encaja bien en cualquier contexto. Para entornos peque\u00f1os, con pocos hosts y un equipo que busca un bajo coste de licencia, Proxmox sigue siendo una opci\u00f3n muy s\u00f3lida. <\/p>\n\n

La situaci\u00f3n cambia cuando aparecen decenas de servidores, un SLA formal, la recuperaci\u00f3n ante desastres entre centros de datos, la separaci\u00f3n por \u00e1reas o clientes, y la necesidad de gestionar todo ello con menos componentes independientes. En este tipo de entorno, FusionCompute empieza a cobrar m\u00e1s sentido. <\/p>\n\n

Adem\u00e1s, resulta m\u00e1s natural cuando el cliente ya utiliza equipos de Huawei, especialmente servidores, sistemas de almacenamiento OceanStor o conmutadores CE. La integraci\u00f3n no lo resuelve todo, pero reduce los problemas operativos. <\/p>\n\n

Arm tambi\u00e9n podr\u00eda entrar en juego. Con el avance de los chips Arm en los centros de datos, la compatibilidad nativa de FusionCompute con los procesadores Arm \u2014que ofrecen las mismas funcionalidades que los x86\u2014 podr\u00eda ser un factor determinante en entornos que ya est\u00e1n considerando servidores Kunpeng o arquitecturas similares. <\/p>\n\n

La migraci\u00f3n de VMware debe abordarse con cautela. Migrar a Proxmox puede ser la decisi\u00f3n acertada en muchos casos, pero cuando el requisito es mantener funcionalidades empresariales como DRS, recuperaci\u00f3n ante desastres orquestada, calidad de servicio (QoS) por m\u00e1quina virtual y multitenencia, FusionCompute lo ofrece sin necesidad de implementar un amplio conjunto de herramientas externas. <\/p>\n\n

Contexto de mercado<\/h2>\n\n

El estudio de Gartner de 2024 revel\u00f3 que el 74 % de los responsables de TI estaban evaluando activamente alternativas a VMware. El soporte t\u00e9cnico para vSphere 7 finaliz\u00f3 en octubre de 2025, lo que aceler\u00f3 las migraciones de quienes a\u00fan estaban posponiendo la decisi\u00f3n. Y los clientes que aceptaron acuerdos puente de un a\u00f1o en 2024 se enfrentan ahora a renovaciones con la tarificaci\u00f3n completa de VCF. <\/p>\n\n

La salida de VMware ha dejado de ser una mera especulaci\u00f3n. En muchos entornos, se ha convertido en un proyecto, un presupuesto y un riesgo. Es en este contexto donde hay que evaluar FusionCompute: no como una simple curiosidad de Huawei, sino como una opci\u00f3n empresarial para quienes no desean cambiar un problema comercial por un problema operativo. <\/p>\n\n

Pr\u00f3ximos pasos<\/h2>\n\n

Si el debate sobre VMware ya ha llegado a la fase de presupuesto, quiz\u00e1 merezca la pena incluir FusionCompute en el an\u00e1lisis. Made4it puede ayudarle con esta revisi\u00f3n t\u00e9cnica: arquitectura, comparaci\u00f3n con Proxmox y VMware, riesgos de la migraci\u00f3n, funcionamiento y dise\u00f1o de la recuperaci\u00f3n ante desastres. <\/p>\n\n

P\u00f3ngase en contacto con nosotros para evaluar si resulta adecuado para su entorno antes de decidir el proceso de migraci\u00f3n.<\/p>\n\n

<\/a> <\/p>\n\n

Fuentes: Documentaci\u00f3n del producto FusionCompute v8.10.0 (Huawei, mayo de 2026) \u00b7 Documentaci\u00f3n del producto DCS v2.2.0 (Huawei, febrero de 2026) \u00b7 Notas de la versi\u00f3n de Proxmox VE 9.2 (mayo de 2026) \u00b7 L\u00edmites m\u00e1ximos de configuraci\u00f3n de Broadcom para VMware vSphere 8.0<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Quienes trabajan en el \u00e1mbito de la virtualizaci\u00f3n ya se han dado cuenta de que VMware se ha convertido en un tema distinto tras la adquisici\u00f3n por parte de Broadcom. El debate ha pasado de \u00ab\u00bfqu\u00e9 recursos necesito?\u00bb a \u00ab\u00bfcu\u00e1nto me va a costar esto en la pr\u00f3xima renovaci\u00f3n?\u00bb. En el caso de muchos clientes, esta conversaci\u00f3n ha dado pie a que surja Proxmox. Tiene sentido. Pero existe una tercera opci\u00f3n que casi nunca sale a relucir en las primeras reuniones: Huawei FusionCompute. La plataforma no es nueva ni experimental. Se encuentra en la versi\u00f3n 8.10, cuenta con una amplia documentaci\u00f3n t\u00e9cnica y casos de uso en empresas de telecomunicaciones, bancos y organismos gubernamentales de todo el mundo. En Brasil, todav\u00eda apenas se menciona en las conversaciones sobre la sustituci\u00f3n de VMware. Y quiz\u00e1 haya llegado el momento de analizarlo con m\u00e1s detenimiento. \u00bfQu\u00e9 es FusionCompute? FusionCompute es la capa de virtualizaci\u00f3n de Huawei para centros de datos. Se ejecuta en servidores f\u00edsicos, proporciona m\u00e1quinas virtuales, gestiona la CPU, la memoria, la red y el almacenamiento, y forma parte de la soluci\u00f3n DCS de Huawei. La arquitectura gira en torno a dos componentes: CNA (Computing Node Agent): se ejecuta en cada servidor f\u00edsico, implementa el hipervisor UVP y gestiona las m\u00e1quinas virtuales de forma local. VRM (Virtual Resource Manager): El VRM es el cerebro central y se encarga de la gesti\u00f3n del cl\u00faster. Controla la programaci\u00f3n de recursos, el ciclo de vida de las m\u00e1quinas virtuales, la asignaci\u00f3n de direcciones IP y VLAN, y proporciona la interfaz web de administraci\u00f3n. Funciona en modo activo\/en espera con conmutaci\u00f3n autom\u00e1tica por error en un plazo de 1 a 2 minutos en caso de que el nodo activo deje de funcionar. El hipervisor UVP se basa en KVM, al igual que Proxmox, pero funciona en una arquitectura \u00abbare-metal\u00bb sin sistema operativo anfitri\u00f3n intermedio, de forma similar a ESXi. Tabla comparativa de las tres plataformas La tabla que figura a continuaci\u00f3n le ayudar\u00e1 a distinguir entre lo que constituye una diferencia real de arquitectura y lo que es simplemente una diferencia de presentaci\u00f3n comercial. Funcionalidad VMware ESXi \/ vSphere 8 Proxmox VE 9.2 Huawei FusionCompute 8.10 Tipo de hipervisor Bare-metal (ESXi) Tipo 1 (KVM + QEMU) Bare-metal (UVP\/KVM) Hosts por cl\u00faster hasta 96 Sin l\u00edmite expl\u00edcito* hasta 128 M\u00e1quinas virtuales por cl\u00faster hasta 8.000 Sin l\u00edmite expl\u00edcito hasta 8.000 Licencias Suscripci\u00f3n obligatoria; m\u00ednimo 72 colores por CPU C\u00f3digo abierto (asistencia t\u00e9cnica de pago opcional) Licencia comercial de Huawei VM HA \u2705 \u2705 \u2705 autom\u00e1tico, independiente del nodo de gesti\u00f3n Migraci\u00f3n en vivo \u2705 vMotion \u2705 \u2705 Migraci\u00f3n en vivo del almacenamiento \u2705 Storage vMotion \u2705 \u2705 Equilibrado autom\u00e1tico de la carga \u2705 DRS (incluso en el paquete) \u2705 Equilibrador de carga din\u00e1mico (a partir de PVE 9.2) \u2705 DRS + DPM integrados Ahorro autom\u00e1tico de energ\u00eda (DPM) \u2705 \u274c \u2705 Desconecta autom\u00e1ticamente los hosts inactivos Sobrecarga inteligente de memoria \u2705 \u2705 (globo) \u2705 (ballooning + sharing + swapping; x86 y Arm) Asignaci\u00f3n din\u00e1mica de recursos \u2705 \u2705 \u2705 Conmutador virtual distribuido \u2705 vDS (no incluido en el paquete de pago) \u2705 OVS\/SDN \u2705 DVS nativo SR-IOV Limitado \u2705 \u2705 Passthrough de GPU \u2705 \u2705 \u2705 Virtualizaci\u00f3n de GPU \u2705 (vGPU de NVIDIA) \u2705 (vGPU de NVIDIA, a partir de 2025) \u2705 (vGPU de Intel integrada) Contenedores \/ K8s nativo \u274c (Tanzu, independiente y de pago) \u2705 (LXC; sin K8s nativo) \u2705 K8s integrado Multitenencia completa \u2705 (con complementos) \u274c \u2705 (VPC, ECS, ELB, NAT, etc.) DR orquestado \u2705 SRM (de pago) \u274c \u2705 UltraVR integrado Copia de seguridad sin agente con CBT \u2705 (a trav\u00e9s de terceros) \u2705 Proxmox Backup Server \u2705 eBackup nativo Compatibilidad con Arm \u274c \u274c \u2705 Caja negra de diagn\u00f3stico \u274c \u274c \u2705 La documentaci\u00f3n oficial de Proxmox no establece un l\u00edmite de nodos por cl\u00faster. El l\u00edmite pr\u00e1ctico depende del hardware de red y de la latencia; hay casos de cl\u00fasteres con m\u00e1s de 50 nodos en producci\u00f3n con hardware de nivel empresarial. Lo que llama la atenci\u00f3n de FusionCompute Escala de cl\u00faster FusionCompute admite 128 hosts y 8.000 m\u00e1quinas virtuales por cl\u00faster l\u00f3gico, con un m\u00e1ximo de 4.096 hosts y 80.000 m\u00e1quinas virtuales gestionadas por instancia. VMware alcanza los 96 hosts por cl\u00faster en vSphere 8. Proxmox no tiene un l\u00edmite m\u00e1ximo documentado, pero la estabilidad en cl\u00fasteres muy grandes depende en gran medida de c\u00f3mo se haya dise\u00f1ado la red de gesti\u00f3n. En el caso de los grandes centros de datos corporativos, la compatibilidad con 128 hosts por cl\u00faster, con una capacidad total de 80 000 m\u00e1quinas virtuales, supone una gran ventaja competitiva. DRS y DPM: programaci\u00f3n que ahorra energ\u00eda El DRS de FusionCompute supervisa la carga de los hosts en tiempo real y migra autom\u00e1ticamente las m\u00e1quinas virtuales para equilibrar el uso de la CPU y la memoria en el cl\u00faster, sin necesidad de intervenci\u00f3n manual. Esto equivale a lo que ofrece VMware en el paquete de vSphere y a lo que Proxmox ha comenzado a ofrecer con el Dynamic Load Balancer de PVE 9.2. La ventaja distintiva de FusionCompute en este caso es el DPM (Dynamic Power Management): cuando la carga del cl\u00faster disminuye, el sistema consolida las m\u00e1quinas virtuales en un menor n\u00famero de hosts y apaga autom\u00e1ticamente los servidores inactivos. Cuando la demanda aumenta, los hosts se vuelven a encender. Para entornos con una carga variable a lo largo del d\u00eda o de la semana, esto supone un ahorro energ\u00e9tico real sin necesidad de recurrir a la automatizaci\u00f3n externa. Sobrecarga de memoria en tres capas FusionCompute combina el \u00abballooning\u00bb, el uso compartido de memoria (las p\u00e1ginas id\u00e9nticas entre m\u00e1quinas virtuales se consolidan en una \u00fanica copia f\u00edsica) y el intercambio de memoria para permitir que un servidor ofrezca m\u00e1s memoria virtual que la f\u00edsica disponible. Proxmox utiliza el \u00abballooning\u00bb, pero no implementa de forma nativa el uso compartido de memoria entre m\u00e1quinas virtuales. El resultado pr\u00e1ctico es una mayor densidad de m\u00e1quinas virtuales por host en FusionCompute, especialmente cuando las cargas tienen<\/p>\n","protected":false},"author":5,"featured_media":18765,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1273],"tags":[1278,945,1277,1279,1274,1275,1276],"class_list":["post-18764","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-virtualizacion","tag-broadcom","tag-huawei","tag-huawei-fusioncompute","tag-migracion-de-vmware","tag-proxmox","tag-virtualizacion","tag-vmware"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t