SharePoint Topologies

1. SharePoint Topologies Tom Wisnowski Sr. Consultant, Microsoft Consulting Services tomwis@microsoft.com

2. Pop Quiz! Forget the old definitions! They do not apply to Microsoft Office SharePoint Server 2007 topologies. • What is the Microsoft supported definition of: • Small Farm? • Medium Farm? • Large Farm?

3. Considerations when planning your physical topology • Availability • Capacity • Performance • Organizational requirements • Differing availability requirements / SLAs • Regulatory / data segregation requirements • Functional requirements • Licensing • Cost

4. Topology Design Components Increasing complexity and cost

5. Getting started… • Review the TechNet planning guides • Plan for system requirements • http://technet2.microsoft.com/Office/en-us/library/0ed0b44c-d60d-4b85-87de-19065d9688351033.mspx?mfr=true • Design server farms and topologies • http://technet2.microsoft.com/Office/en-us/library/0ed0b44c-d60d-4b85-87de-19065d9688351033.mspx?mfr=true • Plan for performance and capacity • http://technet2.microsoft.com/Office/en-us/library/0ed0b44c-d60d-4b85-87de-19065d9688351033.mspx?mfr=true • Logical architecture components • http://technet2.microsoft.com/Office/en-us/library/0ed0b44c-d60d-4b85-87de-19065d9688351033.mspx?mfr=true

6. Getting started… • Document customer base • # users, usage profiles, locations • Gather requirements • Functionality • Availability • Plan for capacity • Plan for performance • Research and document design constraints

7. Logical Components SharePoint Topology Planning

8. Lists and Libraries • Can contain up to 5 million items • Split content up using folders • Try to not have more than 2000 items/folders at any one level in the hierarchy • Not a hard limit • Utilize indexed columns and custom views • Consider • Usability • Search Relevance • Size of the content database

9. Sites and Site Collections • 250,000 sites per collection / 50,000 collections per web application • Nest sites to reach 250,000 (2000 / level) • Site enumeration performance drops at 2000 sites • Consider • Usability & Search Relevance • Size of collection / content databases • Operations like export / import

10. Content Databases • Max size based on operations / SLAs • Most customers: 50GB – 250GB • Recommend no more than 100 per web application (based on SQL server spec) • Move to multiple SQL instances to increase • Try to group site collections of similar size and function into shared content databases • Site collections cannot span multiple DBs • Content deployment requires multiple DBs • STSADM can target content DBs / UI cannot* • New SP1 STSADM command “mergecontentdb” can be used to merge and split content dbs

11. Web Applications • 99 per Shared Service Provider • Consider server resources (10 per farm realistic) • 1-2GB memory typical • Sharing app pools can decrease utilization • 10 > will probably require multiple child farms • Consider • Top level URL requirements / SSL • Functional requirements (ex: self service site creation) • Process isolation

12. Shared Service Providers • 3 per farm, 20 max • Server resources are a big factor • Why multiple SSPs? • Differing functional requirements • Multiple administrative groups • Multiple index servers / multiple indexes * • In most scenarios, one SSP is all you need

13. Farms • No theoretical limit when isolated (running own SSP) • Consider CapEx/OpEx • Can consume a parent farm’s SSP or host an SSP for other farms to consume • 99 web apps per SSP apply • Can only share 1 SSP

14. Physical Components SharePoint Topology Planning

15. Single Server • “Basic Install” – all services running on a single box • Pros • Simple “one click” install • Inexpensive • Includes SQL Express • Great for evals/prototypes • Cons • No direct upgrade to multi-server topology • Availability • Scalability (SQL express) • Performance

16. Dedicated SQL Server • Single MOSS server (complete install), separate SQL backend • Pros • Better scalability / performance with SQL standard / enterprise • Intensive I/O and memory consumption moved offloaded • Added SQL features: SRS, AS • Cons • Availability • MOSS performance • Scalability

17. Clustered SQL Back-end • Pros • SQL high availability • Cons • MOSS availability / perf • More complex install (Cluster setup / shared disk) • Questions • A/A or A/P? • Clustering or Mirroring?

18. Load Balanced WFE • Pros: • Better MOSS performance • Increases scalability • Better availability • Cons: • Only one query server • Unbalanced resource utilization

19. Dedicated Index Server • Typical “starter” topology • Pros: • Balanced resource consumption • Multiple query services • Cons: • Can’t cluster / load balance indexer • Increasing storage requirements

20. Increasing Capacity • Pros: • Increased capacity / performance • Cons • Lots of storage • Increased OpEx • Note • Diminishing returns (4-5 WFE / SQL) • Increases auth traffic (3-4 wfe / AD w/ NTLM)

21. Separate Query Servers • Pros • Potential increase in query performance • Notice • Multiple SQL clusters to support greater number of WFEs

22. Dedicated Indexing Target • Indexer is configured to crawl only 1 WFE (outside the LB) • Pros: • Index traffic doesn’t consume user WFE server resources – better perf • Cons: • Single point of failure • Potential increase in crawl time • Host file maintenance

23. Index / WFE Combo • Indexer running web service and configured to index itself • Pros • Less crawl traffic on the wire • Potential increase in index performance • Cons • Indexer server resources split between indexing operation and WFE operation

24. Additional Application Servers • Services such as Excel Services, Document conversions, etc can be ran on dedicated hardware • Pros • Better performance for WFE and application servers • Cons • More complicated configuration • Increased costs

25. Multiple Farms • Parent farm provides shared services to child farms (must be on LAN not WAN*) • Child farms may have their own SSP (excel services) • Pros • Massive scalability / performance • Targeted performance tuning • Isolation • Franchise model • Cons • Complex setup • Complex backup / restore – increased • Cost • Child farms cannot administrate shared service / differing SSP configuration • Note: • May or may not have multiple SQL clusters

26. Extranet Example • Typical example of multi-farm topology • Challenges • AuthN / SSO experience for internal users • Content Synchronization?

27. Geographically Distributed Farms • Put’s the “service” closer to the customer = Better user experience • Challenges • Centralized administration • Search Architecture • Two way synchronization • Profile synch • Global deployment of MySites

28. Geographically Distributed Farms • Recommendations: • Improve the network issues before jumping to multiple farms • Look to third party tools to provide additional functionality in global scenarios • Admin: Quest, Echo Tech, DeliverPoint • Replication: Syntergy, Echo Technologies, iOra ,Doubletake • Network Acceleration: Citrix, Cisco, Packeteer, Certeon • Offline -Colligio, iOra

29. 32 or 64 bit? • IT Org capability? • Third party components? • 014 strategy / timeline? • Why 64 bit • Performance e • Scalability (> 2GB)

30. 32 or 64 bit? • Mixed mode? • Longer term – recommendation is not to mix 64/32 bit in the same tier • Short term – can mix (example 32 -> 64 upgrade)

31. 32 or 64 bit? • IT Org capability? • Third party components? • 014 strategy / timeline? • Why 64 bit • Performance • Scalability

32. 32 or 64 bit? • Recommendation: • SQL – 64 bit highly recommended • Index - 64 bit if you can – check filter / protocol handler availability • WFE – 64 bit for better scalability (More web applications)

33. What about Central Administration? • The first server in the farm will host the CA site • CA can be moved – • Config Wizard • PSConfig – adminvs • Best location? It depends  • Load Balance? It depends 

34. Additional Elements • Existing Infrastructure • AD / DNS / Network • Authentication method (Kerb/NTLM) can have a big impact on AD • Storage • DAS / SAS / SAN • Backup / Restore • Archive • Disaster Recovery • Monitoring • Proxy Servers / Firewalls

35. Network communications 1. User access (Web traffic from browsers to web servers): TCP Port 80 (HTTP) SSL Port 443 (HTTPS) Custom Port(s) – (Web application zones can be configured to use any available port) 2. Search Query/Index Propagation: Named Pipes, which requires File and Printer Sharing NBT —UDP Port 137,UDP Port 138, TCP Port 139 Direct-hosted SMB —TCP/UDP Ports 445 3. MOSS Web Services: Both default to: TCP 56737 TCP 56738 (SSL) Customizable using stsadm -setsspport 4. SQL Communications: Default Instance: TCL Port 1433 (default), can listen on custom (assigned) port Named Instances: Listen on random TCP ports by default, can listen on custom (assigned) ports 5. Search Indexing: TCP Port 80 (HTTP) SSL Port 443 (HTTP) Custom Port(s) – can index any port based on content source rules (for instance, file share crawls use SMB (TCP/UDP 445 ) 6. SSO Communications Communications with encryption key server requires RPC: TCP 135 (RPC endpoint mapper) Random high ports OR Assigned range of static ports

36. Virtualization • http://support.microsoft.com/kb/909840 • Microsoft fully supports Virtual Server 2005 R2 • We provide commercially reasonable support for VMWare • if a customer is having a SharePoint issue on VMWare we will go to reasonable lengths to address it.  • If it is necessary support will ask to repro the issue on a hardware based machine for further investigation  • 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 • Most issues encountered in a VW environment are issues you would see on physical servers

37. Virtualization • What to virtualize (non production) • Local dev boxes, build machines, integrated dev environments, “smoke test” environments • POC / prototypes • Try not to virtualize performance testing environments • Production • WFE are good candidates • Query servers potentially if you expect a very light search load (which isn’t the case most of the time) • Definitely not the SQL servers! • Remember to be realistic with your VM configuration

38. I need this running tomorrow! • Use a tool like the HP sizing and Configuration Tool or System Center Capacity Planner 2006* • http://h71019.www7.hp.com/activeanswers/Secure/548230-0-0-0-121.html • Start with a basic 5 server physical topology – provides good performance and availability. Scales out easily • Start with a small user population (pilot). Ramp new users on in a controlled manner – monitor and scale out as needed • Use the out of box site definitions / fabulous 40 templates to get started • Let the organization mature, then initiate an IM redesign

39. Questions ?