Speaker: Darko Milevski;
Today, many organizations use SharePoint as an ultimate platform for collaboration and consolidation of their business applications. At the same time, most of them find it easy for start-up implementation and almost plug-and-play use by employees. In time, the platform adopts more and more users, data, applications and processes, and if not architected and governed with this considerations, it becomes very tough to maintain and lose it’s performance and usability. Solid SharePoint solutions architecture at the beginning of implementation is crucial for long-term success, performance and usability of the applications on top of Microsoft prime enterprise content management platform. In this presentation, I will cover various aspects and considerations that should be analyzed and later implemented very carefully in a production SharePoint farm. Topics like Farm topology, SQL performance, Backups, Updates and Patching, Storage, Security and Governance will be covered. Form Development perspective, defining and negotiating Requirements, identifying constraints, policies, and selecting right SharePoint features and APIs that will be used in the solutions, is another aspect of the complete solution designing process.
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
Designing SharePoint solutions – Big Decisions for Big Success
1. Designing SharePoint solutions
Big Decisions for Big Success
DARKO MILEVSKI, NEXTSENSE
SHAREPOINT AND PROJECT CONFERENCE ADRIATICS
ZAGREB, 11/28/2012
3. Breaking the “knows everything”
stereotype
• SharePoint (…, 2010, 2013,…) has become a truly massive
platform that can be thought of as an operating system for
Information Workers.
• In this context, it is becoming increasingly difficult for any single
individual to know everything about SharePoint.
• Instead, the community of SharePoint professionals is
specializing. Some of us are workflow experts, others are web
content management experts, still others are focused on data
integration.
• Furthermore, it is now impossible to collect all of the end user,
administration, and development knowledge for SharePoint into
a single resource.
4. Poll
Infrastructure Development
• SharePoint Farm • SP Web Pages & Web Parts
• Web-Front end server • Web Services & WCF
• Application Server • SharePoint Object Model
• SP Service Applications • Scripting (JavaScript, jQuery)
• SharePoint Web Application • Configuration
• Configuration & Content • Logging
Databases • Notification
• Site Collection
6. SharePoint Farm Servers
A SharePoint farm is a collection of SharePoint servers (and SQL Servers) that
work in concert to provide a set of basic SharePoint services that support a
single site.
7. Limited deployments (1-2 servers)
SharePoint Farm Topologies
Limited deployments are typically used for product evaluation,
development and testing, or for environments that have limited
numbers of users and don t require fault-tolerance.
One-server farm Two-tier farm Three-server virtualized farm
Evaluation or <100 users Up to 10,000 users
Use virtualization to maximize the potential of a
smaller number of servers
All roles on one server, All Web and application Two web servers are predicted to serve
including SQL Server server roles 10,000-20,000 users.
Host A Host B
Databases
Web server Web server
All application All application
server roles server roles
All SharePoint
databases
8. SharePoint Farm Topologies
Smallest fault-tolerant farm utilizing Six-server virtualized farm
virtualization Host A Host B
All farm server roles virtualized and distributed
across two or four host servers (depending on the
operating system) to provide fault tolerance using
Web server Web server
the minimum number of servers.
Windows Server 2008 R2
Web server Dedicated
Host A Host B Web server
for crawling
Host C Host D
Web server Web server
All application All application Query and Query and
index index
server roles server roles
All other All other
application application
Host C server roles server roles
Host D
Host E Host F
All All
databases databases
All All
databases databases
SQL Server installed and configured to support
SQL clustering, mirroring, or AlwaysOn. AlwaysOn
requires SQL Server 2012. SQL Server installed and configured to support
SQL clustering, mirroring, or AlwaysOn across both
of the hosts. AlwaysOn requires SQL Server 2012.
10. Installing SharePoint Farm
• Next -> Next -> Finish experience
• Everybody can install SharePoint Server?
• Installing SP2010 SP1 (Patches)
• Install, Update than Configure
• Configuration Wizard vs. PowerShell
• Control all accounts (Least Privileged Accounts installation)
• Control Service Applications (which will be installed)
• Control Database names
12. SQL Database considerations (1)
• Database/Storage Configuration
• Recommended database file placement priority (fastest to slowest
drive)
• tempdb data and t-log files
• Db transaction log files
• Search db data files
• Content db data files
• Place tempdb, Content and t-logs on separate LUNs
• Use multiple data files for big Content and Search dbs
• Distribute equal-sized data files across separate disks
• # of data files should be <= # of processor cores
• Multiple data files are not supported for other dbs
13. SQL Database considerations (2)
• Database/Storage Sizing
• Limit Content DBs to 100 GB (soft limit)
• MS Supported 200GB – General Usage
• MS Supported 4TB – 0.25 IOPs per GB + 2 IIOPs per GB
• You will easily upgrade
• Size SQL Server data files appropriately
• Pre-allocate data file to cover anticipated size of Content db
• Set SQL „Autogrow‟ to fixed value appropriate for size of db
• Do not over-autogrow
• Use dedicated database for large Site Collections (> 50GB)
• Better: > 20GB
15. SQL Databases Maintenance
• Monitor SQL Server performance regularly
• Defragment physical files
• Content and Search dbs most susceptible
• Rebuild / Reorganize indexes to eliminate fragmentation
• Reorganize index when fragmentation between 10-70%
• Rebuild index when fragmentation > 70%
16. Planning SharePoint Solutions
• Gathering requirements
• Map requirements to features
• Carefully consider constraints
• Max content size db
• Max items per list / max sub-sites, etc.
• One content db per site collection
• Prototyping is not enough
• Most of the “Hello world” blogs are not completely true
• Pessimistic SP Logical architecture
18. Front-end Development
• Which Pages to use?
• Application pages (_layouts)
• Web Part Pages (db)
• Custom Web Parts vs Custom Forms
• SharePoint Web Controls (pros – cons)
• UI development – Client Side Scripting
• JavaScript
• jQuery
• Knockouts
• Async
• Branding: Custom master and CSS
19. Back-End Development
• Middle Service Layer
• Avoid implementing logic
• Back-end Business Layer
• Entity Classes
• Business Logic Services (Adapters/Providers)
• Patterns vs Anti-Patterns
• Dependency Injection – data store version independent
• Data stores: SharePoint and SQL
• Implement Interface, reference current SP Versions
20. Common (Back-end) Development
• Config (Storing Configuration values)
• SharePoint List vs Application Settings (web.config)
• Configurator caching
• Logging
• Log in file (log4net)
• ULS (UlsViewer)
• Massaging
• Common mailing system
• Use SharePoint configured SMTP
• Data -> XML -> XSLT -> HTML body
• Localization
• Features Localization -> Resource files
• Solution Localizations -> Resource files vs Custom
21. Data-Layer Development
• Many Items -> use SQL database
• Consider SharePoint List query performance
• Avoid frequently used complex CAML queries
• Organize (structure) sites, sub-sites and Document Libraries
• Distribute files across many site collections if total size exceeds
100GB
• Always consider performance in SP code
22. Deploying SharePoint Solutions
• PowerShell – ultimate tool for SP manipulation
• Install
• Upgrade
• Backup
• Write ps scripts for installation process automation
• Mix SP, shell, SQL and other commands
• Recreate your development site collections
• Deactivate-Activate Features (redeploy)
• Recreate your Content Types, Terms, Reindex, etc.
We have to decide how many web front-ends we will installHow many Application ServersWhich Service Application we will use (do not run SA if not used, they use resources)Which SA will run on which Server, what about HA of some SADatabase Clustering and Mirroring
Almost everybody can install SharePoint
Web Parts can have propreties that can be changed by the Site Collection Administrators or event by usersSharePoint People Picker control is very powerful, not brandable, has error messages that will move your layoutManaged Metadata control – problem with adding new terms – need a hack
User Services to expose your functionalityAnemic-Domain Object Model
HTTP Request to read Config settings – often and slowConfiguration caching -> cons require IISRESETXML – XSLT technique – easy changeableCustom localization -> user/admin can change localizations