Issue link: https://epubs.iltanet.org/i/4636
ILTA White Paper Infrastructure Technologies 10 • We used a multitude of technologies to backup and replicate data to the DR site, creating a complex environment • Numerous checks were required to ensure each technology was working • There was no easy way to test the DR plan without a planned outage • Recovery time objective (RTO) was long due to manual processes While inconvenient, these were not what drove us to revisit the DR strategy. Rather, it was the firm outgrowing the starter SAN. The original plan was to use the SAN for Exchange and Autonomy iManage WorkSite only. However, the virtualization initiative was very successful, and the initial nine production VMs ballooned to a peak of 55 before we removed clustered servers and consolidated other servers to bring it down to the current count of 43. Over time, disk space and SAN I/O became the bottleneck, which resulted in poor performance, especially during the ever-increasing backup window. The quick solution was to move various VMs to other DAS. However, in doing so, we were no longer able to leverage the flexibility that VMotion offers because common storage is a requirement of this tool. Likewise, at the DR site, the need to support the additional VMs meant that additional storage, disk I/O, CPU cycles and RAM were required. In practical terms, this meant additional servers that required shared storage over the existing single server with DAS storage configuration. THE PLAN With the tight integration of data storage, backup and replication now available with virtualization technologies, it is critical to consider storage and DR of VMs in concert so as to ensure the proper foundation that will allow for the easy addition of DR tools as resources permit. At conception, the plan was to develop a DR strategy, which could be implemented in several phases. Phase 1 would involve trading in the primary SAN for a model with long-term growth potential to correct the performance issue and to keep the existing DR infrastructure as is. Subsequent phases in future budget cycles would involve the purchase of the DR SAN and the software to provide replication, DR cutover and testing to complete the DR infrastructure. The firm chose to stay with NetApp for storage due to its tight integration with the VMware, in which the firm is heavily invested. While developing the plan, the firm undertook a detailed review of available best practices and white papers from both VMware and NetApp. This information, in conjunction with the baseline for storage, CPU, network and WAN utilization, as well as firm best practices for data retention and destruction, was invaluable in completing the design. During the design phase, it became very clear that the configuration of the underlying SAN storage would be considerably different if DR and the software used for DR was not considered and if the SAN was to be used solely for centralized storage. If the firm had not contemplated the DR component when upgrading the storage, a considerable amount of effort would have been required to restructure the storage when the DR tools were implemented.