SharePoint administrators often become de facto SQL administrators as well; the level of SQL familiarity required by a SharePoint implementer is often fairly significant. SQL databases constitute an entire segment of the web/app/data SharePoint farm environment, so it only stands to reason that a SharePoint installation’s health is heavily invested in the performance and storage characteristics of the SQL environment that supports it.
Software boundary considerations
In the previous section, there are some boundaries given for content databases: ■■ Five hundred content databases per farm (supported limit) ■■ General content database size recommendations:
■■ 100 GB maximum recommended
■■ 200 GB supported limit
■■ A supported limit of 4 TB per content database for archival content databases with very little read/write access
■■ No explicit limit for content databases housing document center or record center sites
If you examine these limits for a moment, you come to the realization that an environment approaching these levels would be quite large. A farm containing 500 databases with an average content database size of 50 GB each would place the SQL back-end storage requirement somewhere in the neighborhood of 25 TB of storage required.
In some organizations, the data tier of your SharePoint farm will be administered by one or more SQL database administrators. this team will most likely not be familiar with the specifications and limitations present in SharePoint 2013, so you will need to be able to explain these metrics to them.
A database of 50 GB in size is quite common. As the database continues to grow beyond this limit exceeding 100 GB in size, it will set off the SharePoint Health Analyzer rule: Some content databases are growing too large.
MORE INFO SHAREPOINT HEALTH ANALYZER
In fact, there are two SharePoint Health Analyzer rules that have to do with database sizing. The first database has large amounts of unused space is a weekly check that databases that exceed 100 GB in size will set off the SharePoint Health Analyzer rule: Some content databases are growing too large.
Scaling a SharePoint implementation
A content database can house several site collections, but a site collection can reside only within a single content database; with this thought in mind, we begin to consider how to “scale-out” our environment.
Before contemplating the site collection taxonomy, you might first want to consider the lifecycle of site collections. Some site collections are fairly permanent, providing the structural backbone of your SharePoint environment; others might be quite temporary (a one-off collaborative site collection, for instance).
In an environment in which you, the SharePoint administrator, are responsible for managing growth, the initial goal is scalability. By scaling your SharePoint environment to multiple site collections, you now can control growth.
As shown in Figure 1-29, a content database is initially configured with six site collections:
- Over time, one of the site collections begins to experience rapid growth and begins to cause the content database to increase in size.
- The SharePoint farm administrator recognizes this growth and moves the larger site collection into its own content database to manage growth.
- After the content database is moved, its growth can be restricted by setting maximum number of site collections in the database to 1.
FIGURE 1-29 Moving a site collection into its own content database.
Planning host named site collections
This section and the one that follows, “Planning zones and Alternate Access Mapping,” are closely related; not because one follows the other, but because the two of them put together result in a choice about how a user will ultimately access any particular URL within a SharePoint farm. a little history
One of the primary reasons administrators used to build separate web applications for a SharePoint site was to enable a farm to have distinct URLs for different web applications. A business unit within an organization would request a particular URL for its function, such as hr.yoursharepointname.com for HR.
The farm administrator would then oblige by generating a new web application for the HR group and assigning it the hr.yoursharepointname.com host header. Other business units would find out about the new URL and begin to have the same requirement; soon the farm administrator could have several web applications:
■■ Corporate portal
■■ Human resources
■■ Information technology
■■ Accounting
■■ Operations
■■ Sales
■■ Marketing/communications
■■ Engineering
■■ Central Administration
■■ Personal sites (My Sites)
As you have seen in previous sections, the supported limit for web applications is 20 per farm. If you were to build a farm and give each business unit its own web application (simply to give it a distinct URL), you might find that your farm is quickly trending toward the 20 web application limit.
Using host named site collections
Starting with SharePoint 2007, host named (also known as host header) site collection functionality has been a native component of SharePoint. Multiple host headers can be hosted within a single web application, enabling you to assign vanity URLs to multiple site collections contained within that web application.
Setting up a new web application for host named site collections (HNSCs) requires a bit of forethought as well as some basic knowledge of PowerShell.
as of this writing, the default behavior of the New-SPWebapplication cmdlet is to create a web application in Windows classic authentication mode. this behavior can be averted by using the -authenticationProvider switch. Windows classic authentication mode is deprecated (read: not preferred/might be removed at a later date), and should not be used; claims authentication (Windows NtLM) should be used instead. PowerShell will dutifully warn you of the missing switch, but only after it has executed the cmdlet and created the web application in Windows classic mode.
When you create the new web application to contain the host named site collections, it is important to note that host headers are not assigned to the web application itself. Any host headers assigned within this web application will be assigned to the individual site collections.
When a new SharePoint installation is created, it often is the case that a new web application has also been created by default at TCP port 80 (called the Default Web Site). This site must be deleted as the new HNSC web application will need to respond to TCP port 80.
As with any other technology using host headers, DNS entries and load balancer configurations will be required for any new host named site collections.
The Central Administration interface for creating new web applications does not provide a way to build a new HNSC-based web application.
When the HNSC web application is created, a root site collection should also be created; this site collection should not be available for use, nor should it have a template assigned.
Assuming that the domain name for your SharePoint farm is something along the lines of yoursharepointname.com, you should request that your administrators place a wildcard (*) entry in DNS and point it to the IP address of your web server. Any requests that are made to this domain will then be referred to SharePoint.
Setting up host named site collections
Now that you know some of the caveats associated with host named site collections, let’s run through some of the steps required to build a web application for use with SharePoint host named site collections.
Note that these steps are very manual for the purpose of instruction; it is recommended that these steps be converted to a PowerShell script or function for repeatability.
The following steps assume:
■■ The wildcard and host header DNS entries have been made by your DNS admins.
■■ You have already removed the default web site in IIS on each web server in your farm.
■■ You know the user name/password of the account that will run the web application service.
■■ You are logged in as the farm account or another account with the correct farm/DB permissions.
This example build uses the following names/values:
■■ Application pool name: Intranet Pool - 80
■■ Application pool managed service account: boston\sp_app
■■ Web application name: Boston SharePoint Content
■■ Web server URL: http://ws2012sp13
■■ ContentDB SharePoint_Content_Boston (this database will be automatically built in the PowerShell commands shown following)
To build the example HNSC web application, do the following:
- Open a SharePoint 2013 Management Shell (PowerShell) as administrator (choose to run as administrator).
- Set the variables for your example web application:
- $AP = Intranet Pool - 80
- $APAcct = boston\sp_app
- $APMail = spapp@boston.local
- $WA = Boston SharePoint Content
- $WSUrl = http://ws2012sp13
- $ContentDB = SharePoint_Content_Boston
- Set the variable for claims authentication:
- $Provider = New-SPAuthenticationProvider
- Create the example web application:
- New-SPWebApplication -ApplicationPool $AP -ApplicationPoolAccount $APAcct
-Name $WA -Port 80 -AuthenticationProvider New-SPAuthenticationProvider -DatabaseName $ContentDB
Next, you need to build the empty (but necessary) site collection at the root of the web application:
- Set the variables for the root site collection:
- $OAlias = boston\troy
- $OMail = troy@boston.local
- Create the root site collection (note that there is no template assigned):
- New-SPSite -URL $WSUrl -ownerAlias $OAlias -owneremail $OMail To build a host named site collection, do the following:
- Set the variables for the site collection. This example uses the same account as the admin account and e-mail, but you can specify a different owner alias and e-mail as appropriate:
- $hostName = Boston Local
- $hostUrl = http://www.boston.local
- New-SPSite -url $hostUrl -HostHeaderWebApplication $WSUrl -owneralias $OAlias -owneremail $OMail -template sts#0
When to not use host named site collections
Although creating host named site collections is the preferred choice for SharePoint 2013 installations, there are times when path-based site collections are more appropriate.
Distinct web applications might be preferable in the following situations:
■■ You want to provide greater security by provisioning separating web applications; optionally, each could run under its own managed account/password.
■■ You want to assign a completely different URL to a site that does not conform to the HNSC URL structure.
Path-based site collections might be preferable in the following situations:
■■ You intend to enable the self-service site creation functionality in a web application.
■■ You need to provide unique wildcard inclusions; wildcard inclusions in an HNSCenabled web application are shared across all host name sites.