Step 11. Plan for Database Storage

Storage Considerations

Planning an effective storage strategy, particularly if you are deploying an Enterprise, Back-End Database, is essential to the success of your Office Communications Server 2007 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, 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 environment:

• Capacity. In Office Communications Server 2007, your total capacity for the Enterprise Edition Back-End database is approximately 10 gigabytes 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 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, 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.

General Storage Principles

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

• Decrease the processing required from the CPU by implementing a specialized hardware solution, such as a RAID or a 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 small disks, because they perform better than a single large disk. For example, if you need to store 50 GB of data, consider using three 18-GB disks instead of one 50-GB disk. In general, more disks result in faster performance.

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

RAID Solutions

By using a RAID solution, you can increase the fault tolerance of your Office Communications Server 2007 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 volume). The redundant information enables data regeneration.

Considerations for Office Communications Server 2007

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

• Office Communications Server can support up to 125,000 concurrent users on a pool in the expanded configuration. The back-end SQL database of each pool or Standard Edition 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, persistent data stored in the RTC and RTCConfig database on Standard Edition Server and Enterprise pool contain important user settings and configuration settings respectively. The Archiving and CDR Server database also contains compliance information that is important for archival purposes. It is important to plan for availability and redundancy of this data.

• In Office Communications Server 2007, 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 a separate array separated from database file storage.

Among the more common methods of protecting your Office Communications Server 2007 infrastructure against failure of back-end SQL storage are SQL clustering, NAS (network-attached storage), SAN (storage area network) RAID (redundant array of independent disks) and SQL clustering.

SQL Server 2005 Enterprise Edition can be configured as a failover cluster to provide high availability support. For example, during an operating system failure or a planned upgrade, one 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.

We recommended that you use a SAN for the storage of your Office Communications Server 2007 data files, particularly for Enterprise Edition deployments larger than 50,000 clients, where availability, performance, and data protection are critical. This configuration optimizes server performance and reliability. It is expected that such organizations may already have a SAN deployed and can provision additional LUNs (logical unit numbers) and ports.

A SAN provides storage and storage management capabilities for company data. SANs use Fiber Channel switching technology to provide fast and reliable connectivity between storage and applications.

A SAN has three major component areas:

• Fiber Channel switching technology

• Storage arrays on which data is stored and protected

• Storage and SAN management software

Hardware vendors sell complete SAN packages that include the necessary hardware, software, and support. SAN software manages network and data flow redundancy by providing multiple paths to stored data. Because SAN technology is relatively new and continues to evolve rapidly, you can plan and deploy a complete SAN solution to accommodate future growth and emerging SAN technologies. Ultimately, SAN technology facilitates connectivity between multivendor systems with different operating systems to storage products from multiple vendors.

Server Partitioning Best Practices

To increase fault tolerance and provide for easier troubleshooting, do the following:

• Partition your disks so you can start with a command prompt in an emergency. Partitioning your disks in this way increases your recovery options. For example, you can start with a command prompt and modify or replace any damaged startup files that prevent you from starting Windows.

• Partition your disks so that your Office Communications Server 2007 application files, database files, and transaction log files are all on separate volumes to increase performance and reduce the amount of data you need to recover.

If you partition your hard disks by using these recommendations, each set of files is assigned a separate drive letter. Having each set of files represented by its own drive letter helps you keep track of which partitions you must back up in accordance with the data recovery method you choose.

Storing Transaction Log Files and Database Files

As previously mentioned, to provide fault tolerance in the event of a hard disk failure, keep your Office Communications Server 2007 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 data from backup. SQL transaction logs for Office Communications Server 2007 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.

Hard Disk Space Considerations

Ensure that you have adequate hard disk capacity for your Office Communications Server 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.

Performing normal backups on a daily basis reduces the amount of data that is potentially not recoverable in the event of a disk failure.

Also, you should never let your database drive become more than half full. Although a database drive that is half full results in unused disk space, it can still reduce extended server downtime for the following reasons:

• You can restore databases faster than with a full drive (especially if the file system is fragmented).

• You can perform offline defragmentation on the same physical disk instead of copying databases over to a maintenance server, (a task that takes much longer than copying database files to a temporary directory on the same physical hard disk).

• You can back up a copy of the databases to the same physical disk before you restore them, which enables you to attempt to repair the databases if a problem occurs during the restore process (for example, the existing backup contains errors). For this reason, we recommend that you move or copy the current database and log files before restoring a database.

Using Server Clustering

Microsoft Clustering Service (MSCS) is a Windows Server feature that you can use to achieve scalability and high availability for the Office Communications Server 2007, Back-End Database. A cluster consists of individual computers (also called nodes) that function cohesively in a cluster service. These computers act as network service providers or as reserve computers that take over server operations for another node if it experiences problems. Clustering provides fault tolerance and reliability. Furthermore, depending on how you configure your cluster, clustering can simplify the process of recovering a single server from disasters.

