Chapter 2. Planning and Architecting a SharePoint 2007 Deployment

IN THIS CHAPTER

Many organizations have made the decision to use SharePoint for one or more reasons, but are not sure how to get started deploying the infrastructure needed by the platform. There are many misconceptions about SharePoint, and further confusing the issue is the fact that the architecture and terminology of SharePoint 2007 has changed dramatically from SharePoint 2003.

SharePoint 2007 products and technologies are extremely powerful and scalable, but it is critical to properly match the needs of the organizations to a design plan. Matching these needs with a properly planned and implemented SharePoint farm is highly recommended, and will go far toward ensuring deployment of SharePoint is a success.

This chapter covers SharePoint 2007 design and architecture. The structural components of SharePoint are explained and compared. Server roles, database design decisions, and application server placement are discussed. This chapter focuses specifically on physical SharePoint infrastructure and design. Logical design of SharePoint user components, such as site layout and structure are covered in Chapter 4, “Planning the SharePoint 2007 User Environment.”

Understanding SharePoint Design Components

The design team at Microsoft took a hard look at all the Office components, including SharePoint, when it was redesigning for the Office version 12 product line. This product line, which includes Office 2007 and SharePoint 2007, was re-architected to remove redundant and unnecessary infrastructure and to streamline and improve existing infrastructure.

Of course, at the same time that the architecture of the product was being improved, old terminology associated with the 2003 version of the products was renamed. This requires administrators familiar with 2003 terminology to throw away what they know about the technology and learn it from the ground up again. New terminology and new functionality make SharePoint 2007 a large leap ahead of SharePoint 2003, and it is important to understand in detail each of the components that make up its design.

Note

Before unnecessarily getting into complex Microsoft Office SharePoint Server (MOSS) 2007 design topics, it is important to note that the document management and collaboration needs of many organizations can be satisfied with the Windows SharePoint Services (WSS) 3.0 client, available as a free download from Microsoft. WSS 3.0 deployments are single-server deployments with SQL Server 2005 Express as the integrated database, in most cases, and so they do not require a complex design session. If basic levels of functionality are required, or simply to demonstrate SharePoint 2007 technologies in an environment, installing and using WSS is ideal.

Viewing SharePoint Components from a High Level

When end users look at a SharePoint site, they see a small piece of a complex nested infrastructure. SharePoint design components within this infrastructure range from the server farm at the highest level to subsites at the lowest level.

In Figure 2.1, the nested hierarchy of SharePoint components is illustrated. A server farm is the highest architectural design construct. It itself can contain multiple shared services providers, which themselves can contain multiple web applications. Web applications can contain multiple site collections, which can have a myriad of subsites under them. Going even further down the scale, site content itself, such as document libraries and lists, composes the content of the sites themselves.

Figure 2.1. Understanding SharePoint design components.

image

The following components make up some of the key pieces of SharePoint infrastructure:

Each of these components is described in more detail in this chapter.

SharePoint Farm

At its highest level, SharePoint deployments are defined by a logical design construct known as a server farm, or simply a farm. A farm is a group of servers that is logically administered as part of the same organization or group. They share the same administrative tools (SharePoint Central Admin tool) and are the basis for how a SharePoint environment is defined.

Some organizations choose to deploy multiple farms, but there generally needs to be a very good reason to do so because keeping both environments separate and physically isolated in separate farms is not always the ideal approach. Farms can be configured to crawl other farms and index the content on those farms if necessary, however.

Shared Services Providers

Shared Services Providers (SSPs) are another logical construct in SharePoint 2007 that provides the environment with specific services across all the web applications and sites that exist within the boundaries of the SSP. For example, a single SSP provides the following services for its members:

  • Business Data Catalog
  • Excel Services
  • Office SharePoint Server search
  • Portal usage reports
  • Personalization services and My Sites

Most server farm environments will use a single SSP. However, it is possible to create multiple SSPs for environments, as demonstrated in Figure 2.1, which require content to be securely isolated from other content, such as in industry regulation scenarios.

Excel Calculation Servers

A server that holds the role of an Excel calculation server is a server that provides Excel Services for the SSP. Excel Services provides a method for web browsers to perform spreadsheet tasks similar to Microsoft Excel functionality, but without actually having Excel installed on the client. This role can exist on a dedicated server (in the case of a large farm) or on a single server.

Search Servers

A Search server provides for search capabilities for the SSP. The Search server, once configured, will crawl all the content data within the boundaries of the SSP. Search results will be restricted to the boundaries of the SSP as well, unless the Search servers are configured to crawl the content of other SSPs or other farms.

Index Servers

Index servers provide for indexing functionality, storing searchable text for all site content, including documents, lists, and other SharePoint data. The indexing service is processor-intensive, so it is often installed on its own server, particularly in mid-size to large farms.

Web Servers

The Web server role in SharePoint 2007 is the workhorse role that handles the job of displaying the actual content to the end user’s browser. Web servers can also be set up as load-balanced pairs, as will be demonstrated in the sample design section of this chapter.

Database Servers

A Database server, in regard to SharePoint, is the actual server that holds one or more SharePoint databases. This server might be a dedicated Database server, with running databases from other applications such as Systems Management Server (SMS), Microsoft Operations Manager (MOM), Microsoft Identity Integration Server (MIIS), or other services that consume SQL database functionality. It could also run the “light” version of SQL, called SQL Server 2005 Express.

Content Databases

Content databases in SharePoint 2007 are those SQL databases that actually store the site collections. Content databases are created for the web applications, and different content databases can be created for different web applications as necessary.

Web Applications

Web applications are the logical SharePoint components that are physically attached to individual Internet Information Server (IIS) websites. Each web application can be attached to only a single IIS website. Different web applications are created to provide for different entry points and/or authentication methods to SharePoint. Web applications can be configured to either create a new content database when created or to point to an existing content database.

To illustrate, a common scenario involves a single content database where all data for an organization is kept. That content is accessed through two web applications. The first web application is bound to an IIS website that is configured to use Integrated Windows Authentication and is used for access to SharePoint from inside the company’s network. The second web application is configured through IIS with Secure Sockets Layer (SSL) encryption with X.509 certificates, allowing for secured user access to the same data from across the Internet.

Site Collections

A site collection in SharePoint 2007 is a set of WSS sites that occupy the space directly underneath a managed path. For example, if a managed path exists for /sites, and a SharePoint Site collection is created at /sites/teamsite, that site is the top of a site collection. Site collections share certain configuration information such as site templates, custom web parts, and other customizations.

SharePoint Sites

A SharePoint site is the basic building block unit of the SharePoint world. It is the defined space that has its own identity. Site administrators can configure their own security on a site, and they can change the look and feel of the site, all without changing anything for any other site. SharePoint itself can be thought of as essentially just a collection of a handful of sites, loosely grouped into a platform where they are all indexed.

Root Site

A root site is one that physically occupies the space at the root, “/", of the web application. It is typically the enterprise “portal” site for an organization.

Managed Paths

A managed path is a defined location in a web application where new site collections can be created. For example, the /sites virtual directory could be a managed path, or the root of an IIS website, “/", could also be a managed path.

Site Content

Site content can either be document libraries, lists, web parts, or any other holding mechanisms for content. This type of site content is stored in individual WSS sites within the product.

Architecting the SharePoint SQL Database Environment

One often overlooked aspect of a SharePoint environment is that the actual data, including all documents, lists, web parts, and content, is stored in a SQL Server database format. By storing the data in this format, SharePoint instantly inherits some excellent high availability options and performance enhancements, and is an ideal space for the SharePoint databases to fill.

Choosing SQL Server Version for SharePoint 2007

It is not readily apparent, however, what version of SQL Server is the best version to house the SharePoint databases on. Multiple editions of the SQL Server product support SharePoint 2007, including the following:

  • SQL Server 2005 x64 Enterprise Edition
  • SQL Server 2005 x64 Standard Edition
  • SQL Server 2005 x32 Enterprise Edition
  • SQL Server 2005 x32 Standard Edition
  • SQL Server 2000 SP3a (or higher) Enterprise Edition
  • SQL Server 2000 SP3a (or higher) Standard Edition
  • SQL Server 2005 Express Edition

Choosing between these options is not an easy task, but a few key factors should drive the decision process. These factors are as follows:

  • Is there an existing SQL Server instance that can be used? If so, it might make sense to reuse the existing investment, assuming that it has the necessary capacity.
  • Does the hardware support 64-bit computing? If so, it is ideal to use 64-bit SQL 2005 software.
  • Are advanced redundancy and high availability options needed? If so, the Enterprise Edition of SQL is necessary.
  • Is there any reason why the environment cannot use SQL Server 2005 over SQL 2000? If not, it is best to use the new version to take advantage of the new components and scalability.

Making the decision of which database to use is no small thing, but suffice it to say that most organizations use the preceding criteria to decide which version of SQL to use.

Understanding SQL Server 2005 Components

From a design perspective, it is important to understand what type of services are installed as part of SQL Server. SQL Server 2005, the preferred installation option for SharePoint 2007, has some advanced features and functionality that might be ideal for some organizations, but that might not be necessary for all. It is therefore important to fully understand the history of SQL Server and to gain an appreciation of the different components of SQL Server 2005.

