I took the easy topic this week, and things are so crazy it’s still late in the day that I’m posting this. My apologies. This one also focuses more on ARX than previous ones – this is because replication is a differentiator for many vendors’ products, so I’m being careful to talk about what most can do, then give details for the one I know the best.

If you’re just joining this series, there is a complete list of the Reasons to date on my team member page.

Replication is of growing importance in the enterprise, be it because of distributed data centers or shared folders all over the enterprise. And you guessed it, File/NAS Virtualization will improve your replication strategy.

Most vendors of these products will allow you to write rules (or something similar with a different name) to handle replication, though how they handle it may vary from one to another.

The key here is that if you can drop a rule or schedule or whatever your vendor calls it – ARX calls it rules, hence the reason I’m using that phrase – on your File Virtualization device, you don’t need to waste any CPU cycles on a server doing replication. You can also set all sorts of parameters from aging to file type for doing your replication – in short, no need for a separate replication software package or a complex set of rsync commands to maintain. Or if you’re a huge legacy shop, no lists of xcopy commands ;-). And for most products, a replication failure on a file will merely put that file in retry mode while the system continues to replicate other files – ARX uses five (or is it ten? I always have to look that up but for this blog it isn’t important) minutes after the final (non-shared) lock is released from the file and then it tries to replicate that file again.

And since you set up replication by folder, merely moving a share under that folder in the virtual tree will include it in the replication. Nice, eh?

Replication is getting out there a bit, it is one of the differentiators that vendors use to show off their products, so I’ll take a minute to talk about what ARX is capable of, you’ll have to check with your vendor about what they do. You can replicate from an ARX in one data center to an ARX in another. That makes a backup or redundant data center pretty easy to maintain. From a NAS perspective at least… All those other issues? Yeah, can’t help you via ARX, but BIG-IP can help with many of them.

You can also turn on differential replication or delta replication, so that only the changed parts are moved across the wire. If your data centers are far apart or on entirely different networks, this is an appealing option.

One of the powerful bits is that all of this can be done to wildly disparate storage systems – because the ARX makes them look the same. So you have three NAS arrays and seven servers on the one side, replicating to a monstrous NAS array on the other side. No matter, the ARX will put sub-directories where it’s told to when configured, so these two different architectures can be mirrors of each other.

Note that with ARX, the replication target is read only, but you can tell it to either show files as they’re replicated or hold the whole thing invisible until the replication is done. A nice touch if you have twitchy admins on the receiving end and applications that count on multiple files being present are waiting to be started.

What do you really gain? Well you get all of the other benefits of File/NAS Virtualization, and you get “free” replication between disparate NAS devices (CIFS/NFS/any vendor). And you get the rules, which can provide you with a mechanism whereby your files are replicated in the manner you choose. If you’re using ARX, you get delta replication, other vendors you’ll have to ask – but delta replication saves a TON of network traffic.

That’s it for this week. There’s a ton more, but I haven’t picked next week’s topic yet. I’m considering migration, but I kind of hit on that in Reason #1 That You Need File Virtualization, so I may do something else.

Until next time,