In a clustering environment, SQL runs as a virtual server (not as a stand-alone server), because any node in a cluster can assume control of a virtual server. If the node running the SQL virtual server experiences problems, the SQL virtual server goes offline for a brief period until another node takes control of the damaged node.

Office Communications Server 2007 supports two-node active/passive for the Back-End Database. Active/active clusters are not supported.

You must be familiar with MSCS concepts before you plan and deploy Office Communications Server 2007 clusters. Many resources, including Windows Server 2003 Help, Windows Server 2003 Resource Kit, and Web sites such as the MSDN® developer program (https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=MSdevProg), offer information about Windows Server 2003 clustering concepts.

Office Communications Server 2007 Database Clustering

A failover cluster comprises one or more nodes, or servers, with a set of shared cluster disks specifically configured for use with the cluster. If the active node running the application encounters a problem and becomes unavailable, the cluster fails over to the passive node. In addition to the benefits of server clustering, database clustering provides a higher level of availability to the data and to the Office Communications Server servers.

This section discusses the following aspects of Office Communications Server 2007 database clustering. You can use this information to familiarize yourself with the basic concepts around clustering and decide if you want to cluster your Office Communications Server 2007 database.

• Windows clustering and SQL virtual servers

• Quorum disk resource

• Cluster configurations

• Windows, SQL Server, and Office Communications Server 2007 version requirements

• Understanding failovers

• IP addresses and network names

• Cluster hardware compatibility list

• Scalability-related considerations

Windows Clustering and SQL Virtual Servers

Office Communications Server 2007 and SQL virtual server use the following Windows clustering features:

• Shared-nothing architecture. The shared-nothing architecture of Windows clustering specifies that all nodes in a cluster can access shared data, but they cannot access it at the same time. For example, if a physical disk resource is assigned to node 1 of a two-node cluster, node 2 cannot access the disk resource until node 1 fails or is taken offline, or the disk resource is removed from node 1 and assigned to node 2.

• Resource DLL. Windows communicates with resources in a cluster by using a resource DLL. Office Communications Server 2007 does not provide its own custom resource DLL; it uses the SQL virtual server to communicate with Cluster service.

• Resources SQL. SQL 2000 virtual servers include Windows Cluster service resources, such as IP address resources, network name resources, and physical disk resources.

Quorum Disk Resource

The most important disk in the cluster is the disk designated as the quorum disk resource. The quorum disk resource maintains configuration data in the quorum log, cluster database checkpoint, and resource checkpoints. The quorum disk resource also provides persistent physical storage across system failures. Because the cluster configuration is kept on a quorum disk resource, all nodes in the cluster must be able to communicate with the node that owns it.

When a cluster is created or when network communication between nodes in a cluster fails, the quorum disk resource prevents the nodes from forming multiple clusters. To form a cluster, a node must arbitrate for and gain ownership of the quorum disk resource. For example, if a node cannot detect a cluster during the discovery process, the node attempts to form its own cluster by taking control of the quorum disk resource. However, if the node does not succeed in taking control of the quorum disk resource, it cannot form a cluster.

The quorum disk resource stores the most current version of the cluster configuration database in the form of recovery logs and registry checkpoint files. These files contain cluster configuration and state data for each individual node. When a node joins or forms a cluster, the Cluster service updates the nodes individual copy of the configuration database. When a node joins an existing cluster, the Cluster service retrieves the configuration data from the other active nodes.

Cluster service uses the quorum disk resource recovery logs to:

• Guarantee that only one set of active, communicating nodes can operate as a cluster.

• Enable a node to form a cluster only if it can gain control of the quorum disk resource.

• Allow a node to join or remain in an existing cluster only if it can communicate with the node that controls the quorum resource.

Cluster Configurations

With the clustering process, you can manage a group of independent servers as a single system. Each server in the cluster has individual memory, processors, and network adapters, but it shares a common storage medium. Each server also has an identical processor and the same amount of RAM. A separate private network, used only for cluster communication between the nodes, can connect these servers.

The following sections discuss Office Communications Server 2007 cluster configuration.

Active/Passive Clustering. In active/passive clustering, the cluster includes a primary node and one secondary node. The secondary node is idle until a failover occurs on a primary node. When the primary node in an active/passive cluster fails or is taken offline, the clustering feature in Windows takes over. The failed node is taken offline, and a secondary node takes over the operations of the failed node. It usually takes only a few minutes for the cluster to fail over to another node. As a result, the Office Communications Server 2007 resources on your cluster are unavailable to users for only a brief period of time.