Microsoft officially released SQL Server 2005 a full five years after the debut of SQL Server 2000. Administrators will immediately notice that Microsoft completely revamped the SQL Server database platform in its release of SQL Server 2005. This new enterprise-class database platform is loaded with features directly related to scalability, reliability, performance, high availability, programmability, security, and manageability, making it a more secure, reliable, and flexible platform than its predecessor.

With so many new features to discuss and so little space, this section will limit its focus to a number of different components that, together, make up the entire new SQL Server 2005 product. This discussion aims to introduce readers to SQL’s many components and their purpose. The components consist of the following:

  • Database Engine—The Database Engine component is the heart of SQL Server. It is responsible for storing data, databases, stored procedures, security and many more functions such as full-text search, replication, and high availability.
  • Analysis Services—Analysis Services delivers online analytical processing and data mining functionality for business intelligence applications. Analysis Services allows organizations to aggregate data from multiple heterogeneous environments and transform this data into meaningful information that can then be analyzed and leveraged to gain a competitive advantage in the industry.
  • Integration Services—The Integration Services component provides businesses the opportunity to integrate and transform data. Businesses are able to extract data from different locations, transform data that might include merging data, and move data to different locations such as relational databases, data warehouses, and data marts. Integration Services is the official SQL Server extract, transform, and load (ETL) tool.
  • Reporting Services—SQL Server 2005 Reporting Services includes tools such as Report Manager and Report Server. This component is built on standard IIS and .NET technology and enables businesses to design report solutions, extract report data from different areas, customize reports in different formats, manage security, and distribute reports.
  • Notification Services—The Notification Services platform consists of a notification engine and client components meant for developing and deploying applications that generate and send notifications to subscribers. Notifications are generated when they are either prompted by an event or triggered by a predefined or fixed schedule. Notifications can be sent to email addresses or mobile devices.

Architecting Server and Farm Layout

With advanced knowledge of all the components of a SharePoint infrastructure, it becomes possible to intelligently design a SharePoint environment to match the particular size and needs of an organization. Each individual design component has its own specifics that must be addressed, however. These components make up a sort of checklist that can be worked through, in order, as follows:

  • Design the farm structure
  • Design the Shared Services Provider
  • Determine server role and server placement
  • Design web application infrastructure
  • Determine the user SharePoint environment (site layout, content in sites, and so on)

All of these components except for the final one are discussed in the next section of this chapter. The final component is discussed in Chapter 4.

Designing the Farm

The farm itself defines the boundaries of the logical SharePoint environment, and is therefore an important design element. That said, there are few design decisions made that are directly related to farm structure because it is the components that reside in the farm, such as SSPs and web applications, which make up the structure of the farm itself.

Designing Shared Services Providers

Creating at least one Shared Services Provider is a critical and necessary task for a SharePoint farm. The SSP provides for services for the web applications that reside underneath them. In most cases, an organization will need to design and create only a single SSP for a SharePoint 2007 farm. In a few scenarios, however, multiple SSPs can be created as follows:

  • A branch of the organization needs total data isolation for regulatory compliance reasons.
  • The need exists to create a partner website for external vendors or partners.
  • The need exists to create a website for anonymous external users.
  • Geographically separate branches of the organization are physically isolated and don’t normally collaborate often.

Creating a separate SSP in these cases is the Active Directory equivalent of creating a separate forest for user accounts. For those familiar with Active Directory, this is a procedure that is done only if there is a very distinct need to do so, but should not be done on a regular basis because it is more difficult to administer and collaborate across SSP boundaries.

Determining Server Role Placement

When designing the SharePoint 2007 environment, one of the most critical design decisions that has to be made is which server will handle which role in the farm. A single server can handle multiple roles, but as an environment gets larger, a single server will no longer be able to take the strain of running all services.

In general, the Indexing component is often the first server role that is separated out onto its own dedicated server because it requires the most processor and memory utilization. After that, application services such as Excel Services are often separated onto dedicated hardware.

SharePoint Web Services has the distinct advantage of supporting the Windows Network Load Balancing (NLB) process, which allows multiple servers to distribute load across all the servers, allowing multiple web server roles to exist in a farm. Some of the sample designs illustrated later in this chapter incorporate NLB.

Examining Real World SharePoint 2007 Deployments

Conceptually speaking about a SharePoint environment is not the same as actually viewing some real design scenarios with the product. On that note, the last section of this chapter focuses on viewing some sample real-world deployment scenarios that are supported and give insight into the architecture and design concepts surrounding SharePoint 2007.

Viewing a Sample Single-Server SharePoint Deployment

The most straightforward deployment of MOSS 2007, aside from a simple Windows SharePoint Services 3.0–only deployment, is one that involves a single, “all-in-one” server that runs the database components as well as the Search, Indexing, Web, and Application roles. This type of server deployment, shown in Figure 2.2, has the distinct advantage of being simple to deploy and simple to administer.

