Designing and Building a Medium Server Farm for MOSS SharePoint Solutions Engineering

Transcription

1 Designing and Building a Medium Server Farm for MOSS 2007 SharePoint Solutions Engineering By Ravikanth Chaganti, Manjunath Narayanan and Kevin Guinn Dell Product Group March 2009

2 Executive Summary Implementing a Microsoft SharePoint solution presents many decision points and challenges. This paper discusses some of those challenges and provides possible solutions. It also proposes reference architectures for integrating Dell server and storage hardware into a medium server farm for Microsoft Office SharePoint Server (MOSS) The typical medium farm, as documented in this paper, is designed to handle up to 5000 users, and generally houses less than 500 GB of mixed content. One early SharePoint design decision involves selecting the appropriate product: Windows SharePoint Services (WSS) 3.0 provides a foundational set of services and capabilities, while MOSS 2007 provides extended search functionality and the ability to define audiences, which allow you to control how content is displayed and accessed. The Enterprise Edition of MOSS 2007 adds services for integrating external data and developing business intelligence systems. Determining the topology for a SharePoint solution that can accommodate up to 5000 users and provide collaboration, search, portal, and document library functions requires planning. The solution should be designed to accommodate future flexibility and scalability. A typical medium farm uses two Web front end servers, one application server, and a database server with an external storage array that hosts the SharePoint content. Choosing the right hardware for example, Dell TM PowerEdge M710 and PowerEdge M610 blade servers with Dell EqualLogic TM PS Series arrays provides a solid foundation for the farm and enables the solution to scale and accommodate future growth. Critical SharePoint deployments must meet stringent service level agreements that include data redundancy and high availability. For the database tier, Windows Server Failover Clustering and SQL Server Database Mirroring offer high levels of protection; however, each solution has its benefits and drawbacks. At the application tier, distributing various SharePoint roles across multiple servers provides enhanced availability for the solution. Finally, at the Web front end tier, Network Load Balancing (NLB) can be used to distribute workloads across multiple servers. THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND Dell Inc. All rights reserved. Reproduction in any manner whatsoever without the express written permission of Dell, Inc. is strictly forbidden. For more information, contact Dell. Dell, the DELL logo, PowerEdge, and EqualLogic are trademarks of Dell Inc. Microsoft, Windows, Windows Server, SQL Server, Excel, Word, PowerPoint, Outlook, Active Directory, and SharePoint are registered trademarks of Microsoft Corporation in the United States and/or other countries. Page ii

3 Table of Contents Executive Summary... ii Introduction... 2 Overview of SharePoint Products and Technologies... 2 MOSS Containment Hierarchy... 4 MOSS Roles and Services... 6 Designing and Building a Medium Farm for Office SharePoint Server Other Infrastructure Elements... 7 Medium Farm Topology... 8 Database Server... 8 System Hardware Architecture... 9 Operating System and Database Editions... 9 Database Storage Web Front End and Application Servers System Hardware Architecture Operating System and MOSS Editions Building High Availability and Redundancy in a SharePoint Farm High Availability for the Database Server SQL Failover Clustering SQL Database Mirroring High Availability for Web Front End Servers Redundancy for Application Server Roles Conclusions Figures Tables References Dell Resources Microsoft Resources Page 1

4 Introduction SharePoint is widely used to build and host collaborative Internet and intranet sites, portals, document repositories, and other Web based content. MOSS includes templates for many common use cases, and offers a development platform that enables significant customization. This paper provides an overview of SharePoint products, and proposes a recommended architecture for a medium farm. It also explains various components that constitute a medium size SharePoint farm, offers guidance in designing the farm solution using Dell server and storage hardware, and provides recommendations for configuring services in the farm. Some applications and content hosted within a SharePoint solution may be important to the business and, therefore, require a more strenuous service level agreement (SLA) than the basic topology can accommodate. To meet this common need, this paper also discusses techniques and alternate architectures that increase the availability of services hosted by the farm. Overview of SharePoint Products and Technologies The term SharePoint is broadly used to describe a family of products and technologies interact with Microsoft SQL Server and Internet Information Server (IIS) to provide a Web based engine and a platform for deploying a wide range of business services. The most common solutions deployed using this platform are collaborative sites, content management systems, and Web portals. Although it is possible to install every component of a SharePointbased solution on the same server, such a design is difficult to scale as business needs change. As a result, SharePoint solutions are usually deployed in a farm environment that provides scalability by distributing database, application, and presentation roles across a group of servers. Windows SharePoint Services 3.0 (WSS 3.0) provides the core engine, platform services, and facilities for creating and using templates. This core functionality is based on the ASP.NET 2.0 framework; it can be enhanced and extended by deploying MOSS 2007 and by developing custom templates and code. All data that is stored within a SharePoint infrastructure resides within a SQL Server database. Figure 1 outlines the key services provided by WSS 3.0 and the key enhancements provided by MOSS It illustrates how a SharePoint deployment builds on foundational elements provided by SQL Server and Windows Server, adds platform infrastructure elements in the form of services provided by WSS 3.0, and enhances the features and functionality of these elements through additional services provided by MOSS Improved indexing and search capabilities, the ability to define audiences and share user profile data throughout the infrastructure, and extensive reporting and analytic capabilities make a compelling case for selecting MOSS as the technology on which to build a SharePoint solution. Some MOSS 2007 services are only available with Enterprise Edition 1, including the Business Data Catalog and other services intended to facilitate creating Business Intelligence systems, such as Microsoft Excel 2007 Services. The Business Data Catalog allows SharePoint users to search against and interact with external data sources, such as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM)systems, or Oracle and SQL Server databases. Excel Services enable a rich interaction with Excel, including a snapshot facility for spreadsheets 1 For a more detailed list, see Which SharePoint technology is right for you? on Microsoft.com Page 2

