hazelcast / hazelcast-aws

AWS EC2 discovery plugin for hazelcast
Other
38 stars 50 forks source link

DEPRECATED: hazelcast-aws plugin has been merged with hazelcast!

Since version 5.0 hazelcast includes hazelcast-aws and does not require additional dependency. For details about running Hazelcast on AWS consider the documentation.

Hazelcast Discovery Plugin for AWS

This repository contains a plugin which provides the automatic Hazelcast member discovery in the Amazon Web Services Platform.

Requirements

Embedded mode

To use Hazelcast embedded in your application, you need to add the plugin dependency into your Maven/Gradle file (or use hazelcast-all which already includes the plugin). Then, when you provide hazelcast.xml/hazelcast.yaml as presented below or an equivalent Java-based configuration, your Hazelcast instances discover themselves automatically.

Maven

<dependency>
  <groupId>com.hazelcast</groupId>
  <artifactId>hazelcast-aws</artifactId>
  <version>${hazelcast-aws.version}</version>
</dependency>

Gradle

compile group: "com.hazelcast", name: "hazelcast-aws", version: "${hazelcast-aws.version}"

Understanding AWS Discovery Strategy

Hazelcast member starts by fetching a list of all running instances filtered by the plugin parameters (region, etc.). Then, each instance is checked one-by-one with its IP and each of the ports defined in the hz-port property. When a member is discovered under IP:PORT, then it joins the cluster.

Note that this plugin supports Hazelcast Zone Aware feature.

The plugin is prepared to work for both AWS EC2 and AWS ECS/Fargate environments. However, note that requirements and plugin properties vary depending on the environment you use.

EC2 Configuration

The plugin works both for Hazelcast Member Discovery and Hazelcast Client Discovery.

EC2 Hazelcast Member Discovery

Make sure that:

Then, you can configure Hazelcast in one of the following manners.

XML Configuration

<hazelcast>
  <network>
    <join>
      <multicast enabled="false"/>
      <aws enabled="true">
        <tag-key>my-ec2-instance-tag-key</tag-key>
        <tag-value>my-ec2-instance-tag-value</tag-value>
      </aws>
    </join>
  </network>
</hazelcast>

YAML Configuration

hazelcast:
  network:
    join:
      multicast:
        enabled: false
      aws:
        enabled: true
        tag-key: my-ec2-instance-tag-key
        tag-value: my-ec2-instance-tag-value

Java-based Configuration

config.getNetworkConfig().getJoin().getMulticastConfig().setEnabled(false);
config.getNetworkConfig().getJoin().getAwsConfig().setEnabled(true)
      .setProperty("tag-key", "my-ec2-instance-tag-key")
      .setProperty("tag-value", "my-ec2-instance-tag-value");

The following properties can be configured (all are optional).

Note that if you don't specify any of the properties, then the plugin uses the IAM Role assigned to EC2 Instance and forms a cluster from all Hazelcast members running in same region.

EC2 Hazelcast Client Configuration

Hazelcast Client discovery parameters are the same as mentioned above.

If Hazelcast Client is run outside AWS, then you need to always specify the following parameters:

Note also that your EC2 instances must have public IP assigned.

Following are example declarative and programmatic configuration snippets.

XML Configuration

<hazelcast-client>
  <network>
    <aws enabled="true">
      <access-key>my-access-key</access-key>
      <secret-key>my-secret-key</secret-key>
      <region>us-west-1</region>
      <tag-key>my-ec2-instance-tag-key</tag-key>
      <tag-value>my-ec2-instance-tag-value</tag-value>
      <use-public-ip>true</use-public-ip>
    </aws>
  </network>
</hazelcast-client>

YAML Configuration

hazelcast-client:
  network:
    aws:
      enabled: true
      access-key: my-access-key
      secret-key: my-secret-key
      region: us-west-1
      tag-key: my-ec2-instance-tag-key
      tag-value: my-ec2-instance-tag-value
      use-public-ip: true

Java-based Configuration

clientConfig.getNetworkConfig().getAwsConfig()
      .setEnabled(true)
      .setProperty("access-key", "my-access-key")
      .setProperty("secret-key", "my-secret-key")
      .setProperty("region", "us-west-1")
      .setProperty("tag-key", "my-ec2-instance-tag-key")
      .setProperty("tag-value", "my-ec2-instance-tag-value")
      .setProperty("use-public-ip", "true");

ECS/Fargate Configuration

The plugin works both for Hazelcast Member Discovery (forming Hazelcast cluster) and Hazelcast Client Discovery.

Note: for the detailed description, check out Hazelcast Guides: Getting Started with Embedded Hazelcast on ECS.

ECS Hazelcast Member Discovery

Make sure that your IAM Task Role has the following permissions:

Then, you can configure Hazelcast in one of the following manners. Please note that 10.0.*.* value depends on your VPC CIDR block definition.

XML Configuration

<hazelcast>
  <network>
    <join>
      <multicast enabled="false"/>
      <aws enabled="true" />
    </join>
    <interfaces enabled="true">
      <interface>10.0.*.*</interface>
    </interfaces>
  </network>
</hazelcast>

YAML Configuration

hazelcast:
  network:
    join:
      multicast:
        enabled: false
      aws:
        enabled: true
    interfaces:
      enabled: true
      interfaces:
        - 10.0.*.*

Java-based Configuration

config.getNetworkConfig().getJoin().getMulticastConfig().setEnabled(false);
config.getNetworkConfig().getJoin().getAwsConfig().setEnabled(true);
config.getNetworkConfig().getInterfaces().setEnabled(true).addInterface("10.0.*.*");

The following properties can be configured (all are optional).

Note that if you don't specify any of the properties, then the plugin discovers all Hazelcast members running in the current ECS cluster.

ECS Hazelcast Client Configuration

Hazelcast Client discovery parameters are the same as mentioned above.

If Hazelcast Client is run outside ECS cluster, then you need to always specify the following parameters:

Note also that your ECS Tasks must have public IPs assigned and your IAM Task Role must have ec2:DescribeNetworkInterfaces permission.

Following are example declarative and programmatic configuration snippets.

XML Configuration

<hazelcast-client>
  <network>
    <aws enabled="true">
      <access-key>my-access-key</access-key>
      <secret-key>my-secret-key</secret-key>
      <region>eu-central-1</region>
      <cluster>my-cluster</cluster>
      <use-public-ip>true</use-public-ip>
    </aws>
  </network>
</hazelcast-client>

YAML Configuration

hazelcast-client:
  network:
    aws:
      enabled: true
      access-key: my-access-key
      secret-key: my-secret-key
      region: eu-central-1
      cluster: my-cluster
      use-public-ip: true

Java-based Configuration

clientConfig.getNetworkConfig().getAwsConfig()
      .setEnabled(true)
      .setProperty("access-key", "my-access-key")
      .setProperty("secret-key", "my-secret-key")
      .setProperty("region", "eu-central-1")
      .setProperty("cluster", "my-cluster")
      .setProperty("use-public-ip", "true");

ECS Environment with EC2 Discovery

If you use ECS on EC2 instances (not Fargate), you may also set up your ECS Tasks to use host network mode and then use EC2 discovery mode instead of ECS. In that case, your Hazelcast configuration would look as follows.

hazelcast:
  network:
    join:
      multicast:
        enabled: false
      aws:
        enabled: true
        host-header: ec2
    interfaces:
      enabled: true
      interfaces:
        - 10.0.*.*

All other parameters can be used exactly the same as described in the EC2-related section.

AWS Elastic Beanstalk

The plugin works correctly on the AWS Elastic Beanstalk environment. While deploying your application into the Java Platform, please make sure your Elastic Beanstalk Environment Configuration satisfies the following requirements:

High Availability

