SLAs, Operating Costs and Dynamic Optimization: Achieving Equilibrium in Storage System Design
If you ever wanted to create war within the confines of an application design meeting just bring in someone with an eye for architecture. I don't care if the person is a database, storage or system administrator or some sort of system architect. These guys will often start questioning the application in relationship to the physical requirements of hardware. How much data will there be? What does a typical transaction look like? How many updates will there be? What will be the growth pattern?
There is good reason for this. They want to design a system architecture that will provide acceptable levels of service and performance today as well as in the future. Unfortunately there are opposing forces such as service level agreements (SLAs) and operating costs within organizations with which they must contend. For example:
- If organizations purchase too much storage, for performance or future storage expectations, they might meet service level agreements but they will also face increasing operating costs
- Conversely, if organizations purchase just enough storage or don't adequately forecast future storage needs they will put service levels in jeopardy
Making matters worse, many administrators and architects find it difficult, if not impossible, to agree upon underlying system configurations based on application and service level mix. The simple selection of a RAID level can become a huge design battle. On numerous occasions as an architect and administrator I've had heated discussions about the different RAID levels that are better suited for some storage structures than for others. But because application mix, service levels and future requirements were unknown, IT was often forced and locked into architecting a storage solution that left many questions unanswered.
Because there are often many unanswered questions about current and future application mixes and their future impact on performance and service levels, I've become quite excited about 3PAR's dynamic optimization feature and its ability to deal with the increasing unpredictability of cloud computing and next generation data center environments. Using simple storage-side commands, administrators can alter the underlying storage structure in a non-disruptive fashion.
Also through dynamic optimization, IT can easily change, convert, or adjust key storage features such as RAID type, degree of utilization for processors, drives, and ports, the placement of data on disk, and the type of drives being used (FC or SATA-class drives). In effect, IT can alter the cost structure and service level attributes of an application volume rapidly, non-disruptively and on-demand. Combine 3PAR's dynamic optimization with its utility storage and you circumvent the two previously mentioned opposing forces:
- Organizations are able to purchase and allocate storage as needed to minimize operating costs
- Organizations are able to dynamically change storage configurations to meet changing service levels
Planning for the future is tough as I can testify based on the numerous occasions I've been brought into organizations to look into the reasons behind faulty performance of applications and databases and then figure out how to fix them. This is particularly true when considering virtual server technologies and next generation data center infrastructure. While there are many instances where application and database performance tuning can bring service levels back into compliance, it has been my experience that there are even more application, database, and service level problems that can only be solved from a hardware perspective.
The beauty of a 3PAR solution is that it doesn't lock you into a particular configuration and provides the flexibility to deal with unpredictable application requirements cost-effectively. Using 3PAR, organizations can now align application and business requirements with data service levels easily, precisely, and on demand -- achieving optimal performance and service levels while lowering operational costs.
Leave a comment