Showing posts with label SAN. Show all posts
Showing posts with label SAN. Show all posts

Tuesday, November 3, 2009

Snapshots

In my last post we discussed Storage Area Networks or SANs and their outstanding abilities to manage your storage needs. There is a lot more technical information we can cover on SANs but I decided a followup post was needed to explain what a snapshot is.

For many companies in the construction industry, they might have a single server that has their accounting and file serving roles combined. As storage runs out and processing and memory run dry, inevitably, an additional hardware server will be required. For those companies, many have a dedicated file server, and users simply access the data on in through a UNC path \\Servername\Sharename, or the IT director maps the UNC share to a mapped drive for the users. Backup and recovery is typically done either through a USB drive or a Tape drive. Although there are many valid reasons for using these methods for backup, Snapshots provide huge advantages to traditional tape backup and even some big advantages over simple disk backup, but snaps are not a total backup solution unless they are used in conjunction with a cloned volume on a SAN.

OK, now what is a snapshot. A snapshot is a picture of what a volume looked like at an exact point in time. Snapshots can be done instantly but accurately record an entire volume, even if the volume is hundreds of gigabytes. How can it do this so quickly and yet use up such a small amount of space? Well the snapshot actually uses the volume it snaps as the data for the snap. So when a snap is made, nothing really happens, other than a record that a snap was made. Then as the contents of files, actually the individual sectors on the volume, are changed, it writes the changes to an unused sector and maps the old sectors to the snap. Using this method the original volume can make changes throughout the course of business and the snaps gradually get the old sectors mapped to it so by combining the volume as it stands now and substituting the old sectors, the snapshot can recreate the data as it existed at the exact moment of the snap. For volumes that do not change that often, snaps typically remain small and only contain the data that has changed since the snap. For volumes that have transactional data that change frequently, the snaps can eventually take up as much space as the volume itself, but never more than the volume. Snaps do not cause additional I/O load on the drive and can be accessed at any time and mounted as new volumes that you can recover data from.

The real disadvantage with snaps is that it relies on the the original volume staying intact and healthy in order to recover data. This means snaps are awesome for recovering corrupt or deleted files, but do not allow you to recover from a complete volume failure. For that, you mitigate the risk by using raid or SAN technology, and then use another solution for offsite backup. While some might think this limits the usefullness of snapshots, most of the recovery that takes place in the IT world is due to deleted and damaged files, not storage system crashes.

How do you get your hands on snapshots? Three ways I know of. Buy snapshotting software, get a direct attached storage array that supports it, or get yourself a Storage Area Network. The latter of which I am a fan of. I’ll post another article about snapshot scheduling and remote snapshots, both features of high end SANs.

Monday, November 2, 2009

Storage Area Networks or SANs

Storage Area Networks are cool. Everyone should have one. What are they, you say? Why would a respectable construction company want one, you say? Let’s just explore that for a moment shall we.
Storage Area Networks consolidate your data storage into a single device or cluster of devices that then lend their storage to the computers or servers that need the storage capacity. In plain english, it simply means you get one big server with a lot of hard drives, and use that server to provide storage to all your other servers. SANs make their storage available to the other servers usually through iSCSI or FibreChannel and the servers behave as though the storage is internal, meaning the storage shows up as a single hard drive in the OS disk management. On top of that, you get a ton of extra managment capabilities that you just can’t get any other way.

SANs Reduce IT Costs

SANs are expensive, so how is the cost justified? Having a SAN means that you don’t have to pour so much money into every single server you buy making sure it has enough capacity, redundancy, and storage performance you need for the application. You only need to make sure it has enough hard disk resources for the OS and Server Applications. Then you put all the data on a SAN volume.

SANs Make Adding Capacity Easy

You might think your project folder will last forever with 100GB of space but think again. In this age of paperless office and digital take-offs construction companies are using more storage space than ever. If you are using a SAN, its no problem, just increase the volume to 500GB or even 1TB when its needed. A simple command run in a command prompt and the OS now knows it has the extra capacity. No reformatting, no copying data, no upgrading your server.

SANs Have Outstanding Snapshotting Skills

Want to snapshot your volume on an hourly basis so that you can recover a file someone accidentally deleted 10 minutes ago. No problem. Most SANs support overlapping Snapshot schedules that auto delete aging snaps. Want another schedule that does 1 snap per day for 10 days, and another schedule that snaps the volume 1 time per week for 6 weeks. No Problem!

SANs Have Advanced Storage Features

Now all these big volumes can use up your SAN fast right? Not with thin provisioning. Your SAN tells the OS it has a 1TB but really, the SAN only gives it 100GB. The SAN will automatically allocate more space as it gets used and you get alerts as certain thresholds are passed. Awesome!
What about backup? Most SANs support remote volume cloning or snap shotting which makes sure you have a high performance method of backing up offsite, and an easy, high performance way of disaster recovery as well. Just plain cool!

SANs Can Outperform Internal Storage

Since you have spent your pennies buying a high performance SAN, you dont need to buy expensive systems for each server. The SAN will likely outperform what you would put in those servers anyway. If you find that your SAN is starting to lag in performance, most SAN solutions allow you to simply add a new SAN server and add it to the cluster. In a matter of minutes, your SAN begins to replicate and load balance accross the SAN (It’s not called a storage area NETWORK for nothing). You’ll find that you can build your SAN incrementally as your budget allows so that even the tiniest volume mounted on the lowliest server in your network has over 100 hard disks or better yet solid state disks serving up data at speeds just not achievable without ordering all your servers with massive dedicated direct attached storage.

Conclusion

I actually have a lot more to say about SANs. I’ll make some future posts that concentrate more on how they are used and also talk more about the specific vendors and costs. I can say that for hh2 Web Services, we use iSCSI SANs because they are high performance and cost effective. And after using two other solutions in production, I can say with confidence that Dell’s Equallogic platform is the best iSCSI solution on the market. I believe you get the most bang for the buck. Beat Dell up a little on the price when you negotiate though. They usually have wiggle room in the pricing for a first time customer.