storage ICT
#dcsarticle
http://www.dcseurope.info/n/nosu
New flash storage: So why isn’t everything faster?
It’s time to call in the infrastructure performance management professionals, writes Alex D’Anna, Director of Solutions Consulting, Virtual Instruments.
WHEN CUSTOMERS INVEST in the most current storage technologies whether it be flash or the next generation All Flash Array (AFA) they expect to see an immediate improvement in operational speed to justify outlaying such expense. Most new storage technologies are designed to deliver an immediate improvement in performance through some feature that is specific to the device itself (speed of drives, amount of cache) but this does not always happen and we’re increasingly finding that customers need infrastructure performance management solutions to help identify the root of their IT problems.
When we speak to customers or engage in SAN troubleshooting, we find that if new technologies, such as storage, SANs or hosts, have been introduced, most of the unexpected slow-downs are caused by mis-configurations which can be found at different points in the infrastructure from VM or physical, right through to storage. This is why it’s really important to think of adding new technology not as an add-on or simply as throwing out the old and bringing in the new, but as implementing an interactive part to the whole IT infrastructure.
We have found that an audit of the infrastructure, if focused on the right areas, not just one area such as the storage array itself, will bring better clarity for the reasons that impact critical business applications. From an infrastructure perspective this end-to-end view, which in storage terminology is VM-Server-SAN-Storage and LUNs, often allows the customer to invest wisely by investing in the right place rather than throwing money at the problem without a good result. The list of customers who have invested in faster storage only to find that the application performance hasn’t improved is very long.
16
www.dcseurope.info I Winter 2013
Before introducing flash, or even a private cloud, it’s important to cover all four layers of the IT infrastructure which broadly are: host and switch; virtual machine; I/O stack; and storage. Having an end-to-end view of all of these layers is important for finding and highlighting performance issues.
When we look at what causes slow performance, there are several pain points that come up on a regular basis:
£ Storage array configuration – Let’s take a common example: your business wants to deploy a new application or upgrade an old one. Customers are doing this all the time. Frequently a database, or other application that is customer facing, is far more popular than expected. A customer recently expected 60,000 users on a new application and ended up with 3 million users.
In some respects this is a good problem to have for them as a business, but unfortunately this completely overwhelmed the storage, the SAN, and the host. Users were not happy to say the least, and the business and application owners even less so.
So the design from day one is sufficient, and you architect it as best as you know how but once the application is under real load the array itself isn’t always sufficient to handle the strain. Then things also change. For anyone to expect that a storage array should perform for up to three to five years against all workloads is fairly optimistic in my experience. And so it becomes critical to measure other components that make up that I/O stack. Furthermore, as the report logs on an array might not be at the I/O level, we often see much longer intervals than
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 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72