Analysis Server 2005 Clustering

Hi

I want know for Analysis server 2005 on Clustering environment which type of Cluster (Server Custer/ NLB) is recommended by Microsoft & what is reason behind the recommendation.

Appreciated if you could provide me the URL for Analysis Server 2005 Clustering Best practice.

Thanks

Sunil

I am not aware of any specific whitepapers on clustering with AS 2005 specifically, but in nutshell the 2 different technologies have different focuses, so it depends on what you what to achieve. With most typical AS2005 installations NLB is usually recommended unless you are doing writebacks.

Failover Clustering

This gives you hardware redundancy in case of hardware failure. Note that this is a shared disk technology so you really need to have multiple disk controllers and RAID arrays setup so that you do not have a single point of failure. In the case of a hardware failure or OS crash, another node in the cluster will "pick up" the disks/IP addresses/server names that belonged to the crashed node and bring the instance of SSAS back online. So there will be a small period of downtime as the SSAS instance is started up on the new node. This type of clustering is more intended for applications like the relational database engine or exchange where the server is constantly reading and writing and you only want one copy of the data.

NLB Clustering

This sort of clustering is more for scale out scenarios as you basically have identical copies of your database on multiple servers that are all available to service queries. This means that you can "balance" the load across multiple servers, but only works with read-only databases, as if you are doing writebacks, there is no means of keeping the multiple copies in synch. This option can give you better up time than failover clustering as if an individual node fails, only the users connected to it when if failed are affected, all other users are unaffected and the when the users that were connected re-query they should connect to one of the other available nodes.|||

Hi Darren

Thanks for reply.

I want know, if i create a new cubes or any change in the existing cubes whether we need to Sync all

AS2005 Database (Respository) which is available of different node in NLB Cluster Environment?

Thanks

Sunil

|||

Yes, if you create a new cube you would need to synch all the nodes. But you would probably re-synch all the nodes on a regular basis as you process new data as this would be safer and more efficient than getting each node to re-process the same data

There is a synchronize command which you can use in AS2005 to synchronize databases between 2 servers which is pretty much aimed at doing just this. It is basically an automated backup and restore in a single command which can be scripted or scheduled.

You could also use the deployment wizard to deploy changes to mulitple servers. But I think that with an NLB scenario probably the better and more common scenario is to get one of the servers to do the processing and then synchronize with the other servers. It may even be that you have a staging server that does all the processing and is not part of the cluster.

|||

Hi Darren

The Architecture is excellent but i still i have a thing to clear about the staging server in my setup.

Could it be possible if I take 2 Server where we implement the NLB Cluster for the END user & Two Server which is cluster of staging servers in which we implement the Failover Cluster & this staging Servers are connected to the shared storage SAN Device for the Quorum & Analysis Server repository?

Appreciate if you could reply as earliest

Thanks Sunil

|||

Yes, this is probably the most robust SSAS configuration that I can think of.

I'm pretty sure that you could also have 3 (or more) servers in the NLB cluster and script to temporarily pull one node out of the cluster to do the processing, but if this node had a hardware failure during this time it would take manual intervention to recover.

You should keep in mind that logic errors and dirty data probably cause more issues with processing OLAP cubes than hardware issues, so you need to make sure your cubes and ETL processes are well designed. The advantage of having a staging server is that a processing failure usually only means that the front-end servers have slightly old data, but the users can continue working while you fix the problem.

|||

HI

I prepared a Architecture with 4 Node i.e. 2 Node Cluster for the Analysis Server using NLB Cluster & Other Two node Cluster for Staging server useing Failover Cluster & it will Syncs with NLB Cluster Node in the regular interval using Tidal Scheduler.

Appreciate, if you see the Architecture Diagram and give me your valuable suggestion.

I uploaded on

http://sunilgidwani.blogspot.com/

Blue Dash Line is for Internal Network

Black Solid Line is for External Network

Red Dot is not HeartBeat Network

Thanks

Sunil

|||

HI Darren

Appreciate, if you could reply the above mail as earliest.

Thanks

Sunil

|||It should be possible to maintian extremely high uptimes with this sort of architecture. You might need to talk to a networking expert to make sure that your network infrastructure has full redundancy so there is no other single point of failure, but from a SQL perspective it looks very solid.|||

Hi Darryn

I appreciate your help & repose, now I am planning to implement your suggested architecture for Analysis Server using NLB Cluster.

Thanks one again

Sunil