5 and the ability to use Web Services protocols to remotely interact with data stored in an Excel spreadsheet. Ultimately, the Business Data Catalog and Excel Services allow users to quickly and easily develop Business Intelligence applications and workflows by simplifying access and enabling SharePoint users to work with data that must otherwise be imported through manual processes. Figure 1: SharePoint Services Provided by WSS 3.0 and MOSS 2007 As its name implies, MOSS 2007 is considered to be a part of the Microsoft Office family. As such, it offers integration and ease of use benefits when used in conjunction with Microsoft Office client applications. For example, documents stored in a SharePoint library can be directly opened from Microsoft Word, Microsoft PowerPoint, or Excel. Also, from within Microsoft Outlook, users can subscribe to and display list items from a SharePoint site or RSS feeds provided by a SharePoint powered blog. This integration makes data stored in a SharePoint infrastructure more accessible to end users. Page 3

6 MOSS Containment Hierarchy When designing and maintaining a SharePoint solution, it is important to understand the various levels at which information is organized and contained. The containers within a SharePoint infrastructure are outlined in Table 1. The most granular individual items are located at the bottom of the table, and the level of aggregation increases as you progress to the top of the table. These containers provide physical and logical boundaries 2 that should be considered while designing and deploying a SharePoint infrastructure. Table 1: Moss Containment Hierarchy Container SharePoint Farm SharePoint Servers IIS Application Pool IIS Web Application SharePoint Database Site Collection Site List Item Description A set of servers that collectively provides the databases, applications, and Web services that comprise a SharePoint solution. Individual servers that run the operating system and application software required to perform roles or provide services for the SharePoint farm. Examples include Web front end servers, application servers, and database servers. A container that is configured within IIS to constrain a defined set of content to operate within a defined set of system processes. Application Pools provide logical barriers that protect against the threat of a compromised site being used as a vector to attack other sites hosted on the same Web server. An IIS website with a unique domain name that is created and used by SharePoint products. Three Web Applications must be configured: Central Administration, Shared Services Provider (SSP), and content. Additional Web Applications may be useful for providing content isolation or for establishing distinct management or SLA boundaries within the farm. Individual SQL Server databases that are used to store information about or data from within a SharePoint farm. The core databases used by SharePoint are Configuration, Administration, SSP, Search, and Content. Depending on its architecture and needs, a farm may feature multiple SSP, Search, and Content databases. A set of sites that feature the same owners and administrative settings (such as content types or quotas). A site collection features a top level Web site, and it may also contain several subsites. Generally, all of the sites within a site collection share a common navigational design. One content database can host multiple site collections, but data from a given site collection must reside in the same content database. Similarly, one or more site collections may be configured within the same Web Application. A set of web pages within a site collection that provide common features or content to users. Sites may be structured such as a top level portal site or may be ad hoc, such as team sites for collaboration. MOSS provides templates for several types of sites including blogs, wikis, team sites, and portals. A means of collecting, storing, and organizing data within a site. Some common examples include document collections, calendars, and tasks. An individual data object within a list. Some common examples include document and image files, contacts, and calendar entries. 2 For more information, see Plan for software boundaries (Office SharePoint Server) on Microsoft TechNet. Page 4

7 Figure 2 represents the relationship between a site collection and the sites, lists, and items of which it is comprised. The items are organized into lists, which are in turn organized into sites within the site collection. This site collection is configured within a single Web application, and all of its data and items are stored in a content database. Administrative decisions and the size of the farm play a larger role in the relationships between the higher level entities outlined in Table 1. Figure 2: Example of a SharePoint Site Collection Page 5

