Tenancy Types¶
We support various Tenancy Types to decide "how" tenants will be placed and meet your custom needs:
- Dedicated tenancy: Dedicated infrastructure stack for every resource.
- Resource-shared tenancy: Shared infrastructure across tenant resources.
- Multi-tenancy: Multi-tenancy across your customers.
Now, we will dive deep into each of those Tenancy Type in detail:
Dedicated Tenancy¶
In dedicated tenancy, we create a dedicated infrastructure stack for each resource deployed in your account. This allows your tenants to customize and have infrastructure level isolation for greater security and resiliency.
Many SaaS Products like RDS, Confluent, MongoDB are offered in this model.
Here is a reference architecture, here Res refers to resource:
To configure dedicated tenancy in docker compose, you can specify the tenancy type as OMNISTRATE_DEDICATED_TENANCY in the x-omnistrate-service-plan tag. Below is an example.
Resource-shared Tenancy¶
There are times where you want dedicated tenancy with shared infrastructure across different selected resources to save on cost. One example use-case will be move all the non-critical resources on the shared infrastructure and keep critical infrastructure as dedicated.
Here is a reference architecture, here Res refers to resource:
To achieve this, you can combine multiple Container Images into one and using supervisord to manage the processes is a common approach. Here's a step-by-step guide to achieve this:
1. Create a Dockerfile
You'll need to create a new Dockerfile that will incorporate all the dependencies and scripts from your existing Container Images.
FROM ubuntu:latest # or any base image you prefer
# Install supervisor
RUN apt-get update && apt-get install -y supervisor
# Copy the scripts or binaries from your existing Container Images
COPY script1.sh /app/
COPY script2.sh /app/
# ... add more scripts as needed ...
# Copy the supervisord configuration
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
CMD ["/usr/bin/supervisord"]
2. Create a supervisord.conf
You'll need a configuration file for supervisord that specifies how each script should be run.
[supervisord]
nodaemon=true
loglevel=info
[program:script1]
command=/app/script1.sh
autostart=true
autorestart=unexpected
exitcodes=0,1
[program:script2]
command=/app/script2.sh
autostart=true
autorestart=unexpected
exitcodes=0,1
# ... add more programs as needed ...
- autorestart=unexpected ensures that if any of the processes exit unexpectedly (i.e., with an exit code not in exitcodes), supervisord will not try to restart it.
- exitcodes=0,1 specifies the expected exit codes. If a script exits with a code other than 0 or 1, supervisord will consider it unexpected and will terminate.
Multi-Tenancy¶
In this tenancy model, multiple tenants can share the underlying infrastructure to provide a cost-effective solution to your customers.
Here is a reference architecture, here Res refers to resource:
To configure multi tenancy in docker compose, first specify the tenancy type as OMNISTRATE_MULTI_TENANCY in the x-omnistrate-service-plan tag. Then configure the requests and limits for the Resources in the deploy tag. Below is an example.
x-omnistrate-service-plan:
tenancyType: 'OMNISTRATE_MULTI_TENANCY'
services:
postgres:
deploy:
resources:
limits:
cpus: '0.50'
memory: 50M
reservations:
cpus: '0.25'
memory: 20M
Please see the Kubernetes Resource Management for Pods and Containers documentation for more information regarding the configuration of requests and limits.
Resource requests and resource limits can be specified as API parameter values. x-omnistrate-compute accepts values for requests (resourceRequestMemoryAPIParam and resourceRequestCPUAPIParam) and values for limits (resourceLimitMemoryAPIParam and resourceLimitCPUAPIParam). You will also have to define corresponding API parameters. Here is an example with all values set:
services:
postgres:
x-omnistrate-compute:
resourceRequestMemoryAPIParam: resourceRequestMemory
resourceRequestCPUAPIParam: resourceRequestCPU
resourceLimitMemoryAPIParam: resourceLimitMemory
resourceLimitCPUAPIParam: resourceLimitCPU
x-omnistrate-api-params:
- key: resourceRequestMemory
name: Memory Request
description: Memory Request for the Postgres instance
type: String
modifiable: true
required: true
export: true
defaultValue: 100M
- key: resourceRequestCPU
name: CPU Request
description: CPU Request for the Postgres instance
type: String
modifiable: true
required: true
export: true
defaultValue: 100m
- key: resourceLimitMemory
name: Memory Limit
description: Memory Limit for the Postgres instance
type: String
modifiable: true
required: true
export: true
defaultValue: 2048M
- key: resourceLimitCPU
name: CPU Limit
description: CPU Limit for the Postgres instance
type: String
modifiable: true
required: true
export: true
defaultValue: "4"
Omnistrate will select the best instance type to host the service based on the CPU and Memory requirements, so that multiple instances and components of the service will coexist in the same virtual machine. When the number of service instances/tenants exceeds the supported by the provisioned infrastructure a new virtual machine will be provisioned automatically.
If you want to use a specific processor architecture you can define this on the docker compose spec platform attribute. By default Omnistrate will select instance types using X86_64 processor architecture.
Many SaaS free tier like Redis or MongoDB are offered in this model.
In-App Multi-Tenancy¶
If you have an application thats already tenant aware, that's awesome. You can combine group of tenants to form a cell for security and fault-tolerance. You can use use Omnistrate to create and manage your cells.
Basically, cell is a single application instance that supports small group of tenants.
Many SaaS Products like Hubspot, Pulley, Zendesk are offered in this model.