• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 95
  • Last Modified:

SharePoint 2013 - Web tier pages

In SharePoint 2013, we can separate the servers to 3 tiers: database, application and web tier. What are some specific pages that the web tier serve? Where in the application can I specify which server serve this tier? I don’t need step by step instruction, a general direction will do.
  • 3
3 Solutions
Tim EdwardsIT Team Lead - Unified Communications & CollaborationCommented:
The web tier usually hosts the services for your site connections and iis. The application tier can be split on up to elevate resources depending on the application. The big thing is that the central admin can only be running on one server, to start or stop any particular service log into central admin, sorry going by memory right not in front of a computer but click on manage services on this page in the top right corner you can select the server you want to control the services.

Enterprise search is a good example for this as you can be resource intensive that personally I split then up on multiple server roles.
Walter CurtisSharePoint AEDCommented:
Great information above, here is some additional information that may be useful to you.

SharePoint is not a traditional web site, or portal. That is to say, there is not a root physical folder that has an index.html page that IIS is pointed to and every page is referenced and linked together from that root. SharePoint is based on the .net framework with asp.net as the primary page language. That does not mean though that there is a physical root folder with a default.aspx page or something similar to start the use of SharePoint.

SharePoint is a data driven system based on a SQL database. All content is served from the database server. All content is found within a content database. SharePoint has multiple databases with different uses. Out of the box with minimal features and sites, SharePoint has over 15 databases give or take a few.  As you mentioned, SQL is one tier of the multiple tier infrastructure. The SQL server does not have to have SharePoint installed on it however (unless you have SSRS running, another story.) The SQL server does contain all of the content found within SharePoint, and is extremely important. Without it, there is no SharePoint. Lose that server, and the data is gone, unless you have backups. There are no unique local files on the other servers, unless explicitly put there as part of a customization. (There are some files with local server information, but those files are generated by the install or update routine so they can be restored in a DR situation.)

The other two tiers could actually be run on one server, but then it wouldn't be a three tier farm.  SharePoint is a system comprised of several Windows and SharePoint services and programs. As mentioned above, the best way to see the configurable services is to go to central administration and then services on server. (There are PowerShell cmdlets for this, but that is a different story also.) As you will see there are a mix of SharePoint Service Applications, SharePoint Foundation Services (used by all versions) and feature services such as "Excel Calculation Services" which is an enterprise feature. What you don't see here are Windows services related to SharePoint. One such service is the "SharePoint Administration Service". In central administration you will see one of the most important services the "Microsoft SharePoint Foundation Web Application" service. This is the service that serves pages.
The web application service is one of the only services that should be running on the Web Front End tier of the farm. That is because a very important goal is to always get pages and content to your users as quickly as possible. (If you keep them happy, you keep your job. Sounds important to me!)

The web application service communicates directly with the SQL server to "get" content. What that means is this. When you create your first site collection, you use a template. (That template is in the form of physical files on the servers in the farm when SharePoint is installed. Those are called the SharePoint binaries. Btw... the SQL server does not have these physical files. When the site is created using one of the templates, the template is customized based on your information such as title and description, and a copy of the physical file is made and used for the site. That copy is not saved to a physical location however, but is saved to the content database for the site collection.) So the web application service gets the request from a browser somewhere in the world or within the company via IIS and asks the database for the page(s). The database delivers the data to the web application service in a binary form and the web application service serves it to the requesting browsing in a web standard format. That is why that service should always have enough resources, be it hardware or other resources to do a good job. That is also why, the other SharePoint services are found on an application server usually, the second server of a multiple tier farm.

SharePoint service applications are things such as Search, User Profile Service, Managed Metadata Service and others services. Using User Profile Service as an example, consider what it does. It reads or replicates information from Active Directory and writes it to a SharePoint database. SharePoint expands on that information by adding fields or properties such as "About Me" and other bits of information that SharePoint uses for user profiles and my sites etc... This activity can be resource intensive so in order to keep pages going to the users without interruption, User Profile Service runs on an Application server in the background more or less. If the page is requesting information about a user that is in the user's profile, the page is coded to get that page via the Web Application Service via SQL, and not even address the User Profile Service directly. The same principal applies to search and other SharePoint service applications. (Careful - MS documentation tends to say you can do a portion of search via the WFE server(s). That is only if you are doing a federated search outside of your farm. For farm internal searching, there should be no search components running on the WFE, for performance reasons.)

Although this seems long, this is just a fraction of how deep this subject can get.

Hope it helps...
ArikkanAuthor Commented:
Thank you for the answers!
Let me confirm what I understand: the 3 tier farm thing is actually referring to the ability to specify which servers the services will run on. There will be no text that literally says: this component needs to be on tier 2 server, this tier 3 server. We separate the services to improve the performance of the applications from end users’ perspective.
The servers hosting services that end users cannot interact with in anyway is considered tier 2, servers, where users might be able to send requests to, are tier 3.
If my understanding is correct, is there any official guidance on how to separate these serves and how much resources we will need to allocate to them? Do we have best practice guide or example somewhere?
Walter CurtisSharePoint AEDCommented:
Walter CurtisSharePoint AEDCommented:
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now