Posted a new article last night on configuring BIG-IP LTM VE In a VMWare Team environment with servers (DevCentral login required) and just wanted to let you all know.

It’s a relatively complex topic, considering that the pieces all work well separately, but if you’ve configured networks in VMWare before it isn’t too bad to get going. I chose CENT-OS as the server OS because then if any of you decide you want to toy with the team, you can email me and I’ll get you a copy somehow. You’ll need VMWare, and a license key for the BIG-IP VM, but otherwise you should be able to mess with it as-is. I prefer though that you use the article, which tells you how to set up the same environment, so if you’ve already got BIG-IP LTM VE and VMWare, just follow the steps.

For my part, I’d like to thank Jason and Lori for their JIT help with two different issues I ran into. They’re smart cookies, read their stuff.

There’s plenty of great LTM VE content on DevCentral, so check it out if you have an interest.

Until Next Time – when I’ll be talking about shadow copies…

Don.

ps: There are several I’s in this team because it’s running a BIG-IP, so there are definitely I’s in it.

Last week was golden for me. Three of my projects had major blocking issues, all three were resolved in the course of the week. That makes this week writing time, since two of the three projects were to support writing I want or need to do.

This is the start of that process. The first item to get a break last week was my ARX configuration. When I left off, some of the storage could join the domain and some could not. I needed everything to play nice in the Domain so  that I could pull them all together under the ARX. On Wednesday evening, RDP just dropped to the ADS server. I walked over to the lab and checked from the console what was going on, and it couldn’t get to the local network, let alone anywhere else. I rebooted, and it was better, could get to some things but not everything. Finding this to be terribly odd behavior with no real obvious symptoms like messed up routes or anything, I traced the ethernet cable. And found that it was plugged into a place it shouldn’t have been. While this is clearly a leftover from a previous bit of testing Lori and I were doing, I’m a little confused how it ever communicated. And yet most of the machines I was using for testing were joined to the domain, so it certainly was communicating. Sometimes.

I moved the cable, and everything started playing much more nicely. In fact, that cleared up most of the remaining issues.

Since I had a lot of non-functional items left in the ARX configuration, I opted to wipe the user level configuration on the ARX and start cleanly. It’s pretty easy to wipe an ARX config, it’s simply deletion of a startup file and reboot, so I did that, removed everything from the domain and rejoined it while the ARX was rebooting just to make certain all was communicating cleanly, and 20 minutes later the ARX was configured with both NAS devices behind it, and exposing shares to the domain.

Ta-Daaaa!

So I  went through and snapped you some screenshots. I kept saying I thought my problems were not the ARX, and the speed with which everything was added and working explains what I meant. Here come the screenshots with everything basically configured. It is not set up to do anything fun yet… I understand you may have forgotten this by now, but the point of this blog series was to show you what that cool stuff was and how to do it. So the rest of this blog shows some screenshots and talks about the architecture, and the next blog will hop right in with configuring shadow-copy.

All of my config was done with the UI. While I did trouble-shooting command-line, the UI gave me the opportunity to show you some pretty pictures, so I used it.

First thing you do is configure a namespace – a container for most of the other items you need to create. It holds publicly advertised shares and back-end filer shares, tells how to communicate with the filers and how to expect end users to communicate with you. It also holds the location that all shares are to use for metadata storage. My namespace is ingeniously named “ARXStorage”. The interface for the namespace is CIFS – I turned of NFS completely in this namespace because if it is included as a communications option, every NAS must have NFS access to every share. For simplicity, I disabled it. Some of our shares do support NFS, but we didn’t need NFS access through the ARX. And trust me, after the pain I went through with ADS, this device was going to use it.

The Namespace then contains “Managed Volumes” – exports from NAS devices that are going to be (eventually) presented by the ARX. I have two of them in this configuration – backup (which maps to one NAS device), and Dell (which maps to the other). Lori and I normally immediately back up the primary to a new NAS when we receive one so that a single PDU failure doesn’t drop our storage environment cold. More on why I bothered to tell you that in a moment. First, the Managed Volumes in Namespace ARXStorage.

There you have it, not much to see. Currently neither is listed as a shadow-copy target, both are enabled and online.

These are shares the ARX is going to manage for us, The /backup share is mapped to /backup1 and is actually actively used – hazards of a growing and changing network – but the name is all over so I’m unwilling to change it. The /Dell share is the default share on Powervault servers - /NASShare.

If we take a look at the volume by drilling down in, we can see…

As you can see, there is a lot going on here. The “files” line is way off base (there is over a terabyte of data on the disk), but I took this screenshot as soon as it was up, so import was likely still going on. Notice that Metadata Free Space and Free Space are the same – this is on a NAS that uses thin provisioning, so I would expect them to be very close.

At this point the back-end is set up. We have two shares imported from two filers, the ARX knows how to communicate with them, and it is doing so well enough to tell us how much space is used and free on the disks. Next we need to add the front-end, a way for users to access these shares through the ARX.

So we first create a Virtual. You don’t have to create a virtual first, you can just start defining exports and if there is no Virtual it will ask you to create one (okay, require you to, not ask, but you know). I’m showing you the Virtual first to keep things logically consistent and understandable. No matter how you create one, you must have the Virtual “first” or there is no way to export shares.

