Practical Storage Area Networking: Project Modeling
This chapter is from the book
This chapter is from the book
This chapter is from the book
Project modeling is done as an investigation of the design constraints of a project. In a SAN project, the I/O behaviors of the host systems and applications that will use the SAN are examined for extremes and trends. A good project model takes into account the complete range of tasks the SAN is expected to perform and is based on existing systems or reasonable estimates. A good project model does not have to take a long time to complete, provided assumptions can be made about the expected results to limit the amount of examination required. Models allow the designer to verify the resulting SAN behaviors without the risk of moving critical applications and host systems to the SAN. Start modeling your project with assessments of storage and I/O workload requirements.
3.1 Storage Requirements
Storage requirements can be determined from general rules and knowledge of the target SAN type.
General Rules for Sizing Storage
The expected data set size, or the data set size plus the expected growth of the data set if it already exists, determines the storage requirements. Application users, developers, and database administrators should have an idea of the type of data being stored and characteristic sizes, so they are good sources of sizing information. In a new application, if the typical record size in a database or the size of commonly stored data for an application can be determined, then simply multiply the size by the total expected starting number of records to determine the total amount of storage. If growth can be predicted on the basis of the number of users or the number of records, then storage can be sized for expected growth as well. A last resort for sizing information can simply be a guess based on general information about the new application.
Requirements by SAN Type
Depending on the type of SAN being implemented, assumptions about the amount of storage required can eliminate much of the storage size analysis.
STORAGE CONSOLIDATION
To determine a storage consolidation SAN's requirements, look at the target host systems, add up all the storage in use on the host systems, and add the growth rates of the data on those host systems. A storage consolidation SAN more efficiently accommodates the storage space growth rates of the host systems because all storage space in the SAN is available to all host systems.
NAS REPLACEMENT
A NAS replacement is similar to a storage consolidation SAN. To determine the amount of storage needed, add up all the storage space in use on the existing NAS and look at the expected growth rate of the data stored on the NAS systems.
NAS replacement SANs that implement tape backup require a different storage sizing method due to the unlimited total storage of removable media devices. Size a NAS replacement SAN for tape backup by determining the number of tape drives required to service the backup workload. The number of tape drives depends on all of the following:
The number of concurrent backups
The amount of data to be backed up
The amount of data each tape will store
The amount of time available for system backups
A complete discussion of backup system sizing would be a digression here; there are several good books on this topic. As a simple rule of thumb, use one tape drive for each concurrently backed up file system. Unless the data sets are small, avoid backing up data from multiple sources onto a single tape. Resource contention and possible restore conflicts can occur if multiple backups for different host systems are on the same tape.
CAPACITY PLANNING
For capacity-planning SANs, determine the size of storage by looking at the data set sizes of systems likely to use the SAN. A capacity-planning SAN that supports data warehouse extraction, transformation, and load (ETL) processing has greater storage requirements than a capacity-planning SAN that supports OLTP. This difference reflects the generally smaller overall sizes of high-performance OLTP applications. To estimate a good storage size, look at the typical storage size and the growth requirements of the target systems. If a given system requires 200GB of storage today and doubles in size every six months, and another like it is deployed every six months as well, then a reasonable sizing estimate for a six-month capacity-planning solution is 800GB.
EXPERIMENTAL
Experimental SANs require little or no analysis of storage sizing. Because the purpose is pure experiment, the typical size of a system from your environment makes the best test case. If the experimental SAN's storage size is too small, the investigations cannot yield enough information. If the storage size is too large, there is obvious waste.
NEW PROJECT
When attempting to size a SAN for a new project with little or no relation to any existing system, it is important to find out as much as possible about the new application. Investigation of the expected record size and the number of records goes a long way toward determining the required storage space. System and application overhead requires an additional 10 to 25 percent of space. The expected growth of the application data is also important when planning for system growth.