System clusters configuration

When installing ECE, you will notice that several Elasticsearch clusters get created as part of the installation process. Those are the system clusters which are part of the ECE control plane. You must make sure that they are configured and sized correctly to ensure you have a production-ready installation.

We will review each cluster and provide recommendations to make sure that you are following best practices when starting your ECE journey.

ECE supports the concept of availability zones and, as described in the Playbook for production, requires three availability zones to be configured for the best fault tolerance. Alternatively, you can also configure ECE with two availability zones.

The system clusters are created when you install ECE or enable the user management feature, at which point they are not yet configured for high availability. As soon as you finish the installation process, you should change the configuration to ensure your system clusters are highly available and deployed across two or three availability zones. To configure your system clusters to be highly available, navigate to the Edit page for the cluster and change the number of availability zones under Fault tolerance.

For the logging-and-metrics cluster, you might want to also make sure that your Kibana instance and other components are deployed across multiple availability zones, since you will often access that cluster using Kibana. You can change the availability zones for Kibana on the same Edit page.

ECE lets you manage snapshot repositories, so that you can back up and restore your clusters. This mechanism allows you to centrally manage your snapshot repositories, assigning them to deployments, and restoring snapshots to an existing or new deployment. Since the admin-console-elasticsearch and security clusters have a key role in making sure your ECE installation is operational, it’s important that you configure a snapshot repository after you complete your ECE installation and enable snapshots for both the admin-console-elasticsearch and security clusters, so that you can easily restore them if needed.

As mentioned earlier, the logging-and-metrics cluster stores important information about your environment logs and metrics. There are also additional configurations provided out-of-the-box, such as index patterns, visualizations, and dashboards, that will require running an external script to recreate if you do not have a snapshot to restore from. We recommend that you also back up the logging-and-metrics cluster, though it is up to you to decide if that information should be available to be restored.

To configure snapshot repositories, see Add snapshot repository configurations.

Both the admin-console-elasticsearch and security clusters require relatively small amounts of RAM and almost no disk space, so increasing their size to 4 GB or 8 GB RAM per data node should be sufficient.

The logging-and-metric cluster should be sized according to the expected workload, which will affect the daily ingest size and which depends on the number of ECE hosts, deployments, and which logs will be enabled, such as slow logs, audit logs, and more. As with any other time-series data, you should also make sure to properly manage your indices and delete old indices based on your desired retention period.

In the case of the admin-console-elasticsearch and security system clusters, the team managing ECE and assigned to the platform admin role should have permission to change each system cluster configuration and also to access each cluster itself.

The logging-and-metrics cluster is different since, as an ECE admin, you likely want to provide users with access to the cluster in order to troubleshoot issues without your assistance, for example. In order to manage access to that cluster, you can configure roles that will provide access to the relevant indices, map those to users, and manage access to Kibana by leveraging the Elastic security integration with your authentication provider, such as LDAP, SAML, or AD. To configure one of those security realms, see LDAP, Active Directory or SAML.