Block mode configuration

[Des]

Hello,

I am installing EV 2007 SP1 in a new environment, I have 5 EV servers (4 mailbox Servers and 1 Archive Server) in production, I have the same amount of servers at my failover site (DR Site) acting as standby servers. The production site and failover site is in the same domain even though they are physically separated.

The production site using Centera as storage that is replicated to a Centera at the failover site, I have configured one Vault Store for each server, all indexes, Centera collection area and shopping are installed and configured on a SAN drive for each server, the idea is to move the san disks for to the failover site in a DR scenario. The same idea applies to the SQL database.

I have read the Enterprise Vault PDF documentation about block mode configuration that is supplied with the software but cannot figure out how to configure the servers for failover.

When I add the 5 standby servers in VAC by running the configuration wizard, do I have to create a new site in EV (can servers move/failover between sites ) or do I place the 5 standby servers in the same Enterprise Vault site ?

I guess that I do not configure any vault stores for the 5 standby servers as they will use vault stores configured for production when a failover is initiated ?

Do I have to update the Centera ip addresses when I failover ?

Any help will be much appreciated,

 
Many Thanks,
//Des

[MarkBarefoot]

Building blocks primarily use DNS aliases to assist with failover, and a tool (within the VAC) called "Update Service Location".

Each server:
Has all Enterprise Vault services installed (run USL)
Is a self-contained unit of functionality for a set of users
Must use a remote SQL Server
Must use network storage for all Enterprise Vault data
Must have a DNS Server alias
Must be in the same Vault Site
 -Site must have a non-machine-specific Web Access Application URL


As an example:-

There are two active Enterprise Vault servers, Server 1 and Server 2. Each has a DNS Server Alias, and the Vault Site Alias points to Server 1 – note it actually points at Server 1’s alias, rather than directly at the server name. Each server is using remote network storage, and a remote SQL server (which could be a single server, SQL cluster, etc).

Now, Server 1 fails. Server 2 is completely unaffected by this and continues working. However, the users accessing Server 1 have lost their Enterprise Vault service. To rectify this, only two steps are required. Change Server 1’s alias to point at any other working server, Server 2. Then, run the Update Service Locations tool on Server 2. This tool is available in the Enterprise Vault Administration Console. USL looks at the current settings of the DNS aliases, and reconfigures Server 2 to take on the workload of server 1 (in addition to its own workload), including accessing Server 1’s data storage on the network.

Because all access requests to Server 1 use the DNS alias, those requests are now automatically redirected to Server 2, which can access the archived data on the network storage devices. Also, Server 2 will continue performing background archiving and other tasks previously being done by Server 1. When Server 1 is available again, its DNS alias can be set back to the original computer, and USL run again to switch back to the original configuration.

The only downside with this active-active failover is that, while Server 1 is unavailable, Server 2 has twice its usual workload. This might be acceptable, or if not an alternative is to use active-passive failover. In this case, there would be another Enterprise Vault server, Server 3 that has Enterprise Vault installed but not normally doing anything. Now, when Server 1 fails, its DNS alias can be switched to Server 3 and USL run on Server 3 to make Server 3 effectively become Server 1. This ensures there are always two (or as many as necessary) operational Enterprise Vault servers. When Server 1 is available, the original configuration can be restored, or Server 1 could become the new passive machine.


Hope this helps understanding the concept. If you need more assistance I would advise speaking with Professional Services as you have a fairly complex environment!


Mark

[Des]

Thanks Mark for the overview of the concept, its much appreciated.

Just to clarify, in an active/ passive configuration that you describe with Server 3, when you add server 3 to the site by running the Enterprise Vault configuration wizard you use “Existing Vault Directory ” and then” join the existing vault site” if I understand you correctly ?

If Server 1 fails, its DNS alias can be switched to Server 3, does that mean that Server 3 doesn’t need a DNS alias when added to the site but instead use its FQDN ?

Also does Server 3 require to be configured with its own services like indexes, storage and shopping in this scenario or will Server 3 simply take over the services of Server 1 after USL ?

I have engaged Symantec Professional Services but they have not been able to give a start date as of yet, I just like to understand the process a bit better before we do start.

Many Thanks,

//Des

[MarkBarefoot]

Des,

You would normally have an (A) record for the server itself, a CNAME for the server alias and also a CNAME for the site alias. The Site Alias would point to the Server Alias - this is the link that you would change in the event of a failover (the Site Alias would remain the same and this is pushed out to clients etc. This alias would point to the Server Alias and that link would have to be modified).

If the server that you run Update Service Locations does not have the relevant services it will created them for you.

Ideally, if you have a test environment, I would advise setting up 2 EV servers, 1 in use and 1 for failover and then test it.

Extract from an internal document:-

Building Blocks is the name given to one method of configuring a multi-server, fault tolerant Enterprise Vault environment. It is very straightforward to use, as long as all the servers are set up correctly.

In a Building Blocks system, all the Enterprise Vault servers operate as self-contained units. They have all the Enterprise Vault services running locally, including a Directory Service and Web Access Application on every server. (By default, only the first Enterprise Vault server installed has a Directory Service; to add Directory Services to other servers, use the Update Service Locations (USL) option in the Enterprise Vault Administration Console).

Each server is responsible for archiving and storing data for a particular set of users (ie a set of Exchange servers), and for servicing all search and retrieval requests for those users. So one Enterprise Vault server is never reliant on any other Enterprise Vault server. If one Enterprise Vault server fails, all the others can carry on working unaffected. There is no single point of failure. Additionally, it is very easy to failover to another Enterprise Vault server, which takes over the duties of the failed server, ensuring continuity of service.

For this to work, the Enterprise Vault servers must all be in the same Vault Site, and must all use a remote SQL Server. Standard SQL high-availability solutions would be used to ensure its reliability. Also, all Enterprise Vault storage must be network accessible (via UNC paths, etc) so that it is visible (and with the same name/address) to every Enterprise Vault server. DNS servers must be being used for all Enterprise Vault servers, and the Web Access Application in the Site Properties should be modified to remove the http: and machine name prefixes, leaving just the virtual folder name (all Enterprise Vault servers must use the same virtual folder name). This forces Enterprise Vault to dynamically generate the URL as needed, with the appropriate server name for each user.

Thx,

Mark