by Hu Yoshida on Mar 23, 2010
One of the objectives of storage virtualization is to separate the management of the physical storage from the application, the server, and the network view of the storage, so they can continue to operate while the storage is refreshed, tuned, migrated, maintained, replicated, or replaced. It also creates a common pool of storage resources which can be securely shared by many applications.
On the one hand the application users are freed from worrying about the physical characteristics of their storage and can enjoy the lower costs that come from sharing a consolidated pool of shared storage resources, but on the other hand, they will not know where their physical data resides and how it may be impacted by changes to the pool or by other applications that are sharing that pool of storage.
While storage administrators have many tools to manage and report on the infrastructure as a whole, application users are only interested in the health and performance of their data storage. They need transparency into the virtual storage infrastructure from a business perspective to see that their service level objectives are being met. All the information is available in the infrastructure tools. They just need to be mapped into a business view.
The way Hitachi Data Systems does this is through the Hitachi Storage Command Suite, an integrated suite of management tools. It starts with a Device Manager that does a deep dive into the storage and a Link Manager that reports on the links from the servers. Over this base is a Performance Tuning Manager that monitors the Device and Link managers, reports on their status, and provides alerts to a policy manager for tiered storage or to a replication manager for business continuity. Up to now, this is all about infrastructure. Over all this is a Command portal that gives a business view.
The Hitachi Command Portal provides a simple dashboard tailored to a business unit, that shows the status of their Service Level Objective (red, yellow or green), their actual allocation of storage, the health of their storage ports and array group (red, yellow, green), and their allocation trend line. In the example shown below, the business unit is “Exchange EMEA Corp-Production”. Their Service Level Objective status in the last 24 hours is green. Their Subsystem Health during that same time period for their array groups and storage ports were all green. Their physical storage allocation is identified by location, by type, by RAID group, and by total allocation. Their storage allocation trend is also shown for the last 24 hours.
Virtualization of storage does not have to mean that business units have to lose all visibility into the actual allocation and performance of your own individual slice of the virtual pie. There are tools like the Hitachi Storage Command Suite that can provide that virtualization transparency.
Virtualization Transparency is only a temporary stop gap solution to identify bottlenecks and performance problems. What is needed from Server and Storage vendors is either some mechanism for QoS or a end to end IO Virtualization.
Right now we virtualize servers to enable server consolidation and we virtualize storage mainly to enable tiering. However it looks like the industry forgot about the IO lanes from the server to the storage.
Current NPIV and QoS standards attempt to resolve this in a software stack. What is required from the HBA perspective is the ability to partition it into IO lanes so that each VM has a separate queue that is processed by the CPU and sent out to the Storage Array. These IO lanes could be graded so that QoS can be enabled.
On the Storage front the CPU treats all IO as equal and this can be fixed by implementing IOV within the storage array and grading the IO lanes to enable QoS.
Such an architecture will enable fair sharing of IO lanes between server and storage and also “True” QoS.
Virtualization Transparency is good for identifying configuration issues but does make troubleshooting performance problems any easier. What is required is the missing piece of the virtualization puzzle – Single root IOV and multi root IOV.