8 MOSS Roles and Services MOSS 2007 comes in two editions: Standard and Enterprise. Most features are available in both the Standard and Enterprise editions the key features not included in the Standard edition are for Business Intelligence and Business Process Forms. Table 2: MOSS roles and services Role / Service Central Administration Shared Service Provider (SSP) WSS Search Index Query Web Front End (WFE) Document Conversion Launcher Document Conversion Load Balancer Excel Services [Enterprise Edition Only] Business Data Catalog [Enterprise Edition Only] Description This service provides the central administration interface for farm wide administration. A set of core services that can be shared across several Web applications in the farm. These services include user profiles, usage reporting, search, Excel services, and the business data catalog. One SSP can generally serve the entire farm, but additional SSPs may be desired in circumstances where business requirements dictate a strict level of data isolation for example, an extranet SharePoint implementation or an Internet facing SharePoint implementation This service is a trimmed down version of the Office SharePoint Server Search service that combines aspects of both Query and Index roles into a single service. This service is responsible for crawling content and building indexes that contain keywords and metadata related to the content. These indexes facilitate searching for people and content. Only one index server can be configured for each SSP, but it is possible for a single index server to be associated with multiple SSPs. This service is responsible for executing search queries against a locally stored copy of the index. These servers are responsible for rendering HTML contents to requesting clients and route requests to other services in the farm. Front end Web servers host the SharePoint Web application in IIS, and these servers send queries and updates to database servers in response to user requests. This service schedules and initiates document conversions on a server farm. Multiple instances of the launcher service can exist in the same farm. This service load balances document conversion requests within a SharePoint farm across multiple servers for better performance Excel Services can be used to share and re-use Excel spreadsheet models by implementing a server-based calculation service. Many instances of this service can run on the same farm. This is a fairly resource-intensive role; therefore, it can be moved to a dedicated pair of servers if the load becomes too heavy. The business data catalog service can be useful for integrating data from other databases and enterprise applications into SharePoint applications. It manipulates or presents data to the end user through business data Web parts. Page 6

9 Designing and Building a Medium Farm for Office SharePoint Server 2007 Implementing a MOSS solution must include planning for increased workloads, changing user requirements, and server failures. You can use a server farm deployment model to help ensure that your infrastructure solution is scalable, flexible, and resilient to hardware failures. The following sections of this whitepaper explain the infrastructure elements in a medium server farm and the purpose of server roles in the farm. Other Infrastructure Elements Installing a server farm for MOSS 2007 requires the inclusion of certain infrastructure and services to fully exploit SharePoint features and functionality. For example, Active Directory (AD) is a pre requisite, because it provides authentication and authorization among the servers in a MOSS 2007 farm and can be used to import user profile information from AD into SharePoint. Figure 3: Integrating SharePoint into an Enterprise Infrastructure If Exchange Server 2007 is configured in the organization, it can be used for the mail out and mail in connections for SharePoint. These connections enable features such as e mail notification of changes to a SharePoint collaboration site and the ability to create blog entries by sending an e mail. In addition, if Outlook Web Access (OWA) is configured in the Exchange environment, then data stored in Exchange such as a user or group calendar, task list, or e mail items can be directly displayed within a page on a SharePoint site. Similarly, if Office Communications Server (OCS) 2007 is in use, then user presence information can be displayed on SharePoint pages. For example, the familiar gumball from Office Communicator is displayed next to user names on the SharePoint page, providing the ability to view free/busy data, initiate instant messaging Page 7

10 conversations, send e mail, or even initiate a call with another user. Depending on the configuration of Exchange and OCS and on the log in state of other users, some of these functions may not be available. To fully exploit functionality, a SharePoint end user must be logged in to both Office Communicator 2007 and Outlook Medium Farm Topology A typical SharePoint medium server farm consists of three tiers: Web front end, application, and database. In a typical medium farm, dedicated servers are used to host each tier. Figure 4 depicts such a farm, which generally can provide services for up to 5000 users. The following section provides detailed explanations and recommendations for allocating MOSS server roles into this farm configuration. Database Server Figure 4: A typical medium deployment of SharePoint 2007 The database server is responsible for storing all SharePoint configuration and content data and providing search functionality. Because of the high levels of access the database server requires, it must have adequate processing power and system memory to provide users with high performance and availability. It is a best practice to house SharePoint content databases on external storage enclosures that are well suited to data intensive applications, such as Dell EqualLogic PS Series arrays 3, which offer a suitable number of disks for separating database components. The database server queries and updates the database in response to requests from front end Web servers. When setting up a medium server farm, you must install the Web and database server roles on separate machines to 3 Page 8

