Recently, our government moved forward with a plan to combine two separate county councils into a single entity. One of the more complex tasks involved in the merger is the creation of a single, unified IT infrastructure for the county’s services and public-facing websites. The €1.8 million IT consolidation project includes the creation of a primary data center and disaster recovery site connecting to 57 remote county offices and sites over a variety of connections (point-to-point, VPN, private DSL, MPLS, etc.).
When completed, the network will include a mix of internal applications, public-facing websites and portals for services such as housing, water, roads, environment, planning and other key local government functions. In addition to standard business applications for communications, productivity, CRM and financial management, the network will also host some bandwidth intensive GIS and mapping applications. It will also support remote access and a variety of mobile services and applications.
Creating a single unified network across all of our county is a major undertaking. All of the merged authority’s back-end infrastructure will be located in the North of the county. As a result, all WAN services from the Southern part of the county are being relocated and re-terminated at a separate head end. Major sites in the south of the county will send traffic out through a switch core, up the point to point link to be dropped off in the primary data center core. About 800 users will be connecting to services hosted in the data center, of which approximately 450 will be from the southern part of the county.
The technical complexity of merging existing systems, applications and data was just one of my major concerns. We are especially conscious of the fact that users from the Southern part of the county are sensitive to performance issues in light of the division of labor and responsibility for the unified network. Being able to remotely diagnose and solve network and application problems is a priority.
We need a tool that can give us a complete picture of what is happening with applications, servers and the network across the entire county. Right now, we’re still building the network. But in the medium term, it’s important for us to be able to isolate the source of performance issues so we can get application problems on the desk of the applications team and network problems to the network team so they can address them quickly.
We chose the Fluke Networks Visual TruView appliance to provide the application and network performance monitoring we need. TruView leverages key data sets such as stream-to-disk packet storage, application response time, transactional decode, IPFIX (NetFlow), and SNMP to present analytics through a single reporting interface. As TruView processes analytics from these data sets, it time correlates the results providing cross-functional IT teams such as network engineering, application, and server teams with a new found ability to work more collaboratively and solve problems fast. We deployed TruView directly in our data center core.
With TruView you can get a high-level overview of what’s going on with a particular site or a particular application very quickly. It’s very easy to interpret. We can see which applications are having or causing problems. With our previous solution, it took much longer. And, of course, with TruView you can drill down into the data when you need to take a closer look.
I’ve been a user of Fluke Networks products for more than 12 years. We even had one of the earliest OptiView portable network monitoring devices which was extensively used across the network. So when it came time to choose a performance monitoring solution, I knew Fluke Networks could deliver.
We had no identified budget for a TruView appliance this year, but we could clearly see the benefits we could realise from deploying the solution. We managed to identify savings and re-prioritise some other projects within our budget in order to fund purchase of the TruView. We chose the TruView because it offered better value than the other performance monitoring solutions we saw.
Before deploying the TruView, performance monitoring was fairly manual. We’d used and were very familiar with NetFlow. With TruView, we have a much better view of application performance, particularly from the user perspective.
For example, we had an application response time issue with Exchange. TruView helped to isolate the particular server that was the root of the problem. As the launch of our unified network approaches, TruView has helped my team find “bits and pieces” of things that might have impacted application performance had they gone undetected.
Another recent example of practical use was an issue in which slow user logins were being reported from the southern end of the network. Using the TruView, within minutes we eliminated the point-to-point link, server side performance and end user response times and firmly diagnosed the issue to be local to the southern end of the network. This is exactly the type of scenario we knew the TruView could help us with. Prior to this it would have required an exhaustive search to figure out what exactly or where exactly the issue was.
As the launch of the new, unified network gets nearer I see TruView becoming even more useful. We’re looking forward to seeing how much more it can do. I don’t think we’ve taken full advantage of it yet.