Compute Management¶

Omnistrate provides comprehensive compute management capabilities that abstract away cloud complexities while maintaining full control over your infrastructure. The platform manages compute resources intelligently based on your tenancy model, deployment requirements, and multi-cloud strategy.

How Omnistrate Manages Compute¶

Omnistrate's compute management is built around several key principles:

Tenant-Aware: Compute resources are allocated and managed per-tenant based on your chosen tenancy model
ACID-Compliant: All compute operations are fully ACID-compliant, ensuring no leaked resources
Versioned: All compute configurations and changes are versioned for rollback and audit capabilities
Multi-Cloud: Abstracts cloud provider differences while preserving cloud-specific optimizations
Day-2 Operations: Automates ongoing compute operations, not just initial provisioning

Compute Management by Tenancy Type¶

Dedicated Tenancy Compute Management¶

In Dedicated Tenancy (OMNISTRATE_DEDICATED_TENANCY), each tenant receives completely isolated compute infrastructure with dedicated virtual machines, storage, and network resources.

How Dedicated Compute Works¶

Infrastructure Isolation: Each tenant deployment gets its own dedicated virtual machines with no sharing at the infrastructure level. Omnistrate provisions, manages, and scales these resources independently per tenant.

Resource Allocation: Compute resources are allocated based on:

Service requirements defined in your compose specification
Customer-specific resource parameters
Performance and compliance requirements
Geographic placement preferences

Scaling Behavior: When a dedicated tenant needs more compute capacity, Omnistrate:

Provisions additional virtual machines in the same deployment cell
Configures networking and storage connectivity
Deploys and configures your service components
Updates load balancing and service discovery

Configuration Example:

x-omnistrate-service-plan:
  tenancyType: 'OMNISTRATE_DEDICATED_TENANCY'

services:
  app:
    x-omnistrate-compute:
      instanceTypes:
        - cloudProvider: aws
          name: m5.large
        - cloudProvider: gcp  
          name: n1-standard-2
        - cloudProvider: azure
          name: Standard_D2s_v3

Compute Features for Dedicated Tenancy:

Custom instance types per cloud provider
Dedicated CPU and memory allocation
Isolated storage volumes
GPU support for AI/ML workloads

Multi-Tenancy Compute Management¶

In Multi-Tenancy (OMNISTRATE_MULTI_TENANCY), multiple tenant instances share underlying compute infrastructure through intelligent bin-packing and resource optimization.

How Multi-Tenant Compute Works¶

Intelligent Bin-Packing: Omnistrate automatically places multiple tenant workloads on shared virtual machines based on:

CPU and memory requirements
Resource utilization patterns
Performance isolation requirements

Resource Isolation: While infrastructure is shared, each tenant gets:

Dedicated CPU and memory limits/requests
Isolated container runtime environments
Network-level isolation through Kubernetes namespaces
Storage isolation through persistent volume claims

Dynamic Scaling: Omnistrate continuously monitors resource utilization and:

Adds new virtual machines when capacity is exceeded
Scales down unused capacity to optimize costs
Maintains performance isolation during scaling events

Configuration Example:

x-omnistrate-service-plan:
  tenancyType: 'OMNISTRATE_MULTI_TENANCY'

services:
  app:
    platform: "linux/arm64"  # Use ARM64 for cost optimization
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
        requests:
          cpus: '0.5'
          memory: 1G

Compute Features for Multi-Tenancy:

Automatic resource optimization and bin-packing
Configurable CPU and memory limits per tenant
Shared infrastructure with logical isolation
Cost-effective resource utilization
Automatic scaling based on aggregate demand
Platform architecture support (x86_64, ARM64)

Multi-Cloud Compute Options¶

Omnistrate provides comprehensive multi-cloud compute capabilities, allowing you to deploy and manage compute resources across multiple cloud providers seamlessly.

Supported Cloud Providers¶

Amazon Web Services (AWS)

Full range of EC2 instance types
Graviton (ARM64) and Intel/AMD (x86_64) processors
GPU instances for AI/ML workloads (P3, P4, G4, etc.)
Spot instances for cost optimization
Regional deployment across all AWS regions

Google Cloud Platform (GCP)

Compute Engine instance families
Custom machine types for precise resource allocation
GPU accelerators (NVIDIA T4, V100, A100)
Preemptible instances for cost savings
Regional deployment across GCP regions

Microsoft Azure

Virtual Machine families
ARM64 and Intel/AMD processors
Azure Spot Virtual Machines
GPU-enabled instances for compute-intensive workloads
Regional deployment across Azure regions

Instance Type Selection¶

Specify compute requirements per cloud provider:

