Sharepoint 2010: Practical Architecture from the Field


Published on

Presentation from Microsoft Days 2011 (Sofia, Bulgaria). It covers the main topics during Sharepoint 2010 Architecture planning process as well as some pain points from the field.

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

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

No notes for slide
  • Boundaries are absolute limits that cannot be exceeded by design. It is important to understand these limits to ensure that you do not make incorrect assumptions when you design your farm.An example of a boundary is the 2 GB document size limit; you cannot configure SharePoint Server to store documents that are larger than 2 GB. This is a built-in absolute value, and cannot be exceeded by design. Thresholds are those that have a default value that cannot be exceeded unless the value is modified. Thresholds can, in certain circumstances, be exceeded to accommodate variances in your farm design, but it is important to understand that doing so may impact the performance of the farm as well as the effective value of other limits.The default value of certain thresholds can only be exceeded up to an absolute maximum value. A good example is the document size limit. By default, the document size limit is set to 50MB, but can be changed to a maximum value of 2 GB. Supported limits define the tested value for a given parameter. The default values for these limits were defined by testing, and represent the known limitations of the product. Exceeding supported limits may cause unexpected results, significant performance degradation, or other detrimental effects. Some supported limits are configurable parameters that are set by default to the recommended value, while others relate to parameters that are not represented by a configurable value.An example of a supported limit is the number of site collections per Web application. The supported limit is 500,000, which is the largest number of site collections per Web application that met performance benchmarks during testing. It is important to note that many of the limit values provided in this document represent a point in a curve that describes an increasing resource load and concomitant performance degradation as the value increases. Therefore, exceeding certain limits, such as the number of site collections per Web application, may only result in a fractional decrease in farm performance. However, in most cases, operating at or near an established limit is not a best practice, as acceptable performance and reliability targets are best achieved when a farm’s design provides for a reasonable balance of limits values.Thresholds and supported limits guidelines are determined by performance. In other words, you can exceed the default values of the limits, but as you increase the limit value, farm performance and the effective value of other limits may be affected. Many limits in SharePoint Server can be changed, but it is important to understand how changing a given limit affects other parts of the farm.
  • Sharepoint 2010: Practical Architecture from the Field

    1. 1. Sharepoint 2010: Practical Architecture from the Field<br />Tihomir Ignatov<br />Senior Consultant<br />Microsoft Corporation<br />
    2. 2. Session Objective(s): <br />Recognize the importance of having a detailed understanding of the different SharePoint deployment models and options<br />Understand the implications of the different options, and the ramifications and consequences of each<br />Focus on choosing the appropriate option for our customers based on their business and technical requirements<br />Take away(s):<br />Truly successful architecture design for SharePoint requires both broad and deep technology skills, essentially requiring an understanding of both IT Pro and Development aspects<br />Session Objectives and Takeaways<br />
    3. 3. Architecture in Sharepoint Deployments<br />Deployment Architecture<br />Network Architecture<br />Enterprise architecture<br />Server architecture<br />Permission architecture<br />Cloud architecture<br />Infrastructure architecture<br />Deployment Architecture<br />Software Architecture<br />Data architecture<br />Information architecture<br />Business architecture<br />
    4. 4. To build application that satisfies the business and IT requirements<br />Choosing appropriate technical solution based on the requirement and the maturity of the team involved<br />Sharepoint Architecture – What is it for?<br />
    5. 5. Architecture is Making ideas real<br />“Make everything as simple as possible, but not simpler.”<br />-Albert Einstein<br />
    6. 6. Best practices vs. real world<br />Supportability!<br />Sharepoint 2010 boundaries and limits<br />Performance<br />Capacity (plan and maintain)<br />Client Machines<br />High Availability and Scalability<br />Network Infrastructure<br />Deployment of customizations<br />Support and Maintenance<br />What to consider?<br />
    7. 7. Always use best practices (BP) when is possible<br />Adapt your design to the business requirements<br />Do not hesitate to jump over the BP if is reasonable, but leave a track why (document it)<br />Always weigh out the business requirements against feature TCO (complexity, time, resources, price, etc.)<br />Say “NO” to your client, when the feature is expensive and low business impact<br />Best Practices vs. Real World<br />
    8. 8. Supportability<br />Use only SUPPORTED scenarios for customization and configuration<br />Do not use Quick & Dirty approach for production<br />What is supported?<br />Ask for supportability!<br />
    9. 9. Boundaries are absolute limits that cannot be exceeded by design.<br />Thresholds are those that have a default value that cannot be exceeded unless the value is modified. <br />Supported limits define the tested value for a given parameter. <br />Limits<br />Thresholds and supported limits guidelines are determined by performance. <br />
    10. 10. Some Important Limits<br />Software boundaries and limits at TechNet<br />
    11. 11. Capacity is directly affected by scalability<br />If your solution plans exceed the recommended guidelines <br />Evaluate the solution to ensure that compensations are made in other areas.<br />Flag these areas for testing and monitoring as you build your deployment.<br />Redesign or partition the solution to ensure that you do not exceed capacity guidelines.<br />Take Into Account…<br />
    12. 12. How to design the solution (Sub Sites vs. Site Collections vs. Web Applications)<br />Which SA to provision<br />Do not use the Farm Configuration Wizard<br />Important Decisions<br />
    13. 13. “Some” resources in Technet…<br />Consider the limits!<br />Storage and SQL capacity planning<br />For content databases<br />For Service Applications<br />Always test storage performance with SQLIO tool<br />Make meetings with storage administrators <br />Capacity Planning<br />My capacity planning tool:<br />
    14. 14. Browser and version<br />MS Office version<br />Client PCs – HW & SW configuration, load, other applications<br />Monitor and test page rendering performance on regular PC (not development) <br />Client Compatibilities<br />
    15. 15. Is the Sharepoint a business critical application?<br />Try to define SLA and down time – cost, operations, reliability <br />From scalability and capacity to availability<br />Database availability strategies – clustering or mirroring?<br />Service Applications redundancy strategies<br />SA that store data outside a database <br />SA that store data in databases<br />Search Service Application redundancy<br />High Availability<br />
    16. 16. Scale up or scale out?<br />When to scale?<br />What to scale?<br />Scalability<br />
    17. 17. Understand the connectivity between Data center and branches<br />Mobile views<br />Office Web Apps<br />Office 2010 Document Cache and the MS-FSSHTTP protocol<br />Outlook 2010<br />Sharepoint Workspace 2010<br />BranchCache with Windows 7 and Windows Server 2008 R2<br />The connectivity<br />
    18. 18. Consider OOB Backup/Restore tools<br />SQL backup for content<br />MS DPM 2010 and 3rd party tools<br />Disaster Recovery scenarios<br />Backup and Recovery<br />
    19. 19. Customizations and content<br />Sharepoint deployment framework<br />Logging and monitoring<br />Exception handling<br />Development<br />
    20. 20. <ul><li>SharePoint designer increases flexibility, but if misused, can have direct impact on versioning model</li></ul>Hybrid models<br />SPD allowed for site customizations, but not for page layouts or master pages<br />SPD allowed for team sites, but not in corporate communicational intranet<br />To SPD or not SPD?<br />
    21. 21. What is this?<br />MS Online considerations<br />BPOS-D – limitations and releases<br />Office 365 SharePoint deployment is in single site collection (sandbox)<br />Sharepoint Online<br />
    22. 22. It’s all about governance<br />Define the development process<br />Define the quality assurance process in the individual project and in the full deployment<br />Define the ground rules of the deployment<br />Define the models to administer and manage the deployment<br />Application Life Cycle Management (ALM)<br />Software Development Life Cycle (SDLC)<br />Software Quality Lifecycle<br />Business Continuity Management (BCM)<br />Portal Life Cycle Management<br />Not just ALM or BCM, it’s the entire process for the lifecycle of the deployment...<br />
    23. 23. My blog:<br />Sharepoint User Group Bulgaria:<br />E-mail:<br />Contact me<br />
    24. 24. Q & A<br />