Building Block : Storage Configuration

[hkadoun]

Hi all,

I have a question about  failing over in a Building block environment especially regarding the storage.

Let's say you use LUNs (and not a share on a NAS) for Index location and vault store:

Do you give access to both the EV servers ( the active and passive one)? Is it supported//recommended by all SAN manufacturer?

Or do you include in the failover procedure, the zoning of the LUNs on the second server?

Thanks,

[Nick_White]

Building blocks requires storage to be accessible via exactly the same path/access point for each server, so provided the storage device is presented in a way such that both servers can access it without having to change the access point details then things will continue to work. If you have to change the access settings then this will become a manual step after running USL

[Chai]

You can provide both machine access to the luns, assuming you know which machine has control at all times..

But, I prefer it be included as part of the failover procedure as a safety to make sure the secondary doesn't try to mount the luns

[AndresMunoz]

For building block to work correctly and failover (USL) without other steps, it's necessary that all storage is accessible on the same paths by all servers... this includes index locations.

If you don't do this... then you don't have a building block on its purest, simplest and effective form...I will go as far as saying that you don't have a building block at all!!!... I think building blocks is a very simple yet effective solution for resilliance and DR.

Don't forget also, another reason why you implement building block is scalability.... with NAS storage is very simple to add another server, and then another....

IF you don't have a NAS, I would suggest you deploy an additional server with SAN storage, working as a file server which presents the storage as a network share for EV servers to use. (see attachment). You can then replicate this for your DR site if required, either using SAN replication technology or another third party tool... stay away from robocopy... not quick enough.

[hkadoun]

I understand your point Andres Munoz: when using Building Block, NAS storage is more than recommended.

My question then is how do you manage performance needs on a NAS storage.

Your solution of using a file server sharing its LUN seems to me performance killing especially for index storage location.

[AndresMunoz]

Not really, although according to performance guide it is mentioned as 'Not Optimal'... In my experience I've found that the biggest bottle neck on a EV environment is Exchange more than anything else, followed by SQL. Then comes EV tweaks (conversion mostly). As an example... from a Windows 2008 R2 file server you can get a 80-100Gb/hour... you will never get that out of exchange.... remeber indexes and archive storage are the end part of the whole process. We are seein about 70% storage reduction on two client sites... Ideally you would use a decent NAS device... but a windows file server will do the job just fine!

[AndresMunoz]

To give you an idea on performance... according to the EV8 Performance guide, with a 4 CPU configuration and a 70Kb message size you should get about 40000 messages an hour. The guide also specifes that when doubling the mesasge size the throughtput is reduced by one third... so that would be about 28000 msgs an hour for a 140K message. 

Two of my clients, the ones mentioned above, where the index are located on a network share hosted by a Windows 2008 R2, they get about 48000-50000 messages per hour with mesage sizes of 150k and 140k respectively, way above the indications of the performance guide. Granted, if it was local disk indexing would be probably quicker, but these figures give you evidence that the performance impact of storing the indexes on a network share, even if hosted by a Windows server, is nelegible when compared to the choice of CPU and proper EV tunning.

[hkadoun]

Thanks Andres for the feedback