Completion Report

Project Summary:

Data historically kept in the Database tiers is now commonly held in unstructured file stores and network mounted to several servers. The data requires to be consistent with relational databases transactional entries, currently the site replication is achieved at the filesystem level via period synchronization whereas the databases are replicated by the dataguard stack per transaction. This has the capacity that upon failover between datacentres that the transactional database and the unstructured data stores are out of sync, requiring rationalization to resolve.

The following have been delivered:

• Enablement of the replication Engine to block replicate storage between Compellents & datacenters
• Purchase of SRM Licenses
• Purchase and Installation of additional SAN storage to support the replicated storage footprint
• Configuration of SRM cross vCenters
• Configuration of SRM SA agent VMs

What has not been delivered:

• A prescribed failover mechanism to include:
  • Investigate integration with Compellent LV
  • Investigate whether a devolved red-button failover for specific recipies. e.g. Apps for Learn. EDINA for Digimap can be provided through an API mechanism or other
• Identification of services/VMs that require this level of availability

Analysis of Resource Usage:

Staff Usage Estimate: 50 days

Staff Usage Actual: 41.5 days

Staff Usage Variance: 17%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

We closed the project early without completing the deliverables because the project was being superseded by the build of a metro-stretch cluster. Nevertheless lessons were learnt about out to deploy SRM and the licences are available for use on our clusters and may be used for some services that do not end up in the metro-stretch cluster.

Key Learning Points:

We have SRM and Compellent SRA’s installed in our VMware test infrastructure and an architecture document from the VMware consultation. We have reconfigured the storage to be split between the two sites and not stretched and retested the failover and failback.

The issue we discovered is that in order to make SRM work we would need to rearchitect our entire cluster to not present the storage at both sites. We are now = building a metro-stretch cluster for high availability, this calls into question our strategy of using SRM.

Outstanding issues:

Since we are  building a metro-stretch cluster for high availability, this calls into question our strategy of using SRM. We have therefore decided to close this project with lessons learnt about the deployment of SRM that will be valuable for some services in the future. The main deliverable of the project to deliver resilient infrastructure to critical services will now be delivered by the metro-stretch cluster. The delivery of a robust, shared file service can be delivered in that infrastructure outside of this project.