Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 22 potx

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Physical Architecture 4-7
Component Minimum requirement
Processor (CPU) 64 bit, four cores for small deployments (see “Standard Farm
Topologies” later in this module).
64 bit, eight cores for medium deployments (see “Standard Farm
Topologies” later in this module).
Memory (RAM) 8 GB for small deployments.
16 GB for medium deployments.
Hard disk 80 GB for the system drive.
Additional database storage, based on content requirements and
farm configuration.

Note: The minimum requirement values for a database server are higher than the
minimum requirements for installing Microsoft SQL Server® due to the significant load
on the database servers in a SharePoint farm.
Additional Reading
For more information about hardware and software requirements for SharePoint
Server 2010, see


MCT USE ONLY. STUDENT USE PROHIBITED
4-8 Designing a Microsoft® SharePoint® 2010 Infrastructure
Software Requirements

Key Points
WFE and application servers in a farm require the following software:
• Windows Server® 2008 Standard, Enterprise, Datacenter, or Web Server (64-
bit edition) with Service Pack 2 (SP2). Alternatively, Windows Server 2008 R2
Standard, Enterprise, Datacenter, or Web Server.
• Web server (Internet Information Services (IIS)) role.

• Application server role.
• Microsoft .NET Framework version 3.5 SP1.
• KB979917 - QFE for Sharepoint issues - Perf Counter fix & User
Impersonation.
• Microsoft Sync Framework v1.0 (x64).
• Microsoft Filter Pack 2.0.
• Microsoft Chart Controls for Microsoft .NET Framework 3.5.
• Windows PowerShell™ 2.0.
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Physical Architecture 4-9
• SQL Server 2008 Native Client.
• SQL Server 2008 Analysis Services ADOMD.NET.
• ADO.NET Data Services Update for .NET Framework 3.5 SP1.
• Windows® Identity Foundation (WIF).


Note: An update to support token authentication without transport security or message
encryption in Windows Communication Foundation (WCF) is required for the .NET
Framework 3.5 SP1 in Windows Server 2008 SP2 or Windows Server 2008 R2 before you
run Setup.
Database servers require any 64-bit version of Windows Server 2008 (or Windows
Server 2008 R2) with one of the following databases installed:
• SQL Server 2008 R2.
• The 64-bit edition of SQL Server 2008 with SP1 and cumulative update (CU)
2 or CU5.

Note: CU3 and CU4 are not recommended; instead, use CU2 or CU5.
• The 64-bit edition of SQL Server 2005 with SP3 and CU3.

Additional Reading

For more information about software requirements for SharePoint Server 2010, see



MCT USE ONLY. STUDENT USE PROHIBITED
4-10 Designing a Microsoft® SharePoint® 2010 Infrastructure
Virtualization Considerations

Key Points
Server virtualization with Hyper-V™ on Windows Server 2008 is becoming
commonplace in many organizations. Companies use virtualization to improve
server utilization and management, add flexibility to datacenters, or decrease the
costs that are associated with running multiple physical servers.
If you take the correct planning and sizing steps prior to deployment, then you can
virtualize some or all of the servers in a SharePoint farm successfully.
WFE and Application Servers
WFE and application servers are both good candidates for virtualization. You
should use performance and capacity planning guidelines to plan the number of
servers that you require. You should then consider which of these servers you want
to virtualize.
If you plan to virtualize several, or perhaps all, of the WFE and application servers,
you may require additional virtual servers to achieve the same performance as the
same number of physical servers would achieve. This requirement results from the
performance overhead of the virtualization platform. Using Windows Server 2008
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Physical Architecture 4-11
R2 Hyper-V, you can achieve near parity to physical performance with the correct
planning.
Database Servers
Virtualizing database servers running SQL Server is a difficult design decision,

because the performance overhead of the virtualization platform can affect the
entire solution. However, SharePoint 2010 fully supports virtualized database
servers.
You can always add more virtual database servers to improve performance if
required. In addition, you should allocate the same level of hardware resources,
such as processor cores and memory, to the virtual server as you would to a
physical server.
High Availability
Your virtualization platform may introduce additional high-availability options.
Some virtualization software, including Hyper-V, can make hosted virtual machines
highly available when you configure a failover cluster for the virtualization servers.
In these circumstances, individual virtual machines, such as WFE or application
servers, can fail over from one virtual host server to another.
Additional Reading
For more information about virtualization for SharePoint Server 2010, see

For more information about SQL Server 2008 virtualization, see

For more information about how to plan virtual architectures by using SharePoint
Server 2010, see
For more information about capacity management and high availability in a virtual
environment hosting SharePoint Server 2010, see



MCT USE ONLY. STUDENT USE PROHIBITED
4-12 Designing a Microsoft® SharePoint® 2010 Infrastructure
Storage Options

