Versions Compared

Old Version 3

changes.mady.by.user Sarabjeet Kaur

Saved on

compared with

New Version Current

changes.mady.by.user Sarabjeet Kaur

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Applies to: (tick) Kyvos Enterprise  (tick) Kyvos Cloud (SaaS on AWS) (tick) Kyvos AWS Marketplace

(tick) Kyvos Azure Marketplace   (tick) Kyvos GCP Marketplace (error) Kyvos Single Node Installation (Kyvos SNI)

...

When the usage pattern of a cluster usage duration is not fixed, you must use load-based scaling is recommended. This type of scaling allows you to set rules to automatically scale up or scale down the query engines based on usage patterns. By managing cluster scalingQuery Engine instances based on the resource utilization of the Query Engine instances. By configuring cluster scaling in this way, you can enhance optimize the utilization of your cloud cluster and save on compute costs. Additionally, you can set rules to automatically shut down or start the BI Servers and Query Engines to optimize resource utilization further.

To implement a scale-down rule, you can configure a setting to automatically reduce the capacity of your Query Engines when the cluster is under usage. Additionally, you can set a rule to automatically shut down the Query Engines and BI Servers if the cluster is not in use for a specified period. Similarly, for a scale-up rule, you can set a rule to automatically start the BI Servers and Query Engines with the required capacity when the cluster utilization exceeds over a defined period.

The Kyvos 2024.2 release comes with enhanced Load-based scaling.
Scaling rules are reduce compute costs.

Setting Load-based cluster scaling rules
Anchor
load-based
load-based

From Kyvos 2024.2 onwards, load based scaling is implemented based on the CPU load and memory Memory usage of the Query Engine instances. System resources will be are monitored for all BI Servers and Query Engines every 30 seconds, and Query Engines’ scaling will be performed based on this data.

The cluster will be scaled up step-by-step. For instance, it will scale from Low to Moderate and then from Moderate to High. Similarly, when scaling down the cluster, it will scale from High to Moderate and then from Moderate to Low.

Load-based cluster scaling is enabled by default. You can further configure it on the Cluster Scaling page using the Load option.

To set a load-based schedulingscaling, from the Toolbox, click Setup > Cluster Scaling. The Cluster Scaling page is displayed. The Load option is selected by default.

Anchor
mode
mode

...

Kyvos will provide provides the following scaling modes for Load-based scaling:

  • Managed: In Managed scaling, Kyvos intelligently manages the cluster capacity to scale up and scale down Query Engine instances.

  • Custom: In Custom scaling , allows you can to set up rules based on your environment's cluster usage patterns. Currently, the custom scaling mode supports This feature presently supports scaling based on CPU and Memory utilization-based scaling. When the CPU or memory Memory load condition meets the configured parameters, the Query Engine cluster instances can be scaled up or down accordingly.

On this page, you can specify rules to scale down or scale up the query engines, as well as set rules to shut down or start the BI Servers and query engines.

Panel
panelIconIdatlassian-note
panelIcon:note:
bgColor#DEEBFF

Note

  • The capacity of the BI Servers cannot be changed.

  • All BI Servers can be shut down except the Coordination Master. It is required to provide a response to a query. If there is only one BI Server, this BI Server is treated as the Coordination Master.

  • The Settings option and Add Schedule option are disabled on the Load screen. You can set the default settings for the query engine cluster or create a new schedule using the Schedule option displayed on the Cluster Scheduling page. See the Creating schedule-based scaling section for more details. 

  • You can view on-screen notifications that provide you with timely information about the state of the cluster. 

  • When you scale down the Query Engines, you reduce the capacity of the node, including the number of cores and memory. Conversely, when you scale up the Query Engines, you increase the capacity of the node by adding more cores and memory.

Points to know

...

From Kyvos 2023.2 onwards, you can specify the time (in minutes)  to hold the queries when query engines are started by using the  QE_STARTUP_QUERY_HOLD_TIME  property. Note that if the query engines become active before the configured time, the query will be served; otherwise, it will fail.

...

Upon completion of the Change Cluster State schedule, the load-based rules will be implemented automatically if they have been saved. If no rules have been saved on the Load screen, the cluster will run using the Change Cluster State capacity.

...

In the future, it will be possible to scale the cluster even further. For instance, if the cluster was previously scaled down from maximum to moderate capacity, it can be scaled down again to the next lower capacity. Similarly, it can also be scaled up to increase its capacity.
If the query engine scales down to moderate capacity, you cannot further scale down the Query Engine to low capacity.

...

The Kyvos cluster and the Query Engines automatically scale up at full capacity for any MOLAP query.  

...

The Query Engines do not start for any ROLAP queries.  

...

The scale-down duration cannot be less than 30 minutes.

...

The duration to shut down the query engine must be at least 30 minutes greater than the scale-down duration.

...

If the cluster is down and a query is executed, the first query triggers the cluster startup process, and all queries fail until the cluster is up and running. In this case, the following messages are displayed:

  • Message 1: "Could not serve the query as Query Engine Cluster is not available. Query Engine is launched. Please try after some time." 

  • Message 2: "Could not serve the query as Query Engine Cluster is starting. Please try after some time."

...

To set the scaling modes for Load-Based scaling, perform the following steps. 

  1. On the Cluster Scaling page, the Load option is selected by default. 

    image-20240417-094608.pngImage Added

  2. To set the scaling mode, select one of the following:

    1. Managed: Select the required capacity from the list to start Query Engine when any query is fired.  

    2. Custom: Select this option to configure the custom rules as per your cluster usage pattern.

      image-20240417-094755.pngImage Added

      To set scale up rules,   

      • Select the required capacity from the list to start Query Engine when any query is fired.   

      • Enter a percentage to scale up the cluster if CPU or Memory utilization threshold goes above the specified percentage. Also, specify the number of data points and the total number of data points to set.

      • To set scale down rules,

        1. Specify the BI Server and/or Query Engine from the list to shut down when no queries are fired for the specified period of time.

        2. Enter a percentage to scale down the cluster if CPU and Memory utilization threshold remains below the specified percentage. Also, specify the number of data points and the total number of data points to set.

  3. Click Save. The load-based scaling mode is set.

Panel
panelIconIdatlassian-note
panelIcon:note:
bgColor#DEEBFF

NOTE

A data point is information on resource utilization captured every 30 seconds.

Transitioning period
Anchor
transioningperiod
transioningperiod

The following tables specify the approximate time required to complete the process during the transitioning period. 

