Architecting a SharePoint 2013 Deployment
- Understanding the SharePoint Server Roles
- Understanding the Reasons for Deploying Multiple Farms
- Choosing the Right Hardware for SharePoint
- Determining Optimal Operating System Configuration
- Planning for Database and Additional Software
- Examining Real-World SharePoint 2013 Deployments
- Addressing Common Business Issues with SharePoint Features
- Deploying a Team Collaboration Solution with SharePoint
- Deploying a Corporate Intranet Solution with SharePoint
- Deploying a Customer Extranet Solution with SharePoint
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Many organizations have made the decision to use SharePoint for one or more reasons but are not sure how to start deploying the infrastructure needed by the platform. There are many misconceptions about SharePoint, and further confusing the issue is that the architecture and terminology of SharePoint 2013 has changed over the years.
Many SharePoint 2013 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 that deployment of SharePoint is a success.
This chapter covers SharePoint 2013 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 the chapters in Part IV, “Using SharePoint 2013 Technologies for Collaboration and Document Management.”
Understanding the SharePoint Server Roles
What an end user of a SharePoint environment sees on a SharePoint page is the result of a complex interaction that occurs on one or more servers performing varying tasks. Information is stored in complex databases, web rendering is displayed courtesy of the web role, and searches and processes are driven by the Search service application role on servers.
Depending on the size of the environment, these roles may be on one or many servers. In very small environments, all roles may exist on a single server, whereas in very large-scale farms, the roles may be spread across tens or even hundreds of servers. These server roles are the base architectural elements in a SharePoint farm, or collection, of servers that provide for SharePoint services in an environment. It is subsequently critical to understand what these server roles are and how they are used in a SharePoint farm.
Understanding the Three Tiers of SharePoint Architecture
One of the most important points to understand about SharePoint architecture is that it is fundamentally a three-tiered application, as illustrated in Figure 2.1. The Web tier is composed of a server or servers running Windows Server’s Internet Information Services (IIS) that respond directly to end user requests for information and deliver the content to the user.
){kind=link}
FIGURE 2.1 Understanding the three tiers of SharePoint architecture.
The second tier of SharePoint architecture is the Service Application tier, which includes a list of what Microsoft calls service applications that run various services that are shared between farm members. This includes obvious services such as Search, but also includes an entire list of additional service applications such as the Managed Metadata Service, the User Profile Synchronization Service, and others. More information on this tier is provided in later sections of this chapter.
The third tier of SharePoint is the Database tier, a critical tier that runs on Microsoft’s SQL Server and that stores all content within a SharePoint environment, as well as serving as a location for shared data for service applications. Each of these tiers has unique architectural and functional requirements, and it is subsequently critical to understand these three layers before beginning design of a SharePoint farm.
Understanding the Database Server Role
Nearly all SharePoint content is stored in databases, including all document library content, list items, document metadata, and web parts. There are only two exceptions to this. The first is if the database server uses a concept known as Remote BLOB Storage (RBS), which allows for the storage of the documents, or BLOBs (Binary Large OBjects), in another storage medium such as a file server or an archive. This concept is discussed in detail in Chapter 9, “Managing and Maintaining SQL Server in a SharePoint Environment.” The other exception to this rule is the full-text search index, which is stored in flat-file format. (See the following sections on the Search service application role.) In some rare cases, certain web part solutions may store flat files on web front ends as well, which is a good idea in any case, but in reality the vast majority of SharePoint content is stored on the database server role, making it highly critical both for high availability (HA) and for disaster recovery (DR).
The only supported database format for SharePoint is Microsoft SQL Server, and at least one SQL Server database role server must exist in a farm for SharePoint to function.
Supported versions of SQL Server for SharePoint 2013 are as follows:
- SQL Server 2008 R2 x64
- SQL Server 2012 x64
There may be more than one database server role in a SharePoint farm, because a SharePoint administrator can define where a particular SharePoint database resides. In large environments, for example, there may be multiple SharePoint database role servers, each serving multiple databases as part of the farm. You can find more detailed information about the Database tier in SharePoint, including how to enable new features such as SQL Server 2012 AlwaysOn Availability Groups (AOAGs) for SharePoint farms, in Chapters 4 and 9.
Understanding the Web Server Role
The Web Server role is the most obvious of the SharePoint roles, as most people understand the concept of a server running an application that serves up web pages to users that request them. In SharePoint’s case, that application is Windows Server’s IIS application. A SharePoint farm member running the Web Server role is responsible for rendering SharePoint content, including web parts, page layout, and all other information displayed to the user.
A SharePoint Web Server role runs on either Windows Server 2008 R2 IIS 7.0 or, preferably, Windows Server 2012 IIS. In both cases, SharePoint 2013 requires specific roles to be installed in advance of installation, including the following components:
- Web server (IIS) role
- Application server role
- Windows .NET Framework version 4.5
- SQL Server 2008 R2 SP1 Native Client
- Microsoft WCF Data Services 5.0
- Microsoft Information Protection and Control Client (MSIPC)
- Microsoft Sync Framework Runtime v1.0 SP1 (x64)
- Windows Management Framework 3.0 (includes Windows PowerShell 3.0)
- Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions
- Windows Server AppFabric
- Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)
Each of these components can be installed using the SharePoint 2013 media by clicking the Install Prerequisites link on the initial splash screen. This operation requires Internet connectivity. If Internet access is not available, each individual component needs to be manually installed.
Service Application Roles
The most significant architectural change that was introduced originally with SharePoint 2010 was the addition of service applications, which replaced the SharePoint 2007 concept of shared services providers (SSPs). Service applications, which are still a critical element in SharePoint 2013, are independent services that can be shared across web applications or, in some cases, across farms.
Table 2.1 lists the service applications available with SharePoint 2013 and which version of SharePoint 2013 software they are available in.
TABLE 2.1 SharePoint 2013 Service Applications
|
|
SharePoint Foundation 2013 |
SharePoint Server 2013 Standard Edition |
SharePoint Server 2013 Enterprise Edition |
Can Be Consumed Cross-Farm |
|
Machine Translation Service |
X |
X |
X |
X |
|
Managed Metadata service application |
X |
X |
X |
X |
|
Search service application |
X (non-FAST, limited) |
X |
X |
X |
|
Business Data Connectivity Service |
X |
X |
X |
X (Caution cross-WAN) |
|
Secure Store Service |
X |
X |
X |
X (Not cross-WAN) |
|
User Profile service application |
X |
X |
X |
X (Not cross-WAN) |
|
App Management Service |
X |
X |
X |
|
|
Work Management service application |
X |
X |
X |
|
|
State Service |
|
X |
X |
|
|
Web Analytics Service |
|
X |
X |
|
|
Word Automation Services |
|
X |
X |
|
|
PowerPoint Automation Services |
|
X |
X |
|
|
Access Services |
|
|
X |
|
|
Excel Services Application |
|
|
X |
|
|
PerformancePoint service application |
|
|
X |
|
|
Visio Graphics Service |
|
|
X |
|
In addition, because the service application framework is extensible, it is possible to install third-party applications that have their own service applications. Indeed, developers themselves can also design and deploy their own applications, a concept which is beyond the scope of this book.
Service applications can be resource intensive and are often deployed on their own dedicated servers to separate their impact from the web role servers. This allows for the service application tier to run within its own contained space, rather than sharing memory, processor, and disk input/output (I/O) with the web/database roles.
Search Service Application Role
One of the most commonly used service application roles in SharePoint 2013 is the Search service application role, because it is responsible for running the Enterprise Search functionality that enables you to search both within and outside of SharePoint.
The Search service application differs from the way it was in SharePoint 2010, and drastically differs from what was provided in SharePoint 2007. SharePoint 2013 retains the capability to have multiple redundant indexes, something that was not possible in SharePoint 2007. In addition, the major change made from SharePoint 2010 was the addition of FAST Search functionality directly in all SharePoint Search engines except for SharePoint Foundation Search. FAST Search, previously a separate licensed engine, allows for new features such as thumbnail views for search results, automatic metadata tagging, and other improvements.
Notice a few key things when architecting for the SharePoint Search service application role. First, the index corpus used to store the full-text copy of all documents crawled can grow large in size based on the amount of content being indexed. The size of the corpus is directly related to the size of the actual document data being crawled. Depending on what is being indexed, and how much actual text is included in that data, the index corpus can range from 5% to 30% of the size of content being indexed, so be sure to include a large enough index disk drive for your index server.
Note a few things about SharePoint search:
- Search in SharePoint is security-trimmed for supported content, excluding some external content sources. This means that end users get search results only from content that they have rights to access. This is a highly useful feature that prevents users from seeing content to which they don’t have access.
- Although search is security-trimmed, the permissions are reevaluated only after performing a full crawl of content. Subsequently, if someone is removed from having permissions to a document, she can still see the text of that document as part of a search until a full, not an incremental, crawl has been performed.
- Because SharePoint 2013 allows for redundant search and indexing capability, any one server being down does not take down the entire environment, assuming the Search service application is running on more than one server.
For detailed information on configuring search in SharePoint 2013, see Chapter 8, “Leveraging and Optimizing Search in SharePoint 2013.”
Inbound Email Server Role and Team Mailboxes
For scenarios where SharePoint is configured to be email enabled, various SharePoint servers can be assigned to the inbound email server role. Servers with this role have the Simple Mail Transfer Protocol (SMTP) service installed directly on them and are configured to enable inbound emails to be sent directly into SharePoint document libraries and lists. This functionality is critical for an environment looking to use SharePoint for records management or enterprise content management.
SharePoint 2013 also introduces team mailbox functionality for environments running both SharePoint 2013 and Exchange 2013. The team mailboxes concept takes collaboration with email mailboxes to the next level, allowing for communications to be archived within SharePoint sites that are represented by mailboxes that adhere to the security of the site itself. For more information on how to configure SharePoint for inbound email functionality and team mailbox functionality, see Chapter 16, “Configuring Email-Enabled Content, Site Mailboxes, and Exchange Server Integration.”
SharePoint Central Admin Server Role
The server or servers that hold the SharePoint Central Administration service, the main management application for SharePoint, is also considered a server role. In some large environments, this role may be separated onto dedicated servers to provide for Central Administration functionality without affecting existing server functionality.