You will need an IP address for each Virtual you create. This is the entry point where users will access your shares – it masquerades as a Filer, in essence. Using my expansive wit, I chose to name this Virtual “ARXStore”. Note that it is already joined to the domain and is up and running. This screen shot was taken after all was configured.

Finally, we are ready to set up the exports. These are publicly exposed shares and/or mount points. I’ve made mine all CIFS for the reasons noted above, and here they are…

So they have a “Domain Name” which is the Virtual name in the domain, what Namespace they’re in (which impacts which backend shares they can see), Volume and Virtual Volume Path. The volume is the backend share, the path is the path that it will present to users.

Once those and  the Virtual show online, you’re in!

Now if you go to any machine that is authenticated to the domain, and type in \\ARXStore in the Explorer (or equivalent) Address bar, you will see this:

There you have it, the two shares exposed in the Virtual. They are accessible and can be mapped or mounted from any machine that can authenticate to internal (which is purposefully few, we don’t like giving out actual information about our network, so it’s locked down).

Next we can start using these exports to do some interesting stuff. Remember I said that we normally block-copy the backup1 share (and a couple of others) to a new NAS? Well we’re going to try setting up shadow-copy next on the ARX to see if that will just copy it for us in the background. But that’s the next blog, not this one.

Until then,

Don.

So I’ll bet you’re wondering where the updates have been?

I took on this little side project knowing it would be an “after-hours” and “as time allows” project.

I knew that we had some big projects coming like the BIG-IP LTM VE and others that I’m not able to discuss yet.

What I didn’t expect is ADS re-installs, hardware failures, new equipment (other than the ARX), etc. If I had, I would have gone with delayed broadcasting so you didn’t see all my wardrobe malfunctions ;-).

So those other projects – five of them that are big by my count – are tromping all over my free time, and thus the ARX install. Not bad planning on my part – except the part where nothing goes as expected and I know to pad my time – but just a fact of life/work.

The new Dell NAS is in place and a member of the ADS domain, the Seagate NAS is configured, and both are also accessible outside the ADS domain, so all is set. There are some inside-ADS issues with the Dell I have to work out, but they’re just ADS config, I’m pretty certain, so that’ll go quickly.

Ohhh… Ahhh…. Lori and my new Dell PowerVault 3000 series, unboxed and ready to rack.

I just need to have some time to sit and get it all working as expected. I’m getting an hour here, an hour there, and that’s slowed me down quite a bit.

So unless something changes, my updates between now and Interop will be sporadic at best, since I’m going to skip from the blow-by-blow to the meat of the problem and only offer updates when I have something relevant to say about the ARX configuration and use.

So until next time, I’ll be busy, you should be too… And when I’m not? I’ll be pestering Lori about getting a Dell EqualLogic to do all that heavy lifting like hosting PDFs ;-)

Don.

Well, over the weekend one of our NAS boxes – the NetGear – started throwing SMART errors. Yeah, it was telling me that more and more blocks are going bad and we need to do something about it.

After due consideration (more below) Lori and I decided to replace it with a lower-end enterprise-class NAS.

Now this may sound like odd timing to you, but there’s something I haven’t told you. The NetGear was our tier two because it has a bad channel. It’s been running one disk shy for quite a while, and the problem is with the controller, not the disk – we tried replacing the disk right-off, only to discover that pre-NetGear versions of this box and issues with the first channel on the card. Lose another disk and POOF! No more tier two.

So we’re going to make the Seagate BlackArmor our tier two and place a shiny new Dell PowerVault NX3000 into our network. We picked the lowest end model they had that included CIFs, NFS, and ADS support in one box. Funny thing, neither Lori nor I has touched a PowerVault since we had a prototype in the NWC lab back when they were just starting the line up. Should be fun.

This is a “for us” thing, F5 isn’t subsidizing it in any way, and really shouldn’t be. Our NAS devices hold our stuff – our written works, pictures, PDFs we’ve purchased, even rips of our CD collection. This box is pretty, and we’re stoked, but with this box there is both good news and bad news…

You see, the Dell is a Dell, and it’s an enterprise product, so they don’t have one laying around that they can just ship to us, they have to put the disks in, test, etc. So it’s going to put this series off by another week. The good news is that once the box is here, I can sidetrack writing about configuring it and moving our network around, then we’ll be all set to actually talk about the cool things we hope to achieve with the ARX.

Until then though, I won’t be saying much. Let’s face it, I could play with the ARX for the week and tell you about all the switches I toggled, but you’re not going to use the box to play with, you’re going to put it in and tell it to manage your storage. So until I have the environment set such that I can do the same, it makes no sense to write about stuff that is fluff. In short, I’m not going to blog about stuff that doesn’t matter to you just so I can say I’m blogging.

So I’ll focus on other topics this week, and then you’ll get a flurry of updates when the new device arrives. The only thing I plan to do between now and then is rip down the ADS server (as in shut it off again), and make sure our Seagate plays nice via NFS, so all is set for this box to take the lead. Oh yeah, and back up both NAS boxes, so I can move the Seagate stuff onto the PowerVault, and the Netgear stuff onto the Seagate. So I guess I’ll be doing routine admin stuff, but nothing worthy of a blog unless something goes wrong and I think I can make you smile by blogging about it.

Until then, don’t get NAS-ty, be patient, we’ll be back.

Don.

Well, I’ll bet you’re wondering how it’s going?