services:
  database:
    x-omnistrate-compute:
      instanceTypes:
        - cloudProvider: aws
          name: r5.xlarge      # Memory-optimized for database
        - cloudProvider: gcp
          name: n1-highmem-4   # High memory equivalent
        - cloudProvider: azure
          name: Standard_E4s_v3 # Memory-optimized equivalent

Per-cloud instance type overrides¶

When no explicit instance type is configured, Omnistrate uses your Resource's platform value and resource requests to select suitable compute for each cloud provider. For example, platform: linux/arm64 directs Omnistrate to select ARM64-compatible defaults for supported clouds.

You can override the selected instance type for each cloud provider with x-omnistrate-compute.instanceTypes:

services:
  app:
    image: ghcr.io/example/app:latest
    platform: linux/arm64
    x-omnistrate-compute:
      instanceTypes:
        - cloudProvider: aws
          name: r7g.large
        - cloudProvider: gcp
          name: t2a-standard-4
        - cloudProvider: azure
          name: Standard_E2ps_v6
    deploy:
      resources:
        requests:
          cpus: '0.5'
          memory: 1G

Explicit instance type overrides take precedence over platform-based defaults for the cloud provider where they are defined. This also allows mixed per-cloud choices, such as AWS on ARM and GCP on x86:

services:
  app:
    image: ghcr.io/example/app:latest
    platform: linux/arm64
    x-omnistrate-compute:
      instanceTypes:
        - cloudProvider: aws
          name: r7g.large      # ARM64
        - cloudProvider: gcp
          name: n2-highmem-2   # x86_64

If you select an instance type that has node-local NVMe, see Local NVMe Storage — on AWS and Azure those disks are prepared and mounted automatically, and on GCP local SSD is configured through configurationOverrides.

Instance type overrides are resource-local. Omnistrate does not inherit instanceTypes from a parent resource. In a large resource tree, add instanceTypes only to compute-backed resources that need a specific override.

If several compute-backed resources need the same selected values, define API parameters once on the parent resource and pass them to child resources with parameterDependencyMap. Each child resource still needs its own x-omnistrate-compute.instanceTypes entries that reference those API parameters.

services:
  app:
    image: omnistrate/noop
    x-omnistrate-api-params:
      - key: awsInstanceType
        description: AWS instance type
        name: AWS Instance Type
        type: String
        modifiable: false
        required: false
        export: true
        defaultValue: r7g.large
        parameterDependencyMap:
          api: awsInstanceType
          worker: awsInstanceType
      - key: gcpInstanceType
        description: GCP instance type
        name: GCP Instance Type
        type: String
        modifiable: false
        required: false
        export: true
        defaultValue: n2-highmem-2
        parameterDependencyMap:
          api: gcpInstanceType
          worker: gcpInstanceType
    depends_on:
      - api
      - worker

  api:
    image: ghcr.io/example/api:latest
    x-omnistrate-api-params:
      - key: awsInstanceType
        description: AWS instance type
        name: AWS Instance Type
        type: String
        modifiable: false
        required: true
        export: false
      - key: gcpInstanceType
        description: GCP instance type
        name: GCP Instance Type
        type: String
        modifiable: false
        required: true
        export: false
    x-omnistrate-compute:
      instanceTypes:
        - cloudProvider: aws
          apiParam: awsInstanceType
        - cloudProvider: gcp
          apiParam: gcpInstanceType

  worker:
    image: ghcr.io/example/worker:latest
    x-omnistrate-api-params:
      - key: awsInstanceType
        description: AWS instance type
        name: AWS Instance Type
        type: String
        modifiable: false
        required: true
        export: false
      - key: gcpInstanceType
        description: GCP instance type
        name: GCP Instance Type
        type: String
        modifiable: false
        required: true
        export: false
    x-omnistrate-compute:
      instanceTypes:
        - cloudProvider: aws
          apiParam: awsInstanceType
        - cloudProvider: gcp
          apiParam: gcpInstanceType

parameterDependencyMap applies only to the direct child resources listed in the map. If your dependency graph has multiple levels, map the parameter to each resource that needs the value.

When mixing architectures across clouds, publish a multi-architecture container image or ensure each selected instance type can run the container image you provide. An ARM64-only container image will not run on an x86_64 node pool, even if platform: linux/arm64 is set on the Resource.

Availability Zones and Instance Types¶

Resource capabilities determine whether the Resource uses a single availability zone (AZ), multiple AZs, or a customer-specified AZ:

