Skip to main content
Calico Enterprise 3.19 (latest) documentation

Log storage recommendations

Log storage recommendations​

Calico Enterprise installs an Elasticsearch cluster for storing logs internally.

We use Elastic Cloud on Kubernetes to install and manage the cluster. All you need to do is provide at least one node with suitable storage.

The cluster is configured to use a StorageClass called tigera-elasticsearch. You must set up this StorageClass before installing Calico Enterprise.

We recommend using local disks for storage when possible (this offers the best performance), but high performance remote storage can also be used. Examples of suitable remote storage include AWS SSD type EBS disks, or GCP PD-SSDs.

caution

Do not use Amazon EFS, it is not compatible with Elasticsearch.

For information on how to configure storage, please consult the Kubernetes or OpenShift documentation.

  • If you're going to use local disks, you may find the sig-storage local static provisioner useful. It can create and manage PersistentVolumes by watching for disks mounted in a certain directory.
  • If you're planning on using cloud storage, ensure you have set up the cloud provider integration.

Sizing​

Many factors need to be considered when sizing this cluster:

  • Scale and nature of the traffic patterns in the cluster
  • Retention periods for logs
  • Aggregation and export interval configuration
  • Desired replication factor for data

For tailored recommendations on sizing the cluster, please contact Tigera support.

Example production topology​

5 Elasticsearch nodes, 2 replicas, each node with 32GB RAM, 4 CPU cores and 1TB of storage.

We recommend that you configure your cluster to have:

  • At least 3 nodes
  • At least 1 replica
  • At least 8GB or ram per node, preferably higher
  • The node count should exceed the replica count by at least 2

Relationship between nodes and replicas

Elasticsearch stores data in shards. A replica adds a copy of each shard to the cluster. It must not be on the same node as the original, therefore you need a node count higher than the replica count.

Replicas and cluster health

An Elasticsearch cluster health gives a user a quick impression of the state of the cluster:

  • Green health: the cluster is fully functional and every shard has at least the number of configured replicas
  • Yellow health: the cluster is available for most actions, but there are unavailable shards or shards with too few replicas
  • Red health: There is a serious issue with your cluster, check the troubleshoot page

Pod disruption

The ECK Operator will automatically modify the pod disruption budget according to the cluster health. When the Elasticsearch cluster is yellow or red, it will not tolerate the removal of any extra node. For this reason we recommend that the node count is at least 2 higher than the replica count. Otherwise, there is no tolerance for removing/restarting a node.

Next Steps​