First, the reasons for my silence that you haven’t heard. Last Thursday my wonderful Dell Latitude D820 died. I loved this machine, thought so much of it that last time I updated my home machine I got a D830. But sadly, it was over three years old, and I spend 8+ hours a day abusing it, so no surprise.

The warranty ran out in December, so that left me (IT actually) no option but to replace it. The real reason to include this is to point out to you that F5 IT rocks, and many IT departments could learn from them. I’m a remote worker, I was limping by working on my home machine which had most of what I needed, but some key software like MS Project wasn’t installed, and webmail is… painful in any situation.

I told IT the machine was definitely dead late on Tuesday, on Wednesday I had a new machine. With my login info and the licensed corporate software installed. You don’t do any better than that.

So they sent me a Latitude E6400, and honestly, I’m pleased as can be. The only little problem I’ve had with it was (so far) not work related. I listen to DVD lectures from The Teaching Company in the evenings while working or painting or writing for non-work, and for some reason my newest set of DVDs plays fine on the machine but doesn’t have sound. Local WMV files play and have sound, the DVDs work on my home machine… So I don’t exactly know what’s going on there, but everything else works perfectly, so I’m happy. I’ll figure out what oddity makes them work on other Dell Machines and not on this one.

And I was complaining that I was out of space for VMs… No more! Much larger hard disk.

Anyway, you can imagine that getting the machine, pulling the hard disk from my old one (don’t tell IT, I’m not certain they’d approve), hooking up the disk via USB and dumping all the important stuff, reconfiguring just about everything – from bookmarks to networking settings – to work well in my environment sucked up just a bit of my time.

On the bright side, the days that I had no machine (it was nearly a week because we’d hoped we could fix the old one, but alas, Dell said “motherboard, fixing is a bad choice”) gave me a chance to get my storage house in order.

What did I do? Well I wiped the box running ADS and started over. It had ADS and DNS installed from who-knows-how-long-ago, but it was shut down… So I tried with the installed copies, but wasn’t real confident and it wasn’t working the best.

So I wiped the server and reinstalled, set ADS up again, joined my home laptop to the ADS domain, then worked at getting the storage into the domain. One required using the WINS name instead of the domain name to get it to work, the other required that I add it by had to ADS and DNS, and THEN tell the storage to join the domain. And as usually happens in that case, all went well.

Finally a chance to join the ARX to the domain. This is something I had not attempted up to that point because I wanted to have the things an ARX requires – storage and users – in ADS so that once it was joined I could get rolling. So I went to join the ARX into the domain… And realized I did not have the faintest idea how to do so.

AD Forest/domain list.

RTFM time, so I went and looked. The help on the system I have is very nice, and coworkers tell me that the help on DMOS 5.X is indeed very nice overall. That helped me get rolling, as did the logs, which are very verbose and I cannot recommend enough. In fact, all the oddities I’ve encountered to date – failure to access disks for metadata, failure to connect to shares, failure to negotiate NFS versions… All were ultimately the fault of my storage, and all we ultimately made clear to me via the ARX logs.

Lots of logs – and this does not count the automatically generated reports for lots of common activities.

 

The Managed Volume created under ADS.

One really odd thing I ran into that I am working around by ignoring it – because I can – is that I have a Namespace whose drive mountings failed – a leftover from the work I was doing in NFS and CIFS without Active Directory. It is stuck in the “starting” state, and I can’t get it out. Since the ARX won’t let me delete it, I’m ignoring it for now, and need to look up how to point out to the ARX that it will never finish starting since it has no volumes allocated to it. I’m pretty certain that this is a user error, so don’t judge the ARX poorly, even if it is an ARX error, you can ignore a single Namespace easily enough. Or better, don’t use SMB class storage so you’re not jerking the poor ARX around for three weeks ;-).

A Virtual defined on the ADS domain Internal.

Everything before that last picture that I’ve talked about has been the backend. Now that all the backend pieces were working together, it was time for me to set up the user-facing bit… The Virtual Service. This is the presentation “volume” – where the device advertises the Virtual Directory Tree to the network. It went easy enough on creation and making CIFS exports, and it’s up and running now.

The problem I’m stopped at now is another RTFM – I need to join the Virtual to the domain, but haven’t read how – it told me that I needed to and how to do so when I created the exports on the Virtual Service, but it was 3am and I thought “I’ll figure that out later…” And indeed I will, for this blog is long enough, and that’s where I’ll pick up the next installment.

Until then, enjoying my new laptop and seeing this all working together.

Oh yeah, and I have to make my regular everyday user not be SuperADSMan. I toggled him up to Enterprise ne’er-do-well while testing, and don’t want to forget to make him normal, and create the storage background users I need. More on that next time, when I’m sure what storage background users I want/need.

Don.

I wanted to do at least two updates a week on this series, but circumstances conspired to keep me from an update earlier this week. In case you missed it, we’ve had a release or two going on (that link also has the “F5 joins NetApp Alliance Partner Program” Press Release on it if you missed that one), and I’ve got my bit to play in that. I also inherited a rather large project that I need to drive home, and it took a chunk of time just figuring out where it was and what the next steps were. There all the excuses but the one you came for are done.

Now the one you came for… My network, my devices.

The ARX is up and running beautifully, it behaves as expected except for one niggling bit that I suspect is due to the fact that I’m using SMB class NAS devices, so I’m not going to bring up. If you’ve got a NetApp or EMC NAS, you’re probably not going to see it, so I’ll leave it at that.

