This post was originally published on this siteIn Linux, ASMLib provides the wrapper for managing the ASM disks. To identify the underlying physical device that the ASM disk ...
Listen to any storage vendor pitch, and “simple” and “easy” are sure to be words they use. But what do these mean when it comes to storage systems?
A nice web-based GUI which allow the storage administrator to create and export storage objects to hosts and manage the various features of the storage system is certainly important. (Note that half of the Pure FlashArray administrators manage more than just storage). If this GUI can be used by anyone with little or no training, then it is even better.
Now anyone can make a nice GUI over a complex product, it does not really make the storage array simple.
Don’t get me wrong, user interfaces are very important, they are after all how the storage admins interact with the system on a daily basis. These are busy people and they don’t have time to waste.
This is of course something we at Pure Storage understand very well and we have some of the best UI designers working for us and ensuring that our user interfaces are not only easy to use but great looking
However this is not really what what real storage simplicity is about.
If you’ve managed disk storage systems, you know that there are almost always options : disk type, volume type, features to enable or disable, RAID level… that will usually have an impact on performance or on the features that can be used. As an administrator of this storage system, you have choices to make :
To make the right choices, the administrator has to understand what the storage object is going to be used for. A volume used for database data files might have a different RAID level than one used for the log files of the same database. They might also choose to not enable capacity efficiency features if the application requires the highest level of performance…
In many large enterprises, finding the information required to make the right choices might take days…
At Pure our engineers believe strongly in having as little options as possible.
There is just one way of creating a volume : all capacity efficiency features (thin provisioning, deduplication, compression…) are always enabled (the array will always try to reduce the data by as much as possible) and there’s no storage group, RAID level, snapshot space… to select.
In essence there is just one way of doing things with every feature always enabled, so that it’s always configured in the right way even if you don’t know what application is going to run on these volumes…
That is real ease of use for the administrators of storage (watch this 5 minute demo if you want to see how easy it is!), but what about the other members of the IT team?
What about the server admins, application owners, DBAs or VDI admins?
Even if you do not manage storage systems, you spend a lot of time tuning servers and applications to overcome the limitation of these storage systems.
This might be by using striping file systems over multiple LUNs, configuring databases for specific block sizes, aligning file systems to specific offsets, using specific options best suited for your storage system when creating new virtual servers or desktops…
There’s actually an entire market built on working around the limitations of storage systems. Think about volume managers, snapshot-based virtual desktop provisioning, columnar databases… these were all invented because of spinning disk limitations.
Also, entire chapters have been written on file system alignment to storage boundaries. This is required with traditional storage systems to ensure the best performance out of storage arrays (there can be up to 50% performance degradation if file systems are not aligned) and is a painful topic of discussion if you have existing data that is not using the proper block size or file system offset to match your storage system. Re-aligning data / file systems is at best long and complex, at worst long, complex and disruptive to operations. Realistically, customers just don’t do it…
One of the core design principle of the Pure FlashArray architecture is that the array works with a variable block size.
It can detect IOs of different size (even to the same volume) and store those with “page” sizes that can go as low as 512 bytes, and as high as 32 KB.
This bring many benefits, one of which being that there is not such thing as file system mis-alignment on Pure (file systems alignment is always on a multiple of 512 bytes, so something that would be misaligned on other storage systems is always aligned on Pure). This makes data migration really easy : just move your data any way you want and it’s done properly. No need to ever change the layout of the data.
Another benefit is that there is no need to configure applications to use specific block sizes. Any block size is good and will yield the same level of performance. See post from Chas Dye demonstrating this with Oracle
It also does not matter how many volumes are used for an application or what size they are. A database with a single volume of multiple TB’s will perform as well as if there was a lot of small volumes striped together.
Traditionally, IT has had to work around the limitations of storage. With Pure, it’s the storage system that adapts to the way the IT infrastructure and applications are working, not the other way around!
In any case the performance will be optimal and the capacity reduced to the minimum possible
So to answer the initial question, I believe that storage is really simple when it does not impose any limitation on the other members of the IT team.
The Pure FlashArray is fast, this is natural to flash arrays, but the real difference is that it is fast all the time, in the most efficient manner, and most importantly with no tuning.
Comments welcome of course.