Deploying stand-alone Elasticsearch

Deploy Elasticsearch as a stand-alone instance in an HCL Connections deployment.

This task only applies to a stand-alone Elasticsearch deployment. If you installed Elasticsearch as part of the Component Pack for Connections, skip this task.

To ensure that the stand-alone Elasticsearch instance can work well together with Connections, deploy a multi-node cluster to provide the best performance, stability, and scalability. The topology of the cluster can be flexible, depending on factors such as the number of users and the amount of data, as well as the type of deployment that you used for Connections.

The recommended topology is a cluster with 3 nodes, where each nodes hosts an instance of the Elasticsearch master, client, and data services. This deployment model provides a clustered service with good performance, stability, data redundancy, and availability.

Installation packages
The required Elasticsearch version is 5.5.1. Download the appropriate installation packages for your preferred deployment method from the Elasticsearch 5.5.1 download page.
Deployment guides
The following deployment guides are available for Elasticsearch:
Tip: For an overview on installing a stand-alone Elasticsearch cluster, see the technote, Deploy an Elasticsearch cluster with 3 nodes and secured with SearchGuard. The technote is intended as an example and does not replace the instructions in this documentation.
Configuration guide
In addition, you can refer to the following guide on how to configure important system setting on all Elasticsearch nodes:

Important System Configuration

Deployment considerations

Memory/CPU/Storage
The Memory/CPU/Storage requirement of Elasticsearch instance relate to the deployment type of Connections:
  • Standard Connections deployment: For a standard deployment of Connections, the suggested requirement for a standard deployment (single node) of Elasticsearch:
    • 2.x GHZ, 8GB memory
    • JVM memory setting: "-Xms4g -Xmx4g"
    • 2 CPU
    • 150GB disk
  • HA Connections deployment: For a high-availability deployment of Connections, the suggested requirement for high-availability deployment (3 node cluster) of Elasticsearch:
    • 2.x GHZ, 16GB memory
    • JVM memory: "-Xms8g -Xmx8g"
    • 2 CPU
    • 200GB disk
Note: The standard recommendation is to allot 50% of the available memory to Elasticsearch heap, while leaving the other 50% free. Don’t set Xmx above the cutoff that the JVM uses for compressed object pointers; the exact cutoff varies but is near 32 GB.
Shard number
The default number of shards for this index is five. If you want to change this default, do so before the index is created, because the new value applies only to future indexes and does not affect existing indexes. If you use Elasticsearch to support the Metrics feature, make this change before deploying Metrics. Changing the number of shards after the Metrics component is already deployed requires you to create a new index.

Additional shards in an Elasticsearch index consume resources and can affect performance depending on how the shards are used. Change the default setting only when you have carefully weighed the advantages and disadvantages of doing so in your environment. You can refer to following guide for details on changing the default shard number for future indexes: Changing the number of shards for the Elasticsearch Metrics index .

Replica number
The main purpose of replicas is to provide failover. If the node holding a primary shard dies, a replica is promoted to the role of primary. Replica shards can also serve read requests; you can increase search performance by increasing the number of replicas, but only if you also add extra hardware. The default replica number is 1; you can increase it by updating the number_of_replicas index setting without requiring a service restart.
JVM heap size
By default, Elasticsearch configures the JVM to use a heap with a minimum and maximum size of 2 GB. When moving to production, it is important to configure the heap size to ensure that Elasticsearch has enough heap available. The standard recommendation is to allot 50% of the available memory to the Elasticsearch heap, while leaving the other 50% free. For information on setting the heap size for the Elasticsearch instance, see the article Set JVM heap size via jvm.options.