You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: deploy-manage/cloud-organization/billing/elasticsearch-billing-dimensions.md
+6-1Lines changed: 6 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,7 +48,7 @@ You can control costs using the following strategies:
48
48
***Machine learning trained model autoscaling**: [Trained model autoscaling](/deploy-manage/autoscaling/trained-model-autoscaling.md) is always enabled and cannot be disabled, ensuring efficient resource usage, reduced costs, and optimal performance without manual configuration.
49
49
50
50
Trained model deployments automatically scale down to zero allocations after 24 hours without any inference requests. When they scale up again, they remain active for 5 minutes before they can scale down. During these cooldown periods, you will continue to be billed for the active resources.
51
-
***Indexing strategies** Consider your indexing strategies and how they might impact overall VCU usage and costs.
51
+
***Indexing strategies**: Consider your indexing strategies and how they might impact overall VCU usage and costs.
52
52
To ensure optimal performance and cost-effectiveness for your project, it's important to consider how you structure your data.
53
53
54
54
Consolidate small indices for better efficiency.
@@ -59,3 +59,8 @@ You can control costs using the following strategies:
59
59
Higher resource consumption can lead to higher costs and potentially impact the overall performance of your project.
60
60
61
61
If your use case naturally generates many small, separate streams of data, the recommended approach is to implement a process to consolidate them into fewer, larger indices. This practice leads to more efficient resource utilization. By grouping your data into larger indices, you can ensure a more performant and cost-efficient experience with {{es-serverless}}.
62
+
***Project subtype or profile**: When you use the [API]({{cloud-serverless-apis}}operation/operation-createelasticsearchproject) to create projects, be aware that the `optimized_for` option affects the VCU allocation and costs.
63
+
64
+
The `general_purpose` option is suitable for most search use cases. For example, it is the right profile for full-text search, sparse vectors, and dense vectors that use compression such as BBQ. It is used by default when you create projects from the UI.
65
+
66
+
The `vector` option is recommended only for uncompressed dense vectors ([dense_vector](elasticsearch://reference/elasticsearch/mapping-reference/dense-vector.md) fields with `int4` or `int8` quantization strategies) and high dimensionality. Though the per VCU cost is the same for general purpose and vector profiles, the latter allocates more VCUs for searchable data. This leads to higher VCU consumption in order to improve the performance for uncompressed vector data.
Copy file name to clipboardExpand all lines: deploy-manage/deploy/cloud-enterprise/ece-configure-templates-index-management.md
+33-27Lines changed: 33 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,54 +13,60 @@ products:
13
13
14
14
If you create a deployment template that includes more than one data configuration, you must also specify how {{ece}} should manage indices for your users when they create their deployments. For time-series use cases such as logging, metrics, and APM, providing a template that enables index management ensures that data is being stored in the most cost-effective way possible as it ages.
15
15
16
-
In a template that creates a hot-warm architecture, you can use index curation to specify where new indices are created initially and where they are moved to later on. However, index curation has been deprecated in favor of index lifecycle management, which offers additional features and more fine-grained control over indices. For instance, using ILM you can enable automatic roll-over of index aliases to new indices when existing indices become too large or too old, and you can set indices to be deleted when they are no longer useful.
16
+
Configuring index management is part of the larger task of [creating deployment templates](ece-configuring-ece-create-templates.md) or editing them. The choices you make here determine which index management methods are available to your users when they create deployments.
17
17
18
+
You should configure all index management methods that you want your users to be able to choose from when they create their deployments from your template. You can configure index curation, index lifecycle management, or both.
18
19
19
-
## Before you begin [ece_before_you_begin_4]
20
20
21
-
Configuring index management is part of the larger task of [creating deployment templates](ece-configuring-ece-create-templates.md) or editing them. The choices you make here determine which index management methods are available to your users when they create deployments.
21
+
## Available index management strategies
22
22
23
-
You should configure all index management methods that you want your users to be able to choose from when they create their deployments from your template. You can configure index curation, index lifecycle management, or both.
23
+
Index lifecycle management
24
+
: Uses the [{{ilm}}](/manage-data/lifecycle/index-lifecycle-management.md) feature of the {{stack}} that provides an integrated and streamlined way to manage time-based data, making it easier to follow best practices for managing your indices. Compared to index curation, ILM gives you more fine-grained control over the lifecycle of each index.
24
25
25
-
::::{note}
26
-
Index curation has been deprecated in favor of [index lifecycle management](/manage-data/lifecycle/index-lifecycle-management.md). For {{stack}} version 6.7 and later, any deployments using index curation will be prompted to [migrate to ILM](/manage-data/lifecycle/index-lifecycle-management/migrate-index-management.md).
27
-
::::
26
+
Index curation (Curator) {applies_to}`stack: deprecated 6.7`
27
+
: Creates new indices on hot nodes first and moves them to warm nodes later on, based on the data views (formerly *index patterns*) you specify. Also manages replica counts for you, so that all shards of an index can fit on the right data nodes. Compared to index lifecycle management, index curation for time-based indices supports only one action, to move indices from nodes on one data configuration to another, but it is more straightforward to set up initially and all setup can be done directly from the Cloud UI.
28
+
29
+
If your users need to delete indices once they are no longer useful to them, they can run [Curator](curator://reference/index.md) on-premise to manage indices for {{es}} clusters hosted on {{ece}}.
28
30
29
-
## Steps [ece_steps_2]
31
+
::::{note}
32
+
Index curation has been deprecated in favor of [index lifecycle management](/manage-data/lifecycle/index-lifecycle-management.md). For {{stack}} version 6.7 and later, any deployments using index curation will be prompted to [migrate to ILM](/manage-data/lifecycle/index-lifecycle-management/migrate-index-management.md).
33
+
::::
30
34
31
-
To configure index management when you create a deployment template:
32
35
33
-
1. On the **Index Management** page, configure the index curation methods that you want to be available when your users create deployments:
36
+
## Configure {{ilm}}
34
37
35
-
Index lifecycle management
36
-
: Uses the ILM feature of the {{stack}} that provides an integrated and streamlined way to manage time-based data, making it easier to follow best practices for managing your indices. Compared to index curation, ILM gives you more fine-grained control over the lifecycle of each index.
38
+
To configure {{ilm}} as part of your deployment template:
37
39
38
-
To configure index lifecycle management:
40
+
On the **Index Management** page, under **{{ilm}} ({{ilm-init}})**, specify the node attributes for your data configurations.
39
41
40
-
1. Specify the node attributes foryour data configurations.
42
+
Node attributes are simple key-value pairs, such as `node_type: hot`, `node_type: warm`, and `node_type: cold`. These node attributes add defining metadata attributes to each data configuration in your template that tell your users what they can be used for. What you define here should help guide your users when they set up their index lifecycle management policy in {{kib}}, such as a hot-warm policy.
41
43
42
-
Node attributes are simple key-value pairs, such as `node_type: hot`, `node_type: warm`, and `node_type: cold`. These node attributes add defining metadata attributes to each data configuration in your template that tell your users what they can be used for. What you define here should help guide your users when they set up their index lifecycle management policy in {{kib}}, such as a hot-warm policy.
44
+
For each data tier, specify an attribute key-value pair in the **Node attributes** field, with the key and value separated by a colon. Repeat this process until you have added all the node attributes that you want to be available to your users when they create an index lifecycle policy later on.
43
45
44
-
1. Specify an attribute key-value pair in the **Node attributes** field, with the key and value separated by a colon.
45
-
2. Repeat the previous step until you have added all the node attributes that you want to be available to your users when they create an index lifecycle policy later on.
46
+
## Configure index curation
47
+
```{applies_to}
48
+
stack: deprecated 6.7
49
+
```
46
50
51
+
::::{note}
52
+
Index curation has been deprecated in favor of [index lifecycle management](/manage-data/lifecycle/index-lifecycle-management.md). For {{stack}} version 6.7 and later, any deployments using index curation will be prompted to [migrate to ILM](/manage-data/lifecycle/index-lifecycle-management/migrate-index-management.md).
53
+
::::
47
54
48
-
Index curation
49
-
: Creates new indices on hot nodes first and moves them to warm nodes later on, based on the data views (formerly *index patterns*) you specify. Also manages replica counts for you, so that all shards of an index can fit on the right data nodes. Compared to index lifecycle management, index curation for time-based indices supports only one action, to move indices from nodes on one data configuration to another, but it is more straightforward to set up initially and all setup can be done directly from the Cloud UI.
55
+
To configure index curation as part of your deployment template:
50
56
51
-
If your user need to delete indices once they are no longer useful to them, they can run [Curator](curator://reference/index.md) on-premise to manage indices for {{es}} clusters hosted on {{ece}}.
57
+
1. On the **Index Management** page, under **Index curation**, click **Configure**.
52
58
53
-
To configure index curation:
59
+
2. Configure index curation by adding an index pattern:
54
60
55
-
1. Select the hot data configuration where new indices get created initially.
56
-
2. Select the warm nodes where older indices get moved to later on when they get curated.
57
-
3. Specify which indices get curated by including at least one data view.
61
+
1. Select the hot data configuration where new indices get created initially.
62
+
2. Select the warm nodes where older indices get moved to later on when they get curated.
63
+
3. Specify which indices get curated by including at least one index pattern.
58
64
59
-
By default, the pattern is `*`, which means that all indices get curated. For logging use cases, you could specify to curate only the `logstash-*`, `metricbeat-*`, or `filebeat-*` data views, for example.
65
+
By default, the pattern is `*`, which means that all indices get curated. For logging use cases, you could specify to curate only the `logstash-*`, `metricbeat-*`, or `filebeat-*` data views, for example.
60
66
61
-
4. Specify the time interval after which indices get curated.
67
+
4. Specify the time interval after which indices get curated.
62
68
63
-
2. Select **Next**.
69
+
## Next steps
64
70
65
71
After you have completed these steps, continue with [creating your deployment template](ece-configuring-ece-create-templates.md#ece-configuring-ece-create-templates-ui).
Copy file name to clipboardExpand all lines: deploy-manage/deploy/cloud-enterprise/ece-configuring-ece-create-templates.md
+16-11Lines changed: 16 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,13 +75,17 @@ Before you start creating your own deployment templates, you should have: [tagge
75
75
If a data tier or component is not required for your particular use case, you can simply set its initial size per zone to `0`. You can enable a tier or component anytime you need it just by scaling up the size. If autoscaling is enabled, data tiers and machine learning nodes are sized up automatically when they’re needed. For example, when you configure your first machine learning job, ML nodes are enabled by the autoscaling process. Similarly, if you choose to create a cold data phase as part of your deployment’s index lifecycle management (ILM) policy, a cold data node is enabled automatically without your needing to configure it.
76
76
77
77
8. Select **Manage indices**.
78
-
9. On this page you can [configure index management](ece-configure-templates-index-management.md) by assigning attributes to each of the data nodes in the deployment template. In {{kib}}, you can configure an index lifecycle management (ILM) policy, based on the node attributes, to control how data moves across the nodes in your deployment.
79
-
10. Select **Stack features**.
80
-
11. You can select a [snapshot repository](../../tools/snapshot-and-restore/cloud-enterprise.md) to be used by default for deployment backups.
81
-
12. You can choose to [enable logging and monitoring](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md) by default, so that deployment logs and metrics are send to a dedicated monitoring deployment, and so that additional log types, retention options, and {{kib}} visualizations are available on all deployments created using this template.
82
-
13. Select **Extensions**.
83
-
14. Select any {{es}} extensions that you would like to be available automatically to all deployments created using the template.
84
-
15. Select **Save and create template**.
78
+
79
+
On this page, you can [configure index management](ece-configure-templates-index-management.md) by assigning attributes to each of the data nodes in the deployment template. In {{kib}}, you can configure an index lifecycle management (ILM) policy, based on the node attributes, to control how data moves across the nodes in your deployment.
80
+
10. Select **Stack features**. On this page, you can manage the following options:
81
+
82
+
* You can select a [snapshot repository](../../tools/snapshot-and-restore/cloud-enterprise.md) to be used by default for deployment backups.
83
+
84
+
* You can choose to [enable logging and monitoring](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md) by default, so that deployment logs and metrics are send to a dedicated monitoring deployment, and so that additional log types, retention options, and {{kib}} visualizations are available on all deployments created using this template.
85
+
11. Select **Extensions**.
86
+
87
+
Select any {{es}} extensions that you would like to be available automatically to all deployments created using the template.
88
+
12. Select **Save and create template**.
85
89
86
90
87
91
## Create deployment templates through the RESTful API [ece_create_deployment_templates_through_the_restful_api]
@@ -408,14 +412,10 @@ Before you start creating your own deployment templates, you should have: [tagge
408
412
When specifying `node_roles`in the {{es}} plan of the deployment template, the template must contain all resource types and all {{es}} tiers. The deployment template must contain exactly one entry foreach resource type. It must have one {{es}}, one {{kib}}, and one APM. On top of that, it must also include all supported {{es}} tiersin the {{es}} plan. The supported tiers are identified by the IDs `hot_content`, `warm`, `cold`, `frozen`, `master`, `coordinating` and `ml`.
409
413
::::
410
414
411
-
412
415
::::{note}
413
416
Deployment templates without `node_roles` or `id` should only contain hot and warm data tiers, with different `instance_configuration_id`s. Node roles are highly recommended when using the cold tier and are mandatory for the frozen tier.
414
417
::::
415
418
416
-
417
-
After you have saved your new template, you can start [creating new deployments](create-deployment.md) with it.
418
-
419
419
::::{note}
420
420
To support deployment templates that are versioned due to a constraint on architecture that is only supported by newer versions of ECE, for example ARM instances, you must add additional configuration:
421
421
@@ -427,3 +427,8 @@ These attributes are set at the same level as `name` and `description`. The UI s
427
427
::::
428
428
429
429
430
+
## Next steps
431
+
432
+
After you have saved your new template, you can start [creating new deployments](create-deployment.md) with it.
Copy file name to clipboardExpand all lines: deploy-manage/license/manage-your-license-in-eck.md
+12-2Lines changed: 12 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -107,10 +107,20 @@ Before your current Enterprise license expires, you will receive a new Enterpris
107
107
You can check the expiry date of your license in the [elastic-licensing](#k8s-get-usage-data) ConfigMap. Enterprise licenses are container licenses that include multiple licenses for individual {{es}} clusters with shorter expiry. Therefore, you get a different expiry in {{kib}} or through the {{es}} [`_license`](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-license-get) API. ECK automatically updates the {{es}} cluster licenses until the expiry date of the ECK Enterprise license is reached.
108
108
::::
109
109
110
+
::::{important}
111
+
To avoid any unintended downgrade of individual {{es}} clusters to a Basic license while installing the new license, we recommend installing the new Enterprise license as a new Kubernetes secret next to your existing Enterprise license.
112
+
::::
113
+
114
+
To update your license, please refer to the [Add a license](#k8s-add-license) documentation and utilize a different Kubernetes secret name for your new license. For instance:
To avoid any unintended downgrade of individual {{es}} clusters to a Basic license while installing the new license, we recommend installing the new Enterprise license as a new Kubernetes secret next to your existing Enterprise license. Just replace `eck-license` with a different name in the [Kubernetes secret example](#k8s-add-license). ECK will use the correct license automatically.
121
+
After creating the new license, verify its status as described in [Get usage data](#k8s-get-usage-data). For example, ensure that the `eck_license_expiry_date` reflects the expiration date of your new license.
112
122
113
-
Once you have created the new license secret you can safely delete the old license secret.
123
+
Once the new license is confirmed, you may safely delete the old license secret.
0 commit comments