11 increase load balancing and redundancy and to simplify the process of adding additional servers to the farm as needed. If your farm services requests from Internet users, you should consider logically isolating the database server from the Web server for enhanced security. While the Web servers must be accessible, the database server can be configured behind the firewall. You can even install the database server on a separate network and allow only limited traffic to access the server. SharePoint relies on the database server more than any other server farm component, because it stores all configuration data and content. If there are any bottlenecks in the database server, performance will slow across the entire server farm. To achieve high performance from your SharePoint farm, you must maintain the database server s health. A correctly configured database server is critical to the performance and operation of a MOSS server farm. The database server should always be configured first, followed by the application server(s) and finally the Web server(s). When deciding what server will host the database, consider performance, scalability, and manageability. The PowerEdge M610 is a two socket blade server that can support up to 12 memory modules for future expandability. It also supports up to two 2.5 inch internal SAS hard drives, which allows the OS drives to be mirrored. To store SharePoint database content, external storage enclosures like the PS Series arrays are recommended. System Hardware Architecture The 64 bit extended (x64) system architecture enables direct addressing of memory beyond the 4 GB ceiling imposed by 32 bit systems. Utilizing this capability to increase the number of connections and transactions that the database server can handle requires: x64 server hardware such as Dell PowerEdge M610, an x64 operating system such as Windows Server 2008, and an x64 version of the database software. With the release of MOSS 2007 SP1, it is now possible to use SQL Server 2008 for the SharePoint databases. Operating System and Database Editions Choosing among the various editions of Windows Server 2008 and SQL Server 2008 is primarily a function of which system specifications and software features are important in the intended environment. The most important considerations for the operating system 4 are listed in Table 3, and those for the database software 5 are listed in Table 4. The high availability features listed in these tables such as failover clustering and database mirroring are examined later in this paper. Table 3: Critical Factors for Selecting an Operating System Edition Windows Server 2008 x64 Standard Edition Windows Server 2008 x64 Enterprise Edition Support for Failover Clustering No Yes, up to 16 nodes Maximum x64 Server RAM 32 GB 2 TB 4 For a more detailed comparison, see Windows Server 2008: Compare Technical Features and Specifications on Microsoft.com 5 For more details, see SQL Server 2008: Compare Edition Features on Microsoft.com Page 9

12 Table 4: Key Factors for Selecting a SQL Server Edition SQL Server 2008 x64 Standard Edition SQL Server 2008 x64 Enterprise Edition Support for Failover Clustering 2 nodes Maximum number of nodes supported by the operating system Database Mirroring High safety mode only All high performance and highsafety modes Database Backup Compression No Yes Transparent Data Encryption No Yes Resource Governor No Yes Consider the following example: A single database server (see figure 4) with a content database on an external storage array provides sufficient scalability for a company s medium farm. However, there is a business need to enhance the security of data stored in the SharePoint content database by deploying transparent data encryption and to provide higher levels of service uptime using either failover clustering or database mirroring. To meet these goals, the organization could use a PowerEdge M610 blade server installed in an M1000e chassis. The M1000e chassis will deliver a high density, highly available solution, while providing a scalable infrastructure (power, cooling, I/O connectivity, and bandwidth) for future growth. The whole medium farm including the Web, application, and database servers can be configured within a single chassis, whether it is a three server farm configuration or a large farm with six or more servers. The M1000e chassis houses up to sixteen half height blades (such as the PowerEdge M610), eight full height blades (such as the PowerEdge M710), or a combination. You can configure multiple blade servers in the same chassis to easily scale the farm s architecture for high availability and redundancy. For more information on the M1000e and Dell s blade infrastructure, see Remember that the database server is CPU and memory intensive, and requires greater disk I/O performance than other servers in the farm. For a typical medium farm, Dell recommends eight processing CPU cores and between 8 GB and 16 GB of system memory for the database server. However, two CPU sockets and twelve DDR3 DIMM slots in the M610 enable administrators to scale the server as business needs evolve. To meet the I/O requirements for SharePoint databases, the PS Series arrays are connected to the database server. At least two network interfaces on the M610 should be used as iscsi initiators, other available interfaces are configured for communication with the other farm servers. Database Storage EqualLogic PS Series arrays are well suited for a medium SharePoint farm. The performance of the database is determined by the disks and arrays you choose, and on how you place data on them. Ideally, in a medium farm you should place the TempDB, content databases, and transaction logs on separate volumes. In addition, it is recommended to configure multiple content databases, each of which is limited to 100 GB of data. Page 10

