Defining Custom Node Types

Setting up resources for your ClickHouse® clusters

When you create a ClickHouse® cluster in your environment, the ACM automatically includes a number of node types. The names and capabilities of those node types are based on the cloud provider associated with your environment.

To see the list of node types defined for your environment, go to the summary view of the environment and click the NODE TYPES menu at the top:

The Node Types menu

Figure 1 - The Node Types menu

You’ll see the list of node types defined in your environment:

The list of Node Types

Figure 2 - The list of node types

How (or if) you define custom node types depends on your environment:

  • If you’re running Altinity.Cloud as a Service, the node types are managed for you by Altinity.Cloud. If you need to add or edit node types, contact Altinity support.
  • If you’re running Altinity.Cloud in a Bring Your Own Cloud (BYOC) environment, Altinity defines a number of node types for you. It’s highly unlikely you’ll need to edit or create node types, but if you do, you can.
  • If you’re running Altinity.Cloud in a Bring Your Own Kubernetes (BYOK) environment, the ACM has no way of knowing what kinds of nodes you have in your environment. If you configure autoscaling with Karpenter (AWS), the AKS cluster autoscaler (Azure), or the GKE Autopilot (GCP), you can use the ACM to refer to those node types.

To work with node types, click the button to add a new node type.

It’s not common, but you can also click the vertical dots icon next to a node type in the list and select Edit to edit an existing node type:

The edit node type menu

Figure 3 - The edit node type menu

You’ll see this dialog:

The Node Type Details dialog

Figure 4 - The Node Type Details dialog

Here are the details of these fields:

Name

The name of the node. The node name and the instance type are typically the same, although that’s not a requirement.

Scope

Either ClickHouse, Zookeeper, or System. The scope allows you to define which node types you want to use with each component of the system.

Instance Type

Clicking the down arrow displays a list of dozens of cloud-provider-specific instance types. The example here is from a ClickHouse environment hosted on Azure, so Standard_D2s_v5 is an option. Similarly, n2-standard-4 would be an option for GCP and t4g.large would be an option for AWS.

Memory, MB

The amount of memory assigned to this node type. A value of at least 4096 is recommended.

CPU

The number of CPUs assigned to this node type.

Kubernetes options

These options are typically used in BYOK environments only. In many cases, the underlying BYOK infrastructure hosts workloads other than ClickHouse. That means you’ll want to make sure the right nodes are used for the ClickHouse, Zookeeper, and System nodes, as well as all of the other nodes in your environment. Defining Kubernetes tolerations or nodeSelectors gives you control over how nodes are allocated and managed in your environment. (In some cases BYOC environments are shared with other workloads; if that’s true, BYOC users may need Tolerations or NodeSelectors as well.)

Tolerations

One or more Kubernetes tolerations associated with this node type. Multiple tolerations should be separated by semicolons (;).

Node Selector

One or more Kubernetes nodeSelectors associated with this node type. Multiple nodeSelectors should be separated by commas (,).

Storage Class

Leave this field as is. It will be removed in a future version of the ACM.