Managing a virtualized infrastructure requires visibility across all layers of your environment – from VMs down to the physical systems and storage that supports them. Please join SolarWinds for an integrated product demonstration of the new Virtualization Manager and Storage Manager products and learn how to achieve success in these environments.
NA/LATAM-Thursday June 16, 2011 @ 11:00 AM CDT
EMEA- Thursday June 16, 2011 @ 1:00 PM GMT
APAC- Wednesday June 15, 2011 @ 11:00 AM SGT
In Part 1, we discussed the different management protocols and methods that are used to manage, monitor, and measure application and system health and performance. If you missed Part 1 you can watch the recorded version here.
During part 2 we’ll dive deeper into some of these technologies and demonstrate how they are commonly used within management applications. Specifically we’ll be discussing:
We’ll be leveraging the SolarWinds Application Performance Monitor (APM) among other tools to demonstrate these technologies and facilitate the discussions.
As you might imagine, we here at SolarWinds get to talk to quite a few folks in the IT world, and we hear many interesting stories and product uses. I wanted to share one particular anecdote with you as it really does seem to be a nightmare scenario for some of our customers.
No one in IT is a stranger to digital piracy. It has been happening on a small scale since the days when floppies were the norm. Now that we’re all online, it’s a much different story. With the advent of simple peer-to-peer software and some moderately fast transfer speeds, the rate at which files spread has increased dramatically in the last 10 years. One of the first items to be shared so widely in this fashion was music. The mp3 standard was perfect for this, as the small file size and the population’s desire to fill their new portable music players created an environment perfect for song swapping.
Early file sharing systems like Napster and Audiogalaxy proved wildly popular, but used a centralized model which gave industry watchdogs like the RIAA an easy target for lawsuits. As these sites were shutdown, Internet users and music lovers still yearned for a cheap and easy way to fill their mp3 players. iTunes was still gathering steam, and there were not yet any other viable commercial vendors who could offer enough music to satisfy the audience. Still leveraging the convenience and power of peer-to-peer file sharing, decentralized versions were created, with the BitTorrent protocol emerging as the most popular. Lacking a central server to query, this method of file sharing was not quite as easy to use as its predecessors, but rapidly gained popularity with savvy users. An important aspect of this model was that there was no longer a central entity with which to threaten a lawsuit, once wrongdoing had been established. Since the connections were all ad-hoc, no one was “in charge”, and it became very difficult to pin the blame on any single entity. This also makes it very difficult to stop.
A new strategy was required to combat this decentralized style of file sharing. In order to focus their efforts where they would have the greatest effect, groups like the RIAA began to analyze the p2p traffic. They were looking for tech savvy people who shared many files, and enjoyed fast Internet connections. Universities fit the bill, and had the added benefit that they would be sensitive to government pressure and laws. Through lobbying efforts, the Higher Education Opportunity Act of 2008 included several provisions that represented the ongoing pursuit to curb illegal file sharing on campuses. Each campus must annually distribute information detailing copyright law, and the penalties of violation. They were also directed to describe their policies and disciplinary actions regarding unauthorized peer-to-peer file sharing, in addition to tracking down the offenders that are discovered. It is this last item of assisting investigations that represents a technical challenge to the IT staff.
After receiving a DMCA notice, it is up the IT staff to track down and then serve the notice to the individual responsible. Oftentimes, only the public IP address and port are given in the notice, and this must be translated to a person. We’ve heard of several different methods to discover the internal IP address that corresponded to the public IP and port, but there is one final step they all face. The internal IP address must now be traced back to an individual person. Unless the institution requires registration of all devices, this can turn into a daunting task of wading through log files. This is where our software is saving people time and money. User Device Tracker keeps historical information about the devices on the network, and can correlate IP Address, MAC Address, and Hostname. With this data at one’s disposal, it is a trivial matter of looking up the history of an IP address to see what MAC or Hostname was behind it at the time. We're happy this function is saving our customers so much time and energy!
Would you like to see how easy it can be to keep tabs on your network with User Device Tracker?
I hope this blog post will clarify a few things about this feature, that you need to know in order to make it work.
This will ultimately be incorporated into the product documentation, but since we saw several users being unable to make it work to their satisfaction, we decided to get this information out, before the documentation update.
Before we start, let me remind you that NCM covers only limited user tracking use cases. A more complete list of use cases and much more powerful features are offered by the recently released product UDT. Mav has released a very informative blog post to explain the positioning of the several features and tools available in this area, Finding where devices are connected in your network.
This feature is available on the NPM Integration module of NCM (therefore it requires NPM).
It also requires to manage both devices involved in the connection and the pair of interfaces involved in the connection.
For example, if you want to find-out where your workstations are connected to your switches, the workstations have to be discovered and managed by NPM as well as their interface involved in the connection. The switch and its interfaces have to be managed as well. It is not necessary to import the nodes representing the workstations in the NCM database.
Users also ask sometimes about the level of management required to make the “NPM Network Topology” chart work:
Re-using the same example as above (workstations connected to switches), this feature does not require workstations to be managed at the interface level (they require licenses for PC’s at the node level only, ICMP-only management is sufficient)
I am excited to share with you a great utility that should help you creating (and sharing) device templates for your NCM 6.1!
This utility is basically a wizard-looking assistant that will guide you through the creation of new device templates or to modify an existing template. This first version deals with downloads only, but if the community likes it, we’ll improve it.
It hides from you some of the complex syntaxes that we have to deal with, when designing a device template and it outputs the template file.
Once created, all you have to do is:
Here are a few snapshots of this utility…
Just unzip and copy the 3 files in any directory on the machine that has NCM 6.1 installed (NCM is required).
The 3 files need to remain in the same directory.
Execute the “SolarWinds.NCM.TemplateAssistant” executable.
We believe the utility is simple enough to be used without documentation, but these tips might help you getting started:
You can also look at this video illustrating basic usage of the assistant.
As you have noticed, this utility is provided on Thwack, therefore it is provided “as-is” and is not supported.
Please find here a reminder of the EULA for all Thwack content: http://thwack.com/optin.htm
However, we would be happy to hear your comments and feedback. Please post as responses to this blog, and we will improve the utility on a “best effort” basis!
In case you haven’t heard yet, we have just announced a new product, User Device Tracker. This product helps you quickly find where a machine is connected in the network. We sometimes get questions about the difference between our other solutions for device tracking. To read more about that, see my Finding where devices are connected in your network. We have had a very positive response from our early adopters and testers. Some of the requests we’ve received are things we are working on building into the product, but I want to take a moment to share with everyone some of the more handy tips and tricks.
1. Change the type of interfaces that count for capacity
By default, UDT will use the following types of interfaces for capacity analysis: ethernetCsmacd(6), propPointToPointSerial(22), ppp(23), propVirtual(53), propMultiplexor(54), fibreChannel(56), fastEther(62), fastEtherFX(69), channel(70), gigabitEthernet(117), hdlc(118), l2vlan(135), l3ipvlan(136), pos(171). If you want to change this so that you will collect interface types that you are interested in tracking capacity for; delete the node (if you already added it), stop the Orion Module Engine service, modify the SolarWinds.UDT.BusinessLayer.dll.config file and update the UDT.MonitoredIfTypes values to include only the types you are interested in.
For example, the list of ifTypes can be changed from this initial list, to this second list:
<add key="UDT.MonitoredIfTypes" value="6,22,23,53,54,56, 62,69,70,117,118,135,136,171" />
<add key="UDT.MonitoredIfTypes" value ="6,56,62,69,70,117" />
After you update the list, you will need to start the Module Engine service and re-add the nodes and relevant ports. You capacity analysis charts should now include only the IfTypes you are interested in.
2.More custom reports
UDT only has 1 out of the box report. Yes, we realize we need to do more. However, with all of the exciting new data we are collecting, customers are anxious to get access to it. Our developers have put together a few custom SQL reports and I placed them on the content exchange. In the future we would like to fully extend the schema so that these types of reports are easy for customers to modify and run on their own.
3. Finding machines with suspicious hostnames
UDT has a feature called the Watch List. The Watch List allows you to specify a machine that you are interested in keeping an eye on (maybe it is lost, or a recurring problem machine). You can quickly see where all of your Watch List items are connected in the network by looking at the list, or you can schedule a report to be sent daily so you can see when one of these machines connects to the network. Some people are excited about the potential for this set of use cases for rogue detection or unauthorized computers on the network. A quick (read hack) way to do this is to create a Custom SQL Report that looks for a specific pattern to match. For example, if I know that all of the computers at SolarWinds should start with “Solar”, I can create the following custom SQL report for all endpoints that DO NOT start with “Solar”:
select * from UDT_DNSName where UDT_DNSName.DNSName not like 'Solar%'
4. Integration with NPM and the difference between a port and an interface
Out of the box for v1, we wanted to have tight integration with our existing products. UDT can be installed completely independent of any other products, or it can be installed like a module with NPM. When it is installed with NPM, it will use the same database and you can simply run Port Discovery on the nodes you are already managing in NPM. Several resources are added to the Node Details View: Ports Currently In Use on Node Name, Port Details, and Ethernet Ports Used Over Time. If you install UDT standalone, you will still get these resources, but if you install with NPM, you get the benefit of being able to have the Network Management, Connection, and Capacity Analysis information all on one screen. You may then notice that there is a Port Details resource in addition to the Current Percent Utilization Interface table. This begs the question, what is the difference between a port and an interface? This is primarily a naming convention to make it easier to keep separate the different way these are licensed. An interface is an NPM construct that we collect utilization information about (bytes in/out, percent utilization, errors and discards, etc.). The interface impacts your NPM license count. A port is a UDT idea. When you have a monitored port, we will collect connection and capacity analysis information about that port and it will count against your UDT license. Here is a quick side by side graphic of the difference between ports and interfaces.
Some users get concerned when they learn they need to monitor all of their ports in UDT. This does not impact their NPM license at all. Take the example when you are monitoring the uplink interfaces in NPM on one 48 port switch. This should be 1 node license and 2 interfaces. When you add UDT, you will need to add the 48 ports that will count against the UDT license, but your NPM license will still be just the 1 node (since you are already monitoring the node) and 2 interfaces.
5. Deleting versus un-monitoring ports
This is more of a clarification for users who want to better understand the difference between deleting a port and un-monitoring it. Well you can’t actually delete a port in UDT (don’t worry, we’ll get this fixed in the future). If you want to permanently delete a port, you need to delete the node, the rediscover the ports and only select the ports you are interested in. If you select a port to unmonitor, we will not collect connection information (and it will not count against your UDT license), but we will still count it for capacity purposes.
For more information about UDT and to download a free 30 day eval, go here: User Device Tracker.
We have been super busy in the free tool department. We just launched two over the past few weeks.
1. Real-Time AppFlow Analyzer - This new tool captures and analyzes AppFlow data in real-time, making this powerful diagnostic data available at a glance. Want to know who is sending all the traffic to your web applications? Or if slowdowns are on the server or client side? AppFlow makes this information available, at a glance.
2. SAN Monitor for EMC Clariion - When our popular San Monitor launched, we got a lot of positive feedback , as well as a lot of requests for a similar tool to monitor other types of SANs. We heard you, and voila - the SAN Monitor for EMC Clariion was born.
In addition to these tools, we're working on several more, with several more on the road map. We always want to hear what you think about our free tools and your ideas for new ones, so please review them, send me a message with your ideas, or post on thwack.
We spend a lot of time in the network world keeping track of data, hostnames, and IP addresses. Everything we could want to know is only a few mouse clicks away, except perhaps where our devices are physically located. User Device Tracker bridges the gap between the network and the physical world. It sniffs out each device on each switch port, just waiting to let you know where something is, or where something was. Tracking down a rogue device or anything naughty on your network has never been easier. Historical data shows you where a device was last seen, so you can find that long lost laptop. Switch capacity and utilization is consolidated for easy viewing. Come and see what SolarWinds User Device Tracker can do for you!
This blog post shows how you can configure your Orion IP SLA Manager module to verify whether or not your Communication / Internet Service Providers (CSP/ISP) delivers what they “promised” to you.
If you have a formal Service Level Agreement with them, it’s likely their commitment to you is about availability of the connectivity, but also packet latency and packet loss across the site to site connection (typical commitment from CSPs), and throughput (typical commitment from ISPs) of their access.
Well, if you don’t have a formal agreement (SLA), I think the info below is still a very good best practice and can be used as a solid basis for informal discussions with your CSP about their quality of service, also whether you should think about buying faster throughput from them… It can also provide great data to help you improve the design of your network in general and your WAN in particular, regardless of any I/CSP relationship you may have or not.
So, whatever your situation and objective is, let’s look in details at these 3 metrics.
Cisco’s IP SLA does not natively give information on the throughput experienced by the operations, as they perform their packet generation tasks (therefore Solarwind’s IP SLA Manager module does not either).
But there is an easy way to work this around (manually) and get this precious information about the throughput that your SP connection effectively delivers.
In order to achieve this, just create an IP SLA “FTP” Operation that will periodically perform an FTP GET between any FTP server and an IP SLA-capable router. Orion IP SLA manager will give you a chart similar to this one, showing the time it took to perform the file transfer. Great but this is not the Throughput information you are looking for.
All you have to do to get the Throughput, is apply this simple formula manually:
Throughput = File Size (Bytes) x 8 / Transfer time (Sec)
Let’s do the math on this actual example. The spike in the middle of the chart shows that for 1 hour, the transfer time of this 337KBytes file was around 4000 ms (with a spike up to 10,000 ms).
Throughput = 337,000 x 8 / 4 = 674,000 bps = 674Kbps… for a connection sold as a 1Mbps…
For 1 hour, I did not get my share! And look at 8am when the business day starts…
If this happened too frequently, I would certainly pick-up the phone and call my I/CSP…Especially if I hear my users complaining about slow response time at the same time…
Of course, you don’t want to blame your I/CSP too rapidly and you should make sure that you select a Router which is as close as possible to the connection to your SP. And chose an FTP server which is as fast and consistent as possible (hopefully dedicated to this task), to eliminate any component that would be responsible for this and not be under your I/CSP’s responsibility.
To achieve this, you can either deploy an FTP server dedicated to this, or ask your SP whether they can provide one in their domain, or pick one like I did (Cisco page) and hit it from several locations:
Here is how, in a few snapshots, you can create this FTP operation with IP SLA Manager:
All Orion IP SLA Manager users commonly use their module to monitor Latency on a near real time basis and be alerted about bad latency, but not all use the historical reporting capabilities of Orion to turn this into an SLA verification tool.
On this example, you can see that during May, the committed monthly average of 10ms for packet latency is not met.
To create this view, this is what you have to do:
The same historical report can be done with Packet Loss, using the same technique.
Then, this blog can help you leverage Orion IP SLA Manager to show your customers that you DO DELIVER!
Orion supports account limitation and can be used to push these reports to your end-customers in a safe and secure way, and deliver a simple but effective customer-facing Service Level Reporting portal!
What sessions will you be attending at this year’s VMworld Las Vegas? Vote now through May 18 to help determine the content!
SolarWinds submitted the three sessions outlined below. Please take a minute and show your support by giving us a “Thumbs Up.”
1. Go to http://www.vmworld.com/cfp.jspa.
2. Create a VMworld log in.
3. Once at the Session Voting page, use the Search Options and enter SolarWinds in Keywords.
4. Click on the “Thumbs Up” symbol next to the Session ID and description.
5. Thanks in advance for your support!!!
One of the additional things we’re working on is Hypervisor support beyond VMware. We are looking at Microsoft Hyper-V and Citrix Xen Server – most likely in that order. We also see more prevalence of 2 or more Hypervisors being used in some of our customers, so having a unified and vendor independent way of looking at your Virtual Infrastructure is becoming very important. If you have requests for Virtualization Manager Hypervisor support – please post them in the comments section below.
As many of you know – there is a very tight linkage between virtualization and the shared storage back end. There is a clear need to understand the virtualization layer and its dependence on the physical (and logical) storage underneath. With that in mind, we are working on linkages between Virtualization Manager and Storage Manager so that users can seamlessly navigate from the virtual to the underlying physical entities. For example, from a virtual standpoint, it may seem like a good idea to Storage vMotion this VM to another datastore – but if an analysis of the underlying physical storage shows us that these 2 datastores are sharing a common overloaded RAID group for example – that vMotion isn’t going to help us much!
Some of the additional items we are considering for future releases include:
Role Based Access Control - The ability to tie a subset of the virtual infrastructure to a user account - for example a set of clusters, or VMs in a particular resource pool or folder. By tying an implicit search to a given user, that user's scope can be restricted and all search based content (dashboards, alerts, trends etc...) should be automatically applied to only the chosen search scope.
PLEASE NOTE: We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release. We are working on a number of other smaller features in parallel. If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!
Learn about the common pitfalls that you will encounter as you progress on your Virtualization journey towards Private Cloud computing. Join SolarWinds Head Geek Josh Stephens as we discuss the changes that these Virtual Environments have caused and how they affect management best practices. Some of what he’ll cover will include:
Also during this webcast we’ll demonstrate key technologies from SolarWinds that help to conquer these challenges and ensure success in these environments.
A few weeks ago, I told you how you can use NetFlow technology to diagnose the performance of your network and see who and what are talking on your network. Now I want to share with you an additional technology that can be used to gain even deeper insight into network performance with a specific eye on WAN performance.
Using the IP SLA, a wicked cool technology as our Head Geek is fond of proclaiming, that is already built into most of your Cisco routers you are able to measure transport metrics from one device to another allowing you to isolate point-to-point performance issues. IP SLA generates time-based performance data while NetFlow generates volume-based data. An IP SLA operation is analogous to putting a test car on a highway with specific instructions on where to go and then measuring whether it gets there (availability), the time it takes to get there (latency), and the space between the cars (jitter).
Let me give you a few use cases to better explain just how IP SLA measures your traffic performance.
Use Case 1: Monitoring WAN performance
An IP SLA operation is executed every 60 seconds between routers. The operation reports back the availability of the connection, the packet transmit time (latency), packet loss and jitter. By examining the statistics that come back between each point, you can determine where you may have a WAN issue that allows you to take further action.
Use Case 2: Monitor end-to-end network quality
In this example, you create 4 different IP SLA operations to identify potential problem areas in your network. First you check the overall response time from one end-point to another end-point (852ms). Next you create additional operations that break the end-to-end response time into a series of smaller segments. By examining each independent segment as it relates to the overall performance, you can again identify potential problem areas.
Use Case 3: Verify Service Level Agreements (my personal favorite)
Perhaps you have a service level agreement with your WAN provider or maybe even internal SLAs that you need to meet. So, how do you know if those SLA’s are actually being met? Again, using IP SLA technology, you can measure your WAN performance and compare that to what you service provider is telling you. If you were a good enough negotiator and have charge-back, refund or credit rights then you may be able to recover some money if those SLAs aren’t being met. At a minimum it will give you some leverage the next time the contract comes up.
With IP SLA you can monitor jitter across various parts of your network to determine if your infrastructure can handle deployment of voice and/or video over IP.
Hopefully you can see from the four use cases just how powerful IP SLA can be for monitoring the overall performance of your network.
SolarWinds IP SLA Manager, a module of SolarWinds Network Performance Monitor, is a powerful solution for identifying site-specific and WAN related network performance issues using the built-in IP SLA technology found in most of our Cisco routers.