spca2013 - best practices & considerations for designing your sharepoint logical architecture
DESCRIPTION
Best Practices & Considerations for Designing Your SharePoint Logical ArchitectureTRANSCRIPT
Mirjam van Olst
Best Practices & Considerations for Designing
Your SharePoint Logical Architecture
Introduction Logical Architecture
Design
• Web Applications
• Service Applications
• Site Collections &
Content Databases
• Sites
Agenda
Wrap Up
Introduction
Configuration of
your SharePoint
environment
Logical Architecture
Continuous
monitoring
needed
Get the most
from out-of-the-
box SharePoint
Logical Architecture Design
Be able to
scale your
environment
Avoid common
health and
performance
challenges
Functional Drivers
• Shared security
• Content rollup
• Shared settings
Logical Architecture Design
Technical Drivers
• Boundaries
Second best:
Good insight into
the environment
and the
organization
Logical Architecture Design
Thorough
understanding of
SharePoint
internals
Safest bet: use your crystal ball
Items
Libraries and Lists
Sites
Site Collections
Content Databases
Web Applications
Servers
Farm
SharePoint Hierarchy
Logical Architecture Design
Logical Architecture Design
1 2 3 4Web
ApplicationsService
ApplicationsSitesContent
Databases & Site
Collections
Web Application Considerations
Potential Influences:– Intended Use
– Scalability
– SharePoint App policies
– Host Header Web Applications
vs.
Host Named Site Collections
Host Named Site Collections
Best practice
for new
deployments
Created using
PowerShell
(no User
Interface)
Hosted in a
single web
application
without a host
header
SharePoint
Apps
Multi-Tenancy Request Management
…expect more in the future
Host header-less web applications
New capabilities in SharePoint have been designed
for, and expect a web application with no host header
When to use Path Based Sites
Self Service
Site Creation
Unique wild
card inclusion
Managed Paths
Security
isolation with
separate app
pools
Host Named vs. Host Header
Host Named Site Collections:• 1 web application
Host Header Web applications:• Portal• Team Sites /
Project Sites• My Sites
Custom Solutions
Custom solutions can be deployed to:
All Web
Applications
A specific Web
Application
The Farm
SharePoint Apps
App Catalog per
Web Application
App settings for
users per Web
Application
SharePoint Apps
Software BoundariesWeb Applications
Limit Maximum Value Limit Type
Web Applications 20 per farm Supported
Zone 5 per web application Boundary
Managed Path 20 per web application Supported
Application Pools 10 per web server Supported
Reasons for multiple web apps
Usage Service
Applications
SharePoint
Apps and
Custom
Solutions
2
Logical Architecture Design
1 3 4Web
ApplicationsService
ApplicationsSitesContent
Databases & Site
Collections
Service Application model
Service Applications can easily be scaled out
Web applications can pick and choose service applications
Some Service Applications can be shared across farms
Service Applications
Proxy Groups
• A proxy group is a group of Service Application
Proxies (connections) that are selected for one or
more web applications
• By default, all Service Application Proxies are
included in the default proxy group
• A web application can:
• Use the default proxy group
• Use a custom proxy group and select service application
proxies
• A custom proxy group is specific to a web
application when using the user interface
http://intranet
http://my
http://communities
http://teams
http://projects
Business Data
Connectivity Managed
Metadata
User ProfileExcel
Search
App
Management
Visio Graphics
Excel
Machine
Translation
Secure Store
Proxy Groups
Service Application Considerations
Isolation Scalability What
functionality
and where?
Scaling of Services
• First role to move to a dedicated server is crawl
• Calculations in Excel Services could use a lot of
CPU
• User Profile synchronization single point of failure
• Only one User Profile Service Application and one
Search Service Application per server
• Access Services needs it’s own SQL Server
instance or SQL Server server
2
Logical Architecture Design
1 3 4Web
ApplicationsService
ApplicationsContent
Databases & Site
Collections
Sites
Content Databases
• A content database should be within 100 to 200 GB
• A site collection is always stored in a single content
database
• Limiting the size of a content database could be a
reason to use multiple site collections
Sites and Site CollectionsInfluencers
People Content Site Types
Sites and Site Collections
Within a site collection the following things can shared:
• Navigation
• Content types
• Site Columns
• SharePoint Apps
• Master pages
• SharePoint Security groups
• Lookup fields for lists
• Search scopes
• Feature set
Complex
security
Separate
backup and
restore
schedules and
demands
Site Collection
quotas
Decentralized
administration
Sites and Site CollectionsFunctional reasons for multiple site collections
More than
2000 sub
sites per “site
view”
More than
250,000 sub
sites
More than
100-200GB
of content
Complex
authorization
structures
per site
Sites and Site CollectionsArchitectural reasons for multiple site collections
Software BoundariesSite Collections
Limit Maximum Value Limit Type
Site collections per farm 250,000 for non-personal site collections
Supported
Site collections per farm 750,000 Supported
Site collections per
content database
2,500 for non-personal site
collections
Supported
Site collections per
content database
5,000 Recommended
Users in a site collection 2 million (after more than
1,000 the user interface will
no longer scale and
PowerShell should be used)
Supported
2
Logical Architecture Design
1 3 4Web
ApplicationsService
ApplicationsSitesContent
Databases & Site
Collections
Software BoundariesSecurity
Limit Maximum Value Limit Type
Security Scopes per list 5,000 Recommended
Number of SharePoint groups a
user can belong to
5,000 Supported
Users in a SharePoint group 5,000 Supported
Security principal per Access
Control List (ACL)
5,000 Supported
Security
Don’t use item level security if you can avoid it
– “Sharing” an item or document means using item level
security!
Security
Don’t use item level security if you can avoid it
– “Sharing” an item or document means using item level
security!
Wrap up
Consider
Functional
and
Technical
drivers
Thorough
investigation
and planning
needed
Design for
growth
Custom
solutions add
complexity
and risk
Wrap Up
THANK YOU