My devices on the other hand… Arggghh.

I’ll skip the hoops I jumped through and the number of times I attempted to add shares trying to get my NAS devices to play well with others. One was requiring a login to access a drive marked public, the other was giving me access denied errors. Both of these problems were evident from both servers and the ARX. I’ve changed quite a few settings over the last week, so I went back and started again. It turns out that one NAS device requires the volume in the nfs path, the other does not. Problem one solved. Access wasn’t denied (as the device told me), but the share I was trying to mount didn’t exist. I got the name straight. The other was a setting in the global config that I tracked down – it defaulted to no access for all new nfs shares, and I had created new ones for testing, so I wasn’t messing with production data. A few mouse clicks later, and theoretically both are ready to go. As a bonus, after nearly two weeks of changing things on these boxes to get one of them fully functional – the NetGear was partially functional last week – All of the clients on the network could still get to their shares.

So I go back to the ARX management screen, and attempt to mount a share on my Seagate BlackArmor NAS. This is where owning an SMB NAS really started to hurt. With a fully qualified path, it tried, and it failed because root_squash was turned on. This is a cool protection mechanism of nfs that changes the uid of root to be “nobody” so root has no special privileges and cannot break anything. Fine, I turned it off on the NetGear/Infrant, so I would just turn it off on the Seagate. Remember that the ARX is a file virtualization tool with a lot going on inside. It needs root rights to move things about (particularly files in a tiered environment), manage file access privileges, and to manage the metadata share.

Guess what? After lots of research, I discover that the BlackArmor NAS doesn’t let you turn off root_squash. So I have a solution for this, I have another Namespace (think virtual tree container) on the ARX that I can use that has CIFS enabled. I’ve SMBmounted this box a zillion times, and our XP clients access it fine with CIFS also. So I pop back into the ARX manager, change to that Namespace, and try to add it as CIFS.

“NAS Device does not support Kerberos Authentication” The ARX tells me.

Sigh. So I can’t do NFS because root_squash can’t be disabled, I can’t do SMB without an ADS machine.

The BlackArmor is our primary NAS, so I don’t want to move forward without it, but Lori took down our ADS machine a while back, and it’s physically gone from the building.

That leaves me trying to use SMB PDC functionality (vaguely recall doing that once), or setting up a new ADS server and hoping that the BlackArmor knows how to use that.

So a chunk of the reason I skipped blogging earlier in the week was simple… I had nothing much to report other than the obvious – Seagate BlackArmor isn’t enterprise class NAS. Duh.

And now I have a project for this weekend. Setting up ADS to move this project along, I’m tired of blogging about my network/storage issues and want to move on to actually using the ARX.

I tried to turn this into an excuse to snag a NetApp – something like a FAS2020 would do, but that fell through when a fellow F5er brought reason into the discussion… So that idea is out. For now.

Until next time,

Don.

All Options Were Considered… *

* Photo by Alex Nash and used under the Creative Commons License.

Click the image to view the original picture on Flickr

Okay, so I hit a wall and didn’t post yesterday. That is not at all a statement about the ARX, indeed, it was acting as advertised. The problem is our network. It creaks a little bit around the corners.

We’ve got two NAS boxes, a bunch of Linux boxes (all patched, but some OS versions showing their age), a non-public Windows 2000 Server, and a slew of both Linux and WinXP clients. No Windows 7 yet, and we ditched Windows Vista pretty quickly.

Pretty simple setup, right? Yeah, if you’re in IT, you know that the longer a network exists the more weird stuff happens on it. Ours is a hybrid, we use it for testing and for hosting our “production” servers. Several websites, mail, two DNS servers, a box whose job is to present our SAN as a NAS (yeah, we did that)… Apps we installed to test – either for us or for various employers – and a media server.

The first snag I hit was the DNS servers. I set up the base IPs on the switch okay – the management port on one subnet and the data/inband management port on another – and the ARX config to do this is as straight-forward as any I’ve seen. Then I put the new names into DNS (more on names in a minute)… Problem is that our DNS servers have to be restarted in a specific order. I always forget that, so I modded the files and restarted them, and… Nothing. Wasted more time than I should have before I recalled that this happened to me before several years ago because I had restarted the secondary first (IIRC). So I restarted DNS in the opposite order and BAM! Problem solved.

So now I have reliable connectivity other than a serial port, and I pop open the configuration tool in the web browser. I’ve already done the basic config, so now I’m creating the actual virtual directory structure and mapping my drives to it. Or so goes the theory.

ARX again performed exactly as advertised, and the screens are really clear. The logs don’t contain as much information about errors as I’d like, but if I had the network overall configed correctly, that wouldn’t have been a problem.

The only issue when two people with masters degrees in computer science and high-tech jobs share a network is that it changes a lot. We used to have a Windows Domain Controller – ADS on Win2K. We even used to have a pre-ADS PDC… But when I looked, the NAS boxes were in a workgroup, not a domain. Hrmmm. After poking around the network, Lori tweeted that the domain controller has been gone for a while. Doh! Okay, I look at the ARX config, and while it might be possible to run the CIFS portions without a domain controller, it certainly doesn’t look like it. I could have popped off and asked the great people on our ARX Marketing team, or our IT staff who has also offered a hand, but I wanted to work through this to give you all the “starting cold” walk-through, and I knew a secret. I am Storage Guy in the house, and since most of our servers run Linux, all of our NASes support NFS. I don’t create storage without it.

