- This topic has 7 replies, 1 voice, and was last updated 9 years, 2 months ago by
.
-
Posts
-
-
-
I going on the assumption that when you mean ‘server farm’, you’re referring to a SQL Server cluster? If that is the case, I would recommend using a clustered environment to host your SQL Server environment (active/passive in the basic instance).
If you are talking about running Sharepoint server farm databases on the same environment as BizTalk, I would suggest you perform load balance testing to check that your SQL environment can cope with the load.
Not the answers you were looking for I know – can you elaborate on what you mean by ‘servers farm’?
Regards.
-
Let me just see if I understand what you are getting at first. I assume that you are talking about running the BizTalk Server on its own SQL Instance, but running on a cluster where other active SQL instances will also be running. You are essentially sharing hardware and you are concerned that other applications can negatively impact your BizTalk environment. Is this right?
So obviously a “pro” is this will ultimately cost your company/client less money to implement as you can spread the cost of the cluster (or farm) off against several projects/programs instead of just BizTalk.
A negative is that if your hardware is not sized right you will have competition of resources and degregation of performance. The way we have BizTalk configured where I am is we have a 2 node SQL 2000 cluster (32 bit). One node is “dedicated” to BizTalk and the other node is “dedicated” to a Payroll application. Since this is a cluster, “dedicated” isn’t really a reality, should a physical node go down, the SQL intance will flip to the node that is available. This is all great in theory…until you actually lose a node like we did. We then had a Payroll run which consumed a lot of SQL resources. BizTalk hosts lost connectivity as the SQL Server was pinned and BizTalk host instances were bouncing like a Yo Yo. This lead to a disruption of service for BizTalk. So suffice to say I am a fan of BizTalk running on its own physical node(within a cluster). I am a fan of clusters, provided they are sized right( I dont think ours was) and provided the planning was in place to accomodate other applications.
Something you could propose if there are a lot of applications targeted for this is to ensure your have several nodes and perhaps even a “free” node that could be used in the event of a physical node failure. So potentially you could have an Active-Active-Passive solution. BizTalk running on an Active node, other applications running on the other Active node and in the event of a failure you still have the Passive solution to pick up the load. Or if there were several apps just spread them accross all three nodes.
Something you may also want to persue is the RAID/SAN disk configuration. A poorly configured SAN can lead to disk contention between these applications. It doesn’t matter what memory/cpu you have available if your IO is poor. Here is a good post on disk configuration: http://gregbeech.com/blogs/tech/archive/2007/05/22/san-configuration-for-biztalk-2004-2006.aspx
As you are know BizTalk lives and dies with Disk IO. If you have any doubts about the new configuration, i suggest looking into the PAL tool (http://www.codeplex.com/PAL) This tool takes a lot of the guess work out of performance counters (including Disk IO). If you have a bottleneck, you will have some “evidence” that you can take to your infrastructure group.
-
Hi Zx7R
Can you elaborate on what you mean by a ‘server farm’ – I’m thinking that you mean either:
- Installing the BizTalk runtime on a Sharepoint server farm?
- Installing the BizTalk databases on a shared SQL Server cluster?
Cheers, Nick.
-
Hello Nick.
Actually I ment SQL Server cluster (or not a cluster but only server) running on some shared-resources servers, I will give you an example: Lets say I have pretty hard case server from IBM – which has a huge amount of processing power. All that server contains many virtual images of servers (let’s say it’s VMWARE). So It might be clustered and might be not, the point of a question is: why I would prefer to let run the biztalk DataBases on it’s own “smaller” hardware; maybe one of the reason is that when some system administrator wants (or accidentally did) to change server name – it makes problems to reconnect biztalk to it’s DB’s. (I have had such an issue at one of our customers.).
-
-
Zx7R,
Kent has made some valid points regarding clustering, which I would second – if your budget can stretch to it, go with a dedicated active/passive cluster for your SQL Server environment (if you need to run other high-IO db’s on the same environment, put them on another node and run as active/active/passive). The SQL Server Standard licence can run a two-node cluster (so either an active/active or an active/passive).
With regards to your specific example, if your IBM kit is running VMWare images I’m presuming it’ll be running ESX server, which means you won’t be able to run Windows Server alongside on the same physical hardware, only as another virtual image. Unfortunately, Micosoft don’t support running SQL Server or BizTalk on any virtualisation technology other than their own Virtual Server. So, unless you have a specific agreement with Microsoft over support, I would recommend that you either 1. run your BizTalk/SQL Server environment on dedicated hardware, or 2. take the chance with VMWare and if you do need to raise a support call with MS, be prepared to reproduce the problem on physical hardware.
With regards to underlying storage, if you already have a SAN (again I’m presuming you do if you’re running VMWare ESX), this hardware can be reused for the SQL Server data store, however ensure that your database data and log files are housed on separate LUNs to ensure there is no contention for your IO.
Hope this helps,
Nick.
-
Hi nickh ..
In answers which I receive here, there some points incorrect: I am not going to build or to architect any system/architecrure/etc. The point is that we have a customer, who has some “Server farm”, with many system problems (maybe their administrator is not that good but it doesn’t matter anyway), so we intend to explain to that customer why in their specific case to use BizTalk solutions in their current environment will be disasterous. It’s not that much money counts, but using a correct archtecture.
Using Server farm can save a lot of money, but not when those servers fail once in half of year or change their SQL-Server names (which is also a big problem in certain cases). Anyway, thanx again.
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.