Key Points

When you plan for content storage on SharePoint 2010, you must choose a
suitable storage architecture. SharePoint content storage has a significant
dependency on the underlying database; therefore, database and SQL Server
requirements will drive your storage choices.
Storage Architecture
The following storage architectures are suitable for SharePoint 2010:
• Direct attached storage (DAS), where hard disks are attached directly to the
computer running SQL Server.
• Storage area network (SAN), which uses a network infrastructure to connect
the computer running SQL Server to the separate disk storage volumes.
• Network attached storage (NAS) devices may be suitable, under certain
circumstances, such as for remote binary large object (BLOB) storage.
However, this support is subject to precise NAS specifications.
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Physical Architecture 4-13

Note: Content databases with remote BLOB storage are the only configuration in which
SharePoint 2010 supports NAS storage. Any network storage architecture must respond
to a ping within one millisecond and must return the first byte of data within 20
milliseconds.
DAS is typically a significantly cheaper option than SAN storage. However, DAS
usually offers fewer management capabilities and fewer options for high-availability
configurations. SAN storage can support failover clustering in SQL Server and may
provide additional disaster recovery options, such as SAN mirroring.

Note: In general, you should choose a DAS architecture if a shared storage platform
cannot guarantee a response time of 20 milliseconds or less and sufficient capacity for
average and peak I/O operations per second (IOps).
RAID
SharePoint 2010 works well with redundant array of independent disk (RAID)-

based storage, which offers improved performance, additional fault tolerance, or
both, depending on the RAID option that you choose. The following table
describes the most common RAID types.
RAID configuration Description
RAID 0 Offers improved performance by striping data across disks in the
array. Not fault tolerant.
RAID 1 Duplicates (mirrors) data onto a second disk in the array. Fault
tolerant, but no significant performance improvement.
RAID 5 Uses three or more disks to provide fault-tolerant storage with
less wasted space than RAID 1. RAID 5 typically offers good read
I/O characteristics; however, disk write performance is typically
slower than normal, due to the fault-tolerance requirement.
RAID 10 Uses a combination of RAID 1 to provide fault tolerance and RAID
0 to provide a performance improvement. More expensive than
RAID 1 or RAID 5, but ensures optimum write performance.

Disk Types
Different storage architectures use a range of disk types. These disk types include:
• Serial Advanced Technology Attachment (SATA).
MCT USE ONLY. STUDENT USE PROHIBITED
4-14 Designing a Microsoft® SharePoint® 2010 Infrastructure
• Small Computer System Interface (SCSI).
• Serial Attached SCSI (SAS).
• Solid State Drive (SSD) or Flash Disk.

These disk types have varying performance, capacity, and cost characteristics that
you must take into consideration when you design your SQL Server storage
architecture.
Question: What is the minimum number of physical disks that you require to
implement RAID 10?

Additional Reading
For more information about how to design storage architecture based on capacity
and I/O requirements, see



MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Physical Architecture 4-15
Database Configuration Options

Key Points
SharePoint content, services, and configuration databases are stored on computers
running SQL Server; therefore, there are options for database configuration that
you must consider in your planning.
The database recovery model controls transaction log behavior in SQL Server
databases. There are three database recovery models available:
• Simple recovery. This model reuses log file space. This occurs after transactions
have been committed to the database but before a database backup occurs.
This model reduces the amount of disk space that is required between
consecutive backup operations. However, if a corruption or disk failure
occurs, you can only restore the database to the last backup.
• Full database. This model never reuses log file space. Instead, it increases the
size of the log file (and the storage requirement) when it performs new
transactions. If a database problem occurs, it is possible to restore the
database up to the last transaction, if the transaction log file is intact. For this
reason, it is best practice to store the database and log files on separate disks.
MCT USE ONLY. STUDENT USE PROHIBITED
4-16 Designing a Microsoft® SharePoint® 2010 Infrastructure
• Bulk-logged database. This model is very similar to the full model; the
exception is that bulk operations on the database are only partially

reproduced in the log file, so these bulk operations cannot be performed as a
recovery operation. This model is useful for short periods during large bulk
operations, but it is not recommended for SharePoint databases.

The following table shows the default database recovery model for databases in a
SharePoint farm.
Database
Default database
recovery model
Farm configuration database Full
Central administration content database Full
Content databases Full
Usage and Health Data Collection database Simple
Business Data Connectivity database Full
Application Registry database Full
Secure Store database Full
State database Full
Web Analytics Staging database Full
Web Analytics Reporting database Full
Search service application administration database Simple
Search service application Crawl database Simple
Search service application Property database Simple
User Profile service application profile database Simple
User Profile service application synchronization database Simple
User Profile service application social tagging database Simple
Managed metadata database Full