SharePoint Topology


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

No notes for slide
  • 2003 Definitions: Small - One server running SQL Server 2000 and one server running SharePoint Portal Server 2003 assigned the Web, Search, Job, and Index services. Medium - One or two servers running SharePoint Portal Server 2003 assigned the Web service (more commonly known as front-end Web servers) and running SharePoint Portal Server 2003 assigned the Search, Job, and Index services; and one server running SQL Server 2000. Large - Two to eight servers running SharePoint Portal Server 2003 assigned the Web service (more commonly known as front-end Web servers), two to four servers running SharePoint Portal Server 2003 assigned the Search service, one to four servers running SharePoint Portal Server 2003 assigned the Index service (one of which must be assigned the Job Server role), and any number of servers running SQL Server 2000.
  • Capacity Performance - Optimisation by application profile (Mysites vs Collab) Org – Administrative Boundaries / Operational divisions Funding Sources
  • Usability Nest sites may be hard to navigate Most web parts don’t work cross site collection
  • CapEx: Servers / Infrastructure / Licenses OpEx: Design / Deployment / Administration
  • SQL Complexity: cluster setup, Quorum disk
  • IIS 6.0 32 – 2GB per web application max – will work in most cases. Need multiple web applications to scale on 32 but architecture NO /3GB switch
  • WFE – remember IIS runs 32 OR 64 bit mode. No WoW
  • SharePoint Topology

    1. 1. Geoff Evelyn [email_address]
    2. 2. <ul><li>What is the Microsoft supported definition of: </li></ul><ul><ul><li>Small Farm? </li></ul></ul><ul><ul><li>Medium Farm? </li></ul></ul><ul><ul><li>Large Farm? </li></ul></ul>Forget the old definitions! They do not apply to Microsoft Office SharePoint Server 2007 topologies.
    3. 3. <ul><li>Availability </li></ul><ul><li>Capacity </li></ul><ul><li>Performance </li></ul><ul><li>Organisational requirements </li></ul><ul><li>Differing availability requirements / SLAs </li></ul><ul><li>Regulatory / data segregation requirements </li></ul><ul><li>Functional requirements </li></ul><ul><li>Licensing </li></ul><ul><li>Cost </li></ul>
    4. 4. Increasing complexity and cost
    5. 5. <ul><li>Review the TechNet planning guides </li></ul><ul><ul><li>Plan for system requirements </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul><ul><ul><li>Design server farms and topologies </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul><ul><ul><li>Plan for performance and capacity </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul><ul><ul><li>Logical architecture components </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul>
    6. 6. <ul><li>Document customer base </li></ul><ul><ul><li># users, usage profiles, locations </li></ul></ul><ul><li>Gather requirements </li></ul><ul><ul><li>Functionality </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><li>Plan for capacity </li></ul><ul><li>Plan for performance </li></ul><ul><li>Research and document design constraints </li></ul>
    7. 7. <ul><li>SharePoint Topology Planning </li></ul>
    8. 8. <ul><li>Can contain up to 5 million items </li></ul><ul><li>Split content up using folders </li></ul><ul><li>Try to not have more than 2000 items/folders at any one level in the hierarchy </li></ul><ul><ul><li>Not a hard limit </li></ul></ul><ul><ul><li>Utilise indexed columns and custom views </li></ul></ul><ul><li>Consider </li></ul><ul><ul><li>Usability </li></ul></ul><ul><ul><li>Search Relevance </li></ul></ul><ul><ul><li>Size of the content database </li></ul></ul>
    9. 9. <ul><li>250,000 sites per collection / 50,000 collections per web application </li></ul><ul><ul><li>Nest sites to reach 250,000 (2000 / level) </li></ul></ul><ul><ul><li>Site enumeration performance drops at 2000 sites </li></ul></ul><ul><li>Consider </li></ul><ul><ul><li>Usability & Search Relevance </li></ul></ul><ul><ul><li>Size of collection / content databases </li></ul></ul><ul><ul><li>Operations like export / import </li></ul></ul>
    10. 10. <ul><li>Max size based on operations / SLAs </li></ul><ul><ul><li>Most customers: 50GB – 250GB </li></ul></ul><ul><li>Recommend no more than 100 per web application (based on SQL server spec) </li></ul><ul><ul><li>Move to multiple SQL instances to increase </li></ul></ul><ul><li>Try to group site collections of similar size and function into shared content databases </li></ul><ul><li>Site collections cannot span multiple DBs </li></ul><ul><li>Content deployment requires multiple DBs </li></ul><ul><li>STSADM can target content DBs / UI cannot* </li></ul><ul><li>New SP1 STSADM command “mergecontentdb” can be used to merge and split content dbs </li></ul>
    11. 11. <ul><li>99 per Shared Service Provider </li></ul><ul><ul><li>Consider server resources (10 per farm realistic) </li></ul></ul><ul><ul><ul><li>1-2GB memory typical </li></ul></ul></ul><ul><ul><ul><li>Sharing app pools can decrease utilisation </li></ul></ul></ul><ul><ul><li>10 > will probably require multiple child farms </li></ul></ul><ul><li>Consider </li></ul><ul><ul><li>Top level URL requirements / SSL </li></ul></ul><ul><ul><li>Functional requirements (ex: self service site creation) </li></ul></ul><ul><ul><li>Process isolation </li></ul></ul>
    12. 12. <ul><li>3 per farm, 20 max </li></ul><ul><li>Server resources are a big factor </li></ul><ul><li>Why multiple SSPs? </li></ul><ul><ul><li>Differing functional requirements </li></ul></ul><ul><ul><li>Multiple administrative groups </li></ul></ul><ul><ul><li>Multiple index servers / multiple indexes * </li></ul></ul><ul><li>In most scenarios, one SSP is all you need </li></ul>
    13. 13. <ul><li>No theoretical limit when isolated (running own SSP) </li></ul><ul><ul><li>Consider CapEx/OpEx </li></ul></ul><ul><li>Can consume a parent farm’s SSP or host an SSP for other farms to consume </li></ul><ul><ul><li>99 web apps per SSP apply </li></ul></ul><ul><ul><li>Can only share 1 SSP </li></ul></ul>
    14. 14. <ul><li>SharePoint Topology Planning </li></ul>
    15. 15. <ul><li>“ Basic Install” – all services running on a single box </li></ul><ul><li>Pros </li></ul><ul><ul><li>Simple “one click” install </li></ul></ul><ul><ul><li>Inexpensive </li></ul></ul><ul><ul><li>Includes SQL Express </li></ul></ul><ul><ul><li>Great for evals/prototypes </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>No direct upgrade to multi-server topology </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Scalability (SQL express) </li></ul></ul><ul><ul><li>Performance </li></ul></ul>
    16. 16. <ul><li>Single MOSS server (complete install), separate SQL backend </li></ul><ul><li>Pros </li></ul><ul><ul><li>Better scalability / performance with SQL standard / enterprise </li></ul></ul><ul><ul><li>Intensive I/O and memory consumption moved offloaded </li></ul></ul><ul><ul><li>Added SQL features: SRS, AS </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>MOSS performance </li></ul></ul><ul><ul><li>Scalability </li></ul></ul>
    17. 17. <ul><li>Pros </li></ul><ul><ul><li>SQL high availability </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>MOSS availability / perf </li></ul></ul><ul><ul><li>More complex install (Cluster setup / shared disk) </li></ul></ul><ul><li>Questions </li></ul><ul><ul><li>A/A or A/P? </li></ul></ul><ul><ul><li>Clustering or Mirroring? </li></ul></ul>
    18. 18. <ul><li>Pros: </li></ul><ul><ul><li>Better MOSS performance </li></ul></ul><ul><ul><li>Increases scalability </li></ul></ul><ul><ul><li>Better availability </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>Only one query server </li></ul></ul><ul><ul><li>Unbalanced resource utilisation </li></ul></ul>
    19. 19. <ul><li>Typical “starter” topology </li></ul><ul><li>Pros: </li></ul><ul><ul><li>Balanced resource consumption </li></ul></ul><ul><ul><li>Multiple query services </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>Can’t cluster / load balance indexer </li></ul></ul><ul><ul><li>Increasing storage requirements </li></ul></ul>
    20. 20. <ul><li>Pros: </li></ul><ul><ul><li>Increased capacity / performance </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>Lots of storage </li></ul></ul><ul><ul><li>Increased OpEx </li></ul></ul><ul><li>Note </li></ul><ul><ul><li>Diminishing returns (4-5 WFE / SQL) </li></ul></ul><ul><ul><li>Increases auth traffic (3-4 wfe / AD w/ NTLM) </li></ul></ul>
    21. 21. <ul><li>Pros </li></ul><ul><ul><li>Potential increase in query performance </li></ul></ul><ul><li>Notice </li></ul><ul><ul><li>Multiple SQL clusters to support greater number of WFEs </li></ul></ul>
    22. 22. <ul><li>Indexer is configured to crawl only 1 WFE (outside the LB) </li></ul><ul><li>Pros: </li></ul><ul><ul><li>Index traffic doesn’t consume user WFE server resources – better perf </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>Single point of failure </li></ul></ul><ul><ul><li>Potential increase in crawl time </li></ul></ul><ul><ul><li>Host file maintenance </li></ul></ul>
    23. 23. <ul><li>Indexer running web service and configured to index itself </li></ul><ul><li>Pros </li></ul><ul><ul><li>Less crawl traffic on the wire </li></ul></ul><ul><ul><li>Potential increase in index performance </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>Indexer server resources split between indexing operation and WFE operation </li></ul></ul>
    24. 24. <ul><li>Services such as Excel Services, Document conversions, etc can be ran on dedicated hardware </li></ul><ul><li>Pros </li></ul><ul><ul><li>Better performance for WFE and application servers </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>More complicated configuration </li></ul></ul><ul><ul><li>Increased costs </li></ul></ul>
    25. 25. <ul><li>Parent farm provides shared services to child farms (must be on LAN not WAN*) </li></ul><ul><li>Child farms may have their own SSP (excel services) </li></ul><ul><li>Pros </li></ul><ul><ul><li>Massive scalability / performance </li></ul></ul><ul><ul><li>Targeted performance tuning </li></ul></ul><ul><ul><li>Isolation </li></ul></ul><ul><ul><li>Franchise model </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>Complex setup </li></ul></ul><ul><ul><li>Complex backup / restore – increased </li></ul></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>Child farms cannot administrate shared service / differing SSP configuration </li></ul></ul><ul><li>Note: </li></ul><ul><ul><li>May or may not have multiple SQL clusters </li></ul></ul>
    26. 26. <ul><li>Typical example of multi-farm topology </li></ul><ul><li>Challenges </li></ul><ul><ul><li>AuthN / SSO experience for internal users </li></ul></ul><ul><ul><li>Content Synchronisation? </li></ul></ul>
    27. 27. <ul><li>Put’s the “service” closer to the customer = Better user experience </li></ul><ul><li>Challenges </li></ul><ul><ul><li>Centralised administration </li></ul></ul><ul><ul><li>Search Architecture </li></ul></ul><ul><ul><li>Two way synchronisation </li></ul></ul><ul><ul><li>Profile synch </li></ul></ul><ul><ul><li>Global deployment of MySites </li></ul></ul>
    28. 28. <ul><li>Recommendations: </li></ul><ul><ul><li>Improve the network issues before jumping to multiple farms </li></ul></ul><ul><ul><li>Look to third party tools to provide additional functionality in global scenarios </li></ul></ul><ul><ul><ul><li>Admin: Quest, Echo Tech, DeliverPoint </li></ul></ul></ul><ul><ul><ul><li>Replication: Syntergy, Echo Technologies, iOra ,Doubletake </li></ul></ul></ul><ul><ul><ul><li>Network Acceleration: Citrix, Cisco, Packeteer, Certeon </li></ul></ul></ul><ul><ul><ul><li>Offline -Colligio, iOra </li></ul></ul></ul>
    29. 29. <ul><li>IT Org capability? </li></ul><ul><li>Third party components? </li></ul><ul><li>014 strategy / timeline? </li></ul><ul><li>Why 64 bit </li></ul><ul><ul><li>Performance e </li></ul></ul><ul><ul><li>Scalability (> 2GB) </li></ul></ul>
    30. 30. <ul><li>Mixed mode? </li></ul><ul><ul><li>Longer term – recommendation is not to mix 64/32 bit in the same tier </li></ul></ul><ul><ul><li>Short term – can mix (example 32 -> 64 upgrade) </li></ul></ul>
    31. 31. <ul><li>IT Org capability? </li></ul><ul><li>Third party components? </li></ul><ul><li>014 strategy / timeline? </li></ul><ul><li>Why 64 bit </li></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>Scalability </li></ul></ul>
    32. 32. <ul><li>Recommendation: </li></ul><ul><ul><li>SQL – 64 bit highly recommended </li></ul></ul><ul><ul><li>Index - 64 bit if you can – check filter / protocol handler availability </li></ul></ul><ul><ul><li>WFE – 64 bit for better scalability (More web applications) </li></ul></ul>
    33. 33. <ul><li>The first server in the farm will host the CA site </li></ul><ul><li>CA can be moved – </li></ul><ul><ul><li>Config Wizard </li></ul></ul><ul><ul><li>PSConfig – adminvs </li></ul></ul><ul><li>Best location? It depends  </li></ul><ul><li>Load Balance? It depends  </li></ul>
    34. 34. <ul><li>Existing Infrastructure </li></ul><ul><ul><li>AD / DNS / Network </li></ul></ul><ul><ul><ul><li>Authentication method (Kerb/NTLM) can have a big impact on AD </li></ul></ul></ul><ul><li>Storage </li></ul><ul><ul><li>DAS / SAS / SAN </li></ul></ul><ul><li>Backup / Restore </li></ul><ul><li>Archive </li></ul><ul><li>Disaster Recovery </li></ul><ul><li>Monitoring </li></ul><ul><li>Proxy Servers / Firewalls </li></ul>
    35. 35. <ul><li>1. User access (Web traffic from browsers to web servers): </li></ul><ul><ul><li>TCP Port 80 (HTTP) </li></ul></ul><ul><ul><li>SSL Port 443 (HTTPS) </li></ul></ul><ul><ul><li>Custom Port(s) – (Web application zones can be configured to use any available port) </li></ul></ul><ul><li>2. Search Query/Index Propagation: </li></ul><ul><ul><li>Named Pipes, which requires File and Printer Sharing </li></ul></ul><ul><ul><ul><li>NBT —UDP Port 137,UDP Port 138, TCP Port 139 </li></ul></ul></ul><ul><ul><ul><li>Direct-hosted SMB —TCP/UDP Ports 445 </li></ul></ul></ul><ul><li>3. MOSS Web Services: </li></ul><ul><ul><li>Both default to: </li></ul></ul><ul><ul><ul><li>TCP 56737 </li></ul></ul></ul><ul><ul><ul><li>TCP 56738 (SSL) </li></ul></ul></ul><ul><ul><ul><li>Customizable using stsadm -setsspport </li></ul></ul></ul><ul><li>4. SQL Communications: </li></ul><ul><ul><li>Default Instance: TCL Port 1433 (default), can listen on custom (assigned) port </li></ul></ul><ul><ul><li>Named Instances: Listen on random TCP ports by default, can listen on custom (assigned) ports </li></ul></ul><ul><li>5. Search Indexing: </li></ul><ul><ul><li>TCP Port 80 (HTTP) </li></ul></ul><ul><ul><li>SSL Port 443 (HTTP) </li></ul></ul><ul><ul><li>Custom Port(s) – can index any port based on content source rules (for instance, file share crawls use SMB (TCP/UDP 445 ) </li></ul></ul><ul><li>6. SSO Communications </li></ul><ul><ul><li>Communications with encryption key server requires RPC: </li></ul></ul><ul><ul><ul><li>TCP 135 (RPC endpoint mapper) </li></ul></ul></ul><ul><ul><ul><li>Random high ports OR </li></ul></ul></ul><ul><ul><ul><li>Assigned range of static ports </li></ul></ul></ul>
    36. 36. <ul><li> </li></ul><ul><li>Microsoft fully supports Virtual Server 2005 R2 </li></ul><ul><li>We provide commercially reasonable support for VMWare </li></ul><ul><ul><li>if a customer is having a SharePoint issue on VMWare we will go to reasonable lengths to address it.  </li></ul></ul><ul><li>If it is necessary support will ask to repro the issue on a hardware based machine for further investigation  </li></ul><ul><li>We do set expectations up front that it is not officially supported in the sense that we would provide a Hotfix if the issue was caused by running on VMWare </li></ul><ul><li>Most issues encountered in a VW environment are issues you would see on physical servers </li></ul>
    37. 37. <ul><li>What to virtualise (non production) </li></ul><ul><ul><li>Local dev boxes, build machines, integrated dev environments, “smoke test” environments </li></ul></ul><ul><ul><li>POC / prototypes </li></ul></ul><ul><ul><li>Try not to virtualise performance testing environments </li></ul></ul><ul><li>Production </li></ul><ul><ul><li>WFE are good candidates </li></ul></ul><ul><ul><li>Query servers potentially if you expect a very light search load (which isn’t the case most of the time) </li></ul></ul><ul><ul><li>Definitely not the SQL servers! </li></ul></ul><ul><li>Remember to be realistic with your VM configuration </li></ul>
    38. 38. <ul><li>Use a tool like the HP sizing and Configuration Tool or System Center Capacity Planner 2006* </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li>Start with a basic 5 server physical topology – provides good performance and availability. Scales out easily </li></ul></ul><ul><ul><li>Start with a small user population (pilot). Ramp new users on in a controlled manner – monitor and scale out as needed </li></ul></ul><ul><li>Use the out of box site definitions / fabulous 40 templates to get started </li></ul><ul><ul><li>Let the organisation mature, then initiate an IM redesign </li></ul></ul>