Posted by Will Usher on Mon, May 03, 2010 @ 11:31 AM
(Or "How we help our clients pick the best storage for their needs")
This being my first blog post, I thought I'd take a moment to introduce myself. I'm Will Usher and I've been working for F3 Technology Partners for the past two years. Here at F3, my time is split pretty evenly between pre-sales and post-sales engineering work. My two main focuses are VMware Virtualization and Storage. This blog post is going to be about my methodology around helping a client understand their storage options and picking the solution that best fits their needs.
I break down any potential storage solution into two of four categories; frame-based/frame-less and block-based/file-based. Every storage array on the market can be placed into two of these quadrants. So we're all on the same page, let me give a
quick background of what each quadrant means.
Frame-based arrays are your traditional SANs. You buy a controller (or two) and however much disk you need, generally added in trays. You can continue to add disk until you have reached the limit of disk that your controller can support.
Frame-less arrays are a similar in concept to grid computing systems; every time a node is added, CPU, memory, network and disk are added. You're not locked into the one or two controllers the way you are with frame based computing.
Block Based arrays are traditionally what was considered a SAN. They don't run traditional file systems like Windows' NTFS or Solaris' ZFS. They carve up raw storage into LUNs and serve that out via block based protocols (FC, iSCSI, FCoIP, etc.)
File Based arrays use an internal filesystem, like ZFS, WAFL, or NTFS, and are able to serve files to clients via file based protocols (CIFS/SMB, NFS, HTTP/S, FTP). They have traditionally been called NAS devices, but this is changing as many are now able to serve our block based protocols.
So now we know how to classify storage arrays, but how does this help my clients find the correct storage solution? The answer is that each of these architectures has specific advantages and disadvantages.
Frame based arrays
A frame based array will be easier to design and potentially easier to manage, thus lowering costs. When designing a frame based array you make an assumption that there will be at most two controllers. This makes inter-controller communication easier, as well as adding features easier. This can lead to faster development and richer feature sets.
Frame-less arrays
A frame-less array has a few advantages over their frame-based counterparts. It has to do with what I call "linear growth". With a frame-less architecture your array is composed of nodes. Generally each node has compute resources (CPU), network resources (FC, Ethernet, etc), cache (DRAM, NVRAM, SSD), and storage (disk). This means that every time you add capacity, you're also adding compute, network, and cache resources. This means you maintain a balanced system as you scale the capacity of the array. Contrast this to a frame based array, where you must anticipate your future growth and buy that upfront. If you under estimate your growth, you're going to end up doing a rip-and-replace to move up to the next larger controller. If you overestimate your growth, you've just wasted money on a controller that is too large for your environment. A storage engineer (like me J ) can help mitigate some of this risk based on our experience with other clients, but unless you have a crystal ball that can tell us how much storage you're going to need in the next three to five years, it's still going to be an approximation.
Block Based arrays
Traditional SANs use a block based design where disks are assigned to RAID groups and carved up into LUNs, which are then presented to servers as block devices. The server formats it with its native filesystem, and proceeds to use it like a local disk. This is easier to design as it has fewer moving parts than a file based array. Block based arrays are generally less expensive in the low and mid range, and scale larger at the high end than file based solutions. People generally associate block based arrays as being faster than file based arrays. This does not necessarily hold true today with high-performance file based products like the NetApp FAS, and the Oracle 7000. Keep reading to find out why.
File Based arrays
Once relegated to mundane file sharing tasks, file based arrays have improved leaps and bounds over the past five or so years, thanks in no small part to Moore's law. File based array's require more CPU power to do the same amount of work as their block based counterparts. This was an issue when we had Xeons running at 800 MHz, but now that we have six core Xeons running at 3+ GHz we have more CPU power than we know what to do with. File based arrays can leverage this abundance of CPU power to meet and in some cases exceed the performance of block based arrays. They do this several ways including leveraging advanced caching algorithms to prefetch blocks from disk into cache before they're needed by the client. O f course having equal performance certainly isn't a good reason to go file based over block based. So why are file based arrays gaining rapidly in popularity? Feature set and TCO. Because a file based array will have a local filesystem on the array, it unlocks a huge amount of features not possible with traditional block storage, for example DeDuplication and encryption. One only has to look at the (admittedly dizzying) selection of software features on the NetApp website to understand my point. The other big feature of file based storage is what's been coined Unified Storage. A unified storage device can serve both block based data (iSCSI, FC) and file level data (NFS, CIFS, HTTP, FTP, etc). This means a single device can take the place of a block based array and consolidate all of your file servers. This can save a lot of time between patching and administering windows file servers. Of course there are disadvantages of file based arrays; they tend to be more expensive and they don't scale much over a petabyte.
When I do this for a client I have the benefit of being much more interactive. I can take their needs and pain points into account and tailor the discussion around them. By the end of the meeting a client has a much better idea of what they want, and then I can offer several different solutions that fit their needs. We can the drill down on those products and the client can weigh the pros and cons of each one. My clients appreciate that we're vendor agnostic and that we can give them solutions and let them pick the best one, rather than trying to force a specific technology on them.
Do you agree with me? Think I've got it all wrong? Please let me know in the comments.
Posted by Pete Sorensen on Fri, Sep 25, 2009 @ 03:45 PM
VDI is a very useful concept that is starting to take hold in production desktop environments. In essence it is virtualizing desktop Operating Systems, Applications, and Data and moving it all to the data center with the user only accessing these resources via endpoint. This endpoint can be a thin/thick client or web browser and in some cases a smart phone. The idea is that the endpoint is stateless and ideally retains no user data as it only serves as an I/O conduit.
VDI like most concepts is quite broad. However I tend to view it this way:
As you can see the Operating System, Application layer and User Data are treated as separate and independent entities which align to give the user a seamless experience. This allows for easy modification of each layer without impacting the others. With this model the O.S. is just a stateless environment for applications to be launched and data to be generated and modified. But if the O.S. were to disappear, the applications and the user's data would not be affected. A new O.S. could then be provisioned for that user with a minimal outage.
On the application virtualization side, applications would launch from ‘file servers' and be managed by application virtualization technology such as InstallFree, App-V, and ThinApp. The advantage to this is if you want to push an updated version of an application to a user set you would virtualize that update and push it to the file server. Then the next time the user runs this application they would be running the new code. Inversely if you wanted to serve multiple versions of an application simultaneously this would also be supported as the applications would each be in their own virtual space on the O.S. they are executing on.
User data is a matter of re-direction to CIFS file servers (for windows clients). This means actual backups, snapshots and dedupe of user critical data is made accomplishable in an efficient and cost effective way. This also brings tiered storage into view. Having your actual VM's on low latency, high throughput storage (SAN) and your raw data on cheaper, higher density storage (NAS). This is an important cost savings element.
Endpoints do not have to be consistent over an environment. Repurposing Thick Clients, using various Thin Clients or just a web browser are all acceptable. There are a few things to consider with endpoints such as multimedia performance, USB redirection, VPN capability, Connection Broker compatibility and security being the ones that are of main concern.
VDI does a great job of taking the risk and load off of desktops; however it redistributes that load to your network infrastructure. You must look long and hard at your network to verify it is able to keep up with the increase and type of traffic. VDI traffic tends to be bursty as is the nature with remote display protocols. It is also sensitive to latency and packet loss which is a strong consideration on WAN deployments on the fringes of you network. VLANs and QoS are good measures to implement to keep this traffic segregated and at the right priority level. Redundancy for these systems and the networks they run on is key, as any outage affects many users simultaneously.
So the conclusion is that VDI's benefits are a great for cost savings, increasing quality, and managing your desktop infrastructure. It provides enhanced reliability, usability and security to your infrastructure. However implementation must be well thought out and engineered from the NICs to your storage and to the end points. Implementation in phases is a good practice as it allows you to ramp up your SA's skills and find trouble spots without large impacts.