Dois servidores de banco de dados espelhados, ou um duas vezes mais poderoso

Question

Eu estou olhando para configurar um servidor de banco de dados separado para um dos meus aplicativos, o aplicativo atualmente é executado em 3 servidores; 1 servidor front-end e 2 servidores de aplicativos / banco de dados. Mas, por motivos de desempenho, estou procurando mover o banco de dados para sua (s) própria (s) máquina (s).

Por isso, é melhor obter dois servidores e configurá-los como réplicas uns dos outros. Ou apenas um servidor, mas torná-lo duas vezes mais poderoso?

Coisas que pensei até agora; Com um servidor:

• Mais fácil de gerenciar
• Mais CPU / memória / disco disponível para o banco de dados, já que o sistema operacional ocupará apenas um lote de recursos
• Mais espaço de armazenamento (se o banco de dados foi replicado, precisaria de 2x a quantidade de armazenamento em disco para armazenar os mesmos dados)
• Mais barato (com servidores alugados só um pouquinho, mas imagino mais em servidores adquiridos)

com dois servidores:

• Melhor redundância (Kernel Panic / Disk Failure / falha de SO / falha de rede e o banco de dados como um todo ainda funcionaria, mas provavelmente diminuiria um pouco)
• Menos IO de disco / rede por servidor (isso tornaria isso mais rápido?)

Alguns detalhes técnicos específicos da minha situação;
Os servidores seriam executados em um serviço de nuvem chamado StormOnDemand, portanto, não teríamos muitos problemas com a confiabilidade do hardware. Poderíamos também escalar verticalmente para cima e para baixo conforme necessário.
Nós usamos 4 sistemas de banco de dados diferentes; Postgresql, MongoDB, Redis e Memcached *
A última vez que verifiquei, a média é de pouco mais de 2 milhões de transações por dia no Postgres, cerca de 2,5 milhões em Mongo, não tenho certeza sobre Redis e Memcached, mas usamos os dois para cache, então imagino que seja o mesmo. Todos os servidores estão conectados por meio de uma rede local de 1 GB / s. Os bancos de dados são, eu diria, de tamanho médio (Postgresql: 32GB, MongoDB: 16GB, Redis e Memcached usam memória para armazenamento, mas acho que atualmente rodam sobre Redis: 12GB e 4GB)
Os servidores que eu estaria procurando ficar seria um 8CPU e 30GB de RAM para um único servidor, ou 4CPU e 8GB de RAM para dois servidores

Para a redundância, é um aplicativo da Web e a grande maioria de nossos visitantes está se recuperando, embora não desejemos tempo de inatividade, ficaríamos felizes com algumas horas por mês para obter a redução de custos obtida um único servidor. Em 6 meses consecutivos com SOD, nunca tivemos nenhum tempo de inatividade, mas isso não quer dizer que isso não aconteça no futuro.

Se eu tiver excluído todos os detalhes que seriam úteis, ficarei feliz em fornecê-los, mas tentei incluir o máximo possível.

* O Memcached continuaria sendo executado nos servidores de aplicativos, nós o usamos como uma espécie de 'cache local', como tal, ele não é replicado / fragmentado entre servidores, usando o Redis como um cache distribuído

    

Answer 1

Normalmente, os bancos de dados se beneficiam de grandes quantidades de ferro. Como regra geral, adicionar caixas extras ajuda no desempenho de servidores da Web e de aplicativos - mas, para bancos de dados, a resposta é geralmente para obter uma máquina maior e mais rápida.

Mas o outro lado disso é que ter mais nós equivalentes sempre melhora a disponibilidade e o desempenho - considere se você gastar US $ 3.000 em um servidor brilhante, pode ter uma probabilidade de falha dentro de seu ciclo de vida de (digamos) 1%. Ou você pode comprar 2 máquinas básicas de especificação com probabilidade de falha de 5%. Você é melhor gastar seu dinheiro na caixa brilhante? Se você olhar para a probabilidade de as duas máquinas básicas falharem, é muito menos - 0.05 * 0.05 * 100 = 0.25%, ou seja, 4 vezes mais confiável.

Mas muito depende do DBMS que você está usando. Os bancos de dados NoSQL são projetados para escalar vários servidores. A replicação do MySQL é relativamente confiável e eficiente. Mas os bancos de dados mysql e nosql tendem a não replicar em tempo real. Se você precisa de consistência em todo o cluster, então você precisa de algo como o Oracle RAC para vários nós - e o IME gera grandes volumes de conversa entre os nós - nesse cenário, seria melhor comprar a caixa maior.

Portanto, no seu caso, mongoDB e Redis definitivamente favoreceriam a solução de múltiplos nós. Meu conhecimento de clustering PostGreSQL é limitado, mas dado seu suporte para consistência em consultas, eu esperaria que ele se comportasse mais como o Oracle (ou seja, quantidades infladas de disco local e E / S de rede).

Eu teria dito que seus conjuntos de dados estão no lado pequeno - na verdade, estou bastante alarmado com o uso de quatro substratos diferentes para gerenciar seus dados - e recomendo strongmente que você os consolide

    

Answer 2

Eu teria que dizer o que você acha que pode fazer com o menor risco de perda de dados. Você fala de usar o armazenamento em nuvem e com isso seria mais prático, na minha opinião, para um único servidor. Você também mencionou que custou algumas vezes, então eu acho que é difícil ganhar dinheiro e é muito mais fácil aumentar as especificações de um único sistema do que obter uma correspondência exata de outro sistema menos poderoso. Sempre se perguntando "Eu realmente preciso disso"? e você nunca pode errar.