Choosing your ITRS Analytics deployment

This guide helps you choose how to deploy ITRS Analytics based on what matters most to your organization, including where the platform is hosted, who operates it, resiliency, and backup capabilities. It also explains the trade-offs associated with each option. Your choice of deployment model directly affects high availability, operational continuity, and your ability to meet uptime and compliance requirements.

Use the steps below to align your deployment with your organization’s requirements.

Identify your business requirements Copied

Before choosing a deployment model, first define your organization’s requirements. Consider the following:

• Data residency — Where must your data be stored? Is an AWS region acceptable, or must it remain on-premises or within a private cloud?
• Operational ownership — Who will operate the platform? Should ITRS manage the infrastructure and operations, or will your team be responsible for running it?
• Availability and resilience — Do you require production-grade high availability or backup and restore capabilities, or is a simpler setup sufficient for evaluation purposes?
• Kubernetes environment — Do you already have a Kubernetes platform or team in place (for example, EKS, AKS, GKE, OpenShift, or a self-hosted Kubernetes cluster)?
• Compliance requirements — Are there compliance, audit, or data retention requirements that influence where or how the platform must run?
• Cost model preference — Do you prefer a predictable managed bundle (software and hosting) or a software-only model using your own infrastructure?

Choose between SaaS and Self-hosted Copied

Your first decision is whether ITRS manages the platform for you (SaaS) or your organization operates it on your own infrastructure (self-hosted). This choice determines who is responsible for running, maintaining, and securing the platform, as well as where the system is hosted.

Expand table

When to choose SaaS Copied

Choose SaaS when:

• You want ITRS to manage platform operations, upgrades, and infrastructure health.
• Your team does not have dedicated Kubernetes or cloud operations expertise.
• You require a predictable, fully managed cost model that bundles software and hosting.
• Data residency requirements can be met by an available AWS region.
• You need enterprise-grade high availability across two availability zones without managing the underlying infrastructure yourself.

When to choose Self-hosted Copied

Choose self-hosted when:

• Your organization requires data to remain within a specific on-premises environment or private cloud that is not covered by SaaS regional options.
• You have an existing Kubernetes operations team capable of managing platform lifecycle.
• Your organization’s procurement, security, or compliance policies require full infrastructure ownership.
• You need to integrate ITRS Analytics into an existing internal platform ecosystem (networking, security tooling, storage, observability pipelines).

Note

With self-hosted deployments, your internal teams are responsible for patching, upgrades, backup management, and maintaining infrastructure resiliency. Ensure you have the appropriate platform expertise before selecting this model.

If your requirements point to self-hosted, the next step is how you run Kubernetes.

Key resiliency concepts Copied

When planning your ITRS Analytics deployment, these fundamental concepts work together to define the platform’s operational characteristics.

High availability (HA) Copied

High availability ensures that your observability platform continues to operate without interruption, even if individual components fail. This is achieved by deploying redundant services, load balancers, and failover mechanisms so that if one workload becomes unavailable, another seamlessly takes over.

Key characteristics:

• Both BYOC and Embedded Cluster support full high availability.
• In multi-node deployments, no node should have a round-trip time (RTT) greater than 10 ms to any other node in the Kubernetes cluster.
  • The key difference is recovery: BYOC provides automatic recovery — when a node or workload fails, Kubernetes reschedules pods and services continue with minimal downtime.
  • Embedded Cluster requires manual recovery — when a node fails, workloads cannot auto-reschedule and must wait for the node to return or for manual restoration.

Continuous operations Copied

Continuous operations means the platform keeps running during localized failures (pod or node outages) within a single cluster.

Important

ITRS Analytics does not provide built-in cross-site or cross-region disaster recovery. For protection against data center or regional failures, you must run multiple independent deployments and implement your own DR strategy (sync, failover, runbooks).

Deploy Kubernetes in a Self-hosted environment Copied

ITRS Analytics is built on a Kubernetes-native architecture, designed for continuous high availability, scalable deployments, and resilient operations. If you select self-hosted, you must then choose how Kubernetes is provisioned: either by Bring Your Own (Kubernetes) Cluster (BYOC) or by using ITRS’s bundled Kubernetes distribution (Embedded Cluster).

Note

Bring Your Own (Kubernetes) Cluster (BYOC) is the recommended deployment model for production. It provides automatic recovery when nodes or workloads fail: Kubernetes can reschedule pods and move storage so services keep running with minimal downtime.

Embedded Cluster supports full high availability but requires manual recovery when nodes fail; workloads cannot auto-reschedule and must wait for the node to return or be restored. Choose Embedded Cluster for production environments where Kubernetes expertise is not available.

Designing a resilient ITRS Analytics deployment Copied