13 Table 5 outlines some of the database entities that should have dedicated spindles, and recommends appropriate RAID configurations. Physical disks that operate at 15k rpm are also preferred for database volumes. With the PS Series, it is not necessary to individually allocate spindles to a given volume. Instead, the volume is configured with a pool of disks from one or more member arrays. This greatly simplifies the configuration of these volumes. For more information on PS Series arrays, see Table 5: Database Storage Recommendations Function Preferred RAID Level Notes TempDB Data and Transaction Logs RAID 1/0 TempDB may be used heavily in a SharePoint environment. Always allocate dedicated spindles, and provision one (equal sized) TempDB data file per processor core. Transaction Logs RAID 1/0 Transaction logs are write intensive. SSP Search Database RAID 1/0 When possible, allocate dedicated spindles for the search database and consider provisioning one data file per processor core. Content Database Data RAID 1/0 for collaborative sites or when there will be significant write activity RAID 5 for read intensive content repositories or portals Consider separate content databases for site collections that are particularly active, or for site collections whose access patterns differ greatly. Consider provisioning one data file per processor core for the configuration databases. Estimating Storage Capacity Estimating the total data storage space required for a MOSS farm can be challenging, and is highly dependent on how MOSS will be used within the organization. A departmental or company wide portal may demand significantly more storage be allocated versus a team site or an individual MySite; however, there are likely to be many more of these smaller sites hosted within the farm. In addition, document libraries will generally require more storage than site features such as blogs, wikis, and other types of lists. If the versioning and recycle bin features of SharePoint will be used, then additional space must also be allocated for this data. Table 6 outlines a rule of thumb and provides some examples for estimating the required amount of storage for the content database. The database overhead in this calculation also provides for metadata storage. Specifying a lower fill factor provides additional space in the database that can be used to store document version and site recycle bins. This unused space also serves as a buffer that can accommodate growth of the content stored in the farm. Each content database should be constrained to approximately 100 GB. If the required space exceeds this value, deploying multiple content databases is recommended. Table 6: Estimating Content Database Size Requirements Size of content to be stored Database overhead Fill factor (for growth and versioning) Minimum disk space to allocate Rule of Thumb X 20% (0.2 * X) 50 70% recommended ~1.7 * X (70% fill factor) ~2.4 * X (50% fill factor) 150 GB of content 150 GB 30 GB 50% 360 GB 350 GB of content 350 GB 70 GB 70% 600 GB Page 11

14 In addition to the content databases, the SQL Server host will also require space for housing the configuration and search databases. The minimum disk space to allocate for the search database should be roughly four times as large as the Approximate index size that is calculated using the formula in Table 7 below. As discussed in that section, the size of the index can vary based on the type of content that is stored and indexed by the farm. The search database is larger than its corresponding index because the search system stores additional metadata that is not part of the index. Employing quotas to limit the size of individual sites and establishing governance policies to manage content and control the number of sites in the farm can help control the total space required by a given farm. Regardless, it is important to plan for capacity to increase over time, and to build a flexible and scalable infrastructure that will enable the farm to grow. Web Front End and Application Servers In a SharePoint farm, Web front end servers render HTML to requesting clients and route requests to other services in the farm. Web servers also host the SharePoint Web application in Internet Information Services (IIS), and these servers send queries and updates to database servers in response to user requests. As the front end Web server is the only server role that is directly exposed to the end user, you should typically install it behind a firewall or take appropriate steps to secure the server in your network. All MOSS features, site definitions, rendering, and localization files are stored on the front end Web server. MOSS also installs a number of Windows services on front end Web machines that are required to communicate with other servers in the farm and to perform administrative tasks. When deploying a front end Web server, it is generally a good idea to deploy the Complete installation type to ensure easier future scalability. In a typical medium farm deployment, you should deploy more than one Web front end server for load balancing and redundancy purposes. Managing a server farm is easier when multiple servers host the same service. It allows you to perform a rolling update of both software and hardware without affecting the availability of SharePoint services. Also, it enables you to add additional servers and reallocate roles as the farm grows to meet changing business needs. Page 12

15 Table 6 outlines which farm services can be hosted on multiple servers. How these are allocated is based on the topology of the farm, and the level of availability demanded by business SLAs. Table 7: Application Server roles and support for redundancy Application Server Role Query Excel Calculation Service Windows SharePoint Services Search Document Conversions Load Balancer Service Document Conversions Launcher Service Index Supports redundant role on multiple Server Yes Yes No No Yes No To improve search performance, you can deploy Query server roles on the Web front end servers so that all SharePoint search requests are limited to the same computer as the Web front end. The Query server role can be installed on multiple servers, as can the Web front end role. The search index in SharePoint is stored as a file, and it is propagated to the servers hosting the Query server role. Hence, the server(s) hosting the Query server role require enough hard drive space to hold the search index. The rule of thumb is that the search index file size is approximately 30% of the content database size. Table 8: Estimating Index Size Requirements Size of data crawled (based on content source) Approximate index size Minimum disk space to allocate (not including future growth) Rule of Thumb X ~12% * X 2.85 * (Index Size) = ~34% * X 150 GB of data 150 GB 18 GB 51.3 GB 350 GB of data 350 GB 42 GB GB While this rule of thumb is useful, the index size will vary based on the definitions provided by the content source. If a file share or large content repository contains a significant amount of indexed content, the index will generally contain more metadata. In such a scenario, the index size could be closer to 30% of the base content size, resulting in a recommended allocation that is only 15% smaller than the actual content. If, however, there are no document libraries and no external content is indexed, then the index size could be as low as 1% to 5% of the base content size. Because the index is distributed from the Index server to the Query servers, this space must be allocated on each server that hosts either role. For best performance, the index should be located on a dedicated RAID 1 or RAID 1/0 volume. An index volume with good write performance reduces the time required to complete a crawl operation. Similarly, good read performance improves the time required to return search results. RAID 1/0 provides a balance between read and write performance that is well suited for this purpose. Dell recommends using a PowerEdge M710 for hosting the index server and other application server roles, because it offers up to four 15k rpm hard disk drives that enable Page 13

