Your are here: Home > Blog

What the Heck Is a “Storage Hypervisor?”

August 25th, 2011 | Posted by Sid Herron in DataCore | Storage | Virtualization - (0 Comments)

Our friends at DataCore ran a press release yesterday positioning the new release (v8.1) of SANsymphony-V as a “storage hypervisor.” On the surface, that may just sound like some nice marketing spin, but the more I thought about it, the more sense it made – because it highlights one of the major differences between DataCore’s products and most other SAN products out there.

To understand what I mean, let’s think for a moment about what a “hypervisor” is in the server virtualization world. Whether you’re talking about VSphere, Hyper-V, or XenServer, you’re talking about software that provides an abstraction layer between hardware resources and operating system instances. An individual VM doesn’t know – or care – whether it’s running on an HP Server, a Dell, an IBM, or a “white box.” It doesn’t care whether it’s running on an Intel or an AMD processor. You can move a VM from one host to another without worrying about changes in the underlying hardware, bios, drivers, etc. (Not talking about “live motion” – that’s a little different.) The hypervisor presents the VM with a consistent execution platform that hides the underlying complexity of the hardware.

So, back to DataCore. Remember that SANsymphony-V is a software application that runs on top of Windows Server 2008 R2. In most cases, people buy a couple of servers that contain a bunch of local storage, install 2008 R2 on them, install SANsymphony-V on them, and turn that bunch of local storage into full-featured iSCSI SAN nodes. (We typically run them in pairs so that we can do synchronous mirroring of the data across the two nodes, such that if one node completely fails, the data is still accessible.) But that’s not all we can do.

Because it’s running on a 2008 R2 platform, it can aggregate and present any kind of storage the underlying Server OS can access at the block level. Got a fibre channel SAN that you want to throw into the mix? Great! Put fiber channel Host Bus Adapters (HBAs) in your DataCore nodes, present that storage to the servers that SANsymphony-V is running on, and now you can manage the fibre channel storage right along with the local storage in your DataCore nodes. Got some other iSCSI SAN that you’d like to leverage? No problem. Just make sure you’ve got a couple of extra NICs in the DataCore nodes (or install iSCSI HBAs if you want even better performance), present that iSCSI storage to the DataCore nodes, and you can manage it as well. You can even create a storage pool that crosses resource boundaries! And now, with the new auto-tiering functionality of SANsymphony-V v8.1, you can let DataCore automatically migrate the most frequently accessed data to the highest-performing storage subsystems.

Or how about this: You just bought a brand new storage system from Vendor A to replace the system from Vendor B that you’ve been using for the past few years. You’d really like to move Vendor B’s system to your disaster-recovery site, but Vendor A’s product doesn’t know how to replicate data to Vendor B’s product. If you front-end both vendors’ products with DataCore nodes, the DataCore nodes can handle the asynchronous replication to your DR site. Alternately, maybe you bought Vendor A’s system because it offered higher performance than Vendor B’s system. Instead of using Vendor B’s product for DR, you can present both systems to SANsymphony-V and leverage its auto-tiering feature to automatically insure that the data that needs the highest performance gets migrated to Vendor A’s platform.

So, on the back end, you can have disparate SAN products (iSCSI, fibre channel, or both) and local storage (including “JBOD” expansion shelves), and a mixture of SSD, SAS, and SATA drives. The SANsymphony-V software masks all of that complexity, and presents a consistent resource – in the form of iSCSI virtual volumes – to the systems that need to consume storage, e.g., physical or virtual servers.

That really is analogous to what a traditional hypervisor does in the server virtualization world. So it is not unreasonable at all to call SANsymphony-V a “storage hypervisor.” In fact, it’s pretty darned clever positioning, and I take my hat off to the person who crafted the campaign.

, ,

DataCore Lowers Prices on SANsymphony-V

April 22nd, 2011 | Posted by Sid Herron in DataCore | High Availability | Storage | Virtualization - (0 Comments)

Back at the end of January, DataCore announced the availability of a new product called SANsymphony-V. This product replaces SANmelody in their product line, and is the first step in the eventual convergence of SANmelody and SANsymphony into a single product with a common user interface.

Note: In case you’re not familiar with DataCore, they make software that will turn an off-the-shelf Windows server into an iSCSI SAN node (FibreChannel is optional) with all the bells and whistles you would expect from a modern SAN product. You can read more about them on our DataCore page.

