Today we announce the release of ScyllaDB Manager 1.3.1, a management system that automates maintenance tasks on a ScyllaDB cluster. This release provides support for encrypted CQL communication with ScyllaDB nodes and improves SSH stability. We are also shipping an official, publicly available, ScyllaDB Manager Docker image. Most importantly, while past versions of ScyllaDB Manager supported only ScyllaDB Enterprise clusters, ScyllaDB Manager 1.3.1 now also supports management of ScyllaDB Open Source clusters of up to 5 nodes.
ScyllaDB Manager joins a growing list of ScyllaDB management and monitoring software, including the open source ScyllaDB Monitoring Stack, which provides cluster metrics and graphical dashboards via Prometheus and Grafana.
ScyllaDB Manager provides a robust suite of tools aligned with ScyllaDB’s shard-per-core architecture for the easy and efficient management of ScyllaDB clusters. ScyllaDB Manager performs a regular health check on the nodes of a server, ensuring awareness of any node degradation or downtime. ScyllaDB 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! (ScyllaDB Open Source users)
- Download Now! (ScyllaDB Enterprise Users)
- ScyllaDB Manager 1.3 documentation
- Running ScyllaDB Manager on Docker
- Upgrade from ScyllaDB Manager 1.3.0 to 1.3.1
ScyllaDB Open Source users will now have the ability to automate tasks and other work using ScyllaDB Manager. Previously, ScyllaDB Manager was available only to ScyllaDB Enterprise users. With the new license, you can use all the ScyllaDB Manager features with clusters running ScyllaDB Open Source. 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 ScyllaDB 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 ScyllaDB Manager server and sctool. Running ScyllaDB Manager has never been easier. Now you can run it with just a few lines of
ScyllaDB 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 ScyllaDB configuration that can be used to enable client server encryption on a ScyllaDB 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>
ScyllaDB 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 ScyllaDB 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 ScyllaDB 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 ScyllaDB Manager’s data
When storing ScyllaDB 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
# ScyllaDB 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.
ScyllaDB Manager communicates with the ScyllaDB API using HTTP over an SSH tunnel. If a connection from ScyllaDB Manager to a ScyllaDB 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 ScyllaDB 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