16 the index to be stored locally. If there are a large number of documents to be indexed, it may be preferable to provision a volume on the PS Series arrays to house the main copy of the index. The Web front end server is network I/O intensive, so administrators should take precautions to handle potential bottlenecks. One precaution is to use the NLB software that is included with Windows Server 2008 and can be used to cluster multiple nodes in the network to balance incoming requests between servers. NLB can be useful in cases when there are server and/or hardware failures for example, if a server fails, other server(s) in the cluster can seamlessly begin taking client requests. Another precaution is to use NIC teaming software to overcome the problems associated with a Network Interface Card (NIC) failing in the server. NIC teaming not only provides redundancy, but it is also useful for distributing loads between the NICs. The Dell PowerEdge M710 is a two socket blade server that supports up to four 2.5 inch hard drives for internal storage, two CPU sockets, and up to eighteen memory DIMMs. Dell recommends using a PowerEdge M710 with four processing cores and at least 6 GB of RAM for servers hosting Web front end and Query server roles. For the index server, four processing CPU cores and at least 8 GB of system memory are recommended. System Hardware Architecture As with SQL Server, the various services that constitute the application and presentation tiers of the MOSS 2007 farm are available for both 32 bit (x86) and 64 bit extended (x64) architectures. Some custom code and third party packaged functions have been developed using 32 bit native code; if you need these elements in your environment, then you may choose to host the 32 bit MOSS and IIS components on an x86 version of the operating system. If you primarily use out of the box functionality or plan to develop custom functions and Web parts built with the.net framework, you should deploy the x64 versions of the operating system and MOSS In fact, Microsoft has already announced that Windows SharePoint Services 3.0 and Office SharePoint Server 2007 are the last SharePoint Products and Technologies versions able to run on 32 bit hardware and operating systems. Do take this into account in current and future hardware decisions: Buying 64 bit hardware today helps ensure that your environment can accommodate future requirements and helps you to take advantage of the performance and scale of 64 bit technologies. 6 PowerEdge M710 blades provide a solid foundation for both application and Web front end servers. Index servers should be configured on a separate host, while the Web front end and query servers can be consolidated on the same server. The capabilities of this server are well suited to both WFE/Query and Index servers, and there is ample ability to accommodate future growth. Operating System and MOSS Editions It is uncommon for a SharePoint application server or Web front end server to benefit from the enhancements in Windows Server 2008 Enterprise Edition that are not available in Standard Edition. At the application tier and Web front end tier, failover clustering is not employed for availability; instead, roles within the farm are configured to run on multiple servers. This means that, in most cases, Windows Server 2008 Standard Edition is sufficient for application and Web front end servers. For MOSS 2007, the biggest differentiator between Standard Edition and Enterprise Edition is related to the features and services that are used to develop solutions for Business Intelligence and Business Analytics. These 6 Service Pack 1 for Windows SharePoint Services 3.0 and Office SharePoint Server 2007, p3. Page 14

