Cloud services providers offer hosted virtual servers and they can also offer Storage as a Service. At LightBound we offer both. A customer can opt only for storage as a service, and to this can add server virtualization services. There are two technologies we leverage to maximize cost savings, which we in turn pass on to the customer - thin provisioning and tiered storage.
Definition: A LUN (Logical Unit Number) is a single storage unit on a SAN (Storage Area Network), mapped to a server which then corresponds to a hard drive letter, like C:.
Thin provisioning is the ability to leverage available storage space from the total "pool" of storage, regardless of the number and size of LUN's. In other words, it's over subscription. The space isn't consumed when the LUN is created, but when it's actually used. So you can create twenty 1TB LUNS on your 10TB SAN, and as long as the aggregate consumption across all 20 LUNS is less than 10TB, all is well.
At LightBound we investigated how we might provide this cost savings garnered from thin provisioning directly to the customer. We found, however that for a number of reasons, it just wasn't going to be practical. First off it's a billing nightmare - customers want many things, and one of those is a consistent bill. To charge only for the actual usage would mean a substantially higher cost per "consumed" gigabyte to cover our costs, and every month an analysis of the consumed disk would have to be reported on for accurate billing. Also, how do you determine a months usage if the data ebbs and flows through the month? Maybe 95 percentile, or prorated down to the day, but again, a huge billing ordeal and often an inconsistent and potentially an unexpectedly high bill to the customer.
What we did instead was to take consideration of the average LUN usage (about 75%), and provide that cost savings to the customer. This provided for a competitive price point for disk, and a consistent and simple bill for the customer. But wait there's more - we actually figured out a way to allow the customer to leverage that extra space - snapshots.
Almost all customers utilizing storage area network solutions, including those paying for storage as a service, want to utilize snapshots. Snapshots provide point-in-time recovery capabilities of the critical data. Snapshots are freezing the data, and storing the changes (or deltas) in a different container. Thus even though the data isn't being copied, there is some consumption attributed to these snapshots. Thus the cost of snapshots is not in the number of snapshots, per say, but in the amount of disk space they consume. So here's the cost savings, and I'll apologize up front that it's a little complex, so bear with me. The customer can leverage the space they have not [yet] consumed in their LUN towards snapshot space. Here's an example:
Let's say a customer knows that they will have about 750GB of data, so they lease a 1TB LUN. Why not lease 750GB you ask? Because most operating systems don't react very well when their drive is completely full. You need to instill a little wiggle room, so 1TB it is. Now we invoke the snapshot retention schedule, which is what determines when and how often a snapshot is taken, and how long to retain that snapshot. So let's assume for the sake of discussion that we end up taking and retaining snapshots that total 200GB in disk consumption. The customer bought 1TB, used 750GB, and used another 200GB for snaps. That's only 950GB, less than 1TB, and so less than what the customer paid for. Voila! The customer doesn't have to pay for the snapshot consumption. Now, if the total of the two (data & snaps) exceeds the initial total allotment, then they're some fees, but not until then. So use that extra "wiggle room" for something fruitful like snapshots and in doing so you don't lose your wiggle room!
This was a long one, so I'll save tiered storage for next time.
Go Cloud!
Sam Newberry
Definition: A LUN (Logical Unit Number) is a single storage unit on a SAN (Storage Area Network), mapped to a server which then corresponds to a hard drive letter, like C:.
Thin provisioning is the ability to leverage available storage space from the total "pool" of storage, regardless of the number and size of LUN's. In other words, it's over subscription. The space isn't consumed when the LUN is created, but when it's actually used. So you can create twenty 1TB LUNS on your 10TB SAN, and as long as the aggregate consumption across all 20 LUNS is less than 10TB, all is well.
At LightBound we investigated how we might provide this cost savings garnered from thin provisioning directly to the customer. We found, however that for a number of reasons, it just wasn't going to be practical. First off it's a billing nightmare - customers want many things, and one of those is a consistent bill. To charge only for the actual usage would mean a substantially higher cost per "consumed" gigabyte to cover our costs, and every month an analysis of the consumed disk would have to be reported on for accurate billing. Also, how do you determine a months usage if the data ebbs and flows through the month? Maybe 95 percentile, or prorated down to the day, but again, a huge billing ordeal and often an inconsistent and potentially an unexpectedly high bill to the customer.
What we did instead was to take consideration of the average LUN usage (about 75%), and provide that cost savings to the customer. This provided for a competitive price point for disk, and a consistent and simple bill for the customer. But wait there's more - we actually figured out a way to allow the customer to leverage that extra space - snapshots.
Almost all customers utilizing storage area network solutions, including those paying for storage as a service, want to utilize snapshots. Snapshots provide point-in-time recovery capabilities of the critical data. Snapshots are freezing the data, and storing the changes (or deltas) in a different container. Thus even though the data isn't being copied, there is some consumption attributed to these snapshots. Thus the cost of snapshots is not in the number of snapshots, per say, but in the amount of disk space they consume. So here's the cost savings, and I'll apologize up front that it's a little complex, so bear with me. The customer can leverage the space they have not [yet] consumed in their LUN towards snapshot space. Here's an example:
Let's say a customer knows that they will have about 750GB of data, so they lease a 1TB LUN. Why not lease 750GB you ask? Because most operating systems don't react very well when their drive is completely full. You need to instill a little wiggle room, so 1TB it is. Now we invoke the snapshot retention schedule, which is what determines when and how often a snapshot is taken, and how long to retain that snapshot. So let's assume for the sake of discussion that we end up taking and retaining snapshots that total 200GB in disk consumption. The customer bought 1TB, used 750GB, and used another 200GB for snaps. That's only 950GB, less than 1TB, and so less than what the customer paid for. Voila! The customer doesn't have to pay for the snapshot consumption. Now, if the total of the two (data & snaps) exceeds the initial total allotment, then they're some fees, but not until then. So use that extra "wiggle room" for something fruitful like snapshots and in doing so you don't lose your wiggle room!
This was a long one, so I'll save tiered storage for next time.
Go Cloud!
Sam Newberry
Powered by Compendium
Comments for Storage Area Network Solutions & Cloud Services: A cost analysis, Part 1