infrastructur e ICT
applications such as Exchange or SAP to a virtualised environment there are several best practices to observe, including: £ Before the migration starts, find and eliminate connectivity errors. This means cleaning up multi-pathing errors, both in terms of single and unbalanced I/O paths. If you cannot prove that data paths are completely redundant and balanced, they probably aren’t. At the same time, monitor for physical layer issues in the infrastructure, from the VMs to the storage LUNs. Waiting to find and fix physical layer issues after the migration unnecessarily increases risk.
£ Next, ensure optimal performance by right-sizing the infrastructure components and configuring them properly. Because vendors like VMware report that nearly 90% of performance-related problems are due to issues with the storage and its network configuration, spend a proportionate amount of effort there, not just on server-side optimisation.
£ If you optimise utilisation, you will reduce I/O congestion. Good network capacity planning can help maintain networks in optimal working order. It can reduce the risk of outages due to resource limitations, and justify future networking needs. It is important to look for patterns that occur at various times of day: there are often the equivalent of “rush hour” time periods when the I/O traffic will be slowed due to periods of significantly increased demands. In terms of optimising storage capacity, use solutions that can find and report on all underutilised and unused LUNs and switch ports.
£ Finally, using scenario or what if reporting, you can simulate the effect of a configuration change on throughput or application latency. For instance, one of our customers uncovered a backup job which was going to create a bottleneck if the private cloud migration took place exactly as planned.
Though private clouds can help speed deployments and reduce costs, there is little advantage to the end-user if it increases the risk to application performance and availability. Through de-risking these areas, you can deliver the full benefits of the new compute model and mitigate the risks.
IPM lets the IT department be proactive to the requirements of the business, rather than reactive to solving issues. Latency in applications is rarely caused by one issue – it’s usually a combination of small problems that compound to create a big problem. By being able to see the entire infrastructure, in real-time, from virtual machine right down to LUN level within the storage device, and everything in between, the IT department can resolve these small problems before they affect application performance.
This approach cannot be taken using the tools provided by the server, switch and storage devices as they only give part of the story. If a problem occurs there is a lot of finger pointing as to who is responsible – which wastes valuable time in resolving the issue. IPM lets you see where the issue is and helps you resolve it quickly. It, together with TAPing (inserting a Traffic Access Point into the system so Fibre Channel protocol can be read off line) are quickly becoming the de facto best practice for organisations wishing to guarantee application performance to the business while simultaneously growing the environment and reducing cost.
November 2013 I
www.dcseurope.info 19
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 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56