By Sergio Seabra
In the ever-shifting world of finance, it has become increasingly important to prepare and cater for all contingencies. This is done to not only protect the institution, but customers as well.
It can be argued that the ability to maintain data availability is central to the endeavor. As such, in my little corner of the world, the powers that be stipulated that: in the event of any sort of major setback in a financial institution, the organization would have to provide the means (as well as proof), that a disaster recovery (DR) plan was not only in effect, but also, that a successful trial-run had already taken place.
These environments tend to be quite complex and while some may had already taken measures to, at the very least, have some form of DR, many were taken by surprise and unable to comply by the time the by-laws were published.
But in all fairness, even those that already had a DR plan in place still have had to deal with a predominantly manual process spanning dozens of operatives, and hundreds, if not thousands of manual steps.
In this turmoil, a shining beacon of hope presented itself, and vCenter Site Recovery Manager (SRM) is its name. I know; a little overdramatic perhaps, but in this particular context the importance of this single piece of software should not be understated.
By now most of you are aware of the product’s capabilities, but to be quite blunt, at the time of its release, it revealed itself as quite the lifesaver; it was a perfect fit for this new but most pressing requirement.
VMware already accounted for more than 90 percent of the virtual Datacenter footprint, and the mere possibility of automating most (if not all) of the tedious DR-required tasks, had all these institutions (quite literally) scrambling to deploy the solution.
After all, it seemingly brought order to chaos and more importantly, allowed for testing and reporting against the success of each iteration. Prototyping an entire multi-tier recovery became almost as run-of-the-mill as any other vCenter operation.
One would think that by nature, such capabilities would entail a very complex process, but the truth of the matter is this: at its most basic, the building blocks of SRM are quite straightforward, simply requiring some form of storage replication between sites, and the configuration of logical containers and associated boot procedures within SRM’s user interface.
The software even catered to an array’s process automation, managing all the needed built-in replication procedures (i.e., snapshot creation and removal, LUN presentation to the hosts, replication reversal, etc.).
And that was it! The market demanded it, and VMware was front and centre with a very feasible and elegant solution to what was until then, quite a complex and time-consuming procedure.
Of course, nowadays, the software’s capabilities have been greatly extended, and we can, for instance, interface with Orchestrator. In doing so, the possibilities are practically boundless, but still and at its very core, SRM maintains the same simplicity of configuration that provided such an effective time-to-market as when originally released.
To illustrate this point, I’ll leave you with the following infographic. In it, I depict the “meager 5” main levels of SRM requirements needed to establish a full and effective DR plan for any virtual workload.
Sergio Seabra is a Technical Account Manager based in Portugal. He has a background in Electronics and Telecommunications, and has been employed in the IT field in one form or another for the past 20 years working on some of Europe’s largest telco projects. Currently, he is a VMware TAM engaged mainly with enterprise accounts.
