Nic redundancy via MCSG

[patrick coutinho]

Hi,

I have a query. Is the nic redundancy offered by MCSG similar to the concept of Teaming nic cards with the failover option in Wintel servers.

I know that MCSG offers the capability of configuring a standby nic card (no ip address) as the failover nic for the (example) primary data lan.

What i want to know is whether the failover is seamless, i.e. not user sessions are maintained upon failover and not terminated.

Please advise.

Thanks in advance,

Patrick

[Steven E. Protter · Accepted solution]

There is a delay, usually interpreted by the user as slow response while the failover occurs.

The sessions are not terminated.

SEP

[patrick coutinho]

Thanks Steven,

There was an opinion among some of my colleagues that stated that though the lan will failover, it would result in session loss. Since we are going to go in for an extra lan card in our cluster specifically for the purpose of lan redundancy, i needed to be sure. We have a rp3440 and we currently have a provision only for a failover heartbeat lan. In order to reduce the spof's, we are thinking of adding a secondary lan card to behave as the failover for the data lan.
We have 7 instances of oracle running on this server, in seven packages. These service various countrier. Hence we do not want the sessions to be terminated in case of a lan failover, since ALL the users would they have to reconnect and this will impact the image of our client.

Many thanks once again.

Points assigned. Patrick

[Steven E. Protter]

No points necessary, should have been in the original reply.

I would suggest in spite of what I've said, based on playing around with SG that you conduct a test.

Its a pain, but you should take the time to set up a two node cluster, make oracle failover, connect a few user sessions and then force the primary node to fail.

This will make everyone happy when you see what I've said is true.

SEP

[A. Clay Stephenson]

You should also look at a product called Auto-Port Aggregation (APA); it should not be considered as a replacement for MC/SG but rather as a complement to MC/SG. In addition to providing higher throughput, it also eliminates most of the delay related to NIC failover because most NIC failovers simply don't place. Your might lose half of your throughput but no disconnects occur.

As with all network failovers, the behavior during the transition is determined by how the client handles it and must be tested. I should also tell you that simply having extra NIC's is not sufficient; you also need redundant, independent switches and/or hubs so that the failure of any one thing doesn't kill you. You will find that if you handle all the things required for MC/SG that MC/SG very, very seldom comes into play itself because the underlying systems are now so robust.

[melvyn burnard]

If you have a standby lan configured for a primary lan, the if the primary lan were to fail then everything should switch from that failed lan to the standby with no loss of session. This is known as Local Lan Failover, and is transparent to users sessions.
If, however, the whole subnet were to fail, i.e. there was a problem that resulted in a local lan failover not to work, then you get a remote failover, i.e. the package(s) would switch to the remote node. This DOES cause a session disconnect unless you have a user client that can handle this.
In your current configuration, then as you do not have a standby lan yopu cannot do local lan failover, hence the packages will switch. This maybe where the confusion is coming in.