Reviewing the HA configuration

Symantec recommends as a best practice to configure SQL Server for high availability before configuring SharePoint Server.

Configuring SQL Server for high availability is covered in the SQL Server solutions guides.

See Where to get more information.

In a typical example of a SharePoint Server high availability environment, SharePoint Web Applications and Service Applications are configured on a separate set of cluster nodes. A VCS parallel service group manages the Web Applications residing on the Web servers and local service groups manage the application servers. The SharePoint databases are made highly available using the VCS SQL Server service group. The databases reside on shared storage that is accessible from all the SharePoint server nodes in the cluster.

Figure: Typical SharePoint Server Configuration illustrates a typical SharePoint Server configuration. The SharePoint farm layout is as follows:

Figure: Typical SharePoint Server Configuration

Typical SharePoint Server Configuration

The graphic displays SQL and SharePoint Servers in different clusters. However, if the SharePoint Servers and SQL Servers are using the same operating system and platform, you can configure both SQL and SharePoint nodes in the same cluster.

The SharePoint Web Applications are configured in a parallel service group that is online on Nodes N1, N2, and N3. The application servers host SharePoint services such as Access Services and Excel Services that are used by the Web servers. These application services are configured in local service groups on nodes N4 and N5 separately. If any of the configured Web or Service applications become unavailable, the SharePoint agent attempts to restart those components in the cluster. If the component fails to come online, the agent declares the resource as faulted.

The databases are made highly available by the SQL service group that is configured on nodes N6 and N7. The databases are configured on the shared storage. The SQL virtual server is online on node N6. All client requests are handled by node N6. N7 waits in a warm standby state as a backup node, prepared to begin handling client requests if N6 becomes unavailable. If N6 fails, N7 becomes the active node and the SQL virtual server comes online on N7. From the user's perspective there will be a small delay as the backup node comes online, but the interruption in effective service is minimized.