December 3, 2012 at 11:17 am
Hi,
I'm having a hard time to convince IT team that we don't need so many NICs in a dedicated SQL cluster. Besides SAN, I usually use two NICs only, including the one for heartbeat (if we don't use crossover cable)
Can someone , if one, comment about possible Cluster or security issues because this?
Thanks,
December 3, 2012 at 1:08 pm
umm... one nic card can listen to multiple IP addresses, right? so there's no need for 6 nic cards to watch 6 ip addresses, if that's what they are thinking.
here's a link example of one server listening to 40 ip addresses:
and under TCP/IP properties, you can go to the advanced tab and start adding ip's and submasks : for the server to listen to...and from there you would go to SQL configuration manager and handle ip addresews there if they need different ports and such.
Lowell
December 3, 2012 at 1:39 pm
sql-lover (12/3/2012)
Hi,I'm having a hard time to convince IT team that we don't need so many NICs in a dedicated SQL cluster. Besides SAN, I usually use two NICs only, including the one for heartbeat (if we don't use crossover cable)
Can someone , if one, comment about possible Cluster or security issues because this?
Thanks,
Ideally you'll need 2 or 3 NICs teamed for the public connection and one for the heartbeat (this shouldn't be teamed).
You may require a dedicated network for you backups if you have that luxury.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 3, 2012 at 2:38 pm
My bad, we all know 3 is what we need ... 🙂 .... that's what I've being doing since 2003, when I built my 1st cluster.
My question is, what are, the potential problems? I am getting a hard time justifying simple things like these.
Im thinking about these, if you guys agree
-unnecessary network traffic on the server
-more resources
-DNS resolutions problems
-Heartbeat problems (false failures or fail overs)
-More ports to hack or penetrate (surface area)
December 3, 2012 at 4:29 pm
sql-lover (12/3/2012)
My bad, we all know 3 is what we need ... 🙂
No, not necessarily. It all depends on your network infrastructure and your redundancy requirements.
sql-lover (12/3/2012)
I am getting a hard time justifying simple things like these.
I'm not surprised, let's take a look
sql-lover (12/3/2012)
-unnecessary network traffic on the server
offloading network IO to separate adapters does not create unnecessary traffic
sql-lover (12/3/2012)
-more resources
what does this mean?
sql-lover (12/3/2012)
-DNS resolutions problems
The heartbeat adapter will have dns registration and netbios disabled, so no issue. You may also do the same for a backup network. Multiple gateways will cause more real issues than anything.
sql-lover (12/3/2012)
-Heartbeat problems (false failures or fail overs)
failure of the heartbeat network will not cause a failover, loss of the Public connection will.
sql-lover (12/3/2012)
-More ports to hack or penetrate (surface area)
Since the heartbeat and backup networks are segregated how do you come to this conclusion?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 3, 2012 at 4:39 pm
-We won't use any NIC for backups
-They want more NICs so people can connect from other subnets (no sense, in my opinion and current network layout)
-We are using cross over cable for heartbeat
So pretty much, we only need the public network and the one for the private one or heart beat. Simple.
With more IPs and people able to reach my database servers from different places, I will be taking an unnecessary risk or hacking. While keeping one public, which is behind the firewall, I will minimize that risk.
I just don't see the reason of more public NICs on a dedicated SQL server.
I've seen myself resolution issues when having several NICs. You do pings and the other server can't be reached or it replied with a weird name. This is usually because the DNS suffixes, binding order and lot of NICs.
Ohh, forgot to say, they don't want me to alter binding either. How you can justify that? that and disable NetBios is a Microsoft requirement. I've being challenged on both too.
December 4, 2012 at 1:49 am
sql-lover (12/3/2012)
-We are using cross over cable for heartbeat
As i said a segregated network
sql-lover (12/3/2012)
So pretty much, we only need the public network and the one for the private one or heart beat. Simple.
You'll want to provide some redundancy on your Public connection so 2 or 3 adapters teamed for the public interface would be a general config.
sql-lover (12/3/2012)
-With more IPs and people able to reach my database servers from different places, I will be taking an unnecessary risk or hacking. While keeping one public, which is behind the firewall, I will minimize that risk.I just don't see the reason of more public NICs on a dedicated SQL server.
This is something only you can argue with your network\windows admins.
sql-lover (12/3/2012)
I've seen myself resolution issues when having several NICs. You do pings and the other server can't be reached or it replied with a weird name. This is usually because the DNS suffixes, binding order and lot of NICs.Ohh, forgot to say, they don't want me to alter binding either. How you can justify that? that and disable NetBios is a Microsoft requirement. I've being challenged on both too.
You could send them this Microsoft KB that details network set up for a cluster
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 4, 2012 at 7:33 am
Thanks for the MS link, will be useful indeed.
Now, about this remark ...
You'll want to provide some redundancy on your Public connection so 2 or 3 adapters teamed for the public interface would be a general config
If there is not hardware of switch redundancy as well, how you can accomplish that? Not trying to be a hardheaded , lol, just trying to understand your comment. If this is in case the NIC adapter fails, Windows issue? Also, in case this is true, we will have two entries on the DNS tables, for each node.
December 4, 2012 at 8:48 am
Have you used network teaming before??
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 4, 2012 at 10:58 am
Perry Whittle (12/4/2012)
Have you used network teaming before??
I know the concept, but I haven't used it before. Primarily because we were using a different approach on my previous work.
It's using two physical NICs and present it a one to the Os. So if one fails, goes to the other one. Same subnet I guess and using the NIC driver for that. Am I right about that?
But again, these are not being used for Network Teaming, so that's why I don't understand why so many NICs.
December 4, 2012 at 11:50 am
Ok but generally you would want at least 2 or 3 NICs teamed for your public connection to provide redundancy.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 4, 2012 at 1:43 pm
I'm a happy DBA now, or kind of ...
Clarified the issue with them, but still work ahead (different stuff )
December 4, 2012 at 2:19 pm
They read the MS kb did they 😀
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply