Resources

MSP Shares Best Practices for Performance Monitoring

Video

Join SevOne and special guest Victor Wiebe from CSC, a managed service provider (MSP), as they discuss best practices for performance monitoring from an MSP perspective. See how SevOne technology has helped IT professionals like Victor through use-scenarios.

 

Transcription:

Scott:
Welcome, everybody, to SevOne's webinar today on a managed service provider who's going to share best practices for performance monitoring. Now this is part of our Demo With Dave Series. It's a biweekly webinar series we do.

Typically, in these webinars, much of the presentation is live application demonstration of the SevOne Solution, but today, we have a special guest with us, so we're going to take a little bit of a different take on the Demo With Dave today. Victor Wiebe from CSC, a managed service provider and a customer of ours for, I think it's been at least five years now, has agreed to join us. We're going to do a little bit of a Q and A and have Victor talk to you guys about best practices for performance monitoring from an MSP's perspective. A lot of the discussion today is going to be Victor talking to you about what best practices he sees and what the elements are that he sees for effectively managing client expectations, and how performance monitoring ties into all that. I'm going to introduce Victor in just a second.

We do have Dave Hegenbarth, the original star of Demo With Dave. He's with us as well today. He's a panelist here. If there's any technical questions that come up about the SevOne solution, Dave is on hand to answer those questions as well.

I'm going to jump in real quick. Before we get started with Victor, just in case any of you who are not familiar with SevOne, it probably is a good idea to give you a little bit of a brief background in what the elevator pitch here. Who is SevOne? What do we do in a nutshell?

If you're not familiar, SevOne is a Data Center Performance Management solution. That means that we monitor, report, and alert on the performance and availability of your networks, your applications, your systems. It does not matter if we're talking about private or public cloud environments, hybrid environments, virtualized environments. We monitor it all from a single pane of glass.

Essentially, we give you the ability to prove the performance of the network and all the systems and applications related to the network. The ability to predict potential issues that may impact your ability to deliver services or applications to your end users. I guess you could say our main point here is that we help you guys prevent disruption to business due to performance issues with your infrastructure.

Now with SevOne, in case you're not aware again, we are an appliance-based solution. We deploy either as a physical or virtual appliance. That means that all of the polling, the data collection, the reporting, alerting, analysis, it's all done from a single appliance. This is not a modular solution.

Everything is included out of the box. Support for all the common protocols you would expect, whether it's SNMP, IP SLA, NetFlow, and all the different versions of flow. WMI, JMX, whatever it may be. We support more than two dozen protocols out of the box, so, again, not a modular solution.

We do believe we are the world's fastest, most scalable performance management platform. We say that because a single SevOne appliance can actually monitor up to 200,000 objects on your network. If you need to increase your monitoring capacity beyond that, it's simply a matter of dropping another appliance into what we call the SevOne Cluster Architecture. This is a patented architecture. We just recently received a patent award for this.

All the appliances work in a, I'll say, distributed computing fashion. They're all aware of the different appliances and what they're monitoring in your infrastructure. When you need to run a report, you can run a report from any one of the appliances. It's going to push out to each of the appliances a request for their part or their load of the report, their share of the report, and then return that back to the requesting appliance.

With SevOne, what you typically see is no matter how large your monitor domain is, you're getting reports back in seconds. Not minutes or hours. Our ability to scale to the demands of your network and the size and complexity of your network, and our ability to return reports in seconds, instantly, are a couple of things that set SevOne apart.

That being said, SevOne, we specialize in performance visibility for you guys. We're going to talk a lot about that visibility today during Victor's presentation here. I'm going to bring Victor on. Victor, if you want to go ahead and unmute yourself, I'm going to give a brief introduction here, Victor, through a couple of slides together.

We'll introduce Victor and then he's going to go through, talk about some best practices, and how, as a managed service provider, he gets from one place to the other and managing client expectations. Victor, go ahead. I'll pass you control and I'll let you take over the slides. I'll just jump in occasionally with some questions.

I will say, before I turn things over to you, for our audience today, one of the unique perks that you have of being on this call today is you'll get to ask questions of Victor. If anything comes to mind during the presentation, please go ahead. Use the Q and A chat panel within the WebEx interface.

Submit those questions via text. Obviously, your phone lines are muted, but please go ahead. Submit any text questions you have. We'll try to introduce those questions to Victor as we go, or certainly, if not during the presentation, by the end we'll have a little Q and A session. Victor, I'll turn things over to you. Thank you for joining us today.

Victor:
Okay. Thank you for that. Good afternoon, everybody. Just to give you a very brief introduction of where I am right now, when Scott asked me to put this together, I was not sure if I had 30 minutes or 60 minutes or somewhere in between, and then he just took up the last 10 minutes of it. Thankfully, I am jazzed up in a little bit of coffee, so I can get this done pretty darn quick.

This is who I am. My name is Victortor Wiebe. I have worked with CSC, formally called Computer Sciences Corporation. I have been here for 15 years, working my way up through the ranks, in fact, directly out of college. For the last 10 years of that, I would say, I have been in the IT development business.

What we expect our applications and services to do for us, what we expect our off-the-shelf applications to do for us, is 80% of our clients' needs. We have a team, which includes myself, that is put together to meet the remaining 20% that an off-the-shelf solution cannot support. We have used a variety of performance management solutions in my time here. We have used a number of fault management, we have used agent based, we have looked at agent lists, and we have touched on a grand number of things.

As Scott had pointed out, we have been using SevOne for the last five years now. It has grown from a deployment managing about 20,000 objects to, I think we just recently broke the million-object mark not that long ago. Should anybody wish to get a hold of me after the fact, you could find me on LinkedIn. It's very simple. I am Victor Wiebe on LinkedIn. I am very easy to find.

We are a managed service provider. We have roughly 50 or 60 clients that make use of our services. What I've discovered in the last 10 years, 15 years doing this is is that every client that comes to us has a number of expectations just walking in the door to talk to you. Some of them are easy, some of them are not so easy, and some are difficult to fulfill, and some of these, the client isn't even thinking about.

The easy expectations to meet are the very simple, standard reporting capabilities. People want to see time series type data either in a chart or graph format. They want to be able to see this using custom time frames, using default time frames, and they definitely want to see it on demand. They do not want to have to submit a ticket or wait. They want their data available right now.

The same can be said for TopN reports, capacity planning reports, capacity projection reports. These are types of things that users just expect by saying hi to you. As soon as they say hi, they're expecting to be able to see these types of things. Those should be easy for any service to provide. If it's not easy to provide that type of report, then I think there's definitely an issue that needs dealing with.

Now the not so easy expectations stem around the health of the environment, or the big problematic challenge for me are availability SLAs. The reason that those are not so easy is everyone has a different idea of what's healthy and everyone has a different definition of what's available. I did have one client who expressed to me that it was perfectly acceptable for their network to have up to 10% errors in it. They did not want to be notified unless anything in their environment went above 10% errors. To them, anything below 10% was healthy.

Now that might change. That was 10 years ago. The world has changed, and they're probably not thinking the same way now, but the same can be said today for jitter and latency. Depending on the environment, latency could be anywhere between 100 milliseconds to 300 or 400 over a microwave length.

Availability SLAs are really difficult to pin down because availability does mean something different to who you are. If you are a WAN engineer, your definition of availability is going to be very, very different than if you are an application engineer. The application engineer might view availability as, "My ability to reach the application," whereas the WAN engineers is just saying, "My device is up and passing traffic, and my responsibility stops there."

Now another expectation that typically isn't thought too much of but is always there in the background, or what I call these hidden expectations, the first one is separation of data. If you are a managed service provider, there's a good possibility that you will, at some point, provide a service on the same set of hardware to two different clients.

The standard example is Coke and Pepsi. If you're Coke, you don't want Pepsi to see your data, and vice versa. Even if you're not a competing customer, you might want to separate your data internally as well. If you're an engineer that supports one particular region, you might really not care about what's happening in a different region, and you don't want their data to start interrupting yours.

Another expectation that many people have that they just don't think about or don't bother to mention because it shouldn't need to be mentioned is data integrity. They want their data to be available when they want it available on demand. It is incredibly frustrating, and I have come across this both as a supplier and as a user, to look for data just to find that it is not there. Our clients are expecting their data to be available 24/7. The last expectation is ease of reporting and ease of using the infrastructure. If the data is available but it's not easy to get to, users become very frustrated with you anyway.

From a backend point of view, the administrators of the tool also have their own sets of expectations, and these become a little bit exemplified for a managed service provider. Some standard processes such as adding devices to management, modifying them, removing them needs to be as simple as possible. The longer or the more difficult it takes your administrators to perform their day-to-day functions, the more the tool ends up costing you from a TCO aspect.

Report modifications both for administrators and users need to be as simple as possible. The longer it takes, either you're using more time that could be spent elsewhere or your users are getting frustrated with you. The same can be said for alarm modifications. If you are alarming on a particular object more often than you should, your users want that to change. They don't want to wait 24 hours for a change to take place. They want to be able to see those changes take place immediately.

Integrations is something that users typically and clients typically don't give much thought to until it breaks. By integration, I am simply referring to the ability to integrate two or more different services. SevOne has a very good reporting front end, reporting infrastructure. We might need to take some of that data or some of those reports and integrate them on an external portal. We need to be able to do this. Our clients are expecting us to do it.

How do we get there from here, and how does SevOne help us do that? How does SevOne help us meet all those expectations? Reporting is very simple. The SevOne interface is one of the more straightforwards that I've seen. It's very fast. It's intuitive. I had very, very few complaints about it. More often than not, I have had more people mention to me how happy they are with it, that they're able to get their data and have it make sense to them. Straight out of the box, they provide good trend reports, Top N, and capacity projection.

Now I can't show you any of my clients' reports, that's obviously proprietary data, but I can show you some of my data and some of my reports. What we're looking at here is a simple Least Available report. Now I took this template from one of my clients and I superimposed over it my own data.

The bottom end report, my bottom end available report, show me my least 10 available devices, and give that to me in a nice graphical format. Monthly availability reports we have found, particularly for managers, need to be presented as simple as possible. They don't want to see a big chart. They really want to see a gauge, or a button, or a big, green dot or a big, red dot. It's good or it's not.

In this case, bottom 10 report, eight of the devices were absolutely unavailable the entire month. Our availability becomes 75%. This particular report took me about, I would say, less than a minute to put together. It gets saved as a template, and from this point forward, all it takes is a simple click of a button to pull it up.

This is a baselining report. It's another way of showing just some simple trend data. We are comparing the same piece of information over two different time frames. In particular, if we are looking at CPU and memory utilization for a server, the chart on the left shows the previous week, the chart on the right is showing yesterday.

I happen to like this type of report for devices that we know we're having a problem with because it very quickly shows at what time of day or what time of week we might be having issues. In this case, you see that the charts themselves look very, very normal. The spikes are occurring at the same time. The drops are occurring at the same time. Whatever issue we have had with this particular server appears to have resolved itself, or has been resolved, has been resolved within the last week.

Now we're going to move from on-demand reporting to service-level reporting. There are a couple of type of SLAs. Internally, we have our own service levels as a managed service provider to get a new service into production. We have a new client, they're starting to pay us, we need to get our service up and running as quickly as possible.

The nice thing we have discovered about new SevOne deployments is that they are appliance based and they are shipped to us pre-configured and ready to go. It's as drop-and-play or as plug-and-play as possible. As soon as the appliance is on the loading dock, we know all we need to do is have the networking cables run, have power ready, and a place to put them in the rack.

With previous solutions we have deployed, it can be as difficult as trying to combine the work of four or five different groups. There might be a database group that configures the database, a SAN group to give you storage, a server group to build the operating system, my team to put the application together, and that's a lot of moving parts to try to gear together to get a service up and running.

Having an appliance ready to go is a really good thing for us. We have been able to decrease our time to deployment from, in some cases, a month or two weeks down to the time it takes us to take the appliance off the loading dock and up onto the raised floor.

Another major SLA for us is availability of the service. We happen to purchase a Hot Standby failover high availability solution from SevOne. When they ship us an appliance, they're actually shipping us two appliances, one of which contains an up-to-the-minute replica of the primary.

We have not yet had an instance where the primary has failed, but we have tested it. We have tested failover and it does occur within a few minutes. We have never suffered more than a 10-minute outage on a failover, and that has been using our own simulation of outages such as flipping the power on the first one off.

Obviously, other solutions have their own mechanisms for dealing either with high availability or backups or what have you. We have found having the high availability appliance ready to go has been a very good method of ensuring that we have 5 9's availability.

Scott:
Victor, this is Scott. I've been resisting the temptation to jump in with some questions here because, obviously, I ate up a little bit of your time at the beginning, so I'm going to let you go a little bit forward. I know Brian is texting in a question here, so if that's something you want to address, please do so, but I'll let you go another slide or two and then we're going to jump in with some questions of my own.

Victor:
Okay, sure. I'm not sure if everyone can see the question or not. Just in case, I will phrase it out. The question is, "How well does SevOne work crossing subnets and remote locations via direct link?" What I can tell you is that with our deployment, we put the SevOne appliance onto a Class C network. The Class C network is a management network devoted to network management. Our network management network plugs into an MPLS cloud and then reaches the client's network. If we have routing in place, we will not have an issue managing the devices.

Now if I understand the question correctly, the way SevOne manages a device is via one IP address on the device. If we're managing a device that might have 10 or 11 different subnets or IP networks on it, we're not concerned with them. We're only concerned with the one IP address that we use for management. If we're lucky, the client has provided us an out-of-band network for management. If not, we are really dependent upon routing.

When the SevOne appliance polls the device, it will use that one IP address we have for management to poll all the information down for all the various interfaces. It does store their IP addresses, but it does not use them for any form of connectivity or polling. I do hope that answers the question. If it doesn't, please feel free to ping me privately. Awesome. Thank you very much. Scott, do you have a question? Do you want to interrupt at this point?

Scott:
No, Vic. Go ahead. I know you have another slide or two to get through here, and then I'll jump in with a question for you, but I want to hear you get through some of the content.

Victor:
Okay, awesome. I've spoken about some of our internal SLAs for time to deployment. I'd like to move to some of our clients' expectations around SLAs, and they typically revolve around availability. We might see some that include total network utilization is beneath a certain point, but that's the exception, not the rule. The vast majority of our SLAs revolve around availability.

Availability is a tough animal to tame. A user's view of availability is, "Is my application available when I go to reach it?" If you're a LAN engineer, you might be fully concerned around ensuring that your switches are up. If you're a WAN engineer, you might really only be concerned about the MPLS cloud. It goes on and on and on. The definition of availability is very tough to pin down. It really is dependent upon a particular situation.

Now the SevOne appliance is a single polling mechanism. It can be distributed if we have multiple appliances. If we don't however, and most of our deployments personally do not, we have one central location to monitor the entire environment. If we happen to lose a pipe between here and there, we might lose reachability from the SevOne appliance to a portion of the network, and that could potentially impact availability metrics. We have ways around that.

The methods that we have, the tools that we have at our disposal to monitor availability include the very simple ICMP ping. "Can we ping a device, and is it up?" Beyond that, every five minutes or every X minutes, we query a device via SNMP. We can also measure that. "Is SNMP available?" It might be, for some reason, that one protocol or the other is currently not responding.

The last SevOne mechanism we have is to monitor the system uptime of a device. It might be that we lose ICMP and SNMP for a particular period of time, but if the device was still up, we will still see that when we're finally able to poll the device again via system uptime. That's what we're looking at here.

This top left graph is a very simple graph for available memory, and you can see that there's a gap. There's a gap right here. It's about the middle, if my cursor is not showing up. For a period of time, we were unable to reach the device. The ICMP availability report for this time shows less than 100%.

Looking at the bottom graph, the large one on the bottom, shows the system uptime of that device. We can see that even though SevOne lost connectivity to the device for a small period of time, the device itself stayed up. Depending upon your definition of availability, you either have slightly less than 100% or you have 100% availability for that time.

Another solution would be to use SevOne to leverage the IP SLA infrastructure inherent in Cisco devices, other devices have very similar technologies, or we can use them to perform certain tasks such as a web poll or a simple ping internal to the environment, and we store that data within SevOne itself.

Now that brings me to the very last part of the mind map that I had showed at the beginning of my presentation. I'd like talk about separation of data very, very quickly. We do have 50 clients, we have fewer SevOnes than that, so separation of data is very important to us. Thankfully, the architecture lets us separate user roles and permissions. Authorization and authentication, I think, is the right term.

We can show to users only the data that they need to see. They do not see other people's data. This is pervasive through the SevOne architecture. If we have Coke data and Pepsi data on the same appliance and we apply the Coke policies to User A, User A can only see Coke reports, he can only see Coke alarms, and vice versa for a Pepsi user.

Data integrity has also been a very important part for our business to us. Previously, with some previous solutions we have used, we have not been able to provide, I would say, 5 9's data integrity. We had, in many cases, come across upset clients because they have missed either particular objects, they are not receiving data for key WAN ports, or in some cases, their entire report is unavailable for the month.

We have done away with nearly all of those issues after migrating to SevOne. On the few issues where we have had questions about why particular interfaces are not available, we have been able to explain and we've been able to correct. In every case, I would say, it has not been a fault of the product. It's been a configuration issue either on our part or on the client's part.

Scott:
Hey, Vic. I'm going to jump in here, I think, with a question because you're talking about data integrity and trust in the performance data that you're collecting and reporting on. I actually was just digging through a conversation I had earlier this week as I spoke with another customer of ours in the Telco space.

They said that prior to deploying SevOne with their legacy provider, they only had about, I think, 70% visibility of their infrastructure, or the performance of their infrastructure, and of that 70%, they only trusted about 60% of the data that was being reported to them. Of course, the problem on top of that was they didn't know what 60% of the data to trust.

Obviously, that went away with SevOne, but this is a motif, a theme, that I'm hearing from you here about data integrity and trust in the data from your performance monitoring platform. I've also heard you say at the beginning in your mind map there that a couple of the things that were important to you were being able to deal with the very unique requirements of so many various customers of yours and clients. I've heard you talk about things like ease of deployment of the performance monitoring system, and how you can achieve quick time to value with being able to rapidly deploy performance monitoring for a new client.

I guess my question, my long-winded question, to you is if you're evaluating performance monitoring platforms, what are the one or two things that really rise to the top as far as importance to you in your criteria for evaluating a new platform? Is it ability to customize reporting? Is it quick deployment? What things are important to you?

Victor:
Important to me personally would be the data integrity aspect, that I spend, or I used to spend, way too much time hunting down why we did not have data when we should have it. The other second big one to me personally is having a very good API where I can integrate the product with other products that we have.

Obviously, it's important to me. It's my job, it's why I get paid, so I like to have that available to me, but we have found that being able to take not only SevOne data but SevOne reports and place them in front of our clients in a very specific format has made them very, very happy. That's really key to me. Other management in CSC has greatly enjoyed the lower total cost of ownership that we have experienced with SevOne over some competing products that we used to use.

Now there is a question here asking if I'm willing to share some of the other NPM products that we've used. I'm happy to do that off the call afterwards. I'm not authorized to say that publicly, but if you would like to chat, by all means, hunt me down on LinkedIn. I'm more than happy to talk. Getting back to our TCO question, we have been able to reduce our total cost of ownership, and I think the term is "by half" or "by 100%", or depending how you look at it. We used to have four people devoted full time to managing our previous products. We've been able to reduce that to two people, we've been able to more than double our footprint, and that saved two STEs to do other client value-adds for us. It's been a very big benefit.

Scott:
Right. Hey, Vic, thanks for answering that. Just a quick note to our audience here. I know we're past the bottom of the hour. Typically, we only go about 30 minutes on these, but I think today is a special engagement since we have a customer on the line. Obviously, this is a great resource for you guys to talk to and ask questions of and get a glimpse of how he views the role of performance management at his managed service provider that he works for. Vic, I'm going to let you continue here. We'll spend another 10 minutes or so going through the content.

