Hazelcast distributes key objects into partitions (blocks) using a consistent hashing algorithm and those partitions are assigned to nodes. That means an entry is stored in a node which is owner of partition to that entry's key is assigned. Number of total partitions is default 271 and can be changed with configuration property hazelcast.map.partition.count
. Along with those partitions, there are also copies of them as backups. Backup partitions can have multiple copies due to backup count defined in configuration, such as first backup partition, second backup partition etc. As a rule, a node can not hold more than one copy of a partition (ownership or backup). By default Hazelcast distributes partitions and their backup copies randomly and equally among cluster nodes assuming all nodes in the cluster are identical.
What if some nodes share same JVM or physical machine or chassis and you want backups of these nodes to be assigned to nodes in another machine or chassis? What if processing or memory capacities of some nodes are different and you do not want equal number of partitions to be assigned to all nodes?
You can group nodes in the same JVM (or physical machine) or nodes located in the same chassis. Or you can group nodes to create identical capacity.
We call these groups partition groups
. This way partitions are assigned to those partition groups instead of single nodes. And backups of these partitions are located in another partition group.
When you enable partition grouping, Hazelcast presents three choices to configure partition groups at the moments.
First one is to group nodes automatically using IP addresses of nodes, so nodes sharing same network interface will be grouped together.
<partition-group enabled="true" group-type="HOST_AWARE" />
Config config = ...; PartitionGroupConfig partitionGroupConfig = config.getPartitionGroupConfig(); partitionGroupConfig.setEnabled(true).setGroupType(MemberGroupType.HOST_AWARE);
Second one is custom grouping using Hazelcast's interface matching configuration. This way, you can add different and multiple interfaces to a group. You can also use wildcards in interface addresses.
<partition-group enabled="true" group-type="CUSTOM"> <member-group> <interface>10.10.0.*</interface> <interface>10.10.3.*</interface> <interface>10.10.5.*</interface> </member-group> <member-group> <interface>10.10.10.10-100</interface> <interface>10.10.1.*</interface> <interface>10.10.2.*</interface> </member-group </partition-group>
Config config = ...; PartitionGroupConfig partitionGroupConfig = config.getPartitionGroupConfig(); partitionGroupConfig.setEnabled(true).setGroupType(MemberGroupType.CUSTOM); MemberGroupConfig memberGroupConfig = new MemberGroupConfig(); memberGroupConfig.addInterface("10.10.0.*") .addInterface("10.10.3.*").addInterface("10.10.5.*"); MemberGroupConfig memberGroupConfig2 = new MemberGroupConfig(); memberGroupConfig2.addInterface("10.10.10.10-100") .addInterface("10.10.1.*").addInterface("10.10.2.*"); partitionGroupConfig.addMemberGroupConfig(memberGroupConfig); partitionGroupConfig.addMemberGroupConfig(memberGroupConfig2);
Third one is to give every member their own group. This gives the least amount of protection and is the default configuration for a Hazelcast cluster.
<partition-group enabled="true" group-type="PER_MEMBER" />
Config config = ...; PartitionGroupConfig partitionGroupConfig = config.getPartitionGroupConfig(); partitionGroupConfig.setEnabled(true).setGroupType(MemberGroupType.PER_MEMBER);