3 ms·

Everyone’s experience is different. I’ve run networks with millions of servers with single NICs and networks with thousands of servers with dual NICs. The dual

by erentz 7y ago

Everyone’s experience is different. I’ve run networks with millions of servers with single NICs and networks with thousands of servers with dual NICs. The dual NICs are a cost and complexity and outage inducing nightmare that’s totally unjustifiable at any large scale. Yes it can be warranted for smaller and specialized use cases, particularly with older software. But you can’t push that kind of complexity into the network at very large scale and have it pay off. One day your rack will fail and your software will need to deal with it gracefully enough. IMO solve it at the application level don’t make the network try to do it for you.

toast0 7y ago
I don't think I'm going to convince you, but let me try one more time :) > One day your rack will fail and your software will need to deal with it gracefully enough. IMO solve it at the application level don’t make the network try to do it for you. I agree, the rack is going to fail, and you have to be able to handle it. It's a question of what the consequences are, and how often you have them. Without a radically atypical socket setup, you're going to at least lose the state of clients connected to hosts in the rack that fails. That will, at least, cause significant communication delays while the connection loss is determined. Probably your clients are well behaved and will reconnect and retry their requests. Most requests will be retried in a timely fashion, but some of your clients are going to have an independent network failure around the same time, and their requests are going to suffer a major delay (I'm mobile oriented, so I'm trying to send a message before I go into the dead zone, etc). Like you said, it's going to happen sometimes anyway. Redundant networks and redundant power only mitigate outages, they don't eliminate them, and there's always room for human error. But, I would pay several times the cost of the network to be able to have a significantly reduced frequency of outages.
- erentz 7y ago
  I hear what you’re saying :-) it is fairly easy to model once you have good data, I can certainly see if you do the modeling there may be some that find it’s worth it for their case.
rbanffy 7y ago
> IMO solve it at the application level don’t make the network try to do it for you. You'll still have far fewer catastrophic failures if you run redundant hardware.

by erentz 7y ago

toast0 7y ago

I don't think I'm going to convince you, but let me try one more time :) > One day your rack will fail and your software will need to deal with it gracefully enough. IMO solve it at the application level don’t make the network try to do it for you. I agree, the rack is going to fail, and you have to be able to handle it. It's a question of what the consequences are, and how often you have them. Without a radically atypical socket setup, you're going to at least lose the state of clients connected to hosts in the rack that fails. That will, at least, cause significant communication delays while the connection loss is determined. Probably your clients are well behaved and will reconnect and retry their requests. Most requests will be retried in a timely fashion, but some of your clients are going to have an independent network failure around the same time, and their requests are going to suffer a major delay (I'm mobile oriented, so I'm trying to send a message before I go into the dead zone, etc). Like you said, it's going to happen sometimes anyway. Redundant networks and redundant power only mitigate outages, they don't eliminate them, and there's always room for human error. But, I would pay several times the cost of the network to be able to have a significantly reduced frequency of outages.

erentz 7y ago
I hear what you’re saying :-) it is fairly easy to model once you have good data, I can certainly see if you do the modeling there may be some that find it’s worth it for their case.

rbanffy 7y ago

> IMO solve it at the application level don’t make the network try to do it for you. You'll still have far fewer catastrophic failures if you run redundant hardware.