Normally OpenKM is configured like a single-instance single-tenant (ST) environment where each tenant (Instance owner) will run a single instance that is installed on one server or across a cluster of them.
Although it may also be possible to run multiple OpenKM instances on the same server, separating content stores and creating a personalized clients environments. Some advantages are:
The Multi-tenancy 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 them. The main instance is logically partitioned such that it will appear to each tenant that they are accessing a completely separate instance of OpenKM.
The super user 'okmAdmin' has access to complete environment. Tenants will be administered by the super 'okmAdmin' using the Tenant Admin Console.
Once a tenant is created and enabled, then the tenant admin can log in to the OpenKM instance and access the Administration area within the context of their tenant domain. If for example, a tenant/organisation called 'OKM' is created, the tenant admin can log in as 'admin@OKM' and create users such as 'joe@OKM', 'ralph@OKM'.
It provides tenants the ability to customize their OpenKM environment, including models, workflows and web client UI.
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.
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.