vRealize Network Insight Overview

"It's the network!" seems like the battle-cry for some server teams.  I come from a system administration background; I get it.  When all of your services are running and the event logs look clear, it must be something external to the system... which is either the network, or something is being talked to through the network.  I've seen so many server guys chant that mantra, toss the problem over the fence and then wash their hands of the whole situation that I want to scream.  That said, I've also been in plenty of situations where I've brought a problem to the network team, asking them for help when I can't find anything wrong with a system.

One reason I like to go to the network team when I have a seemingly intractable issue is perspective.  Within a single server, I can drill down deep and get a good idea about what the applications on that server are doing, but it's much more difficult to get a picture of a whole solution.  The network team, with their delphic wisdom, are able to see what's happening between my servers and can frequently point me at a problem that I didn't even know existed.  vRealize Network Insight takes that network perspective and packs it up into an interface that's so simple, even a sysadmin can do it!

So, how's it do that?  Well, it basically aggregates data from routers, firewalls and switches (both physical and virtual), then stitches that together into a single interface.  To enable this action, VRNI is distributed in two virtual appliances, a Platform Server and a Proxy Server.

The Platform Server runs the show.  It hosts the database and runs the interface and it provides a common place to interlace data from anyplace, with speeds from hyperspace and a nice, soft pillowcase... ok, that's enough of that.  But, you get the point, it's the central point of the solution.  The Proxy Server, on the other hand, is responsible for actually collecting the data from all of the endpoints and then funnels that data into the Platform Server for processing and presentation.  Depending on the size and topology of the environment, there can be multiple Platform Servers, Proxy Servers, or both.  In some environments, such as a remote datacenter, it might be advantageous to deploy a Platform Server in the primary datacenter, and then one Proxy Server in the primary datacenter and another in the remote datacenter.  Why, you ask?  Network flows.

The Proxy Servers collect a ton of data.  They collect data from vCenter, from ESXi hosts, from the NSX Manager, from physical network devices... basically, they need to talk to a lot of different devices.  Rather than punching all of those holes in the firewall to allow the remote devices to communicate back to the main datacenter, we can aggregate their data with a local Proxy Server and allow that one network flow between the datacenters.

So, what network flow is that, exactly, and as an ancillary, what network flows does the solution need overall?  Well hypothetical strawman, I'm glad you asked.  I've put together a table of the required network flows for vRNI - it'll answer your questions nicely!

Source Destination Port Notes
Admins Platform Server HTTPS:443 User Interface
Proxy Server Platform Server HTTPS:443 Data Transfer
Proxy Server, Admins Platform Server SSH:22,HTTP:5480 Troubleshooting
Platform Server, Admins Proxy Server SSH:22,HTTP:5480 Troubleshooting
ESXi Hosts Proxy Server IPFIX:2055 Data Collection
Proxy Server vCenter Server, NSX Manager HTTPS:443 Data Collection
Proxy Server NSX Edge, NSX Controller SSH:22 Data Collection
Proxy Server Most Network Devices SSH:22, SNMP:161 Data Collection

VMware has also published a very helpful User's Guide that explains how to actually use the product to find the data that you're probably interested in finding; it's definitely worth a quick read through.

Comments

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

Clone a Standard vSwitch from one ESXi Host to Another

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host to another.
Read more

PowerShell Sorting by Multiple Columns

PowerShell's Sort-Object cmdlet is super useful, especially when preparing output for human consumption.  A few people have found my blog while looking for more information about its use, specifically while looking for how to sort by multiple columns (well, properties, technically).  I've never done so (much less written about it), so I hope those folks found answers elsewhere.  But, it got me curious... and it turns out that it's really easy. The Technet article on Sort-Object has the answer directly spelled out: just use commas to create a list of properties to sort by (in order to precedence).  Let's look at some examples!  First, prepare a variable with some good sortable data: $myData = get-eventlog System -newest 25 And then we can get to sorting!  Say you want to sort primarily by EntryType (Warning, Information, Error) and then by Source.  Easy-peasy: $myData | sort EntryType,Source How about if you want it to be in descending order?  Yeah, there&
Read more

Deleting Orphaned (AKA Zombie) VMDK Files

A problem that most Virtualization Administrators need to deal with is Orphaned VMDK files (or Zombie VMDK files, as some people call them).  These are Virtual Machine hard drive files that are just hanging out, taking up storage, but are attached to no VMs.  How can this happen?  Well, the most common way is when an administrator needs to delete a VMDK but isn't quite ready to commit... so, after pressing "remove", they select "remove from virtual machine" rather than "remove and delete files".  The intent is always good: "I want to be able to restore this if it turns out to be necessary... so I'll just come back and delete it next week if nothing breaks!"  But, of course, next week something else happens and the file doesn't get deleted.  After a little while, it turns into "which files did I rename, again?" and nothing seems to happen. So, how do you deal with these orphaned files?  Well, a few years ago I found a scrip
Read more