Updated 2020: melhorias para legibilidade do artigo
Tenho trabalhado com projetos de virtualização praticamente desde que surgiram os primeiros hypervisors baremetal e já encontrei ambientes em clientes de várias formas, alguns muitos corretos, alguns sub-dimensionados ou super-dimensionados, algumas configurações simples erradas e até conceitos errados aplicados.
Mas existem alguns erros que são básicos, muitas vezes feitos por falta de entendimento da tecnologia, outros por medo de errar ou por distração.
São esses erros que você pode procurar se existem em seu ambiente, cerca de 50% dos ambientes tem esses erros, alguns são muito fáceis de serem corrigidos, principalmente na fase de projeto.
1) Falta de redundâncias
É comum em pequenas empresas, ao chegar um novo servidor, decidirem iniciar o mesmo virtualizado. Até aí tudo ok, mas depois vem a demanda, e como o ambiente já está ali, subir mais 2, 3 ou 4 VMs é fácil. Quando menos se percebe, tem 10 VMs rodando no mesmo servidor físico, sem redundância nenhuma.
Pode não ter problema nenhum de performance, as VMs podem ser simples, mas são tudo que a empresa tem e precisa para trabalhar. Na falha desse servidor, vai dar muuuiito trabalho para recuperar o ambiente.
E quando chega nesse ponto, normalmente o ambiente já depende dessas VMs, o backup é inadequado e podem até existir algumas licenças irregulares.
Não é culpa da virtualização, faltou um plano diretor de TI para guiar o crescimento e investimentos. A ferramenta permitiu atender a demanda do negócio, agora é hora do negócio reinvestir na infraestrutura para suportar o crescimento futuro.
Nesse caso, não tem jeito, a saída para a empresa é investir na adequação do ambiente e compra das redundâncias necessárias. Cabe à equipe de TI demonstrar os riscos existentes e a importância da infraestrutura para o negócio, daí uma análise de riscos pode ajudar bem.
2) Super Dimensionamento das máquinas virtuais
É comum em um ambiente novo de virtualização o administrador de redes querer dar todo o desempenho possível para as novas máquinas virtuais.
Até ao fazer uma migração, é comum fazer um P2V de máquinas físicas de 2 gerações de processadores atrás, que já tinham 4 núcleos, para VMs com 4 ou mais núcleos.
Mas é incorreto entregar a mesma quantidade de núcleos em uma VM depois de um P2V; mesmo ao criar uma VM nova, também não é boa prática começar com muitos núcleos.
Só para comparação, um servidor com processadores de duas gerações de diferença: Dual Xeon E5520 que roda a 2.27Ghz tem um score de processamento de 7.590, enquanto que um processador mais novo Xeon: E5-2630 v2 que roda a 2.6Ghz tem um score de processamento de 15.697, é mais do que o dobro da capacidade de processamento!
Sem contar que o mais novo tem 6 núcleos versus 4 do antigo, maior velocidade de transferência para a memória e quase o dobro de cache interno.
O processador mais novo já vai deixar a VM mais rápida, por isso a recomendação é que, depois de uma migração de ambiente, seja via P2V ou instalação nova, as VMs sejam iniciadas com o mínimo de vCPUs, memória e disco possível e vá crescendo (redimensionando) sob demanda.
Um estudo recente indica que 95% das VMs são super dimensionadas, isso mostra claramente esse problema e é possível que na sua infraestrutura existam muitas máquinas virtuais super dimensionadas.
Os problemas são vários:
- Maior tempo de boot das VMs
- Maior tempo de vMotion / XenMotion / LiveMigration
- Snapshots maiores (pois normalmente é feito um Snapshot da memória também)
- Problemas de NUMA
- Problemas de Ready Time (que será tratado em outro artigo)
- Pouco espaço para manobra em eventos de migração ou na falha de um dos servidores hospedeiros, podendo até causar falha no serviço automático de High Avaliability.
Por isso vale a pena acompanhar os indicadores de uso de CPU de todas as VMs, principalmente as menos importantes e o tempo de CPU Ready, para entender se seu ambiente tem gargalho causado por super dimensionamento das máquinas virtuais.
Algumas ferramentas como o Veeam One ou o Vmware VCops conseguem até calcular a quantidade de recursos desperdiçados e recomendar o ajuste quando necessário.
3) Super Dimensionamento dos servidores hospedeiros
Por medo de errar e por não conhecer o ambiente, muitos projetos de virtualização acabam super dimensionados em recursos dos hosts físicos.
Embora não crie problemas diretos no projeto, e, se comprado, irá rodar tudo bem, a grande dificuldade dos projetos super dimensionados são os alto custos de aquisição, que podem inviabilizar o mesmo e manter recursos ociosos por vários anos até o ambiente crescer e ocupar essa capacidade.
Por isso é importante executar ferramentas de análise no ambiente antes de fazer um projeto, para que o dimensionamento do projeto não seja exagerado e possa apresentar um bom custo benefício.
Como a virtualização permite o crescimento de Configuração das Máquinas Virtuais, Hosts Físicos, Espaço em Disco e Performance de Disco sem muito esforço, o recomendado é que os investimentos sejam feitos gradativamente, comprando uma parte da capacidade a cada ano.
Isso permite aproveitar a Lei de Moore a seu favor, a cada um ano e meio, cada novo host, storage ou outro componente comprado poderá ter o dobro da capacidade, pelo valor do componente da geração anterior.
Claro que isso não resolve para empresas que já tenham o ambiente muito sub-dimensionado, ou onde o financeiro não vê vantagem em ter compras constantes (anuais) e prefere uma compra grande financiada.
Mas se a TI puder programar as próximas compras com o decorrer do tempo, com certeza terá benefícios de ter sempre um parque de servidores atualizado, em garantia e corretamente dimensionado.
4) Sub Dimensionamento do ambiente
Essa é meio óbvia se pensarmos bem e muitos profissionais alocam CPU e memória em excesso para evitar, mas quando fala-se de disco, é bem comum encontrarmos esse erro.
Existe até uma piada interna entre alguns especialistas que diz que os projetos de virtualização tem metade dos discos que precisa, o dobro da memória e 10 vezes a CPU que precisa.
Exageros a parte, depois de acompanhar dezenas de projetos, e principalmente vendo os ambientes rodando por anos depois, percebi que isso é a mais pura realidade.
Por algum motivo, a CPU é a principal preocupação de muitos profissionais e acaba super dimensionada.
Normalmente a camada de armazenamento (discos e Storage) é subjulgada e é a primeira que acaba. O crescimento de discos frequentemente é calculado como linear, quando na prática é exponencial.
Outro erro básico para os discos é fazer a conta somente em Terabytes utilizados e não da performance necessária.
Olha-se o ambiente atual, por exemplo, 10 servidores com 2 discos de 144Gb em RAID 1 cada, multiplica-se, chega a 1,4Tb de espaço disponível no cenário atual, calcula-se o dobro prevendo o crescimento: 3Tb.
Para fazer 3Tb são necessários apenas 8 discos de 900Gb em RAID 10… mas existiam 20 discos anteriormente e agora com apenas 8 discos vai ocorrer problema de performance na certa por falta de IOPS.
Mas também não é correto fazer o projeto com 20 discos como era no ambiente original, vai voltar ao problema de super dimensionamento.
Para não errar para mais nem para menos, é preciso medir os IOPS (quantidade de operações de disco por segundo) usados no ambiente e fazer a projeção.
Talvez nem precise dos 8 discos, ou talvez precise de 16, aí pode-se optar por ter mais espaço em disco (16 discos de 900Gb) ou manter os custos com mais discos de menor capacidade (16 discos de 600Gb).
5) Licenciamento de Aplicações
Não é mais tão comum, mas algumas aplicações podem ter o licenciamento vinculado com a máquina física, independente do ambiente virtual. Outras aplicações podem exigir o licenciamento de todo o Cluster virtual, independente de qual servidor a aplicação está rodando efetivamente.
Esse é um item que deve ter atenção dobrada, até para não pagar exageros de licenças. Às vezes pode ser vantajoso manter uma aplicação, mesmo virtualizada, fora do Cluster, apenas para não pagar as licenças excedentes.
Outras vezes, o uso de licenças de nível Enterprise de um software permitem a instância de múltiplas VMs sem custos adicionais, diferente de licenças básicas que precisam ser licenciadas por VM.
6) Configuração de rede sem redundâncias
Esse é um aspecto bem técnico e realmente precisa de um especialista para fazer corretamente, mas fico impressionado com a quantidade de implementações que encontro com essa falha, mesmo com tanta documentação existente.
É comum encontrar mais de uma interface de rede conectada, mas cada uma para um propósito diferente, com uma VLAN diferente que foi configurada no Switch físico, ou com um link de Internet fixo em uma porta do servidor ESX.
O problema disso é que não existem redundâncias no ambiente e no caso de um ambiente com vMotion licenciado, não é possível fazer a movimentação das máquinas virtuais entre servidores hospedeiros sem interromper o serviço.
Essa configuração também limita a performance do ambiente, já que existe apenas um canal de comunicação entre o ESX e cada VLAN, sendo que poderiam existir dois ou mais.
A configuração a ser feita é bem simples, no VMware ESX principalmente, uma configuração recomendada é usar no mínimo duas interfaces de rede conectadas ao Switch e com essa configuração, adicionar ambos os adaptadores no mesmo Switch Virtual, depois configurar as VLANs como Port Group e conectar as máquinas virtuais que precisam de acesso a essa VLAN no Port Group.
É uma alteração simples, mas que pode fazer toda a diferença para a disponibilidade do ambiente.
7) Não monitorar a infraestrutura adequadamente
O uso de ferramentas de monitoramento que não entendem o ambiente virtual pode levar a diagnósticos incorretos.
Ter os plugins para o ambiente virtual e capacidade de análise do mesmo é fundamental para as ferramentas de monitoramento.
Para isso, ferramentas específicas para o ambiente virtual como o VMware VCenter Operations Manager são fundamentais e devem ser consideradas na aquisição da solução.
Mesmo ferramentas tradicionais de monitoramento já possuem plugins para virtualização e esses plugins devem ser instalados e configurados corretamente para monitorar todo o ambiente.
Conclusão:
Alguns dos erros são menos óbvios e podem passar desapercebidos até o ambiente começar a ter problemas de performance. A solução daí será aumentar os investimentos de forma abrupta, quando poderia ser feito de forma planejada e gradativa.
Outros casos, simples configurações podem resolver, mas por falta de conhecimento da ferramenta, pode-se optar até por situações extremas, como um único Host físico com uma única máquina Virtual, ou tirar um determinado serviço da Virtualização.
Por isso recomendamos a contratação de equipes especializadas, capacitadas pelos fabricantes, ou então fazer cursos especializados em ambientes virtuais para a criação e manutenção de um ambiente virtualizado profissional.
E você, já viu esses erros em algum ambiente ou projeto de virtualização? Acha que esqueci algum importante? Deixe seu comentário.
