Influxdata
/
docs-v2
mirror of https://github.com/influxdata/docs-v2.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'clustered/install-reorg' into staging/commandbar-clustered-install

staging/commandbar-clustered-install
Scott Anderson 2024-10-07 11:11:16 -06:00
parent 52bb29aa60 683fd62ad5
commit 0f12032569
4 changed files with 86 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
content/influxdb/clustered/admin/scale-cluster.md
View File

@ -32,6 +32,7 @@ resources available to each component.
- [Querier](#querier)
- [Router](#router)
- [Compactor](#compactor)
- [Garbage collector](#garbage-collector)
- [Catalog](#catalog)
- [Object store](#object-store)
@ -67,6 +68,7 @@ properties in your `AppInstance` resource:
- Querier
- Compactor
- Router
- Garbage collector
{{% note %}}
#### Scale your Catalog and Object store
@ -129,11 +131,18 @@ resource minimums and limits per pod and replicas per component:
- `limits`
- `cpu`: Maximum CPU Resource units to assign to routers
- `memory`: Maximum memory resource units to assign to routers
- `garbage-collector`
- `requests`
- `cpu`: Minimum CPU resource units to assign to the garbage collector
- `memory`: Minimum memory resource units to assign to the garbage collector
- `limits`
- `cpu`: Maximum CPU Resource units to assign to the garbage collector
- `memory`: Maximum memory resource units to assign to the garbage collector
{{< expand-wrapper >}}
{{% expand "View example `AppInstance` with resource requests and limits" %}}
{{% code-placeholders "(INGESTER|COMPACTOR|QUERIER|ROUTER)_(CPU_(MAX|MIN)|MEMORY_(MAX|MIN)|REPLICAS)" %}}
{{% code-placeholders "(INGESTER|COMPACTOR|QUERIER|ROUTER|GC)_(CPU_(MAX|MIN)|MEMORY_(MAX|MIN)|REPLICAS)" %}}
```yml
apiVersion: kubecfg.dev/v1alpha1
@ -178,6 +187,13 @@ spec:
limits:
cpu: ROUTER_CPU_MAX
memory: ROUTER_MEMORY_MAX
garbage-collector:
requests:
cpu: GC_CPU_MIN
memory: GC_MEMORY_MIN
limits:
cpu: GC_CPU_MAX
memory: GC_MEMORY_MAX
```
{{% /code-placeholders %}}
@ -233,11 +249,18 @@ replicas per component:
- `limits`
- `cpu`: Maximum CPU Resource units to assign to routers
- `memory`: Maximum memory resource units to assign to routers
- `garbage-collector`
- `requests`
- `cpu`: Minimum CPU resource units to assign to the garbage collector
- `memory`: Minimum memory resource units to assign to the garbage collector
- `limits`
- `cpu`: Maximum CPU Resource units to assign to the garbage collector
- `memory`: Maximum memory resource units to assign to the garbage collector
{{< expand-wrapper >}}
{{% expand "View example `values.yaml` with resource requests and limits" %}}
{{% code-placeholders "(INGESTER|COMPACTOR|QUERIER|ROUTER)_(CPU_(MAX|MIN)|MEMORY_(MAX|MIN)|REPLICAS)" %}}
{{% code-placeholders "(INGESTER|COMPACTOR|QUERIER|ROUTER|GC)_(CPU_(MAX|MIN)|MEMORY_(MAX|MIN)|REPLICAS)" %}}
```yml
# ...
@ -274,6 +297,13 @@ replicas per component:
limits:
cpu: ROUTER_CPU_MAX
memory: ROUTER_MEMORY_MAX
garbage-collector:
requests:
cpu: GC_CPU_MIN
memory: GC_MEMORY_MIN
limits:
cpu: GC_CPU_MAX
memory: GC_MEMORY_MAX
```
{{% /code-placeholders %}}
@ -435,6 +465,7 @@ to automatically scale your cluster as needed.
- [Ingester](#ingester)
- [Querier](#querier)
- [Compactor](#compactor)
- [Garbage collector](#garbage-collector)
- [Catalog](#catalog)
- [Object store](#object-store)
@ -530,6 +561,13 @@ increasing the available CPU) is the most effective scaling strategy for the
Compactor. Horizontal scaling increases compaction throughput, but not as
efficiently as vertical scaling.
### Garbage collector
The Garbage collector can be scaled [vertically](#vertical-scaling). It is a
light-weight process that typically doesn't require many system resources, but
if you begin to see high resource consumption on the garbage collector, you can
scale it vertically to address the added workload.
### Catalog
Scaling strategies available for the Catalog depend on the PostgreSQL-compatible

44
content/influxdb/clustered/install/customize-cluster/scale.md
View File

@ -27,13 +27,17 @@ to increase your write throughput and latency.
requests.
- **3 ingesters**:
Ensures redundancy on the write path.
- **1 querier**:
The optimal number of queriers depends on the number of concurrent queries you
are likely to have and how long they take to execute.
- **1 compactor**:
While you can have multiple compactors, it is more efficient to scale the
compactor vertically (assign more CPU and memory) rather than horizontally
(increase the number of compactors).
- **1 querier**:
The optimal number of queriers depends on the number of concurrent queries you
are likely to have and how long they take to execute.
- **1 garbage collector**:
The garbage collector is a light-weight process that only needs to be scaled
vertically when you observe high resource usage by the garbage collector.
_The garbage collector cannot be scaled horizontally._
The default values provide a good starting point for testing.
Once you have your cluster up and running and are looking for scaling
@ -104,11 +108,18 @@ If omitted, your cluster uses the default scale settings.
- `limits`
- `cpu`: Maximum CPU Resource units to assign to routers
- `memory`: Maximum memory resource units to assign to routers
- `garbage-collector`
- `requests`
- `cpu`: Minimum CPU resource units to assign to the garbage collector
- `memory`: Minimum memory resource units to assign to the garbage collector
- `limits`
- `cpu`: Maximum CPU Resource units to assign to the garbage collector
- `memory`: Maximum memory resource units to assign to the garbage collector
{{< expand-wrapper >}}
{{% expand "View example `AppInstance` with resource requests and limits" %}}
{{% code-placeholders "(INGESTER|COMPACTOR|QUERIER|ROUTER)_(CPU_(MAX|MIN)|MEMORY_(MAX|MIN)|REPLICAS)" %}}
{{% code-placeholders "(INGESTER|COMPACTOR|QUERIER|ROUTER|GC)_(CPU_(MAX|MIN)|MEMORY_(MAX|MIN)|REPLICAS)" %}}
```yml
apiVersion: kubecfg.dev/v1alpha1
@ -153,6 +164,13 @@ spec:
limits:
cpu: ROUTER_CPU_MAX
memory: ROUTER_MEMORY_MAX
garbage-collector:
requests:
cpu: GC_CPU_MIN
memory: GC_MEMORY_MIN
limits:
cpu: GC_CPU_MAX
memory: GC_MEMORY_MAX
```
{{% /code-placeholders %}}
@ -203,11 +221,18 @@ in your `values.yaml`. If omitted, your cluster will use the default scale setti
- `limits`
- `cpu`: Maximum CPU Resource units to assign to routers
- `memory`: Maximum memory resource units to assign to routers
- `garbage-collector`
- `requests`
- `cpu`: Minimum CPU resource units to assign to the garbage collector
- `memory`: Minimum memory resource units to assign to the garbage collector
- `limits`
- `cpu`: Maximum CPU Resource units to assign to the garbage collector
- `memory`: Maximum memory resource units to assign to the garbage collector
{{< expand-wrapper >}}
{{% expand "View example `values.yaml` with resource requests and limits" %}}
{{% code-placeholders "(INGESTER|COMPACTOR|QUERIER|ROUTER)_(CPU_(MAX|MIN)|MEMORY_(MAX|MIN)|REPLICAS)" %}}
{{% code-placeholders "(INGESTER|COMPACTOR|QUERIER|ROUTER|GC)_(CPU_(MAX|MIN)|MEMORY_(MAX|MIN)|REPLICAS)" %}}
```yml
# The following settings tune the various pods for their cpu/memory/replicas
@ -253,6 +278,15 @@ resources:
limits:
cpu: ROUTER_CPU_MAX
memory: ROUTER_MEMORY_MAX
# The garbage collector evicts obsolete data and files
garbage-collector:
requests:
cpu: GC_CPU_MIN
memory: GC_MEMORY_MIN
limits:
cpu: GC_CPU_MAX
memory: GC_MEMORY_MAX
```
{{% /code-placeholders %}}

9
content/influxdb/clustered/install/set-up-cluster/configure-cluster/_index.md
View File

@ -17,9 +17,12 @@ a YAML configuration file.
Apply configuration settings to your cluster by editing and applying a
Kubernetes custom resource (CRD) called `AppInstance`.
The AppInstance CRD is defined in a YAML file (use the `example-customer.yml`
provided by InfluxData as a template) or, if using the InfluxDB Clustered Helm
chart, is provided by the chart and configured in a `values.yaml` file.
provided by InfluxData as a template).
Use one of the following methods to configure your InfluxDB cluster:
We recommend editing the `AppInstance` resource directly as the primary method
for configuring and managing your InfluxDB cluster. If you are required to use
[Helm](https://helm.sh/), there is a InfluxDB Clustered Helm chart available
that acts as a wrapper for the `AppInstance` resource and lets you use Helm to
manage configuration changes in your InfluxDB cluster.
{{< children >}}

2
content/influxdb/clustered/install/set-up-cluster/configure-cluster/directly.md
View File

@ -11,7 +11,7 @@ menu:
parent: Configure your cluster
weight: 220
list_code_example: |
<a class="btn arrow" href="/influxdb/clustered/install/set-up-cluster/configure-cluster/directly/">Configure AppInstance directly <span class="cf-icon CaretOutlineRight"></span></a>
<a class="btn arrow" href="/influxdb/clustered/install/set-up-cluster/configure-cluster/directly/">Configure AppInstance directly <em class="op65">Recommended</em> <span class="cf-icon CaretOutlineRight"></span></a>
aliases:
- /influxdb/clustered/install/configure-cluster/directly/
---