So I checked, and yes, both NAS boxes were configured to run NFS, and ARX has some great NFS support, so I chose this path (as opposed to making our one Windows server into an ADS domain controller).

I was off! Well, kind of. This is the point where I admit that while I set everything up with NFS, I don’t always mount NFS. In fact, it appears that my finely configured NFS interfaces on one NAS box had never been used.

Our primary servers are all Linux. I checked them. They were nearly all mounting the NAS boxes with CIFS. Nearly. All of the ones accessing the primary NAS box were mounting it CIFS.

Sad state of affairs. Now I had NFS configured, and had read up on how to add nfs shares to the ARX (easy as pie, just a few questions like “which file server?” and “What mount point”, etc.)… But my shares were rather stale. So stale in fact that neither machine allowed the ARX access – not with an admin account, not with a user account. The ARX uses the admin task to handle things like moving files between tiers and other non-user activity, while the users just want their files.

Major sidetrack #2. The ARX was talking to both boxes, but wasn’t able to mount them. Either of them, any of the shares. So I go look at the configurations. On the secondary NAS box it was a simple case of mount point permissions. On the primary? I don’t know yet. That’s where I sit. I have a managed volume on the secondary (a 2TB Infrant NAS if you care), and it appears to be loading, but the primary is still not letting me mount via NFS – not from a random Linux box, not from the ARX.

So what’s the point of all of this? Well, you’ve got my “we’ve got a crufty network” update, and Lori and I talked on the phone tonight about how we’re going to rearchitect it after she returns – another fun time for reconfiguring the ARX ;-). And I’ve got at least one filer hooked up. Seems strange to me to call a brick a filer, but it’s equivalent, I still need to get the other going and see what happens when it synchs directories - they’re copied directory structures with some files on both and many others on one but not the other.

And if I can avoid it, I’m not going to take the fine offers of help from fellow F5ers. You are going to have to wade through most of this on your own if you install an ARX, and I want to give you a bit of an overview of one man’s issues as much as I want to do the “look how cool and easy this was!” thing.

Off to get some rest, it’s the 2 year old and I, off on our own tomorrow, I’m going to need that rest!

Tomorrow, we’ll see if I can actually get the basic config together. This sounds bad, but remember that I have other duties, I’ve got about six hands-on hours into this including downloading and reading docs – less than a day of your time, or a day of your time if you hang out at the water cooler a lot. Weeks of your time if you read too much BoFH. ;-)

Until next time,

Don.

Well I’m putting my new ARX through the paces on my network, starting today with the base config and try number one at setting up the shares.

This is an ARX 500, which is more than enough for our needs, and gives us a platform to start testing different ideas out on. To quote Lori when I told her I had all the ports communicating, “Now make it do something impressive”.

The point of this blog series is to give me a chance to play with my new toy and give you all an idea of what the ARX can do. I’ve got a few goals in mind for this box, but want to make certain I’m not asking too much before listing them for you. So we’ll just walk through configuring it to handle my two NAS boxes (and possibly one linux share – but more on that later, it’s for an advanced use case), and start tiering. While the two NAS boxes are roughly equivalent, I do have one as a primary and one as secondary storage today, we’re just making that distinction with hand copies, and we would love the ARX to handle tiering for us. That’s the baseline. After that there is some replication I’m interested in, and some scripts and and and… I get ahead of myself ;-).

Today had a couple of snags – I hate it when hardware is designed so that the cable condom – that little piece of rubber over the clip on the Ethernet plug – catches when you unplug the Ethernet cable. Having worked for Network Computing, I can tell you plenty of vendors have this issue on their 1U box, and honestly if you check the hardware configuration guide before plugging in CAT5 all willy-nilly, this won’t be much of a problem for you (I had the in-band mgmt port plugged in, but initial config must be through the out-of-band mgmt port. RTFM’d, and used a knife to remove the plug, and all was well).

And that’s the first out-of-the-box impression I have. In several cases things that I assumed were not true. The manuals are astonishing (no, that’s not employee-speak or I wouldn’t have mentioned the Ethernet jack thing) by any standard, but that’s good, because you’re going to need them. I’ve configed a couple of hundred storage devices, maybe more than a thousand, and this one got me a few times already – all minor stuff, and all makes perfect sense once you know what the designers were thinking. Thankfully, with a full documentation set on Ask F5 (login required), you’ll have no problem breezing through these issues.

I’m going to spend a couple of hours a day playing with this box to get it configured just the way I want/need it, and I’ll write at least a bit each night about my experiences. I would love to play enterprise IT guy and spend a day or two in ARX-land, but we have a lot of other stuff going on, and a nice side benefit is that you all get these blogs in bite-sized chunks. A fellow Twitterer reminded me of the massive spiral bound training document that I brought home from Boston (where ARX is made/maintained/whatever you call it) last year, and while it’s got some good information in it, I’m happy with the documentation on Ask F5 thus far, it’s more crisp because it’s not formatted for training, but once it’s fully configured and running in my environment, there were some tricks in that book I’d like to try.

