- SAP Managed Tags:
Update on February 25, 2025:
Related Tutorials: |
Previously introduced in my blog last year, the Elastic Compute Node (ECN) has been released with SAP HANA Cloud QRC 04/2024 and is now generally available to all SAP HANA Cloud customers. Since I've already covered its key capabilities, characteristics, and potential use cases in my previous blog, this post will focus on getting started with ECN, rather than repeating that information. For a recap, please refer to the earlier blog.
In general, suitable use cases for ECN include addressing compute-intensive OLAP or read-only peak workloads with better flexibility, ensuring performance through workload distribution, and optimizing TCO.
In this context, individual ECNs or multiple ECNs can be provisioned and deprovisioned based on your requirements, with workloads being routed to and executed on the ECN. To maximize ECN utilization, tables can also be replicated to the ECN, allowing query executions to be fully delegated to it, as it fetches data from the replicas.
The following illustrates how ECNs can be provisioned with and without table replicas and then deprovisioned.
For example, in this case, four ECNs are provisioned via the REST API. ECN1 and ECN2 each have table replicas and dedicated workload classes (Workload Class 1 and 2) used to route workloads to them, respectively. Meanwhile, ECN3 and ECN4 are grouped without table replicas, and a dedicated workload class (Workload Class 3) is used to route workloads to them. In this case, routed queries will be executed in a round-robin manner within the ECN group (ECN3 and ECN4). If the ECNs are no longer needed, they can also be deprovisioned via the REST API after adapting the workload classes.
However, please note that the above is just an example. An individual ECN can also be used without replicas, and an ECN group can also be used with replicas.
Now, with that concept and flow in mind, let's dive deeper into the way of using ECNs.
The way of using ECNs
As you have already noticed, workload classes and workload mappings are necessary to route workloads to ECNs. These classes and mappings are carefully managed to ensure proper use of ECNs. In this context, please refer to the following as a guide for using ECNs:
It is highly recommended to follow the described steps to properly manage and use ECNs. Otherwise, running queries may be canceled, and queries could fail in the worst-case scenario.
And as written, in general, provisioning an ECN takes approximately 10 minutes or less in 90% of cases. However, this duration depends on various factors, such as the resource capacity of the cloud service provider and SAP's internal operations. In the best-case scenario, it can be provisioned in around 5 minutes, whereas in the worst-case scenario, it can take up to 20 minutes.
As previously mentioned, table replication is optional. However, if you fully understand the characteristics of your queries and the required tables for execution, replicating them to ECNs can be beneficial. This approach allows data to be fetched directly from replicas in the ECNs, rather than involving the coordinator node in fetching the data.
However, there are also disadvantages to replicating tables, as it can cause overhead and delay the readiness of the ECN until replication is completed, given the expected average internode communication speed of approximately 70 MB/s.
Once the ECN is provisioned and table replication is completed as an optional step, you need to adapt the workload class and workload mapping to route workloads to the ECN. This should be done after ECN provisioning, and once the workload class and workload mapping are adapted, only newly executed queries will run on the ECN according to the workload class configurations. Queries already in execution, such as long-running queries, will remain unaffected and continue based on the previous configurations as originally intended.
If the ECN is no longer needed, you should first adapt the workload class and workload mapping in the opposite order of how they were set up. This way, you can ensure that workloads are rerouted to a coordinator or other ECNs that will remain active. Then, the deprovisioning of the no-longer-needed ECN can be started. If the workload class and workload mapping are adapted in this way, only newly executed queries will be affected, while queries already in progress, such as long-running queries, will remain unaffected.
In that sense, as a rule of thumb, it is highly recommended to follow the steps below especially for safely deprovisioning ECNs:
1. Always adapt workload classes before deprovisioning ECNs by doing one of the following:
- Remove the workload class
- Disable the workload class
- Change the mapping to the index server or other existing ECNs that will not be deprovisioned
2. Check whether there are any open transactions involving ECNs
3. If there are no open transactions involving ECNs, start deprovisioning ECNs
Alright, then let's dive even deeper into how to get started with ECNs in SAP HANA Cloud.
Getting started with ECN in SAP HANA Cloud
Obviously, the first step is provisioning ECNs, and there are multiple ways to provision or deprovision ECNs:
- Using ECN in SAP HANA Cloud Central
- Provision/Deprovision ECNs via Cloud Foundry Command Line Interface (cf CLI)
- Provision/Deprovision ECNs via BTP Command Line Interface (btp CLI)
- Provision/Deprovision ECNs via REST API
Using ECN in SAP HANA Cloud Central
In the multi-environment edition of SAP HANA Cloud Central, a new Elastic Compute Node tab is available for SAP HANA Database with the following capabilities, but not limited to:
- Overview
- Memory Usage per Node
- Current Running ECNs
- Manage ECNs (provisioning / deprovisioning)
- Manage Workload Classes
With the Manage ECNs button, ECNs can be provisioned and deprovisioned in the Additional Nodes section as described below:
To use the multi-environment edition of SAP HANA Cloud Central, please follow the instruction in Subscribing to the SAP HANA Cloud Administration Tools.
For more information, please refer to the links below.
- SAP HANA Cloud, SAP HANA Database Administration Guide: Set up ECNs Using SAP HANA Cloud Central
Provision/Deprovision ECNs via Cloud Foundry Command Line Interface (cf CLI)
In addition to the above UI-based method, the Cloud Foundry Command Line Interface (cf CLI) can be used to provision and deprovision ECNs when the SAP HANA database instance is created within the Cloud Foundry runtime environment.
To ensure atomic operations and prevent concurrent updates, it is highly recommended to include the optional parameter resource_version when provisioning ECNs. The resource_version value can be found based on the GUID as shown below.
-- retrieve the GUID of the my_hana instance
cf service my_hana --guid
-- retrieve the resource version
cf curl /v2/service_instances/<GUID>/parameters | grep resource_versionWith the retrieved resource_version and available ECN sizes, you can directly provide the configuration using the -c flag with the cf update-service command.
The size of ECNs (memory, storage, and vCPU) should match the available ECN sizes provided by the cloud service provider. Available ECN sizes and their estimated CUs by the cloud service provider can be found in the SAP HANA Cloud Capacity Unit Estimator.
-- directly provide the configuration
cf update-service my_hana –c '{ \
"data":{ \
"computeNodes":[ \
{ \
"memory":32, \
"name":"ecn1", \
"storage":120, \
"vcpu":2 \
}, \
{ \
"memory":64, \
"name":"ecn2", \
"storage":200, \
"vcpu":8 \
} \
] \
}, \
"resource_version": "<resource_version>" \
}'In the example above, two ECNs (ecn1 and ecn2) are defined by specifying the resource_version.
Alternatively, a JSON file (e.g., add_ecn.json) can be created first and used with the -c flag, as described below.
-- use a json file (e.g., add_ecn.json)
{
"data":{
"computeNodes":[
{
"memory":32,
"name":"ecn1",
"storage":120,
"vcpu":2
},
{
...
}
]
},
"resource_version": "<resource_version>"
}-- provision ecns
cf update-service my_hana –c add_ecn.jsonThe ECN can also be deprovisioned using the same cf update-service command by removing its configuration. This can be done by directly providing the configuration using the -c flag or by using a JSON file. Let’s look at the examples below.
-- deprovision ecn1 while keeping ecn2
cf update-service my_hana –c '{ \
"data":{ \
"computeNodes":[ \
{ \
"memory":64, \
"name":"ecn2", \
"storage":200, \
"vcpu":8 \
} \
] \
}, \
"resource_version": "<resource_version>" \
}'This example can deprovision ecn1 while keeping ecn2, since only ecn1-related configurations are removed. This operation can also be done with a predefined JSON file. If all ECNs are to be deprovisioned at once, the following example can be used instead.
-- deprovision all ecns
cf update-service my_hana –c '{ \
"data":{ \
"computeNodes":[] \
}, \
"resource_version": "<resource_version>" \
}'Additionally, to track the status of the last operation, the cf get services command can be used, or cf service <instance-name> can be used for more detailed information.
For monitoring purposes, the monitoring view M_LANDSCAPE_HOST_CONFIGURATION can also be used to check the status. If needed, cf curl "v2/service_instances/<GUID>/parameters" shows the current configuration of the instance.
It is also possible to change the performance class or size of the ECNs using the existing ECN names but note that the storage cannot be reduced.
For more information, please refer to the links below.
- SAP HANA Cloud, SAP HANA Database Administration Guide: Setting Up the ECN Using the Cloud Foundry CLI
- SAP HANA Cloud, SAP HANA Database Administration Guide: Deprovisioning ECNs Using the Cloud Foundry CLI
Provision/Deprovision ECNs via BTP Command Line Interface (btp CLI)
Similar to the aforementioned cf CLI method, the BTP Command Line Interface (btp CLI) can be used to provision and deprovision ECNs when the SAP HANA database instance is created within the multi-environment.
Like the cf CLI method, both direct configuration and JSON file methods are supported. Typically, a JSON file can be used as shown below (please refer to the add_ecn.json example in the cf CLI section). Specifying the resource_version is also highly recommended to ensure atomic operations.
-- provision ecns
btp update services/instance <GUID> --parameters add_ecn.jsonDeprovisioning can also be done with a JSON file (e.g., delete_ecn.json), as shown below.
-- use a json file (e.g., delete_ecn.json) to deprovision ecn1 while keeping ecn2
{
"data":{
"computeNodes":[
{
"memory":64,
"name":"ecn2",
"storage":200,
"vcpu":8
}
]
},
"resource_version": "<resource_version>"
}-- deprovision ecns
btp update services/instance <GUID> --parameters delete_ecn.jsonSimilar to the cf CLI, to track the status of the last operation, the btp get services/instance command can be used, or the --show-parameters option can be included for detailed information.
For monitoring, the M_LANDSCAPE_HOST_CONFIGURATION view can be used to check the status.
It is also possible to change the performance class or size of the ECNs using the existing ECN names, but the storage cannot be reduced.
For more information, please refer to the links below.
- SAP HANA Cloud, SAP HANA Database Administration Guide: Setting Up the ECN Using the BTP CLI
- SAP HANA Cloud, SAP HANA Database Administration Guide: Deprovisioning ECNs Using the BTP CLI
Provision/Deprovision ECNs via REST API
The REST API can be used to provision and deprovision ECNs when the SAP HANA database instance is created within both the Cloud Foundry runtime environment and the multi-environment. Full technical specifications of all API calls (including parameters, responses, and schemas) are available on the SAP Business Accelerator Hub - Elastic Compute Node Service.
Like other SAP HANA Cloud REST API use cases, the API Gateway URL, Client ID, Client Secret, and Token URL (https://{uaaurl}/oauth/token) are required.
For example, in the case of Cloud Foundry, a service key can be created via the cf create-service-key command, and this information can be retrieved using the cf service-key <hana-name> <key-name> command. A PUT request can be used to change the performance class or size of the ECN, but the storage cannot be reduced.
-- endpoint example for provisioning ecn
https://api.gateway.orchestration.prod-eu10.hanacloud.ondemand.com/compute/v1/serviceInstances/{serviceInstanceID}/nodesFor more information, please refer to the links below.
- SAP HANA Cloud, SAP HANA Database Administration Guide: REST API for the ECN
Maximizing ECN Usage through Table Replication (Optional)
Tables can be replicated to the ECN using either synchronous or asynchronous replication to maximize the use of the ECN, as it will fetch data from replicas in the ECN instead of from the indexserver (a.k.a. coordinator).
- Synchronous Replication (a.k.a. OSTR, or Optimistic Synchronous Table Replication):
- In this case, the data in the replica is always consistent with the data in the source
- Queries are automatically routed to either the source or the replica based on decisions made by the SQL Optimizer
- Asynchronous Replication (a.k.a. ATR, or Asynchronous Table Replication):
- In this case, the data in the replica can be stale due to synchronization delays
- Hints can be used to route queries to the replica by overriding the decisions made by the SQL Optimizer
- Hints can also be applied to the workload class instead of individual statements for ease of operation
As mentioned, using replicas is optional, as there are both advantages and disadvantages:
- Advantages:
- Reduced resource consumption (CPU, memory) of the coordinator node
- Better performance compared to using the ECN without replication in general, if all required tables are replicated
- Disadvantages:
- Additional preparation time is required to replicate all necessary tables to make the ECN ready for use (the expected average speed of internode communication is around 70 MB/s)
- Slower write transactions occur when synchronous replication is used due to the need to synchronize with the replica before committing (all write transactions are always rerouted to the coordinator, as the ECN cannot store data permanently)
One more thing to remember is that if the ECN is deprovisioned, all replicas will be removed. However, if the size of the existing ECN is changed, the replicas will be retained.
To create replicas, consider the following three methods:
- SQL statement to create replica tables
- SQL statements to set up table placement rules
- Automated table placement using table distribution
For example, replica tables can be created using SQL statements like the ones below:
-- create an (empty) asynchronous replica table on ECN for the specific table
ALTER TABLE CUSTOMER ADD ASYNCHRONOUS REPLICA AT '<ecn_host_name>:30040';
-- activate replication for the specific table
ALTER TABLE CUSTOMER ENABLE ASYNCHRONOUS REPLICA;However, please note that the above example is a simple one, focusing on the core table replication capability for use with the ECN. Please refer to the Table Replication and Table Placement documentation for more information.
For monitoring, the monitoring view M_SERVICES can be used to obtain host and port information, and M_TABLE_REPLICAS can be used for replication details.
For more information, please also refer to the links below.
- SAP HANA Cloud, SAP HANA Database Administration Guide: Table Replication for the ECN
Configuring Workload Management for ECN
To route workloads to ECNs, workload classes and workload mappings should be configured, except when OSTR is being used.
As previously described, an ECN must be provisioned before adapting workload classes and workload mappings. Additionally, workload classes should be adapted before ECN deprovisioning.
When creating workload classes, hints can be applied to route workloads to an ECN or ECN group as shown below.
-- create a workload class to route workloads to ecn1 without replicas
CREATE WORKLOAD CLASS "MyClass1" SET 'ROUTING LOCATION HINT' = 'ecn1';
-- create a workload class to route workloads to ecn2 with ATR replicas
CREATE WORKLOAD CLASS "MyClass2" SET 'ROUTING LOCATION HINT' = 'ecn2', 'RESULT LAG HINT' = 'HANA_ATR';However, please note that the above example is a simple one focusing on the core workload management capability for use with ECN. Please refer to the Workload Management documentation for more information.
As explained earlier, in the case of an ECN group (multiple ECNs) being set up as shown in the example below, workloads will be routed and processed in a round-robin manner.
-- update the workload class to route workloads to ecn_group1 (ecn1 and ecn2)
ALTER SYSTEM ALTER TABLE PLACEMENT LOCATION ECN_group1 SET (INCLUDE => 'ecn1,ecn2', EXCLUDE => '') WITH RECONFIGURE;
ALTER WORKLOAD CLASS "MyClass1" SET 'ROUTING LOCATION HINT'='ECN_group1';For monitoring ECN groups, the monitoring view M_TABLE_PLACEMENT_LOCATIONS can be used to check the status.
Once a workload class is set, you can map workloads to it in a number of ways. The example below shows a couple of methods, but please refer to the Properties for Workload Class Mappings for more information.
-- create a workload mapping based on a named user (ecn_user)
CREATE WORKLOAD MAPPING "Mapping1" WORKLOAD CLASS "MyClass1" SET 'USER NAME' = 'ECN_USER';
-- create a workload mapping based on a session variable value (application component name)
CREATE WORKLOAD MAPPING "Mapping2" WORKLOAD CLASS "MyClass2" SET 'APPLICATION COMPONENT NAME' = 'MyApp';For more information, please refer to the links below.
- SAP HANA Cloud, SAP HANA Database Administration Guide: Workload Classes for Routing
- SAP HANA Cloud, SAP HANA Database Administration Guide: Routing Queries to Replicas
Monitoring ECN Usage and Consumption
As described earlier, in the multi-environment edition of SAP HANA Cloud Central, the usage of ECNs and configured workload classes can be monitored. Please refer to the information below for more details.
- SAP HANA Cloud, SAP HANA Database Administration Guide: Monitoring ECNs Using SAP HANA Cloud Central
Additionally, on the Instance Overview page, in the Consumption tile, you can see a breakdown of your instance's resource usage for the month to date, including ECN usage. This information can help you manage the cost of running your SAP HANA Cloud instance.
Key Considerations
There are several key considerations to keep in mind when using ECN:
- The maximum number of ECNs per HANA instance is 16, and the maximum memory is 2TB per node
- In practice, the maximum sizes available for memory and compute are determined by the offering of each cloud service provider:
- Microsoft Azure: 1,920 GB (120 vCPUs)
- Amazon Web Services: 1,800 GB (120 vCPUs)
- Google Cloud: 1,344 GB (84 vCPUs)
- This means that high memory performance is not supported because the minimum memory size required for the high memory performance class is greater than 2TB
- An ECN incurs higher additional costs than an indexserver of the same specifications due to its on-demand capabilities while running, but by running it only when it is needed, it can lower the total cost of ownership
- The ECN feature is not supported in the SAP HANA Cloud free tier or trial
FAQs
Q: What happens if the workload classes and workload mappings are not adapted before deprovisioning ECNs?
A: During the deprovisioning, running queries will be canceled, and newly executed queries will fail. After the deprovisioning, any newly executed queries will also fail. However, this query failure behavior can be changed by setting force_reroute = false in the global.ini. For more information, please refer to the link below:
- SAP HANA Cloud Elastic Compute Node: Routing Queries to Replicas
Q: Is the provisioning of an ECN always guaranteed?
A: Provisioning an ECN is generally very reliable, and SAP has fallback mechanisms internally in case cloud service providers like AWS, Azure, and GCP cannot accept the resource request as it is due to their hardware capacity constraints.
Nevertheless, provisioning an ECN cannot always be 100% guaranteed due to hardware capacity issues on the cloud service provider's side. This issue is not related to SAP's capacity but rather to the cloud service provider's capacity, which SAP cannot guarantee.
Q: What happens to the replicas on an ECN if the ECN is deprovisioned?
A: Since the ECN is a temporary computeserver, once the ECN is deprovisioned, the replicas will be gone as well. You will need to replicate the tables from scratch even if another ECN is provisioned with the same name and size.
Q: What happens to ECNs if a High Availability (HA) or Disaster Recovery (DR) takeover occurs?
A: HA/DR for the coordinator node is possible even if an ECN is attached. However, HA/DR for the ECN itself (e.g., a secondary ECN) is not supported.
When the coordinator node fails and a takeover occurs, the attached ECNs will be handled as follows:
- If the secondary coordinator node is in the same Availability Zone (AZ), the existing ECNs will be attached to the new coordinator.
- If the secondary coordinator node is in a different AZ, the ECNs will be recreated in the new AZ and attached to the new coordinator. In this case, table replicas will be automatically repopulated.
For more information, please refer to the link below:
- SAP HANA Cloud Elastic Compute Node: High Availability
Q: What happens if write operations, such as DMLs, are routed to the ECN?
A: These will be re-routed to the coordinator and executed there since the ECN doesn't have storage for persisting data.
Q: Can I use the replica table in an ECN as a replication source table for another replication, such as SDA- or SDI-based replication?
A: No, this is not supported, although you can still use the original tables in the indexserver (coordinator) as source tables for another replication while replicating them to ECNs.
Q: What happens if another workload class is defined for an application with a different name, and they conflict with each other? For example, one might route the workload to an ECN, while another mistakenly routes it to the indexserver, as a mistake from the end user.
A: Such ambiguity would already have been blocked in the workload management layer. For example, let's assume that workload class 1 is configured to route queries to an ECN, while workload class 2 is configured to route queries to an indexserver. If workload mapping 1 for workload class 1 sets a specific session variable, creating another workload mapping 2 for workload class 2 with the same session variable would be blocked.
Conclusion
If properly managed, ECN can be a game changer in scaling SAP HANA Cloud by effectively addressing compute-intensive peak workloads. Although I only explained a guided way of using ECN in this blog post, Automation Pilot can be leveraged, if needed, to simplify and automate the provisioning and deprovisioning processes for ECNs. However, please note that Automation Pilot is not yet available in all regions.
For a better understanding of your workloads, the ECN Advisor can also be utilized to analyze workload history and estimate potential sizes and timing of ECN usage based on existing workload classes.
As this is just the first step in achieving dynamic elasticity in SAP HANA Cloud, and with more innovations to come in ECN and ECN Advisor as they continuously evolve, please stay tuned for our next blog series.
