Scaling SharePoint 2010

Topologies

for Your Organization

Spencer HarbarEnterprise Architect

harbar.net

MSC12

About Spencer

• www.harbar.net | spence@harbar.net | @harbars

● Microsoft Certified Master | SharePoint 2007

● Microsoft Certified Master | SharePoint Instructor & Author

● Most Valuable Professional | SharePoint Server

● SharePoint Patterns & Practices Advisory Board Member

● 15 years in Enterprise IT

● ISPA Board Member

● Enterprise Architect working with Microsoft’s largest

customers deploying SharePoint Server.

● Works with SharePoint Product Group on 2010 Readiness

● Author for MSDN on Excel Services, ECM

● Author for TechNet on Farm Topologies & Security

AgendaWhat’s this session all about?

• Intended as follow up to MSC33● Understanding the Service Application Architecture of SharePoint 2010

(Rick Taylor)

• Recap of SharePoint 2010 Service Architecture

• Variables that influence Service Application

Topologies

• Designing SharePoint Topologies for 3

canonical cases

• Migrating your MOSS 2007 Topology

Objectives and Takeaways

• Session Objectives

● Understand principles behind designing SharePoint

architectures

● Understand how to accommodate growth in your

deployments

• Key Takeaways

● SharePoint 2010 supports topologies to suit your

organizational needs

● SharePoint 2010 scales further and more flexibly than

ever before

Virtualization

• Mostly Irrelevant to the concepts here

● Design Topology First!

● Sometimes constraints influence design!

• For more information check out

● Virtualization of SharePoint 2010 Farm

Architecture

Michael Noel, Today 15:00 - 16:15

Service Architecture Recap

• Flexible Deployment Model

• Improved Security Model

● Claims Based Authentication/Authorization

● Cross-Farm Communications via Web

Services

• Simplified Administration Model

● Central Administration and PowerShell

Service Architecture Recap

• Service Isolation

● Each Service App uses separate Database

● Optionally can use separate Application Pool

● Support for Multiple Service Applications

• With different App Pools, Accounts & Databases

• Multi-Tenancy

● Some Service Applications can be partitioned

to serve Multiple Tenants.

Choosing an Architecture

• Consider both Logical and Physical

aspects

• Start with a Logical Architecture

● Consolidated versus Distributed

• Build it out to a Physical Architecture

● Low Scale -> Medium -> High Scale

• Scale Out as necessary

Logical Topology Considerations

• Business Needs

● Organisations may need isolation between respective

Services

• Regulatory Restrictions

● Geo-Political

● Regulatory

• Information Architecture

● “Architecture” of Web Sites influence Services

association

● Governance requirements

Physical Considerations

• Scale

● Scale Up / Scale Out needs influence physical

topology

• Link Latency

● Host Services close to Users and Content

• Directory Architecture

● Host Services close to Directory for better

AuthN, Profile Sync, etc

• Budget!

Scaling Services – Step OneScale within the Farm

• Scale Up

• Scale Out on each Tier

● Add Web Front Ends for Content Servers

● Additional Application Servers for compute intensive

services

● Scale SQL for data centric services

• “Affinitize”

● Services on specific Application Servers

● Specific Web Apps to Web Front Ends

(NLB, Request Routing)

Scaling Services – Step TwoMultiple Farms

• Split Services into Separate Farm

● Security Boundary

● Usage / Scale

● Political / Organisational

● Patching Flexibility

• Multiple Service Farms

● Geo-distributed

● High Load Scenarios

● Start with separating out Search

Three Sample Topologies

• Small Organisation (Woodgrove)

• Medium Enterprise (Fabrikam)

• Large, Distributed Enterprise (Contoso)

These are simple examples, not

prescriptive guidance or “best practices”

Woodgrove

• Small-Medium Organization

● Single or few locations

● < 5000 Users

● Mainly uses Collaboration, Search

● 1-3 IT Staff spanning multiple roles

● Need to accommodate multiple “projects”

Woodgrove – Logical Architecture

http://my/personal/<user>

http://my

Application pool

HR

Http://woodgrove/

Application pool

Facilities Purchasing

Team 1

http://team

Team 2 Team 3

Web application—Published Intranet Content Web application—My Sites Web application—Team Sites

Application pool

User ProfileManaged Metadata

SearchSecure Store Service

Access Services

IIS Web Site—“SharePoint Web Services”

Excel Calculation Services

Business Data Connectivity

Woodgrove – Physical Topology

SQL Server

Web+App Servers

Woodgrove – Salient Points

• Single Farm

• Mostly configured with default settings

• Combined App Server/WFE tier

• Managing growth

● New content in Site Collections

● Add additional servers

Fabrikam

• Typical Medium-Large Sized Organisation

● 10k-50k Users

● May use all or some SharePoint workloads

● ~10 IT Staff spanning multiple roles and

solutions

● Limited intra-organizational “seams”

● Need to accommodate multiple “projects”

Fabrikam – Logical Architecture

http://finance

Application pool

Web application—Finance Web

Application pool

Division 1

http://fabrikam

Division 2 Division 3

Web application—Company Web

http://my/personal/<user>

http://my

Web application—My Sites

Application pool

Managed Metadata

Secure Store Service

Default group Custom group

Access Services

Managed Metadata

http://hrweb

Application pool

Web application—HRWeb

Search

Custom group

Excel Calculation Services

Excel Calculation Services

User Profile

IIS Web Site—“SharePoint Web Services”

Business Data Connectivity

Business Data Connectivity

Fabrikam – Physical Topology

Excel Services

Central Admin

User Profiles