Victor:
Yeah, I am nearly done. The last thing I had wanted to talk about was the nightly rediscoveries. This is part of data integrity. SevOne will touch every device that it manages on a nightly basis. It updates the configuration for them. For those of you in the NPM arena who might suffer IF Index shifts, this has been really good for us. We arguably see, at most, the 23-hour gap in data due to an IF Index shift, and that doesn't really happen very often.

The other multi-tenant issue that has been a good benefit to us is storing one year of "as polled" data. Literally, if we poll every five minutes, we will store that five-minute data for a 365-day period. That's been important to us because some of our clients bill based off of percentile measurements. 95th percentile, let's say. If there's a billing dispute, we can go back up to 12 months and pull the actual data of utilization and usage for that particular time period.

Some fringe benefits of using SevOne, it's very easy to deploy. We drop it into the rack, we turn it on, and the application is ready to go. The low total cost of ownership has been very good to my management in particular. It does have a robust API. I've mentioned it briefly in a couple of points how we're able to take some of SevOne's data, place it in front of other web interfaces and such.

The API does much more than that. We could, if we really wanted to, build our own management infrastructure on our own portal using the API. It can be used to manage devices, manage users, add them, delete them, we can pull reports out of it, we can pull the raw data out of it. It's a very robust API. I've personally, as a developer, been very happy with it. It's met our needs on multiple occasions.

There is a question. "Is the five-minute data stored for one year the default, or is specific for my deployment?" That is the default. The appliances we use are geared toward monitoring 60,000 objects. They are shipped to us to hold five-minute data for those 60,000 objects for 365 days.

Now the five-minute polling rate can be modified. We can make it faster, we can make it slower, but there's always a trade-off. If we decided to poll 60,000 objects at one minute, then we would obviously not have enough database space to store 365 days. You might end up storing 200 days. To answer the question, those are the default metrics. Five-minute data for 365 days.

Scott:
Vic, I'll just jump in there to clarify. With SevOne, our claim is that we will maintain a year of "as polled" data. By default, it may be set to a five-minute cycle, but we can poll down to sub-minute levels. Actually, with individual objects, we can get down to as granular as one-second polling of your objects if need be. We do have a very high frequency polling that we can employ, and, again, we will maintain a year of "as polled" data for you.

Victor:
That segues into the next question in the Q and A chat. "Can we change the polling for individual resources?" The answer is yes. As Scott pointed out, we could do, if we really wanted, down to one second. For one of our key financial clients, a very large bank, we monitor their devices on a five-minute basis, except for key WAN interfaces that we poll every 30 seconds. The next question is, "When we maintain the data, is it stored locally or does it report back to a centralized location?" It is stored locally on the appliance.

Scott:
Yeah, I can answer that one as well. Because we are an appliance-based solution, again, just going back to some of my initial points at the outset, a single appliance acts as your poll or your data collection, your database, reporting, analytics. Everything is done from that single machine. There is no centralized database.

If you're working in a cluster environment, as we call it, where you have multiple appliances that might be monitoring, in Vic's case, a million different objects, there is no centralized database. They all know what each other is responsible for, and when a report is run, they all share their load of the report from the data that they've collected and report back to whatever appliance you're reporting from.

We've essentially eliminated, our patented architecture, has eliminated the historical bottleneck of a centralized database, which is why you see a lot of performance monitoring platforms and vendors out there that typically, as your infrastructure expands and you're collecting more data, the speed of reporting slows down because it is all funneling through one bottleneck. I'm sure Vic could probably talk to the speed of reports with SevOne as well just to validate that point.

Victor:
I could, but there are a couple of other questions here that I'm going to get to quickly. One is another question, am I allowed to speak to the other NPM products that I've used? I will be happy to do that offline.

The appliances that we use from SevOne are capped. They're sized for 60,000 objects, but they do have a number of other-sized appliances. They have a virtual appliance that you can stuff onto a VMware image that we use to monitor 5,000 objects for very small deployments. I believe that they also have now a much larger appliance that can support up to 200,000 objects from the one appliance.

What we have preferred to do with our larger deployments is to deploy the appliances globally, that we do have a large financial customer where we have an appliance in each global region. One in the US, another in EMEA, Switzerland, and Singapore. They do work together, they're paired together, so the end user does not see a difference. It's strictly a backend difference.

