Here is a new twist on an old friend. The Avanu WebMux line of hardware load balancers has been around on the approved list since, IIRC, OCS 2007 R2. Here is the ancient link to that listing. The Webmux is also on the Lync 2013 OIP listing.
Avanu offered to let me try out their hardware and virtual appliances; so naturally, I jumped at the opportunity. Avanu first sent me a piece of hardware, an A500XD, which I will not specifically make detailed comments about, other than these two semi-humorous notes.
- OMG, I have a 747 in my office! This thing needs to go into a server room, or at least away from me!
- Power Supply out/failed tone. The alarm will wake the dead. Removing the failed/disconnected power supply turns off the zombie alert, leaving you with just the 747 taxiing out for takeoff.
The A500XD oozes build quality. A very nice piece of gear from that perspective. And wicked fast. But, I am living in a mostly virtualized world, so Avanu sent me their virtual appliance, which they assure me (and I verified) that the interface and operation aspects of the virtual match that of the physical hardware. So the remainder of this short article will focus on the virtual appliance and how it might work with Skype for Business Server 2015 in your environment. You can do some light reading on the Avanu Virtual WebMux here.
Network Environment
Here is what we are going to walk through:
Pretty simple, yes? Even so, Avanu has provided their WebMux with a set of wizards that will do most of the work for us. So, first, let’s step through the basic networking of the applicance to get it into the environment, and then we’ll take a look at the wizard for SfB to see how that functions.
After downloading my VMDX/VMX files, and opening them with vmware, we get our first look at the virtual appliance.
I sent a quick note to the fine folks at Avanu tech support over the size of the disk… seemed small to me. But, this is correct. Very small footprint. Makes me wonder what the other vendors are doing that requires all that drive space.
But wait, it gets better. No DHCP support, so the WebMux comes up on static addresses…192.168.11.21 and 192.168.12.21 to be exact. But which interface is which? I learned more Linux figuring that out. What you get in the vmware console is this:
Not exactly helpful for someone trying to figure out IP, eh wot? But, in the best sysadmin tradition, I persevered. It turns out that “ifconfig ethf0” and “ifconfig ethb0” gave me the existing IP (which are listed in the documentation)(but, which to paraphrase Alfred E. Newman, “What, me read?”) Ha! For you intensely curious types, I have vnet0 set to the 1.1.1.0 net and vnet7 set to the 10.10.10.0 net, and those are set to the first two virtual NICs for the WebMux vmx…
and
All of that got me to the web-based UI, so that humans (not to be confused with Linux admins) can configure the WebMux. There is a CLI available that can whip the WebMux into shape, but dang, I am Mr. Visual. So, we got to the GUI.
Basic Setup
You may note that I took this screen cap after I set the IP up to match the actual network. And oh yes, you will need to educate yourself on the various network choices and their definitions. You mean you did not read the link up above? Here it is again but focused this time on the “Arms and Architecture” section. If you are following along (and reading the (*&%$ doc) note that the “two-armed server LAN NAT” selection REQUIRES you to have the WebMux be the GW for the farm real servers. Note down below that I chose 1.1.1.2 for this – not a real address for anything else on my net, and one that the WebMux can float between HA instances if need be. But, if your first efforts fail, remember that I told you to set the real server gateway to the WebMux impersonated IP. I will wait whilst you digest that statement.
OK, so we need to choose “two-armed server LAN NAT” – got it. And all the rest should be fairly obvious; well, it was to me.
With that out of the way, and after the reboot, let’s take a swing at the aforementioned wizard configuration.
SfB Wizard Configuration
I am going to choose the “Skype for Business” option..
This is so easy, even *I* got it right the first time…but here goes.
On to Step 2…
Step 3…
Step 4…I am a solo, no HA…so it looks like this:
Step 5…
Step 6… I don’t use the Monitoring Port, so I will use the default…
Step 7… Submit the configuration. Yes, part of this will simply duplicate my network configuration work, but if you don’t get access to the WebMux in the first place, then you could not have gotten to this wizard unless you went through the “change the IP on a workstation” bit… chicken and egg scenario, but that is what we have to work with!
oh my, it’s rebooting!
And here we are:
Pretty slick. If this meets your needs because your firewall is doing all the port redirects for you, then perfect. But what about the aspects of internal versus external? I just did the external…and I need the 443 farm to be on the 1.1.1.0 network and the external to come in on 443 and attach to the real servers on 4443.
Looks like the wizard might not be what we want, eh? So we’ll have to do this manually! Oh joy. Luckily, this turns out to be dirt simple.
Manual Setup for SfB Basic Stuff using Two Nets
First, I blew off what the wizard put in for me. I did not like it, and it only did my external stuff. When I tried to run it again for the internal, I got only internal. The reason seems pretty simple; the wizard appears to be doing the entire WebMux configuration and once things are in place, running the wizard again appears to re-configure. Ooops! Well, no matter, I want more control anyway. And specifically, 90%+ of my workings will have an external facing subnet and an internal facing subnet, with certificates in both directions, so I need to know how to do this thing manually anyway. And then wata-shi-wa get’s to be in control. I am all about control My SO says TOO controlling, but I let her go shopping every third month, so I think she is over-reacting. Adelante!
Here is what I ended up with and working as expected:
A regex note
To do content redirects, you will need to get some content rules. Here is where things get a little different – just like all developers everywhere, “they” followed a different “standard” so things look a bit “off” from what I am used to.
You want to do a host name filter you should use the "layer 7 host MIME header perl regex match" field since the host name requested by the browser is in the host MIME header of the HTTPS request. The URI regex match field is for matching strings following the host name portion which you don't need in this case.
An example of a match pattern to allows all hosts in a specific domain would be: ^.*testing\.com$
That will allow all hosts for the domain "testing.com" to pass through that farm.
While putting together the virtual servers, keep this in mind:
- Each IP/Port combination must have it’s own virtual server.
- Real servers MUST have their gateway set to the core IP of the WebMux
- WebMux must be in Two-Arm NAT mode
- When adding a farm, choose “service: generic no health check (TCP)”
- The farm gets the core port, the real server gets the tranlated port (443 –> 4443 in the case of SfB)
- If you want to do SSL other than a straight pass-through, you will need to remember that WebMux is a linux box, and it acts like one. Holy moly! To get your cert up into the WebMux is going to be pulling teeth. I suggest you call them – the most excellent support folks up in WebMux-land were very helpful – and will do all the work for you if you wish. You can read up on it here: http://avanu.com/webmux_ssl_certificate/
Conclusions
The WebMux, even in virtual living on my strapped-for-resources lab, was wicked fast. Really excellent throughput and admin response. The linux-based certificate goat-rope exercise was a royal PITA; but the Avanu folks are very helpful with working it through. The WebMux is very granular. Planning before jumping off the cliff is strongly recommended. Did I mention the WebMux is wicked fast?
YMMV
No comments:
Post a Comment