Spring 2009 Connections Conference Template
-
Upload
aamir97 -
Category
Technology
-
view
446 -
download
0
Transcript of Spring 2009 Connections Conference Template
Scaling SharePoint 2010
Topologies
for Your Organization
Spencer HarbarEnterprise Architect
harbar.net
MSC12
About Spencer
• www.harbar.net | [email protected] | @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!