Some users have questions about how SharePoint works. SharePoint consulting services, a solution to facilitate collaboration, content management and productivity, has enjoyed growing success over the past ten years. However, users still don't fully understand how SharePoint works. For them, SharePoint is a veritable treasure trove of business-oriented functions and features that magically appeared one day to make their lives easier – magic dust, unicorn songs and rainbows.
If only it
were that simple.
In reality, from licensing to deployment, SharePoint admins go through a comprehensive process that includes defining performance requirements → designing the server farm architecture (see below) → developing the server farm and installing SharePoint → test → define and create the information architecture → more testing → content migration → MORE of tests → and finally,
nervously granting access to users and declaring SharePoint
operational. This is when the day-to-day tasks of performance monitoring,
content and server farm assurance, settings and configuration management
(service applications, permissions, provisioning, etc.), and governance and
management begin. compliance.
No trace of unicorns. That's good enough for business users,
because they need to know how SharePoint works at least as much as knowing how
to configure Active Directory (ie not at all). But if you are not a simple
user, but rather an administrator in charge of the
architecture/configuration/management of SharePoint, it is essential to
understand the basics. Although a full deployment of SharePoint is beyond the
scope of this position, let's take a look at one of the most important concepts
in SharePoint: farm roles and how they interact.
How
SharePoint Works: SharePoint Server Farm
Clearly, a SharePoint server farm is a set of servers that
work together to fulfill SharePoint roles, thus making SharePoint work. If you
are unfamiliar with this term, think of these roles as different tasks that
each require specific skills. Once you're ready to configure SharePoint, you
configure each server on your farm to perform one or more roles.
An appropriate analogy to describe roles would be a team
working together toward a common goal (long live collaboration!). Take for
example a restaurant team. In a restaurant, the hostess is there to welcome and
seat customers, the waiter to take orders and then serve them, and the kitchen
staff to prepare the dishes. If you remove the hostess, the customer will not
have a place. If you remove the server, the customer will never be able to
place an order, or eat, or even receive a simple glass of water. You get the
idea. Of course, one person could do all of these tasks, like in a small cafe
where the person behind the counter also takes orders, tells you to sit
anywhere, and makes and serves your bagel for you. However, this only works if
the place is not crowded with people, in which case that person would quickly
be overwhelmed. Your server farms work the same way: a single server can adopt
all the roles, or you can distribute them across multiple servers to optimize
performance.
In SharePoint there are three roles (officially defined in
the SharePoint Setup Wizard with some
new roles in SharePoint Server 2016 ). These roles are: Web Front End Server
(WFE), Application Server, and Database Server.
How
SharePoint Works: Web Front Ends (WFE)
The front-end web server is supposed to be the connection
point between users in SharePoint. When a user opens a browser and visits a
SharePoint URL, they are actually addressing a front-end web server. User
requests and responses to requests always go through a front-end web server,
and are never sent directly to/from an application server or database server.
Front-end web servers host web applications (IIS web sites)
that are the top-level sites for users and other SharePoint components. The
SharePoint application is installed on your front-end web servers, which should
be optimized to receive and process user requests.
How
SharePoint Works: Application Servers
Application servers
host service applications. But what is a service application?
To understand SharePoint service applications, just think of
a car. What is the purpose of an automobile? Getting you from A to B of course.
But here it is: do you need a car stereo to get from A to B? The answer is no.
You need the engine, transmission, steering, inflated tires, brakes, etc., but
not the radio. That said, it's nice to have the radio, isn't it? Does the radio
offer features that make your trip easier and more enjoyable? Yes ? That's
exactly what SharePoint service applications do: they provide specific
functionality that makes SharePoint work for users or the server farm. The
search function is a good example. You can run SharePoint without the search
feature if you want,
SharePoint is installed on your application servers, which
are optimized to best provide the services configured on them. Service
applications can even be configured across multiple servers to improve
performance. This is often what happens for the research function by creating
what is commonly called a research farm. Users do not connect directly to
application servers. Front-end web servers "talk" to application
servers.
How
SharePoint Works: Database Servers
Microsoft SharePoint is a browser-based collaboration
platform to which users upload content, including Office documents, PDFs,
images, videos, exported emails, calendar entries, tasks, contracts and project
information. This allows them to take advantage of all the great features
provided by SharePoint, and that's what it's all about. So, one might ask: what
happens to all this content? Where does it end? To answer this question, you
first have to understand where you do
n't want it to end up.
You don't want user content on your front-end web servers.
They have quite enough work: receiving, processing and responding to user
requests. Resources (memory and storage) are not meant to handle user content
in addition to their normal load.
You also don't want user content on your application
servers. They are busy hosting and responding to local service application
requests. Just like front-end web servers, they lack the necessary resources.
Where does the user content go? Ladies and gentlemen, tonight (like every
night), the role of database server will be interpreted by Microsoft SQL
Server!
Indeed, all this user content (and also other elements) ends
up in SQL Server databases, and more specifically in SharePoint content
databases. These databases are almost always on a dedicated machine because SQL
Server is a demanding application that requires a lot of resources and minimal
latency to run SharePoint optimally. For this reason, SharePoint is usually not
installed on your database servers, nor is it necessary. Your front-end web
servers and application servers only need to know the destination of the
databases that you configure when installing SharePoint (or later) with Al Rafay Consulting.
SharePoint users never connect directly to the database
server. This is not necessary since every user request is sent to front-end web
servers.
How
SharePoint Works: Roles in Action
0 Comments