Having LTM-VE is nice, but setting things up so that you can actually use it for something is a different matter. There is a lot of information floating around out there about configuration ranging from Joe's Tech Tip to Lori's Architecture Reference to deployment guides. This article focuses on setting up a VMWare team that includes your BIG-IP and some test servers.
Since I wanted this to be something you can re-create, all of the servers utilized in this Tech Tip are clones of a straight-forward CENT-OS install. I toyed with a large number of OSS operating systems, and decided of all the OS's I installed, this was the one most suited to enterprise use, so cloned it a couple of times and changed the IP configuration. All of this will be documented below, the goal is to set you up so you can easily copy this environment. If for some reason you cannot, drop me an email and we can arrange for some way to get the files to you.
One thing to remember throughout an install of LTM-VE is that in the end it is just a BIG-IP. Sure, it's in an odd environment that offers some challenges of its own, but from an administration perspective it is just another BIG-IP. In terms of throughput and configuration it is different because of the environment, but in terms of day-to-day administration, it has nodes, pools, virtuals, iRules, etc. that are all accessed and managed in the same manner as you would if this was a physical BIG-IP.
I placed my BIG-IP and the three server instances into a single VMWare team, meaning I have single-button turn-on/turn-off for the entire test environment. For my purposes, my desktop (the VMWare host) is sufficient for representing clients, but I'll point out how and where you would add clients below.
And last caveat, this entire Tech Tip is done in VMWare Workstation. If you are running one of the server versions, some dialogs/etc will be slightly different.
First off, download and open the BIG-IP vmx file. A link to the vmx can be found on the DevCentral VE page. Once you have LTM-VE opened, you're ready to start your team-building exercise. Download CENT-OS from the link above, or some other OS that you are familiar with. Windows works just fine, I only excluded it from this solution because I can't be offering to give you copies of an OS that charges per-copy, and I did say if you had problems to drop me a line.
You'll need to install CENT-OS into a new VM, but VMWare makes that so easy that even if you've never done it you should have no problems. Just choose New|VM and tell it where to find the ISO images you downloaded.
Once the BIG-IP is loaded - and you can start it and play with it if you like, the default management address will be in the output of an ifconfig on the BIG-IP command line as eth0-mgmt. From your host OS's web browser you can navigate to that address and start licensing and configuration as explained in the release notes.
Next you'll want to create the team though. From the VMWare menu, select File|New|Team like this...
Give it a name and check the directory it will save to...
Then add VMs to the team. Choosing "existing VM" will move a VM into the team, choosing "Clone of a VM" will copy a VM into the team. I basically configured one copy of CENT-OS and then added clones of that one to the VM. I used the same process with BIG-IP LTM VE.
Finally, add network segments to the team if you are going to model an existing network with your team.
In the case that we're exploring here, I did not add any network segments to the team, but rather relied upon VMWare's DHCP capability to assign me networks that I then utilized when configuring the servers to use static IPs (as they would in most environments).
So the first thing you need to do after you’ve built your team is set your servers to use static IPs. They will default to DHCP, but that’s not the greatest solution for a load-balancing environment, since any change to the IP addresses of these servers will have an impact on the BIG-IP’s ability to load-balance. Note, if you are terribly lazy you probably don’t have to give them static IPs, because you control what goes in and out of the network, if you don’t add any servers to a segment, you should get the same IPs each time you boot. But boy, I just cannot recommend assuming a given server will always get the same address, that’s asking for trouble.
One last thing to check, go into the Connections tab of the Team Settings dialog. We started with each of our three servers set to NAT, and eventually had to switch them to Host Only during config. If you can’t ping across the VLANs (there should be an implied route between them), this is something worth checking.
And that covers creating the team. In short, the benefits of a team in our case are these:
- Single button power on/off
- Contained environment with everything you need to test in one VM
- The ability to add network segments to emulate your production environment
As I mentioned above, I put nothing but Virtuals directly on the external network because I planned on testing with just my host OS, but you may well want to add clients to the external interface.
Next, you’ll have to configure the BIG-IP. You need to create an internal VLAN with the internal network (the one the servers are on) in it, and an external network that faces the outside world. The BIG-IP Management interface on first boot will be DHCP’d on your local network, you can change that setting through the browser on your client OS (we made it static on the local network). All of this is detailed in the release notes availabe on the VE page of DevCentral.
After your VLANs are set, then you need to go into the client OS’s and set the route to point at the BIG-IP address on the internal VLAN. Bing! At that point you should be able to ping the world. If you can, then you can create the nodes, pools, virtuals in the BIG-IP and start routing traffic!
I won’t go into a ton of detail here, since this article is running long already, but here are some screenshots of BIG-IP LTM VE with everything configured.
Here’s the list of nodes as-we-added them…
And the shots of the pool, showing it using these nodes…
And the VS, showing it using the pool. All is set, the VS is listening on 192.168.42.110.
There’s more I’d like to show you, but I’m not only out of room, this is longer than I’d wanted. So go forth and play, and I’ll circle back with some fun stuff like setting up iRules and such.