A successful deployment of SRM is dependent on a thorough understanding of the business RTO/RPO requirements, data classification standing of applications, a technical preparatory analysis of the environment, storage and backup policy and administrative procedures; storage/replication design and whether there is a need to perform physical to virtual migrations.
Work with VMware to identify the full scope of the SRM deployment, the architectural design that maps to the enterprise, licensing and your company’s purchasing agreement with VMware. Also, consider SRM future growth as architecture changes after a threshhold is met.
1. SRM is an engineering solution and should be fostered/owned by both server and storage engineering.
2. Identify an SRM owner and ensure that they are trained before and during the deployment.
3. Choose an integrator to support the project manager and the SRM owner. They will help design SRM for use in testing and disaster recovery.
4. If you do not have a replication solution in place or if you cannot fall back from the DR site, you may only be able to failover from prod-to-dr using SRM.
5. A data Classification policy specified by the business will facilitate the deployment of SRM. This should: 1) classify the application and data by criticality based on direction from the business; 2) The storage design would be dictated to some level by the data classification requirements as identified by the business - and this would find its way into the replication solution and schedule.
6. Identify what applications and application data will be configured into SRM. Here you can use data classification policy and application qualifications, a business’ set of applications or a particular business process and those applications/data used to manifest.
7. If there is goal is to configure all applications with physical server dependencies into SRM a review of all of the applications resident on the physical servers is required to identify:
a. re-configuration needs of the application;
b. if the application can be migrated to virtual;
c. whether any applications require additional licenses and / or upgrades to be able to migrate frfrom p-to-v. P-to-V migrations are a sub-project to the SRM deployment and need to include all application-owners who are responsible for the application through the complete migration and validation process.
8. If you plan on performing P-to-v migrations to accommodate your new SRM deployment, understand any additional ESX servers that you may require and the number of licenses to cover your complete solution.
9. The storage design should be analyzed to ensure:
a. The related data for these applications are on the same frame and not spread over various frames.
b. The related data is not spread over various vendor products.
c. The replication solution and schedule works and is in synch with the storage design and data classification requirements; e.g. does it meet the RTO and RPO?
d. There is enough storage to handle data requirements as a result of data classification requirements and its configuration in SRM.
e. Backup policies / administrative processes exist and can be tweaked as SRM is configured and tweaked.
f. Storage administration policies and administrative processes exist and can be tweaked as SRM is configured and tweaked.
10. A very strong testing and validation program with proven scripts owned by each respective technology layer.
11. Before you schedule any configuration of SRM or P-to-v migrations to be able to configure applications into SRM understand the business schedule to avoid impact to the technical plan as a result of month/quarter/year-end activities on the applications. So, change management is a very important aspect of the project methodology.