ScyllaDB Enterprise Release 2024.1.0

tzach · February 8, 2024, 1:40pm

ScyllaDB Enterprise Release 2024.1.0

The ScyllaDB team is pleased to announce the release of ScyllaDB Enterprise 2024.1.0 LTS, a production-ready ScyllaDB Enterprise Long Term Support Major Release.

With 2024.1 LTS out, ScyllaDB Enterprise 2022.1 and 2022.2 will support EOL in June 2024.

More information on ScyllaDB Long Term Support (LTS) policy is available here.

The ScyllaDB Enterprise 2024.1 release is based on ScyllaDB Open Source 5.4, and introduces significant performance improvements, additional Encryption At Rest (EaR) functionality, Repair Base Node Operations (RBNO) for all operations, and many more improvements and bug fixes.

Consistent schema management using Raft, introduced in 2023.1, will be enabled automatically on upgrade (more below).

In addition, 2024.1 includes enhancements to Encryption at Rest (EaR), including Amazon KMS integration, and default encryption at rest, first introduced in 2023.1.2. Together, these improvements allow you to easily use your own key for a cluster wide EaR.

Performance Improvements

2024.1 include many performance improvements which translate to:

Higher throughput per vCPU and server
Lower mean and p99 latency

ScyllaDB Enterprise 2024.1 vs ScyllaDB 2023.1

Throughput tests

2024.1 has more than x1.5 higher throughput compared to 2023.1!

In some cases, this can translate to %35 reduction in the number of vCPU required to support a similar load, which means a similar reduction in vCPU cost.

Latency tests

Latency tests are done in 50% of the max throughput tested.

As demonstrated below, the latency (both mean and p99) is 33% lower, even with the higher throughput.

Test Setup

Amazon EC2

instance_type_db: i3.2xlarge

instance_type_loader: c4.2xlarge

Test profiles:

Through tests: cassandra-stress [mixed|read|write] no-warmup cl=QUORUM duration=50m -schema ‘replication(factor=3)’ -mode cql3 native -rate threads=100 -pop ‘dist=gauss(1…30000000,15000000,1500000)’

ScyllaDB Enterprise 2024.1 vs ScyllaDB Open Source 5.4

ScyllaDB Enterprise 2024.1 is based on ScyllaDB Open Source 5.4, but includes Enterprise only performance improvement features. As shown below, throughput gain is significant, while latency is lower.

Test setups and parameters are equal to the above Enterprise tests.

Encryption at Rest (EaR) Enhancements

Scylla Enterprise has supported Encryption at Rest (EaR) for a long time. So far, one could store the keys for EaR locally, in an encrypted table, or in an external KMIP server.

This release Release adds:

Ability to use Amazon KMS to store and manage keys.
Ability to set default EaR parameters (including the new KMS) for all cluster tables.

Amazon KMS Integration for Encryption at Rest

Scylla Enterprise has supported Encryption at Rest (EaR) for a long time. So far, one could store the keys for EaR locally, in an encrypted table, or an external KMIP server.

Release 2023.1.2 added the ability to use Amazon KMS keys.

ScyllaDB can now use Customer Managed Key (CMK), stored in KMS, to create, encrypt, and decrypt Data Keys (DEK), which are then used to encrypt and decrypt the data in storage, such as SSTables, Commit logs, Batches, and hints logs.

KMS creates DEK from CMK

DEK (plain text version) is used to encrypt the data at rest.

Diagrams from: AWS KMS concepts - AWS Key Management Service

Before using KMS, you need to set KMS as a key provider and validate that ScyllaDB nodes have permission to access and use the CMK you created in KMS.

Once you do that, you can use the CMK in the CREATE and ALTER TABLE commands with KmsKeyProviderFactory, as follows

CREATE TABLE myks.mytable (……) WITH

scylla_encryption_options = {

‘cipher_algorithm’ : ‘AES/CBC/PKCS5Padding’,

‘secret_key_strength’ : 128,

‘key_provider’: ‘KmsKeyProviderFactory’,

‘kms_host’: ‘my_endpoint’

}

