diff --git a/deploy-manage/deploy/elastic-cloud/change-hardware.md b/deploy-manage/deploy/elastic-cloud/change-hardware.md index b646b3ebd..26d965178 100644 --- a/deploy-manage/deploy/elastic-cloud/change-hardware.md +++ b/deploy-manage/deploy/elastic-cloud/change-hardware.md @@ -8,9 +8,11 @@ products: - id: cloud-hosted --- -# Change hardware [ec-change-hardware-for-a-specific-resource] +# Customize instance configuration [ec-change-instance-configuration] -The virtual hardware on which {{stack}} deployments run is defined by instance configurations. To learn more about what an instance configuration is, refer to [Instance configurations](cloud://reference/cloud-hosted/hardware.md#ec-getting-started-configurations). +## Consideration [ec-consideration-on-changing-ic] + +The virtual hardware on which {{stack}} deployments run is defined by instance configurations. Review [Hardware profile](./ec-change-hardware-profile.md#ec-hardware-profile) and [Instance configurations](cloud://reference/cloud-hosted/hardware.md#ec-getting-started-configurations) for more information about hardware profile and instance configuration respectively. When a deployment is created, each {{es}} tier and stateless resource (e.g., Kibana) gets an instance configuration assigned to it, based on the hardware profile used. The combination of instance configurations defined within each hardware profile is designed to provide the best possible outcome for each use case. Therefore, it is not advisable to use instance configurations that are not specified on the hardware profile, except in specific situations in which we may need to migrate an {{es}} tier or stateless resource to a different hardware type. An example of such a scenario is when a cloud provider stops supporting a hardware type in a specific region. @@ -89,6 +91,30 @@ Having an instance configuration mismatch between the deployment and the hardwar ## Deprecated instance configurations (ICs) and deployment templates (DTs) [ec-deprecated-icdt] -A list of deprecated and valid ICs/DTs can be found on the [Available regions, deployment templates and instance configurations](cloud://reference/cloud-hosted/ec-regions-templates-instances.md) page, as well as through the API, using `hide_deprecated` to return valid ICs/DTs. For example, to return valid ICs/DTs the following request can be used: `https://api.elastic-cloud.com/api/v1/deployments/templates?region=us-west-2&hide_deprecated=true`. To list only the deprecated ones, this can be used: `https://api.elastic-cloud.com/api/v1/deployments/templates?region=us-west-2&metadata=legacy:true`. +Hardware profile is also referenced as deployment templates in {{ecloud}}. + +You can find a list of deprecated and valid instance configurations (ICs) and deployment templates (DTs) in two ways: + +### Public documentation page + +Visit the [Available regions, deployment templates and instance configurations](cloud://reference/cloud-hosted/ec-regions-templates-instances.md) page for detailed information. + +### API access + +Use the [Get deployment templates API](https://www.elastic.co/docs/api/doc/cloud/operation/operation-get-deployment-templates-v2) with query parameters like `hide_deprecated` to retrieve valid ICs and DTs. This API request returns a list of DTs along with the respective ICs referenced within each DT. + +For example, +* To return valid ICs/DTs the following request can be used: `https://api.elastic-cloud.com/api/v1/deployments/templates?region=us-west-2&hide_deprecated=true`. +* To list only the deprecated ones, this can be used: `https://api.elastic-cloud.com/api/v1/deployments/templates?region=us-west-2&metadata=legacy:true`. If a deprecated IC/DT is already in use, it can continue to be used. However, creating or migrating to a deprecated IC/DT is no longer possible and will result in a plan failing. In order to migrate to a valid IC/DT, navigate to the **Edit hardware profile** option in the Cloud UI or use the [Deployment API](https://www.elastic.co/docs/api/doc/cloud/operation/operation-migrate-deployment-template). + +::::{note} +Deployment with Elastic stack version prior to 7.10 does not support hardware profile change {{ecloud}} console and API. If you want to make change on hardware profile, upgrading to version 7.10 and onwards is required. +:::: + +In addtion, you can refer to below information about how these terminologies are referenced. +* _Deprecated_ is also referenced as _legacy_. +* Using the `metadata=legacy:true` query parameter will return only legacy/deprecated DTs. +* Using the `hide_deprecated=true` query parameter will return only valid DTs. +* Not using any of the query parameters above will return all DTs. In this case, check the presence of `legacy: true` in the `metadata` entries within the API response, to verify if an IC/DT is deprecated or not. diff --git a/deploy-manage/deploy/elastic-cloud/ec-change-hardware-profile.md b/deploy-manage/deploy/elastic-cloud/ec-change-hardware-profile.md index f7cc41bdc..54a2537cc 100644 --- a/deploy-manage/deploy/elastic-cloud/ec-change-hardware-profile.md +++ b/deploy-manage/deploy/elastic-cloud/ec-change-hardware-profile.md @@ -8,7 +8,9 @@ products: - id: cloud-hosted --- -# Change hardware profiles [ec-change-hardware-profile] +# Manage hardware profiles [ec-change-hardware-profile] + +## Hardware profile [ec-hardware-profile] Deployment hardware profiles deploy the {{stack}} on virtual hardware. Each hardware profile has a different blend of storage, RAM, and vCPU. @@ -24,6 +26,11 @@ The {{ecloud}} console indicates when a new version of a hardware profile is ava ## Change the hardware profile using the {{ecloud}} console [ec_change_the_hardware_profile_using_the_elastic_cloud_console] +::::{note} +Deployment with Elastic stack version prior to 7.10 does not support hardware profile change {{ecloud}} console and API. If you want to make change on hardware profile, upgrading to version 7.10 and onwards is required. +:::: + + ### Upgrade to the newest version of your current hardware profile [ec_upgrade_to_the_newest_version_of_your_current_hardware_profile] Note that if there’s no indication that a newer version is available, that means that your deployment is already running on the latest version of that hardware profile. @@ -72,6 +79,11 @@ If your deployment is configured for high availability, the hardware profile cha ## Change the hardware profile using the API [ec_change_the_hardware_profile_using_the_api] +::::{note} +Deployment with Elastic stack version prior to 7.10 does not support hardware profile change {{ecloud}} console and API. If you want to make change on hardware profile, upgrading to version 7.10 and onwards is required. +:::: + + Prerequisites: * A valid {{ecloud}} [API key](../../api-keys/elastic-cloud-api-keys.md) (`$EC_API_KEY`) @@ -176,14 +188,13 @@ Consider this configuration for ingestion use cases with 1-4 days of data availa ### CPU optimized (ARM) [ec-profiles-compute-optimized-arm] -This profile is similar to CPU optimized profile but is powered by AWS Graviton2 instances. You can find the exact storage, memory, and vCPU allotment on the [hardware details page](cloud://reference/cloud-hosted/hardware.md#ec-getting-started-configurations) for each cloud provider. +This profile is similar to CPU optimized profile but powered by ARM instances. Currently, we offer ARM instances on AWS. You can find the exact storage, memory, and vCPU allotment on the [hardware details page](cloud://reference/cloud-hosted/hardware.md#ec-getting-started-configurations) for each cloud provider. **Ideal use case** Consider this configuration for ingestion use cases with 1-4 days of data available for fast access and for search use cases with indexing and querying workloads. Provides the most CPU resources per unit of RAM. - -### Vector search optimized (ARM) [ec-profiles-vector-search] +### Vector search optimized [ec-profiles-vector-search] This profile is suited for Vector search, Generative AI and Semantic search optimized workloads. You can find the exact storage, memory, and vCPU allotment on the [hardware details page](cloud://reference/cloud-hosted/hardware.md#ec-getting-started-configurations) for each cloud provider. @@ -191,6 +202,14 @@ This profile is suited for Vector search, Generative AI and Semantic search opti Optimized for applications that leverage Vector Search and/or Generative AI. Also the optimal choice for utilizing ELSER for semantic search applications. Broadly suitable for all semantic search, text embedding, image search, and other Vector Search use cases. +### Vector search optimized (ARM) [ec-profiles-vector-search-arm] + +This profile is suited for Vector search, Generative AI and Semantic search optimized workloads powered by ARM instances. Currently, we offer ARM instances on AWS. You can find the exact storage, memory, and vCPU allotment on the [hardware details page](cloud://reference/cloud-hosted/hardware.md#ec-getting-started-configurations) for each cloud provider. + +**Ideal use case** + +Optimized for applications that leverage Vector Search and/or Generative AI. Also the optimal choice for utilizing ELSER for semantic search applications. Broadly suitable for all semantic search, text embedding, image search, and other Vector Search use cases. + ### General purpose [ec-profiles-general-purpose] @@ -203,7 +222,7 @@ Suitable for ingestion use cases with 5-7 days of data available for fast access ### General purpose (ARM) [ec-profiles-general-purpose-arm] -This profile is similar to the General purpose profile but is powered by AWS Graviton2 instances. You can find the exact storage, memory, and vCPU allotment on the [hardware details page](cloud://reference/cloud-hosted/hardware.md#ec-getting-started-configurations) for each cloud provider. +This profile is similar to General purpose profile but powered by ARM instances. Currently, we offer ARM instances on AWS. You can find the exact storage, memory, and vCPU allotment on the [hardware details page](cloud://reference/cloud-hosted/hardware.md#ec-getting-started-configurations) for each cloud provider. **Ideal use case** diff --git a/deploy-manage/production-guidance/optimize-performance/indexing-speed.md b/deploy-manage/production-guidance/optimize-performance/indexing-speed.md index c4841102e..719f33729 100644 --- a/deploy-manage/production-guidance/optimize-performance/indexing-speed.md +++ b/deploy-manage/production-guidance/optimize-performance/indexing-speed.md @@ -133,7 +133,7 @@ If indexing is I/O-bound, consider increasing the size of the filesystem cache ( Stripe your index across multiple SSDs by configuring a RAID 0 array. Remember that it will increase the risk of failure since the failure of any one SSD destroys the index. However this is typically the right tradeoff to make: optimize single shards for maximum performance, and then add replicas across different nodes so there’s redundancy for any node failures. You can also use [snapshot and restore](../../tools/snapshot-and-restore.md) to backup the index for further insurance. ::::{note} -In {{ech}} and {{ece}}, you can choose the underlying hardware by selecting different hardware profiles or deployment templates. Refer to [ECH > Change hardware](/deploy-manage/deploy/elastic-cloud/change-hardware.md) and [ECE deployment templates](/deploy-manage/deploy/cloud-enterprise/configure-deployment-templates.md) for more details. +In {{ech}} and {{ece}}, you can choose the underlying hardware by selecting different hardware profiles or deployment templates. Refer to [ECH > Manage hardware profiles](/deploy-manage/deploy/elastic-cloud/ec-change-hardware-profile.md) and [ECE > Manage deployment templates](/deploy-manage/deploy/cloud-enterprise/configure-deployment-templates.md) for more details. :::: ### Local vs. remote storage [_local_vs_remote_storage] diff --git a/deploy-manage/production-guidance/optimize-performance/search-speed.md b/deploy-manage/production-guidance/optimize-performance/search-speed.md index fff7f0de6..ab8fd0046 100644 --- a/deploy-manage/production-guidance/optimize-performance/search-speed.md +++ b/deploy-manage/production-guidance/optimize-performance/search-speed.md @@ -66,7 +66,7 @@ If your searches are I/O-bound, consider increasing the size of the filesystem c If your searches are CPU-bound, consider using a larger number of faster CPUs. ::::{note} -In {{ech}} and {{ece}}, you can choose the underlying hardware by selecting different hardware profiles or deployment templates. Refer to [ECH > Change hardware](/deploy-manage/deploy/elastic-cloud/change-hardware.md) and [ECE deployment templates](/deploy-manage/deploy/cloud-enterprise/configure-deployment-templates.md) for more details. +In {{ech}} and {{ece}}, you can choose the underlying hardware by selecting different hardware profiles or deployment templates. Refer to [ECH > Manage hardware profiles](/deploy-manage/deploy/elastic-cloud/ec-change-hardware-profile.md) and [ECE > Manage deployment templates](/deploy-manage/deploy/cloud-enterprise/configure-deployment-templates.md) for more details. :::: ### Local vs. remote storage [_local_vs_remote_storage_2] diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index de7e3bc74..2002ff21f 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -45,6 +45,8 @@ toc: - file: deploy/elastic-cloud/configure.md children: - file: deploy/elastic-cloud/ec-change-hardware-profile.md + children: + - file: deploy/elastic-cloud/change-hardware.md - file: deploy/elastic-cloud/ec-customize-deployment-components.md - file: deploy/elastic-cloud/edit-stack-settings.md - file: deploy/elastic-cloud/add-plugins-extensions.md @@ -57,7 +59,6 @@ toc: - file: deploy/elastic-cloud/switch-from-apm-to-integrations-server-payload.md - file: deploy/elastic-cloud/find-cloud-id.md - file: deploy/elastic-cloud/ec-vcpu-boost-instance.md - - file: deploy/elastic-cloud/change-hardware.md - file: deploy/elastic-cloud/manage-deployments-using-elastic-cloud-api.md - file: deploy/elastic-cloud/keep-track-of-deployment-activity.md - file: deploy/elastic-cloud/restrictions-known-problems.md