Today we announce the release of Scylla Manager 1.3.1, a management system that automates maintenance tasks on a Scylla cluster. This release provides support for encrypted CQL communication with Scylla nodes and improves SSH stability. We are also shipping an official, publicly available, Scylla Manager Docker image. Most importantly, while past versions of Scylla Manager supported only Scylla Enterprise clusters, Scylla Manager 1.3.1 now also supports management of Scylla Open Source clusters of up to 5 nodes.
Scylla Manager joins a growing list of Scylla management and monitoring software, including the open source Scylla Monitoring Stack, which provides cluster metrics and graphical dashboards via Prometheus and Grafana.
Scylla Manager provides a robust suite of tools aligned with Scylla’s shard-per-core architecture for the easy and efficient management of Scylla clusters. Scylla Manager performs a regular health check on the nodes of a server, ensuring awareness of any node degradation or downtime. Scylla Manager can also control cluster repairs on a per-shard basis, ensuring repair speed and impact on performance is optimized. This gives maximum repair parallelism on a node and shortens overall repair time without generating unnecessary load.
- Download Now! (Scylla Open Source users)
- Download Now! (Scylla Enterprise Users)
- Scylla Manager 1.3 documentation
- Running Scylla Manager on Docker
- Upgrade from Scylla Manager 1.3.0 to 1.3.1
Scylla Open Source users will now have the ability to automate tasks and other work using Scylla Manager. Previously, Scylla Manager was available only to Scylla Enterprise users. With the new license, you can use all the Scylla Manager features with clusters running Scylla Open Source NoSQL Database. The only limitation is that the cluster size that you connect to is limited to 5 nodes. The full license agreement can be read at: https://www.scylladb.com/scylla-manager-software-license-agreement/.
With the introduction of a new license, and to make it easier for open source users, we are now shipping the official Scylla Manager Docker image. The image is available on Docker Hub https://hub.docker.com/r/scylladb/scylla/scylla-manager. It is based on a Centos 7 image, and contains both the Scylla Manager server and sctool. Running Scylla Manager has never been easier. Now you can run it with just a few lines of
Scylla Manager 1.3 introduced a Health Check functionality that monitors CQL connectivity on cluster nodes. This release extends support for clusters with client server encryption enabled. Below is a sample Scylla configuration that can be used to enable client server encryption on a Scylla node. For more details on enabling encryption refer to our security documentation: https://docs.scylladb.com/operating-scylla/security/client_node_encryption/
# enable or disable client/server encryption.
# truststore: <none, use system trust>
# require_client_auth: False
# priority_string: <none, use default>
Scylla Manager Health Check will work out of the box with encrypted CQL provided that
require_client_auth is not set on the node. Users may check if encryption is enabled by using sctool status command that now has a new SSL column that informs the user if a given node has encryption enabled or not.
sctool status -c prod-cluster
│ CQL │ SSL │ Host │
│ UP (2ms) │ ON │ 192.168.100.11 │
│ UP (3ms) │ ON │ 192.168.100.12 │
│ UP (5ms) │ ON │ 192.168.100.13 │
│ CQL │ SSL │ Host │
│ UP (12ms) │ ON │ 192.168.100.21 │
│ UP (11ms) │ ON │ 192.168.100.22 │
│ UP (13ms) │ ON │ 192.168.100.23 │
If Scylla requires the client to present a certificate (
client_encryption_options.require_client_auth set to
true) then the certificate and key must be provided to Scylla Manager. This is typically done when adding a cluster, you may also update an existing cluster with the information.
sctool cluster update -c=prod-cluster --ssl-user-cert-file <path to client certificate> --ssl-user-key-file <path to key associated with the certificate>
SSL/TLS for Scylla Manager’s data
When storing Scylla Manager data on a remote cluster you may also enable encryption. In order to do so, find the database section in the configuration file and set ssl parameter to
# Scylla Manager database, used to store management data.
# Enable or disable client/server encryption.
If you want to specify client certificate, disable validation or use a custom certificate authority to validate node’s certificate. This is not an issue, the ssl configuration section, that is just below the database section, contains more SSL options.
# Optional custom client/server encryption options.
# CA certificate used to validate server cert. If not set will use the host's root CA set.
# Verify the hostname and server cert.
# validate: true
# Client certificate and key in PEM format. It has to be provided when
# client_encryption_options.require_client_auth=true is set on server.
The database configuration section also gained local_dc parameter that should be set if working with a multi-dc cluster. This will instruct the database driver to prioritize hosts in that datacenter when selecting a host to query.
Scylla Manager communicates with the Scylla API using HTTP over an SSH tunnel. If a connection from Scylla Manager to a Scylla node goes through a proxy, and the connection is idle then the proxy may decide to drop it. To avoid this situation we are introducing a keepalive mechanism. The keepalive is controlled by two parameters, the
server_alive_interval that specifies the interval in which the keepalive messages are being sent, and
server_alive_count_max that specifies the maximal number of failed attempts. This is very similar to how you can configure the ssh unix command with
ServerAliveCountMax options. The keepalive setting can be modified globally in the new ssh section in the Scylla Manager configuration file.
# SSH global configuration, SSH is used to access scylla nodes. Username and
# identity file are specified per cluster with sctool.
# Alternative default SSH port.
# port: 22
# Interval to send keepalive message through the encrypted channel and
# request a response from the server.
# server_alive_interval: 15s
# The number of server keepalive messages which may be sent without receiving
# any messages back from the server. If this threshold is reached while server
# keepalive messages are being sent, ssh will disconnect from the server,
# terminating the session.
# server_alive_count_max: 3