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.

The ongoing battle for 3Par by HP & Dell tells us much more about the state of the IT Industry than just the desires of two companies to acquire some interesting storage tech.  It signals an acceptance that storage is a key feature in the future direction of the IT industry – more important than networking and almost as important as the virtualisation platform itself.

This may seem like a bold statement to make, however we need to look forward to where the industry is headed.  First of all, vendors want us to buy their unified hardware stacks; it represents that move back to a consolidated architecture that kept one vendor dominant in the mainframe days – IBM.  “No-one gets fired for buying IBM” the saying goes (or used to go), demonstrating how IBM was seen as the data centre supplier for all things computing in the 70’s and 80’s.  Of course we know that politics within organisations and the cost of IBM hardware eventually broke the monopoly, but the status quo worked well for many companies for many years.

Now, Cisco, EMC, VMware, HP, Oracle and potentially many others want to own your data centre.  They want you bought into their computing stack.  Over time, I suspect many of those same companies want to move you to their cloud infrastructure offerings, even if they don’t offer them today.  This will be both directly and indirectly.  There will be the direct model, where the vendor offers cloud services to you under their name; there will be the indirect model where their technology powers the cloud provider, or is offered as a service.  It’s at this point the 3Par acquisition becomes much more interesting.

3Par already have many customers in the cloud services sector.  In fact they sell their hardware on the virtues of multi-tenancy, reduced cost through thin provisioning, tight integration with virtual hypervisors and so on.  In this growth sector of the industry, cost is a key driver and no end user or company will pay more than they need for storage.  This means Enterprise arrays like those from Hitachi and EMC won’t play a central role in this future, but rather storage devices which provide the highest efficiency will.  Where do all the major players stand?

• EMC have entered the market with a brand new platform – Atmos.  Although withdrawn as a direct service, Atmos continues to be available from partners.  EMC have chosen to use their own technology as the foundation for cloud.  In addition, VPLEX provides the ability to virtualise the storage layer, including federation features that fit well with VMware.
• HP have a strong blade server offering for their cloud infrastructure.  Matrix provides orchestration for the server, network and some parts of the storage layer, however this work is incomplete and doesn’t fit well with the high end XP arrays.  Slotting 3Par into the storage layer would provide a storage platform well suited to HP Converged  Infrastructure.  It means EVA can be quietly dropped and XP can be retained (in whatever future guise) for high end customers (including mainframe) and if required, gradually dropped.
• Cisco have chosen to partner with EMC rather than acquire storage technology itself.  In fact, looking and both EMC and Cisco, they need each other; EMC have no server platform, Cisco have no storage; it’s a mutually beneficial arrangement, a bit like Jack Sprat and his wife.  At this stage, Cisco could have purchased 3Par and provided and end-to-end solution, but clearly that would be a big step and would require kicking EMC to the kerb, something they obviously don’t want to do (yet).
• Hitachi have server and storage offerings, however Blade Symphony is mainly sold in domestic Japan and not widely advertised globally.  They do have the potential to provide an end-to-end offering as Hitachi also sell networking equipment.  Key for Hitachi will be credibility in a market they don’t currently play in.
• IBM should have all the components of a consolidated infrastructure but there doesn’t appear to be a lot of discussion about their offerings.  They appear to have two strategies – Dynamic Infrastructure and Cloud Computing but their offerings aren’t clear.
• Dell clearly wanted 3Par to fit into their medium to high-end storage offerings.  Today Equallogic has successfully met their SMB requirements, but they OEM technology from EMC (CLARiiON and Symmetrix) for the rest.  Acquiring 3Par would remove that dependency and allow Dell to offer end-to-end technology as their own products.
• Netapp have a self-proclaimed unified architecture that does fit well with virtualisation from VMware.  However they don’t own any other parts of the technology stack and so must partner to deliver unified offerings.  Netapp are covering all bases by offering solutions with VMware, Microsoft and Citrix, but none of these could be described as the unified stack other vendors have.
• Oracle already provide an integrated infrastructure based around their Exadata acquisitions and of course all of the Sun Microsystems technology, however I’m not sure many companies would see the Oracle offerings as other than tied directly to their database platform and not for virtualisation.

Overall, 3Par fit the requirements of HP & Dell to provide integrated technology offerings.  The move to the cloud will require leaner and efficient storage products, plus tight integration and orchestration.  It’s all about positioning today for bigger returns tomorrow.

