Grupos de recursos do ESX 3.5

2

Sou um DBA e gerencio um cluster vmware ESX 3.5 que hospeda predominantemente SQL Servers e alguns servidores de aplicativos e tenho uma pergunta sobre como configurar os grupos de recursos, mas estou em conflito com um dos os administradores do sistema ESX sobre como gerenciar os recursos .

O cluster (3 nós, 32 GB por nó) atualmente hospeda 33 convidados configurados para consumir 77 GB de RAM, embora o ESX esteja informando que apenas 44 GB estão ativos. O cluster hospeda servidores de teste, desenvolvimento ao vivo e alguns outros convidados diversos.

O que eu gostaria de fazer é simplificar o gerenciamento dos recursos dos servidores e poder gerenciar e reportar o desempenho de servidores relacionados.

Por exemplo, os recursos consumidos (RAM, disco, CPU) para os servidores do Live SQL, os servidores do SharePoint, os servidores do CRM, etc.

O que eu fiz em seguida é criar 4 grupos de recursos de "nível superior".

1-High    - For the most mission critical services (ie. the live SQL server)
  32768 memory shares
2-Normal  - For the majority of the remaining live systems (CRM, Sharepoint etc)
  16384 memory shares
3-Dev     - Test and development systems
  8192 memory shares
4-Low     - Non supported servers (no sla, temporary build servers etc)
  1024 memory shares

Agrupei os servidores em seus próprios grupos de recursos de "aplicativo" (SQL Live, Teste SQL, CRM Live, Teste de CRM, etc.), mas não defini limites de recursos explícitos nesses grupos.

Depois, coloco os grupos de "aplicativos" no grupo de recursos "nível superior" apropriado.

Por exemplo, cada subgrupo tem 4 convidados, cada 1 CPU e 1 GB de RAM

1-High               32768 shares
    SQL Live         4 guests
2-Normal             16384 shares
    CRM Live         4 guests
    Sharepoint Live  4 guests
3-Dev                16384 shares
    CRM Test         4 guests
    SQL Test         4 guests
    Sharepoint test  4 guests
4-Low 
    Remaining cruft  4 guests

O administrador do sysadmin está me dizendo que "o Sharepoint só receberá 28% de 50% dos recursos de que precisa!"

Antes de responder a ele, posso obter alguns conselhos e verificar minhas suposições:

  • Em operação normal, o cluster não está supercomprometendo a RAM (ou a CPU), portanto, não há limites de recursos sendo aplicados a nenhum convidado, seja a CPU ou a RAM.
  • Se um dos hosts falhar, haverá apenas 64 GB de RAM disponíveis. À medida que os convidados são reiniciados (temos o HA e o DRS habilitados), os hosts restantes começarão a reiniciar os convidados e isso comprometerá a RAM.
  • Quero garantir que os serviços de maior prioridade mantenham seus serviços
  • Eu não quero micromanage cada convidado individual!

Quais são seus pensamentos e experiências?

    
por Guy 13.01.2010 / 16:20

2 respostas

6

Se eu estou lendo isso corretamente, então você está correto sobre o funcionamento normal do seu ambiente, mas não tenho certeza se algum de vocês está correto sobre como funciona quando a contenção surge.

Quando não há contenção (a contenção começa quando a utilização de recursos excede 80% BTW), as ações não têm efeito. Portanto, no que diz respeito às operações normais em seu ambiente, os Grupos de Recursos serão cosméticos.

Quando houver contenção, os recursos da CPU serão limitados conforme indicado pelo seu sysadmin, mas isso não acontecerá necessariamente se você perder um host.

Você não diz se modificou compartilhamentos nos pools de recursos filhos. Eu vou assumir que tudo isso está normal.

Supondo que haja contenção, embora a maneira como os compartilhamentos funcionem é que cada Pool de Recursos obtém a proporção dos recursos que é igual à sua fração da quantidade total de compartilhamentos nesse nível. Para o seu primeiro nível, você tem ~ 58k de ações para que o High Pool receba aproximadamente 56%, o normal receba 28%, o Dev receba 14% e o Low receba 1,7%. Em cada Pool, os subpiscina compartilham os recursos desse pool de maneira uniforme, a menos que você tenha explicitamente definido compartilhamentos adicionais nesse nível, se você tiver as mesmas regras aplicáveis, mas o total do pool permanecerá inalterado.

Portanto, no seu caso, quando surgir a contenção, os sistemas do Live Sharepoint obterão 50% de 28% dos recursos contidos, ou seja, 14%.

Você pode ajudar algumas coisas alocando reservas para os valores mínimos absolutos de CPU e RAM de que cada sistema precisa. Os valores reservados são garantidos para os pools \ de recursos de sistemas aos quais você os aloca e não são alocados por compartilhamentos. A principal desvantagem deles é que, se os valores forem muito altos, o cluster poderá ser incapaz de tentar reiniciar as VMs, já que os recursos não podem ser garantidos.

Lembre-se também que, embora seus sistemas consumam apenas ~ 44 GB sob operação normal com sistemas Windows, 100% da memória será (brevemente) alocada quando uma VM for inicializada. Isso pode acionar um cenário de contenção para a memória durante um failover, embora haja RAM suficiente para os sistemas quando eles estiverem em execução. É algo para ficar de olho em mais do que se preocupar, mas pode causar problemas durante as reinicializações do HA.

Editado para adicionar
Se você não fez alterações nas configurações de compartilhamento padrão em VMs individuais ou Grupos de recursos filhos, a proporção de recursos alocados para VMs individuais não será alterada quando você mover todas as VMs para um nível em uma estrutura onde haja apenas um único filho RG. e colocá-los diretamente no pai. No entanto, se houver vários RGs filhos e números diferentes de VMs em cada um, isso não é verdade.

Em seu exemplo, digamos que você tenha suas 4 VMs do SharePoint em seus filhos RG e 2 CRM VMs em seu grupo filho. As VMs do Sharepoint recebem ~ 3,5% cada (50% de 28% / 4) e as VMs de CRM obtêm 7% cada (50% de 28% / 2). Se você agora mover todos eles para o RG pai e excluir os RGs filhos vazios, agora você tem 6 VMs compartilhando 28% dos recursos disponíveis para o RG normal e cada um deles receberá ~ 4,7% (28% / 6).

É claro que, se você alterar os compartilhamentos nos Grupos de recursos filho ou nas VMs individuais, tudo isso será alterado.

    
por 13.01.2010 / 17:01
1

As definições de recursos só entram em vigor em um cluster supercomprometido.

    
por 13.01.2010 / 17:00