Executive Summary:
To keep your Microsoft Office SharePoint Server (MOSS) 2007 deployment up and running, remember these points: Use a two-tiered or three-tiered architecture for your MOSS 2007 server farm.
The two-tier approach features a clustered Microsoft SQL Server back end and a front-end server for Web content and application services.In the three-tier design, Web servers serve only Web content, and the application services are delegated their own servers. Use Microsoft Network Load Balancing (NLB) to load balance front-end servers. Use Microsoft Cluster Service (MSCS) to cluster the database back-end servers.
|
Microsoft Office SharePoint Server (MOSS) 2007 answers many business
needs, from document storage and information sharing to centralized project
tracking to exposing business intelligence (BI) data. As such, MOSS is considered
a business-critical application in most organizations, and therefore you need
to ensure that the services provided are available when needed. In this overview
of MOSS 2007 high availability, I discuss four key areas that will help you
design and deploy a highly available SharePoint environment: selecting the appropriate
architecture, understanding core services and their availability options,
implementing your high-availability strategy, and planning for failures.
Architecture Selection
There are many ways to design a MOSS farm, but it's important to choose a farm
layout that is conducive to high availability. Factors such as budget, availability
of hardware, desired performance, and service level agreements (SLAs)
will affect the number of servers in your farm and their placement. There
are two basic SharePoint architectures that provide high availability: the two-tier
architecture and the three-tier architecture. Figure
1, illustrates both architectures.
The Web content tier consists of servers that host the Microsoft IIS Web sites
that deliver content to the end user. The application tier hosts all the background
services (e.g., Excel Web Access, Search) that are used by Web parts to display
information to the end user.
The two-tier approach features a clustered Microsoft SQL Server back end and
a Web server front end. In this scenario, the front-end servers host the Web
content and the application-tier functionality. The benefit of the two-tier
approach is that it's simpler to design and implement than the three-tier setup.
The major drawback comes in potential performance loss if there's a heavy reliance
on Excel Calculation Services, which performs calculations on Excel workbooks
stored in the database, and other application-layer services.
In the three-tier design, Web servers serve only Web content, and the application
services are delegated their own servers. You need to keep in mind a few caveats,
which I discuss later on a per-service basis. The main benefit of the three-tier
approach is that it's highly scalable, allowing for easy expansion. On the downside,
it's more complex and harder to monitor and maintain.
You also need a load-balancing technology. Network Load Balancing (NLB) and
Microsoft Cluster Service (MSCS) are Microsoft's two load-balancing technologies.
In an NLB architecture, machines host the same data and share an IP address
that clients use to access the load-balanced site or service. Requests are divided
up between the load-balanced hosts according to rules set by an administrator.
In an MSCS environment, hosted services reside in virtual servers. Virtual servers
are a group of services required to run a clustered application; they are coupled
with an IP address, network name, and usually a shared physical disk that all
nodes in the cluster have access to. When one node fails, the next node configured
as a possible owner of the service takes the shared resources (IP, network name,
physical disk) and starts the necessary services, thereby starting the virtual
server. In our example, we'll use NLB on front-end servers and MSCS to cluster
the SQL Server back end.
Note that when load-balancing the front-end servers, keep in mind that NLB
operating in unicast mode with a single NIC will prevent inter-host communications,
possibly interfering with the functionality of the farm. In this situation,
it's usually best to implement the NLB cluster in Internet Group Management
Protocol (IGMP) multicast mode (provided your switch vendor supports this).
Alternatively, you can use a third-party hardware load-balancing solution.
Because failover clusters depend on their shared storage, your storage design
is important. There are many shared-storage devices available today, taking
advantage of different technologies from Fibre Channel to iSCSI. The one consideration
that you need to take into account regardless of the technology leveraged is
storage redundancy. It does no good to have redundant servers if your storage
device represents a possible single point of failure. If the situation warrants
redundancy, it probably warrants redundant storage devices. For both two-tier
and three-tier scenarios, SQL Server must be set in an active/passive failover
cluster. This provides for redundancy and ensures that the failure of one node
doesn't affect the availability of the database.
Services and Availability Options
Knowing the core SharePoint services, their functions, and methods for providing
redundancy, when possible, will help you keep the server farm highly available.
MOSS 2007 has five key services:
-
The Web Server serves Web content to end users.
-
The Query service provides query functionality for MOSS 2007 search.
-
Excel Calculation Services performs calculations on Excel workbooks stored
in the database.
-
The Index service collects and propagates the results of SharePoint Search
crawls. This information is then used by the Query service to return search
results.
-
Windows SharePoint Services (WSS) 3.0 Search provides search functionality
in the absence of Query and Index services, and provides full text search
of SharePoint Help.
Only the first three services in the list can be made redundant in your server
farm, and Table 1 shows you how to do so. The
remaining two services, WSS Search and the Index service, can't be made redundant.
The WSS Search service isn't required if
you're running the Query service and the Index
service, unless you want full-text search in SharePoint Help. If you do, you can run WSS Search
on the same server farm as the Query and Index
services with no change in functionality.
Note that although you can't make these services redundant via load balancing
or by installing them on multiple servers, it's possible to make them redundant
by installing them on a Microsoft Virtual Server virtual machine (VM) and using
MSCS to cluster them. Bear in mind that this redundancy protects only from hardware
issues, and might not provide the desired level of performance. For more information
on clustering VMs, visit http://www.windowsitpro.com/articles/index.cfm?articleid=45901&feed
=articleLink.
You can attain database redundancy by using a clustered SQL Server configuration;
you would then configure SharePoint to use the SQL cluster virtual server during
installation. For more information about clustering SQL Server, see the SQL
Server 2005 Books Online (BOL—http://technet.microsoft.com/en-us/sqlserver/bb428874.aspx)
materials and search for "clustering."
Note: During the install of SQL Server 2005
to multiple cluster nodes, keep in mind that the
installation must be performed from one of the
nodes; however, if you're logged on to one of
the other target nodes during the installation,
the install on that node will fail.
Previous
)
)
)
You say: "It does no good to have redundant servers if your storage device represent a possible single point of failure".
But also you "recommend" to use NLB, which is not able to detect software level errors. Meaning, if the web site goes down for some reason, NLB still behaves like there are no problems.
Also even your storage is HA designed, you still have a Quorum disk in cluster. If you lost that the whole cluster shutdown.
Pepi August 29, 2007 (Article Rating: