Access Control

Call it what you will, but permissions, access control, and change management are part and parcel of most corporate environments. So far we have been managing SRM using a default “administrator” account for every task. This is not only unrealistic, but also very dangerous—especially in the realm of DR. DR is such a dangerous undertaking that it should not be triggered lightly or accidentally. Correctly setting permissions should allow SRM to be configured and tested separately from the process of invoking DR for real. Although this is a high-level “C-Class” executive decision, management of the process should be in the hands of highly competent, trained, and ideally well-paid IT staff. Alarms can be very useful if you have an environment that is changing rapidly or if you don’t have tight change control management in place. At least with alarms the SRM administrator can be alerted to changes in the environment caused by others. In an ideal world, the left hand knows what the right hand is doing. But we don’t always live in an ideal world, so if alarms are configured, your attention is at least drawn to changes in the environment that could impact SRM and a successful recovery process.

SRM introduces a whole raft of roles to vCenter, and as with day-to-day vCenter rights and privileges, the SRM product displays the same “hierarchical” nature as vCenter. An additional layer of complexity is added by having two vCenter systems (Protected and Recovery Site vCenters) that are delegated separately. It’s worth saying that in a bidirectional configuration these permissions would have to be mutually reciprocal to allow for the right people to carry out their designated tasks properly.