4.14. Coordinator High Availability#

SEP offers the ability to enable high availability (HA) of the coordinator. In the event the coordinator becomes unavailable, the cluster automatically switches over to a new coordinator and continues to accept new queries.

Configuring HA#

Coordinator high availability (HA) is only supported via the Starburst CloudFormation template in AWS. In order to fully utilize this capability set the HACoordinatorsCount field of the Stack creation form (EC2 Configuration section) to a value greater than 1. Setting it to 2 or 3 should suffice most scenarios.

HA is ALWAYS enabled. However in the when HACoordinatorsCount is set to 1, there is no hot standby. In that case SEP eventually creates a new coordinator. This may take several minutes. If HACoordinatorsCount equals 2 or more, then there are hot standby coordinators and the fail-over switch is faster.

Note: It is possible to disable automatic failover of the coordinator by setting the``KeepCoordinatorNode`` CFT parameter to yes.

Coordinator IP Address#

The Coordinator is accessible via attached Elastic Network Interface (ENI) which has a static auto-assigned private IP address. After you launch the Starburst CloudFormation cluster stack, note the PrestoCoordinatorURL and PrestoSSH keys in the stack’s Outputs section/tab in the AWS CloudFormation console.

PrestoCoordinatorURL is the Presto Web UI and REST API endpoint address, which you use to point your Presto CLI or JDBC/ODBC drivers or access the Presto Web UI from your browser. PrestoSSH notes the SSH connection details to manually log onto the current coordinator.

Fail Over Scenario(s)#

In general in the event of a failure of the current coordinator the HA mechanism kicks in and performs the following steps:

  1. Terminate the old/failed coordinator EC2 instance

  1. Attach Elastic Network Interface to the new coordinator

  1. Launch a new stand-by coordinator (within a couple minutes)

The core fail-over process (steps 1 and 2) should complete in under a minute, from the time when the coordinator started failing to respond. It is a matter of seconds once the coordinator is identified to be in a failed state, but there is some built-in time buffer so that we don’t act on a false alarm. When Elastic Network Interface is attached to the new coordinator, it is almost immediately available to clients.

In real life it may happen that a coordinator “dies” because one of the following:

  • The node becomes unresponsive (e.g. hardware issues, OS level and network issues).

  • The node disappears, might be terminated by some account admin or by AWS.

  • The Presto process may exit because of an fatal error.

  • The Presto process may become unresponsive, e.g. because of a long full garbage collection taking place.

In all those scenarios, after a short grace period, the failed coordinator, if still exists, is terminated. Then a new coordinator is chosen among the hot standby instances and has coordinator ENI attached to it. Clients should re-issue the failed queries when the new coordinator becomes accessible. A new hot standby coordinator is launched in the background to take place of the one that has just been assigned.

High-Availability Considerations#

  • When Presto is deployed in a custom setup (e.g. with a bootstrap script which sets up security) make sure the HTTP port (unsecured) is open and accessible from localhost. You may want to restrict access to it by binding it to localhost only or otherwise securing external access e.g. via the AWS Security Group assigned to the cluster. See HA with HTTPS enabled for more information.

  • Coordinator ENI has private IP address which is accessible only within the same VPC as the cluster stack. This means in order to connect to the coordinator you need to initiate the connection from a client either on EC2 machine deployed in the same VPC or connected to the VPC via a VPN.

  • Note that all queries, that were running when the coordinator failed, fail to complete. You need to restart these queries on the new coordinator. Similarly the SSH connections to the old coordinator needs to be re-established after the fail-over.

  • When connecting via SSH, depending on your SSH configuration you may see login issues like REMOTE HOST IDENTIFICATION HAS CHANGED etc, due to the fact that the underlying host has changed, and the key’s fingerprint that was previously accepted has changed. You may want to not verify the host keys at all, by adding -o StrictHostKeyChecking=no to the SSH command or deleting the key from your known_hosts file and accepting the new one.

HA with HTTPS enabled#

The coordinator’s health is checked by polling Presto locally via HTTP. This is why you need to have the coordinator’s HTTP port open even if you configured Presto to use HTTPS, regardless how many coordinators are configured (even if only one). Workers do not need to have their HTTP port open, although we recommend using HTTP for internal cluster communication (unless HTTPS is explicitly required for internal communication as well). Note that using HTTPS for internal communication may have substantial impact on overall cluster performance, because all intermediate data needs to be encrypted and decrypted. The overhead of HTTPS depends on the amount of data sent over network and actual ciphers being used.

Example Presto config.properties fragment:

http-server.http.enabled=true
http-server.https.enabled=true
... other `https` related configs

Additionally you should block non-local HTTP access to the coordinator by configuring the AWS Security Group assigned to the cluster accordingly.