Why did I stop where I did? I toyed with actually importing shares and creating a Virtual, but deleted them all and decided to wait because there are some fundamental questions I need to dig up answers to before taking those steps – like where is the best place to have the ARX put its meta-data and if a share can be accessed with both CIFS and NFS, what are the benefits of turning on both, one, or the other through the ARX? Also want to look at our infrastructure and see about locking down the share IPs so that they must be accessed via the ARX, a trick that I have heard of and finally get to try out. Feels all FC to run everything through the switch, but saves scanning disks for changes, something that bears a large cost if a few NAS devices’ interfaces can be slightly modded to avoid it.

But that’s for another day. For tonight I’ll just leave you with a screen shot of the web UI, for those who’ve never seen it…

If that posts like it  looks in Windows Live Writer, it’s too small to read. This was taken just before doing the web configuration, so only the configuration option is available. Once it was completed then several other options became available, and as I said, I played with them, but deleted everything I’d done because I want to paw through the manuals and get answers to my questions first.

To be honest, having dabbled in both CIFS and NFS protocol-level development, I’m just impressed that it can proxy both. Sometimes a little knowledge gives you a lot of respect for those who have more :-).

Until next time,

Don.

Well, tmsh has been around for a while now, but the scriptable version and support for it here on DevCentral are relatively new. In fact, I just got the links to the parts of DevCentral last night, so that’s very new.

I wrote about tmsh when it first came out in version 10.0, but with version 10.1 we have added some key functionality to make it more useful in your daily admin work.

And now, our team with the able assistance of our Technical Publications staff have created a tmsh wiki much like the iControl and iRules wikis, and forums to support tmsh (note: both require DevCentral logins).

What is tmsh? Well the first link in this article will tell you a lot, but if you just want the synopsis, tmsh is the shell replacement for BIG-IP’s bigpipe command, only it does much more than bigpipe did. Worried that you don’t want to have to learn tmsh to manage your BIG-IP family products? No worries, bigpipe is still available at this time, but the power of tmsh combined with its scripting capabilities make us certain that you should check it out. bigpipe won’t be around forever, and you can get a lot out of tmsh.

And that’s where the wiki and the forums come in. Pop by, registered members of DC can modify the wiki and post to the forums, so not only can you get a leg up getting started, but you can share your experience with others and take advantage of their knowledge.

Colin and Jason have put together quite a few examples of how to use the features, they’re linked to the different tmsh commands in the wiki. Let us know what you think, offer up your own examples, help us expand the documentation, and have some fun. We’ll be around if you need anything.

Until next time,

Don.

Funny thing happens when you start talking about things like inter-cloud standards, those who are looking at it from the IT guy’s perspective start to see issues that are as-yet unresolved.

We have an excellent screencast on moving VMs between clouds, and Lori has written a ton about inter-cloud standards, but neither goes far enough. Yet.

George Crump of Storage Switzerland talks about moving data over on the Network Computing Blogs too, but he also is missing some important bits in the Inter-Cloud story.

Simply put, you’re gonna have downtime if you’re trying to do it today. Or tomorrow. Yeah, probably next year too. After that the vision gets a bit cloudy.

Your website “WeSellStuffForBigProfits.com” is not going to be around for a while, and that means “WeDontSellStuffAtAll.com” is a better name.

We at F5 have a ton of the puzzle in place – our GTM product module can dynamically redirect users to the new instance no matter how far across the globe it has moved, our LTM product’s iSessions can create back-end tunnels to transfer data (assuming both cloud vendors have BIG-IP LTMs, which at this point in time is a relatively safe assumption), and we have the whitepaper on how to move your VMs and bleed off users to the new cloud provider.

But there is the problem. If there is no cutover, what to do about changing data? Whether it is in files or in a database, users in two places on an interactive system means you have two sets of data that don’t match and are both changing. Bad Juju.

We can move your users, we can move your app, we can move your files and databases. What we can’t do is guarantee that the new file system or database is the only place that changes are being made – because you either migrate users (and thus they’re potentially updating on two systems simultaneously) or you cut them over (and they lose their connection).

But all is not lost. Several years ago, quite a few companies started approaching data replication from a new perspective – Continuous Data Protection (CDP). While most of the time CDP is overkill (every DB transaction replicated as-it-happens, in essence the call being replicated rather than the data, each write to the file system the same), moving between clouds might just be the golden problem for CDP to solve. Turn CDP on for the old DB/Filesystem and make the new DB/Filesystem the target. Then whenever someone runs a transaction or uploads a file to the old site, it is automatically copied to the new site also. I do have some questions about changes coming at the new site from both users and the old site – there is a potential there for conflict – but that’s the type of stuff I would ask the CDP vendor how they resolved.

I’ve not tried this of course. Intercloud is not yet in such a state that you can come up with a good idea and pop-off to test it, but the theory is sound as long as both providers offer you APIs for getting at your files and data. Indeed, the Cloud Interoperability crowd should be taking steps to make certain this happens.

Why? Because for the people Inter-Cloud is supposed to serve – IT shops who don’t want to be locked in – moving IPs and VMs is okay, but not a complete solution. The need is for the ability to seamlessly move applications, VMs, and users. And that won’t happen if “bleeding off” users causes your data – both structured and unstructured – to become out-of-synch between source cloud and target cloud. And the CIO doesn’t want to hear that there’s going to be down-time for their site from the moment the move starts until it is finished. That’s just not viable for most online applications.

There are still quite a few CDP vendors out there. I have in-depth knowledge of the CDP solutions for one vendor, but I’ll skip mentioning them here (I have a compensated relationship with them and they’re not F5, so it saves me having to put a disclaimer in my blog ;-)). You can do a bit of research into CDP and find several companies with offerings.

