Produção pesada MySQL / Percona Database no container openvz

1

Portanto, estou atualmente executando um banco de dados MySQL 5.1, com as seguintes especificações:

  • Proc: CPU Intel (R) Xeon (R) E5-1620 0 @ 3.60GHz
  • RAM: 64 Go
  • discos: SSD 2x 100 Go (RaidSoft)

Estou planejando migrar meu servidor físico e meu servidor mysql para um servidor Percona 5.6.

Estou usando um cluster Proxmox para o resto da minha infraestrutura, portanto, gostaria de colocar meu novo servidor MySQL em um contêiner openvz dedicado (apenas um no host).

Já corri para configurar isso e parece funcionar bem, mas ainda estou pensando se é uma boa ideia.

Algum feedback?

    
por Trent 11.02.2014 / 11:17

4 respostas

1

Tenha cuidado ao usar o OpenVZ (Proxmox ou outro) para qualquer operação onde possa haver muita E / S de disco. Eu posso dizer por experiência que é muito, muito lento - cerca de metade da velocidade do hardware nativo em alguns casos. É especialmente ruim com as gravações, e fica pior quanto mais contêineres estiverem no servidor fazendo leituras e gravações (a última parte disso não se aplica no seu caso).

Além disso, lembre-se que o MySQL está com muitos recursos e pode facilmente matar o OOM ou atingir um limite de contêiner se você não tiver configurado corretamente. Mais uma vez, por experiência, isso pode ser difícil de fazer. Há também o fato de que certas coisas para ajudar o MySQL a ter melhor desempenho, como as "abraepages", não podem ser definidas dentro do contêiner, então você pode acabar trocando de hospedeiro para convidado.

Sobre as únicas coisas que você vai deixar de colocar o MySQL em um container são o isolamento do processo (mas não realmente), algumas garantias suaves de que o container não vai derrubar o nó (mas sem garantias), uma bonita interface para controlar o seu servidor com (não exclusivo para recipientes OpenVZ), e um monte de dores de cabeça até que seja configurado corretamente. Eu evitaria o OpenVZ para este uso particular.

Se você estiver pronto para usar o Proxmox, sugiro usar o KVM para essa finalidade em vez de um contêiner OpenVZ. Você terá menos dores de cabeça, acredite em mim.

    
por 17.02.2014 / 05:32
0

Existem alguns benefícios em executar o MySQL em um contêiner.

Os contêineres PVE oferecem alguns benefícios: - Gerenciar o servidor de banco de dados e não afetar mais nada - Mova-se facilmente (on-line, se estiver usando armazenamento compartilhado) para outro host físico - backup com PVE, embora, xtrabackup ou Idera Hot Copy seja melhor na minha opinião - Execute 2 ou mais deles, em um cenário de replicação mestre-escravo, para que você tenha servidores SQL de backup "ativos", mas isso criará um único ponto de falha se eles estiverem no mesmo servidor físico.

Prox é muito confiável, não há dúvida sobre isso - eu tenho servidores proxmox que tem até 800 dias +. Se você correr em contêineres, você terá apenas um pequeno impacto no desempenho. Apenas certifique-se de alocar os núcleos da CPU na VM para que o innodb possa fazer uso deles.

    
por 12.02.2014 / 07:57
0

Para um servidor de produção pesado, não vejo o objetivo de usar um contêiner. Não há vantagem real na minha experiência. Talvez colocar um escravo ou alguns escravos em contêineres faça sentido, mas o mestre, eu colocaria em metal puro. Confira o cluster percona. Isso arrasa.

Quais foram seus motivos para querer usar uma VM? Qual é o caso de negócios?

    
por 17.02.2014 / 05:06
0

Em resposta ao "não faça isso por motivos de desempenho", usamos o Proxmox em um ambiente muito pesado (70% INSERTs), com um back-end RAID-10 em discos normais (WD Red) e vários outras VMs ocupadas (OpenVZ e KVM) e não têm problemas de desempenho de gravação (o iodelay raramente sobe acima de 0%). Se a sua consideração é apenas de desempenho, então deve haver zero problemas se o hardware subjacente for decente.

Benefícios sábios - migração on-line, backups de snapshots, expansão de drivespace ... tudo isso por lá.

Quanto à confiabilidade do proxmox, só consigo ecoar outro pôster.

tempo de atividade

19:51:09 até 785 dias, 22:59, 1 usuário, média de carregamento: 4,92, 4,81, 4,79

tempo de atividade

19:51:55 até 142 dias, 4:56, 1 usuário, média de carregamento: 0,05, 0,07, 0,05

    
por 14.05.2014 / 20:46