An often neglected part of Consolidation is the network
configuration of a server. If you have mirroring set up this is particuarly
important because the network throughput can be in the same magnitude of the
transaction log throughput.
Generally if I am limited to four NIC's available I will team
two and make them available for general application access, allocate one to an
external backup device (iSCSI or a CIFS UNC path) and one for a dedicated
connection to the mirrored server. This kind of configuration is for a very
basic setup. If there are replication topolgies in place or a scaled out BI
Infastructure on a bigger server I would also look at dedicated NIC's for this
kind of trafiic. I always set my network cards to Full Duplex.
To get round the issue of legacy applications that dont
support the failover partner syntax with mirroring, I often use DNS aliases that
I talk about in my previous blog
post. When I'm utilising mirroring over a WAN and I want to reduce the network
sent over the very precious WAN link, I will disable encryption and utilise
riverbed hardware as mentioned here.
To force the routing of traffic via a dedicated DR connection I make an entry in
windows hosts file for the mirrored server.
While this is not meant to be an exhaustive list, but it does
illustrate a few best practices i've discovered. If anyone has any more tricks
they would like to share, please let me know.
Following on from my comments about CPU configuration I
have decided to restate my position to "it depends....".
Having performed some investigation in the Sql community,
Glenn Berry ( Twitter | Blog )
suggested that Hyper Threading should be enabled for the new
Xeon
55xx, 56xx, 65xx, and 75xx (Nehalem)
processors and pointed me in the direction of the
TPC-E benchmarks for evidence of their performance.
According to the benchmarks in this article http://www.qdpma.com/Benchmarks_TPCH.html
OLTP systems (TPC-E) benefit from a 30% performance gain from
hyperthreading while Data Warehousing (TPC-H) benefitted only 10% from
hyperthreading.
Still concearned about the potential issues with
Hyper-threading I descided to investigate further. I found this great
article by Joe
Chang suggesting that many of the problems with the original Hyperthreaded
Netburst processors have gone away with the advent of Nehalem. He just suggested
setting MAXDOP to 4 as a general rule.
Given that there is such a great performance gain to be
had for Hyperthreading with OLTP, I do intend to turn it on for servers
containing the new Nehalem chipset. For DW servers, I will still leave it
disabled as I have spent many an hour tracking down various issues with CXPACKET
and Intra Query Parallel Thread Deadlocks. I still dont trust the technology
enough to go there at this point.
@Blakmk