Multi-Tenancy / Multi-Site

Topics: Administration
Nov 5, 2011 at 12:14 PM

As I understand it, the Orchard implementation of Multi-Tenancy is different from typical Multi-Site functionality, in that it allows multiple instances of orchard using one or more databases, but does not allow for comingling of data.  For example, it's not possible to allow all users to access all sites, even if each site is separately administered.   Correct?

Nov 5, 2011 at 2:49 PM

That's right. The architecture has pros and cons. The nice thing is it creates an absolute, physical partition between the data of each site. However sometimes you actually want to share data between sites and there's no model for this.

I've been wanting to put some thought into coming up with a module for this scenario, it's something I'm probably going to need quite soon.

I'll just toss some ideas around here to see if anyone has any input:

- Orchard's database technically allows multiple Site objects, since they're just a regular content type. Perhaps this feature could be (ab)used to define multiple domains, and enable each to be configured slightly differently.

- The Alias feature in development could be extended to allow per-domain aliases (solving the whole routing problem quite neatly across multiple domains)

- Combined with Vandelay Industries' Theme Picker it'd be easy to add a per-domain rule.

Any thoughts?

Nov 5, 2011 at 8:47 PM
Thanks for the reply.
I am not sure what 'per-domain' aliases is. I tend to think the best solution would be aliases that have permissions to any given set of domains.
I tend to think of domains in terms of actual customer needs: that they have sites and sub-sites, that they want to skin differently for campaigns.  Each site might show different content, or might mix content, but be skinned differently.  The same users would have access across those domains.  So maybe this is easier that I thought: domains can be members of collections. Users belong to collections of domains, and domains wear skins.
Curt




________________________________
> From: [email removed]
> To: [email removed]
> Date: Sat, 5 Nov 2011 07:49:08 -0700
> Subject: Re: Multi-Tenancy / Multi-Site [orchard:278425]
>
>
> From: randompete
>
> That's right. The architecture has pros and cons. The nice thing is it
> creates an absolute, physical partition between the data of each site.
> However sometimes you actually want to share data between sites and
> there's no model for this.
>
> I've been wanting to put some thought into coming up with a module for
> this scenario, it's something I'm probably going to need quite soon.
>
> I'll just toss some ideas around here to see if anyone has any input:
>
> - Orchard's database technically allows multiple Site objects, since
> they're just a regular content type. Perhaps this feature could be
> (ab)used to define multiple domains, and enable each to be configured
> slightly differently.
>
> - The Alias feature in development could be extended to allow
> per-domain aliases (solving the whole routing problem quite neatly
> across multiple domains)
>
> - Combined with Vandelay Industries' Theme Picker it'd be easy to add a
> per-domain rule.
>
> Any thoughts?
>
> Read the full discussion
> online<http://orchard.codeplex.com/discussions/278425#post694244>.
>
> To add a post to this discussion, reply to this email
> ([email removed]<mailto:[email removed]?subject=[orchard:278425]>)
>
> To start a new discussion for this project, email
> [email removed]<mailto:[email removed]>
>
> You are receiving this email because you subscribed to this discussion
> on CodePlex. You can
> unsubscribe<https://orchard.codeplex.com/discussions/278425/unsubscribe/>
> on CodePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any
> posts to this discussion will also be available online at CodePlex.com
Nov 8, 2011 at 5:26 PM
CurtD59 wrote:
Thanks for the reply.
I am not sure what 'per-domain' aliases is. I tend to think the best solution would be aliases that have permissions to any given set of domains.
I tend to think of domains in terms of actual customer needs: that they have sites and sub-sites, that they want to skin differently for campaigns.  Each site might show different content, or might mix content, but be skinned differently.  The same users would have access across those domains.  So maybe this is easier that I thought: domains can be members of collections. Users belong to collections of domains, and domains wear skins.
Curt


This is basically what I'm suggesting - if an alias can have a domain reference, then any number of Urls on different domains could point to the same content item (but skinned differently), and conversely the same urls on different domains can point to different content. Your registration applies across all the domains; hopefully this could work like Google where logging in once logs you in for all services.

Coordinator
Nov 8, 2011 at 6:56 PM

The main challenge in sharing data is that it involves potentially cross-database queries. I think the right approach will be in a content deployment feature that enables transfers of content rather than sharing of content, but I may be wrong.

Nov 8, 2011 at 8:23 PM
I your right for content, but I"m not sure if it's true for users. I think one login should give people access to multiple sites, even if sites are isolated. For commercial purposes as well as for community purposes.

Profile is a 'network' asset. Content is an organizational asset.

I'm thinking here about large commercial sites where geographic control may be distributed among many owners, but customers and employees may want to access multiple geographies. Or ... thinking multiple catalog brands where it is beneficial to reduce consumer access costs by allowing profile information to be shared across the network.



From: [email removed]
To: [email removed]
Date: Tue, 8 Nov 2011 11:56:17 -0800
Subject: Re: Multi-Tenancy / Multi-Site [orchard:278425]

From: bertrandleroy
The main challenge in sharing data is that it involves potentially cross-database queries. I think the right approach will be in a content deployment feature that enables transfers of content rather than sharing of content, but I may be wrong.
Read the full discussion online.
To add a post to this discussion, reply to this email (orchard@discussions.codeplex.com)
To start a new discussion for this project, email orchard@discussions.codeplex.com
You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com
Coordinator
Nov 8, 2011 at 8:44 PM

Oh, but that you can already do, by replacing the default membership.

Nov 9, 2011 at 12:57 PM
bertrandleroy wrote:

The main challenge in sharing data is that it involves potentially cross-database queries. I think the right approach will be in a content deployment feature that enables transfers of content rather than sharing of content, but I may be wrong.

What I want for certain scenarios (real use case) is the ability to, from a single admin UI, manage content on multiple domains. "Sharing data" is only one aspect of this (for instance, n-n relationships between content on different sites, i.e. a "related content" panel that might link you to content on other domains). Content deployment (I think you are basically suggesting a semi-automated import/export) would make this fairly complex and it'd introduce extra challenges, such as syncing changes between the sites. On the other hand, adapting existing systems to be able to respond to requests on multiple domains (and having the routing mechanism support this) might not actually be so tough.

Really there are three separate architectures we're talking about here. Each has their own merits for different setups:

Multi-tenancy: Completely different database per domain

Partitioned domains: User database shared between domains; each domain has a different content database (tweaked import/export supports sharing content)

Multi-domain: Single database, routing and content management are aware of domains and allow you to select both domain and url for any piece of content

Coordinator
Nov 9, 2011 at 8:50 PM

Yes, maybe we could do this by implementing a form of multi-tenancy that segregates content not in different tables or databases but with an additional column, in the same tables, within the same database. That would be an option, and the content sharing would only be available in that configuration. Something to think about for sure.

Nov 10, 2011 at 11:56 AM

That's what I'm thinking; it'd be easy to include that column in the Alias table, or it could be supported in a separate module/feature by supplementing the functionality of alias as appropriate. The big issue to overcome is allowing multiple tenants to have a list of domains they serve, rather than each being tied to a single domain.

Coordinator
Nov 10, 2011 at 7:16 PM

That's not a big issue to overcome as the code is already there ;) You can specify a comma-separated list of host names for each tenant.

Oct 30, 2012 at 4:02 PM

Has any more research/work been done on this?

I have the same requirement as randompete for Multi-domain, content sharing between sites sharing a database.

It's a bit of a show-stopper for me if Orchard can't do that...

Coordinator
Oct 31, 2012 at 6:56 PM

No change here. If you need to share data between those sites, multitenancy is not the right solution for you. There are other ways (the blogging module implements some of that with multiple blogs, and you can easily implement a theme selector).

Jan 30, 2014 at 11:53 AM
Any more news on this one? I've been trying out suggested solutions here, but they don't fully apply to my case.
Sep 15, 2014 at 8:38 AM
What about multi organizations/communities? I am OK with db separation with current multi-tenancy. However, on top of that, i need a second layer that should support different organizations/branches etc. Liferay Portal implemented this with groups (can be anything). Every table has a company is (for multi tenancy) and group id (for sub organization) so data could be context aware. I like separating companies with different dbs as in Orchard though.
Sep 21, 2014 at 8:18 PM
I also believe that multitenancy is not your solution. You have to treat tenants as different web sites.

What about using different domain names pointing on same code base?
Implement a theme selector according your domain.
And use a machine key on your web.config to have single sign on across your multiple domains.
With your machine key/sso you can have orchard running on multiple servers pointing on same database and each machine can service any of your domains.

This way you have the same code running on all of your domains with different themes/rules according the requested domain and of course keep the same database/users.
For extra control over your installation you can also use the rewrite rules module by Sebastien Ros.
Nov 11, 2014 at 10:24 AM
Has anyone achieved this? Any guidance on how this can be achieved?

Thanks & Regards,
Ajay
Developer
Nov 11, 2014 at 12:13 PM
Sharing data between tenants is possible and is not even too complicated, see: http://orcharddojo.net/blog/advanced-orchard-accessing-other-tenants-services