We have 4 fairly large servers. We have two matched sets of servers.
All servers will run 64bit EE Sql Server 2005 on windows 2003 Enterprise.

set "A": 8 core with 64gb of ram
set "B": 8 core(Slightly slower CPU's) box with 24gb of ram.

We would like to implement 2, 2 node standard Active / Active Clusters

The thought is that we can have two environments one for production the 2nd
for staging.

We are split between to approaches:

First Approach: SQL Server and Analysis Services on the same node:

set "A" Production

SQL Server Active on Node A Fails Node B
AS Active on Node B Fails to Node A

set "B" Staging

SQL Server Active on Node A Fails Node B
AS Active on Node B Fails to Node A


Second Approach: SQL Server and Analysis service on there own Clusters

set "A" SQL

SQL Prod Active on Node A Fails Node B
SQL Stage Active on Node B Fails to Node A

set "B" AS

AS Prod active on Node A fails to Node B
AS Stage active on Node B Fails to Node A

Will both of these configurations work?

Can anyone see any reason to go with one over the other?

Thanks for any advice

Hello Jason,

From my point of view, both of the configurations should work. However, for
production server I think it shall be all installed on more powerful
server. Therefore, I perfer the first approach to the second one. Also,
production server have more memory to use (espeically on 64bit server),
which is very important to heavy load production environment.

The following link might be helpful:

Microsoft SQL Server 2005 Analysis Services Performance Guide
http://download.microsoft.com/downlo...6-97d0-7f7151b
2011c/SSAS2005PerfGuide.doc

If you have any comments or feedback, please feel free to let's know.

Best Regards,

Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications
<http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscriptions/support/default.aspx>.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks Peter, I agree with you.

Does anyone see any benefit in the 2nd solution? or problems with the first
approach. This is causing quite a heated interanl debate.

Some would argure that best practice would be to install AS and SQL server
on different machines. does that make any sense in this case?

my understanding is that in a normal scenario, they are isolated from each
other. and only when we have a failure over, are the two instances sharing
the same resources.

It also would seem that if we wanted to leverage the processing benefit of
having both on the same machine, we could simply fail AS over to the sql
node, process the cube and then fail back.

Would that work?




""Peter YangMSFT]"" wrote:
[..]

What hasn't been mentioned is that the numbers for the memory being used
point to the fact that either configuration will meet our needs for the near
future. Also, the Intel servers with 32GB of ram can be upgraded to 64 GB of
ram when it is necessary. Further, in configuration 1 we run the risk of
having both AS and SQL (customer facing) on the same server. If this is no
longer regarded as bad practice, I'd like someone from MS to respond so.

There are also admin related reasons to keep the clusters as like/like.
Patching is easier as well as server configuration settings. AS and SQL are 2
different animals and what works well for one, may not work for the other. In
a mixed configuration we need to set the instances to the lowest common
denominator instead of what each application likes.



"Jason" wrote:
[..]

Hello Jason,

Since AS/SQL are installed on different node, they usually run on different
"machines" though they may run on the same node under situaiton that one
node fails. I agree with Chip this is a riks but it rarely occurs.

You are correct that in a normal scenario, they are isolated from each
other since they are on different nodes. It's possible fail over AS to SQL
node to process and fail back afterwards. However, I don't think it's
necessary since the other node has more processing capability.

As Chip mentioned, AS/SQL are different type of applications, and
configuration/optimation might be different. This shall be the benefit of
the 2nd solution.

Best Regards,

Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

================================================== ===


This posting is provided "AS IS" with no warranties, and confers no rights.