EV12 and Building Blocks
Hi
Has Building Blocks changed at all with EV12? I need to create a DR solution for EV across two sites and had the following thoughts - but just wanted them sanity checked as I've not done it this way previously.
This is quite a small requirement for Exchange mailbox archiving only and less than 500 users. Exchange is configured in a two node DAG with one node on each site - both DAG nodes host active exchange databases and passive copies of the other DAG node.
EV servers need to be physical with internal storage only and will be running EV12.x and configured to archive from the local DAG node (in BAU)
Failover doesn't need to be automated and can take up to 2Hrs to achieve so bulding blocks seem the best way to go.
Please assume that the SQL databases will be replicated as necessary using SQL functionality and I'll use an SQL alias to assist with failover of the SQL databases between SQL servers
Replication of data I perhaps think can be done via something like Robocopy\Richcopy\Doubletake or something similar.
So - can I do the following:
Create a E:\ on EVServer01 for the Archives and replicate this to E:\ on EVServer02
Create a F:\ on EVServer02 for the Archivesand replicate this to F:\ on EVServer01
Create a J:\ on EVServer01 for the Indexes and replicate this to J:\ on EVServer02
Create a K:\ on EVServer02 for the Indexes and replicate this to K:\ on EVServer01
When doing a BB failover and updating the DNS aliases and Service locations will the fact that the surviving EV server has the EV index and archive data (of the failed EV server) visible on the same volume letter and path as it was on the failed server be sufficient for everything to work as expected?
thanks in advance.
The information about the Storage Queue (SQ) and safety copies is not quite correct.
It is true that if you do not store safety copies on the SQ, you should not have a whole lot of items just hanging out in the SQ long-term. However, if you happen to lose the primary server during an archiving window, when items are being actively added to and processed from the queue, you could end up in a situation where EV has written the items to the SQ and the database, but StorageArchive has not processed the item out of the queue yet. When you fail over to the DR server, the database will still contain records for these savesets and .EVSQ files, so the StorageQueueBroker will try to assign them for ingestion, but they will not exist on the disk and that will fail.
Depending on the type of target and certain policy settings (Pending Shortcut Timeout, for example), this might not be a huge problem as the original items will be reverted after sitting in pending for so long, and they will be rearchived later. Still, you'll have to wait whatever the timeout period is before this happens, and in the meantime you'll see a bunch of errors related to the missing files from the SQ. Better practice is just to replicate the SQ location like you are the partition and index locations.
--Chris
