Monitoring Interopnet With Glenn Evans, Chief Engineer (part 2 Of 2)

Monitoring Interopnet With Glenn Evans, Chief Engineer (part 2 Of 2)

By:




With 100 pieces of equipment from over twenty different vendors, theInteropNet 2011 will be one of the most ambitious and complex InteropNet builds to date. We asked the man responsible for it, Glenn Evans, Chief Engineer of the InteropNet, about how he plans to monitor this massive project:

Q: What kind of metrics are you collecting on the InteropNet?

A: We rely on the providers to some degree. We ask the people who are providing the equipment: 'What is the best practice? What sort of best-practices recommendations do you have for managing and monitoring a network core system?' To some degree, we pick the vendors' brains, asking them: 'This is what we want to achieve, what's the best way to do it?'
We certainly look at overall bandwidth usage. Overall client "end-to-end performance" how is the information being transited through the network? We also look at monitoring for any sort of security threat or abnormal traffic on the network. Because we're providing service for a large number of people, we also look at uptime statistics. We're taking a bit of a green approach so we're monitoring our power statistics as well. A pretty good metric for a datacenter is: 'How much power are we using?' vs. 'How much traffic are we pushing?'
We meter and monitor from the ground-up, so we're looking at everything from the power right through to bandwidth usage and application performance.

Q: How do you use these reports to improve the InteropNet?

A: We primarily use monitoring for problem solving. If we have an issue, and we know we can put a certain device in there that will stop the issue, that's certainly one use of all that information. For planning purposes it's more: 'What's the best place to place particular services? ' Obviously, these days there's a big push for cloud or virtual datacenter, or whatever you want to call it. So does it make more sense to push up some core services out into the cloud, or do you need to keep them local? And that's really based on performance statistics that you've gathered over time.
We use a private-cloud environment. We have our own datacenters which are hubs or data points from the show floor out to the Internet. Within those locations, we've positioned some services that are available all-year round, so the respective vendors can get access to statistics from the show, and use that for sales presentations, and for demonstrations and stuff. Because the InteropNet is, primarily, a demonstration network.
One of the benefits we provide is to monitor, meter, and gather statistics. We can then present that to vendors' clients year-round. And that's sort of one of the benefits of using a private datacenter. We can move some of the centralized management platforms that gather the data from collectors into those areas.
We also have some of our voice services, when the show's operational; the primary service is coming out of the show floor. But when we're not operational, we move over to the to the datacenters, so we've got some of the basic infrastructure available to us all year round.

Q: Is this very different from past years?

A: This is a more recent trend. We started using these datacenters, or 'the cloud,' or whatever you want to call it, about three or four years ago, which is when people started realizing: 'Hey, we don't need to put all our equipment down in our local environment.' As time's gone on, we've put a toe in the water to test things out, to ask if it's going to work for us, and we found out, yes, it would.

Q: How do you use dashboards at InteropNet?

A: Dashboards are only as good as the information that they get, and how it's presented. Every manager - every person - wants to look at the information a slightly different way. It's more related to their particular viewpoint of the world.
We use the dashboards in a couple of ways, and we take our inputs from a number of different areas. We use SysLog, SNMP polling information, and NetFlow or sFlow information. We combine them to give us a good overall picture of what's going on in the network at any given time.
Plus, it also lets us gather information over periods of time so we can review that at a later date and make decisions on what did and did not work. We had a problem - was it a basic design flaw or was this some sort of anomaly that we need to cater for in the future?
I use it to get an immediate snapshot of what's going on at any given time, so your typical up/down, on/off, or 'Hey, guys, we've got a problem.' But I also use it for trending information - seeing the peaks and troughs of traffic flow and when people are getting on. That allows us to some degree to plan our wireless deployments more effectively. We can see if we need a bit more coverage or a bit more radio coverage to a certain area. We use the dashboards in a number of different ways.

Q: Is it important to show dashboards to Interop attendees?

A: I think it's one of the elements the attendees like about Interop and the InteropNet - that they actually get visibility into what's going on in the event environment. Now they can see that there's X number of wireless users on the network, they can see the overall bandwidth statistics we have, they can see the traffic flows - and they can also see the problem. We're actually quite open about problems. And we invite them to ask questions: 'Why did you do it this way? I notice you seem to have a red light here, what's that about?' For us, it's all part of the attendee experience.

Q: How is InteropNet monitoring their power usage?

A: We have the capability for SNMP monitoring, and we have a number of management platforms that attach to that information and provides statistics. We do that from physical datacenter software right down to physical management platforms, and we're getting information all the time about how much power each particular rack is drawing - or even how much each particular piece of equipment is drawing. We gather statistics on all of that.
We can then work out how and where we can drop our power requirements. Can we go for a smaller power feed, can we make it more efficient, do we go from 110 to 208 volts, (and then theoretically drop the current down and get some power savings?). We pay for power on the show floor to connect all that stuff, so lower current lines do provide some cost savings for us. Even though InteropNet is only on the show floor for a week, the same principles can be applied in a normal datacenter.

Q: How are you addressing IPv6 this year?

A: This year we are going full IPv6. The network will be dual-stacked - both IPv4 and IPv6, both wired and wireless. All our backend server platforms and systems are dual stacked. DNS is IPv4 and IPv6 capable. We're using stateless autoconfig, as well as DHCPv6 on the show floor. That's our primary way of doing it, we can just dual-stack everything. We're also doing some demonstration areas which will be IPv6 only, and we're also looking at setting up an area that will be NAT 6to4. The whole idea is just to show the attendees some different IPv6 deployment models and some of the challenges and issues they may have with each of those systems.

Q: How does ScienceLogic help you build and maintain the InteropNet?

A: It gives me the snapshot and long-term information I need at any given time to allow me to better manage it, from an operational perspective, but it also provides me with the ongoing statistics and information to better plan and project into the next show cycle - the next network we build.

Q: What role will ScienceLogic play in 2011s Interop?

A: We actually have two vendors doing the environment. ScienceLogic is monitoring the show floor and the cloud monitoring, and the other company is doing the off-show floor conference space. This was all based on the principle that, with 2011 being the 25th anniversary, it was all about going back to our roots and going with multi-vendor interoperability. That was the prime reason for two solutions.
I think at this time, ScienceLogic has a strong cloud presence and a strong cloud story. Historically, they've proved that they can do the job.

One of the things we're looking at with ScienceLogic this year is expanding our metering and monitoring points, where, historically, we've gone with just SysLog information and SNMP polling and traps. This year we're also using the sFlow engine to provide us a better insight into the real time data, and hold that for the ongoing analysis. That's one of the biggest changes in the way we're metering this year.

About the Author:
A self-described "technology-humorist," Brian Boyko is a skilled wordsmith and has a habit of figuring out new ways of looking at tech issues that get people to think. He's an avid blogger for ScienceLogic, a provider of IT operations management and cloud monitoring solutions.



Article Originally Published On: http://www.articlesnatch.com


Tags:

|

Loading...
Related....
Videos...

Recent Computers-and-Technology Articles

Comments

Still can't find what you are looking for? Search for it!

Loading

Site Navigation:

Copyright 2005-2011 ArticleSnatch, LLC - All Rights Reserved.
Privacy Policy | Terms of Service.