Quais são os inconvenientes de executar um banco de dados dentro de uma máquina virtual? Como posso superá-los? [fechadas]

Question

Executar qualquer coisa dentro de uma máquina virtual terá algum nível de desempenho, mas o quanto isso realmente afeta o desempenho de um sistema de banco de dados?

Eu encontrei este documento de referência acadêmica com alguns pontos de referência interessantes, mas era um limite teste usando apenas Xen e PostgreSQL. A conclusão foi que o uso de uma VM "não tem um alto custo em desempenho" (embora você possa achar que os dados reais digam o contrário).

Quais são as desvantagens técnicas, administrativas e outras associadas à execução de um banco de dados em uma máquina virtual?

Por favor, poste respostas que possam ser apoiadas por fatos objetivos, eu não estou interessado em especulações ou qualquer outro argumento semi-religioso (a paixão geek é boa em muitos aspectos, mas isso não nos ajudará aqui).

Dito isto,

• What issues show up when running database in a Virtual Machine? (please post references)
• Are those issues significant?
  • Are they only significant under certain scenarios?
• What are the workarounds?

    

Answer 1

Embora muitos fornecedores de banco de dados estivessem muito lentos para fazer isso, quase todos agora suportam oficialmente seu software em execução em um ambiente virtualizado.

Nós executamos muitas instâncias do Oracle 11g no linux em cima do ESXi, e é certamente possível obter um desempenho muito bom. Como com todo o escalonamento de hardware, você só precisa ter certeza de que o host de virtualização tem muitos recursos (RAM, CPU) e que sua camada de disco está pronta para entregar qualquer desempenho de IO que você precisar .

    

Answer 2

Como ErikA diz, isso está se tornando cada vez mais comum. Estou no campo do SQL Server e não tenho nenhum sistema de produção em execução nas VMs, mas não hesitaria (depois de um pouco mais de estudo sobre o assunto). Definitivamente, algumas coisas devem ser levadas em consideração antes de você ir por esse caminho (pelo menos para o SQL Server). O disco IO (como outros já mencionaram) e a alocação de memória são apenas dois exemplos. As coisas também serão diferentes entre os diferentes hipervisores.

Brent Ozar é um especialista reconhecido em virtualizar o SQL Server, especificamente no VMWare. Eu recomendo a leitura através de seu material.

link

    

Answer 3

Existe pode e depois deve . Uma corveta pode andar a 150 km / h, mas em estradas públicas? Você pode se machucar desnecessariamente.

Bancos de dados são sistemas operacionais convidados. Por design, quando eles começam, eles capturam blocos de um recurso e o gerenciam diretamente por motivos de desempenho. Assim que você tornar o sistema operacional central do servidor de banco de dados um convidado em um ambiente de hospedagem virtualizado, estará colocando uma camada de arbitragem com o hypervisor entre o elemento alocado em bloco do disco e a RAM e o servidor de banco de dados. Vai diminuir a velocidade. Quanto mais ineficientes forem as suas consultas, mais ela ficará lenta. Essas ineficiências podem ser mascaradas hoje em hardware dedicado, mas assim que você introduzir a arbitragem em seu recurso dependente, você descobrirá rápido.

O grande número de contadores de beans que estão exigindo que a virtualização não reconheça é que os servidores de banco de dados, como sistemas operacionais convidados, oferecem sua própria camada de consolidação. Não há motivo para não conseguir migrar várias instâncias de bancos de dados lógicos em um servidor físico, até mesmo para mover endereços IP, configurar nomes de host adicionais, etc ..., para permitir a união natural de serviços. E, com esse modelo, você não apenas retém as economias de custo que o gerenciamento está pressionando por um número reduzido de hosts físicos, mas retém o bloqueio de acesso a recursos físicos sem o impacto do hipervisor arbitrário, que pode tomar decisões benéficas às vezes e não outros.

