Well, it's been a busy week. Just been out on a series of customer visits in New York. Great time to be there - Lincoln Center skating, Holiday Fair in Grand Central, cold morning walks in Central Park - the place really has a great buzz at Christmas.
It was also a great opportunity to meet some of our customers there and talk about their NetApp deployments and plans for evolving data center management. These were all large New York Financial accounts and are some of the most demanding of customers. All of them are implementing more service driven ways to manage their IT environment - their administrative teams cannot scale to meet the data growth challenges and are getting asked for continued high (and higher) levels of service.
A great example of how Policy-based management can change the game for Data Centers came with our discussions with one of these accounts. They are implementing a building level DR solution - they want to have their entire data center mirrored to a different building to cope with disasters (sadly an all too common need and desire now in new post 9-11 New York). The challenge is how can they do this effectively and efficiently.
Traditional disaster recovery on a scale like this would be implemented at an using database inbuilt replication, host-based replication solutions like symantec's veritas volume replicator or storage level replication using EMC's SRDF or NetApp's SnapMirror. The storage level replication has great advantages as you don't have to affect host-side performance on data transfer and so is becoming a far more common approach. However in this customers case the number of objects they need to replicate is huge.
With NetApp Protection Manager in conjunction with SnapMirror a far easier implementation is possible.
The customer can define a single policy, their DR Policy, which governs the level of DR service which is expected - type of replication (single mirror or mirror then backup etc), how much lag time is allowed, max network utilization allowed, your recovery point objective defined in data movement frequency and alerts/warning thresholds. Then they can group entire storage systems at a time into a Dataset by just selecting them, we'll call it Building1 Dataset. (a dataset is a logical grouping of physical storage objects so that you can apply en mass data management techniques like mirror and backup - not requiring repetitive operations). At the destination side the customer also has a set of storage systems setup and grouped into a Building2 Resource Pool (again customers can just drag and drop entire systems in a resource pool). Now the act of setting up the building level replication is selecting the Building1 dataset, applying the DR Policy to it and giving it Building2 Resource Pool as the destination. Protection takes care of everything else, setting up any necessary destination volumes, qtrees, luns and of course the SnapMirror replication which is appropriate (qtree SnapMirror or volume SnapMirror). All this can be setup through a simple intuitive GUI or through CLI in a matter of minutes. Protection Manager lets administrators see what exactly is going to happen before applying and then afterwards it will continuously check for operational conformance and alert administrators to any possible error situations. It continuously enforces the Service Level defined in the policy. An even more powerful combination is possible if you use VMware or other server virtualization software. Then you can start managing the state of the server as data and replicate it in addition to your real data. Recovery becomes a matter of instantiating new VMs from the replicated OS images on the DR side and storage re-mapping the mirrored data (note. NetApp is working with VMware on Site Recovery Manager to make even this fully automated).
Policy-based management can implement the disaster recovery Service Levels required with greatly simplified management - who wouldn't want that.
Applying these same Policy-based management to Backup, Disaster Recovery, Compliance, Provisioning has the opportunity to change the way we manage data and data management operations.
Adios for now,
Paul.
