With the PartitionGroupConfig you can control how primary and backups are going to be split up. In a multi member cluster, Hazelcast will place the backup partition on the same member as the primary partition to prevent data loss.
But in some cases this is not good enough; imagine that you have a 4 member cluster. And imagine that member1 and member2 run in datacenter-1 and member3/member5 in datacenter-2. If you want high availability, you want to all backups of the primary partitions in datacenter-1 or stored in datacenter-2. And you want the same high availability for the primary partitions in data center2.
With the PartitionGroupConfig this behavior can be controlled. Imagine that members in datacenter-1 have ip address 10.10.1.* and ip addresses of datacenter-2 is 10.10.2.* then you can make the following configuration:
10.10.1.* 10.10.2.*
The interfaces can be configured with wildcards '*' and ranges e.g. '10-20'. Each member-group can have as many interfaces as you want.
You can define as many groups as you want, Hazelcast will prevent that in a multi member cluster, backups are going to be stored in the same group as the primary.
You need to be careful with selecting overlapping groups, e.g.
10.10.1.1 10.10.1.2 10.10.1.1 10.10.1.3
In this example there are 2 groups, but because interface 10.10.1.1 is shared between the 2 groups, there is still a chance that this member is going to store primary and backups.
In the previous example we made use of custom group; we creates the groups manually and we configured the interfaces for these groups. There also is another option that doesn't give you the same fine grained control, but can prevent that on a single machine, running multiple HazelcastInstances, a primary and backup are going to be stored. This can be done using the HOST_AWARE group-type: