Practical SharePoint 2010 Architecture Planning
•Download as PPTX, PDF•
2 likes•1,940 views
Practical SharePoint 2010 Architecture Planning
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Practical SharePoint 2010 Architecture Planning
Similar to Practical SharePoint 2010 Architecture Planning (20)
More from Chakkaradeep Chandran
More from Chakkaradeep Chandran (14)
Recently uploaded
Recently uploaded (20)
Practical SharePoint 2010 Architecture Planning
- 1. SharePoint Site http://www.sharepointconference.co.nz search username Site Actions Browse Page Parent > Parent > Current Page Page Title Current Page Page One Page Two This Site: site search Libraries Site Pages Shared Documents Drop Off Library Custom library Practical SharePoint 2010 Architecture Planning Chakkaradeep (Chaks) Chandran @chakkaradeep Consultant, Microsoft Consulting Services www.chakkaradeep.com chaksc@microsoft.com Microsoft New Zealand
- 2. Session Agenda • What we will cover – Server Architecture – Server Topologies – Performance and Capacity Planning – Software Boundaries and Limits – QUIZ! – Search Topology • No Demos • What we will not cover – Information Architecture Planning – Backup and Recovery Plans – High Availability – Disaster Recovery – Search Planning
- 3. Audience Poll • SharePoint Administrators ? • SharePoint Developers ? • SharePoint End Users ? • IT Administrators ?
- 4. Overall Design Goals • Use minimum number of server farms • Build a topology that suits our requirements • Build a topology that caters for performance, maintainability, reliability etc., • Creating a framework that can scale out
- 5. Architecture Components Web Front End Database Servers Servers Application Servers Service Applications SharePoint Services High Availability 29/03/2012 1:30 p.m. - 2:30 p.m. Disaster SharePoint 2010 – Planning High Recovery Availability for SharePoint 2010 Farms 29/03/2012 2:45 p.m. - 3:45 p.m. A Closer Look at SQL and SharePoint: Tips and tricks from the field
- 6. Where do we start? • Gather Requirements • Requirements drive everything we do • What we are really doing “Build and deploy a solution that satisfies the business and IT requirements”
- 7. Service Applications Application Tier design decisions will be based on Service Applications • Access Services • Business Data Connectivity service • Excel Services Application • Managed Metadata service • PerformancePoint Service Application • Search Service Application • Secure Store Service • State service • Usage and Health Data Collection service • User Profile service • Visio Graphics Service • Web Analytics service • Word Automation Services • Microsoft SharePoint Foundation Subscription Settings Service
- 8. Real World Example “I want my company Intranet powered by SharePoint. I see my teams are struggling to work together. I heard SharePoint can solve that problem too.”
- 9. Different Workloads Intranet My Sites User Profiles Project Team Access Services Sites Team Collaboration Sites Workflows Search Document Management Excel Services System
- 10. Service Applications Application Tier design decisions will be based on Service Applications • Access Services • Business Data Connectivity service • Excel Services Application • Managed Metadata service • PerformancePoint Service Application • Search Service Application • Secure Store Service • State service • Usage and Health Data Collection service • User Profile service • Visio Graphics Service • Web Analytics service • Word Automation Services • Microsoft SharePoint Foundation Subscription Settings Service
- 11. SharePoint Topology Options Single Server with SQL Server • “All In One” Box • All Roles on one server – SQL Server – Web Front End – Application Server • Easy to deploy • Best suited for developer environments or pilot • What's wrong? – Installs SQL Express – No High Availability – Heavy resource usage – Single point of failure (SPOF) “All In One” Box
- 12. SharePoint Topology Options Multiple Servers – Option 1 • Dedicated SQL Server • All SharePoint Roles on one Server – Web Front End – Application Server • Good option to start • What’s wrong: – No High Availability – We still have SPOF – Heavy resource usage • SharePoint 2010 Server (AND/OR) Database Mirroring Failover Clustering – No redundancy Log Shipping
- 13. SharePoint Topology Options Multiple Servers – Option 2 • Dedicated SQL Server • Dedicated Web Front End Server • Dedicated Application Server • What’s wrong: – No redundancy (AND/OR) Log Shipping Database Mirroring Failover Clustering
- 14. SharePoint Topology Options Multiple Servers – Option 2 Extended / WFE (AND/OR) Database Mirroring Failover Clustering Log Shipping
- 15. Bit more on service applications... Service Application Limiting Factor Access Services • CPU on the App Server Business Data Connectivity • CPU and memory on the WFE • CPU on the App Server that require calls to Secure Store Excel Services • CPU on the Excel Services tier (app server) • CPU on the WFE Workflow Performance • Depends on Queue Settings: - Key thing to note is Workflow Timer • Workflow Postpone Threshold Service runs on WFEs • Workflow Event Delivery Batch Size • Workflow Timer Job Frequency • You can increase workflow throughput by scaling out to up to four WFEs. More Info - http://technet.microsoft.com/en-us/library/ff608068.aspx
- 16. SharePoint Topology Options Multiple Servers – Option 3 NLB (AND/OR) Database Mirroring Failover Clustering Log Shipping
- 17. Software Boundaries and Limits Limit Maximum Value Content Database (x) per Web Application [500 – 300 – 100] Site collection (x) per Web application [50,000 – 150,000 – 250,000] Site collections per content database (x) recommended 5000 Maximum [3000 – 1500 – 2000] Application Pools (x) per Web Server [5 – 10 – 3] Content Database (general scenarios) (x in GB/TB) per content database [100GB – 200GB – 1TB] Content Database (document archive scenario) (x in GB/TB) per content database [500GB – 4TB – 3TB] More Info - http://technet.microsoft.com/en-us/library/cc262787.aspx
- 18. What about Disaster Recovery? Key Metrics • Recovery Time Objective (RTO) – The maximum time a data recovery process will take • Recovery Point Objective (RPO) – The maximum amount of time between the last available backup and any potential failure point. • Service Level Agreements (SLA) Business Continuity Planning - http://technet.microsoft.com/en-us/library/cc287972.aspx
- 19. An Update From The Business Team • We have 10 departments • Documents around 10GB per department • This will grow 2% to 3% every year • Search is very critical • We have HR department who want immediate search results
- 20. Search Architecture Example RAM Disk Space Disk Space RAM INDEX PARTITION Query Component 1 Query Component 1m Search Admin Crawler Crawler RAM Use dedicated Crawl Db Crawl Db server instead Enterprise Search Planning - http://technet.microsoft.com/en-us/library/cc263400.aspx
- 21. Scaling out Search Architecture • Add Query Components – To increase query throughput – To add failover query components to support redundancy • Add Index Partitions – To support larger number of items • Add Property Databases – To eliminate bottlenecks – To support more metadata to index • Add Crawl Components – To increase crawl throughput – To add failover crawl components
- 22. Software Boundaries and Limits Limit Maximum Value SharePoint search service applications (x) per farm [20 – 30 – 10] Crawl databases (x) crawl databases per search service application [30 – 10 – 15] Crawl components (x) per search service application [14 – 15 – 16] Query components (x) per search application 64 total crawl components per server [65 – 128 – 120] Index partitions (x) per search service application 128 in total [22 – 20 – 64] Property databases (x) per search service application 128 in total [12 – 10 – 14] More Info - http://technet.microsoft.com/en-us/library/cc262787.aspx
- 23. Real World Example “I want my company Intranet powered by SharePoint. I see my teams are struggling to work together. I heard SharePoint can solve that problem too.” Thank You | www.chakkaradeep.com
- 24. SharePoint 2010 Architecture Example RAM Disk Space Disk Space RAM INDEX PARTITION Query Component 1 Query Component 1m Search Admin Crawler Crawler RAM Use dedicated Crawl Db Crawl Db server instead Enterprise Search Planning - http://technet.microsoft.com/en-us/library/cc263400.aspx
- 25. Gold Sponsors Silver Sponsors Technology Bronze Sponsors Sponsor Media Sponsors
Editor's Notes
- Opening slide please include
- www.chakkaradeep.com
- HA and DR can impact the architecture.
- Workflow Postpone Threshold (Set-SPFarmConfig –WorkflowPostponeThreshold <integer>)The maximum number of workflows that can execute against a single content database before additional requests and operations are queued. Queued workflows show a status of Starting. This is a farm-wide setting that has a default value of 15. This represents the number of workflow operations that are being processed at a time, not the maximum number of workflows that can be in progress. As workflow operations are completed, successive operations will be able to run.Workflow Event Delivery Batch Size (Set-SPWorkflow –BatchSize <integer>)The Workflow Timer service is an exception to the postpone threshold limit and will retrieve batches of items from the queue and execute them one at a time. These batches can be larger than the postpone threshold. The number of work items that the service receives per run is set by using the BatchSize property. The BatchSize property can be set one time per service instance. The default value is 100. When running on application servers that are not configured to be front-end servers, the Workflow Timer service requires workflow configuration settings in Web.config to be set in the configuration database. This must be done through a script that calls UpdateWorkflowConfigurationSettings() on the SPWebApplication object, which will copy the Web.config settings from a front-end server.Workflow Timer Job Frequency (Set-SPTimerJob job-workflow –schedule <string>)The frequency with which the Workflow Timer service runs can be adjusted through timer job settings. By default, the service is set to run every five minutes. This means that there can be a five-minute delay before the work items at the top of the queue are processed.