We’ve been playing with SANsymphony-V in our engineering lab, and our technical team is impressed with both the functionality and the new user interface – but that’s another post for another day. This post is focused on the packaging and pricing of SANsymphony-V, which in many cases can come in significantly below the old SANmelody pricing.

First, we need to recap the old SANmelody pricing model. SANmelody nodes were priced according to the maximum amount of raw capacity that node could manage. The full-featured HA/DR product could be licensed for 0.5 Tb, 1 Tb, 2 Tb, 3 Tb, 4 Tb, 8 Tb, 16 Tb, or 32 Tb. So, for example, if you wanted 4 Tb of mirrored storage (two 4 Tb nodes in an HA pair), you would purchase two 4 Tb licenses. At MSRP, including 1 year of software maintenance, this would have cost you a total of $17,496. But what if you had another 2 Tb of archival data that you wanted available, but didn’t necessarily need it mirrored between your two nodes? Then you would want 4 Tb in one node, and 6 Tb in the other node. However, since there was no 6 Tb license, you’d have to buy an 8 Tb license. Now your total cost is up to $21,246.

SANsymphony-V introduced the concept of separate node licenses and capacity licenses. The node license is based on the maximum amount of raw storage that can exist in the storage pool to which that node belongs. The increments are:

  • “VL1″ – Up to 5 Tb – includes 1 Tb of capacity per node (more on this in a moment)
  • “VL2″ – Up to 16 Tb – includes 2 Tb of capacity per node
  • “VL3″ – Up to 100 Tb – includes 8 Tb of capacity per node
  • “VL4″ – Up to 256 Tb – includes 40 Tb of capacity per node
  • “VL5″ – More than 256 Tb – includes 120 Tb of capacity per node

In my example above, with 4 Tb of mirrored storage and 2 Tb of non-mirrored storage, there is a total of 10 Tb of storage in the storage pool: (4 x 2) + 2 = 10. Therefore, each node needs a “VL2″ node license, since the total storage in the pool is more than 5 Tb but less than 16 Tb. We also need a total of 10 Tb of capacity licensing. We’ve already got 4 Tb, since 2 Tb of capacity were included with each node license. So we need to buy an additional six 1 Tb capacity licenses. At MSRP, this would cost a total of $14,850 – substantially less than the old SANmelody price.

The cool thing is, once we have our two VL2 nodes and our 10 Tb of total capacity licensing, DataCore doesn’t care how that capacity is allocated between the nodes. We can have 5 Tb of mirrored storage, we can have 4 Tb in one node and 6 Tb in the other, we can have 3 Tb in one node and 7 Tb in the other. We can divide it up any way we want to.

If we now want to add asynchronous replication to a third SAN node that’s off-site (e.g., in our DR site), that SAN node is considered a separate “pool,” so its licensing would be based on how much capacity we need at our DR site. If we only cared about replicating 4 Tb to our DR site, then the DR node would only need a VL1 node license and a total of 4 Tb of capacity licensing (i.e., a VL1 license + three additional 1 Tb capacity licenses, since 1 Tb of capacity is included with the VL1 license).

At this point, no new SANmelody licenses are being sold – although, if you need to, you can still upgrade an existing SANmelody license to handle more storage. If you’re an existing SANmelody customer with current software maintenance, rest assured that you will be entitled to upgrade to SANsymphony-V as a benefit of your software maintenance coverage. However, there will not be a mechanism that allows for an easy in-place upgrade until sometime in Q3. In the meantime, an upgrade from SANmelody to SANsymphony-V would entail a complete rebuild from the ground up. (Which we would be delighted to do for you if you just can’t wait for the new features.)

, ,

Top Ten VDI Mistakes (According to Dan Feller)

January 13th, 2011 | Posted by Sid Herron in Application Virtualization | Best Practices | Branch Repeater | Citrix | Provisioning Services | Storage | VDI | Virtualization | XenDesktop - (1 Comments)

Dan Feller is a Lead Architect with the Citrix Consulting group, and has written extensively about XenDesktop. We found his series on the top ten mistakes people make when implementing desktop virtualization to be quite enlightening. In case you missed it, we thought we’d share his “top ten” list here, with links to the individual posts. We would highly recommend that you take the time to read through the series in its entirety:

