Without a sufficient amount of storage space on a storage area network (SAN), Windows Server 2003 cannot operate effectively. What constitutes a sufficient amount? That varies with the specific installation, but it must be estimated when planning the SAN.
In general, storage is much more granular than the SAN itself. This means that each incremental addition to the SAN, such as a bigger switch, will handle a range of storage capacities. So unless you're close to the limit -- in performance or size -- in some part of your SAN, you won't have to add to your SAN structure to support the new storage. (In fact, SAN capacity is much more likely to be affected by the volume of traffic on the SAN than by the amount of storage it supports.)
In planning SAN capacity, you should probably assume that your company's storage needs will grow faster in the future than they have in the past. Beyond that, here are six factors to consider when sizing SAN storage for Windows Server 2003:
1. RAID redundancy. Allow for the space consumed by the RAID levels you have chosen. For example, mirroring reduces available storage space by 50% because each file is stored twice. Other RAID levels extract their own penalties.
2. Operating system. Windows Server 2003 needs at least 1.5 GB for storing operating system files. Microsoft recommends doubling that to allow for service packs and other upgrades.
3. Paging file. By default, this is set at 1.5 times the amount of RAM.
4. Memory dump. This depends on the options you have chosen, but it can be as large as the size of physical memory plus 1 MB.
5. Shadow copies. The default for the Shadow Copy Service is 10% of the available space in each volume. However, that is a minimum allocation; Microsoft recommends increasing it for most installations.
6. Log files. Log files for applications such as SQL Server can consume huge amounts of storage space for little or no increase in recoverability. Fortunately most applications allow you to set the amount of storage that will be devoted to the log files.
To do this, first decide how far back you need to keep the logs (the period between incremental backups, or sometimes between full backups). Then size the log space accordingly. You can usually set the log file to roll over and start rewriting over the oldest data when it reaches that size.
It may take some trial and error efforts to determine how much storage to allocate for each log file. There are several reasons for this. While you will want to allocate enough space to preserve the log file for the period between backups, the size of the log file is not determined by time alone. Log files are configured by storage size and grow according to application activity. Also, don't forget to allow for periods of exceptionally high activity.
Rick Cook has been writing about mass storage since the days when the term meant an 80 KB floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last twenty years, Cook has been a freelance writer specializing in storage and other computer issues.
More information from SearchWinSystems.com
