Planning a storage solution for Office Communications Server 2007 R2 requires knowing what types of data are generated and where each type is stored. The following table lists this information.

Table 1. Data Types and Storage

Planning an effective storage strategy, particularly if you are deploying an Enterprise pool with a back-end database, is essential to the success of your Office Communications Server 2007 R2 deployment. Failure to accurately assess your storage requirements and implement strategies optimizing data access and security can be inconvenient at best and catastrophic at worst.

As you plan your storage strategy for Office Communications Server 2007 R2, you need to balance three criteria: capacity, availability, and performance. The choices you make as you plan and implement your storage solution affect the cost associated with administration and maintenance of your Office Communications Server 2007 R2 environment:

• Capacity.In Office Communications Server 2007 R2, your total capacity for the Enterprise Edition back-end database is approximately 10 gigabytes (GB) for a large deployment. By traditional standards, a database of this size is not considered to be large.
  
  
• Availability.The availability of your database can be increased by redundancy. Redundancy can mean that you should cluster applications to provide CPU redundancy or implement a redundant array of independent disks (RAID) solution to provide data redundancy.
  
  
• Performance.Performance requirements are also unique to each organization. This refers to performance as it relates to throughput. With regard to storage technology, throughput is measured by how many reads and writes per second a storage device can perform.
  
  

Before you design your storage solution for Office Communications Server 2007 R2, determine how your company prioritizes these three criteria, especially when considering a balance between availability and performance. The following sections discuss the factors you should consider regarding storage.

Regardless of the application that you are running, consider the following storage principles to help maximize capacity, availability, and performance:

• Decrease the processing required from the CPU by implementing a specialized hardware solution, such as a RAID or a storage area network (SAN) that incorporates RAID technology. In this scenario, it is assumed that you use a hardware solution rather than a software (host-based) RAID solution.
  
  
• Decrease the overall time it takes to complete a transaction by separating files that are accessed sequentially from files that are accessed randomly. Storing sequentially accessed files separately keeps the disk heads in position for sequential I/O, which reduces the amount of time required to locate data.
  
  
• Use multiple disks, because they perform better than a single large disk. In general, more disks result in faster performance.
  
  

Use the information in the following sections to compare and contrast these storage technologies.

By using a RAID solution, you can increase the fault tolerance of your Office Communications Server 2007 R2 deployment. In a RAID configuration, part of the physical storage capacity contains redundant information about data stored on the hard disks. The redundant information is either parity information (in the case of a RAID-5 volume) or a complete, separate copy of the data (in the case of a mirrored RAID1 or striped and mirrored RAID 0+1 volume). The redundant information enables data regeneration.

When planning your storage solution, consider the following features of Office Communications Server 2007 R2:

• Office Communications Server can support up to 100,000 concurrent users on a pool in the consolidated configuration. The back-end database of each Enterprise pool and the SQL Server 2005 with SP2 database on a Standard Edition server each has a set of transaction log files and database files.
  
  
• Not all data stored on Office Communications Server is managed in the same way. A single storage solution for all data types is not the most efficient. For example, both transient and static data reside on the back-end database. The RTCDyn database stores conference state information and other information that is transient in nature. Because of its temporary nature, this information does not need to backed up or saved regularly for restoration purposes. However, it is important to plan for redundancy and ongoing availability of the following data:
  
  
  • Persistent data stored in the RTC (user settings) and RTCConfig (configuration settings) databases on a Standard Edition server and in an Enterprise pool.
    
    
  • The Archiving Server database, which contains compliance information that is important for archival purposes.
    
    
• In Office Communications Server 2007 R2, transaction log files are accessed sequentially, and databases are accessed randomly. In accordance with general storage principles, you should separate the transaction log files (sequential I/O) from databases (random I/O) to maximize I/O performance and increase fault tolerance. Specifically, you should move the transaction log files to separate disks from database file storage.
  
  To further enhance system performance, store the transaction log files for the RTCDyn database on a separate dedicated device. This helps ensure transaction throughput.
  
  
• SQL Server 2005 Enterprise Edition with SP2 or SQL Server 2008 Enterprise can be configured as failover clusters to provide high availability support. For example, to provide support in case of an operating system failure or a planned upgrade, you can configure one node in the failover cluster to fail over to any other node in the failover cluster configuration. This ability helps to minimize system downtime, thereby providing high server availability. Additionally, if you decide to implement archiving in critical mode, which means that the Office Communications Server shuts down if archiving is not available, you may want to use a failover cluster because a SQL Server failure can potentially bring down the entire Office Communications Server infrastructure.
  
  

Regardless of whether you use Direct Attached Storage (DAS) or a Storage Area Network (SAN) solution for storage, your storage solution requires proper planning and design to ensure that appropriate capacity and throughput can be delivered for Office Communications Server 2007 R2.

As previously mentioned, to provide fault tolerance in the event of a hard disk failure, keep your Office Communications Server 2007 R2 transaction log files and database files on separate physical hard disks. Furthermore, if you keep these log files and database files on separate disks, you significantly improve performance of hard disk I/O. For the data and transaction file access, select separate I/O channels on the RAID controller and, if possible, place each I/O channel on a separate RAID controller.

If the hard disk containing the transaction log files fails, but not the disk containing your databases, you do not have to restore any Office Communications Server 2007 R2 data from backup. SQL Server transaction logs for Office Communications Server 2007 R2 are collapsed on a periodic basis and are kept within a limited size. You should also enable write caching if the controller supports this capability. Enabling write caching increases throughput significantly.

Important:
If you keep your Office Communications Server 2007 R2 databases and transaction log files on the same physical hard disk, performance is impacted and, if that disk fails, you can recover only the data that existed up to your last backup.

Ensure that you have adequate hard disk capacity for your Office Communications Server 2007 R2 servers. You should have enough space on your hard disk to restore both the database and the log files. If you do not, you could have backup files that are too large to restore to their original location.