#10 – Not calculating user bandwidth requirements
Back in the “good old days” of MetaFrame, when we didn’t particularly care about 3D graphics, multimedia content, etc., we could get by with roughly 20 Kbps of network bandwidth per user session. That’s not going to cut it for a virtualized desktop, for a number of reasons that Dan outlines in his blog post. He provides the following estimates for the average bandwidth required both with and without the presence of a pair of Citrix Branch Repeaters (which have some secret sauce that is specifically designed to accelerate Citrix traffic) between the client device and the virtual desktop session:

Parameter XenDesktop Bandwidth without Branch Repeater XenDesktop Bandwidth with Branch Repeater
Office Productivity Apps 43 Kbps 31 Kbps
Internet 85 Kbps 38 Kbps
Printing 553 – 593 Kbps 155 – 180 Kbps
Flash Video (with HDX redirection) 174 Kbps 128 Kbps
Standard WMV Video (with HDX redirection) 464 Kbps 148 Kbps
HD WMV Video (with HDX redirection) 1812 Kbps 206 Kbps

NOTE: These are estimates – your mileage may vary!

One thing that should come across loud and clear from the table above is what a huge difference the Citrix Branch Repeater can make in your bandwidth utilization. And as we’ve always said: you only buy hardware once – bandwidth costs go on forever!

#9 – Not considering the user profile
It should go without saying that user profiles are important. But if it’s number 9 on the list of things people most often screw up, then apparently it doesn’t. In a nutshell: If you mess up the users’ profiles, the users won’t be happy – logon/logoff performance will suffer, settings (including personalization) will be lost. If the users aren’t happy, they will be extremely vocal about it, and your VDI deployment will fail for lack of user buy-in and support. There are some great tools available for managing user profiles, including the Citrix Profile Manager, and the AppSense Environment Manager. AppSense can even maintain a consistent user experience across platforms – making sure that the user profile is the same regardless of whether the user is logged onto a Windows XP system, a Windows 7 System, or a Windows Server 2008 R2-based XenApp server.

Do yourself a favor and make sure you understand what your users’ profile requirements are, then investigate the available tools and plan accordingly.

#8 – Lack of an application virtualization strategy
How many applications are actually deployed in your organization? Do you even know? Are the versions consistent across all users? Which users use which applications? You have to understand the application landscape before you can decide how you’re going to deploy applications in your new virtualized desktop environment.

You have three basic choices on how to deliver apps:

  1. You can install every application into a single desktop image. That means that whenever an application changes, you have to change your base image, and do regression testing to make sure that the new or changed application didn’t break something else.
  2. You can create multiple desktop images with different application sets in each image, depending on the needs of your different user groups. Now if an application changes, you may have to change and do regression testing on multiple images. It’s worth noting that many organizations have been taking this approach in managing PC desktop images for years…but part of the promise of desktop virtualization is that, if done correctly, you can break out of that cycle. But to do that, you must…
  3. Remove the applications from the desktop image and deliver them some other way: either by running them on a XenApp server, or by streaming the application using either the native XenApp streaming technology or Microsoft’s App-V (or some other streaming technology of your choice).

Ultimately, you may end up with a mixed approach, where some core applications that everyone uses are installed in the desktop image, and the rest are virtualized. But, once again, it’s critical to first understand the application landscape within your organization, and then plan (and test) carefully to determine the best application delivery approach.

#7 – Improper resource allocation
Quoting Dan: “Like me, many users only consume a fraction of their total potential desktop computing power, which makes desktop virtualization extremely attractive. By sharing the resources between all users, the overall amount of required resources is reduced. However, there is a fine line between maximizing the number of users a single server can support and providing the user with a good virtual desktop computing experience.”

This post provides some great guidelines on how to optimize the environment, depending on the underlying hypervisor you’re planning to use.

#6 – Protection from Anti-Virus (as well as protection from viruses)
If you are provisioning desktops from a shared read-only image (e.g., Citrix Provisioning Services), then any virus infection will go away when the virtual PC is rebooted, because changes to the base image – including the virus – are discarded by design. But you still need AV protection, because the virus can use the interval between infection and reboot to propagate itself to other systems. The gotcha here is that the AV software itself can cause serious performance issues if it is not configured properly. Dan provides a great outline in this post for how to approach AV protection in a virtual desktop environment.