Replication will only take you so far… It’s not real-time enough to handle things like primary/foreign key mismatches, though you can work around this, it is work, and I’ve seen even those workarounds (like separate ranges for primary keys that are auto-increment) fail. So we need something more, and CDP or massively distributed databases and filesystems are the only real answers.

Until next time,

Don.

Well, this is my “on vacation” blog, so I’ll keep it short.

This holiday season I received a big box from our Data Solutions Group that I’m told contains an ARX for my play-time and will no doubt fill your reading time in the new year. Assuming you read my blog anyway ;-). Those guys rock, and pulled through for me in a  major way to get this delivered.

I’m stoked to have one to play with, and will blog for you from set-up to messing with it. I’m terrible about that. Give me new hardware and I play with it until I understand most of the ways it breaks and how to fix it. Most breaks in the IT realm are user error, so I can make just about anything break if I tinker with it long enough.

And the gift for you this festive time of year? Oracle and F5 are finished testing the Oracle Enterprise Manager Grid Control Plug-in for LTM versions 9.4 and 10.0.1. So if you’re an Oracle customer with BIG-IP LTMs deployed, pop over to the Oracle pages of DevCentral and download the plug-in. It’s certified by Oracle, and monitors your BIG-IP like any other Oracle Enterprise Manager Grid Control.

At this time you have to be a registered user on DevCentral, but we will no doubt be like all the other OEM Grid controls available on Oracle TechNet. Sorry for the inconvenience, but this stuff doesn’t happen overnight and this is an iffy time of year to count on people being around to update websites and such.

Meanwhile, anyone want to take a guess at which geek toys I picked up for Lori this year? Anyone?

Until next time – which will likely be next year since I’m off until the 4th, and traveling the 4th…

And no, the picture is not the ARX I expect to find in that box… Mine should be smaller ;-).

Don.

Yeah, I’ve been putting the baby to bed most nights lately, and yeah, that was a Goldilocks reference.

In the slew of new versions and products that we’ve been talking about, I didn’t want you all to miss what is (to me) some of the biggest news this month – the ARX 2000 and DMOS 5.1.

I’ve blogged a bit on why you might need File Virtualization, and our smart product management people have listened to your needs and produced a box that sits right in the middle of our product line to meet the needs of those whose data problems are large  for an ARX 1000, but don’t quite need the ARX 4000 yet.

This little box packs a lot of punch in a 2U device – twice the performance and capabilities of the ARX 1000, redundant hot-swappable power supplies, and twice the max users of the ARX 1000. It comes with 12 GigE ports and can handle more than four gigabits of throughput. If you’re thinking of an ARX 2000 instead of the higher-end 4000, what you need to know is that the 2000 has no 10 Gig support and less users/throughput than the 4000. Talk to your sales rep to figure out what box is best for you.

Coinciding with the release of the ARX 2000, DMOS 5.1 came along also. There is added support for NTLM v2 and Windows 2008 Domain Controllers, CIFS connection multiplexing to give more users simultaneous access to connection-limited devices behind the ARX, support for Windows 2008 Clusters, and support for Windows 7 clients. DMOS 5.1 is available for all of the ARX product family, but comes pre-installed on ARX 2000 machines.

I don’t have my box to play with yet, but you can assume you’ll be hearing more from me about DMOS 5.1 in the near future.

Sound market-ty? Yeah a bit, but I like new toys, so give me a break :-)

I’m hearing rumblings of Lori and my ARX being about ready – not a 2000, we don’t have that much need for sure, but one we can play with. So keep your eyes glued to this space. Ah! No! No bathroom breaks!

Don.

After George Crump and I played ping-blog - His Storage Switzerland Blog, my blog mentioning it, and his InformationWeek blog, I went to post a comment on his blog and didn’t feel like giving InformationWeek my entire family history just to do so… So I give you “the comment blog!”

One of the key things that I find to be a side benefit of File Virtualization is file/directory level security and centralization of security management. I personally wouldn’t buy for this reason alone, but I know others, particularly some of my security friends, who would (and are calling me names for saying I wouldn’t in 3,2,1…). I’ll speak here only of our ARX series because I’ve had reason to look into it pretty closely of late and don’t want to misrepresent other vendors, but I presume they have similar functionality.

As I said (at length) in this post, you can enhance your security with a file virtualization appliance. Lock down the NAS boxes so they can’t be accessed except from the IP of the appliance (a good idea anyway, if files are changing and the appliance doesn’t know it, well an ARX can figure it out, but it’s certainly less than optimal in terms of real-time reflection of file status), then open them up to any user, and finally, implement folder and file security on the File Virtualization Appliance.  Since most will talk to ADS, there shouldn’t be a huge problem here, and it improves both your file virtualization infrastructure and your security management – because you’re only managing in one place.

But that brings up a thought from the back-and-forth with Mr. Crump. In this scenario, while the ARX is the File Virtualization appliance he mentioned, if for some reason it goes down or you want to remove a NAS from the virtualized directory tree, you’ll have  to remember to open up the IP addresses that can access the NAS, otherwise no one will be able to see it unless they’re masquerading as the ARX. Bad mojo, so I thought I’d point it out.

