Print | posted on Tuesday, May 04, 2010 4:39 AM
Introduction
This second article in my Rational Guide series focuses on the capabilities in SharePoint 2010 which enable the delivery of hosting environments. Hosting is finally a first class citizen in SharePoint 2010, however there isn’t a great deal of material out there on this subject. This article will:
- Part One:
- walk through the problem space
- discuss the features of SharePoint 2010 that enable multi-tenant environments
Part Two: provide a step by step guide to setting it all up give general recommendations for those looking to deliver hosting platforms based on SharePoint 2010
Now, as much as I wanted to post this as a single article, it’s just too big. There’s too much to discuss and there’s way too much script. I’m not a fan of downloadable documents for this stuff. I am now doing this as a longer series of articles. Hopefully this makes it more easily consumable.
The articles are (links will be added as they come on line):
- Feature and Capability Overview (this article)
- Planning your Deployment
- Example Scenario and what Multi Tenancy brings to the party
- Configuring the base Infrastructure
- Configuring Partitioned Service Applications
- Provisioning Tenants
- Testing the Functionality
For those who attended my breakout session on multi-tenancy at the SharePoint Evolution conference in London during April, this article can be used as its companion.
What about the SharePoint 2010 for Hosters Guide?
This article has been sitting in draft for quite some months now, and I always intended to publish it soon after RTM as a follow up to my Evolutions session. Recently Microsoft published the SharePoint 2010 for Hosters Guide which can be downloaded from TechNet. I do urge you to check this document out but it and this article serve different purposes. This article is a “rational guide” which means I keep the chatter to a minimum and concentrate on the essential information. The Hosting Guide is a decent document, but unfortunately it suffers some flaws, namely:
- PowerShell cmdlet names are incorrect [Update, the PowerShell has now been updated for RTM]
- It’s full of marketing claptrap – about 50% of the document is a markitecture disaster
- It doesn’t cover Subscription-specific service application or proxy settings
- There’s a bunch of superfluous details which distract from the core concepts
The document has obviously been written for pre-release bits and rush published. Its value as it stands as an instructional aid is minimal. And let’s face it, what it is doing in a DOCX? That stuff should be on TechNet proper, as should the PowerShell scripts once they are corrected.
I do strongly recommend you check out the Hosting Architectures for SharePoint 2010 Poster thou – an excellent resource.
Problem Space
Definition of Multi-Tenancy
Before we dive into the details it is essential to level set and get to grips with the problem space. Multi-Tenancy is all about the isolation of data, operational services and management. We can break this down into the following aspects.
- Data
Each customer’s data should be isolated, or partitioned. We should also consider other aspects here such as where each customer’s data is physically backed up. - Usage
We are talking about the functionality on offer, the services and data that is exposed to end users. - Administration
How sites and data are administered, how services are administered and how customisations are managed. - Customisations
We need to ensure that Customer A’s customisation isn’t shown to Customer B. - Operations
We need to be able to report on usage, audit usage, and perhaps most importantly, charge for usage.
So what is Multi-Tenancy? In a word, it’s Hosting! A unique deployment for each customer on a shared set of infrastructure resources. The most common scenarios are
- “Traditional” Web Hosting Environments
- SharePoint Online
- Corporate On Premise Deployments
The last one here is interesting, there are a number of aspects which we will cover later which make multi-tenant an often requested and compelling deployment approach for large corporate on premise deployments.
A good analogy here is a flat or apartment building. In this real world case, multiple tenants share the same infrastructure (the building, the doors etc). In addition some services are shared but have no data (entry phone, refuse collection). Some other services are shared (electricity, telephone) and have data which should be partitioned (meter readings, billing). Some other services are a free for all (car parking).
Multi-Tenancy in SharePoint 2010
We had a bunch of problems with doing multi-tenancy in SharePoint 2007. Inherent limitations with Web Applications meant that true isolation wasn’t possible, and Site Collections couldn’t provide consistent management capabilities. Furthermore URL namespaces could not be constructed in a manner suitable for multi-tenancy. Probably the biggest problem though was with shared services, which were simply not designed with hosting in mind. Whatever services were offered by a SSP were consumed by all associated web applications and we only had very limited ability to delegate control. Managing customisations also was pretty much impossible as any changes were reflected across all customers.
Goals for SharePoint 2010
The core goal was to make hosting a first class citizen in SharePoint 2010. That is to deliver features to make the operational service management of SharePoint easier for one or more divisions, organisations, or companies. Some of the things needed were:
- Less hardware
- More centralised control over hardware and data storage
- Simplified management and scripting capability
- Support “chargeback”
- Auditing and Reporting
- Block setup of rogue “under the desk” deployments
Now this is probably the most important thing to take away from the discussion before moving into how we set it all up. Multi-Tenancy in SharePoint 2010 isn’t a “feature” that lights up. It’s a combination of many things which all together enable the scenario we are interested in. The new Service Application model and Claims authentication are two of the most obvious, but don’t forget that improvements to other areas (e.g. Host named site collections) also have a significant role. Like many things in SharePoint, it’s a grab bag of capabilities, that when used together, enable the scenario. This once more, underlines SharePoint’s architectural superiority as a platform, rather than a point solution.
Multi-Tenancy in SharePoint 2010
Let’s take a simple scenario, such as that depicted below.
Here we have a single Web Application which hosts five Site Collections. Customer 1 has three site collections, and Customer 2 has two. We then also have a Service Application for which the data for each customer is partitioned. This is the essence of multi-tenancy in SharePoint 2010.
Member Sites
Member Sites are simply Site Collections. Of course in a multi-tenant scenario the site collection is associated with a tenant or customer, and therefore we use the term Member Site. We have a couple of options as to where we can host the member site.
We could give every tenant a Web Application, this allows us to have a separate web.config for each tenant, but Web Applications limit our scalability and introduce significant overhead. There are cases where this is the right approach but you must consider this very carefully.
The alternative is to host member sites within a single web application – as per the diagram above. We can scale this easily and very far indeed. The downside of course is that they will share a web.config.
Host header Site Collections
Host header site collections have been around for a while now. It used to be called Scalable Hosting Mode when it wasn’t anything of the sort back in 2003. It’s been improved significantly in SharePoint 2010 and is a key piece of the puzzle. Host header site collections allow us to have multiple root level sites with independent top level domain names in the same Web Application. In SharePoint 2010 we can now also use them in combination with Managed Paths and furthermore they now work properly when terminating SSL on an external device such as a load balancer. All of these improvements together mean we can now deliver a consistent URL namespace. We can also “mix ‘n’ match” our URL namepaces within a single web application to suit even the most vain tenants!
Hybrid Hosting Approaches
It is important to note at this point that we can mix and match different hosting approaches within the same farm to deliver a range of service offerings. We don’t need to build out separate farms to meet different requirements. That’s not to say we should avoid multiple farms, but as one of the high level goals here is a reduction of infrastructure assets, co-locating service offerings can be compelling. Take a look at this excerpt from the Microsoft hosting poster which shows a hybrid of regular Web Apps for particular purposes.
And now focus in on Company E, for whom we are using host named site collections and managed paths to deliver their requirements.
Site Subscriptions
At the core of multi-tenancy is Site Subscriptions. A site subscription is a logical group of site collections that can share settings, features, and service data.
Site collections for each tenant are grouped together with a Subscription ID. The subscription ID is used to map features, services, and sites to tenants and also to partition service data according to tenant.
The Subscription Settings service application is responsible for keeping track of multi-tenant services and subscription IDs.
So you can think of a Site Subscription as essentially just an ID that identifies a subscription, it is more than that but the concept is simple. A Site Subscription can only be created by PowerShell or the SharePoint object model. Once a subscription is created, member sites can then be added to the subscription. It’s worth noting that once a member site is added to a site subscription it cannot be changed.
All member sites in a subscription can then be managed from a common site called the Tenant Administration Site.
Member Sites in the same subscription can span Web Applications, but this is not recommended as that increases the management overhead and could lead to data leakage.
Service Application Partitioning
Service applications can be configured to partition data. That is, to use the same instance (database) to serve multiple tenants.
Both the service application and proxy must be configured and this again is only possible via PowerShell or the object model. With PowerShell the –partitionmode flag is used.
Note that the Word Automation Services Service App allows you set to partition mode on creation through the UI - perhaps they didn't get the memo!
It is important to note that the mode of a service application or proxy cannot be changed after deployment. We can’t go from un-partitioned mode to partitioned mode or vice versa. So don’t be using the Farm Configuration Wizard (not that you should be thinking of doing that anyways!)
Service applications and proxies can have subscription specific values. For example the Managed Metadata service content type hub value. Once the service application or proxy is deployed in partition mode, those settings are no longer exposed in Central Administration as having a “global” setting no longer makes any sense. These properties can only be configured again using PowerShell or the Object Model.
Services that do not store data do not need to be partitioned. However it is a good idea to partition them anyway especially in external hosting environments in order to support isolated reporting and diagnostics.
However, this recommendation kinda falls down. If you check out the Hosting guide or the poster the list of Partitionable Service Applications is incorrect.
The list of service apps that are actually tenant aware in SharePoint RTM is
The following services can be partitioned and can store Tenant Data:
- Subscription Settings (not actually partitioned)
- User Profiles
- Managed Metadata
- Business Data Connectivity
- Search
- Secure Store
- Word Automation
- Project
The following services do not store tenant data, and do not support Partition Mode:
- State
- Access Database
- Visio Graphics
- Word Viewing
- PowerPoint
- Excel Calculation
The following services cannot be partitioned and could store tenant data:
- Web Analytics (this one is site collection based, so it's not a big deal)
- Usage and Health Data Collection (as above)
The following services cannot be partitioned and don’t make sense in multi tenant deployments:
- PerformancePoint
- FAST for SharePoint
Feature Packs
Feature Packs are groups of features that are enabled by an administrator for tenants to activate and use. They are groups of Site and Web scoped features. Once again we can configure these only via PowerShell or the object model.
Site Templates that depend on features that are not activated for a given subscription will be trimmed from the UI. Site Templates further filter non dependant features that are not activated.
Feature packs are very useful for delivering different SLAs. For example we can charge more for tenants that make use of cool features such as BI. We can also lock down suspicious tenants to a limited set of functionality. We can also make use of feature packs to evaluate dodgy ISV solutions assuming they use the features and solutions framework in the first place!
The Hosting Guide provides sample PowerShell scripts which define feature packs that correspond to the different core SharePoint Server SKUs (Enterprise CAL, Standard CAL and SharePoint Foundation). Thus it is possible to host multiple licensing standards on the same farm, one of the most common enterprise requests.
We can of course create our own custom Feature sets as we see fit.
Tenant Administration
Tenant administrators can manage the configuration of farm administrator delegated features and can manage all sites for their subscription from a single place, the tenant administration site. This site is a “hidden” site template. We create the site and associate it with a subscription. This site, just like Central Administration is fully extensible.
From tenant administration new site collections can be created, but it is important to note that this requires that Self Service Site Creation is enabled for the Web Application. Self Service site creation is web application scoped, which means all tenants within a web application can create sites when this is enabled.
Customisations
Many of the same challenges from SharePoint 2007 remain consistent. If we are dealing with fully trusted code we have the same headaches as before. However SharePoint 2010 introduces Sandbox Solutions which allows Site Collection administrators to deploy code that runs in isolation and on specific servers in a farm. Administrators have control over resource usage and can isolate the farm from defective custom code. Sandbox Solutions are badly understood and unfairly maligned by developers thus far. Whilst they are beyond the scope of this article one thing is for sure, true multi-tenancy without sandbox solutions would not be possible.
That’s wraps it up for Part One, which gives an overview of the problem space and explores the core capabilities in SharePoint 2010 for multi-tenancy. In Part Two I will look at configuring multi-tenancy and provide some general recommendations. Part two will be published directly here and will be announced on my main blog page. Stay tuned!
Part Two is here.