By default, Hazelcast distributes partition replicas (backups) randomly and equally among cluster members. However, this is not safe in terms of high availability when a partition and its replicas are stored on the same rack, using the same network, or power source. To deal with that, Hazelcast offers logical partition grouping, so that a partition itself and its backup(s) would not be stored within the same group. This way Hazelcast guarantees that a possible failure affecting more than one member at a time will not cause data loss. The details of partition groups can be found in the documentation: Partition Group Configuration

In addition to two built-in grouping options ZONE_AWARE and PLACEMENT_AWARE, you can customize the formation of these groups based on the network interfaces of members. See more details on custom groups in the documentation: Custom Partition Groups.

Multi-Zone Deployments

If ZONE_AWARE partition group is enabled, the backup(s) of a partition is always stored in a different availability zone. Hazelcast AWS Discovery plugin supports ZONE_AWARE feature for both EC2 and ECS.

NOTE: When using the ZONE_AWARE partition grouping, a cluster spanning multiple Availability Zones (AZ) should have an equal number of members in each AZ. Otherwise, it will result in uneven partition distribution among the members.

XML Configuration

<partition-group enabled="true" group-type="ZONE_AWARE" />

YAML Configuration

hazelcast:
  partition-group:
    enabled: true
    group-type: ZONE_AWARE

Java-based Configuration

config.getPartitionGroupConfig()
    .setEnabled(true)
    .setGroupType(MemberGroupType.ZONE_AWARE);

Partition Placement Group Deployments

AWS Partition Placement Group (PPG) ensures low latency between the instances in the same partition of a placement group and also provides availability since no two partitions share the same underlying hardware. As long as the partitions of a PPG contain an equal number of instances, it will be good practice for Hazelcast clusters formed within a single zone.

If EC2 instances belong to a PPG and PLACEMENT_AWARE partition group is enabled, then Hazelcast members will be grouped by the partitions of the PPG. For instance, the Hazelcast members in the first partition of a PPG named ppg will belong to the partition group of ppg-1, and those in the second partition will belong to ppg-2 and so on. Furthermore, these groups will be specific to each availability zone. That is, they are formed with zone names as well: us-east-1-ppg-1, us-east-2-ppg-1, and the like. However, if a Hazelcast cluster spans multiple availability zones then you should consider using ZONE_AWARE.

Cluster Placement Group Deployments

AWS Cluster Placement Group (CPG) ensures low latency by packing instances close together inside an availability zone. If you favor latency over availability, then CPG will serve your purpose.

NOTE: In the case of CPG, using PLACEMENT_AWARE has no effect, so can use the default Hazelcast partition group strategy.

Spread Placement Group Deployments

AWS Spread Placement Groups (SPG) ensures high availability in a single zone by placing each instance in a group on a distinct rack. It provides better latency than multi-zone deployment, but worse than Cluster Placement Group. SPG is limited to 7 instances, so if you need a larger Hazelcast cluster within a single zone, you should use PPG instead.

NOTE: In the case of SPG, using PLACEMENT_AWARE has no effect, so can use the default Hazelcast partition group strategy.

XML Configuration

<partition-group enabled="true" group-type="PLACEMENT_AWARE" />

YAML Configuration

hazelcast:
  partition-group:
    enabled: true
    group-type: PLACEMENT_AWARE

Java-based Configuration

config.getPartitionGroupConfig()
    .setEnabled(true)
    .setGroupType(MemberGroupType.PLACEMENT_AWARE);

Autoscaling

Hazelcast is prepared to work correctly within the autoscaling environments. Note that there are two specific requirements to prevent Hazelcast from losing data:

Read about details in the blog post: AWS Auto Scaling with Hazelcast.

AWS EC2 Deployment Guide

You can download the white paper "Amazon EC2 Deployment Guide for Hazelcast IMDG" here.

How to find us?

In case of any question or issue, please raise a GH issue, send an email to Hazelcast Google Groups or contact as directly via Hazelcast Gitter.