OpenKM is normally configured as a single-instance single-tenant (ST) environment where the tenant (who owns the instance) will run a single instance that is installed on one server or across a cluster of them.
It may also be possible to run multiple OpenKM instances (Multitenant) on the same server; it will allow the instance owners to store different content and create personalized client environments. Some advantages are:
Multi-tenancy enables multiple independent tenants to be hosted on a single instance, 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.