SharePoint 2010 Physical Design: Top 10 Considerations
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When it comes to your SharePoint 2010 rollout, you’ll want to come up with a solid physical design, which will ensure that your SharePoint deployment is responsive to users, is easy to maintain, and stands the test of time. The physical design consists of answering questions like:
- How many farms do I need?
- How many servers do I need?
- Should I use virtualization?
- How do I properly manage my environment?
- How do I plan and scale for growth?
In order to properly answer those questions and more, you’ll want to consider some key items up front before you ever touch a piece of hardware. Here’s a collection of “top 10” things to consider doing when creating your SharePoint 2010 physical design. It’s by no means exhaustive, but will give you a few things to think about.
Invest in a Solid Information Architecture and Logical Design
Before you start creating a physical design for your SharePoint deployment, you’ll need to have something to base it on. SharePoint 2010 Logical Design: Top 10 Considerations provides a concise overview of the tasks you should have completed prior to commencing a physical design. Also visit the “Logical Architecture Components” article on TechNet. Once you have a solid logical design, you’ll have a better idea of the underlying hardware you’ll need to support it.
Understand the SharePoint 2010 Server Roles
SharePoint 2010 enables you to logically separate its functionality into several roles. Logically, SharePoint can be broken up into one of three key roles:
- Web Front-end (WFE)
- Application Server
- Database Server
The WFE role renders HTML pages to users, while the application server role includes all of the service applications (things such as search crawling, search queries, Excel Services, managed metadata service, etc.). The database server role provides database services via SQL Server and does not need to use the SharePoint installation software directly. You could combine all these roles in one physical server or separate the logical roles onto many physical servers.
Determine Your Initial Sizing Requirements
There are two key components you’ll need for sizing:
- Number of users: Measured in requests per second.
- Total size of your data: Measured in gigabytes (GB) or terabytes (TB).
You typically can’t just take the total number of users that you’ll need to support and go from there. You’ll want to compute four key values—first by estimating, then by measuring:
- Concurrent users: A good rule of thumb is to expect 10 percent concurrency.
- Requests per second (RPS): The number of incoming requests processed by the farm every second.
- Total daily requests: The number of requests during a 24-hour period. This enables you to measure peaks throughout the day.
- Total daily users: The actual number of unique uses in a 24-hour period. This provides insight into who is using the system (what percentage of employees or expected users).
In terms of total data size, you’ll have to compute two key values:
- Total size of your content: Typically made up of documents, media, and web content.
- Total size of your crawl index: Typically a percentage (such as 10 percent or so) of your total searched corpus.
Be sure to review the “Capacity Management and Sizing Overview for SharePoint 2010” and “Capacity Planning for SharePoint Server 2010” articles on TechNet.
Determine the Number of Production Farms Needed
You’re probably asking yourself, “Who needs more than one farm?” Although it’s ideal to keep your number of total farms to a minimum, there are legitimate reasons for having more than one. All of the following reasons could lead you to use multiple farms in production:
- Availability requirements: You might have two groups within the company with vastly different uptime and availability requirements.
- Customization: You could decide to have different offerings supported by different farms, where on one farm you allow central customization and on the other you don’t.
- On-premise versus Cloud: You could decide to host your customized BI portal in-house while managing your ad-hoc team sites in the cloud using Office 365.
- Security isolation: You might have highly confidential information that comes with a mandate to be stored on separate hardware.
- Extremely large-scale deployments: You might need to scale beyond the capability of what a single farm can offer.
- A silo-oriented corporate culture: You might find yourself creating a farm for every department due to funding or other reasons (try to resist this one!).
- Geographically dispersed: Your organization could be global in nature, with many geo-dispersed datacenters.
Determine the Number of Total Farms Needed
What’s the difference between “total production farms” and “total farms”? In addition to production farms in operation, the total farms number also includes your development, integration, testing, staging, and authoring farms. Do you need all of those different types of farms? Probably not. But you should definitely plan at minimum for a testing farm where you can perform a QA check on custom components and service packs.
Determine Your RPO and RTO Requirements
Two important factors in determining your physical hardware requirements are:
- The time is takes you to recover from a disaster (recovery time objective, or RTO)
- How much data loss your organization can accept in the event of a disaster (recovery point objective, or RPO).
These two business objectives will guide your decision to take more frequent backups, add additional servers, or possibly even add an entire farm to your overall topology.
Decide on a Physical Topology
When considering deployment options for SharePoint, you ultimately need to consider your final topology, determining how many servers you will deploy in your SharePoint farm and what roles they will play. In SharePoint Server 2010, how you deploy SharePoint can be very flexible. In essence, you have an unlimited number of physical configurations to use when rolling out SharePoint. The following sections describe some configurations you may want to consider; they are by no means the only way, but the most common.
Single-Server Deployment
A single server hosts all three roles (WFE, application server, and database server) on a single machine. This is good for very small deployments because it’s fast and easy. The major downsides include scalability issues (there is no room to grow except for expanding things like memory and processor) and availability issues (if the server goes down, SharePoint is down). From a logical perspective, all SharePoint objects are located on this server (content sites, service applications, Central Administration, and databases). And there is no direct upgrade from a stand-alone installation to a farm installation.
Two-Server Deployment
In a two-server scenario, one of the servers hosts SharePoint (as a WFE and application server), while the second hosts the SQL Server database. This configuration provides a way to manage the database separately but adds complexity without adding scalability or availability. This step adds a second tier to the deployment. In most organizations, this is the smallest deployment that is recommended for anything other than a demonstration environment or very small group.
Three-Server Deployment
By adding an additional SharePoint server to the two-server deployment that acts as an additional WFE/application server, you gain scalability (by being able to service more requests) and availability (by load-balancing requests, so that if one SharePoint server goes down, the system stays up and running on the other machine). The single point of failure is now the SQL machine.
Four-Server Deployment
By adding another machine to the database tier and upgrading the SQL Server machine to a full cluster, we can achieve availability on both tiers of the environment. This is the smallest highly available environment, meaning that there are no single points of failure. Note that clustering is not a simple upgrade but rather a reinstall where you must move databases.
Five-Server Deployment
The next step that you should consider is to start breaking out the application services for additional performance. For example, the indexing (search crawling) process is very CPU-intensive and should often be put onto its own server, depending on the volume of searched content. In a five-server deployment, the fifth server would typically run SharePoint and host application services, primarily serving as an indexing machine. This creates a three-tier environment, with a new application server tier being added.
N-Server Deployment
The beauty of the scale-out process is that you can continue adding servers at each of the tiers, depending on the needs of the business. Do you need to serve more web pages per second? Add more WFEs. Need to dedicate processor time to calculating Excel sheets? Add some more application servers specifically dedicated to Excel Services. You get the idea.
Decide on Your Virtualization Strategy
Most organizations these days do not deploy their farms on physical hardware alone. They typically use a virtualization approach that enables them to use a single set of hardware with software-based virtualized machines. SharePoint 2010 can be virtualized, provided you take care to account carefully for server resources such as memory, disk, and CPU allocation. Be sure to check out Bill Baer’s blog entry on SharePoint 2010 virtualization.
Have a “Back-End” Governance Plan
In addition to making sure you have your physical topology correct, you’ll want a plan that manages your SharePoint 2010 environment for the benefit of all. The “Implementing Governance in SharePoint 2010” white paper provides high-level guidance on the many configuration options SharePoint provides.
Monitor and Adjust
If you do your homework, you’ll start out with a great physical topology from day one. But your job doesn’t stop there. You’ll want to make sure that you’re continuously monitoring your environment and reacting to changes over time. You should continuously validate your assumptions and run through this checklist on a regular basis (perhaps twice per year) to ensure that you’ve got the best environment to support your SharePoint deployment.
Summary
SharePoint 2010 physical design is about finding a balance between creating the simplest, lowest-cost design and still having enough horse power to support the demands of the business. Make sure you focus on up-front planning and understand the trade-offs of multiple servers, multiple farms, and multiple networks before jumping into a design.
For additional information, be sure to check out this article on TechNet: “Planning and Architecture for SharePoint 2010.” Need help? Contact me at scott.jamison@jornata.com.