Windows, SQL Server, and Live Communications Server Version Requirements

Specific versions of Windows and SQL Server are required to create an Office Communications Server 2007 cluster. The following table outlines these requirements.

Table 109 Windows, SQL Server, and Office Communications Server version requirements

Understanding Failover

The failover time for SQL virtual servers is important. To maintain high availability, the failover time must be short. There are two scenarios for failover: planned and unplanned. A planned failover occurs when you schedule time to remove a server from operation maintenance or other reasons. An unplanned failover occurs when a server encounters a failure.

In a planned failover:

• You use the Cluster service to move the SQL virtual server to another node.

• All resources of the SQL virtual server go offline.

• You move resources move to your specified node.

• All resources of the SQL virtual server go online, Office Communications Server 2007 application comes online.

In an unplanned failover:

• At least one resource of the SQL virtual server fails. The failure is discovered with the next IsAlive check or if one of the resources fails.

• Cluster service automatically takes all dependent resources offline.

• If the failed resource is configured to restart (the default setting), Cluster service attempts to restart the failed resource and all its dependent resources.

• If the resource fails again, one of the following happens:

  • Cluster service tries to restart it again.

  • If the resource is configured to affect the group (default) and the resource has failed a certain number of times (default 3) within a configured time period (default 300 seconds), the Cluster service takes all resources in the SQL virtual server offline.

• All resources are failed over (moved) to another node in the cluster. If specified, this is the next node in the Preferred Owners list.

• Cluster service attempts to bring all resources of the SQL virtual server online on the new node.

• If the same or another resource fails again on the new node, the Cluster service repeats the previous steps and may need to fail over to the original node.

• If the SQL virtual server keeps failing over, the Cluster service fails over the SQL virtual server a maximum number of times (default 10) within a specified time period (default 6 hours). After this time, the SQL virtual server stays in a failed state.

• If fail back is configured (default is turned off), the Cluster service either moves the SQL virtual server back to the original node immediately when the original node becomes available or at a specified time of day if the original node is available again, depending on the group configuration.

IP Addresses and Network Names

A typical installation of a cluster includes a network that client computers use to connect to Office Communications Server 2007 Enterprise Edition and a separate private network for cluster node communication.

• Each node of the cluster has two static IP addresses (the public and private network connection IP addresses of each node) and one NetBIOS name.

• The cluster itself has a static IP address and a NetBIOS name.

  Important

  We recommend that you use a private network for cluster communication and static IP addresses in any cluster deployment. Using DHCP (Dynamic Host Configuration Protocol) prevents client computers from connecting to the cluster, and the entire cluster may fail if the DHCP server fails to renew the IP lease. Using a private network for cluster communication is strongly recommended. Otherwise, a failure of the public network connection of one node prevents the cluster nodes from communicating with each other, and the failure blocks affected resources from failing over and may even cause the entire cluster to collapse.

Cluster Hardware Compatibility List

For Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition, Microsoft supports only complete server cluster systems chosen from the Windows Server Catalog (https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=WinServCat). To see if your system or hardware components, including your cluster disks, are compatible, browse the hardware in this catalog. For a geographically dispersed cluster, both the hardware and software configuration must be certified and listed in the Windows Server Catalog.

The network adapters used in certified cluster configurations must be chosen from the Windows Catalog.

We recommend that your cluster configuration consist of identical storage hardware on all cluster nodes to simplify configuration and eliminate potential compatibility problems. In addition, ensure that both nodes in the cluster are identical in terms of DLLs, version of software, drivers, and patches and that no data is written to the Direct Attached Storage of either node that is critical or needs to be accessible by the other node. All data that is required subsequent to a failover must be on the shared storage.

Scalability-Related Considerations

Determining the sizing and scalability of your clusters depends on how you plan to implement server clustering. This section discusses the following aspects of cluster sizing:

• Sizing active/passive clusters

• Testing server components

Sizing Active/Passive Clusters

Active/passive clusters are the required configuration for Office Communications Server 2007 clusters. Windows Server 2003, Enterprise Edition supports two-node active/passive clusters, and Microsoft Windows 2000 Datacenter Server operating system supports two-node active/passive clusters.

Testing Server Components

It is important to test the capacity of your clusters before making them available in your organization.

The following list identifies some of the hardware components you need to test:

• Individual computer components such as hard disks, controllers, processors, and RAM.

• External components such as routers, bridges, switches, cabling, and connectors.

The following are some of the stress tests you need to set up:

• Test cluster performance under heavy network loads.

• Test cluster performance under heavy disk I/O to the same disk.

• Test cluster performance under heavy Office Communications Server 2007 services load.

• Test cluster performance under a large number of simultaneous logon attempts.

• Fail over each SQL virtual server at least once to each of the nodes.