Multi-tenancy18.104.22.168.4SaaS Important: This document details the multi-tenant (MT) features for Alfresco ECM. These features are currently available both in the latest Enterprise and Community releases. As always, any and all feedback is welcome via Alfresco Support and/or the community forums.
By default, Alfresco supports a single-instance single-tenant (ST) environment where each tenant (such as customer, company, or organisation) will run a single instance that is installed on one server or across a cluster of servers.
Theoretically, it may also be possible to run multiple instances of Alfresco on the same development server by configuring separate database schemas (with the DB on a separate server), separate content stores, separate (non-conflicting) ports, etc. However, this adds additional complexity in terms of configuration and upgrades, and some functionality may not work independently for both instances. Hence this is not recommended or supported in a production environment.
What is Alfresco Multi-tenancy?
The Multi-tenancy (MT) features enable Alfresco ECM to be configured as a true single-instance multi-tenant environment. This enables multiple independent tenants to be hosted on a single instance, which can be installed either on a single server or across a cluster of servers. The Alfresco instance is logically partitioned such that it will appear to each tenant that they are accessing a completely separate instance of Alfresco.
The features include:
Tenant content routing
We recommend that you download the latest Alfresco Enterprise release, available from Alfresco Support.
Enabling MT on latest releases (HEAD / 4.0.2 or later)
In the latest Alfresco Community (HEAD) or Alfresco Enterprise (4.0.2 or later) the multi-tenancy feature is pre-configured out-of-the-box, although it is not enabled by default. It will be auto-enabled if and when you create your first tenant.
Enabling MT on earlier releases (4.0.d / 4.0.1 or earlier)
If you wish to use Alfresco multi-tenancy with earlier releases of Alfresco Community (4.0.d or earlier) or Alfresco Enterprise (4.0.1 or earlier) then it is necessary to configure a multi-tenant environment by download, copying and renaming the three sample MT extension files and then restarting Alfresco.
1. Rename the following three sample MT extension files:
Upgrading MT to latest releases (HEAD / 4.0.2 or later)
If upgrading to the latest Alfresco Community (HEAD) or Alfresco Enterprise (4.0.2 or higher) you *must* first delete your existing MT sample extension files. It is also recommended that you backup your existing copies first. For example:
1. Backup the following three existing MT extension files:
Important All three files must be renamed to enable MT. If you have downloaded the tomcat bundle, these can be found under .../tomcat/shared/classes/...
3. Restart Alfresco
The super 'admin' (default Alfresco 'admin' user) has access to the default environment. This admin can be considered as super-admin. Tenants can be administered by the super 'admin' using the Tenant Admin Console.
To disable a tenant and prevent tenant logins, type:
disable <tenant domain>
Export/Import of a Space
A tenant admin can use the Web Client Admin UI to export/import spaces.
Export/Import of a Tenant
The existing 'repository export' feature can be used to export a tenant.
Note: In general, 'repository export' does not apply to certain areas, such as in-flight workflows. Also, the 'repository import' must be into the same version of Alfresco (from which the export was performed).
A tenant can be exported by the super admin using the 'export' command from the Tenant console. To export a tenant to a set of repository export files, the super admin should type:
export <tenant domain> <destination directory>
Alternatively, a tenant admin can also export the tenant using the Web Client Admin UI.
A tenant can be imported by the super admin using the 'import' command from the Tenant console. To import a tenant from an existing set of repository export files, the super admin should type:
Note: If an existing tenant needs to be re-imported, the tenant must be deleted first. Currently, in order to cleanly delete a tenant, the server must be restarted to clear the index threads. The tenant-specific index directories and tenant-specific content directories should also be manually deleted before starting the import.
Tenant Console Help (Example)
For more details on each command, refer to the Tenant Console help. Here's a snapshot:
## ## Meta commands ##
List this help.
Repeat last command.
## ## Tenant Commands - for administering tenants ##
ok> show tenants
List all tenants and show their details.
ok> show tenant <tenant domain>
Show tenant details - status (ie. whether enabled or disabled) and root contentstore directory.
Create empty tenant. By default the tenant will be enabled. It will have an admin user called 'admin@<tenant domain>' with supplied admin password. All users that the admin creates, will login using '<username>@<tenant domain>'. The root of the contentstore directory can be optionally specified, otherwise it will default to the repository default root contentstore (as specified by the dir.contentstore property). The default workflows will also be bootstrapped.
Once a tenant is created and enabled, then the tenant admin can log in to the Alfresco Web Client and access the Administration Console within the context of their tenant domain. If for example, a tenant/organisation called 'acme' is created, the tenant admin can log in as 'admin@acme' and create users such as 'alice@acme', 'bob@acme', 'eve@acme'.
The admin features currently available to the tenant admin include:
Users will authenticate using their fully-qualified userid (such as 'alice@acme').
tenant 'guest' authentication is allowed, but must be within the context of a tenant (such as 'guest@acme')
tenant-specific Web Scripts held in the repository will always require authentication (ie. web script description document requires <authentication> setting which should not be 'none')
CIFS is not currently supported
Tenant Content Routing
The super 'admin' will typically create tenants, such that the physical content for each tenant is stored on a separate root directory (possibly a separate mounted drive). This also allows accurate physical disk usage to be derived by measuring the disk used at the root location.
If no root directory is supplied when creating the tenant, the default root directory is used to store content for multiple tenants (in addition to any 'default' content). In this case, the content will be intermingled which may not be desirable.
Backup and Restore
Since all tenants share the same database schema, the steps for a cold backup and restore are similar to the simple backup process. The steps also must take the use of tenant-based Content Routing (if applicable)into account. For example:
Stop the application server (ensures no one can make changes while backing up or restoring.
Export the database to Alfresco dir.root.
If dir.root has enough space, copy each of the Tenant Root directories under dir.root/<tenantid>(or back them up separately).
Back up the entire Alfresco dir.root.
Start the application server.
Stop the application server.
Copy the existing dir.root to a temp location.
Copy each of the existing Tenant Root directories to a temp location.
Restore the dir.root.
Copy each dir.root/<tenantid> to their respective Tenant Root directories.
Import the database from dir.root.
Start the application server.
To implement MT, the Alfresco ECM has been logically partitioned such that each tenant has access to their own set of tenant-specific stores. These stores are typically routed to their own physical root directory. Also, if using Lucene (Alfresco 3.4.x or Alfresco 4.0.x configured for 'lucene' search subsystem) then the Lucene index files are partitioned, since Alfresco maintains a Lucene index per store.
All ECM-related services are partitioned including node services, security services, workflow services, search/index services, dictionary services etc. Also, in order to support MT Alfresco Share, additional partitioned services include site services, activity services, invite services, avm services etc.
The meta-data is logically partitioned within the DB schema.
If you wish to support a large number of tenants (eg. > 99) then you will need to review and increase the cache size for all of the tenant caches, that are by default configured to 100 (including the default domain). Please refer to:
Tenant-based caches currently include:
Alfresco supports the ability to pre-package AMPs (Alfresco Module Packages) into the Alfresco WAR which will be installed into the default domain on startup. In a multi-tenant environment, the module will also be installed into each tenant domain when the tenant is created or imported. Note: As of Alfresco 4.2d, the functionality of a AMP may still apply to tenants depending on the implementation, but ModuleComponents will not be installed into each tenant domain. See ALF-19207
Currently, the only authentication method supported is 'alfresco'.
The following are not supported/implemented/tested in a multi-tenant enterprise environment.