Http:// Tom Wisnowski Sr. Consultant, Microsoft Consulting Services [email protected].

http://www.azsharepointpros.comhttp://www.azsharepointpros.com

Tom WisnowskiSr. Consultant, Microsoft Consulting [email protected]


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 Organizational 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

SharePoint Topology Planning


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


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 utilization

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

SharePoint Topology Planning


“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

utilization


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 Synchronization?


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


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 SharingNBT —UDP Port 137,UDP Port 138, TCP

Port 139Direct-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 CommunicationsCommunications with encryption key

server requires RPC:TCP 135 (RPC endpoint mapper)Random high ports ORAssigned 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 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


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

Http:// Tom Wisnowski Sr. Consultant, Microsoft Consulting Services [email protected].

Documents

Transcript of Http:// Tom Wisnowski Sr. Consultant, Microsoft Consulting Services [email protected].