Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

enter image description here

As you can see, my two Windows Server Failover Cluster (WSFC) nodes have three network interfaces each, which connects them to three different networks :

  1. A public network
  2. A private network consisting of the WSFC nodes
  3. A private network consisting of the WSFC nodes and a machine with the WSFC Quorum Witness File Share

Does this network configuration I've planned, make sense? Do I have the "right" number of NICs and networks? I'm thinking the 2nd NIC/network may be unnecessary.

My two MongoDB Replica Set nodes also have three network interfaces each - very similar to the previous situation:

  1. A public network
  2. A private network consisting of the primary and secondary MongoDB Replica Set nodes
  3. A private network consisting of the primary, secondary and arbiter MongoDB Replica Set nodes

Does this network configuration, make sense? Do I have the "right" number of NICs and networks? I'm thinking the 2nd NIC/network may be unnecessary.

Here is the simpler version I'm considering: enter image description here

UPDATE:

enter image description here

share|improve this question

1 Answer 1

up vote 1 down vote accepted

There are two questions here, one for MS clustering, and another one for Mongo.

MS Clustering

The decision of where to put the public, heart-beat, inter-node communication, and quorum drive is significant. Also cluster architecture makes a difference; you pick different quroum options if the two nodes are in adjacent racks than if they were in completely different datacenters.

Put the heartbeat on the same interface/subnet as the public interface

This theory holds that if you lose your public interface, you want the heartbeat to fail because this node is effectively down to users.

Put the heartbeat on it's own private interface/subnet

This theory holds that something outside of the cluster is arbiting who is doing what role, and unnecessary node-death is to be avoided.

Put the WFS on the heartbeat network

If the two nodes are in the same overall network (the same set of switches is supporting the non-public networks for both nodes) then putting the WFS on the heartbeat network doesn't introduce any new vulnerabilities.

If the two nodes are in different network fault domains (such as different datacenters), this is a bad idea. The heartbeat network provides the 'node majority' quorum option, and the WFS provides the 'File Share Majority' quorum option. You really want both options to be in separate fault domains.


Your revised diagram makes sense if both nodes are in the same data-center, though I myself would but the heartbeat on the public side.

MongoDB

MongoDB is a bit simpler. With even numbers of nodes, you absolutely want a third node to act as tie-breaker. They're pretty clear about that. However, your diagram states:

Up to 12 replica members (7 can vote).

7 is an odd number. You don't require an Arbiter.

Unlike Microsoft clusters, Mongo's cluster voting doesn't care about multiple avenues of network to break voting deadlocks. Because of this, separate arbitration and cluster-internal networks do not provide any meaningful increase in robustness. The only reason you'd want a separate arbitration network is if replication traffic was expected to be so heavy that election-packets (the heartbeat, actually) would get pushed so far down the stack that it would miss the 10 second timeout.

share|improve this answer
    
I re-organized my diagram and added a web server. The WSFC nodes are currently in the same datacenter on the same ESXi host. In production they will probably be in geographically seperate datacenters. For MongoDB I will only have two replica members plus an arbiter, as this is a development environment (the text you mentioned was informational only). Are you saying one NIC on each MongoDB connecting it to the public network would be enough? (That would also obviously mean that the #2 NICs on the Arbiter is also unnecessary.) –  arex1337 Oct 6 '12 at 13:59
1  
@arex1337 Mongo is not as cluster-featured as MS is, so you can very well get away with only the single NIC in MongoDB. Where it would be a good idea to have a second is if you want replication traffic to flow across a different interface. But the arbiters don't need a public NIC. –  sysadmin1138 Oct 6 '12 at 14:16
    
I removed the private network for the MongoDB nodes (blue color). Now I'm trying to justify the private network for the SQL nodes (red color). Do I really have a good reason to have them? Perhaps I can drop those NICs too. What do you think? –  arex1337 Oct 6 '12 at 20:23
1  
@arex1337 Depends on how close you want dev to mirror the prod build. If you want a close mirror, keep 'em. If you just want it to work as cheap as possible, you can live with just the one. –  sysadmin1138 Oct 6 '12 at 21:32
1  
@arex1337 Since it's all going to be in ESX anyway, multiple NICs won't make much difference. Though, if the path the heartbeat/WFS traffic would be different than public, it would be a good idea for a 2nd vNIC. –  sysadmin1138 Oct 6 '12 at 22:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.