Gostaria de fazer uma pergunta sobre as melhores práticas descritas neste documento:

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

Use vários roteadores de consulta. Use vários processos mongos espalhados por vários servidores. Uma implantação comum é a co-localização do processo mongos nos servidores de aplicativos, o que permite a comunicação local entre o aplicativo e o processo mongos. O número apropriado de processos mongos dependerá da natureza do aplicativo e da implantação.

Apenas um pouco de plano de fundo sobre nossa implantação. Temos muitos nós do servidor de aplicativos. Cada um deles executa um processo baseado em JVM com WS RESTful sem estado. Como essa prática recomendada sugere, cada nó do servidor de aplicativos executa seu próprio mongosprocesso, o que significa que o número de processos da JVM sempre é igual ao número de mongosprocessos.

Todos os mongosprocessos se conectam a 3 servidores de configuração e vários shards mongo (com conjuntos de réplicas em cada shard). Mesmo usando uma implantação fragmentada, não estamos realmente fragmentando nossas coleções. De fato, temos um grande número de bancos de dados que estão espalhados por todos os shards durante o tempo de criação (e este é o nosso principal caso de uso para sharding no momento).

Como as práticas recomendadas também sugerem que "o número apropriado de processos mongos dependerá da natureza do aplicativo e da implantação", comecei a pensar se nosso uso mongosé realmente apropriado ou se seria melhor termos vários mongosnós dedicados e permitir nossos servidores de aplicativos se conectam a eles sem mongosexecutar localmente.

Qual sua opinião sobre a melhor abordagem para decidir quantas mongosinstâncias são adequadas em relação à contagem de instâncias do servidor de aplicativos ou ao tamanho do cluster do MongoDB?

Recentemente, começamos a analisar o gerenciamento de cluster para nossos serviços da Web sem estado, com o que quero dizer ferramentas como Docker, Apache Mesos e Kubernetes. Se estivermos usando o Docker, geralmente é uma prática desencorajada executar mais de um processo no contêiner. Considerando esse fato, torna-se muito difícil garantir que o contêiner e o contêiner do servidor de aplicativos mongosestejam sempre co-localizados no mesmo nó físico e tenham a mesma quantidade de processos. Isso me faz pensar se essa prática recomendada ainda se aplica à arquitetura de cluster que acabei de descrever. Caso contrário, você pode sugerir qual seria a melhor maneira de localizar e implantar mongosprocessos nessa arquitetura?

Como já existe uma resposta, e uma útil e válida, não quero me distrair de sua própria utilidade, mas há de fato pontos para elevar isso que vão muito além de apenas um breve comentário. Portanto, considere este "aumento", que é esperançosamente válido, mas principalmente além do que já foi dito.

A verdade é realmente considerar "como seu aplicativo usa os dados" e também estar ciente dos fatores em um "ambiente fragmentado", bem como do "ambiente de contêiner" proposto que afeta isso.

O caso de fundo

A abordagem geral da recomendação prática para co-localizar o mongosprocesso junto com a instância do aplicativo é evitar qualquer sobrecarga de rede necessária para que o aplicativo se comunique com esse mongosprocesso. Obviamente, também é uma "prática recomendada" especificar um número de mongosinstâncias na cadeia de conexão do aplicativo no caso em que o nó "mais próximo" não esteja disponível por algum motivo, então outro poderá ser selecionado, embora com a possível sobrecarga de contato com um nó remoto.

O caso "docker" que você menciona parece um tanto arbitrário. Embora seja verdade que um dos principais objetivos dos contêineres (e antes disso, algo como cadeias BSD ou mesmo chroot) geralmente seja atingir algum nível de "isolamento do processo", não há nada realmente errado em executar vários processos, desde que você entender as implicações.

Nesse caso em particular, ele mongosdeve ser "leve" e ser executado como uma "função adicional" no processo do aplicativo, de forma que é praticamente uma parte "emparelhada" do próprio aplicativo. Portanto, as próprias imagens do docker não possuem um processo do tipo "initd", mas não há realmente nada de errado em executar um controlador de processo como supervisord (por exemplo) como o processo principal do contêiner, o que lhe dá um ponto de controle do processo. esse recipiente também. Essa situação de "processos emparelhados" é um caso razoável e também é bastante comum pedir que exista documentação oficial para isso.

Se você escolher esse tipo de operação "emparelhada" para implantação, ela realmente abordará o ponto principal de manter uma mongosinstância na mesma conexão de rede e, de fato, "instância do servidor" que o próprio servidor de aplicativos. Também pode ser visto de alguma forma como um caso em que o "contêiner inteiro" falharia, então esse nó em si seria simplesmente inválido. Não que eu o recomende e, na verdade, você provavelmente ainda deve configurar conexões para procurar outras mongosinstâncias, mesmo que estas sejam acessíveis apenas por uma conexão de rede que aumente a latência.

