SharePoint 2010 Mythbusters

SharePoint 2010

Mythbusters

IT112

Spencer Harbar Enterprise Architect

harbar.net

About Spencer

www.harbar.net | [email protected] | @harbars

General SharePoint Dogsbody

Microsoft Certified Master | SharePoint 2007

Microsoft Certified Master | SharePoint Instructor & Author

Most Valuable Professional | SharePoint Server

SharePoint Patterns & Practices Advisory Board Member

16 years in Enterprise IT

ISPA Vice President

Enterprise Architect working with Microsoft‟s largest

customers deploying SharePoint Server.

Works with SharePoint Product Group on 2010 Readiness

Author for MSDN & TechNet

Agenda

Debunking Common SharePoint

Farm Misconceptions Topology

Service Applications

Authentication

Global Deployments

Agile Farms

Scalability

Software Boundaries

FARM TOPOLOGIES

Farm Topologies (Roles)

“Web Front End” (WFE) Terminology hangover from previous version(s)!!

SPF Web Application Service

Here to stay (unfortunately!)

Functional Decomposition of: – Managed Metadata

– Document Conversions

– Content Deployment

– etc

– SPF (Help) Search

– Search Crawl & Search Query

– Excel Services

– Visio Services

– etc

Farm Topologies

“No Topology Restrictions” No enforced restrictions

Plenty of real world restrictions, for example

– Number of “WFE”s

– Number of Web Applications

– Topology Models remain appropriate

“Load balancing” of: Search Query Servers

Excel Calculation Services

etc

Farm Topologies (Search)

“Make the Crawl Server a „Crawl Front End‟”

Not always a smart idea!

Dedicated Crawl Front Ends are a good idea

Indexer resources can easily become saturated

“Always host Search Query on the WFEs”

Each WFE == propagated indexes

Depends on usage patterns

SERVICE APPLICATIONS

SharePoint 2010

Service Applications

“...are hosted by the SharePoint Web Services IIS

Web Site”

“...are deployed on an Application Server”

“...are WCF Services”

“...provide scalability and load balancing”

“...avoid Authentication Delegation configuration”

“...make Inter-Farm Services a snap”

“Service Application Example”

AUTHENTICATION

Claims Based Identity

“...means Kerberos is dead”

“..solves identity delegation problems”

“…provides single sign on”

Authentication

“One DC for every four WFEs” Old wives tale, from Exchange!

It depends upon your authentication scenario

Placement of DCs is far more important

GLOBAL DEPLOYMENTS &

HIGH AVAILABILITY

Global Deployments

“SharePoint can‟t do geo-distribution” Plenty of options

Consider carefully why you may need them

SharePoint Online

“SharePoint doesn‟t work over the WAN” A slow WAN link problem is a slow WAN link

problem!

Not a SharePoint problem

High Availability

“Web Gardens give you better performance” Don‟t use them (ever!)

BLOB Cache & other managed resources

“A single Farm can host 100s of Web Apps” ~20 Web Applications per Farm is reasonable

SharePoint loves RAM

Request Routing or DNS increases operational service burden

considerably

High Availability

“Web Apps can be deployed to

specific servers in a Farm” Request Routing or DNS increases

operational service burden considerably

There is nothing wrong with multiple farms

Server Groups is a logical concept not a

feature

AGILE FARMS

Your Farm Topology is NOT done!

SharePoint Deployments need to be agile

Your day one topology...

May not be suitable in the future

Adoption patterns

Feature implementation

Usage patterns

Plan for an agile farm

Assume your topology will change over lifespan

Seriously consider virtualisation

Agile Farms

Consider future versions

We aren't done yet

Operations Management

Patching, Reporting etc

Don‟t get stuck with a single Farm

The “hidden cost” of SharePoint

Anti-Virus, Backup & Restore, Systems

Management, Usage Anaylsis

SCALABILITY

“SharePoint can’t scale”

average daily load throughput of:

~5 million TIFF images

~1.9 million Microsoft Office documents.

40+ million content items were loaded into SharePoint

in only 13 days

Average content database size of:

200.65 GB for Divisional Site Collections

137.60 GB for departmental site collections

539 GB for the search database

Over 5TB content storage with capacity for double

“SharePoint can’t scale”

“SharePoint can’t scale”

technet.microsoft.com/en-us/library/cc262067.aspx

SHAREPOINT “MAGIC

NUMBERS”

SharePoint “Magic Numbers”

“How many XXXX can I have in my

SharePoint?”

Plan for Software Boundaries

(TechNet) technet.microsoft.com/en-us/library/cc262787.aspx (2007)

www.microsoft.com/downloads/details.aspx?displaylang=en&F

amilyID=66438e41-5733-448a-bd76-a8052b394fe2 (2010)

SharePoint “Magic Numbers”

There are only guidelines for acceptable

performance

Such guidelines are based upon test scenarios – 1 thru 1 Database Server

– 1 thru 8 Web Servers • Team Sites (55%), Doc Workspace (20%), Meeting Workspace (10%), Blog (10%), Wiki

(5%)

– Other scenarios coming soon

– Often refined based on customer deployments

Logical Architecture "Magic

Numbers"

There are NO magic numbers!

Successful Solutions Architecture is basically

two things:

Compromise

Reduction of Complexity

Evaluate solution holistically ensuring adequate compromises.

Test and monitor as you build and deploy your solution.

Re-design the solution to ensure that you do not exceed capacity

guidelines.

Test, test, test!

Thank you for attending!

Patrick, we miss you