#5 – Managing the incoming storm
In most organizations, the majority of users arrive and start logging into their desktops at approximately the same time. What you don’t want is dozens, or hundreds, of virtual desktops trying to start up simultaneously, because it will hammer your virtualization environment. There are some very specific things you need to do to survive the “boot storm,” and Dan outlines them in this post.

#4 – Not optimizing the virtual desktop image
Dan provides several tips on things you should do to optimize your desktop image for the virtual environment. He also has specific sections on his blog that deal with recommended optimizations for Windows 7, and recommended optimizations for Windows XP.

#3 – Not spending your cache wisely
Specifically, we’re talking about configuring the system cache on your Provisioning Server appropriately, depending on the OS and amount of RAM in your Provisioning Server, and the type of storage repository you’re using for your vDisk(s).

#2 – Using VDI defaults
Default settings are great for getting a small Proof of Concept up and running quickly. But as you scale up your VDI environment, there are a number of things you should do. If you ignore them, performance will suffer, which means that users will be upset, which means that your VDI project is more likely to fail.

#1 – Improper storage design
This shouldn’t be a surprise, because we’ve written about this before, and even linked to a Citrix TV video of Dan discussing this very thing as part of developing a reference architecture for an SMB (under 500 desktops) deployment. We’re talking here about how to calculate the “functional IOPS” available from a given storage system, and what that means in relation to the number of IOPS a typical user will need at boot time, logon time, working hours (which will vary depending on the users themselves), and logoff time.

Just to round things out, Dan also tossed in a few “honorable mentions,” like the improper use of NIC teaming or not optimizing the NIC configuration in Provisioning Servers, trying to provision images to hardware with mismatched hardware device drivers (generally not an issue if you’re provisioning into a virtual environment), and failing to have a good business reason for launching a VDI project in the first place.

Again, this post was intended to whet your appetite by giving you enough information that you’ll want to read through Dan’s individual “top ten” posts. We would heartily recommend that you do that – you’ll probably learn a lot. (We certainly did!)

, , , , , , ,

A Better Way to Backup Your Data

September 13th, 2010 | Posted by Sid Herron in Backup and Recovery | Best Practices | Business Continuity | Disaster Recovery | Microsoft | Storage | Troubleshooting and How-Tos - (0 Comments)

Moose Logic has been building and supporting networks for a long time. And during most of that time we’ve had a real love-hate relationship with most of the backup technologies we’ve implemented and/or recommended.

Tape backups – although they are arguably the best technology for long-term archival storage – are a pain to manage. Tapes wear out. Tape drives get dirty. People just don’t do test restores as often as they should. As a result, all too often, the first time you realize that you’ve got a problem with your backups is when you have a data loss, try to restore from your backups, and find out that they’re no good.

Add to that the astronomical growth in storage capacity, meaning that all the data you need to back up often won’t fit on one tape any more. So, unless you have someone working the night shift who can swap out the tape when it gets full, you’re faced with…

  • Buying multiple tape drives, which typically means you’re going to spend more on your backup software. And if your servers are virtualized, where are you going to install those tape drives?
  • Buying a tape library (a.k.a. autoloader), which can also get expensive.
  • Changing the tape when you come in the next morning, which means that your network performance suffers because you’re trying to finish the backup job(s) while people are trying to get work done.

Then there’s the issue of getting a copy of your data out of the building. Typically, that’s done by having multiple sets of tapes, and a designated employee who takes one set home every Friday and brings the other set in. If s/he remembers. Or isn’t sick or on vacation.

Backing up to external hard drives is a reasonable alternative for some. It solves the capacity issue in most cases. But over the years, we’ve seen reliability issues with some manufacturers’ units. We’ve uncovered nagging little issues like some units that don’t automatically come back on line after a power interruption. And they’re not necessarily the best for long-term archival storage, unless you keep them powered on – or at least power them on once in a while – because hard disks that just sit for long periods of time may develop issues with the lubrication in their bearings and not want to spin back up.

But we’ve finally found an approach that we really, really like. One that, as one of our engineers said in an internal email thread, we actually enjoy managing. In fact, we like it so much we built a backup appliance around it. It’s Microsoft’s System Center Data Protection Manager (SCDPM).

In this installment of the Moose Logic Video Series, our own Scott Gorcester gives you a quick overview of SCDPM 2010:



For more detail on how it works, check out the description of our MooseSentryTM backup appliance.

, , , ,

What Is Storage Virtualization (Part 2 of 2)

September 7th, 2010 | Posted by Sid Herron in DataCore | High Availability | Storage | Virtualization - (1 Comments)

This is the second of two videos addressing virtual storage and its benefits. In Part 1, we addressed thin provisioning and virtual volumes. In this video, Steve talks about multipathing, and how it contributes to a high availability storage solution:

, , ,

What is Storage Virtualization? (Part 1 of 2)

August 27th, 2010 | Posted by Shane Kalles in DataCore | High Availability | Storage | Virtualization - (1 Comments)

This is the first of two videos addressing virtual storage and its benefits. There are a number of storage solutions out there on the market but we have chosen to focus on DataCore of the purposes of this video. DataCore is an iSCSI SAN solution and you can learn more about their products here.

In part one, we address thin provisioning and virtual volumes. Watching this video will help you understand part 2 of “What is Storage Virtualization” where we talk about how multipathing relates to virtual volumes and contributes to a highly available SAN solution.

, , ,

Interview With DataCore

August 20th, 2010 | Posted by Shane Kalles in DataCore | General | Storage | Virtualization - (0 Comments)

Recently Steve Parlee, Moose Logic’s Director of Engineering, sat down with Tim Warden, DataCore’s Western Region Director of Sales. Moose Logic has installed a number of DataCore solutions over the last few years and highly recommends their software to anyone looking into storage virtualization. We’ve also mentioned DataCore a number of times in our blog and newsletters. If your still not sure what DataCore does, this is a great introduction to their storage solutions. In the interview, Tim Warden explains the benefits of the DataCore software and what their solution can bring to your data center.

SAN Tips – Storage Repository Design

July 26th, 2010 | Posted by Shane Kalles in Best Practices | Education | Snapshotting | Storage | Virtualization - (0 Comments)

Back with another Moose Logic video for your viewing pleasure. In this installment, our own Steve Parlee, Moose Logic’s Director of Engineering, talks about SAN storage repository design concepts, and the effects your design choices have on things like snapshots, disk usage, and overall performance. In the process, you’ll also learn what we consider to be “best practice,” and some of the reasons why. As always, your comments will be appreciated. Enjoy!

, , , ,

iSCSI vs. Fibre Channel

July 22nd, 2010 | Posted by Sid Herron in Storage | Virtualization - (5 Comments)

We’ve had several posts here about storage virtualization (a.k.a. SANs) and the role that storage virtualization plays in both server and desktop virtualization. We made the decision some time ago to promote iSCSI SAN products rather than fibre channel, primarily because iSCSI uses technologies that most IT professionals are already familiar with – namely Gigabit Ethernet and TCP/IP – whereas fibre channel introduces a whole new fiber optic switching infrastructure into your computing environment, together with the new skills required to manage it.

But there are many who maintain that, although a fibre channel SAN infrastructure may be more expensive, and may require a different set of skills to manage, it offers superior performance.

So I was particularly interested to run across an article by Greg Shields on techtarget.com entitled “Fibre Channel vs. iSCSI SANs: Who Cares?” I would encourage you to click through and read this article in its entirety, although you may have to register and give up your email address to do so. But here are a couple of tidbits from the article to whet your appetite:

iSCSI vs. Fibre Channel: Who cares?
The answer: Statistics suggest that it doesn’t really matter…In most real-world scenarios, the performance difference between Fibre Channel and iSCSI SANs is negligible. Partisans will extol the raw performance statistics of their favorite SAN type, but it’s fantastically difficult to translate raw performance specifications into real-world user experience…

Performance alone may not be a decisive factor, but a SAN’s ease of administration can be. The management tools and techniques for Fibre Channel and iSCSI storage infrastructures are substantially different…the skills and experience required to run a Fibre Channel storage infrastructure are difficult to come by – often requiring additional consulting support for most implementations to start correctly. On the other hand, iSCSI SANs lean heavily on the existing TCP/IP protocol. If you have network engineers in your environment, they probably possess most of the necessary skills to successfully manage an iSCSI storage infrastructure.

So, while I would once again encourage you to read Greg’s post in its entirety (so you can assure yourself that I’m not quoting him out of context), I must say that I find his comments gratifying, because they tend to reinforce our own conclusions: unless you already have a fibre channel SAN infrastructure, there’s no compelling reason not to go with an iSCSI solution, and several reasons in favor of doing so, including cost and simplicity of management.

