cancel
Showing results for 
Search instead for 
Did you mean: 

Enterprise vault DR site

Rizwan_Ahmed_1
Level 4
Partner

We are planning the EV 9 for the DR site.

Cureently we have EV 9 running on 2008 R2 as standalone server for Exchange 2010 archiving and sql 2008 R2 in clustering mode.

 

Exchange and SQL are already clustered to the DR site.

 

For EV we are looking do it using MCS cluster for DR site as SQL is already cluster conating Ev databses.

we will use the SAN based replication to replicate the vault stores.

How we are gonna install EV in DR site as shared storage will be replicated.

 

Secondly,

 

How can we accomplish building blocks configuration for EV server one at each site. The information in E-books suggesting that it requires three server but I am not sure if the storage is replicationg to DR site how we gonna install and configure a EV 9 for hot DR.

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

JesusWept3
Level 6
Partner Accredited Certified

So as far as the storage goes, you will be ok if the paths are the same
So for instance if you have it as a mapped drive, for instance

E:\Enterprise Vault Stores\EVStore Ptn1\

Make sure that you have the other server pointing to the same drives and paths

If you use a UNC path such as \\192.168.10.1\Enterprise Vault Stores\EVStore Ptn1\
You are best off making it a DNS Alias so that you have something like

\\StorageDevice\Enterprise Vault Stores\EV Store Ptn1\

Then you just have the DNS Alias point "StorageDevice" to the active IP address, and then when it swaps over to the other storage, you just change StorageDevice to point to the other storage IP Address


In a USL/Building Blocks environment, the way this works is that you have your Aliases pointing at physical machines, so you would have something like

EVSiteName (Alias) -> EVServer1 (Alias)
EVServer1  (Alias) -> machineA.myDomain.com
EVServer2  (Alias) -> machineB.myDomain.com
EVServer3  (Alias) -> machineC.myDomain.com

If something happens to those machines and you want to fail over you would simply change the DNS settings so you would update it to

EVSeever1 (Alias) -> DRServerA.myDomain.com
EVServer2 (Alias) -> DRServerB.myDomain.com
EVServer3 (Alias) -> DRServerC.myDomain.com

Then if you have storage Aliased as well you would change it
From: StorageDevice (Alias) -> 192.168.10.1
To: StorageDevice (Alias) -> 192.168.100.2


This really though is a more manual failover way using Building Blocks, it is not an HA solution as it could very well be down for hours until someone see's the servers are down, makes the DNS changes, waits for the DNS to update etc

If you are using MSCS to do all the clustering then you wouldn't really need to do USL at all, you'd just make sure all the Servers are clustered correctly, and then everything would be targeted at the Virtual names and not the physical machine names.

And then when the fail over occurs, everything such as Storage will go with it and it becomes instantly available and you need not do anything with the DNS. It's definitely the more robust approach to take. However setting it up and testing it a lot more difficult than USL

https://www.linkedin.com/in/alex-allen-turl-07370146

View solution in original post

3 REPLIES 3

JesusWept3
Level 6
Partner Accredited Certified

So as far as the storage goes, you will be ok if the paths are the same
So for instance if you have it as a mapped drive, for instance

E:\Enterprise Vault Stores\EVStore Ptn1\

Make sure that you have the other server pointing to the same drives and paths

If you use a UNC path such as \\192.168.10.1\Enterprise Vault Stores\EVStore Ptn1\
You are best off making it a DNS Alias so that you have something like

\\StorageDevice\Enterprise Vault Stores\EV Store Ptn1\

Then you just have the DNS Alias point "StorageDevice" to the active IP address, and then when it swaps over to the other storage, you just change StorageDevice to point to the other storage IP Address


In a USL/Building Blocks environment, the way this works is that you have your Aliases pointing at physical machines, so you would have something like

EVSiteName (Alias) -> EVServer1 (Alias)
EVServer1  (Alias) -> machineA.myDomain.com
EVServer2  (Alias) -> machineB.myDomain.com
EVServer3  (Alias) -> machineC.myDomain.com

If something happens to those machines and you want to fail over you would simply change the DNS settings so you would update it to

EVSeever1 (Alias) -> DRServerA.myDomain.com
EVServer2 (Alias) -> DRServerB.myDomain.com
EVServer3 (Alias) -> DRServerC.myDomain.com

Then if you have storage Aliased as well you would change it
From: StorageDevice (Alias) -> 192.168.10.1
To: StorageDevice (Alias) -> 192.168.100.2


This really though is a more manual failover way using Building Blocks, it is not an HA solution as it could very well be down for hours until someone see's the servers are down, makes the DNS changes, waits for the DNS to update etc

If you are using MSCS to do all the clustering then you wouldn't really need to do USL at all, you'd just make sure all the Servers are clustered correctly, and then everything would be targeted at the Virtual names and not the physical machine names.

And then when the fail over occurs, everything such as Storage will go with it and it becomes instantly available and you need not do anything with the DNS. It's definitely the more robust approach to take. However setting it up and testing it a lot more difficult than USL

https://www.linkedin.com/in/alex-allen-turl-07370146

Rizwan_Ahmed_1
Level 4
Partner

Thanks for the reply jesus.

 

Is there any related document which specify configuring EV in a DR using MCS.

 

The info given by use is quite useful

JesusWept3
Level 6
Partner Accredited Certified

ftp://ftp.support.veritas.com/pub/support/products/Exchange_Mailbox_Archiving_Unit/317266.pdf

Page 223 - Chapter 30


That's a fairly comprehensive list of how to get the ball rolling, would suggest discussing this with your clustering team as they should find this stuff a breeze and once they're familiarized with the pre-reqs they should be able to get it set up pretty quickly

https://www.linkedin.com/in/alex-allen-turl-07370146