I recently wrote an article covering storage for virtualisation and was surprised to find out that Microsoft does not support the use of NFS shares with Hyper-V.  At first I thought perhaps I was doing something wrong and that my configuration was in error.  But after a lot of [...] ]]>

I recently wrote an article covering storage for virtualisation and was surprised to find out that Microsoft does not support the use of NFS shares with Hyper-V.  At first I thought perhaps I was doing something wrong and that my configuration was in error.  But after a lot of lab testing and eventually finding some obscure forum posts, I’ve concluded that NFS cannot be used for storing Hyper-V guests.  But why?

Client for NFS

Microsoft has supported an NFS server and client within Windows for some time.  In Windows Server 2008, the Client for NFS can be added through the “Services for Network File System” role.  This creates a new MMC plugin on the start menu that allows administration of both Client and Server services for NFS.  From that point on there’s not much to configure in the GUI and all NFS shares are mapped via the command line, or within WMI for Windows Server 2008 R2 (look for future posts describing NFS installation and configuration).

Hyper-V Fail

Any attempts to create Hyper-V guests fail with the error code shown in the screenshot attached.  I’ve tried lots of options; pre-creating the VHD, importing the guest and so on, however all fail to allow a VHD to be created.  Where does this leave me?  Well, I can fall back to standard block-based Fibre Channel and iSCSI LUNs but this is potentially limiting if I’m looking to be more efficient with my Hyper-V installation.  SCVMM 2012 for instance assumes I’m storing VMs on an entire single LUN as it uses LUN snapshots to replicate virtual machines.  To make this kind of configuration work best, I’d need a storage system that does LUN level thin provisioning; this escalates my costs somewhat.

So the question is, why would Microsoft put in such a restriction?  It’s not as if network share-based guests are totally banned as I can use CIFS to store them.  Of course I wouldn’t want to do that because CIFS has some severe performance and integrity limitations that make it unsuitable.  Perhaps it’s just that Microsoft still don’t “get” storage.  After all, the latest recommendations for Exchange 2010 are to use DAS.  Redmond needs to embrace the use of storage agnostic connectivity for Hyper-V; it’s these kind of features that keep VMware ahead and for many will make ESXi a preferred option.

Hitachi have modified the VSP array to provide significant performance improvements over the previous USP [...] ]]> This is a series of posts that cover the features of Hitachi’s new enterprise storage platform, the VSP (Virtual Storage Platform), also sold by HP as the P9500 array.  Previous posts:

• Hitachi Virtual Storage Platform: Disk Drive Architecture

Hitachi have modified the VSP array to provide significant performance improvements over the previous USP and USP V models.  These changes may not be immediately significant but are worthy of discussion, as with any new technology, the devil is in the detail.  As a background to this post, I suggest you read my previous discussion on Monolithic v Modular architectures.

USP V Ports

Hitachi USP High Level Architecture

The USP V array design (reproduced here in schematic format) consists of a central switched architecture with both shared memory and cache.  Processing takes place on FEDs (Front-End Directors) and BEDs (back-end directors) that take care of host and disk I/O respectively.

Front-end processors are shared between port pairs, so for example on a 16-port front-end card there are 8 processors.  It is typical to see scenarios where either the port bandwidth or the port processing power is fully utilised.  For example, with very small blocksize I/O, a FED processor can be max’ed out.  This requires the storage administrator to be aware of host I/O profiles and distribute workload accordingly, or risk performance impact as ports are loaded up with hosts.  This fixed design isn’t desirable (in any array) and in fact when external storage virtualisation is used can result in the over-purchase of storage ports purely to ensure sufficient capacity is available; bear in mind that port pairs (i.e. the processor) can only have one identity, either host port, external port, or source/target port for replication.

VSP Ports

The VSP changes the FED/BED architecture by sharing the processors for use across all physical ports.  This is shown schematically in the following diagram (reproduced from Hitachi presentation – I will be working on a better representation).  Port processors are now on the Virtual Storage Directors (VSDs).

By decoupling the physical port and processor, the VSP provides the ability to maximise both port and processor utilisation; it enables the driving of more work through the array.  This is a key benefit when virtualisating external storage, as the static nature of the previous design has been overcome, so more storage can be externalised.

VSP Architecture

There is also an additional benefit to abstracting ports and processors; as firmware/code upgrades are performed on the VSP, there is no need to worry about path failover.  Typically, code upgrades temporarily disrupt I/O to hosts.  This isn’t usually a problem as production environments dual-path all connections, however if connectivity problems exist, then code uploads can cause host outages.  This doesn’t occur with the VSP.

Futures

Although processor sharing is a simple change, it has wider implications; array performance is improved and made more efficient and this improves the ability to manage variable workloads.  However, the change also provides a basis for future enhancements that could be even more compelling.  Virtualising processor workload introduces the ability to:

• Implement QOS (Quality of Service) on I/O requests.  Although basic server prioritisation occurs today, full virtualisation enables real QOS to be implemented on I/O workload in a much more granular fashion.
• Implement Multi-tenancy.  The USP V already offered workload segmentation through Storage Partitions (SLPRs) and Cache Partitions (CLPRs).  The VSP has the ability to create virtual partitions that are also prioritised in terms of workload.  This meets requirements of organisations to offer secure multi-tenancy without having to dedicate physical hardware.

Hitachi have moved forward by producing a platform that is more scalable and potentially offers future enhancements for highly scalable environments.  Although the VSP is a step up from USP, looks to me like only a single step on an evolving journey.

Create a Smarter Storage Strategy