Anybody out there disagree? And, if so, can you tell me why, exactly, you feel that fibre channel is superior?

,

Switch to SAN but BE CAREFUL!

May 6th, 2010 | Posted by Scott Gorcester in Storage | Virtualization - (0 Comments)

I am a big fan of Storage Area Network (“SAN”) technology. SAN technology offers high performance, highly flexible storage for Physical and Virtual Systems and is particularly valuable to empower advanced features for virtualization solutions such as VMWare, XENServer, and Hyper-V Virtual Hosts to name a few. 

The moral of this story is that you need to know that SANs have some very different management requirements compared to traditional Direct Attached Storage (“DAS”).  Many if not most IT Staff in small to medium size organizations are most familiar with throwing hard disks into physical servers in single or RAID configurations.  Now that they are are purchasing and deploying SAN technology we find that many problems occur if they do not fully understand how to implement and manage these new beasts. 

I would suggest that the difference between DAS and SAN technology is similar in spirit to the difference between a passenger car and a high performance race car.  Most passenger cars are designed to be slower and more forgiving than race cars, if you get into trouble it’s much easier for the average driver to recover.  Race cars will do many things that passenger cars won’t, but if you push them too far you will require very specific skills to recover or you will spin out of control.  SANs are in my opinion similar to this analogy, they will do many things that DAS won’t but if you don’t design and manage them properly you may quickly find yourself in spinning out of control. 

Here are a couple of things you need to know.

  1. Most popular SAN’s offer some impressive features such as “Thin Provisioning.”  Thin provisioning is one of those features that you will absolutely love, that is, until you don’t.  Thin Provisioning is a feature that allows you to provision gobs of storage – more, in fact, than you actually have – to Physical and Virtual Systems.  For example, you might have a SAN with 2 terabytes of physical storage, but then “provision” 10 individual 2 terabyte “volumes" and present them to your physical and virtual servers.  Your servers will see this as a combined total of 20 terabytes of storage. This is great but requires you to be very careful.  The reason is that you have offered 20 terabytes of “Virtual Storage” but of course you really only have 2TB of actual or “physical” storage.  So while your systems believe there is 20TB of available storage you have to insure that you do not attempt to put more than 2TB of physical data on this system or bad things will happen. 

    What bad things? Well in most cases once you fill up the physical space the volume will become unusable.  You must make sure you carefully monitor the system and pay close attention to it so that if you start reaching capacity, you’ll know in time to do something about it.  Our own SANs alert us when total available free space reaches 20%.  We have from time to time been between 70% and 90% utilization of our total capacity, and while everything is running just fine we know we have to watch this carefully.  If we hit 100% (intentionally or otherwise), the result could be catastrophic: the storage could immediately shut down and the recovery might not be quick. 

    This happened to a client last week. They started a backup, and when they realized that this was causing one of their thinly-provisioned SAN volumes to fill up to capacity, they immediately stopped the backup and deleted the data.  Unfortunately this caused the volume to fill to 100% and immediately shut down.  Fortunately this volume was mirrored to a second SAN and since there was a little more room on the mirror volume the workload actually stayed online until we could assist the client in recovering from this problem.  If the mirrored side had filled to 100% as well, the result would have been an immediate failure of a critical SQL server workload. 

    The client didn’t realize that copying all this backup data to a Windows Server VM would fill up the SAN volume, nor did they realize that simply deleting that data from the VM would not necessarily delete it from the SAN.  We were able to configure a new volume and replace the full half of the mirror with an empty volume, but only because their was some un-provisioned space available to use for this purpose.

  2. And that brings me to my second point – which is that deleting data from a Physical or Virtual server that is using SAN storage may not in many cases free the physical space on the SAN.  Again, DAS is like the passenger car, if you over-commit your storage you can simply press the brake (a.k.a. delete key) and recover immediately. With SAN storage it is common that once the space is committed you may have to perform specific tasks to free up this space.  This task might require special tools or utilities, or even require adding more physical disks.  In extreme cases it may require that you remove and recreate the over-committed SAN Volumes, and that is time consuming and painful.  In this scenario an ounce of prevention is worth a hundred pounds of cure. 

    We have been running our SAN over-provisioned for years with no ill affects or degradation in performance…but we know we are “on the bubble” and we carefully monitor and maintain this situation.

So please be aware that SAN technology is wonderful, but its important to learn some new skills to keep the systems performing their best.

, ,