Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Spring 2009 Connections Conference Template


Published on

Published in: Technology, News & Politics
  • Be the first to comment

  • Be the first to like this

Spring 2009 Connections Conference Template

  1. 1. Scaling SharePoint 2010 Topologies for Your Organization Spencer Harbar Enterprise Architect MSC12
  2. 2. About Spencer • | | @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
  3. 3. Agenda What’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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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.
  8. 8. 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
  9. 9. 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
  10. 10. 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!
  11. 11. Scaling Services – Step One Scale 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)
  12. 12. Scaling Services – Step Two Multiple 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
  13. 13. Three Sample Topologies • Small Organisation (Woodgrove) • Medium Enterprise (Fabrikam) • Large, Distributed Enterprise (Contoso) These are simple examples, not prescriptive guidance or “best practices”
  14. 14. 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”
  15. 15. Woodgrove – Logical Architecture IIS Web Site—“SharePoint Web Services” Application pool Access Excel Managed User Profile Services Calculation Metadata Services Business Data Secure Store Search Connectivity Service Application pool Application pool Web application—Published Intranet Content Web application—My Sites Web application—Team Sites http://team Http://woodgrove/ http://my http://my/personal/<user> HR Facilities Purchasing Team 1 Team 2 Team 3
  16. 16. Woodgrove – Physical Topology Web+App Servers SQL Server
  17. 17. 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
  18. 18. 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”
  19. 19. Fabrikam – Logical Architecture IIS Web Site—“SharePoint Web Services” Application pool Managed Excel User Profile Managed Excel Access Metadata Calculation Metadata Calculation Services Services Services Business Data Secure Store Search Business Data Connectivity Service Connectivity Custom group Default group Custom group Application pool Application pool Application pool Web application—HRWeb Web application—Company Web Web application—My Sites Web application—Finance Web http://hrweb http://fabrikam http://finance http://my http://my/personal/<user> Division 1 Division 2 Division 3
  20. 20. Fabrikam – Physical Topology Query Index Excel Services Excel Services Central Admin User Profiles User Profiles Metadata Metadata
  21. 21. 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
  22. 22. 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
  23. 23. Contoso - Logical Architecture Enterprise services farm IIS Web Site—“SharePoint Web Services” Application pool User Profile Managed Search Business Data Secure Store Metadata Connectivity Service Published content farm Collaboration farm My Site farm Departmental farm IIS Web Site—“SharePoint Web Services” IIS Web Site—“SharePoint Web Services” Application pool Application pool Default group Default group Access Excel Usage and InfoPath Services Services Health Data Managed Usage and Excel Collection Metadata Health Data Services Application pool Default group Application pool Collection Web application—Published Intranet Content Web application—My Sites Default group PowerPoint Word Visio Word Viewing Graphics Automation PowerPoint Word Visio Service Services Viewing Graphics http://Fabrikam http://my Service http://my/personal/<user> HR Facilities Purchasing Application pool Application pool Web application—My Sites Web application—Team Sites Web application—Specialized Department Sites No Services No Services http://team http://my http://department http://my/personal/<user> Team 1 Team 2 Team 3 Mix of local and remote services Deployment of services for a specialized department farm
  24. 24. Contoso - Physical Topology My Site Published Content Collaboration Departmental Farm Web Servers Web Servers Web Servers Web Servers Index Usage & Health Usage & Health Usage & Health Index Index Usage & Health Usage & Health Usage & Health Usage & Health Usage & Health Usage & Health Usage & Health Usage & Health Index Target Target Target Target Usage Central Admin Central Admin Central Admin Central Admin Central Admin Excel Services SSRS Excel Services SSRS Central Admin Central Admin Excel Services Excel Services WAC PPT Broadcast Excel Services Access Services WAC Access Services WAC Excel Services WAC PTC WAC PPT Broadcast PTC (offline) Access Services Visio Services PPT Broadcast Visio Services PPT Broadcast Access Services Visio Services Visio Services SSRS SSRS 1x2 SQL cluster 1x2 SQL cluster 1x2 SQL cluster 1x2 SQL cluster 1x2 SQL cluster 1x2 SQL cluster Enterprise Services Farm Taxonomy Taxonomy Web Analytics Profile Profile BCS Web Analytics BCS 1x2 SQL cluster 1x2 SQL cluster (Profile, Taxonomy, BCS) (Web Analytics, Usage)
  25. 25. 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
  26. 26. Other Scenarios • Internet Publishing • Multi-tenant Hosting • And many more…
  27. 27. Multi-tenant Hosting Farm
  28. 28. 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
  29. 29. 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
  30. 30. Upgrading Parent->Child Farms Phased hybrid upgrade approach 2007 Parent Farm 2010 Parent Farm 2007 Parent Farm Copy Backup/Restore 2007 2010 2007 Services Services 2007 2010 2007 2010 Web App Web App V3 Child Farm 1 1 2010 Child Farm V3 Child Farm 2 2 2010 Child Farm
  31. 31. 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
  32. 32. 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
  33. 33. Your Feedback is Important Please fill out a session evaluation form drop it off at the conference registration desk. Thank you!