Aura tab collection
paramsJTdCJTIyZ2VuZXJhbCUyMiUzQSU3QiUyMnRhYlNwYWNpbmclMjIlM0EwJTJDJTIydGFiV2lkdGglMjIlM0ExMDAlMkMlMjJ0YWJIZWlnaHQlMjIlM0E1MCUyQyUyMmRpcmVjdGlvbiUyMiUzQSUyMmhvcml6b250YWwlMjIlN0QlMkMlMjJjb250ZW50JTIyJTNBJTdCJTIyYmFja2dyb3VuZENvbG9yJTIyJTNBJTdCJTIyY29sb3IlMjIlM0ElMjIlMjNmZmYlMjIlN0QlMkMlMjJib3JkZXIlMjIlM0ElN0IlMjJzdHlsZSUyMiUzQSUyMnNvbGlkJTIyJTJDJTIyd2lkdGglMjIlM0ExJTJDJTIydG9wJTIyJTNBdHJ1ZSUyQyUyMmJvdHRvbSUyMiUzQXRydWUlMkMlMjJsZWZ0JTIyJTNBdHJ1ZSUyQyUyMnJpZ2h0JTIyJTNBdHJ1ZSUyQyUyMmNvbG9yJTIyJTNBJTdCJTIybGlnaHQlMjIlM0ElMjIlMjNjY2NlY2YlMjIlN0QlN0QlMkMlMjJwYWRkaW5nJTIyJTNBJTdCJTIydG9wJTIyJTNBMTAlMkMlMjJyaWdodCUyMiUzQTEwJTJDJTIyYm90dG9tJTIyJTNBMTAlMkMlMjJsZWZ0JTIyJTNBMTAlN0QlN0QlMkMlMjJhY3RpdmUlMjIlM0ElN0IlMjJiYWNrZ3JvdW5kQ29sb3IlMjIlM0ElN0IlMjJjb2xvciUyMiUzQSU3QiUyMmxpZ2h0JTIyJTNBJTIyJTIzZjU4MjI3JTIyJTdEJTdEJTJDJTIydGV4dCUyMiUzQSU3QiUyMmZvbnRTaXplJTIyJTNBMTYlMkMlMjJjb2xvciUyMiUzQSU3QiUyMmxpZ2h0JTIyJTNBJTIyJTIzMDAwMDAwJTIyJTdEJTJDJTIydGV4dEFsaWduJTIyJTNBJTIybGVmdCUyMiUyQyUyMmZvbnRXZWlnaHQlMjIlM0ElMjJib2xkJTIyJTdEJTdEJTJDJTIyaG92ZXIlMjIlM0ElN0IlMjJiYWNrZ3JvdW5kQ29sb3IlMjIlM0ElN0IlMjJjb2xvciUyMiUzQSUyMiUyM2RmZTFlNiUyMiU3RCUyQyUyMnRleHQlMjIlM0ElN0IlMjJmb250U2l6ZSUyMiUzQTE4JTJDJTIyY29sb3IlMjIlM0ElMjIlMjM1ZTZjODQlMjIlMkMlMjJ0ZXh0QWxpZ24lMjIlM0ElMjJsZWZ0JTIyJTJDJTIyZm9udFdlaWdodCUyMiUzQSUyMmxpZ2h0ZXIlMjIlN0QlN0QlMkMlMjJpbmFjdGl2ZSUyMiUzQSU3QiUyMmJhY2tncm91bmRDb2xvciUyMiUzQSU3QiUyMmNvbG9yJTIyJTNBJTIyJTIzZjRmNWY3JTIyJTdEJTJDJTIydGV4dCUyMiUzQSU3QiUyMmZvbnRTaXplJTIyJTNBMTYlMkMlMjJjb2xvciUyMiUzQSUyMiUyMzVlNmM4NCUyMiUyQyUyMnRleHRBbGlnbiUyMiUzQSUyMmxlZnQlMjIlMkMlMjJmb250V2VpZ2h0JTIyJTNBJTIybGlnaHRlciUyMiU3RCUyQyUyMmJvcmRlciUyMiUzQSU3QiUyMnRvcCUyMiUzQXRydWUlMkMlMjJsZWZ0JTIyJTNBdHJ1ZSUyQyUyMnJpZ2h0JTIyJTNBdHJ1ZSUyQyUyMmJvdHRvbSUyMiUzQXRydWUlMkMlMjJ3aWR0aCUyMiUzQTElMkMlMjJzdHlsZSUyMiUzQSUyMnNvbGlkJTIyJTJDJTIyY29sb3IlMjIlM0ElN0IlMjJsaWdodCUyMiUzQSUyMiUyM2NjY2VjZiUyMiU3RCU3RCU3RCU3RA==
Aura tab
summaryAWS
paramsJTdCJTIydGl0bGUlMjIlM0ElMjJBV1MlMjIlN0Q=

The process with the number of Query Engine =10

The time required for Load-based scaling

scale up

16 8 mins.

scale down

12 7 mins.

startup

4 3 mins.

Aura tab
summaryAzure
paramsJTdCJTIydGl0bGUlMjIlM0ElMjJBenVyZSUyMiU3RA==

The process with the number of Query Engine =7

The previous time required for Load-based scaling

New time required for Load-based scaling

Scale up

15-19 minutes

11-13 10 minutes

Scale down

15-19 minutes

11-13 9 minutes

Startup

8-10 4 minutes

8-10 minutes

Aura tab
summaryGCP
paramsJTdCJTIydGl0bGUlMjIlM0ElMjJHQ1AlMjIlN0Q=

The process with the number of Query Engine =10

The time required for Load-based scaling

scale up

4 -5 mins.

scale down

5-6 3 mins.

startup

3 -4 mins.

 To set the scaling modes for Load-Based scaling, perform the following steps. 

  1. On the page, select the Load option. The Load page is displayed. 

    image-20240401-085154.pngImage Removed

  2. To set the scaling mode, select one of the following:

    1. Managed: Select the capacity option as Low, Moderate, High or Full from the list to start Query Engine and BI Server when any query is fired.  

    2. Custom: To set scale up and scale down the query engines and BI Server.

      • To scale up,   

        1. To start the BI Servers and query engines, select the capacity option as Low, Moderate, High or Full from the list when any query is fired. 

        2. Enter a percentage to scale up the cluster if CPU and memory utilization threshold goes above the specified percentage. Also, specify the number of data points and the total number of data points to set.

      • To scale down,

        1. To shut down the BI Server and/or Query Engine, when no queries is fired for specified period of time.

        2. Enter a percentage to scale down the cluster if CPU and memory utilization threshold remains below the specified percentage. Also, specify the number of data points and the total number of data points to set.

  3. Click Save. The load-based scaling mode is set.

