Um de meus colegas de trabalho ontem enviou um email comentando sobre esta ferramenta online da Dell para sizing de Virtualização (Hyper-V, VMWare e Xen), SQL Server, Exchange, Oracle e HPC em http://content.dell.com/us/en/enterprise/large-enterprise-solutions.aspx

É claro que estas ferramentas não são o unico recurso que deve ser utilizado em um sizing, mas dão uma idéia muito boa de tecnologias e as diferentes configurações possiveis. Paticularmente gostei da ferramenta de virtualização onde após escolher o numero de servidores que estarão no ambiente, suas funções, o tipo de storage e a previsão de uso dos hosts ele dá não só uma lista de dados mas também diagramas do ambiente recomendado. Divirta-se com essas ferramentas e entenda como as soluçoes que envolvem ambientes precisam ser muito bem planejadas com as dicas que o “Consultor Virtual” da Dell pode lhe dar.

SINTOMA

Ao acrescentar um novo nó em um cluster já existente enfrentei um problema no HA (High Avaliability) quando ao mover o storage ocorreu o erro “This node is not a possible owner for this resource”.

CAUSA

Em geral este erro não acontece, pois ao se acrescentar um novo nó ao cluster este já adiciona o novo host como “Possible Owner”, porem neste caso em especial o problema foi a configuração do iSCSI que estava incorreta e o novo host não conseguia acessar uma das unidades do CSV, ocasionando “Redirect Access”.

Após resolver o problema dos endereçamentos do iSCSI os discos ficaram visiveis, porem ele não era migrado para o novo host e acusa o erro indicando que o novo host não era um dos possiveis owners.

No caso de uma VM ou o Quorum basta clicar com o botão direito para acessar a lista de Possible Owners, mas isso não existe em unidades de storage.

Solução

Utilizando o PowerShell Modules execute o cmdlet abaixo e veja que uma das unidades do storage não tem o novo servidor na lista de nós:

Get-ClusterSharedVolume | Get-ClusterOwnerNode

ClusterObject                                            OwnerNodes
-------------                                               ----------
Unidade_G                                               {ServerA}
Unidade_H                                              {ServerA, ServerB}

Na sequencia utilize o comlet abaixo para definir os Owners da unidade que está incorreta:

Set-ClusterOwnerNode –Owners ServerA,ServerB -Resource "Unidade_G"

Por fim, execute o comando inicial novamente e veja que agora os Owners estão corretos:

Get-ClusterSharedVolume | Get-ClusterOwnerNode

ClusterObject                                            OwnerNodes
-------------                                               ----------
Unidade_G                                               {ServerA, ServerB}
Unidade_H                                               {ServerA, ServerB}

Nota

Antes de conseguir resolver o problema tentava utilizar o cmdlet Get-ClusterResource  | Get-ClusterOwnerNode porém unidades CSV não listados, com excessão do Quorum.

No post anterior sobre VMM 2012 abordei a capacidade de utilizar as 3 tecnologias de migração das VMs entre os host XenServer, VMWare e Hyper-V. Todos podem estar no mesmo grupo e utilizando o PRO Tips. Detalhes em http://bit.ly/pf0v9M

Mas agora vamos falar de duas novas features e como funcionam:

1. Dynamic Optimization – Gerencia a agressividade com que as VMs são movidas entre os nós no modo “quente”
2. Power Optimization – Desliga e religa nós do cluster conforme a utilização dos recursos

Dynamic Optimization

Esta feature irá gerenciar com qual nível de agressividade iremos fazer o balanceamento de carga nos hosts. É compativel com XenServer e VMWare desde que o BMC esteja instalado nos hosts. Note porem que o processo de migração das VMs ocorrerá entre os hosts do mesmo SO.

Note na tela abaixo que é possivel definir manualmente a frequencia em que este processo será executado. Tempos muito altos ocasionaram moves excessivos de VMs entre os hosts, tempos longos podem gerar lentidão em um host até que as VMs sejam movidas. O ideal é de 10 a 30 minutos para detecção e solução.

Abaixo vemos a configuração considerada ideal para que o VMM detecte a necessidade de move de VMs. No exemplo temos 30% de CPU, 512 MB de memória livre e não levamos em conta IOPS e Network pois esses dois itens comulmente são compartilhados entre os nós de um cluster e não são otimizados com moves entre os nós.

NOTA: Lembrando mais uma vez que esta configuração é feita nos grupos que podem contem Hyper-V, Xen Server e VMWare e que os moves irão acontecer entre estes servidores com o mesmo SO e não entre os diferentes SOs. Alem disso é necessário no caso do VMWare e do Xen Server que estejam em cluster.

Power Optimization

Este novo recurso é muito interessante, levando em conta que muitos cluster tem o dobro da necessidade média levando em conta os picos. O Dynamic Optimization ajuda no momento em que o pico ocorre a distribuir as VMs, mas e quando há sobra de recursos?

O Power Optimization irá desligar os nós que não sejam necessários quando a utilização dos hosts reduzindo nós terá umca determinada capacidade e no horário escolhido.

No exemplo abaixo iremos desligar o host desde que a utilização dos outros nós com os moves de VM não fiquem acima de 40% e 1GB de RAM, e desde que esteja em horário noturno ou final de semana.

O processo de desligamento é um shutdown  sendo que o religamento é realizado por pacotes WOL (Wake On Lan) que precisa estar habilitado na BIOS do host. Alem disso nos hosts ESX e Xen Server é necessário ter o BMC, assim como no Dynamic Optimization.

Alem disso, existe uma proporção para esse recurso:

• Cluster de 4 ou 5 nós – 1 nó será desligado
• Cluster de 6 ou 8 nós – 2 nós serão desligados
• Cluster de 9 ou 10 nós – 3 nós serão desligados
• Acima de 10 nós – 1 nó adicional pode ser desligado a cada 2

NOTA: O recurso Power Optimization só funcionar entre nós do cluster e não host-to-host.

Referencia: http://technet.microsoft.com/en-us/library/gg675109.aspx