This page contains a Flash digital edition of a book.
Be On the Lookout Private clouds are about


process, automation, people, and centralization. Some private clouds use virtualization as well as physical hosts, so no matter which tools you select for performance monitoring, you should gather data from all of your hosts. Collect data all the time, not just when you are consolidating, centralizing, or troubleshooting. Often, customers and monitoring


systems don’t notice a problem when it starts. They only notice when it gets bad enough for users to complain. With historical data, you can see when a problem started. Perhaps that CPU load problem you were just notified about started a week ago with an antivirus scanner update. You would be able to see that easily in your historical data, and the people working on the problem could find it quickly, fix it, and return to more productive work. Private cloud performance


monitoring has additional nontechnical benefits. Services you want to centralize, such as a series of departmental Web servers, often don’t have much monitoring in place. When a server is “down” or “slow,” someone just walks over to it and reboots it. And that’s the wrong thing to do. If you promote a centralized service by saying that it is monitored for both availability and performance, you make it harder for departments to resist. After all, you’re doing it right, whereas they were not.


Be Transparent Transparency is important, too.


Make private cloud performance data available to developers and application administrators so they can see the effects of their configuration choices. For a cloud based on virtualized infrastructure, such choices might be good for an application but bad for the environment in general. Everything in IT is a tradeoff, including performance. An app’s performance goals should


IMAGE © BUCHACHON / FOTOLIA CONNECTION/BUSINESS IT 2012.Q4 15


be well documented so they can be met but not exceeded. Exceeding these goals would require additional expenditures of money and time.


Be Choosy When implementing a private cloud performance monitoring system, gather data on as many relevant metrics as possible and from the right places. Don’t ask a guest OS in a virtual environment what the CPU load is—it won’t know the right answer. You can get that data accurately from the virtualization platform. The same is true for memory usage, network I/O, storage I/O, and so on. By contrast, application performance is best measured at the individual server level, which will help you see things like a cluster member about to be overloaded. In addition, gather data at the


highest resolution you can afford. Many performance-monitoring tools show historical data in 5-, 15- and 60-minute averages, which smoothes the peaks in load for the graphs. That smoothing is deceptive, because the spikes in load are very important. When an application goes to do


work, it doesn’t do it slowly. It uses all of the CPU it has available and gets that work done as fast as it can, which appears as a 100% CPU spike on a graph. The width of that spike is important because it often represents how slow


Accelerate Your Journey to the Cloud Start with an Assessment


The first step in your cloud project is to examine the big picture. Our assessments will ensure that you do just that, and kick your project off right. Our Server, Storage, and Network Assessments give you a clear picture of your


infrastructure, provide remediation plans to fix the problems, and optimize your network’s performance. We can help you make changes and improvements that reduce costs, shorten backup and recovery times, and accelerate performance and operational efficiency.


Call today to learn more, and discover why we are your Cloud Connection™


solutions provider.


1.800.800.0014 www.pcconnection.com/cloudcomputing


an application feels to a user—in other words, the latency between a request and the result. If the performance monitoring


software averages those spikes with idle time, you might see the server as 50% loaded and arrive at the false conclusion that it has enough capacity. Network and storage connections work the same way. If the link is 100% busy for a minute, and 0% busy the next, the average is 50% busy, which may not seem like a problem. Digging deeper by using a higher-resolution graph is very useful in these situations. Of course, keeping a lot of data and collecting higher-resolution data also consumes CPU, memory, network and storage resources, so you want to strike a balance.


ABOUT THE AUTHOR


Bob Plankers is a virtualization and cloud architect at a major midwestern university.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36