Main menu

Post navigation

Choosing a storage platform: P1

A brief overview:

Choosing a storage platform for your computing environment is one of the most critical decisions to be made and one of the most difficult. There are many different approaches to solving storage problems and each has its benefits and its drawbacks. Understanding the specific needs for your project is a critical first step in the process of choosing a storage platform. I would like to explore some of the key considerations that should be understood before “shopping” for new storage begins.

What is the budget?

Storage platforms can span a very wide range of costs. Simple platforms can be obtained for only a couple of thousand dollars but enterprise class systems can cost millions. Knowing your budget before calling a vendor can help you and your sales person avoid wasting time looking at systems and features you cannot afford.

Remember that storage platforms are usually heavily discounted so it is important that you do not base your choices on the list price of the system. At times I have seen discounts well over 60% when the vendor is hungry for the sale. For this reason alone, it is usually unwise to look at storage from only one vendor; when there is competition, there is a much better chance at getting the best deal.

What are the Service Level requirements that must be met?

Fault tolerant storage platforms can be very expensive and so it is very important to understand what SLA’s are required before searching for a storage system. In an environment where most business can be conducted “offline” in the event of a system failure, a basic storage platform with next day parts replacement may be suitable. However, in an environment, like a large OTP database, where tens of thousands or sometimes millions of dollars can be lost each hour the system is down, the cost of highly fault tolerant storage is just part of the cost of doing business; these costs are a drop in the bucket compared to the losses that could potentially be sustained in the event of a storage system failure.

When remote replication is required there are a number of considerations that come into play when deciding on the appropriate technology.

What are the bandwidth requirements needed to replicate the data and what are the recurring costs associated (Budget considerations again).

How much data loss is acceptable in the event of a failure that requires a move to the DR systems. Many replication strategies update the remote site only periodically i.e. once an hour, once a day, etc… If a storage system were to fail or be destroyed in a fire, flood, etc… near the end of the update window, all data updated during that window would be lost.

Is replication of your applications best handled by storage replication or replication at the applications level? While storage vendors will always want to sell their replication, often the best strategies for updating database applications are done at the applications level and not at the storage level because the recurring costs of the WAN tend to be less and the time window for potential data loss is much shorter.

When considering the requirements for data protection, it is important that one not forget about backup and restore strategies. Storage platforms today are often an integral part of any backup and recovery process. Here are some considerations regarding backup and recovery.

Is there a time window for backups that is sufficient to complete required backup. For applications that must be backed up while online, storage snapshot support is often required. Additionally, supplemental software is often also required to ensure that an application’s data on disk is in a “backup ready” state when the snapshot is initiated. These features often require supplemental licenses at additional costs.

Are online periodic snapshot backups required? Many sites take periodic snapshots during the day to ensure that a minimal amount of data loss is incurred if a file or database becomes corrupted. Note: online snapshots are never an appropriate substitution for regular backups because a single raid failure can cause all snapshot data to be lost simultaneously. Most snapshot data is composed of a single copy that is shared between all snapshots.