There's no doubting that storage virtualisation will prove to be a key component of IT architecture in the future. The overall benefit is to abstract the physical storage layer from servers either in the fabric, or through the use of a dedicated appliance or even in the array itself.
Over time, storage resources can be upgraded and replaced, potentially without any impact to the host. In fact, products such as USP from HDS are sold on the virtues of their migration features.
However at some stage the virtualisation platform itself needs to be replaced. So how do we do that?
The essential concept of virtual storage is the presentation of a virtual world wide name (WWN). Each WWN then provides virtual LUNs to the host. The virtualisation appliance manages the redirection of I/O to the physical device, which also includes responding to SCSI LUN information queries (like the size of the LUN).
Ultimately, the host believes the virtual WWN is the physical device and any change to the underlying storage is achieved without affecting this configuration. If the virtualisation appliance must be replaced, then the virtual WWN could change and this means host changes, negating the benefit of deploying a virtual infrastructure.
As an example, HDS and HP allow USP/XP arrays to re-present externally connected storage as if it is part of the array itself. LUNs can be moved between either physical storage medium (internal or external) without impact to the host. However, the WWN used by the host to access the storage is a WWN directly associated with the USP/XP array (and in fact decoding the WWN shows it is based on the WWN serial number). If the USP is to be replaced, then some method of moving the data to another physical array is needed. At the same time, the host->WWN relationship has to change. This is not easy to achieve without (a) an outage (b) host reconfiguration (c) using the host as the data mover.
There isn't an easy solution to the issue of replacing the virtualisation tool. Stealing an idea from networking, it could be possible to provide a DNS style reference for the WWN with a "name server" to look up the actual physical WWN from the "DNS WWN". Unfortunately whilst this would be relatively easy to implement (a name server already exists in Fibre Channel) the major problem would be maintaining data integrity as a DNS WWN entry is changed and reads/writes start occurring from a new device. What we'd need is a universal synchronous replicator to ensure all I/Os written to an array are also written to any other planned target WWN, so as the WWN DNS entry is changed, it can't become live until a guaranteed synchronous mirror exists. I can't see many vendors agreeing to open up their replication technology to enable this; perhaps they could offer an API for "replication lite" which was used solely for migration purposes while the main replication product does the big replication features.
In the short term, we're going to have to accept that replacing the virtualisation engine is going to have some impact and just learn to work around it.
Monday, 13 October 2008
Replacing the Virtualisation Component
Subscribe to:
Post Comments (Atom)
2 comments:
Ummm Chris, have you heard anything about IBM's SVC??? It has been possible for several years now to add nodes to an existing cluster and remove nodes without disrupting access to data. Furthermore, new nodes can be inserted that will assume the WWN of the node being replaced. So as node technology improves you can continue to upgrade your nodes without losing any access to data. Perhaps you may want to consider this one of the many strengths of an appliance based virtualization approach over a subsystem based virtualization approach.
Try an SVC in front of the USP and things can only get better.
Have a great day.
Chuck
Yes I have!! I wasn't aware of the details of the node migration feature though. Thanks for bringing it to my attention. I've not deployed SVC before so I need to do some reading up!
Post a Comment