Before we get in to the details of each concept in SharePoint, I though I would share some basic things a user should now about its architechture and its storage
Below are few key terms which every SharePoint admin or developer should know
SharePoint Farm :
SharePoint farm is a logical grouping of SharePoint servers that
share common resources
A Farm can have single server (Stand alone with everything installed on same server, which is generally useful for small scale business) or multiple servers (which include one or more WFE servers, Application servers , DB servers and network load balancer to manage the traffic or requests according the requirement and number of users accessing the application)
Note: A SharePoint farm can only have one central administration database
although you can host the central administration website on more than
one server in your farm. A SharePoint farm must have one Configuration Database.
Web Front End Server (WFE):
A web server handles web page requests from users, processes the request and returns the data.
They process HTTP/S traffic and rely on Internet Information Server (IIS) to provide much of the web server 'stack'.
In a farm there can be multiple Web Front End (WFE) servers and a
Network Load Balancer (NLB) will distribute requests between them. This is the primary method of scaling in SharePoint - as the number of users grows you add more WFE servers. If a WFE fails the NLB can distribute requests to other WFE's.
Application Server :
An Application Server is a computer that provides key infrastructure and services for applications that are hosted on a farm.
Typically - in SharePoint this means that a server that has been
assigned to run duties such as Excel, Visio or Access Services or
Index/Search services - as opposed to general web server duties of a Web Front End Server.
Configuration Database:
The SharePoint config database is used by central administration to help
manage all of your web applications, site collections, service
applications, what's server and services are on the farm etc. Each server in the farm is able to
directly interface with the central configuration database. Servers
use this to configure services (e.g. IIS, windows features, database
connections) to match the requirements of the farm, and to report
server health issues, resource allocation issues, etc.
Every SharePoint site is distributed among 3 logical parts, namely: -
- IIS (inetmgr.exe) - Where website are created for each web application.
- Just like a normal asp.net website, virtual directories are created for
each web application in sharePoint. This directories consists of the
.aspx pages, web.config, short-cuts to 14 hive folders like _layouts,
_vti_bin etc.
- Best reference: http://abhijitjana.net/2010/03/14/beginner%E2%80%99s-guide-how-iis-process-asp-net-request/
- The 14 Hive ("C:\Program Files\Common files\Microsoft Shared\Web Server Extensions\14 ") - Store configuration files, templates and other components for supporting SharePoint 2010.
- All the configuration files like web.config, feature.xml, etc reside in
14 Hive. It also consist of all the in-built SharePoint master-pages,
styles, site definitions, etc. Any custom developed component like
webparts, user controls, application pages etc is deployed in 14 hive.
The files in 14 hive are accessed by IIS through shortcuts configured by sharePoint inside the virtual directories.
- Content Database - Back end server for each web application.
- This is back-end database base where all the SharePoint data is stored.
List Items, Document library contents, site pages etc are stored in the
content database. In the following figure you can see a database named "WSS_Content_3000" exclusively created for "SharePoint : 3000" web application.
How does IIS handle a SharePoint request
1) A request for SharePoint page is sent through browser arrives at
HTTP.sys in
IIS. The HTTP.sys determines if the request is valid. If the request is
not valid, it sends a code for an invalid request back to the client.
2) An IIS website monitors for incoming requests through a
particular port, and it checks for a particular host header or IP
address, or both. Every SharePoint Foundation web application is hosted
in an IIS website that has the same name as the web application.
3) The request is passed through a
pipeline of units including
authenticating the user, verifying the user’s authorization, building
the response, sending the response, and finally, logging the request.
4) The response to any request is produced by an
HTTP handler object.
Requests are assigned to one or another HTTP handler object depending
on the resource requested and the HTTP verb in the request.
5) The request pipeline also contains
HTTP modules. Modules are
assemblies that typically contain one or more event handlers or define
new events that other modules can handle. An HTTP module can register
for one or more events in the life cycle of the request.
6) The processing of a request by HTTP modules and an HTTP handler is
governed by an HttpApplication object or an object derived from that
class. SharePoint installs a
global.asax file in the root of each web application (IIS website) that identifies
SPHttpApplication as the class from which an HTTP application object is created.
7) SharePoint also modifies the pipeline with a custom HTTP module
(SPRequestModule), and with changes to the default
applicationhost.config file.
8)
SPRequest module eventually request the location of the
SharePoint configuration database from the registry. Connection string
for the SharePoint configuration database is set using DSN key at
HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure\ConfigDB.
So, this is the registry value, you need to change, if you ever need to move configuration database.
9) When an HTTP request is received by a front-end web server, a special
driver, HTTP.SYS, detects the request and routes it to the application
pool that is handling requests for the targeted IIS website, and thus,
the targeted SharePoint web application. Every application pool has an
IIS worker process (
w3wp.exe) in which the request pipeline for each request is executed.
10) After processing the request, the worker process sends the response
back to HTTP.sys which in turn sends the response back to the client and
logs the request, if configured to do so.