Truth be told though, how often is this likely to be an issue? Well, how often do your mess around with your NAS infrastructure? Most companies I have worked for don’t, except to add new disk and get files and users transferred to the new disk. Since ARX will automate this process for you in a couple of different ways, you won’t even do that when you have one in the building. The other big to-do is security. Stuff that has to be locked down must be… But why keep your NAS security information on a bunch of different boxes, even if you use groups? Why set access for a group on three different NAS racks when you could just do it once on three directories in the ARX? The other possibility is a device failure – rare in a File Virtualization device, but possible since it is a piece of equipment - and your decision to remove some bit of storage from the virtualized tree, or remove the virtualization appliance completely. Hope that never happens, but now you’ve been warned about one check-box you’ll have to complete if that comes about.

But not touching a bunch of different boxes whenever a security policy change comes around… Now that is worth the issue above. Worth it and a lot more, since the issue above is a one-time thing and security policies, well lets just say they’ve been getting a lot of adjustment the last few years, even without the manager that wants his entire staff to have access to every share/mount in the building.

Until next time,

Don.

George Crump over at Storage Switzerland has a pretty good introductory primer to File/NAS Virtualization. George and I haven’t always seen eye-to-eye, but that’s no surprise, I’m one of those people that wants analysts to prove they’re working on solid ground, and he’s an analyst. Both being type A personalities just guarantees that once in a while we’ll get a little sparky. This time though, he’s got a good intro written up, and though he doesn’t come out and mention it, the standalone, heterogeneous solution he talks about as the second type is pretty much what our ARX series products are all about.

The only thing he missed that I think it is imperative to clearly delineate in any storage virtualization solution primer is that NAS/File Virtualization does not suffer from the horrid “my virtualization box went down, how to find my data” problem that SAN virtualization largely failed because of. With File Virtualization you are still saving the file with the name that the user typed in, it just might be on a different NAS or share than the user thinks – you’re masking where, not what. I know that some vendor’s NAS solutions used an indexing scheme that masked what and where, I presume those have all improved or gone the way of the dodo (though I haven’t looked in a while… If I find some when I look over the next few months, I’ll let you know. If I do find any still  extant, I’ll leave the ridiculing to others though, since those in the File/NAS virtualization space are our competitors ;-)).

The other thing that made me a throw up a little in the back of my throat was his use of the dread phrase “ILM” (Information Lifecycle Management). I shudder when our marketing organization uses it too. ILM had such a huge hype curve that it was doomed to fail when reality showed that its most useful bits were easier merged into other applications and appliances than implemented as stand-alone solutions. ILM products like dedupe and tiering have survived, but this functionality is also merged into existing products. The reason stand-alone products still live is because they are heterogeneous and offer a more data-center wide strategy than the one NAS box you have doing these functions for itself and ignoring all the other NAS your organization owns.

So I prefer some other terminology for tiering and rule-based movement, both of which the ARX does smashingly well (how smashingly well you ask? Watch this space, I’m working up a series). But in essence the tiering bit being associated with ILM is fair, ILM or HSM is where its roots lie anyway. I just think that as early as 2004 some smart people were pointing to the rebound problem and trying to slow the hype curve before it reached the clouds. Sound familiar? Yeah, it happens a lot – XML, Java, SOA, Cloud… All got their share of over-hype, but most found a home. ILM was a group of related ideas and while large chunks found a home in products like ARX, it did not really survive as a single field of technology. So I don’t use it unless I’m talking about other people’s writing.

The biggest problem I see with File/NAS virtualization is one of education – most people don’t fully understand what they can hope to gain from it. Since I’m doing my bit to educate people on the issues (find a full list of my file virtualization articles on my DevCentral “About the Team” page or by searching for “Don MacVittie Virtualization” on Ulitzer), I’m happy to point to Mr. Crump’s article as a good starting point for those of you who are still trying to figure out why you’d bother implementing File virtualization in your organization.

Meanwhile, I’m cooking up that series, expect to hear more from me in the near future – maybe even an “unboxing” video of an ARX, depending upon how mine is packaged when it comes.

Until then, read on, and enjoy our increasingly virtual world!

Don.

Fun with full disclosure. I’m an employee of F5 Networks, producer of the ARX family of products, file virtualization solutions. If you think that is enough to make me say good things about the product line, I suspect that you don’t know me very well…

(Picture is By Ian Wilson, released via Wikipedia under Creative Commons license.

Click the image to be taken to the picture in its original context)

If you’re an OEM user and an F5 customer, we’ve got an updated version of the OEM Grid Control Plug-in for BIG-IP in beta testing right now. It’s been in limited beta for a while, but we wanted to make certain that both TMOS 9.x and 10.x were supported before we talked about it publicly.

The plug-in, jointly developed by F5 and Oracle, allows you to monitor your BIG-IP like any other infrastructure in the Oracle Enterprise Manager, and if you’re part of the beta program, you can download the source to see how the developers did it too! No, I wasn’t on the dev team for this one, there just aren’t enough hours in the day for me to play with all the toys. Though large pieces of it are based upon my Java Wrappers for iControl, so I can claim a little bit of the fun ;-).

If you’re interested, head on out to the Oracle forum here on DevCentral, and post a note that you’re interested. That’ll get the ball rolling to get you access to the beta and the source.

From a post in the forum by Ron Carovano, here’s some info on what exactly you get.

Oracle Enterprise Manager Grid Control System Monitoring Plug-in for F5 BIG-IP Local Traffic Manager