The term “Virtual Blind Spot” has begun to fly around, but what does it mean? Basically, when you have resources and servers that are virtually moving between hardware boxes, the tried and true methods of monitoring traffic are unlikely to provide the required visibility for maintaining a secure and well-performing data center. After all, if I activate a SPAN to attach an IDS or an Application Monitor, great. But how the heck will I know whether the same traffic streams will be available to those tools over time?

Simple answer: I can’t.

What’s a security, operations, or application performance professional to do? It’s time to look at a different way of managing your monitoring assortment.

It’s time to adopt Monitoring Optimization.

Here are the switches, but where are the servers?

Physically-based monitoring has served us well over the years.  But times, they have already changed! For virtual environments, you need a very flexible, yet easy-to-use, monitoring solution. This is exactly what monitoring optimization provides.

In the past, you had to activate a SPAN (or place a Tap inline) to monitor key traffic streams. This was important, since the mirroring practice provided a safe place to monitor without introducing any latency or other risk into the live network segments on your network. The weakness with the old approach is that you can only have one tool for each SPAN or Tap. If you need more than two tools on a switch, tough luck. Go look for some point solutions to band-aid together, regardless of the management nightmare that would ensue. At least the data gets to the tools, right?

Wrong. Even in that scenario, the risks of dropped packets, misconfigured filters, and potential for human error during the “band-aid” process would be more than you may anticipate. Then something goes awry and you have to troubleshoot, and the problem becomes twice as complex. When you throw virtualization and moving resources into the mix, the whole model breaks.

Monitoring Optimization: Virtual Connections For Virtual Environments

Monitoring Optimization, the key technique that you get from the Anue 5200 Series Net Tool Optimizer, employs aggregation, replication, the most advanced filtering on the market, and the most intuitive interface to simplify this whole mess.

It is even more critical than ever to have visibility into all network segments where a virtualized resource may appear. Given the high cost of tools and limited number of available access points, it is impractical to think you can simply buy tools for every candidate network segment for whatever it is you need to monitor (not to mention the management overload you’d personally suffer through if you did choose to go that route).

Monitoring Optimization allows you to simply SPAN or Tap each segment a single time, route it to the Net Tool Optimizer, and leave all important tools attached to the box as well. Then you do all the connections and filtering “virtually”, i.e. right in the product’s fully-integrated GUI.

Simply drag and drop the segments to the tools that need to see the traffic, configure the filters in a matter of minutes using a simple Windows-like interface, and start monitoring. Heck, you could route all network segments to every tool if you like. Just filter down the data appropriately to keep the tools from overloading, and move on with your day.

If something goes wrong and you need to troubleshoot, no problem! Drag across a “virtual” connection from the segment(s) requiring diagnosis, set up the filter, and your diagnostic tool is off to the races. Notice that there’s no need to actually plug and unplug tools, because your connections are all virtual, just like your network! How’s that for minimizing MTTR?

All Virtualized Data Centers Should Have Monitoring Optimization

Yes, when I wrote it I meant it. Every. Single. Virtualized. Data. Center.

We are all squeezed for time. Why spend all day playing around with point solutions or plugging and unplugging tools to get this figured out? Just optimize it and move on! You also get the added benefits of monitoring more of the network without buying more tools, full integration to existing systems (SNMP, TACACS+, etc.), complete control to access based on groups, and a variety of other key features we included specifically to make your job easier.

Want to learn more? We are offering a $50 promotion for 30 minutes of your time to view a demo (for qualified respondents as indicated on the signup page). If virtualization is important to your business, you owe it to yourself to learn about the best monitoring optimization solution on the market.

The show was great through the first couple of days without question. As we saw with most vendors who chose to display in the Expo, the Monday evening reception was very busy. Surely an abundance of free beer played a part in the jovial attitude, but regardless, we had some outstanding conversations with many existing and potential customers. For those of you who came by the booth, thank you for your time and interest. For everyone else, here are a few simple snippets of the Anue presence at the show…

_____________

Please enjoy the following guest post by Abhinav Vaid.

______________________

Performance Testing was always a part of Software Testing whether explicitly stated or not. The world of software testing is becoming smarter and mature. With the changing landscape of Computing and an  Industry-wise paradigm shift towards SOA/web based applications has brought to the forefront a focus on Performance Testing. The expectations sought from this kind of testing are measurable numbers.

Performance Testing is about measuring the performance of an application under test, whether the application is an embedded, desktop, or distributed enterprise application. However, these are the enterprise-based applications/architectures, wherein lies the prime focus of performance testing. Expectations sought from AUT is to measure the performance numbers and to ensure that it conforms to the expectations.

Goals of Performance Testing

The business goal of performance testing is to measure the application performance and ensure that the numbers conform to the Service Level Agreements. Goals can be internal (if the application is an in house project), or external (when the SLA’s define the objectives).

External Goals

Conforming to the Service Level Agreements (SLA’s). The SLA’s at the highest level consists of the following parameters (whether or not explicitly stated). Application Response time. Application throughput. Maximum number of concurrent users Resource utilization in terms of various performance counters for example: CPU, RAM, network I/O, and disk I/O. Soak Tests1 under varied workload patterns including normal load conditions, excessive load conditions, and conditions in between. This can include increase in the number of users, amount of data and so on.

Internal Goals

Application Crash. The application crash translates into a condition where the application either hangs or stops responding to requests. Some of the symptoms of breaking point include 503 errors with a “Server Too Busy” message, and errors in the application event log that indicate that the ASPNET worker process recycled because of potential deadlocks. Symptoms and causes of application failure under stress conditions. Recoverability options, whether the application recovers after a crash or not.

Soak Testing is about measuring application performance over long periods of test run typically one would expect in a real production/live environment.

More importantly to ensure that there is no data loss when the application crashes and application recovers gracefully. Known issues/bugs in the AUT.

Performance Objectives

Most of the performance tests depend on a set of predefined, documented, and agreed-upon performance objectives. Knowing the objectives from the beginning helps make the testing process more efficient. You can evaluate your application’s performance by comparing it with your performance objectives. One should by all means just run Ad-hoc tests randomly without any specific objectives (Old Principle: how many bugs were discovered just by executing the test cases).

As a rule of thumb, the following are the performance expectations from the Application Under Test:

1. Application Response Time. This is the most fundamental parameter which ideally is the second nature of the performance tester. Application Response time is the amount of time taken to respond to a request.  You can measure response time at the server or client as follows:
2. Response Time at the server. This is the time taken by the server to complete the execution of a request. This does not include the client-to-server latency, which includes additional time for the request and response to cross the network.
3. Response Time at the client. The latency measured at the client includes the request queue, plus the time taken by the server to complete the execution of the request and the network latency. You can measure the latency in various ways. Two common approaches are time taken by the first byte to reach the client (time to first byte, TTFB), or the time taken by the last byte of the response to reach the client (time to last byte, TTLB). Generally, you should test this using various network bandwidths between the client and the server.

By measuring latency, you can gauge whether your application takes too long to respond to client requests.

Application Throughput

Throughput is the number of requests that can be served by Application Under Test per unit time. It is measured in terms of transactions per second or orders per second. The throughput varies largely due to the type of load applied, volume of load applied etc. The various examples include credit card transactions, the number of concurrent users, volumes of downloads and so on.

A larger parameter, however, also happens to be the network connection. For example, in terms of numbers lets say, there are 1000 users with an average page request data of 5k for every 5 minutes. The throughput would be = 1,000 x (5×1024x8) / (5 x 60).

______________________

Article Source: http://EzineArticles.com/

For those of you who frequent this blog or use Anue products, you are very aware of the importance of testing against the real world network before deploying on it. The following is a great guest post discussing how and why to test new converged applications before rolling out to the production network.

The best way to actually complete the tests with the highest level of accuracy is to use a Network Emulator that can capture and replay actual conditions from your unique network environment. When you are ready to undertake this task, we are here to help.

______________

The Virtual Network Test Lab

After all the planning has been done and the network assessed, the conclusions drawn and assumptions made must be tested to assure that they are correct before moving on with the migration. Testing new applications and hardware in a production environment can be potentially disruptive to a business if things don’t go as expected. It is therefore essential that the testing and tweaking be done on an isolated network segment

The test lab should mirror the production environment in all aspects. As duplicating a network would be cost prohibitive from a hardware point of view, IT managers have turned to virtualization software to setup and emulate the production network, and to test the effects of MACs before deploying them live. Virtualization pioneer VMWare offers a variety of virtual networking solutions, and in 2004 Microsoft released its Virtual PC (VPC) software.

A virtual network is an invaluable tool that allows IT professionals and system integrators to accurately emulate current and planned network conditions, and to assess the impact of new applications, moves and changes, and new hardware on the network. In the case of implementing convergence, some specific best practices have been adopted as to how testing should proceed in a virtual network test lab.

To ensure the testing environment is realistic, conditions on the production network should be captured over an extended period of time, taking into consideration the busiest time of the day, week, month, and year, as well as average and below average periods of network congestion. Once captured, conditions can be replicated in the test lab, adding the VoIP application and connecting phones or using call generation software to accurately reflect the impact on the network in best, average, and worst case scenarios.

Calls can be analyzed from point to point to monitor QOS as well as for audio quality using human indicators such as the Mean Opinion Score (MOS) rating system. Have end users listen to calls under a variety of conditions to indicate their level of satisfaction with the quality of the call. As mentioned before, bringing the end user into the loop at all stages of deployment will help ensure a successful migration and help avoid mass revolution.

Before, during, and after the rollout, a virtual network test lab can play an important role in testing and optimization. Initial objections by management due to cost considerations should be overcome by the potential ROI realized through enhanced troubleshooting techniques, and the ability to see the effects of MAC before implementation on the production network. A useful tool not just for deploying IP Telephony, but for the network as a whole.

Rolling Out the Converged Network

For smaller businesses, after all the testing is done and confidence is high, it may be advisable to migrate all users in a single sweep. For larger organizations and enterprises with a more complicated network topology or departmental scheme however, they would be well advised to proceed with caution with a partial migration, rolling out the new application on a departmental or regional basis.

