[SERVER-1889] Support different networks / nics for client & replication traffic Created: 05/Oct/10  Updated: 08/Jan/24  Resolved: 08/Dec/21

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 1.7.0
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Alvin Richards (Inactive) Assignee: Backlog - Service Architecture
Resolution: Won't Do Votes: 26
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-40314 Cannot connect to replica set Closed
is duplicated by SERVER-26817 replset member connect to each other ... Closed
is duplicated by SERVER-34060 Intranet & Internet Address in mongod... Closed
is duplicated by SERVER-3098 Allow replica sets to use separate ne... Closed
is duplicated by SERVER-22321 Can I use several IP addresses for Re... Closed
Related
related to SERVER-34986 CIDR Block That is Exempt from maxConns Closed
is related to DOCS-8596 Make clear in server docs as well as ... Closed
is related to SERVER-20461 Write tests to verify replica set ope... Backlog
is related to SERVER-36603 Support for multiple hostnames and IP... Backlog
Assigned Teams:
Service Arch
Participants:
Case:

 Description   

Problem:
In order to scale network traffic for client connections and replication traffic, there are two options

a) add a NIC
b) swap out a 1Gig for a 10Gig Ethernet Card

Case b) is already supported. However, to support case a) we would need to be able to specify different networks for
– client connections (and failover of client connections)
– replication connections

Impact:

This would impact
– mongod would need to accept connections over more than a single interface
– replSetInitate configuration would need the ability to specify a different ip/port for the replication traffic

Other:
Would need test cases for the client nic failover from the replication nic failover.



 Comments   
Comment by John Bito [ 22/Aug/16 ]

We would also like to see the ability to configure clients with different connection URIs, so that the DB host appears to be in the same network sub-domain as the client, while serving clients in various sub-domains.

Comment by Scott Hernandez (Inactive) [ 03/Jun/12 ]

This can be done today by simply having the configured names resolve to the correct network/interface by the respective clients.

For example, configure all names as relative host names, not fully qualified. Then configure each tier (web/app, replicas, etc) with a different domain search order where the FQDN resolves to the different ip/interface. This can also be done by overriding resolution in any other way, like via /etc/hosts. When the client or other replica member resolve the name they will now point to the correct ip/interface depending on their role.

It would good if it supported this on the server to specify priority/access control as an additional feature for cases like this.

Comment by Chris Westin [ 12/Sep/11 ]

I just got request for this from another customer. They cite the following reasons:

  • security, since replication traffic is sent in the clear
    e.g. exchange allows this
  • performance
    can apply QoS rules over a WAN link in order to prefer this
  • doing this with MySQL and MSSQL today
    easier to manage by differentiating the traffic
    clients won't compete for bandwidth with the replication traffic
Generated at Thu Feb 08 02:58:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.