for the storage requirements. While
being the simplest method due to the fact
that no sub-system alterations have to be
implemented, it is not practical for larger
organisations with substantial storage
requirements and even larger data
centres, due to the operating costs
associated with single storage server
management.
The answer to the eternal question of
storage capacity inevitably lies in the
consolidation of resources and therefore
the virtualisation of available storage
facilities. Big is not necessarily best. By
deploying storage virtualisation
architecture, an organisation can avoid
the capital expenditure that results from
constantly purchasing extra hardware
when there are already vast amounts of
unused storage potential available, as
well as delaying the need to physically
expand the data centre size in order to
incorporate unnecessary equipment.
Ongoing costs are also minimised by
simply powering fewer storage servers,
therefore minimising carbon footprint
and saving on man-hours by introducing
a degree of automation to a process, that
is already designed to maximise its own
potential.
has granted storage authorisation, the
data can use the entirety of the fibre
optic SAN bandwidth without
interference from its control. The LSI
StoreAge SVM solution is a good
example. It results in better utilisation of
the SAN bandwidth, as well as excellent
scalability and storage consolidation, and
the ability to pool products from different
vendors in one unified virtual partition.
This solves the `bottlenecking' issue,
however does require each host device to
utilise a new set of drivers that allow
them to recognise the metadata
controller and establish the separate
control path.
Host-based
Host-based storage virtualisation is the
final option to consider. Each host
electronic device or application has its
own virtual `storage focused' interface
that allocates both the core data and its
control. However this requires the
installation and management of
specialist software on every relevant
server, often at the operating system
level. This technique utilises age old
volume managers to present the storage
pool and then divide it up as necessary
management device to sit between all the
applications or host electronic devices
and the server area network (SAN). Host
devices only have to query the
virtualisation appliance to find where on
the virtual drive the data is stored. The
appliance then redirects the host device
to the relevant storage unit. However, the
disadvantage with this method is the
associated bottleneck of requests that can
build up (if the throughput of the device
is limited), increasing network latency as
a by-product. It therefore becomes
necessary to make sure your
virtualisation appliances are at least as
fast as your fastest storage device.
Out-of-band
The second architecture type essentially
works in the same way as in-band, with a
device manager sitting between the SAN
and the applications. However this
separates the data and metadata into
different strands, both of which are
saved in different locations. The
applications then `seek permission' from
the metadata controller which advises
exactly where its accompanying data is
saved. The advantage of an out-of-band
system is once the metadata controller
ITadviser Winter 2009 39
virtualisation
The author
David Galton-Fenzi,
Zycko UK

Page 1Page 2Page 3Page 4Page 5Page 6Page 7Page 8Page 9Page 10Page 11Page 12Page 13Page 14Page 15Page 16Page 17Page 18Page 19Page 20Page 21Page 22Page 23Page 24Page 25Page 26Page 27Page 28Page 29Page 30Page 31Page 32Page 33Page 34Page 35Page 36Page 37Page 38Page 39Page 40Page 41Page 42Page 43Page 44Page 45Page 46Page 47Page 48Page 49Page 50 Produced by PageSuite