Panel
panelIconIdatlassian-note
panelIcon:note:
bgColor#DEEBFF

NOTE

A data point is information on resource utilization captured every 30 seconds.

Changing cluster state 

You can change the cluster capacity as required. This change comes into effect immediately and overrides any existing schedules or rules. 

Panel
panelIconIdatlassian-note
panelIcon:note:
bgColor#DEEBFF

Note

  • When you change the cluster state, the system enters a transition phase from one schedule to another. During this phase, you cannot modify the Query Engine capacity.

  • Once the transition phase is complete, you can change the cluster capacity as needed. 

To change the cluster state, perform the following steps. 

  1. Click the Change Cluster State link available in the Cluster Current State section. 
    The Change Cluster State dialog is displayed. 

    Image Removed

  2. Every cluster capacity option is associated with a title. The associated title is displayed in the Title box when you select a required capacity option.
    For example, if you choose the capacity option as Full, the title associated with the Full cluster capacity option is displayed in the Title box. You can use the default title or change the title for that schedule as needed. 

  3. Select the date and time when you want to change the cluster state. 

Panel
panelIconIdatlassian-note
panelIcon:note:
bgColor#DEEBFF

Note

The difference between the end time and the current time cannot be less than an hour.

  1. Select whether the service should remain online or offline.

  2. Click to select a query engine capacity. 

  3. Click Change Now.
    The Schedule entry is displayed in the schedule. 

Subscribe to notifications

Click the Actions menu (...) located in the upper right corner of a cluster scaling page, and then click  Subscribe Cluster Events  to subscribe to receive notifications for cluster events. These events include the cluster shutting down as per schedule, the cluster state scaling down due to Cluster scheduling, all query engines being up and in a running state, the cluster state scaling down, entity modifications, or a license expiring soon.

You can set up notifications and subscriptions as needed.

Tip

Tip

If you subscribe to the  Notify if the cluster shuts down as per schedule, you will receive an email with details on how to restart the cluster if you need to manually.

View cluster audit logs

Click the Actions menu (...) located  in the upper right corner of a cluster scaling page, and then click  View Audit Logs to view audit logs for cluster scaling events. This opens the Monitor page and displays all the events that have occurred on your cluster along with the details. You can view details about default and user-created schedules and download logs of any cluster scaling event.  

Panel
panelIconIdatlassian-info
panelIcon:info:
bgColor#FFFAE6

Important

  • If the cluster is down and a query is executed, the first query triggers the cluster startup process, and all queries fail until the cluster is up and running. In this case, the following messages are displayed:

    • Message 1: "Could not serve the query as Query Engine Cluster is not available. Query Engine is launched. Please try after some time." 

    • Message 2: "Could not serve the query as Query Engine Cluster is starting. Please try after some time."

  • By default, the queries fail until Query Engines are started. If you want to hold the queries when query engines are down, you can specify the time (in minutes) for holding queries by using the QE_STARTUP_QUERY_HOLD_TIME property.
    Ensure that if the query engines become active before the configured time, the query will be served; otherwise, it will fail.

  • The capacity of the BI Servers cannot be changed.

  • All BI Servers can be shut down except the Coordination Master. If there is only one BI Server, this BI Server is treated as the Coordination Master.

  • The Settings option and Add Schedule option are disabled on the Load screen.

  • You can view on-screen notifications that provide you with timely information about the state of the cluster. 

  • When you scale down the Query Engines, you reduce the capacity of the node, including the number of cores and memory. Conversely, when you scale up the Query Engines, you increase the capacity of the node by adding more cores and memory.

  • The Query Engines do not start for any ROLAP queries.  

  • During the transitioning period of Query Engines; such as scale-up, scale-down, or shut down; you can design and refine the semantic model because the Coordination Master is always up and running .