The design of your SharePoint farm
has a large impact on the level of disaster recovery. At the lower end
of the scale, a simple farm with minimal redundant hardware provides
little to no recovery in the event of failure, whereas a multiple
server farm with multiple redundant servers provides rapid recovery.
Microsoft designed SharePoint 2013 to scale, to allow reuse of common
services across multiple infrastructure hardware, and to embrace
virtualization. In this section, I shall discuss some of the high-level
considerations when planning an Enterprise SharePoint infrastructure
for maximum uptime.
Looking at a SharePoint farm from a 50,000-foot
view, we see the farm essentially consists of a data storage component,
some service middleware, and web-front-end to render pages to end
users. Consider Figure 1 as the bare minimum components of a SharePoint farm, which consists of
- A SQL data store
- An application server for middleware services
- Two web-front-end servers
The diagram in Figure 1
provides very little redundancy—should the SQL Server fail, the farm
goes offline. SharePoint can partially operate without a working
application server, but services like search, user profiles, Business
Connectivity Services, business intelligence, managed metadata, etc.
that rely on the application server will fail, rendering SharePoint to
basic collaboration. There is minimal redundancy with two web-front-end
servers and the ability to distribute user request load to these
servers. This is important because the WFE servers are the entry to the
SharePoint farm for users, and without them, the farm might as well be
inoperable.
Now consider the diagrams in Figure 2 and Figure 3—this infrastructure is vastly larger than the example presented in Figure 1.
This design separates the farm into six tiers, consisting of the web
server tier, application server tier, search index and query tier,
other search components tier, database search tier, and database
content tier. One immediate observation in this larger design is the
separation of search services and search data from other tiers in the
farm. SharePoint 2013 relies heavily on the
Search platform (FAST) to allow users’ to search and discover content.
Unlike previous versions of SharePoint, SharePoint also leverages the
search platform for content rollup and rendering of dynamic content,
which constantly changes. As you can imagine, with the search platform
playing such an important role in the SharePoint farm, it deserves big
consideration in the overall farm design. The search platform itself
consists of multiple components, which, like the rest of the farm,
require redundancy to combat anticipated failure.
The design in Figure 2 and Figure 3
leverages virtual server technology, which provides greater number of
redundant virtual servers. Infrastructure consisting of large number of
servers benefit from virtual servers, running on multiple virtual host
servers (the physical hardware) and save the organization the cost for
procurement of physical hardware and costs associated with maintaining
physical hardware.
Notice the design provides redundancy across
the physical infrastructure – multiple virtual hosts – as well as
redundancy with multiple virtual servers. This is important because
physical hardware often fails. Operating multiple redundant virtual
servers on one physical host fails disaster recovery if the physical
server dies.
The design in Figure 2 and Figure 3
also caters for distribution of services and data across multiple
virtual servers and across multiple host servers. In the event that
either a virtual server fails, or a physical server fails, the data and
operating service resides on another virtual server on another physical
host.
Of course, the design in Figure 2 and Figure 3
is quite elaborate and caters for many disaster scenarios. There are
plenty of scaled-down designs that provide a good level of redundancy,
which fall in between the design shown in Figure 1, Figure 2 and Figure 3. This is the beauty of SharePoint; you can design your SharePoint farm around the business need of the organization.
Depending on the size of your organization, you
might have to consider multiple global office locations across in your
SharePoint infrastructure design (Figure 4).
If your organization shares data across multiple offices and that data
resides in SharePoint, it may not make sense to host one copy of the
data in a single SharePoint farm at one office location. SharePoint
2013 scales globally and allows cross-pollination of data between
multiple offices. This design provides location redundancy—if an entire
office goes dark (perhaps because of power failure or natural
disaster), the business can continue using one of the other office
locations.
Design of globalized SharePoint farms
is nontrivial and impacts network connectivity design. Globalized
scenarios require considerable planning for how to replicate data and
must consider peak usage of data for multiple offices in multiple time
zones.