http://thestoragearchitect.tradepub.com/free/w_fnet24

Availability and the Cloud

http://thestoragearchitect.tradepub.com/free/w_fnet22/

The Economic Impact of File Virtualization: Reducing Costs and Improving Efficiency for File-Based Storage

http://thestoragearchitect.tradepub.com/free/w_fnet09/

As usual I welcome any feedback as to whether this part of [...] ]]> There are three new white papers available on the site that may be of interest.  They are:

Create a Smarter Storage Strategy

http://thestoragearchitect.tradepub.com/free/w_fnet24

Availability and the Cloud

http://thestoragearchitect.tradepub.com/free/w_fnet22/

The Economic Impact of File Virtualization: Reducing Costs and Improving Efficiency for File-Based Storage

http://thestoragearchitect.tradepub.com/free/w_fnet09/

As usual I welcome any feedback as to whether this part of the site is useful.

Disclaimer:  For each subscription I receive a payment which goes to fund the running of this site and www.thevirtualisationarchitect.com.  This includes covering the costs of trial subscriptions to cloud services.

In [...] ]]> I’m in the process of migrating my existing physical infrastructure into a virtual environment. There’s nothing like “eating your own dog food” (there’s got to be a better expression than that) for testing out your beliefs on how technology should be implemented, so it’s only fitting I virtualise the IT infrastructure I rely on.

In summary, I run a “production” Windows AD domain, Exchange, IIS and file services. This is a typical scenario for many small businesses, with perhaps a few variations thrown in for good measure, such as SharePoint. I’m moving to a virtual environment that is built on ESXi v4.0, a custom design Intel-based server with 2x Quad Core Intel 5420 processors and 16GB of memory. Local hard drives include 2x SAS 7.2K 500GB drives and 2x 73GB SAS 15K drives.

Storage Choices

The first question I posed for my infrastructure is to decide on a storage platform. As this is a SOHO type deployment, I don’t have the luxury of a fibre channel SAN environment. I expect that many SMBs will feel the same and not want to commit to fibre channel deployments when the alternative options out there are low cost and probably more suitable. Therefore here are my choices:

• Internal drives. I have over a terabyte of internal storage but unfortunately its not RAID protected. The disks are deployed on SAS connectors on the motherboard rather than through a dedicated RAID card. Although I could change the configuration and include a card, there are a number of issues; (a) increased cost (b) downtime to replace failed drives (c) physical intervention and downtime on the server to replace drives. My goal is to deploy this infrastructure to run 24×7, so having to take the system down to replace a drive is not an option. I also think that internal drives wouldn’t give me the scalability I might need.
• iSCSI. In this environment, iSCSI is a great solution; there are lots of SMB iSCSI solutions on the marketplace today, offering low cost storage with simple operations. iSCSI is definitely a possibility.
• NAS. Using NAS (more specifically NFS) for storage on VMware provides lots of flexibility. The management of the filesystem itself moves to the NAS hardware and so any VMware host files appear as standard files on the NAS device. When people see this, they usually get the “light bulb moment” as they realise the possibilities this kind of deployment offers. Whole virtual machines can be cloned, backed up or even simply copied as files around the infrastructure. NAS offers easy access to log and configuration files too.

So, for me the choice is NAS. I have iSCSI deployed, but for my production environments, NAS will be used to store my VMware hosts. This is for a variety of reasons, however there’s one additional benefit I haven’t discussed and that’s portability. Placing my vmdk’s on NAS means I can move them around at will. I can replicate them, I can back them up and I can move them easily to another NAS device without using ESXi as the data mover.

Stay tuned for more discussions as I evolve my setup.

T5 is Heathrow’s new flagship terminal and the dedicated home for British [...] ]]> The day has finally arrived and I’m sitting in the BA Lounge in Terminal 5.  As with any long distance trip I have that usual mixture of trepidation and excitement, especially when travelling to a place I haven’t visited before.

T5 is Heathrow’s new flagship terminal and the dedicated home for British Airways.  Unfortunately, my experience to date travelling to and from T5 has been less than spectacular.  So far, today things seem to have been a little easier.

So, looking forward to the remainder of today, what can I expect to be in store for me and the other Gestalt IT attendees?

Well, after landing and heading off to the hotel, we’ve dinner planned for 7pm with a chance to catch up with everyone.  Of course for us UK folk, that will already be 3am UK time.  We then have to leave the hotel by 7am the next morning – yes 7am to go to the VMware offices.  It’s pretty clear that we’re going to have a busy time.

I’ve compiled a list of some of the things I’m hoping to achieve or learn about whilst I’m here.  I know some of the vendors; others I have no knowledge of at all.  Here’s what I’m looking for:

3Par – information on the new “Thin built-in” technologies, which were just supported in software; real world calculations on TP savings; array clustering; solid state and block-level tiering; VMware integration; vStorage API support; CLI/API interfaces.

Data Robotics – more information on proprietary RAID; management framework integration; hot swap operation (graceful rather than forced); futures (larger devices, rack mount, FC(oE) support); DroboShare futures (AD integration, iSCSI support)

Nirvanix – CloudNAS; security; block and file protocol support.

Ocarina – Value proposition (cutoff where de-dupe savings recoup hardware investment); platform integration (e.g. BlueArc); compression ratios; data replication between archives; imgestion rates; ingestion methods.

Xsigo – market positioning – fabric or array; perceived competition; TCO/value proposition.

Whatever happens, I’m sure it will be a fascinating trip.  Look out for more updates here and on Twitter (@chrismevans)!