A key goal at NetApp is advancing the value of storage in the virtual data center from the traditional model of highly available storage to a more advanced virtual object oriented model. This approach is unified in nature as it provides the traditional functions of high availability, high performance, and the traditional storage provisioning of LUNs and file shares while also expanding into the realm of management of virtualized objects by the virtualization administrative team.
By virtualized objects I am specifically speaking of the objects that a VMware admin care about such as VMs, Datastores, workflow automation tools such SRM or View Manager, etc. For this blog I’d like to share with you an example of the direction NetApp is taking storage virtualization by discussing how to integrate a NetApp NAS file server into a VMware SRM recovery plan.
NetApp Virtual Filers
With MultiStore customers are able to logically partition a physical NetApp array into multiple virtual storage arrays referred to as Virtual Filers. A vFiler is an isolated software container that behaves exactly like a physical NetApp array. vFilers share the physical resources of the array and by abstracting the client access from physical array into virtual arrays.
Each vFiler is its own unique entity complete with its a hostname, IP address, iSCSI Qualified name, and Active Directory SID or Kerberos realm ID, etc. For all implicit purposes vFilers are just like VMware VMs, and as such they provide customers with similar advantages over physical storage arrays.
vFilers provide the ability to non-disruptively migrate a production dataset between NetApp controllers in a HA configuration. vFiler migrate is analogous to VMware’s VMotion technology. vFilers can also be pre-configured for recovery in DR scenarios. This functionality is referred to as vFiler DR, it is analogous to VMware’s Site Recovery Manger, and it is the topic I am going to discuss in this post.
If you’d like more details around MultiStore I’d recommend you see Scott Lowe’s recent post on MultiStore.
Virtual Filers sound a lot like Virtual Machines. Marketing Ploy?
I’m sure some will make this claim; it seems to be the reaction some take to the unique virtualization technologies that NetApp ship. In fact I’m having premonitions of such responses as I type!
The reality is NetApp has a long history of delivering unique storage virtualization of which vFilers we added to the portfolio in 2002.
Integration is Simplification
I think we’d be hard pressed to find someone who wasn’t enamored with the elegance SRM delivers to the numerous tasks associated with implementing a DR plan to recover virtual machines. This simplicity has made what was once only available to an exclusive list of applications a reality for every virtualized server.
Along with the recovery of your virtual machines, properly recovering a whole environment might require the recovery of NAS storage as well like CIFS shares for home directories or engineering datasets. For example if you’ve recovered your virtual MS Exchange server with SRM and your users keep their Outlook profiles or .pst files in their home directories they’ll need access to their home directory as well.
By integrating the execution of the vFiler DR command into a SRM recovery plan you can automate the recovery of your vFiler, extending the simplicity and value of SRM should a worst-case scenario ever occur.
vFiler DR Details
Any time after a vFiler is created it can be configured to failover to a remote NetApp FAS or V-Series array. This configuration is completed on the destination NetApp array buy running the vFiler DR configure command. For the sake of this post I wont go thru NetApp setup steps as they are well documented.
Unlike VMs, VFs do not require the equivalent of vCenter Server in order to implement vFiler Migrate and vFiler DR as Data ONTAP executes these processes. When a vFiler DR activate command is issued the running vFiler is shutdown (if there is a running vFiler), the SnapMirror replication is broken, the datasets are brought online, and the vFiler starts. The process of bringing a vFiler online can be preconfigured to start with a new IP address, which gets registered with DDNS servers. To anyone familiar with the capabilities of SRM this feature should sound very familiar.
How to integrate vFilers with SRM
I have to tip my hat here to VMware as they have made putting this solution together pretty straight forward by allowing recovery plans to execute additional commands. As you can see here in this image that we are simply adding a script that will remotely execute the vFiler DR command.
A critical note: As a safety measure the vFiler DR activate command shuts down the production vFiler prior to starting the DR version of the vFiler, this design prevents concurrently running two instances of the same VF. Because of this behavior I would advocate the insertion of a confirmation step into vFiler DR activate scripts prior to the execution of the activation step. Doing so would allow the running of a SRM recovery test without forcing the execution of vFiler DR, which would disrupt the production vFiler environments
I am mulling around posting a follow up to this blog where I cover the exact steps of configuring the vFiler DR setup, securing remote execution of the script, and sharing an example script. Let me know if this level of detail is of interest and I will start on the follow up, else I’ll move on to the next post.