Resource placement	Plan specification	Compose specification
Single AZ selected by Omnistrate	Omit `enableMultiZone` and `enableCustomZone`, or set both to `false`.	Omit both flags under `x-omnistrate-capabilities`, or set both to `false`.
Multiple AZs	`capabilities.enableMultiZone: true`	`x-omnistrate-capabilities.enableMultiZone: true`
Customer-specified AZ	`capabilities.enableCustomZone: true`	`x-omnistrate-capabilities.enableCustomZone: true`

Choose one placement mode. For custom placement, the customer supplies the AZ when creating the deployment.

Per-instance-type zone placement policy¶

For Azure AKS, set zonePlacementPolicy inside each instance type's configurationOverrides to control node-pool creation within the Resource's selected AZs. Use compute.instanceTypes in a Plan specification, including Helm Resources, or x-omnistrate-compute.instanceTypes in Compose. Direct API calls use the same zonePlacementPolicy property in the instance type configuration override.

Value	Behavior
`strict`	Default when omitted. The instance type must be available in every selected Resource AZ, and a pool is created in each AZ.
`bestEffort`	Create pools only in selected Resource AZs where this instance type is available. The type can have one pool or no pools, provided another instance type covers each remaining selected AZ.

This Plan specification fragment configures a multi-zone Resource with a strict CPU type and a best-effort GPU type:

services:
  - name: inference
    capabilities:
      enableMultiZone: true
    compute:
      instanceTypes:
        - name: Standard_D4s_v3
          cloudProvider: azure
          configurationOverrides:
            zonePlacementPolicy: strict
        - name: Standard_NC6s_v3
          cloudProvider: azure
          configurationOverrides:
            zonePlacementPolicy: bestEffort

The equivalent Compose fragment is:

services:
  inference:
    image: ghcr.io/example/inference:latest
    x-omnistrate-capabilities:
      enableMultiZone: true
    x-omnistrate-compute:
      instanceTypes:
        - name: Standard_D4s_v3
          cloudProvider: azure
          configurationOverrides:
            zonePlacementPolicy: strict
        - name: Standard_NC6s_v3
          cloudProvider: azure
          configurationOverrides:
            zonePlacementPolicy: bestEffort

You can use apiParam instead of name; the policy applies to the resolved instance type for that entry.

How Resource AZs are selected¶

During initial placement, Omnistrate considers instance type availability in the selected Azure region and the deployment cell's eligible AZs:

Configured policies	Eligible Resource AZs
All instance types are strict	The intersection of their available AZs: each type must be available in the same AZ.
Strict and best-effort types are mixed	The intersection of the strict types' available AZs. Best-effort types do not restrict this set.
All instance types are best effort	The union of their available AZs: at least one type must be available in each AZ.

Omnistrate then restricts this set to the deployment cell's eligible AZs and applies the Resource placement mode. Single-zone placement selects one eligible AZ. Multi-zone placement selects all eligible AZs and requires at least two. Custom placement validates the exact customer-specified AZ against the eligible set.

For example, suppose the CPU type is available in AZs 1, 2, and 3, and the GPU type is available only in AZ 3:

CPU policy	GPU policy	Eligible Resource AZs	Multi-zone result
`strict`	`strict`	`3`	Fails because only one AZ is eligible.
`strict`	`bestEffort`	`1`, `2`, `3`	CPU pools in all three AZs; a GPU pool only in AZ `3`.
`bestEffort`	`bestEffort`	`1`, `2`, `3`	CPU pools in all three AZs; a GPU pool only in AZ `3`.

These examples assume all three AZs are eligible for the deployment cell. Availability varies by region and Azure account; the example instance types do not imply availability in a particular region.

If a best-effort type is unavailable in every AZ, Omnistrate skips its pools. Another configured type must cover the selected Resource AZs. If that unavailable type is the only type, placement fails. A single best-effort type available in only one AZ can support a single-zone Resource, but cannot satisfy multi-zone placement.

Customer-specified AZs and subsequent operations¶

With enableCustomZone: true, placement stays in the customer's requested AZ. If two types use bestEffort and only one is available there, Omnistrate creates a pool for the available type and skips the other. If neither is available, provisioning fails. A strict type unavailable in the requested AZ also causes provisioning to fail. Omnistrate does not fall back to another AZ.

Existing Resource AZs are retained for subsequent operations. On managed Azure hosts that have not been adopted, Omnistrate checks instance availability during create, update, start, restart, and add-capacity operations. Before creating AKS pools, it validates all selected Resource AZs: every strict type must be available in each AZ, and every selected AZ must have at least one eligible pool. If validation fails, no pool creation is dispatched.

When availability metadata is missing for an instance type, that type does not restrict AZ selection and its pools retain the existing unfiltered behavior. A type with metadata reporting no available AZs is treated as unavailable. Pool cleanup continues to consider all configured types so that changes in availability do not prevent deletion of existing pools.