Large Scale SharePoint SQL Deployments


Published on

Large Scale SQL deployments for SharePoint.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Pre-construct and pre-size your content databases. Once the content database size has been specified, it is recommended that the database be created using a script that appropriately generates the empty database. Note that the “Autogrow” feature should be left on to prevent any future issues.Place the content database file or files on RAID 5 or RAID 10 logical units. RAID 10 is the best choice when cost is not a concern. RAID 5 will be sufficient and will save on costs, since content databases tend to be more read intensive than write intensive.For a large-scale document management solution, with a multi-core computer running SQL Server, the primary file group for the content database could potentially consist of a data file for each CPU core present in SQL Server. If possible, move each data file to separate logical units consisting of unique physical disk spindles.Database storage for content items will be between 1.2 and 1.5 time the raw file size when stored in SharePoint.
  • If you would like to host your demo on the Virtual Server, please use the myVPC demo slide, not this slide.
  • Large Scale SharePoint SQL Deployments

    1. 1.
    2. 2. Considerations for large-scale SharePoint deployments on SQL Server<br />Name: Joel Oleson<br />Title: Sr. Tech Prod Mgr<br />Company: Quest Software<br />
    3. 3.
    4. 4. Audience Poll<br />New to SharePoint?<br />SQL Admins?<br />Large-scale Implementation (&gt;1TB) experience?<br />Scalability or performance issues in SharePoint deployments?<br />
    5. 5. Session Overview <br />Lightweight<br />Understanding SharePoint databases<br />SQL Performance<br />SQL Server 2008 with SharePoint<br />Heavyweight<br />Architectural Design Considerations<br />Real-world scenarios<br />Business Requirements<br />Logical and Physical Architecture<br />Architectural Design Statistical Results<br />Appendix: DB Sizes, Content Distribution…<br />
    6. 6. =<br />Lightweight<br />
    7. 7. Real World Examples<br />Information based on real-world, large-scale SharePoint Implementations.<br />Large software company (Microsoft)<br />Intranet Portal for 120K users<br />Global Enterprise Collaboration Solution (~20TB)<br />Scalable Hosting Solution (SharePoint Online)<br />Large automotive manufacturer<br />Loan Origination Application / Document Repository<br />~50 Million content items (~6 TB)<br />
    8. 8. Understanding the SharePoint Databases<br />
    9. 9. Disk I/O Demand<br />Most Demand<br />Medium Demand<br />Low Demand<br />*Content..<br />Search<br />Config<br />Temp<br />Model<br />+SSP<br />Master<br />Tlogs<br />* Except during backup and Indexing + Except during Profile Import<br />
    10. 10. Top Performance Killers<br />Indexing/Crawling<br />Backup (SQL & Tape)<br />Profile Import<br />Misc Timer Jobs – User Sync for large #s of Users<br />STSADM Backup/Restore<br />Large List Operations<br />Heavy User Operation List Import/Write<br />
    11. 11. Content Db<br />
    12. 12. Config<br />
    13. 13. SQL Server 2008 with Windows Server 2008<br />Transactional Performance with SQL Server 2008 Dramatically outperformed SQL 2005 on Win 2003.<br />Compressed backup in the box<br />Support for SQL External Blob Storage<br />Increased resiliency<br />Transparent Encryption<br />See Performance Gains at<br />
    14. 14. =<br />heavyweight<br />
    15. 15. Architectural Design Considerations<br />Database Volumes<br />Separate database volumes into unique LUN’s consisting of unique physical disk spindles.<br />In a heavily read-oriented internet (portal) site, prioritize data over logs.<br />Separate out Search database transaction log from content database transaction logs.<br />
    16. 16. Architectural Design Considerations<br />SQL TempDB Data Files<br />Optimal TempDB data file sizes can be calculated using the following formula:<br />[MAX DB SIZE (KB)] X [.25] / [# CORES] = DATA FILE SIZE (KB)<br />Calculation result (starting size) should be roughly equal to 25% of the largest content or search DB.<br />Use RAID 10; separate LUN from other database objects (content, search, etc…).<br />“Autogrow” feature set to a fixed amount; if auto grow occurs, permanently increase TempDB size.<br />TempDB Log file separated to unique LUN.<br />
    17. 17. Architectural Design Considerations<br />Content Databases<br />100 content databases per Web application<br />100GB per content database<br />CAUTION: DB locking issues reported in collaborative DM scenarios above 100GB<br />Need to ensure that you understand the issues based on number of users, usage profiles, etc…<br />Service Level Agreement (SLA) requirements for backup and restore will also have an impact on this decision.<br />
    18. 18. Architectural Design Considerations<br />Content Databases - Continued<br />Pre-construct and pre-size<br />Use RAID 5 or RAID 10 logical units<br />RAID 10 is the best choice when cost is not a concern. <br />RAID 5 will be sufficient and will save on costs, since content databases tend to be more read intensive than write intensive.<br />Multi-core computer running SQL Server<br />Primary file group could consist of a data file for each CPU core present in SQL Server. <br />
    19. 19. Architectural Design Considerations<br />Database Maintenance<br />SQL Server SP2 is needed if using the DB maintenance wizard (KB930887).<br />Plan regular defrag of databases<br />Performance - Average Disk Queue Length<br />Single Digit values are optimal.<br />Occasional double-digit values aren’t a large concern.<br />Sustained triple-digit values require attention.<br />
    20. 20. Architectural Design Considerations<br />Performance<br />The recommended practice for separating the database volume types for the transaction log files to unique LUN’s follows.<br />Content Database Log Files.<br />Search Database Log Files.<br />Consider filegroups for search database<br />
    21. 21. Architectural Design Considerations<br />Topology<br />A single list should not have more than 2,000 items per list container.<br />A container represents the root of the list, as well as any folders within the list; a folder is a container because other list items are stored within it.<br />Whitepaper: Working with large lists in Office SharePoint Server 2007 (Steve Peschka)<br /><br />Disk Drive Speed<br />15K RPM recommended.<br />IIS Application Pools<br />Ensure “Max Used Memory” setting utilizes all the available RAM in your WFE’s.<br />
    22. 22. Architectural Design Considerations<br />STSADM Command-line Tool and CreateSiteInNewDBOperation<br />Gary Lapoint STSADM Extensions for Site Collection DB maintenance<br /> tools for archive & delete capture<br />
    23. 23. Large Scale Manufacture<br />
    24. 24. Real-world Scenarios<br />Automotive Mfgr. Business Requirements (Phase I)<br />Loan Origination Application built on Office SharePoint Server 2007<br />Ability to manage10.5 million images.<br />System performance with a “normal” input load defined as receipt of 27,000 images per business day = 10 hours.<br />Simulate user load to represent 200 users for search, view & update with 2x peak<br />
    25. 25. Real-world Scenarios<br />Data Load Process (Phase I)<br />Used KnowledgeLake Document Release Engine<br />Loaded 9.17 documents/second per server <br />Employs a high-volume, storage-based folder architecture within SharePoint to ensure UI responsiveness.<br />Executed on 4 servers. Using this application, we were able to achieve:<br />An average document load throughput of 36.6 documents per second!<br />An average daily input of 3.17 million documents!<br />10.5 million documents with only 28% utilization!<br />
    26. 26. Real-world Scenarios<br />Data Load Process (Phase II)<br />15 million documents consisting of Word (.docx), Excel (.xlsx), PowerPoint (.pptx) and Adobe PDF.<br />Five Web Front-Ends were used for the load process.<br />Peak Load Rate:<br />24.3 docs per second/2.1 million documents per day.<br />Average Load Rate:<br />~1.9 million documents per day.<br />Load Time:<br />8 days.NOTE: Load rates included automation process that created the PDF files.<br />
    27. 27. What does the logical architecture look like?!<br />
    28. 28. What does the physical architecture look like?!<br />Scale OUT…<br />Scale UP…<br />
    29. 29. What does the site topology look like?!<br />Phase I<br />17 Divisional Site Collections / DB’s<br />Phase II<br />10 Departmental Site Collections / DB’s<br />
    30. 30. What does the storage architecture look like?<br />
    31. 31. Database SizesPhase I<br />
    32. 32. Architectural Design Statistical ResultsPhase I<br />Designed Once / Built Once<br />No architecture OR configuration changes were required after the initial build was completed.<br />10.5+ million documents loaded into the system in approximately 60 hours!<br />Full Crawl indexed 10 Million items in 32 hours!<br />Average content database size for divisional breakouts was 60GB<br />
    33. 33. Architectural Design Statistical ResultsPhase II<br />Search database size was 539GB.<br />Lesson Learned: Large search database caused disk I/O contention; break this out into multiple data file allocations matching the number of core processors on SQL Server, and spread them over unique LUN’s.<br />Total Index size was 162GB!<br />Average Content database size for Divisional breakouts was 200.65GB!<br />Average Content database size for Departmental breakouts was 137.60GB!<br />
    34. 34. Large Scale Pharma<br />
    35. 35. Real-world Scenarios<br />Pharmaceutical Business Requirements<br />Collaboration Portal built on Office SharePoint Server 2007<br />Validate ~40TB of content storage.<br />Identify performance characteristics and provide guidance around content database sizing<br />FAST search integration<br />
    36. 36. Real-world Scenarios<br />Data Load Process<br />71,524,357 documents loaded across two SharePoint Farms 10.92 days!<br />Content was spread across the farms into 165 unique content databases.<br />6,240 Site Collections, each containing 10 sub-sites for a total of 62,400 sites.<br />Database sizes were pre-configured to vary in size from 100GB to 350GB to determine performance and/or SLA impacts.<br />
    37. 37. What does the logical architecture look like?!<br />
    38. 38. What does the physical architecture look like?!<br />
    39. 39. What does the site topology look like?!<br />165 Content DB’s<br />6,240 Site Collections<br />10 Sub-Sites in each collection:<br />62,400 Sites!<br />
    40. 40. What does the storage architecture look like?<br />
    41. 41. Architectural Design Statistical ResultsConclusion<br />User Loads<br />Stress tests included 2 - 3,000 concurrent users.<br />Based on the 10% rule, testing completed equated to an environment representing 300,000 users!<br />RAWnumber of RPS during peak times is 1,469 at Pharma.<br />773 RPS, which equates to 346.59 ACTUAL RPS!<br />FAST Search Integration<br />Successfully integrated FAST search capabilities, indexed content corpus and served search results as expected.<br />
    42. 42. Large-Scale Case Study Available<br />SharePoint Scalability and Performance Whitepaper<br />Contains majority of content you will see here, along with test results you won’t see here.<br />TechNet topic:<br />Word 2007 format:<br />Word 2000-2003 format:<br />PDF format:<br />
    43. 43. question & answer<br />
    44. 44. Appendix<br />
    45. 45. Database SizesMPSC/Nissan Phase I<br />
    46. 46. Database SizesMPSC/Nissan Phase II<br />
    47. 47. Performance of Components Over Time<br />MPSC/Nissan Phase I<br />14 individual performance tests were run to simulate various load scenarios.<br />
    48. 48. How do we pull all this together?!<br />PharmaContent Database Distribution<br />Substitute “F1” with SQL Server number to generate unique DB’s<br />Farm 1: 2 SQL<br />Farm 2: 1 SQL<br />165 Content Databases!<br />
    49. 49. How do we pull all this together?!<br />PharmaData Load Statistics<br />
    50. 50. Architectural Design Statistical ResultsTesting Results – 300GB Content Databases<br />
    51. 51. Architectural Design Statistical ResultsTesting Results – 350GB Content Databases<br />
    52. 52. Architectural Design Statistical ResultsTesting Results – 250GB Content Databases<br />
    53. 53. Architectural Design Statistical ResultsTesting Results – 150GB Content Databases<br />
    54. 54. Required Slide<br />© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.<br />The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.<br />