Where “my_key” point to a section in scylla.yaml

kms_hosts:

my_endpoint:

aws_use_ec2_credentials: true

aws_use_ec2_region: true

master_key: alias/MyScyllaKey

You can also use the KMS provider to encrypt System level data.

See more examples and info here.

Transparent Data Encryption

Transparent Data Encryption (TDE), adds a way to define Encryption at Rest parameters per cluster, not only per table.

This allows the system administrator to enforce encryption of all tables using the same master key, for example, from KMS, without specifying the encryption parameter per table.

For example, with the following in scylla.yaml, all tables will be encrypted using encryption parameters of my-kms1

user_info_encryption:

enabled: true

key_provider: KmsKeyProviderFactory,

kms_host: my_kms1

See more examples and info here.

Repair Based Node Operations (RBNO)

RBNO provides a more robust, reliable, and safer data streaming for node operations like node-replace and node-add/remove. In particular, a failed node operation can resume from the point it stopped – without sending data that has already been synced. In addition, with RBNO enabled, you don’t need to repair before or after node operations, such as replace or removenode.

Repair Based Node Operations were introduced as an experimental feature in ScyllaDB Open Source 4.0. They use repair to stream data for node-operations like replace, bootstrap and others.

In 2024.1, RBNO is enabled by default for all operations: remove node, rebuild, bootstrap and decommission. Replace node operation was already enabled by default in 2023.1.

See Repair Base Node Operations (RBNO) docs and Scylla Summit 2022 session by Asias He

Node Level Metrics

Most ScyllaDB metrics are per-shard, per-node, but not for a specific table. We now export some per-table metrics. These are exported once per node, not per shard, to reduce the number of metrics. #2198

Guardrails

Guardrails is a framework to protect ScyllaDB users and admins from common mistakes and pitfalls. In this release ScyllaDB includes a new guardrail on the replication factor. It is now possible to specify the minimum replication factor for new keyspaces via a new configuration item #8891.

This matches the same functionality in Apache Cassandra #CASSANDRA-14557

The new RF guardrails include the following configuration:

minimum_replication_factor_fail_threshold. Default -1 (Disabled)
minimum_replication_factor_warn_threshold. Default 3.

More Guardrails are expected in upcoming releases.

Security

In addition to the EaR Enhancements above, the following security features introduced in 2024.1:

Encryption at transit, TLS certificates:

It is now possible to use TLS certificates to authenticate and authorize a user to ScyllaDB. The system can be configured to derive the user role from the client certificate and derive the permissions the user has from that role. #10099

See more on certificate-authentication docs.

Default superuser name and password

It is now possible to specify the initial superuser name and password (salted) in scylla.yaml config or command line. Note that config values become redundant as soon as auth tables are initialized. See two new config parameters auth_superuser_name, auth_superuser_salted_password below.

FIPS Tolerant

ScyllaDB Enterprise can now run on FIPS enabled Ubuntu, using libraries that were compiled with FIPS enabled, such as OpenSSL, GnuTLS, and more.

Deprecated and removed features

As part of the CQLSH refactoring Python 2 is no longer required by ScyllaDB.
DateTieredCompactionStrategy was removed. Users should move to TimeWindowCompactionStrategy. It is already illegal to create new DateTieredCompactionStrategy tables. If you are still using DTCS, migrate to TWCS before upgrading!

Strongly Consistent Schema Management with Raft

Strongly Consistent Schema Management with Raft became the default for new clusters in ScyllaDB Enterprise 2023.1.

In this release it is enabled by default when upgrading existing clusters.

Note that when you have a two-DC cluster with the same number of nodes in each DC, the cluster will lose the quorum if one of the DCs is down. We recommend configuring three DCs per cluster to ensure that the cluster remains available and operational when one DC is down. See docs for more on Quorum Requirement.

If you are not sure, contact the ScyllaDB Support team for advice.

If you do not want to enable Raft, you should explicitly disable it in scylla.yaml of each node before the upgrade:

consistent_cluster_management: false

Source: Upgrade from 2023.1 to 2024.1 doc