building a highly available internet facing sharepoint 2010 farm
TRANSCRIPT
Robin Van den broeck
Building a highly available Internet
facing SharePoint 2010 farm
Sponsors
Venue Sponsor
Platinum Sponsors
Gold Premium Sponsors
Gold Sponsors
About me
• IT Consultant since 1994
• Freelance consultant since 2010
• Been doing .NET development since 2001
• Focus on SharePoint technology since 2008
• Currently employed as a SharePoint Infrastructure Architect at a large financial institution
• Part-time trainer in .NET and SharePoint technologies
• Twitter: @vandero
• Email: [email protected]
Agenda
• Introduction
• Advantages
• Disadvantages
• Specifics of a SharePoint Internet Site
• Content Deployment
• High Availability
• Disaster Recovery
• Patching
• Security
• Performance
USING SHAREPOINT TO CREATE INTERNET
SITES
• SharePoint is one of the “cash cows” of Microsoft
• Mostly used for collaboration but…
more and more internet sites are being created in SharePoint
• Internet sites in general present specific challenges:
• High availability
• Disaster Recovery
• Security
• Performance
• Branding
ADVANTAGES OF USING SHAREPOINT
• You have a full-fledged web content management “authoring” environment with:
• Collaboration options (lists, surveys, my sites, etc)
• Workflows (Approval, Three-State)
• Branding Engine (CSS, Master Pages, Page Layouts, Web Parts)
• SharePoint provides OOTB security (authentication & authorization)
• It’s based on .NET 3.5 and ASP.NET
• It creates its own databases and applies security on them
• It allows you to easily create web farms
• Built-in functionality: Content Deployment, Variations
DISADVANTAGES OF USING SHAREPOINT
• It can be quite challenging to set up a properly working infrastructure
• And even more to keep it running and healthy
• Specialized personnel is required to support it
• Development is not always that easy and becomes challenging when in production
• Price can turn out to be an issue
• It’s very cumbersome to create/brand a site (unless you can do with the OOTB branding –
but not recommended)
SPECIFICS OF A SHAREPOINT INTERNET SITE
• Often a separation between an “authoring” and a “publishing” environment
• Authoring is accessed by internal users
• Publishing is accessed by internal (administrators) and external users
• External users are most often anonymous (but can be authenticated too)
• Content deployment used to migrate content from authoring to publishing
• Must be high available (avoid downtime at all cost)
• Is often available in multiple languages (SharePoint Variations)
• Uses custom branding
SAMPLE PHYSICAL TOPOLOGY
b7b69e
CONTENT DEPLOYMENT
• Specify an export server in the source farm (authoring)
• Specify an import server in the target farm (publishing)
• The import and export servers are typically application servers
• In case an application server fails then the import/export server needs to be manually
reconfigured
Publishing 1
WFE 1 WFE 2
APP 1 APP 2
Publishing 2
WFE 1 WFE 2
APP 1 APP 2
Authoring
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2 DB 1 DB 2
DB 1 DB 2
Data Center A Data Center B
Content
Deployment
Path A
Content
Deployment
Path B
BEST PRACTICES: CONTENT DEPLOYMENT
• Always make sure that the installed solutions are identical on authoring and publishing
farms
• Never change content on the publishing farms
• Use snapshots (avoids putting locks on the source db while deploying content)
• When having multiple publishing farms make sure to leave a small interval between the
schedules of the two deployment jobs (for snapshot creation)
• Make sure the default zone of the target farm is the FQDN URL
• Make sure to require encryption
• No need to copy user names to publishing (however do copy Roles)
• Do one full content deployment to a database with an empty site collection (no template)
• Then only do incremental deployments
HIGH AVAILABILITY
• Within the farm:
• Make Web Front-Ends redundant (external load-balancing)
• Make Application servers redundant (internal load-balancing)
• Install Central Administration on multiple application servers
• Deploy a SQL Server cluster with active/passive nodes
or
Use Database mirroring and the SharePoint failover server settings
• Between farms:
• Deploy separate farms onto multiple locations (e.g. data centers)
• Deploy a load-balancer that includes WFE nodes from different locations
WEB FRONT-END HIGH AVAILABILITY
• Deploy multiple Web Front-Ends in a load-balancing scheme
• Load-balancing options: DNS round-robin, Windows NLB, hardware load-balancer (e.g.
Cisco ACE)
• Even load-distribution is most often sufficient for WFEs
• Sticky-ness can be configured if necessary (recommended when using session state and
caching)
• Hardware load-balancers can do HTTP probing (instead of PING probing)
APPLICATION SERVER HIGH AVAILABILITY
• Most services can be made redundant and load-balanced
• SharePoint services use the internal SharePoint load-balancer
• Services that cannot be made redundant:
• User Profile Synchronization Service
• Enterprise Search Administration Service
• Very easy to configure: simply start the service on multiple application servers
Publishing 1
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2
Publishing 2
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2
Authoring
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2
Data Center A Data Center B
LB
LB
Reconfigure Search
Admin on APP 2
Reconfigure User Profile
Synch on APP 2
ENTERPRISE SEARCH HIGH AVAILABILITY
• Only one administration component (and
search administration database)
• Multiple crawl components (on
application servers or separate index
servers)
• Possible to dedicate crawl components
and databases to specific content
• Multiple query components
• Index partitions (groups of query
components)
• Index partitions is associated with a
property database (crawl metadata)
• Make index partition redundant by adding
mirror query components
DISASTER RECOVERY
• Imagine what to do when your complete SharePoint infrastructure is destroyed
• Not the same as High Availability
• If time permits rebuild the SharePoint farm (worst case) or restore from backups
• Make sure you have a backup SharePoint farm (e.g. in a different data center) if
necessary to recover in a very short time (typical for internet sites)
• Make a Disaster Recover Test Plan and execute it at regular times
• Make a Disaster Recovery Plan (DRP) and
Publishing 1
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2
Publishing 2
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2
Authoring
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2
Data Center A Data Center B
LB
LB
PATCHING
• Keep in mind High Availability when patching publishing
• Authoring can be patched outside of office hours
• Can use the Disaster Recovery Plan to implement a new patch
• Patching sequence on publishing:
1. Patch publishing 2 farm (passive)
2. On the load-balancer make publishing 2 farm active and publishing 1 passive
3. Patch publishing 1 farm
4. On the load-balancer make publishing 1 farm active and publishing 2 passive
Publishing 1
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2
Publishing 2
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2
Authoring
WFE 1 WFE 2
APP 1 APP 2
DB 1 DB 2
Data Center A Data Center B
LB
LB
USER PROFILE SERVICE APPLICATION
• In a separated authoring/publishing architecture, this is only necessary on authoring
• Augment the profiles of “authors” and “administrators” with information from AD or any
other “people” source
• User Profile Synchronization can only be running on one application server at a time
• Make sure that default zone of Central Administration is load-balanced to easy the manual
fail-over
SECURITY
• Make sure that every web app zone that requires authentication is secured with SSL
• Reasons to stay away from wildcard certificates:
• If one server or sub-domain is compromised, all sub-domains may be compromised
• If the wildcard certificate needs to be revoked, all sub-domains will need a new
certificate
• May not work seamlessly with older server-client configurations
• When integrating SharePoint with other components use mutual SSL (e.g. between
SharePoint and WebSphere)
• Apply “Least Privilege principle”: only give necessary permissions to technical accounts
and not more (also apply separation of duties)
TYPICAL TECHNICAL ACCOUNTS
• Setup account
• Farm account
• Enterprise Search Service account
• Enterprise Search Default Content Access account
• User Profile Synchronization account (requires replication directory changes permission in
AD)
• SharePoint Foundation Search Service account
• SharePoint Foundation Search Crawl account
• Web Application AppPool account
• Service AppPool account
AUTHENTICATION
• Implement user authentication using FBA (requires Claims Web App)
• FBA requires membership and role providers (and optionally custom sign in page)
• For optimal security use FBA in combination with ISA, UAG, WebSeal, etc
• Configure FBA on a separate web application or as an extend on the original web app
• Security concern when using extend -> uses same application pool!
• Alternative is use web app extend but segregate anonymous and secure access using
separate VIPs in the load-balancer
WFE 1
ANON
WFE 2
ANON
WFE 3
SEC
WFE 4
SEC
APP 1 APP 2
LB LB
Anonymous users Authenticated Users
DB 1 DB 2
Scenario to segregate anonymous and authenticated users in one farm
LIFE CYCLE MANAGEMENT
• Different environments:
• Development (developer machines – virtualized)
• Test (integration testing)
• Acceptance (User Acceptance Tests / Performance Tests)
• Production
• Developers should locally test deployments including content deployment
• Test should resemble the production topology but with less servers and minor hardware
• Acceptance should be a copy of production (passive farm could be downsized if needed
since DR tests can be done and active farm is used for performance tests)
• Acceptance should ideally be accessible from the internet
Development
TestUser
Acceptance
Production
PERFORMANCE
• Internet sites can have potentially a lot of users
• Caching is very important! 5 types of caching:
• Output Page Caching (set in web.config of Web App or in Site Collection Settings)
• Blob caching (enable in web.config)
• Object caching (set object cache super user and super reader accounts as properties
of Web App)
• Code caching (developer’s responsibility)
• Browser caching (determined by IIS response header settings and blob caching
settings)
• Determine proper sizing (do performance tests as soon as possible on acceptance)
