Conjunto de réplicas Mongo atrás do firewall

Question

Dado que você executa uma versão atual (3.2) do MongoDB como um conjunto de réplicas em sua rede que consiste em 3 nós:

mongo1.local
mongo2.local
mongoarbiter.local

Agora, esses nós devem estar disponíveis via internet pública (restrita via FW). mongo1 e mongo2 receberão um VIP no firewall e alguns A-Records válidos:

mongo1.example.com
mongo2.example.com

O árbitro não está exposto.

Agora, algumas implementações de cliente simplesmente funcionam bem (python) se você passar os nomes DNS externos por meio da string de conexão. Mas outros (Java) não conseguirão se conectar, já que o conjunto de réplicas só conhece seus nomes internos. Os clientes irão analisar a lista de nós fornecidos pelo rs, observe que o nome externel que ele conectou não está na lista e falha:

Monitor thread successfully connected to server with description ServerDescription{address=mongo1.example.com:27017, type=REPLICA_SET_PRIMARY, state=CONNECTED, ok=true, version=ServerVersion{versionList=[3, 0, 14]}, minWireVersion=0, maxWireVersion=3, maxDocumentSize=16777216, roundTripTimeNanos=5305689, setName='mongo-rs', canonicalAddress=mongo1.local:27017, hosts=[mongo2.local:27017, mongo1.local:27017], passives=[], arbiters=[mongo3.local:27017], primary='mongo1.local:27017', tagSet=TagSet{[]}, electionId=5821da77ccc118202cd2b75d, setVersion=3}

Existe alguma solução para isso além de mexer com o / etc / hosts no sistema do cliente?

BTW: isso faz o truque com o cliente js lib, mas também parece um pouco sujo:

replSet.connectWithNoPrimary

    

Answer 1

Os drivers oficiais do MongoDB implementam um Especificação do Server Discovery and Monitoring (SDAM) , que está disponível no GitHub no % repositóriomongodb/specifications . A especificação do SDAM entra em mais detalhes sobre o comportamento esperado e a justificativa para os drivers.

A expectativa atual é de que clientes sempre usarão os nomes de host listados na configuração do conjunto de réplicas , não a lista de propagação fornecida em uma cadeia de conexão. A principal motivação para isso é ativar o failover e a reconfiguração automáticos com base em uma configuração de conjunto de réplicas (que inclui nomes de host e portas).

Is there any solution to this other than messing with /etc/hosts on the clients system?

Se você não precisar de failover, poderá se conectar a um único servidor em vez de usar uma conexão de conjunto de réplicas. Uma conexão autônoma / direta não deve implementar nenhuma descoberta de servidor.

No entanto, se você estiver se conectando a outro servidor que não seja autônomo, não há soluções alternativas no momento além de mexer na resolução do nome do host para corresponder à configuração do conjunto de réplicas ou estender o perímetro de rede (por exemplo, usando uma VPN).

Uma sugestão de recurso relevante para upvote / assistir é: SERVIDOR-1889: Suporte a redes / nics diferentes para o cliente & tráfego de replicação . Isso poderia permitir a separação da comunicação da rede interna para o conjunto de réplicas das conexões do cliente.

    

Answer 2

Se você configurar um cluster sharded, poderá se conectar diretamente ao processo mongos e deixar que se preocupe com os nomes dos hosts internos / externos dos nós no conjunto de réplicas.

Se você fizer parte do seu replicaset de um cluster sharded , todas as conexões do cliente passarão por um mongos servidor. O mongos mantém suas próprias conexões com os nós no conjunto de réplicas (e pode fazê-lo usando os nomes internos mongo1.local, etc.); o cliente só se conecta aos mongos, e é permitido fazê-lo usando qualquer nome que desejar - ele não precisa corresponder aos nomes de host usados internamente.

Portanto, mesmo que você não queira usar sharding para escalonamento de dados, pode ser útil evitar o problema de endereçar uma réplica definida por nomes de host externos?