Fastest Way to Network Two Servers?

[JRA]

Hi all - bear with me on this one!

 

I want two servers to talk to each other as quick as poss. Best way I can figure is this:

 

- Single NIC set aside on each, connected via crossover cable.

- Each NIC in a subnet not used anywhere else, say 10.0.0.1/30 on one, 10.0.0.2/30 on the other.

- Change the hosts file on each so that the name of each server points to the new address above.

- ????

- Profit.

 

This sound sane enough? Thanks for any help or suggestions!

[Norphy]

Don't use a crossover cable on gigabit NICs, you'll restrict them to 100mbps. Using a straight ethernet cable will work, gigabit NICs have auto MDIX

 

Otherwise, what exactly are you hoping to achieve?

Edited December 5, 2018 by Norphy

[JRA]

Cheers Norphy! I'm trying to get a PARS and SIMS server talking to each other as fast as possible, and this direct connection seems to be the best way.

[AJWhite1970]

Before you go through that pain, have you asked TASC to tune up your copy of PARS? When Liam was on-site with me setting up PARS he ran several config scripts and access time greatly improved as a result.

[JRA]

Before you go through that pain, have you asked TASC to tune up your copy of PARS? When Liam was on-site with me setting up PARS he ran several config scripts and access time greatly improved as a result.

Hi - did run it by Liam (nice guy btw, as is Grant) and he said maybe look at the speed at which it talks to the SIMS server. Currently SIMS server has 3x teamed gb NICs, PARS server 4x teamed gb NICs, both into core switch. Just wondering if they'd both benefit from connecting directly as I pondered above.

[dhicks]

Just wondering if they'd both benefit from connecting directly as I pondered above.

 

I'd be surpised if network speed is the limiting factor, I'd guess it's more likly to be disk / swap size or speed, RAM allocation or database configuration. We attempted to increase the performance of our MIS by doubling the available CPU and RAM, but the underlying database simply wasn't able to actually make use of the resources - if the database is designed in a way where a bunch of tables are locked for a given operation then there's not really much you can do (although increasing the avaulable RAM or write speed of the underlying disk might help).

 

You should be able to see if the network is being a bottleneck from a simple performance monitor - is the network actually hitting 100% usage at any point?

[pete]

Concurr with @dhicks, I doubt it's a network speed issue unless you've misconfigured the teaming. I'd look at SQL first, particularly SIMS and see what the most expensive/grinding queries were.

[dhicks]

I doubt it's a network speed issue unless you've misconfigured the teaming.

 

For a single TCP/IP connection between two servers with teamed network interfaces, can you actually utilise more than one interface's worth of bandwidth anyway? If I remember correctly, you can but both sets of teamed interfaces and the switch have to support some extra technology / features of some sort, otherwise teamed interfaces really only make a difference for multiple connections between multiple servers. You could, of course, add 10GbE cards to both servers, but that might start getting expensive. If both servers are VMs you could move them both to the same server, then networking speed limit should simply be a case of however fast the internal virtual switch can go.

[Davit2005]

I'm suspecting a SQL query to be the issue. Whilst you could set up a 10Gb link fairly cheaply with a few second hand 10Gb cards and a DAC cable the bottleneck will probably turn up elsewhere.

[PD1279]

As it's speed you are looking for - like others have said I would look at the SIMS DB first. Also you may be able to look at indexing on the SQL DB as we used to have one accounting app a while back that used to take 45 mins to run some major queries. Once I was allowed at it (on test environment first of course) I found the indexes were getting out of whack every day. I ran a re-index job at around 5 in the morning on the important tables and suddenly these queries were running in 4 mins flat - I was popular I can tell you. SIMS of course could have some default index jobs but who knows really except Capita.

 

Second option - move to Enterprise SSD disks just for the SQL DB and make sure NOT Raid 5

[ataylor]

Why not Raid 5 for an SSD?

[3s-gtech]

Traditionally it has been unrecommended for SQL servers due to slower writes. More modern storage may have altered this somewhat, but then RAID levels have moved on too. RAID 5 has had its day.

[mavhc]

That is the best way to connect them, if you have a spare port might as well. But yeah, check disk queues, how much data is moved between them for a query, can you fit the in use parts of the database in ram, are there indexes, etc.

[EddyAllen]

Why not Raid 5 for an SSD?

 

While it may seem appealing from a storage space point of view, RAID 5 (Parity) absolutely hammers performance both in sequential, random, latency and IO scenarios. You would be much better off just spending a little extra and getting 4 drives and going with RAID10.

 

As for query performance, try getting a view from the SIMS GUI and then try return it using a query in SSMS. Alternatively go in to the event profiler on SSMS to find the queries being generated by the GUI. Easy way to determine application overhead, our DMS software was executing the queries in milliseconds but the GUI was sometimes taking up to 10 seconds to change views even when using the GUI on the server itself! If there is one thing I've learned working in Education and non-education environments is that when Software or Hardware advertises itself as "for Education" this is synonymous with "Terrible performance"!

Edited January 31, 2019 by EddyAllen

[mavhc]

While it may seem appealing from a storage space point of view, RAID 5 (Parity) absolutely hammers performance both in sequential, random, latency and IO scenarios. You would be much better off just spending a little extra and getting 4 drives and going with RAID10.

 

As for query performance, try getting a view from the SIMS GUI and then try return it using a query in SSMS. Alternatively go in to the event profiler on SSMS to find the queries being generated by the GUI. Easy way to determine application overhead, our DMS software was executing the queries in milliseconds but the GUI was sometimes taking up to 10 seconds to change views even when using the GUI on the server itself! If there is one thing I've learned working in Education and non-education environments is that when Software or Hardware advertises itself as "for Education" this is synonymous with "Terrible performance"!

 

Do you need raid 0 though? drives should be as fast as the interface now, or 1 drive that's twice as large and twice as fast be cheaper than 2 smaller/slower

[EddyAllen]

Do you need raid 0 though? drives should be as fast as the interface now, or 1 drive that's twice as large and twice as fast be cheaper than 2 smaller/slower

 

Well it depends on the interface you are using, personally I wouldn't buy SATA SSD's unless I didn't have any free PCI-Express lanes / slots open. I would much rather use m.2 drives in a PCI-E caddy due to a similar price point for much higher performance.

 

While most drives will max out a SATA6 link in most cases or SAS(12) you will still get aggregate performance benefits from having them in a RAID setup as the backplane has a much higher throughput than each individual SATA link. Admittedly unless you are running a huge amount of VM's or have a large school 2k+ you probably aren't going to need much more than 1GB/s read speeds which can be reached by just having one pair of drives in RAID0.

 

I would say that if you are in a production environment without a very nice backup solution DPM / Veem etc and that you are confident you can restore service in under 30 minutes (Or whatever your risk appetite is) you should be running with RAID10 instead of RAID 0 to cope with drive failures. Although failure rates are significantly lower with SSD's than your traditional spindle drives.