Creating Policies on the ARX
Naturally, ARX does a lot more than just provision virtual storage for use by end users. The ARX platform also provides additional capabilities, ranging from simplified storage migration to intelligent storage tiering to extensive management tools and policy controls. According to F5, this is where the real value of the solution lies. I had the chance to play around with some of the policies. Although I was obviously in a small test environment, even this limited experience was intriguing.Similar to namespaces, creating a policy on the ARX is a relatively straightforward affair using a wizard-based setup. The ARX applies policies at the volume level to control the movement of files between the various physical file systems within each volume. I'll talk about how this plays out in each of the ARX's primary use cases below.The first use case that F5 talks about is data migration-essentially, the movement of files from one physical file system to another. I performed a simple test that simulated a migration between two storage devices. I started with an ARX volume presented over the network as a CIFS share and comprised of a single physical file system on a Windows file server. After creating some files in the CIFS share, I verified that they were in actuality created on the Windows server. I then used the ARX's GUI to provision a second physical file system into the volume, this time from a NetApp device. In the policy wizard, I selected the Windows device as the source and the NetApp device as the destination, initiated the migration and watched as the files simply appeared on the NetApp device. During the entire process, the files were visible to the user in the CIFS share, regardless of whether they were physically located on the Windows or NetApp device. The next use case was storage tiering, a pretty common topic these days. The ARX tiers files in an innovative way, making the best use as its design as an intelligent proxy. For this test, I used the NetApp as "Tier 1" and Windows as "Tier 2" and created a policy to automatically move files from the NetApp to the Windows device over time. For the first test, I scheduled a policy at one-minute intervals to move files unmodified in that interval to Tier 2. I then created some files in the CIFS share and watched them get created on Tier 1. After about a minute, they were moved down to Tier 2 as expected. The second tiering test involved what F5 called a "placement" policy. Here, files are placed on the designated tier as they are created, instead of being moved there after a period of time. Using a common example, I created a policy that automatically placed all MP3 files on Tier 2. Next, I created an MP3 file on my desktop and copied it to the CIFS share, watching it get placed on Tier 2. Files in both tests were always visibile in the CIFS share, regardless of whether they were physically located on Tier 1 or Tier 2. In the final test, I created a capacity-balancing policy to balance utilization across several file systems. Here, I created several 500GB physical systems across both a NetApp and EMC device. Then, I created a new ARX volume comprising these file systems and presented it on the network as CIFS share. As expected, checking the properties of the CIFS share on my PC showed the aggregate storage capacity of the physical file systems. The next step was to create the capacity-balancing policy to balance new file creation. Then, I created several files, watching as the ARX automatically placed one file in each of the physical file systems. F5 says that this is a growing use case for its customers, as applications become more and more data-intensive. Some applications require very large file systems beyond what is capable from a single device. This capacity-balancing capability allows you to construct a very large virtual file system comprising capacity from multiple physical file systems or storage devices behind it.