Versão específica / Uso específico

Agora que esse ponto foi levantado, a outra consideração aqui volta à consideração inicial de co-localizar o mongosprocesso com o aplicativo para fins de latência de rede. Nas versões do MongoDB anteriores à 2.6 e especificamente em operações como a estrutura de agregação, havia o caso de haver muito mais tráfego de rede e subsequente trabalho de processamento após o processamento realizado pelo mongosprocesso para lidar com dados de diferentes shards . Esse não é o caso agora, já que boa parte da carga de trabalho de processamento agora pode ser executada nesses shards antes de "destilar" o "roteador".

O outro caso são os próprios padrões de uso do aplicativo em relação ao sharding. Isso significa se a carga de trabalho principal está em "distribuir as gravações" entre vários shards, ou mesmo sendo uma abordagem de "coleta dispersa" na consolidação de solicitações de leitura. Nesses cenários

Teste, Teste e Teste novamente

Portanto, o ponto final aqui é realmente autoexplicativo e se resume ao consenso básico de qualquer resposta sensata à sua pergunta. Isso não é novidade para o MongoDB ou qualquer outra solução de armazenamento, mas seu ambiente de implantação real precisa ser testado em seus "padrões de uso" tão próximos da realidade real quanto em qualquer "teste de unidade" da funcionalidade esperada dos componentes principais ou os resultados gerais precisam ser testados.

Realmente não existe uma declaração "definitiva" para dizer "configurar desta maneira" ou "usar dessa maneira" que realmente faz sentido, além de testar o que "realmente funciona melhor" para o desempenho e a confiabilidade do aplicativo, conforme o esperado.

Obviamente, o "melhor caso" sempre será não "agrupar" as mongosinstâncias com solicitações de "muitas" fontes do servidor de aplicativos. Mas, então, permitir a eles alguma "paridade" natural que pode ser distribuída pelas cargas de trabalho de recursos disponíveis para ter "pelo menos" um "conjunto de recursos" que pode ser selecionado e, de fato, idealmente em muitos casos, mas evitando a necessidade de induzir um adicional "sobrecarga de transporte de rede".

Esse é o objetivo, mas, idealmente, você pode "testar em laboratório" as diferentes configurações percebidas para obter uma solução "mais adequada" para sua eventual solução de implantação.

Eu também recomendaria fortemente os cursos "gratuitos" (como na cerveja) disponíveis, como já mencionado, e independentemente do seu nível de conhecimento. Acho que várias fontes de material do curso geralmente oferecem "joias escondidas" para fornecer mais informações sobre coisas que você pode não ter considerado ou ignorado. A classe M102, conforme mencionado, é construída e conduzida por Adam Commerford, para quem posso atestar que possui um alto nível de conhecimento em implantações em larga escala do MongoDB e outras arquiteturas de dados. Vale a pena considerar pelo menos uma nova perspectiva sobre o que você acha que já sabe.

Como as práticas recomendadas também sugerem que "o número apropriado de processos de mongos dependerá da natureza do aplicativo e da implantação", comecei a pensar se nosso uso de mongos seria realmente apropriado.

Penso que esta é uma pergunta que, em última análise, apenas você pode responder, como refere a documentação.

Uma das estratégias recomendadas é ter um mongosserviço em cada um dos nós do aplicativo e, possivelmente, até um nó dedicado extra, para disponibilidade adicional. Como você tem isso atualmente, não vejo nada de errado com sua implantação atual. Se nada estiver mudando em sua arquitetura, você estará dentro das melhores práticas atualmente. Contudo...

Se estivermos usando o Docker, geralmente é uma prática desencorajada executar mais de um processo no contêiner.

Como o mongosprocesso não exige muitos recursos, você também pode colocar uma instância dele em cada um dos seus shards e permitir que cada mongodnó também atue como um mongosnó. Isso pode fazer mais sentido se você tornar a arquitetura do servidor de aplicativos um pouco mais complexa.

Pessoalmente, não estou muito familiarizado com esses produtos, mas também verificaria as recomendações do fornecedor, pois mongospode ser menos intensivo do que a maioria dos outros processos que você pode executar lado a lado.

Por fim, você sempre pode contratar nós dedicados para o mongosprocesso, dependendo da sua escala, recursos etc., que também se enquadram nas melhores práticas. A verdadeira vantagem aqui é que, desde que você tenha vários mongosprocessos em algum lugar , estará bem.

Quantos realmente dependem do tamanho dos seus requisitos de implantação e SLA. Se você usar os shards, terá mais do que suficiente, mas se usará nós dedicados, tentarei corresponder o número de nós de aplicativos o mais próximo possível.

Você pode conferir este vídeo no curso on-line do MongoDB M102, que aborda esses tópicos, e pode tentar se inscrever na classe M102 para DBAs na próxima vez em que estiver na sessão (gratuito, on-line).