Skip to content

Commit

Permalink
Introduce orchestration cluster (#4646)
Browse files Browse the repository at this point in the history 
* swap orchestration cluster for automation cluster

* replace core automation cluster
  • Loading branch information
@akeller
akeller authored Nov 22, 2024
1 parent 6f75f62 commit b732a48
Show file tree
Hide file tree
Showing 5 changed files with 13 additions and 13 deletions.
12 changes: 6 additions & 6 deletions docs/components/concepts/clusters.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -29,13 +29,13 @@ You can choose from three different cluster types:

### Cluster availability and uptime

| Type | Basic | Standard | Advanced |
| :---------------------------------------------------------------------------- | :------------------------------------------------------------------------------------- | :-------------------------------------------------------- | :------------------------------------------------------------------------------------ |
| Usage | Non-production use, including experimentation, early development, and basic use cases. | Production-ready use cases with guaranteed higher uptime. | Production-ready use cases with guaranteed minimal disruption and the highest uptime. |
| Uptime Percentage<br/> (Core Automation Cluster<strong>\*</strong>) | 99% | 99.5% | 99.9% |
| RTO/RPO<strong>\*\*</strong><br/>(Core Automation Cluster<strong>\*</strong>) | RTO: 8 hours<br/>RPO: 24 hours | RTO: 2 hours<br/>RPO: 4 hours | RTO: < 1 hour<br/>RPO: < 1 hour |
| Type | Basic | Standard | Advanced |
| :-------------------------------------------------------------------------- | :------------------------------------------------------------------------------------- | :-------------------------------------------------------- | :------------------------------------------------------------------------------------ |
| Usage | Non-production use, including experimentation, early development, and basic use cases. | Production-ready use cases with guaranteed higher uptime. | Production-ready use cases with guaranteed minimal disruption and the highest uptime. |
| Uptime Percentage<br/> (Orchestration Cluster<strong>\*</strong>) | 99% | 99.5% | 99.9% |
| RTO/RPO<strong>\*\*</strong><br/>(Orchestration Cluster<strong>\*</strong>) | RTO: 8 hours<br/>RPO: 24 hours | RTO: 2 hours<br/>RPO: 4 hours | RTO: < 1 hour<br/>RPO: < 1 hour |

<p><strong>* Core Automation Cluster</strong> means the components critical for automating processes and decisions, such as Zeebe, Operate, Tasklist, Optimize, and Connectors.</p>
<p><strong>* Orchestration Cluster</strong> means the components critical for automating processes and decisions, such as Zeebe, Operate, Tasklist, Optimize, and Connectors.</p>
<p><strong>** RTO (Recovery Time Objective)</strong> means the maximum allowable time that a system or application can be down after a failure or disaster before it must be restored. It defines the target time to get the system back up and running. <strong>RPO (Recovery Point Objective)</strong> means the maximum acceptable amount of data loss measured in time. It indicates the point in time to which data must be restored to resume normal operations after a failure. It defines how much data you can afford to lose. The RTO/RPO figures shown in the table are provided on a best-effort basis and are not guaranteed.</p>

:::info
Expand Down
2 changes: 1 addition & 1 deletion docs/reference/announcements.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ End of maintenance: TBD

### Southeast Asia now available for SaaS customers

SaaS customers can now create automation clusters in the [Singapore (asia-southeast1) region](/reference/regions.md), ensuring lower latency and improved processing speed for organizations operating in southeast Asian countries.
SaaS customers can now create orchestration clusters in the [Singapore (asia-southeast1) region](/reference/regions.md), ensuring lower latency and improved processing speed for organizations operating in southeast Asian countries.

## Camunda 8.6

Expand Down
2 changes: 1 addition & 1 deletion docs/self-managed/concepts/multi-region/dual-region.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -120,7 +120,7 @@ The following Zeebe brokers and replication configuration are supported:
| Connectors Deployment | Connectors can be deployed in a dual-region setup, but attention to [idempotency](../../../components/connectors/use-connectors/inbound.md#creating-the-connector-event) is required to avoid event duplication. In a dual-region setup, you'll have two connector deployments and using message idempotency is of importance to not duplicate events. |
| Connectors | If you are running Connectors and have a process with an inbound connector deployed in a dual-region setup, consider the following: <ul><li> when you want to delete the process deployment, delete it via Operate (not zbctl), otherwise the inbound connector won't deregister.</li><li>if you have multiple Operate instances running, then perform the delete operation in both instances. This is a [known limitation](https://github.com/camunda/camunda/issues/17762).</li></ul> |
| Zeebe Cluster Scaling | Not supported. |
| Web Modeler | Web Modeler is a standalone component that is not covered in this guide. Modelling applications can operate independently outside of the automation clusters. |
| Web Modeler | Web Modeler is a standalone component that is not covered in this guide. Modelling applications can operate independently outside of the orchestration clusters. |

### Infrastructure and deployment platform considerations

Expand Down
4 changes: 2 additions & 2 deletions docs/self-managed/console-deployment/overview.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@
id: overview
title: "Console (Self-Managed)"
sidebar_label: "Overview"
description: "Console Self-Managed provides key insights into automation cluster deployments, process orchestration usage, and streamlining usage tracking."
description: "Console Self-Managed provides key insights into orchestration cluster deployments, process orchestration usage, and streamlining usage tracking."
---

Camunda Console Self-Managed offers a centralized overview for Camunda 8 installations, designed to enhance operational efficiency and oversight within Enterprise environments. Console Self-Managed provides key insights into automation cluster deployments, process orchestration usage, and streamlining usage tracking.
Camunda Console Self-Managed offers a centralized overview for Camunda 8 installations, designed to enhance operational efficiency and oversight within Enterprise environments. Console Self-Managed provides key insights into orchestration cluster deployments, process orchestration usage, and streamlining usage tracking.

Camunda Console Self-Managed provided is available as a container image. Refer to the [installation guide](/self-managed/setup/overview.md) for details on how to install this component.
6 changes: 3 additions & 3 deletions docs/self-managed/setup/guides/multi-namespace-deployment.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,11 @@ title: "Multi-namespace deployment"
description: "Deploy Camunda 8 Self-Managed across several namespaces for better resource management and environment separation."
---

Camunda 8 Self-Managed offers flexible deployment options that allow it to span multiple namespaces. This setup consists of a management cluster, which includes the Console, Identity, and Web Modeler components, along with several automation clusters (including Zeebe, Operate, Tasklist, and Optimize).
Camunda 8 Self-Managed offers flexible deployment options that allow it to span multiple namespaces. This setup consists of a management cluster, which includes the Console, Identity, and Web Modeler components, along with several orchestration clusters (including Zeebe, Operate, Tasklist, and Optimize).

For this configuration, each namespace is set up independently through Helm, with deployments classified into two types: management and automation. Each type has a specific values file designed for its deployment requirements.

Below, we illustrate multi-namespace Camunda deployment: one namespace will be dedicated to the management cluster, and the other two will be used for the automation cluster.
Below, we illustrate multi-namespace Camunda deployment: one namespace will be dedicated to the management cluster, and the other two will be used for the orchestration cluster.

## Management deployment

Expand Down Expand Up @@ -63,7 +63,7 @@ helm install camunda camunda/camunda-platform \

## Team One deployment

Let's create a Camunda automation cluster that can be owned and managed by Team One and will be deployed into namespace `camunda-team01`. This deployment includes Zeebe, Operate, Tasklist, and Optimize, and authenticates against Keycloak in the Management deployment:
Let's create a Camunda orchestration cluster that can be owned and managed by Team One and will be deployed into namespace `camunda-team01`. This deployment includes Zeebe, Operate, Tasklist, and Optimize, and authenticates against Keycloak in the Management deployment:

```yaml
# File: camunda-team01.yaml
Expand Down

0 comments on commit b732a48

Please sign in to comment.