The order of migration should be logically considered, and although the pressure may be there, political considerations should not be high on the list of priorities. The last thing any IT manager wants is to roll out the CEO first, to be witness to all the glitches and stumbles that will inevitably occur at the beginning of the migration. Planning the roll out should be based on a number of factors, including but not limited to:

Which department or region has the best qualified support staff, or has taken part in the testing and is most familiar with the system. The early rollouts are the slowest and will for sure have the most problems. Consider the first roll out as a test and let the group closest to the project, perhaps the now converged IT/Communications department, enjoy the fruits of their labor. If rolling out a remote location, choose one with the nearest proximity to the location of the support staff. Subsequent migrations will become easier and the knowledge gained will make for smoother transitions.

The regions or departments that are the most needy should also be considered candidates for early migration. Branches that have sufficient network infrastructure but an aging or outdated PBX system should have the priority, while locations that need significant network upgrades should take care of that first. For example, a public school district may want to deploy IPT to schools that have the capacity first, while simultaneously upgrading the older schools networks to sufficiently accommodate data and voice.

In a campus LAN situation, it may be feasible to migrate by building, where if only one building is involved, migrating by department may be the better solution. For the International Corporation with offices in India, migration may not be possible due to legal considerations of Voice over IP in that country.

You also have the option at this juncture not to migrate. As long as there is sufficient telephony equipment to do the job, it may make better business sense monetarily to postpone migration. As VoIP and IPT mature, competition in the market place grows and prices will eventually fall. Functioning legacy equipment that is not yet fully depreciated could also be reason enough to postpone deployment. If all is well in the organization, there is no reason to hurry; the technology of IPT and Unified Communications will only get better and cheaper over time.

______________

Article Source: http://EzineArticles.com/

The survey, which was conducted by Network Instruments the past two years (NetQoS and NI conducted it together in 2008), revealed some very interesting data points.

1. Virtualization, as we would have anticipated, has picked up a great deal of momentum both in the data center and on the desktop.
2. The primary reason for adopting virtualization is cost savings. Yet, they also revealed that implementation costs are too high.
3. The single biggest virtualization-related challenge is a lack of visibility to data streams, an inability to secure the infrastructure, and a lack of monitoring tools optimized for virtualized environments.

Based on the interplay of the first two key findings above, it is clear that high implementation cost is not a long-term problem. Obviously, today’s decision makers can see the “forest for the trees” so to say, in that the expected long-term cost savings will easily dwarf the high cost of entry.

What jumps out to me the most is the monitoring problem. This is not a unique challenge to virtualized environments, but rather, virtualization itself is causing some head-scratching regarding the monitoring itself. And really, for data centers that are already burdened with escalating tool costs, shrinking staffs, and a shortage of physical access points, it’s no wonder some of them might feel desperate to fix the monitoring quandary.

The reality of the situation is that there is a very easy answer to this problem: Monitoring Optimization. Monitoring optimization involves the adoption of an aggregation and replication switch, which can solve all of these problems if designed with a fully-integrated GUI. The key is to look at this as the monitoring of specific data flows or traffic, not specific links, switches, or access points.

With servers and other hardware switching over to “virtual” servers and hardware, one of the biggest issues is knowing where to place tools in the physical infrastructure. If you stick with the “old way” of placing a tool everywhere monitoring is required, you’ll need more tools than any reasonable enterprise can afford to buy or manage!

What you really need is a “virtual tool farm” to go with your virtual infrastructure. Don’t get me wrong; you’ll still be using the same hardware/software-based tools you have already deployed. But using Monitoring Optimization, you can extend a single tool to cover multiple data streams, and you can share traffic from a single data stream with any or all of the tools you desire. The best part is that you can do it all in a fully integrated GUI without ever having to use  some time-intensive, cryptic IOS-like CLI (likely in a proprietary coding language from the vendor, as most of our competitors offer) to manage your most challenging filtering…it’s all drag and drop and windows-esque form entry.

If you count yourself among those who said monitoring is their biggest headache, I urge you to learn more about the Anue 5200 Series Net Tool Optimizer. Then reach out to us via our Contact Me form, and we’ll show you exactly how much easier this can be, and you will see a positive impact to your tool use and staff effort immediately upon deploying our solution.

_____________________________

Article Source: http://EzineArticles.com/

______________________

______________

Anue Systems is exhibiting in the Vendor Expo at booth 2631. I was personally present for the first day, and I must say, the show was busy right from the start. In what turned out to be a very productive first day, we were able to chat with nearly 200 IT professionals. While we of course highlighted our products, we were also able to check out some cool new technologies, learn a bit about some real world needs among data center and security professionals, and generally meet some intelligent and engaging professionals.

If you intend to be at the show today or tomorrow, please come by to visit with us. Here are some of the highlights of our booth space.

Free Coffee in our booth until it runs out on Thursday

Scan Your Badge to Enter Our Google Nexus One Drawing

Meet our Executives and Sales Team