Recursos dedicados em VMs que hospedam o SQL Server

8

Meu entendimento é que um dos grandes benefícios do uso de uma VM é que você pode compartilhar recursos entre as máquinas virtuais em um host. Assim, você pode ter um host com 120 CPUs e colocar 5 VMs nele com 32 CPUs cada. As CPUs extras são "compartilhadas" entre as VMs, com o host atribuindo CPUs dinamicamente com base na necessidade. O mesmo para a memória.

Também entendi que isso é um grande não-não para VMs que hospedam servidores SQL, mas meus administradores de VM discordam. Alguém tem alguma evidência ou documentação de uma maneira ou de outra?

Não sei se isso importa, mas estamos usando o VMWare.

sql-server virtualisation vmware

— Kenneth Fisher
fonte

2

Por incrível que pareça, acabamos de ter um problema com failovers aleatórios em um grupo de disponibilidade virtualizado. estávamos com excesso de assinaturas na CPU com um tempo de espera de ~ 8 segundos. o ouvinte ag perdia sua concessão de cluster e passava para o outro nó HA. a dificuldade aqui é que ela não se apresenta como pressão da CPU no convidado, mesmo que o erro esteja geralmente associado à pressão sustentada da CPU. isso leva ao maior problema da virtualização - saber o que está acontecendo e confiar que outras pessoas façam o mesmo.

— swasheck

É realmente um bom post sobre VMware CPU Hot Plug vNUMA Efeitos sobre SQL Server por Jonathan Kehayias

— Kin Shah

btw: Normalmente não é "O mesmo para memória". Na maioria dos casos, você compartilha a CPU, mas como uma quantidade específica de memória é alocada para cada VM e essa memória não é compartilhada. Compartilhando cpu com um SQL Server pode ser OK, dependendo da carga total da CPU para todas as suas VM, mas partilhando a memória com um SQL Server seria ruim em quase todos os casos

— MTilsted

@MTilsted Desculpe pela confusão. Quando eu disse "O mesmo para a memória", quis dizer especificamente que ele couldseria compartilhado. Quando eu estava fazendo a pergunta, percebi que poderia muito bem ser diferente para CPUs e memória, mas que ambas eram uma opção.

— 9139 Kenneth Fisher

15

O que você está perguntando é: "Tudo bem se nós comprometemos demais as CPUs?"

Tudo bem até você começar a enfrentar gargalos de desempenho relacionados ao consumo de CPU. A mesma resposta também é verdadeira com o comprometimento excessivo da rede - não é como se você estivesse colocando 5 placas Ethernet de 10Gb separadas no host e dedicando uma placa por VM. A virtualização tem a ver com comprometimento excessivo e na linha entre disponibilidade de recursos e requisitos de recursos.

De um modo geral, você não deseja comprometer demais a memória, pois o SQL Server usará ativamente qualquer memória que você apresentar a ele. Em vez de deixar a página das VMs no disco do host, é melhor fazer uma análise VM por VM para descobrir quais VMs poderiam viver com menos memória e depois configurá-las com menos memória para começar.

— Brent Ozar
fonte

Não esqueçamos a importância de discos físicos dedicados e independentes também; um para Dados, Logs e Tempdb . :)

— Chiramisu 27/10

13

O problema que vejo ao ter alocação dinâmica de alguns recursos é que isso leva a um desempenho imprevisível. A consulta de relatório x tinha 32 CPUs disponíveis ontem e foi executada em 4 minutos, hoje possui apenas 24 e demorou consideravelmente mais. Você também pode ver a latência enquanto o convidado aguarda a disponibilidade de outros núcleos.

Jonathan Kehayias dá alguns avisos práticos sobre a inscrição excessiva de CPU e memória aqui (e, sinceramente, confio na sua experiência e conselhos mais do que um administrador típico de VM, sem ofensa a eles, mas suspeito que ele tenha uma experiência muito mais direta com a combinação):

O DBA acidental (dia 5 de 30): considerações sobre virtualização

— Aaron Bertrand
fonte

11

Meu entendimento é que algum nível de comprometimento excessivo da CPU pode estar perfeitamente bom, mas isso depende totalmente dos requisitos de carga de trabalho de todos os convidados. Confira o blog de David Klee para obter muitas informações boas sobre VM. Especificamente http://www.davidklee.net/articles/sql-server-articles/cpu-overcommitment-and-its-impact-on-sql-server-performance-on-vmware/ para explicação de comprometimento excessivo da CPU e seu impacto no SQL Server.

O comprometimento excessivo da memória é outro animal inteiramente e, em geral, o host da VM não deve ser comprometido demais na memória se estiver executando servidores SQL. Mais uma vez, usarei David Klee como referência. http://www.davidklee.net/2013/11/04/lock-pages-in-memory-in-sql-server-on-vmware-why-or-why-not/ onde ele explica os efeitos da memória sobre -comprometimento.

Espero que isto ajude.

— cjsommer
fonte