• Select BYOC when enterprise high availability with automatic recovery, backup and restore, standard security tooling integration, and predictable scaling are required.
• Select Embedded Cluster for production environments where Kubernetes expertise is unavailable; note that HA is fully supported but recovery from node failures is manual.

Expand table

The following scenarios illustrate how the choice between BYOC and Embedded Cluster plays out in practice across key operational areas: load balancing, storage scalability, recovery behaviour, security, and team responsibilities.

Ensuring resilient access with load balancers Copied

Scenario: Your organization runs multiple ITRS Analytics ingestion services and UIs that must remain accessible even during high traffic spikes.

In a Bring Your Own Cluster environment, especially in cloud-based setups, a load balancer is typically readily available and integrates seamlessly with Kubernetes. It distributes traffic across multiple service replicas and often integrates with DNS services, helping maintain stable URLs and endpoints during scaling events or network changes.

In Embedded Cluster deployments, a load balancer is still required but is not provided as part of the deployment. Customers must supply and manage their own load balancer, which can be hardware-based or software-based. This usually requires additional planning and coordination with the network or infrastructure team.

Scaling storage dynamically with decoupled storage classes Copied

Scenario: Your ClickHouse workload grows steadily from 500GB to several terabytes of data over time.

In a Bring Your Own (Kubernetes) Cluster (BYOC) environment, storage is decoupled from individual nodes. Kubernetes ensures that persistent volumes move with pods as they are rescheduled, and extensible storage classes allow volumes to grow seamlessly as data increases.

In Embedded Cluster (EC) deployments, storage is tied to local node disks. If a node becomes unavailable, the workloads depending on that node cannot be rescheduled elsewhere, and the system may operate in a degraded state until the node is restored.

Choosing between automatic and manual recovery Copied

Scenario: A node in your ITRS Analytics deployment fails unexpectedly during peak monitoring hours.

In a Bring Your Own (Kubernetes) Cluster (BYOC) environment, Kubernetes detects the failure and automatically reschedules stateful pods onto healthy nodes. Services remain available with minimal disruption, and no manual intervention is required to restore normal operations.

In an Embedded Cluster (EC) deployment, the platform supports full high availability, but recovery is manual. Workloads tied to the failed node cannot be rescheduled elsewhere and must wait for the node to come back online or for an operator to intervene directly.

Deploying secure workloads on tuned platforms Copied

Scenario: Your IT security team enforces strict policies and container security requirements for all workloads.

In a Bring Your Own Cluster environment, security aligns with Kubernetes-native policies, simplifying troubleshooting and operational management.

An Embedded Cluster running on servers secured with traditional tools may encounter conflicts, with agents potentially blocking installation or container operations.

Streamlined support across teams Copied

Scenario: Your organization has separate teams for infrastructure, platform, and application operations.

In a Bring Your Own Cluster setup, responsibilities are clearly divided: infrastructure teams manage nodes, platform teams administer Kubernetes, and application teams deploy and manage ITRS Analytics. Issues can be addressed at the appropriate layer.

With Embedded Cluster, cluster-level issues are escalated to ITRS, with limited internal visibility.

Deployment scenarios Copied

The following sections describe various deployment scenarios, each with specific benefits and trade-offs. Understanding these helps you select the right configuration for your requirements.

Non-HA single or multi-node (BYOC) Copied

This configuration is suitable for proof-of-concept deployments and smaller production environments where high availability is not a strict requirement.

Common use cases:

• SaaS proof-of-concepts
• Small SaaS Geneos or Opsview observability deployments
• Development and testing environments

Characteristics:

• Lower infrastructure costs
• Backup and restore available with 24-hour recovery time objective
• Suitable for environments with flexible uptime requirements
• Managed by ITRS cloud operations teams for SaaS deployments

Note

Proof-of-concept deployments come with no guarantee of highly available data due to their exploratory nature.

Non-HA single or multi-node (Embedded Cluster) Copied

Similar to the Bring Your Own Cluster non-HA configuration, but deployed on-premises using Embedded Cluster. This option has additional limitations around data protection.

Common use cases:

• On-premises proof-of-concept deployments
• Small production use cases with relaxed uptime requirements

Important considerations:

• Lower infrastructure costs
• Backup and restore functionality is not supported (Velero does not support node filesystem storage classes)
• Risk of complete data loss if a node fails catastrophically
• Requires complete rebuild if storage is lost

Warning

Since backup and restore is not supported with Embedded Cluster, organizations should carefully assess their data protection requirements before choosing this deployment method.

Plan your rollout Copied

Use the following summary to confirm your deployment choice before proceeding to installation.

Expand table

To continue planning your deployment, refer to the following resources:

• For backup and restore procedures, see the Backup and restore documentation.
• For infrastructure sizing and resource requirements, see ITRS Analytics Sizer.