SharePoint Topology

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

Availability Capacity Performance Organisational requirements Differing availability requirements / SLAs Regulatory / data segregation requirements Functional requirements Licensing Cost

Increasing complexity and cost

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

Document customer base # users, usage profiles, locations Gather requirements Functionality Availability Plan for capacity Plan for performance Research and document design constraints

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 Utilise indexed columns and custom views Consider Usability Search Relevance Size of the content database

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

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

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

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

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

“ 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

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

Pros SQL high availability Cons MOSS availability / perf More complex install (Cluster setup / shared disk) Questions A/A or A/P? Clustering or Mirroring?

Pros: Better MOSS performance Increases scalability Better availability Cons: Only one query server Unbalanced resource utilisation

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

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)

Pros Potential increase in query performance Notice Multiple SQL clusters to support greater number of WFEs

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

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

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

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

Typical example of multi-farm topology Challenges AuthN / SSO experience for internal users Content Synchronisation?

Put’s the “service” closer to the customer = Better user experience Challenges Centralised administration Search Architecture Two way synchronisation Profile synch Global deployment of MySites

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

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

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

IT Org capability? Third party components? 014 strategy / timeline? Why 64 bit Performance Scalability

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)

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 

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

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

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

What to virtualise (non production) Local dev boxes, build machines, integrated dev environments, “smoke test” environments POC / prototypes Try not to virtualise 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

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 organisation mature, then initiate an IM redesign

SharePoint Topology

Related slideshows

More Related Content

SharePoint Topology

Editor's Notes