Metadata

Query Index

Excel Services

User Profiles

Metadata

Fabrikam – Salient Points

• Single Farm

● Isolated Web Applications

● Multiple Service Applications

● Multiple Proxy Groups

• Distinct Server Roles

• Managing growth

● Adding new Sites, Web Applications

● Scale out through adding WFEs or App Servers

● Consider splitting out Content Farms

Contoso

• Large multinational corporation

● >50k Users

● Geographically distributed

● Dedicated vertical and horizontal IT

departments

● Organizational boundaries

● Uses all or most SharePoint workloads

● Internal hosting with different SLAs

Contoso - Logical Architecture

Enterprise services farm

Application pool

User Profile Managed Metadata

HR

http://Fabrikam

Application pool

Facilities Purchasing

Published content farm

Web application—Published Intranet Content

http://my/personal/<user>

http://my

Application pool

Team 1

http://team

Team 2 Team 3

Collaboration farm

Web application—My Sites Web application—Team Sites

Application pool

Access Services

PowerPoint Word Viewing

Visio Graphics Service

Word Automation Services

Usage and Health Data Collection

InfoPath

Search Secure Store Service

Mix of local and remote services

IIS Web Site—“SharePoint Web Services”

IIS Web Site—“SharePoint Web Services”

Excel Services

Default group

Default group

Business Data Connectivity

No Services

Application pool

My Site farm

Default group

No Services

http://my/personal/<user>

http://my

Web application—My Sites

Application pool

http://department

Departmental farm

Web application—Specialized Department Sites

Application pool

PowerPoint Word Viewing

Visio Graphics Service

Usage and Health Data Collection

Managed Metadata

Default group

Deployment of services for a specialized department farm

IIS Web Site—“SharePoint Web Services”

Excel Services

Contoso - Physical Topology

My Site

ProfileTaxonomy

Web AnalyticsProfile

1x2 SQL cluster

1x2 SQL cluster

Central AdminPPT BroadcastPTC (offline)

Web AnalyticsBCS

Usage

Index Target

Usage & Health

1x2 SQL cluster

TaxonomyBCS

(Profile, Taxonomy, BCS) (Web Analytics, Usage)

Central AdminExcel Services

PTC

Central AdminExcel Services

WAC

Central AdminWAC

PPT Broadcast

Usage & Health Usage & Health

Published Content

1x2 SQL cluster

Index Target

Usage & Health Usage & Health Usage & Health

Collaboration

1x2 SQL cluster

Index Target

Usage & Health

Central AdminExcel Services

Access ServicesVisio Services

SSRS

Central AdminWAC

Usage & Health Usage & Health

Central AdminExcel Services

Access ServicesVisio Services

SSRS

1x2 SQL cluster 1x2 SQL cluster

Enterprise Services Farm

Web Servers Web Servers Web Servers

Departmental Farm

1x2 SQL cluster

Index Target

Usage & Health

Excel ServicesAccess ServicesVisio Services

Usage & Health

SSRSWAC

PPT Broadcast

Excel ServicesAccess ServicesVisio Services

SSRSWAC

PPT Broadcast

Web Servers

Contoso – Salient Points

• Enterprise Services owned and published by Central IT

• Managing Growth

● Additional departments can be incorporated as

• New Site Collections

• New Web Applications in existing Farms

• New Farms

Depending on service agreement

● Scale out through adding Web Front Ends and App Servers

• Geo-distribution through multiple Service Farms

• Disaster Recovery and High Availability considerations

Other Scenarios

• Internet Publishing

• Multi-tenant Hosting

• And many more…

Multi-tenant Hosting Farm

MOSS 2007 -> SharePoint 2010

• MOSS 2007 Farms do not interoperate with

SharePoint 2010 Farms

• Two modes of upgrade

● All-up once upgrade: Upgrade organizations entire

SharePoint infrastructure in a single phase• Pros: Simple

• Cons: Business, technology limitations

● Phased upgrade: Upgrade SharePoint infrastructure

in phases• Bring properties to SharePoint 2010 as

technology/business policies permit

• Pros: Flexible per organizational policies

• Cons: more complex, and harder to manage

Upgrading a MOSS 2007 Farm

• Each Shared Service Provider upgrades into:

● A Search Service Application

● A User Profiles Service Application

● An Excel Service Application

● An App Registry back-compat Service Application

● A new Managed Metadata Service Application

• Web Application Associations are preserved

● A Proxy is created for each Service Application

• New Databases are created as needed

Upgrading Parent->Child FarmsPhased hybrid upgrade approach

2007 Parent Farm

2007Services

2007 Parent Farm Copy

2007Services

2010 Parent Farm

2010Services

V3 Child Farm 1

2007Web App

2010 Child Farm 1

2010Web App

V3 Child Farm 2

2007Web App

2010 Child Farm 2

2010Web App

Backup/Restore

Upgrading Parent->Child Farms

• Create a Mirror of the Parent Farm

• Upgrade the Mirror Farm

• Keep settings on the Original and Mirror Farms

synchronized

• Publish Service Applications from Mirror Farm

• Upgrade a Child Farm

• After the upgrade, point Child Farms to consume the

Services published by the Mirror Farm

• Repeat for each Child Farm

• Once all Child Farms are upgraded,

remove the 2007 Parent Farm

Summary

• SharePoint 2010 Services Architecture

● Supports Topologies to suit your

organizational needs

● Scales further and more flexibly

than ever before

● Supports upgrade from MOSS 2007

Your Feedback is Important

Please fill out a session evaluation form

drop it off at the conference registration

desk.

Thank you!