Enterprise Vault SAN Storage to Hitachi HCP
(This is deliberately very high level, every configuration is different, but summarises the process.)
Digest
We recently completed a move from SAN to Hitachi HCP HTTP/REST storage using the streamer interface. Only the Partition data was in scope and also included was moving the existing (closed) SAN partitions to Hitachi HCP hosted CIFS namespaces. Index data remained on local SAN storage.
EV Archives were not moved to the HTTP/REST partition as the native tools are slow and would have caused user disruption (all vault cache users, no shortcuts) and no 3rd party products (ArchiveShuttle etc) were budgeted for.
The initial configuration is as below:
- EVSRV01 has 5x2TB SAN drives, each hosting a single EV Partition, each partition has approximately 55 million items.
- EVSRV02 has 5x2TB SAN drives, each hosting a single EV Partition, each partition has approximately 55 million items.
- EVSRV03 has 3x2TB SAN drives, each hosting a single EV Partition, each partition has approximately 55 million items.
All in 1 Vault Store Group, with a sharing boundary of the Vault Store Group.
The aim was to move all data to Hitachi HCP without any user impact.
Setup of the HCP
Create Tenants and configure replication as appropriate for your design. In our case we had 2 nodes, one primary and a replica.
Create HTTP/REST Namespaces and logon account (1 for EV each server)
Login using account and create top-level directory for new Partition
Create CIFS Namespaces (1 for each server)
Login using account and create top-level directories for existing Partitions. In our case the 5 (or 3) folders for each EV server.
Install Streamer software on each of the 3 EV servers (see Hitachi Content Platform Adaptor for Symantec Enterprise Vault Guide)
Set Archive Processes to 25, Restore Process and Restore Threads to 5 (as the guide)
Note
The EV retention category is respected by the HCP device, in our case it was forever retention and the objects have the same on the HCP.
EV Server Changes
Create new Partitions on each EV server, selecting Storage Type as HCP
Set configuration options as appropriate. (Safety copies setting for backed up items)
Test.
Note the WORM mode setting here, this cannot be changed after setup. (Technically it can be changed but HDS were heavily involved.)
Set Compression/Deduplication settings as appropriate (we set Device performs compression)
No Roll-Over settings, these are the last Partitions we will create.
Roll-Over to new HCP Partition
Moving closed partitions to CIFS namespaces
(Closed partitions can still change, nothing new is added but data can be edited or deleted. As we don’t use Collections or Expiry we felt it was an acceptable risk to retain potentially unused file data.)
Replicate local partition data to appropriate top-level directory on CIFS namespaces.
Follow TECHNOTE35742 to update SQL to UNC path of CIFS namespace.
Test and verify.
Clean-up
Remove the local data and storage for the moved Partitions.
Summary
We moved the live and 26TB of closed EV storage to the Hitachi HCP device without any user impact. In total it should have taken approximately 2 months, with the WORM mode issues it took longer.