Figure 2.2. Deploying a single-server SharePoint environment.

image

In this type of deployment, the server takes on all the roles of the environment, including the following:

  • SharePoint Central Admin tool
  • Single SSP
  • Content databases and other SharePoint databases
  • All site collections and sites
  • Applications roles such as Excel Services

This environment works well for those environments with fewer than 1,000 moderately active users. For those environments with greater than 1,000 users, more servers will be necessary for the environment.

Viewing a Sample Small SharePoint Farm

For those organizations with greater than 1,000 users or whose users are more active and require a separate server, the next step up in SharePoint design is a small farm model such as that shown in Figure 2.3.

Figure 2.3. Deploying a small farm.

image

In this type of deployment, three servers would be set up. The first would hold all the databases, and would essentially be a dedicated SQL server box for SharePoint. The second and third servers would be load-balanced using Network Load Balancing, and would perform redundant SharePoint front-end server roles, including the following:

  • SharePoint Central Admin tool (only on one server)
  • Single SSP distributed across both servers
  • Applications roles such as Excel Services

This model would allow this type of farm to expand from 5,000 to 10,000 moderately active users.

Viewing a Sample Mid-Sized SharePoint Farm

As an organization’s document management and collaboration needs grow, the SharePoint farm needs to grow with it. Figure 2.4 illustrates a mid-sized SharePoint farm with five total servers.

Figure 2.4. Deploying a mid-sized SharePoint farm.

image

• Server1

All SharePoint SQL Databases (Active Cluster node 1)

• Server2

All SharePoint SQL Databases (Passive Cluster node 2)

• Server3 (Index server)

SharePoint Central Admin Tool

SSP Index

Excel Calculation Server

• Server4 (Web server NLB Cluster node 1)

SharePoint Web Server

• Server5 (Web server NLB Cluster node 2)

SharePoint Web Server

This type of configuration will scale to between 30,000 and 50,000 moderately active users, depending on other factors in the environment.

Viewing a Sample Large SharePoint Farm

SharePoint operates under design principles that are massively scalable if need be. Using redundancy and load-balancing techniques such as the Microsoft Cluster Services and Network Load Balancing, more performance can be obtained from an environment simply by adding other servers to provide redundancy and load-balancing to specific roles. For example, in a very large farm, such as the one shown in Figure 2.5, multiple servers in cluster and NLB configurations allow the environment to be scaled into very large numbers of users.

Figure 2.5. Deploying a large SharePoint farm.

image

• Server1

All SharePoint SQL Databases (Active Cluster node 1)

• Server2

All SharePoint SQL Databases (Active Cluster node 2)

• Server3

All SharePoint SQL Databases (Active Cluster node 3)

• Server4

All SharePoint SQL Databases (Passive Cluster node 4)

• Server5 (Index server)

SharePoint Central Admin Tool

SSP Index

• Server6 (Index server)

SSP Index

• Server7 (Search server)

Search

• Server8 (Search server)

Search

• Server9 (Excel Calculation Server)

Excel Services

• Server10 (Excel Calculation Server)

Excel Services

• Server11 (Web server NLB Cluster node 1)

SharePoint Web Server

• Server12 (Web server NLB Cluster node 2)

SharePoint Web Server

• Server13 (Web server NLB Cluster node 3)

SharePoint Web Server

• Server14 (Web server NLB Cluster node 4)

SharePoint Web Server

This type of environment could easily scale well into the realm of hundreds of thousands of users. Larger environments have been configured as well, and SharePoint scales easily in the terabytes of data and vast number of users.

Summary

Microsoft Office SharePoint Server 2007 is a powerful tool that can allow knowledge workers to become more productive with a wide array of built-in tools and web parts. To take advantage of these features, however, the SharePoint environment must be properly designed and all the SharePoint components fully understood by the administrator in charge of designing the environment.

With SharePoint 2007 design knowledge in hand, an administrator can properly scope and scale the infrastructure to handle anywhere from a handful of users to a large, distributed deployment of hundreds of thousands of users, allowing those users to take full advantage of the productivity gains that can be realized from the platform.

Best Practices

  • Become familiar with SharePoint 2007 design terminology because it has changed significantly from SharePoint 2003.
  • Use 64-bit SQL Server 2005 for the database engine whenever possible for the best performance, redundancy, and scalability.
  • Consider separating the Indexing components from the front-end server role if the web server is overloaded.
  • Create multiple Shared Services Providers very sparingly, and only when absolutely necessary.
  • Use clustering and Network Load Balancing to scale the SharePoint server environment and provide redundancy.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset