Skip to content
This repository has been archived by the owner on Dec 20, 2024. It is now read-only.

Multi Tenant Operation

JoeWinter edited this page Mar 23, 2015 · 3 revisions

[Table of Contents](https://github.com/dell-oss/Doradus/wiki/Doradus Administration: Table-of-Contents) | [Previous](https://github.com/dell-oss/Doradus/wiki/Single Tenant Operation) | [Next](https://github.com/dell-oss/Doradus/wiki/Managing Tenants)
[Multi-Tenant Configuration](https://github.com/dell-oss/Doradus/wiki/Multi-Tenant Configuration): Multi Tenant Operation


Multi-tenant operation is enabled by setting `multitenant_mode` to `true`. Multi-tenant mode requires the use of the CQL API, hence `use_cql` must also be set to `true`, and `dbport` should be set to Cassandra’s CQL port. Finally, multi-tenant mode requires Cassandra to enforce user ID/password authentication, and Doradus must be configured to use a super user. Therefore, enabling multi-tenant mode requires setting all of the following doradus.yaml options:
multitenant_mode: true
use_cql: true
dbport: 9042
dbuser: cassandra
dbpassword: cassandra

As described in the previous section, you can pass dbhost and dbpassword as runtime arguments to prevent storing them in the doradus.yaml file.

When multi-tenant mode is enabled, all application-specific REST commands that do not identify a specific tenant are directed to the default tenant. Such commands do not require tenant credentials, hence the default tenant can be considered a "public" tenant. You can disable the default tenant by setting the following doradus.yaml option:

disable_default_keyspace: true

When this option is set, all application-specific REST commands must be directed to a specific tenant and provide valid credentials for that tenant.

When a new tenant is defined, Doradus creates the corresponding Cassandra keyspace using the following doradus.yaml file options as a template:

ks_defaults:
    - strategy_class: SimpleStrategy
    - strategy_options:
        - replication_factor: "1"
    - durable_writes: true

This options can be changed to use different defaults for new keyspaces. In a multi-node cluster, replication_factor should be increased to ensure data availability in case of a node failure. Note a tenant can be creating while overriding some of these default keyspace options.

Clone this wiki locally