Next question is, "By objects, do you mean individually monitored measured metrics or physical device?" I am referring to an object that would have an index in it in the MIB such as an interface or a CPU or a QoS policy, a piece of memory. Essentially, the smallest item that we can generate a report against.

The next question is, "Do configuration changes include firewalls?" Yes, it does. Any time the SNMP MIB goes through any form of change, a rediscovery will pick that up for a firewall that might be the addition of a new policy, or IP Sec tunnels might be created. IP Sec concentrators, we try to avoid because we can have hundreds or thousands of users on them. Yes, any time the SNMP agent changes, their rediscovery will pick that up, and it's really device independent.

Scott:
Hey, Vic, I'm going to actually put a question out to Dave Hegenbarth if he is still on the line with us here. I know we're running a little over, but, Dave, if you're there, there was a question earlier. Vic had mentioned the high availability solution, our HSA, Hot Standby Appliance, and there was a question that came in about, "Are those deployments typically in the same geographical location or can they be in different geographical locations as the primary appliance?"

I'll put that one to Dave since he is the star of Demo With Dave, if he's still with us right now. If not, Vic, I'll put it to you. Let's just see if Dave jumps on here. He might have left us. Okay, Vic, so I'm going to put that one back to you. With your high availability solution, is that maintained at the same geographic location?

Victor:
Yes, it is. It is currently in the same geographic location. It does not need to be. Okay, there's another question. "How well does SevOne deal with a large number of concurrent users?" We have never had a problem. I'm sure at some point, there would be a bottleneck, but we have never had a problem yet. I'm not sure I have any statistics to give you. I'm sorry on that one.

Scott:I can share some statistics because we have reports from at least two other customers who regularly hit over a thousand concurrent users with no degradation to performance of the system. All right, Vic, did you have any slides you want to wrap up on here? If not, we can see if there's any last-minute questions that come in.

Victor:
There is one more question. I'm going to leave that one to you, Scott, if you see it.

Scott:
I'm not sure I'm seeing it there.

Victor:
Okay. The question is, "Does SevOne recommend smaller multi-appliance configurations in large networks or one large one?" I'm thinking, personally, it depends upon the network. We had one client at one point that had a lot of microwave networks in Africa that we ended up deploying a small virtual appliance to, just because microwave doesn't handle traffic very well.

For most of our clients, we will manage them from one central location here in Delaware. I think our largest deployment from one central location is about 6,500 devices, and it's getting close to 200,000 objects. We're doing that from one data center out globally.

Scott:
Sure. I will jump on there and just say, for that question, SevOne can deploy centrally or in a distributed fashion. I think there may be cases where you may be concerned with the bandwidth impact of traffic going over your network from different geographies and different remote locations. In some cases, you may prefer to have a number of smaller configured devices more local to those locations, but you can deploy both centrally or distributed, whichever is your preference.

I think we've certainly taken up a lot of time today. I know people are going to have to start dropping. I think we got to all the questions online. If you guys had any additional followup questions you'd like to ask, I'm going to jump through here, please go ahead. As Victor said, you can certainly connect with him on LinkedIn if you have any followup questions or questions about other performance monitoring solutions he's used that can he can handle and address offline.

If you'd like to follow up with SevOne with any technical questions about the SevOne platform, we'd be happy to speak with you. Please reach out to us at info@sevone.com or give us a call. We'd love to hear about what challenges you are having when it comes to performance visibility. Again, it's something we specialize in. We'd like to hear how we could potentially solve some problems for you guys.

All right. I hope it was an informative session. Vic, again, there has his LinkedIn address if you'd like to reach out to him. I very, very much thank you, Victor, for your time today, your openness and willingness on both your behalf and CSC's to share that information with us and give some open, honest answers to people who may be interested in just what you see as best practices or in SevOne platform itself.

Please, guys, join us again. In about two weeks, we're going to have a session on determining if your network is ready for VoIP. Dave Hegenbarth, our Demo With Dave expert, will be back to give a live application demonstration for that session. Otherwise, I appreciate the time you took out of your busy days. We hope to speak with you soon. Vic, again, thanks. I hope everybody has an enjoyable weekend. Take care.