17 features are enabled by the Business Data Catalog and Excel Services 7 that are outlined in Table 2. If these features are (or will be) needed in the farm, you should select MOSS 2007 Enterprise Edition; otherwise, Standard Edition is sufficient. Building High Availability and Redundancy in a SharePoint Farm A business critical application hosted on a SharePoint Server solution that is not designed for high availability can lead to unacceptable amounts of service downtime and revenue loss. To ensure that hardware failures do not affect the business, you must consider availability as a part of the solution design. Overall capacity and performance requirements will affect how you implement availability within the SharePoint farm. To determine if you should implement high availability within your solution, you should look at the expected uptime, the number of users affected if service becomes unavailable, and the productivity and business losses that will accumulate until service is restored. If your solution requires high levels of uptime to prevent productivity loss when the service is offline, you should consider high availability options for each of the server roles in the SharePoint solution. Typically, high availability is the first consideration in determining the number of server computers required to deploy a server farm. Within the scope of this paper, availability refers to service or server role availability only, and does not include high availability of data through backup and restore or data protection mechanisms. To mitigate any unexpected data loss, you must evaluate various disaster and data recovery options as a part of SharePoint solution design. MOSS 2007 offers out of the box backup and restore capabilities. Native backup and restore can be performed using the SharePoint central administration user interface or stsadm command line tool. Using the built in interface, you can backup and restore either the entire farm or individual components of a SharePoint farm 8. However, the native backup and restore can be process intensive and provide high restore time and low availability. For lower backup and restore times and to reduce the downtime that your users experience, you can use other backup and restore solutions such as Microsoft s System Center Data Protection Manager or Microsoft SQL Server 2008 backup and restore methods. These alternate methods provide better disaster recovery options than native features. For example, native backup and restore cannot restore the configuration database or the central administration database; whereas, SQL Server 2008 backup can be used to restore the configuration database and central administration database. 7 See Unsupported Features in Excel Services on the Microsoft Office Developer Center to determine whether Excel Services are desirable in your environment. 8 Backup, Restore, and Disaster Recovery for Microsoft SharePoint Products and Technologies 9 Dell data protection appliance Page 15

18 High Availability for the Database Server Microsoft SQL Server 2008 provides features to ensure high availability. Table 8 summarizes and contrasts database mirroring and failover clustering, which are the two most commonly used techniques. Table 9: Failover Clustering and Database Mirroring Feature Comparison Protection Provided Recovery Method Performance Impact Operating System and SQL Server Editions SQL Server on a Failover Cluster Data is stored on a single shared storage array and employs RAID, hardware redundancy, and multipath I/O for protection. The clustered SQL Server instance can run on any node in the cluster, providing tolerance for a wide range of hardware and software faults on the host servers. The design goal for a failover cluster is to militate against a single point of failure that might cause the database to remain offline. When there is a failover event, there will be some downtime as SQL Server services are started on the alternate cluster node and the database steps through the redo logs to ensure consistency. Once this is complete, services will resume without intervention. The overhead associated with running a clustered instance versus a standalone instance of SQL Server is generally considered negligible. Operating System: Enterprise Edition is required for failover clusters SQL Server: Standard Edition supports just two cluster nodes. Enterprise Edition supports as many nodes as the operating system. SQL Server Database Mirroring Both the primary SQL Server and its mirroring partner have their own data copy, and each node s storage subsystem features RAID and hardware redundancy. Although manual recovery is necessary, the fact that there are independent database servers provides protection against faults that may adversely impact one of the database host servers. Although it is possible to use a witness system and provide automated database failover to the mirroring partner, the SharePoint application server still must be updated to connect to the alternate database server. Using SQL Server connection aliases can help reduce the time required to perform the manual (or scripted) recovery steps. Logs are compressed and transmitted to the database mirroring partner. This adds some additional CPU, network, and I/O load to the primary SQL Server system. Operating System: Standard Edition is generally sufficient. SQL Server: Standard Edition provides high safety (synchronous) mirroring. Enterprise Edition adds support for highperformance (asynchronous) mirroring. SQL Failover Clustering In a failover clustering scenario, the database is placed on an external shared storage array, such as a Dell EqualLogic PS series array. SQL Server 2008 failover clustering works in a shared nothing model; this means that each node in the cluster owns and manages its own resources. In the case of a node failure, services running on the failed node are moved to an active node. Microsoft SQL Server 2008 failover clustering can be configured as active passive clustering. There is a single instance of SQL Server on all nodes of the cluster. This environment consists of single active node and multiple inactive (or passive) nodes. In case of a database outage on the active node, all resources needed to run the SQL application and database ownership will be failed over to the new active server. In a medium farm configuration, SQL databases run in a single instance configuration. Active passive cluster configuration suits this architecture Page 16

19 well. As shown in figure 5, you can have two database servers configured in a failover cluster configuration to achieve high availability at the database tier. SQL Database Mirroring In SQL Server 2008, database availability can also be achieved using the database mirroring 10 feature. This feature is implemented on a per database basis. In a mirrored database configuration, all transaction logs from the source servers are sent to a mirrored server. The mirrored server then adds the transaction log to its own log, keeping the databases on both the servers in sync. However, as noted in table 8, mirroring does not provide an automatic failover option unless there is a witness server in the farm. Within a SharePoint farm, you can use high availability mode configuration for the SQL database to achieve automatic failover of the SharePoint database. However, in the presence of a witness server and high availability mode, only SQL databases will be automatically failed over to the mirrored servers. You still must manually reconfigure the SharePoint farm to use the mirrored server as the new database server. As shown in figure 6, primary and mirrored SQL servers can be hosted in separate blade chassis to provide additional fault tolerance for the farm us/library/cc aspx Page 17