O mesmo vale para outros sistemas operacionais convidados, como o Java. As soluções de virtualização geralmente são ambientes ocupados e o hipervisor precisa tomar muitas decisões sobre quem "recebe o token" em um recurso. Sempre que você puder eliminar essa camada, ficará melhor.

Una várias instâncias usando a camada natural do sistema operacional convidado em primeiro lugar. É provável que você consiga acertar mais facilmente seus objetivos de consolidação e desempenho da plataforma.

    

Answer 4

Há duas coisas para perceber aqui:

• A unidade de desempenho do banco de dados por unidade de hardware é um pouco menor para um banco de dados virtualizado. Isso significa que você precisa comprar um pouco mais de hardware para obter o mesmo nível de desempenho.
• Isso não significa que o mesmo nível ou um nível desejado de desempenho é inatingível. Os ganhos obtidos com o gerenciamento aprimorado e outros benefícios (como o HA mais fácil) muitas vezes caminho mais do que compensam os custos de hardware aumentados marginalmente.

Dito isto, onde eu trabalho, a nossa instalação do Sql Server é um dos dois únicos servidores que eu não pretendo virtualizar em breve (o outro é o DC primário).

    

Answer 5

A execução do SQL Server é uma VM, desde que você possa fornecer recursos suficientes para a VM executar seu aplicativo. Se no mundo físico você precisa de 24 núcleos e 256 Gigs de RAM, então você precisa fornecer 24 vCPUs e 256 Gigs de RAM no mundo virtual.

Eu apenas escrevi um artigo nos últimos meses, na revista SQL Server, sobre a execução do SQL Server no vSphere da VMware.

    

Answer 6

Eu corro dois bancos de dados, um PostgreSQL e outro MySQL, em um ambiente virtual (Xen) onde os dom0s são altamente disponíveis. Os sistemas de arquivos domU estão todos localizados em um SAN LUN iSCSI, dividido com volumes lógicos LVM2. O banco de dados MySQL é unicamente para o Cacti e, portanto, não vê muito uso, e também está localizado no iSCSI LUN.

O banco de dados PostgreSQL é o banco de dados para o nosso ambiente de preparação e, portanto, vê uma maior utilização do que o banco de dados MySQL. Por esse motivo, o banco de dados está localizado em um conjunto RAID10 local e o DRBD é replicado no segundo nó do cluster. No entanto, em termos de carga real, esse banco de dados de preparo não vê carga muito alta. O que, na minha opinião, faz com que seja um bom / ótimo candidato para virtualizar.

Alguns dos benefícios para a nossa organização foram o baixo consumo de energia, o espaço economizado em rack e a menor sobrecarga administrativa de hardware.

Nosso principal banco de dados de produção, por outro lado, não consigo me imaginar como virtual ...

    

Answer 7

Eu trabalho com servidores MSSQL e MySQL em vários servidores. Há alguns anos, hesitei em começar a configurar servidores SQL em VMs, porque tinha ouvido falar sobre os problemas de desempenho da execução de um servidor SQL em uma VM. No entanto, fiquei surpreso depois de configurar meus primeiros servidores SQL e não vi nenhuma mudança no desempenho. Cada vez mais os servidores em que trabalho estão na VM e quase todos os clientes corporativos maiores para os quais trabalho virtualizaram servidores SQL.

Sim, a VM adiciona alguns custos indiretos e, se você for hospedar várias VMs em uma única caixa, precisará de um bom servidor robusto. Um problema comum de recursos a ser observado é adicionar VMs adicionais e reduzir os recursos disponíveis. É uma prática comum planejar um pouco de crescimento, mas se você comprou o seu servidor para hospedar 2 ou 3 VMs e agora ele está executando 10 VMs, provavelmente verá um impacto no desempenho.

Eu estaria mentindo se dissesse que nunca vi problemas de desempenho executando um servidor SQL em uma VM. Mas eu aprendi que, se você está vendo um desempenho ruim, provavelmente há algo errado com o ambiente.