Notícias e Eventos Blue Solutions

Atualizações sobre produtos, Informações Técnicas, Dicas para Ambientes de TI, Virtualização, NOC, Operações de TI, Serviços de Segurança, Serviços Gerenciados, Recuperação de Desastres, Continuidade de Negócios e notícias da Blue Solutions.

Os 7 Erros Básicos que até Profissionais cometem em Projetos de Virtualização

2 comentários
7 Erros

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, outros super-dimensionados, algumas configurações bobas erradas, 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ê deve observar em seu ambiente, tem uma chance de 50% dos ambientes ter esses erros, alguns são muito fáceis de serem corrigidos.

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 está fácil. Quando menos 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é numa 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 atrás: Dual Xeon E5520 que roda a 2.27Ghz tem um score de processamento de 7.590, enquanto que um processador moderno 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.

http://ark.intel.com/pt-br/products/64593/Intel-Xeon-Processor-E5-2630-15M-Cache-2_30-GHz-7_20-GTs-Intel-QPI

http://ark.intel.com/pt-br/products/40200/Intel-Xeon-Processor-E5520-8M-Cache-2_26-GHz-5_86-GTs-Intel-QPI

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 sob demanda.

Um estudo recente indica que 95% das VMs são superdimensionadas, isso mostra claramente esse problema, e é possível que na sua infraestrutura existam máquinas virtuais superdimensionadas.

O problema que isso gera é que, ao iniciar todas as VMs consumindo todos os recursos ambiente, sobra pouco espaço para manobras, e na prática, não é necessário. Corre até o risco de criar problemas de Ready Time (que será tratado em outro artigo) e falhas no HA (High Avaliability) por falta de recursos.

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 superdimensionamento das máquinas virtuais.

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 superdimensionados 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 (como o Dpack), para que o sizing do projeto não seja exagerado e possa apresentar um bom custo X 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 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.

4) Subdimensionamento do ambiente, principalmente de disco

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 vermos esse erro.

Existe até um ditado 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, 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 Gigabytes. 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 ter problema de performance na certa.

Mas também não é correto fazer o projeto com 20 discos como era no ambiente original, vai voltar ao problema de superdimensionamento.

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 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? Acha que esqueci algum importante?

2 comentários :