20 High Availability for Web Front End Servers To increase availability and to handle higher workloads, Windows Server 2008 provides built in software for NLB 11. In an NLB cluster, many servers perform the same functionality to distribute loads across different physical servers in the cluster. For example, you can use the NLB feature to distribute requests at the Web front end tier. As shown in figure 5, you can configure the Web front end role on three physical servers, and then configure them to be a part of a network load balancing cluster. The third server has been added for redundancy. If the number or concurrency of user requests in a particular farm is low, then two WFE servers may be sufficient. However, in a high demand environment, two servers will be needed to handle user requests and the additional server allows service levels to be maintained in the event of a failure. The query server role is also configured on all of the Web front end servers to ensure availability. Figure 5: Highly Available Medium Farm with Clustered SQL Servers Hosting the Query role on the same servers as the Web front end role limits search requests to the same physical server, improving overall search performance in the farm. However, this design requires a larger amount of hard disk space on the Web front end servers, as the search index is stored on the server where the Query role is installed. Hence, the M710 servers are recommended. Redundancy for Application Server Roles The application tier of a SharePoint farm hosts multiple roles, such as indexing services, Excel calculation services, document conversion load balancing, and a document conversion launcher service. At the application tier, any application role except the Index role can be made redundant by adding another physical server with the same 11 Deployment process for network load balancing Page 18

21 role. If the Index role is installed on the same server as the Query role, the Index role no longer propagates content indexes to external query servers. Consequently, if you install the Index role on one of the Web servers, you lose the ability to host the Query role on both Web servers. You can install the Index role on the database server, achieving availability of the Query role on the Web servers. However, the performance of the database server will be affected. Hence, it is a better idea to install the Index role on a dedicated server for any given SSP. Any failure in the index server will make the search index update stop, and search requests will generate stale results until the index server comes online. This lack of redundancy for the Index role can be mitigated by creating a failover Shared Service Provider 12 (SSP) and configuring both primary and secondary SSPs to crawl the same SharePoint content. As shown in figure 5, you can configure a failover SSP to crawl the same content as the primary SSP. In the case of index server failure, you can manually configure the farm to use the failover SSP and provide search services to the farm. However, this design impacts the overall performance of the Query server role and also consumes double the space for the search index. As shown in figure 6, you can achieve chassis level redundancy by hosting a few Web front end and query servers inside one chassis and the rest in another chassis. The M1000e blade solution provides six redundant power supplies to ensure high availability at the chassis level. This configuration also features database mirroring to protect the content, configuration, and search databases. Figure 6: Medium Server Farm with Failover SSP Configuration 12 Plan and Configure availability in a SharePoint farm Page 19

22 Conclusions Dell PowerEdge M610 and M710 blade solutions offer high levels of performance and scalability for a MOSS 2007 farm. A single M1000e blade enclosure can host the entire SharePoint farm, and this enclosure provides six redundant power supplies to help avoid downtime due to a power outage. You can configure various blade servers in a highly available or redundant configuration to achieve higher levels of uptime. Dell EqualLogic PS arrays are optimized for SQL Server and high I/O applications such as MOSS The farm recommended in this paper integrates Dell hardware with 64 bit versions of Windows Server 2008, SQL Server 2008, and MOSS 2007 SP1. When additional protection beyond hardware redundancy is required, the farm can be extended to offer high availability for critical services. You can host the entire SharePoint farm in a single M1000e chassis to achieve high availability scenarios. You can also host the farm in two different chassis to ensure the highest levels of redundancy within various SharePoint services and database servers. Your design goals will dictate whether Windows Server Failover Clustering or SQL Server Database Mirroring is the most appropriate technology for protecting SQL Server. Similar considerations determine how to best protect the MOSS services. Figures Figure 1: SharePoint Services Provided by WSS 3.0 and MOSS Figure 2: Example of a SharePoint Site Collection... 5 Figure 3: Integrating SharePoint into an Enterprise Infrastructure... 7 Figure 4: A typical medium deployment of SharePoint Figure 5: Highly Available Medium Farm with Clustered SQL Servers Figure 6: Medium Server Farm with Failover SSP Configuration Tables Table 1: Moss Containment Hierarchy... 4 Table 2: MOSS roles and services... 6 Table 3: Critical Factors for Selecting an Operating System Edition... 9 Table 4: Key Factors for Selecting a SQL Server Edition Table 5: Database Storage Recommendations Table 6: Estimating Content Database Size Requirements Table 6: Application Server roles and support for redundancy Table 7: Estimating Index Size Requirements Table 8: Failover Clustering and Database Mirroring Feature Comparison Page 20