This is a series of post discussing storage array architectures.  Previous posts:

• Choosing Between Monolithic and Modular Architectures – Part I

In the first post, I discussed the shared storage model architectures typified by what we sometimes think of as Enterprise arrays, but I’ve called monolithic.  This term harks back to the mainframe days of large single computers (see Wikipedia definition), hence it’s use to describe storage arrays with a large single cache.  In the last 10 years we have seen a move away from the single shared cache to a distributed cache architecture built from multiple storage engines or nodes, each with independent processing capability but sharing a fast network interconnect.  Probably the most well known implementations of this technology have come from 3Par (InServ), IBM (XIV) and EMC (VMAX).  Let’s have a look at these architectures in more detail.

EMC VMAX

The VMAX architecture consists of one to eight VMAX engines (storage nodes) connected together by what is described as the Virtual Matrix Architecture.  Each engine acts as a storage array in its own right, with front-end host port connectivity, back-end disk directors, cache (which presumably is mirrored internally) and processors.  The VMAX engines connect together using the Matrix Interface Board Enclosure (MIBE), which are duplicated for redundancy.  The virtual matrix enables inter-engine memory access, which is required to provide connectivity when the host access port isn’t on the same engine as the data.  There are two diagrams in the gallery at the end of this post, one showing the logical view of the interconnected engines and the second showing how back-end disk enclosures are dedicated to each engine.

What’s not clear from the documentation is how the virtual matrix architecture operates, other than being based on the RapidIO.  I’m not sure if VMAX engines have direct access to the cache in other engines or whether the processor of connected engines is required.  In addition, can an engine access cache in another engine purely to manage throughput of the local host and disk connections? I’m not entirely sure.

3Par InServ

3Par storage arrays consist of multiple storage nodes joined through a high-speed interconnect.  They describe this as their InSpire architecture.  From 2 to 8 nodes are connected (in pairs) to a passive backplane with up to 1.6Gb/s of bandwidth between each node.  3Par use the diagram shown here to demonstrate their architecture and with 8 nodes, the numbers of connections can easily be seen.  I’ve also shown how connectivity increases in 2, 4, 6 and 8 node implementations.  InServ arrays write cache data in pairs, so each node has a partner.  Should one of the node pairs fail, the cache of the surviving partner is immediately written to another node (if one is present), so protecting the cache data.

The InServ and VMAX architectures are very similar but differ from each other in one subtle but important way.  3Par InServ LUNs are divided into chunklets (256KB slices of disk) that are spread across all disks within the complex.  So as an array is deployed and created, all of the nodes in the array are involved in serving data.  VMAX uses the Symmetrix architecture of hypers – large slices of disk – to create LUNs, with four hypers used to create a 3+1 RAID-5 LUN, for example.  As new engines are added to a VMAX array, the data is not redistributed across the new physical spindles, so data access is unbalanced across the VMAX engines and physical disks.  In this way, InServ has better opportunities to optimise the use of nodes, although within VMAX the use of Virtual Provisioning can help to spread load across disks in a more even fashion.  In addition, a fully configured VMAX array has up to 128Gb/s of bandwidth across the VMA, exceeding InServ’s capacity.

In my opinion the tradeoff here comes down to increased scalability with dedicated nodes versus the latency introduced when data isn’t located on the local node.  In the 3Par model, data is always being accessed across nodes.  In the EMC model, nodes only exchange data when the LUN’s physical disks aren’t located on the local node.  This leads to two problems.  Firstly, as more nodes are added, the number of node<->node connections increases exponentially.  For an 8-node array, there are at least 28 node to node connections (not including additional connections for redundancy).  This increases to 120 for 16 nodes (nearly 6-fold increase in connectivity for double the nodes) and nearly 500 connections for 32 nodes, to which VMAX can theoretically scale.  The second issue is that of diminishing returns.  As more nodes are added, more overhead is required to service data not found on the local node.  This leads to a situation where the benefits of adding additional nodes are so small to make it not worth doing.

IBM XIV

The IBM XIV array takes a different approach to node configurations that are directly connected to the underlying data protection mechanism of the hardware.  XIV uses only RAID-1 style protection, based on 1MB chunks of data known as partitions.  Data is dispersed across nodes in an even and pseudo-random fashion, ensuring that for any LUN, data is written across all nodes.  The architecture is shown in the XIV picture in the gallery at the end of this post.  Nodes (known in XIV as modules) are divided into interface and data types.  Interface modules have cache, processors, data disks and host interfaces.  Data modules have no host interfaces but still have cache, processors and disk.  Each module has twelve (12) 1TB SATA drives.  As data is written to the array, the 1MB partitions are written across all drives and modules ensuring that the two mirror pairs of any single partition do not reside on the same module.  Sequential partitions for a LUN are also spread across modules.  The net effect is that all modules are involved in servicing all volumes and the loss of any single module does not cause data loss.

Whilst XIV might be tuned for performance, there is still the inherent risk (however small) that a double disk failure results in a significant data loss, as all LUNs are spread across all disks.  Additionally the XIV architecture requires that every write operation must go through the Ethernet switches as data is written to the cache on the primary and secondary modules before being confirmed to the host.  As a consequence, overall bandwidth of a single module will be limited to the available network capacity, which is 6Gb/s for interface nodes and 4Gb/s for data nodes.  This value halves if either of the Ethernet switches fails.

Summary

The multi-node storage arrays on the market today are all implemented in slightly different ways.  Each has positive and negative points that contribute to the overall decision on which platform to choose for your data.  Whether any of them are suitable for “Enterprise” class data is an open question that continues to be the subject of much debate.  From my perspective I would want a “tier 1″ storage array to provide high levels of availability and performance, something each of these devices are capable of achieving.

Next I’ll discuss modular arrays and the benefits of dual controller architecture.

The recent proposed acquisition of 3Par by Dell and/or HP has made me think a little more about the direction the storage industry is taking in terms of their storage array design architecture.  Since storage arrays became a category of devices in their own right, we’ve seen the growth of the monolithic, sometimes called Enterprise storage array.  Hu Yoshida discusses the subject on one of his recent blog posts.  Looking at the wide range of storage devices, I’ve categorised arrays into the following groups:

• Monolithic – this architecture is characterised by Hitachi USP, HP XP & EMC DMX and consists of a shared memory architecture and multiple redundant components.
• Multi-Node – these devices use loosely coupled storage “nodes” with a high-speed interconnect providing scalability by adding extra nodes to the storage “cluster”.  Products in this category include EMC VMAX and 3Par InServ.
• Closely Coupled Dual Controller – this is the typical “modular” storage architecture characterised by IBM DS8000, EMC CLARiiON, Hitachi AMS and HP EVA.
• Loosely Coupled Dual Controller - this category describes technology that are capable of device failover but aren’t closely coupled to enable individual LUN failover as the Closely Coupled model permits.  This category is characterised by arrays such as Netapp FAS filers and Compellent Storage Center.
• Single Controller – this category covers devices that act as standalone products, including SOHO storage devices such as the Iomega IX4 & Data Robotics Drobo series.

The above list isn’t exhaustive and it’s my own personal categorisation.  There are many more vendors of technology than I’ve listed here.  In addition, none of these lists qualify as “Enterprise” in their own right.  The use of this term is a hotly debated subject.

Monolithic Architectures

EMC DMX High Level Architecture

Monolithic arrays use a shared cache architecture to connect front-end storage ports to back-end disk.  This is shown clearly in the architecture diagrams shown here, representing the internal connectivity of the EMC DMX  and Hitachi USP storage arrays.  Each of the memory units is connected to each of the front-end directors and the back-end disk directors.  Hitachi divide their cache into two halves for Clusters 1 & 2 in the array; EMC have up to eight cache modules.  This architecture has positive and negative benefits; firstly having director connections connecting to all cache modules ensures resources aren’t fragmented;  unless cache becomes completely exhausted there’s always connectivity to another cache module to process a user request.  It also doesn’t matter on which port that request comes in; the cache module can process any request from any port to any back-end disk.  This connectivity is also beneficial in terms of failure.  If a cache module fails, for example, only the cache on that module is lost; in a fully deployed architecture the total cache would drop (by 1/8th in EMC’s case), but front and back-end connectivity would remain the same.  With this model it is possible pair up storage ports and have a single LUN presented from 1 or more ports with no performance impact; the path length between a storage port and disk adaptor will always be the same.

This any-to-any model also has disadvantages.  The connectivity is complex and therefore becomes expensive and requires overhead to manage and control the interaction between the various components.  In addition, there’s a limit to the practical scalability of this architecture.  With eight FE, BE and cache modules, there are 128 connections in place; (8×8x2).  Adding a single cache module requires an additional 16 connections; similarly, adding more front or back-end directors requires more connectivity.  Also monolithic arrays are based on custom components and custom design, increasing the ongoing maintenance and development costs for the hardware.

One other point to remember; front and back-end directors have their own processors.  It is possible for the traffic across the directors to be unbalanced and for some processors to be more heavily utilised than others.  I’ve seen a number of configurations where USP V FED ports are running at 100% processor utilisation due to to small block sizes.  This means manual load balancing is required both in initial host placement and subsequently as traffic load increases.  This fact is worth bearing in mind as we move to more highly virtualised environments as it is likely host port utilisation will start low and rise over time as more virtual machines are created.

Hitachi USP High Level Architecture

Now that the DMX platform has been put out to pasture in place of VMAX, it appears Hitachi are the only vendor continuing down the monolithic route.  Next time I’ll discuss Multi-Node arrays and why they may (or may not) be a replacement for today’s monolithic devices.

So there we have it.  A week after Dell announce their intention to acquire 3Par, HP put their cards on the table and trump the Dell bid with an updated offer of $24 a share.  This represents a 1/3 increase over the Dell $18/share offer.

HP have been pretty acquisitive in the storage arena over the last few years, acquiring LeftHand, Ibrix and others.  Why now would they want to acquire 3Par?

• Defensive positioning – 3Par being acquired by any of the major vendors could weaken HP’s position in the mid-to-enterprise market.  EVA is a fading product and unlikely to be the first choice for many organisations when choosing a mid-tier storage array (unless you’re an out and out HP shop of course).  Maybe HP felt they had to protect their existing mid-market position.
• Technology Replacement - As I just mentioned, the EVA looks long in the tooth.  Should HP replace or upgrade it?  Acquiring 3Par could be the answer to that problem – use InServ as the EVA replacement.  Goodbye EVA.  Alternatively, 3Par could be a replacement for the XP range of devices that HP OEM from Hitachi.  HDS are being brought closer to the Hitachi family (and making acquisitions of their own) so perhaps this is another defensive move on HP’s part, in case the Hitachi deal unravels.

Whatever the reason, HP & 3Par would create a large overlapping portfolio of similar products.  I’m not sure where the clear strategy would be, or what the marketing message would say; which product is best for enterprise, mid, SME and so on.

Final thought:  Will Dell rebid at a higher price?  Will anyone else come into the bidding?  Storage is clearly still hot acquisition territory.

I’ve added a new section to the site, which you can find at the top of the navigation bar – “Storage White Papers“.  The selections are free, specifically storage orientated and here are a few examples to get you started:

• Create a Smarter Storage Strategy
• Availability and the Cloud
• The Economic Impact of File Virtualisation: Reducing Costs and Improving Efficiency for File-Based Storage

These are vendor sponsored and you’ll need to register (which is the tradeoff for them being free).  Please let me know what you think if you download any of these white papers.

Disclaimer: I receive a small fee for whitepaper subscriptions as part of this service.  This will go towards running the site, which, due to traffic is now increasing in expense.

There’s nothing like a bit of surprise (ish) tech news to generate an off the cuff quick post; here’s today’s tidbit.  Dell are to acquire 3Par.

Clearly the Farley Curse has struck again and for a mere $1.15 billion Dell plugs another gap in their storage portfolio.

Let’s face it, Equallogic was good, but not high end enough.  3Par technology can span the medium and large enterprises leaving Equallogic to overlap the SMB market.

I think this could be great deal for both companies; 3Par get validation of their story and of their continued rise in customer base and access to even more customers.  Dell get to plug their higher end storage strategy with a great product and move further away from the EMC dependency.

What else could be coming up? A Dell Unified Computing Strategy based on 3par?  That would be interesting.

As I said, this is a quick post pending more thinking and reading.  In the meantime please give @3parfarley all the ribbing he’s requested, before he concedes and changes his twitter handle to @dellfarley….

I’ve twice posted now on Data ONTAP 8.0 shortcomings and this evening I did a little more research with the IBM version of Netapp’s hardware, the N-Series products.  Fortunately, IBM are slightly more generous and informative in their documentation than Netapp and this document (freely available online) provides more background information on the “DOT8″ transition process.  So, I’ve tried to produce a more in-depth objective view of the steps to move to “DOT8″.  Firstly the following diagram provides a clue as to how Data ONTAP has migrated to the current release.

Data ONTAP History

At the point of reaching DOT8, Data ONTAP has been re-written to run off FreeBSD as the original GX code did.  This is a departure from the original Berkeley Net/2 code as documented in this post from Dave Hitz.  I have no idea how much of this version of the code was a re-write, but presumably porting over WAFL with all the bells and whistles it now has wasn’t an easy task.  This may go towards explaining why the current release of ONTAP took so long to come out.

Although the diagram shows the code base as being a single product, it isn’t.  There are still two modes, 7-mode, emulating  7G and cluster-mode emulating the GX product line.  These modes are non-interchangeable; you choose the one you want to use at system installation time and it’s fixed; no chance to change in the future.  As the IBM document explains (quote) “If a customer decides to change from one mode to another, the change is a transition rather than an upgrade (or downgrade).  Dual boot capabilities are not present, so the transition requires total reconfiguration of the storage system.  This can include backup and restore of user data”.

I think it would have been fairer to draw two parallel lines here as it appears there are still to pretty separate versions of code masquerading as a single marketing version.  So, the remainder of this discussion focuses on 7-mode.

Upgradeability

What happens if you want to take an existing system and upgrade it?  Well, depending on your hardware, you may or may not be able to perform an upgrade.  Systems such as the 6xxx models, 3×70 & 3×40 models are upgradeable, devices such as the 2050 are not.  There are also restrictions on the disk shelves that can be used too.  Should you choose to upgrade from your current 7G release, you can only move to 7-mode or build a new 8.0 installation, presumably on new hardware as you wouldn’t want to trash your existing environment.  Be aware though, that upgrade actually removes certain features.  For instance, SMB 2.0, IPv6 & IPSec are not supported.  They will reappear in a future release.  Does this mean writing these features in the ported version of WAFL was too hard or was taking too long?  Why else would you remove features from an upgrade only to replace them later?  One final upgradeability gotcha – Performance Acceleration Modules (PAM) are not supported with the initial version of 8.0.

Aggregates

As mentioned in my previous post, aggregates move to 100TB in size.  However there are many restrictions.

• Volume SnapMirror will not replicate between unlike aggregate types; so you can’t replicated to/from 32-bit to 64-bit aggregates.
• aggr copy and vol copy commands will not work between different formats.
• Flexvol size for volumes using de-duplication in 64-bit aggregates is limited to 16TB
• System root volumes can only reside on 32-bit aggregates.

On the positive side, Qtree SnapMirror and SnapVault do work between aggregate formats.

Aggregate Migration

Here’s IBM’s statement on migration of data: “Currently there is no direct migration path or conversion from 32-bit to 64-bit aggregates.  The following options can be used to migrate the data: qtree SnapMirror, SnapVault, ndmpcopy”. Each of these options also has limitations, which I don’t have time to go into, but you can read in the referenced document.

Benefits

I’ve been trying to find any benefits of upgrading to DOT8 from the customer’s perspective. For new installations, the increased aggregate size is obviously a benefit, but does come with restrictions.  There are now interface groups rather than VIFs and it appears snapshots can now be named.  Excluding these, I can’t see that DOT8 is anything more than a positioning exercise as Netapp continue to get the real features they wanted in this version into future releases.  This has been hinted at by other commentators.

Whilst I can see the benefits to Netapp of this move, I fail to see the benefit to the customer, who will have to suffer major migration headaches to realise what are small improvements from a major version upgrade.  I suspect many customers will chose to wait for 8.0.1, 8.1 or whatever version actually integrates the real improvements.  During that time, it offers more opportunities for the competition to be snapping closer to Netapp’s heels.

This is a series of posts on the Promise SmartStor NS4600 home storage server.  Previous posts:

• Hardware Review: Promise SmartStor NS4600 – Part I
• Hardware Review: Promise SmartStor NS4600 – Part II

In this post, we will discuss file layout, formats and protocols available on the NS4600.  The previous post (above) discussed how RAID is constructed across physical disks.  Multiple volumes can be constructed from the disks available in the system (subject to a disk being dedicated to only one volume).  Above this layer sits the file system and logical iSCSI devices.

Filesystem Status

The first screen shot shows the normal status of a file system.  In this example there are two drives paired together in a RAID-1 mirror, providing approximately 1675GB of storage space.  At present only around 1442GB of space as been allocated to the file system, with some 187GB of free capacity still available.  At first it may not seem obvious why all the available space shouldn’t be allocated to the file system, however the answer is simple; standard NAS file space and iSCSI LUNs sit beside each other together on the RAID volume.  Therefore as a file system is created, it can be sized as required, allowing future expansion as either additional file space or as iSCSI LUNs.  The creation of the iSCSI LUN is shown in subsequent screen shots, highlighting the initial available 187GB of space, followed by the creation of two 50GB iSCSI LUNs, reducing the available space to 87GB.

Mixing data types on the same RAID set would not necessarily be best practice on a medium-tier or enterprise-class array; fortunately the ability to create multiple volumes enables some disks to be dedicated to file and others to block-level access, simply by creating multiple volumes.  Of course the main restriction is only having 4 drives to play with, however the underlying architecture enables multiple configurations to be created and potentially in the

future, should Promise choose to create larger devices, would offer the fundamentals for sensible data segregation.  In any event, for single CPU, single NIC devices like the NS4600, high performance isn’t likely to be the main purchasing consideration and mixing file and block data on the same RAID group shouldn’t pose a problem.

Protocols

For file data, the NS4600 provides Windows, Mac, FTP and Unix connectivity.  See screenshot 9 in the gallery at the end of this post.  Protocols can be turned on/off system-wide or specified for each file share.  For Windows, the server is able to connect to an Active Directory domain.  This may not be everyone’s first choice but in a small office, centralising security is an essential requirement – I always look for Active Directory support as it simplifies my home lab setup.  Mac settings are pretty simple; on or off, with the ability to issue a message to connecting systems.  FTP is similarly simply specified and for Unix/Linux connectivity, the NS4600 can be connected to a NIS domain.  It also seems possible to connect a share to both a NIS domain and AD at the same time.  Now, unfortunately I don’t run NIS so couldn’t test this; however specifying two security domains does throw up issues of consistency and questions around which security model “wins” in the event of a conflict.  There doesn’t appear to be any way to specify userid translation as there is in Data ONTAP for example.

Creating shares and using onboard security is straightforward.  The screenshots in the gallery at the end of the post highlight how this is achieved.  File shares can be created under the root of a volume and assigned permissions based on internally connected users, or on imported users from external sources like AD.

Ok, now we have the file system basics out of the way, the next two (and final posts will be more interesting).   Next I’ll discuss backups and replication and the final post will look at the NS4600 as an application server and the other features it offers.

Well, it appears from comments on recent blog entries that I’m all of the above!  The post(s) in question are as follows;

• http://www.thestoragearchitect.com/2010/08/02/netapp-the-inflexibility-of-flexvols/
• http://storagebod.typepad.com/storagebods_blog/2010/08/and-bod-makes-three.html
• http://www.grumpystorage.com/2010/08/notapp-random-thoughts.html
• http://blog.nigelpoulton.com/netapp-some-good-and-some-errrrr/

I thank those who have made positive comments on my behalf, it is most appreciated.  I find it even more amusing that my style of writing has been described as tabloid.  Perhaps I need a few more appropriate blog titles.  How about the following: Netapp ate my Hamster or Gotcha! (when EMC outbid Netapp for Data Domain).

The things I write about are coloured by the work I do – which is for and on behalf of customers.  It’s my job to cut through the marketing hype and understand the real issues in deploying and managing technology in the most efficient and cost effective way.  No vendors are without faults and I can point to many posts that place each vendor in a negative light.  However in my defence where I see something I like, I also talk about it.  If you don’t like what I write, I urge you to unsubscribe now.  If you do like what I write about, I’d appreciate your views on what else you’d like to see me discuss.  If you have something to say, then leave a comment that can be treated as courteous.  I always post comments – apart from the SPAM ones.  I’m happy to discuss things in a reasoned manner and to admit when I’m wrong.  You never know, if we continue in that manner we all may just enjoy the blogosphere more.