Answered What Does Multi-Tenancy Actually Provide?

  • Saturday, May 29, 2010 8:14 AM
     
     

    Hi Folks

    We have a number of WSS sites that we host for customers using host header based sites. We have been testing SharePoint Foundation 2010 and the multi tenancy features. We are struggling to understand exactly what benefits this would provide our existing user base as opposed to what they have today already apart from the new functionality and new interface. We have looked at the tenancy admin site and it doesn't look like you can do much from here apart from create new sites and change site quotas, each of these we would not want customers to do and this would surely be difficult to track from a commercial and resource perspective. We would rely on our third party control panel for this.

    Can someone give me a easy to understand explanation of what exactly multi tenancy can provide to an everyday SharePoint WSS user after we upgrade them?

    At the moment we cant see a good reason to implement multi tenancy and move away from our existing model. We can however see how this opens the doors to providing SharePoint Server 2010 on a shared platform as this historically has been hard to do.

    Any input would be greatly appreciated, I am probably just missing the point somewhere!

    Thanks

    Adam

Answers

All Replies

  • Sunday, May 30, 2010 6:51 PM
     
     Answered

    Have you seen this article?

      http://blogs.msdn.com/b/russmax/archive/2010/04/02/sharepoint-2010-multi-tenant-hosting-part-1.aspx

      http://blogs.msdn.com/b/russmax/archive/2010/04/03/sharepoint-2010-multi-tenant-hosting-part-2-configuring.aspx

    It provides a good overview.

     

    Some of the key benefits of multi tenancy are:

    • The "tenant" can be at the site collection level instead of the application level (your reference to host headers implies you are setting up one application per customer) - big difference in administration work
    • The service applications can keep each tenant's data separate (for a project I use a cheap-o WSS hosting search that has disabled Search for this reason)
    • Better Feature management (one tenant see a different list of available features then others do)

    Mike Smith TechTrainingNotes.blogspot.com
  • Monday, May 31, 2010 9:52 AM
     
     

    Thanks Mike.

    Could I ask you to expand on a couple of the points in your post.

    Point 1 - What specifically is different in regard to administration? We currently run STSADM to create host header based sites per customer.

    Point 2 - Not sure I understand what you mean by this. We have search running today and the search only returns what is in the customers site collection. Could you please elaborate

    Point 3 - I see. So I could deploy a SP solution at the farm level and only scope this to the site collection or several site collection if required, as opposed to an all or nothing?

    appreciate your help

    Adam

  • Monday, June 21, 2010 1:34 PM
     
     Answered

    check out

    http://www.harbar.net/articles/sp2010mt3.aspx

    for a walk through of the scenarios

     

    1. Host headers now support managed paths and SSL termination

    2. It now works across site collections

    3. feature packs allow you to tie features to a site subscription

     


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2007
  • Tuesday, January 25, 2011 7:41 PM
     
     

    Hi everyone. I have a few questions on the topic that I'm just going to attach to this conversation.

    First, I have read through all the materials linked above and some others on Technet, so I am familiar with all the concepts. My questions are regarding practicality and software boundaries.

    I am relatively new to my company and we have over 200 hosted clients. Currently, each client has their own dedicated environment - SQL, WFE, Central Admin, etc. Obviously this is not ideal and we are using up way too many resources to support that architecture. So we are going to implement a new SP 2010 farm to move our clients to.

    From the information I've read, it seems the multi-tenancy features are best used in a single company structure where Company A has multiple departments they would like to segment - HR, Finance, Operations, etc. We are looking at things more from a multiple company standpoint. So our biggest decision point is:

    1 Web Application for each client (company) or 1 Site Collection for each client

    Each of our clients use their own DNS:

    www.company1.com

    www.company2.com

    ....etc

    I read where hosted site collections will support this structure, but there are some managed path limitations.

    So I'm looking for feedback on the Web App/Site Collection decision point. Any horror stories, recommendations, etc?

    Are there any software boundaries that should be taken into account?

    At my last company we had WSS 2.0 and WSS 3.0 hosting and we had 1 web application for each client and it worked well. So I'm just struggling with the benefits of the new features. Like Adam42, our clients wouldn't be allowed to use the Tenet administrator and we do all the administration for them. If anyone has any input on what I might be missing here, it would be greatly appreciated.

    Thanks!

  • Tuesday, January 25, 2011 8:29 PM
     
     

    you definatley need to look at host named site collections for this scenario.

    It's not host named site collections that have managed path limitations, it's using web apps per customer.

    Please review http://www.harbar.net/articles/sp2010mt2.aspx for details on this.


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2010
    Microsoft Certified Master | SharePoint 2007
  • Tuesday, January 25, 2011 9:08 PM
     
     

    We just went ahead and used the exact same model as we did with WSS3.0. We use host header based sites for each customer and have one web application hosting these. We didn't see any benefit of changing the way we operated.

    The only addition we added to our services was WSP as our control panel (DNP) which has a SharePoint 2010 Enterprise Module as well as others. This will allow user management but the site admin still has to add new accounts to the site via people and groups manually for some reason.

    I would of thought you would of hit resource issues on your servers if you created lots of web apps, I seem to recall there being a theoretical  limit of about 10 web apps per server for WSS3.0 until you started seeing performance issues. The idea of host based header sites is to reduce the number of web apps required.

    HTH

    Adam

  • Tuesday, January 25, 2011 9:13 PM
     
     

    Thanks guys, just the confirmation I was looking for.

    Adam, you mentioned "WSP as our control panel (DNP) which has a SharePoint 2010 Enterprise Module" what were you referring to, is that a 3rd party solution of some sort?

  • Tuesday, January 25, 2011 9:58 PM
     
     

    WSP - WebsitePanel, it's a windows hosting control panel which is Open Source, used to be know as DotNet Panel (DNP). 

    http://www.websitepanel.net/

    I'm not sure how development will progress with this so we are watching closely, we may decide to move to another provider. It's quite limited in what it can do from an Exchange, SharePoint, CRM, OCS perspective but hey it's free! I believe its strengths are mainly in the web hosting side of things but that is not what we use it for.

    Adam

     

     

  • Thursday, January 27, 2011 12:30 AM
     
     

    Thanks Adam.

    Now I'm looking for a more complete guide to installing service applications in a farm environment. Spencer, I saw your blog posts and while it has most everything I'm looking for, it doesn't have everything. Do either of you know where I could find a complete farm configuration guide for a multi-tenant environment?

    Thanks!

  • Thursday, January 27, 2011 1:27 PM
     
     

    Joe,

    What exactly are you looking for that my scripts don't cover?

    s.


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2010
    Microsoft Certified Master | SharePoint 2007
  • Thursday, January 27, 2011 5:20 PM
     
     

    I'm looking for info specifically on farms. We want to setup multiple server groups for:

    1. Partioned Services
    2. Un-Partitioned Services
    3. Search Service
    4. Web Front Ends
    5. Content DB
    6. Search DB
    7. Service Apps DB

    Based on all the topology docs I've read from Microsoft there are ways to setup a multi-tenant farm so that there are multiple servers in a group servicing the specific functions listed above. For the Service Applications we want to segment them into the 3 groups listed above with 2 servers per group to start with. So I'm looking for examples on how to group them in this manner and how that might change the powershell commands you have in your blog. With the DB's how is the same accomplished? Do we setup 1 big cluster with 6 servers and just have 3 separate instances for each DB group or do we setup 3 separate clusters or is there another way to do this? Our goal is to have the groups above be segmeneted so that if say Search needs more resources we can add another server to the farm that is specifically servicing the search service.

    I might be thinking about this all wrong, don't know. So I was just looking for some info on how to segment these groups properly and some examples of how you might do this in powershell. Sorry if that's already in your blog and I missed it. You've been very helpful already, thank you!

  • Thursday, January 27, 2011 5:31 PM
     
     

    Server Groups are an entirely logical concept. There is nothing in the product that enables you to configure them. How you deploy the idea is entirely up to how you deploy service instances and deal with request routing. Additionally server groups have no relationship with multi-tenancy.

    Server Groups have no impact on the creation of service applications, other than specifying of the service instance(s) location. There is no different powershell for this - it's just the same as starting any other service instance.

    TechNet's farm design and topology guidance provides detailed information on farm topology design, including the concept of server groups.

     


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2010
    Microsoft Certified Master | SharePoint 2007
  • Thursday, January 27, 2011 7:10 PM
     
     

    Thanks. Yea the Technet design is what I'm reading through now and the SharePoint 2010 for Hosters whitepaper. It's just really confusing trying to sift through the Microsoft marketing BS, like it says "In large environments, an entire enterprise services farm - which is a farm that hosts the most commonly used cross farm services - can be deployed. A dedicated Search farm, which is a farm that is optimized to provide search, can also be implemented." Ok great, so how exactly do I do this? That's that stuff I'm struggling with, getting from the concept to exactly how I go about implementing this.

    You said "the idea is entirely how you deploy service instances and deal with request routing." Could you dive into that a bit more, is there any further practical details you can provide?

    Thanks again, you have been very helpful.

  • Thursday, January 27, 2011 7:33 PM
     
     

    Enterprise Services Farms, publishing service apps and dedicated search farms are all fully documented on technet. Fundamentally building a services farm is no different from any other, and is just a question of which service applications are present. The real question here is "is it necceassary for a given set of requirements?"

    No comment on the marketing BS :)

    Getting back to the idea of server groups...

    Let's say you want a server group for Search. There's nothing special to be done here. You design and deploy the search topology on a given number of servers. Should you need to scale search you add more servers into the mix. Within the rest of the farm, how consumers speak to the search SA is all handled by the Topology service which is on every machine in the farm. Again, it's entirely a logical thing, i.e. how you seperate roles within the farm. the boxes in the search group would commonly be a different spec (more ram) than the boxes serving end users.

    You might also have a server group for hosting Office Web Apps, again once the service instances are deployed, the topology service on the other boxes deals with routing requests to the appropriate machine(s).

    Another exmaple is a dedicated crawl front end group. this is machines that host the web applications, but which are only used by the search crawler, i.e. they are not accessed by end users. Say you have two machines in that group. Again there is no special configuration here - you configure them to run the SPF Web application service instance and load balance them. the trick here is to make the crawler use them instead of other web servers in the farm. this is accomplished by simple DNS or host file entries on the machines running the crawler. In other words you are configuring things outside of sharepoint to get the end results you are after.

     


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2010
    Microsoft Certified Master | SharePoint 2007
  • Friday, June 03, 2011 1:41 AM
     
     
    I was told by someone putting up a large server farm for the government that Fast Search was not supported in multitenant deployments, and I have seen references to support that limitation (such as this document from Microsoft http://tinyurl.com/67aokxb). Has anyone had a successful implementation of Fast Search with a multi tenant system?