# ScyllaDB Enterprise Release 2024.1.0 **URL:** \ **Category:** Release Notes\ **Tags:** enterprise, enterprise-release, enterprise-2024-1\ **Created:** [February 8, 2024, 1:40pm UTC](https://forum.scylladb.com/t/scylladb-enterprise-release-2024-1-0/1292 "2024-02-08T13:40:34Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![tzach](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/tzach/32/172_2.png) [@tzach](https://forum.scylladb.com/u/tzach)\ **Post date:** [February 8, 2024, 1:40pm UTC](https://forum.scylladb.com/t/scylladb-enterprise-release-2024-1-0/1292/1 "2024-02-08T13:40:34Z")
# 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](https://www.scylladb.com/product/scylla-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](https://www.scylladb.com/2022/06/08/new-scylladb-enterprise-support-and-versioning/). The ScyllaDB Enterprise 2024.1 release is based on [ScyllaDB Open Source 5.4](https://forum.scylladb.com/t/release-scylladb-5-4-0-part-1/1084/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. Related Links - Read more about ScyllaDB Enterprise [here.](http://www.scylladb.com/product/scylla-enterprise/) - [Get ScyllaDB Enterprise 2024.1](https://www.scylladb.com/download/#enterprise) (customers only, or 30-day evaluation) - [Upgrade from ScyllaDB Enterprise 2023.1.x to 2024.1.y](https://enterprise.docs.scylladb.com/branch-2024.1/upgrade/upgrade-enterprise/upgrade-guide-from-2023.1-to-2024.1/upgrade-guide-from-2023.1-to-2024.1-generic.html) - [Upgrade from ScyllaDB Enterprise 2022.2.x to 2024.1.y](https://enterprise.docs.scylladb.com/branch-2024.1/upgrade/upgrade-enterprise/upgrade-guide-from-2022.2-to-2024.1) - [Upgrade from ScyllaDB Open Source 5.4 to ScyllaDB Enterprise 2024.1.x](https://enterprise.docs.scylladb.com/branch-2024.1/upgrade/upgrade-to-enterprise/upgrade-guide-from-5.4-to-2024.1) ScyllaDB Enterprise customers are encouraged to upgrade to ScyllaDB Enterprise 2023.1, and are welcome to contact our [Support Team](https://www.scylladb.com/product/support/) with questions. ## 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. ![](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/334855b046d1b2c16f7147fa28e108ee598aac44.png "Chart") ### 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. ![](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/be91a6a87b8c021ee6f33bfb92dd6012eb6690bc.png "Chart") 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. ![](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/e57b179404b7c65f08c43eb2e4bb4fb42a608512.png "Chart") ![](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/4059f57c6604adf05cde06f5b45499b69e879150.png "Chart") ## Encryption at Rest (EaR) Enhancements Scylla Enterprise has supported [Encryption at Rest](https://enterprise.docs.scylladb.com/stable/operating-scylla/security/encryption-at-rest.html) (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](https://aws.amazon.com/kms/) to store and manage keys. - Ability to set default EaR parameters (including the new KMS) for _all_ cluster tables. More on each below ### Amazon KMS Integration for Encryption at Rest Scylla Enterprise has supported [Encryption at Rest](https://enterprise.docs.scylladb.com/stable/operating-scylla/security/encryption-at-rest.html) (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](https://aws.amazon.com/kms/) keys. ScyllaDB can now use [Customer Managed Key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK), stored in KMS, to create, encrypt, and decrypt [Data Keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#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 ![](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/6f3aa5e158920b1640cadf4ae929ae1726e232c1.png) DEK (plain text version) is used to encrypt the data at rest. ![](https://us1.discourse-cdn.com/flex016/uploads/scylladb/original/1X/e73f6523be0cde5de890b0abe12c33665aff676d.png) Diagrams from: [AWS KMS keys - AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#data-keys) 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](https://enterprise.docs.scylladb.com/branch-2024.1/operating-scylla/security/encryption-at-rest.html#set-the-kms-host). ### 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](https://enterprise.docs.scylladb.com/stable/operating-scylla/security/encryption-at-rest.html#set-the-kms-host). ## 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)](https://opensource.docs.scylladb.com/branch-5.4/operating-scylla/procedures/cluster-management/repair-based-node-operation.html) docs and [Scylla Summit 2022 session by Asias He](https://www.scylladb.com/presentations/scylladb-lightning-talks-maintenance-improvements/) ## Node Level Metrics Most ScyllaDB metrics are per-shard, per-node, but not for a specific table. We now export some [per-table metrics](https://github.com/scylladb/scylladb/commit/cb3b808e3f0cdf27b0edded92e805559d74d7a69). These are exported once per node, not per shard, to reduce the number of metrics. [#2198](https://github.com/scylladb/scylladb/issues/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](https://github.com/scylladb/scylladb/commit/cdedc7905077ed94a3172759ab4f70af1013e061) for new keyspaces via a new configuration item [#8891](https://github.com/scylladb/scylladb/issues/8891). This matches the same functionality in Apache Cassandra [#CASSANDRA-14557](https://issues.apache.org/jira/browse/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](https://enterprise.docs.scylladb.com/branch-2024.1/operating-scylla/security/certificate-authentication.html) 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](https://github.com/scylladb/scylladb/issues/10099) See more on [certificate-authentication docs](https://enterprise.docs.scylladb.com/branch-2024.1/operating-scylla/security/certificate-authentication.html). ### 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](https://ubuntu.com/security/certifications/docs/fips), using libraries that were compiled with FIPS enabled, such as OpenSSL, GnuTLS, and [more](https://ubuntu.com/security/fips#modules). ## Deprecated and removed features - As part of the CQLSH refactoring Python 2 is no longer required by ScyllaDB. - DateTieredCompactionStrategy was [removed](https://github.com/scylladb/scylladb/commit/d6029a195e9d57717617d3aec951031bf18a5554). 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](https://enterprise.docs.scylladb.com/branch-2024.1/architecture/raft.html#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](https://enterprise.docs.scylladb.com/branch-2024.1/upgrade/upgrade-enterprise/upgrade-guide-from-2023.1-to-2024.1/upgrade-guide-from-2023.1-to-2024.1-generic.html) Related Posts > [@ScyllaDB Enterprise Release 2024.1.0 - Deployment and more improvements](https://forum.scylladb.com/t/scylladb-enterprise-release-2024-1-0-deployment-and-more-improvements/1293): > > See [2024.1 release notes](https://forum.scylladb.com/t/scylladb-enterprise-release-2024-1-0/1292)Deployment and install ScyllaDB Enterprise 2024.1 is officially supported on Rocky / RHEL 9. RHEL / CentOS 7 support is deprecated and won’t be supported going forward. ScyllaDB installation will now tune the OS core dump service to allow a [longer time](https://github.com/scylladb/scylladb/commit/bf27fdeaa2290c39dbc7160803cc30e82fb0ae10) to dump cores. This is necessary since ScyllaDB allocates all memory and therefore takes a longer time to dump core if an error is encountered. [#5430](https://github.com/scylladb/scylladb/issues/5430) The installer now [wipes filesystem signatures](https://github.com/scylladb/scylladb/commit/fdceda20ccb3d15456d5b2af8582a01bd89e3aad) from the individual disk… > [@ScyllaDB Enterprise Release 2024.1.0 - Tools, Configuration, Admin API and Monitoring](https://forum.scylladb.com/t/scylladb-enterprise-release-2024-1-0-tools-configuration-admin-api-and-monitoring/1294): > > [Scylla Enterprise 2024.1 Release Notes.](https://forum.scylladb.com/t/scylladb-enterprise-release-2024-1-0/1292)Tools The CQL shell, cqlsh, has been [separated into its own repository](https://github.com/scylladb/scylladb/commit/ef229a5d23e96f1ae5ac05d27db50a1e163291c4). As part of that change, cqlsh is now compatible with Python 3. CQLSh is now available as a [Docker image](https://hub.docker.com/r/scylladb/scylla-cqlsh), and in [PiPy](https://pypi.org/project/scylla-cqlsh/), allowing you to easily use it when you do not need the entire ScyllaDB server, for example with Scylla Cloud. The port option in [SSTableLoader](https://opensource.docs.scylladb.com/stable/operating-scylla/admin-tools/sstableloader.html) was [fixed](https://github.com/scylladb/scylladb/commit/5a9f75aac6aa1f48516d9c7721fb0afcc36ca3d4). The cassandra-stress benchmarking tool’s -log hdrfile=… option now works with [Java 11](https://github.com/scylladb/scylladb/commit/6d5c242651fa51dcee7732dcb9bbbdd9e5e2dd61) Scylla process --list-…