Por muito tempo, abandonar a VMware foi uma daquelas ideias sobre as quais muitas equipes de infraestrutura falavam, mas que relativamente poucas levavam a sério. A VMware estava profundamente enraizada, os administradores sabiam disso e, mesmo quando o licenciamento não era particularmente atraente, a perturbação envolvida na migração de centenas ou milhares de máquinas virtuais muitas vezes fazia com que permanecer onde estavam fosse a opção mais fácil.
Esse cálculo mudou.
As mudanças decorrentes da aquisição da VMware pela Broadcom forçaram as organizações a reavaliar decisões de infraestrutura que, em alguns casos, permaneceram praticamente inquestionáveis por uma década ou mais. As discussões sobre hipervisores alternativos não são mais meros exercícios teóricos de arquitetura e, cada vez mais, o Proxmox VE surge como a resposta.
Há um bom motivo para isso. O Proxmox amadureceu e se tornou um hipervisor confiável, com recursos de clustering, alta disponibilidade, armazenamento definido por software, backup e os recursos de gerenciamento necessários para operar ambientes de produção de grande porte. Mais importante ainda, as organizações não estão simplesmente avaliando-o em laboratórios. O departamento de TI da Universidade de Stanford publicou seu próprio relato sobre a conclusão da migração: mais de sessenta nós de servidor foram reconfigurados em seis clusters independentes do Proxmox, e aproximadamente 1.500 máquinas virtuais foram migradas do VMware. Infraestruturas desse porte estão sendo migradas no mundo real.
Para uma organização cujo parque de VMware consiste principalmente em cargas de trabalho de servidor, isso pode tornar o caminho a seguir surpreendentemente simples: implantar o ambiente Proxmox, migrar as cargas de trabalho, desativar o ESXi e seguir em frente.
Mas o que acontece quando o vSphere não é o único produto da VMware do qual você depende?
Substituir o vSphere é apenas metade da história
Imagine uma organização que opera um ambiente VMware bastante convencional. Seu parque de servidores está hospedado no vSphere, enquanto várias centenas de funcionários acessam desktops e aplicativos do Windows por meio do VMware Horizon.
Alguns usuários podem ter ambientes de trabalho completos do Windows 11. Outros executam alguns aplicativos do Windows publicados, enquanto prestadores de serviços recebem ambientes de trabalho rigidamente controlados, sem acesso direto à rede corporativa. Para os usuários, o Horizon é simplesmente a forma de acessar os recursos de que precisam.
Então, a organização decide deixar a VMware.
A migração da infraestrutura para o Proxmox resolve uma parte significativa do problema. Os controladores de domínio podem ser migrados. Os servidores de arquivos podem ser migrados. Os bancos de dados e os servidores de aplicativos podem ser migrados. As máquinas virtuais do Windows utilizadas para fornecer ambientes de trabalho aos usuários também podem ser executadas no Proxmox.
Mas o Horizon não pode simplesmente ser pegado e levado junto com eles.
A razão fica clara quando a pilha da VMware é dividida em suas partes constituintes. O vSphere fornece a infraestrutura de virtualização; o Horizon fornece o serviço que transforma essa infraestrutura em algo que os usuários podem utilizar. Ele sabe quem são os usuários, a quais aplicativos e desktops eles têm direito de acesso e de onde esses recursos devem vir.
O Proxmox substitui a primeira dessas funções. Não se destina a substituir a segunda.
Nesse momento, o que parecia ser uma migração de hipervisor passa a ser também um projeto de TI voltado para o usuário final. A questão não é mais simplesmente “Por que substituímos o vSphere?”
Se a Horizon faz parte do patrimônio, surge outra questão: o que substituirá a Horizon?
Uma camada diferente da área de trabalho
É aqui que a gente se encaixa.
O Inuvika OVD Enterprise fornece a camada de distribuição de aplicativos e áreas de trabalho acima do hipervisor, e é um Alternativa ao VMware Horizon que não depende de um hipervisor. O Proxmox fornece a infraestrutura na qual as máquinas virtuais são executadas; transformamos as cargas de trabalho do Windows e do Linux em execução nessa infraestrutura em aplicativos e desktops que podem ser disponibilizados com segurança aos usuários.
Considere uma organização com 600 usuários do Horizon. Duzentos engenheiros recebem suas próprias áreas de trabalho virtuais do Windows 11, pois precisam de ambientes de área de trabalho completos. Os 400 funcionários restantes precisam, principalmente, de acesso a um conjunto de aplicativos empresariais do Windows.
Antes da migração, tudo isso poderia ter sido disponibilizado por meio do Horizon no vSphere. Depois da migração, poderá ser disponibilizado por meio do Inuvika OVD Enterprise no Proxmox.
Os engenheiros podem continuar a receber desktops dedicados do Windows, enquanto os demais funcionários podem receber desktops compartilhados do Windows ou aplicativos publicados individualmente. Do ponto de vista do usuário, o hipervisor subjacente é, em grande parte, irrelevante: eles se autenticam e recebem os recursos que lhes são atribuídos.
Nos bastidores, no entanto, ambas as camadas do ambiente VMware foram substituídas.
É importante ressaltar que o Inuvika OVD Enterprise não é simplesmente um software que por acaso é executado em máquinas virtuais hospedadas pelo Proxmox. Nós oferecemos suporte ao provisionamento para o Proxmox VE, de modo que nosso software interage diretamente com a infraestrutura de virtualização subjacente.
De uma imagem do Windows até a área de trabalho do usuário
Se esses 200 engenheiros precisarem de desktops com Windows 11, alguém terá que configurá-los e mantê-los. Da mesma forma, se o ambiente compartilhado de aplicativos precisar de mais capacidade à medida que a demanda dos usuários aumenta, configurar manualmente cada servidor Windows adicional acabaria por comprometer o próprio objetivo de se ter um serviço de desktop gerenciado.
Em vez disso, um administrador prepara um “gold master” contendo o sistema operacional, os aplicativos e a configuração exigidos pela organização. Podemos então usar esse modelo para provisionar as instâncias necessárias para fornecer desktops e aplicativos.
A organização ainda é proprietária e responsável pela gestão da imagem do Windows. Ela decide como o Windows recebe atualizações, quais aplicativos são instalados e quais políticas de segurança são aplicadas. Para uma implantação do Proxmox, a preparação do Windows, incluindo o Sysprep, é realizada por meio dos Scripts do Servidor OVD, enquanto a conversão final da máquina virtual preparada em um modelo ocorre dentro do próprio Proxmox. Ambas as etapas estão descritas em nosso documentação de provisionamento.
Depois de preparado, esse modelo passa a ser a base para os recursos do Windows que provisionamos.
Essa distinção é importante porque há uma diferença significativa entre dizer que um produto de VDI roda no Proxmox e dizer que ele realmente se integra ao Proxmox. Praticamente qualquer aplicativo pode ser instalado dentro de uma máquina virtual. Integração significa que o software de desktop pode interagir com a infraestrutura subjacente para criar os recursos necessários à prestação do serviço.
Para uma organização que está deixando a VMware, isso significa que a migração para o Proxmox não precisa implicar em abrir mão da automação que ela esperava anteriormente de seu software de provisionamento de desktops.
Não reconstrua automaticamente o ambiente do Horizon
Uma migração também é uma boa oportunidade para questionar se todos os usuários ainda precisam da arquitetura que tinham anteriormente.
Se a nossa organização de exemplo tiver atualmente 600 desktops Horizon, o plano de migração mais óbvio poderia ser criar 600 desktops substitutos. Mas talvez apenas os 200 engenheiros realmente precisem de seu próprio ambiente Windows. Se os outros 400 usuários passam a maior parte do dia de trabalho utilizando o mesmo conjunto de aplicativos do Windows, fornecer a cada um deles uma máquina virtual Windows 11 separada pode não trazer grandes benefícios além de criar centenas de sistemas operacionais a mais para serem executados, atualizados e gerenciados.
O Inuvika OVD Enterprise oferece suporte a ambas as abordagens no mesmo ambiente.
Os usuários que precisam de um ambiente individual do Windows podem receber uma área de trabalho dedicada, enquanto os aplicativos e as áreas de trabalho compartilhadas podem ser fornecidos a partir de servidores de aplicativos do Windows aos usuários que não precisam disso. Assim, vários usuários podem compartilhar os recursos do servidor subjacente e, ao mesmo tempo, continuar recebendo suas próprias sessões individuais.
Isso transforma a migração em uma oportunidade para fazer uma pergunta mais útil do que “Como podemos recriar o Horizon no Proxmox?”.”
Em vez disso, pergunte: “Para que nossos usuários estão realmente usando o Horizon?”
O ambiente substituto pode, então, ser projetado com base no serviço de que eles precisam, em vez de simplesmente reproduzir a infraestrutura que, por acaso, fornecia esse serviço anteriormente.
Como evitar a próxima dependência
Há também uma lição mais ampla a ser tirada disso. Para muitas organizações, os recentes acontecimentos envolvendo a VMware demonstraram o risco de permitir que uma parte excessiva da pilha de infraestrutura dependa de um único fornecedor.
Substituí-la por outra pilha fortemente acoplada seria uma conclusão estranha a se tirar dessa experiência.
O Inuvika OVD Enterprise não é uma solução exclusiva para o Proxmox. O Proxmox é um dos ambientes da lista integrada com a qual nosso sistema de provisionamento funciona, juntamente com o Nutanix AHV, o VMware vSphere e o VergeOS, além de provedores de nuvem como Zadara, Microsoft Azure, Google Cloud e AWS. De maneira mais ampla, somos independentes de hipervisores e nuvens, e também rodamos no KVM, Hyper-V e Virtuozzo.
Hoje, uma organização pode decidir que o Proxmox é a opção certa para tudo o que está rodando atualmente no vSphere. No futuro, ela pode adquirir outra empresa, adotar uma infraestrutura em nuvem ou realizar outra mudança que ninguém envolvido no projeto do ambiente atual possa prever.
A separação das duas camadas significa que essas decisões podem permanecer independentes.
Escolha o Proxmox porque é o hipervisor certo. Escolha o Inuvika OVD Enterprise porque é a solução certa para a entrega de aplicativos e desktops. Mudar um não significa automaticamente mudar o outro.
Deixar a VMware significa olhar além do vSphere
Para organizações que utilizam o VMware exclusivamente para virtualização de servidores, a migração para o Proxmox pode oferecer um caminho claro para se afastar do vSphere. Migrações reais realizadas em Stanford e em outros locais já demonstraram que o Proxmox é capaz de operar ambientes de produção de grande porte.
Para as organizações que utilizam o VMware Horizon (Omnissa), no entanto, a substituição do hipervisor é apenas uma parte do processo.
A Proxmox fornece a infraestrutura de virtualização, enquanto o Inuvika OVD Enterprise pode fornecer a camada de entrega de aplicativos e desktops acima dela. Juntos, eles oferecem uma alternativa ao vSphere e ao Horizon sem abrir mão de aplicativos Windows gerenciados centralmente, desktops compartilhados ou VDI dedicada.
Talvez o mais importante seja que elas permitem que uma organização substitua uma pilha de produtos VMware verticalmente integrada por duas escolhas tecnológicas independentes.
Substituir o vSphere é uma decisão.
A substituição do VMware Horizon é outra.
E separar as duas coisas pode acabar sendo um dos aspectos mais úteis dessa mudança.
Perguntas frequentes
O Proxmox pode substituir o VMware Horizon?
Não diretamente. O Proxmox VE fornece a infraestrutura de virtualização e pode substituir a função desempenhada pelo VMware vSphere e pelo ESXi. O Horizon desempenha uma função diferente, direcionando os usuários para os desktops e aplicativos aos quais eles têm acesso, e essa camada precisa ser substituída separadamente. O Inuvika OVD Enterprise foi projetado para ser essa camada.
O Inuvika OVD Enterprise é compatível com o Proxmox VE?
Sim. O Proxmox é um dos ambientes da lista integrada com a qual nosso sistema de provisionamento trabalha, juntamente com o Nutanix AHV, o VMware vSphere, o VergeIO e os principais provedores de nuvem. O provisionamento é executado no Terraform; portanto, ambientes que não constam nessa lista podem ser adicionados por meio da configuração avançada ou pela nossa equipe de suporte.
Precisamos atribuir a cada usuário sua própria área de trabalho do Windows?
Não, e a maioria das organizações não deveria. As instâncias dedicadas oferecem ao usuário seu próprio ambiente Windows, enquanto as instâncias compartilhadas fornecem desktops baseados em sessão e aplicativos publicados a partir de um único servidor de aplicativos Windows. Ambas são executadas no mesmo ambiente, de modo que a arquitetura pode se adaptar ao que cada grupo de usuários realmente faz.
Como é preparada a versão Gold Master do Windows para o Proxmox?
Você cria um servidor de aplicativos com o sistema operacional, os aplicativos e a configuração desejados e o registra como um modelo. No Proxmox, o Sysprep é configurado por meio dos Scripts do Servidor OVD. A conversão final da máquina virtual preparada em um modelo ocorre no próprio Proxmox, pois essa operação é de responsabilidade do hipervisor e não do nosso console.
Se mudarmos de novo mais tarde, precisaremos alterar a camada da área de trabalho também?
Não. É exatamente por isso que se mantêm as duas decisões separadas. O mesmo ambiente roda no Nutanix AHV, no VMware vSphere, no VergeIO e em provedores de nuvem pública; assim, uma futura mudança na infraestrutura não obriga a uma segunda migração da camada de desktop.
Experimente no Proxmox
O Inuvika OVD Enterprise é instalado em poucas horas e configura os desktops a partir da sua própria imagem mestre. Inicie um 30 dias de teste gratuito.