Ich habe eine Anwendung mit einem gestreckten Hazelcast Cluster auf 2 Rechenzentren gleichzeitig eingesetzt. Die beiden Rechenzentren sind in der Regel beide voll funktionsfähig, aber manchmal wird einer von ihnen für SDN-Upgrades vollständig aus dem Netzwerk genommen.Stellen Sie die Replikation zwischen Rechenzentren mit Hazelcast sicher
Ich beabsichtige, den Cluster so zu konfigurieren, dass jede Hauptpartition von einem DC mindestens 2 Backups - eins im anderen Cluster und eins im aktuellen Cluster hat.
Zu diesem Zweck zeigte mir die Dokumentation in Richtung Partition Gruppen (http://docs.hazelcast.org/docs/2.3/manual/html/ch12s03.html). Die Enterprise WAN-Replikation schien genau das zu sein, was wir wollten, aber leider ist diese Funktion für die kostenlose Version von Hazelcast nicht verfügbar.
Meine Konfiguration ist wie folgt:
NetworkConfig network = config.getNetworkConfig();
network.setPort(hzClusterConfigs.getPort());
JoinConfig join = network.getJoin();
join.getMulticastConfig().setEnabled(hzClusterConfigs.isMulticastEnabled());
join.getTcpIpConfig()
.setMembers(hzClusterConfigs.getClusterMembers())
.setEnabled(hzClusterConfigs.isTcpIpEnabled());
config.setNetworkConfig(network);
PartitionGroupConfig partitionGroupConfig = config.getPartitionGroupConfig()
.setEnabled(true).setGroupType(PartitionGroupConfig.MemberGroupType.CUSTOM)
.addMemberGroupConfig(new MemberGroupConfig().addInterface(hzClusterConfigs.getClusterDc1Interface()))
.addMemberGroupConfig(new MemberGroupConfig().addInterface(hzClusterConfigs.getClusterDc2Interface()));
config.setPartitionGroupConfig(partitionGroupConfig);
Die configs verwendet wurden zunächst:
clusterMembers=host1,host2,host3,host4
clusterDc1Interface=10.10.1.*
clusterDc2Interface=10.10.1.*
jedoch mit diesem Satz von configs auf jeden Fall ausgelöst wird, wenn die Komponenten des Clusters zu ändern, ein zufälliger Knoten im Cluster gestartet Protokollierung "Keine Mitgliedsgruppe ist verfügbar Partition Eigentümerschaft zuweisen" jede zweite Sekunde (wie hier: https://github.com/hazelcast/hazelcast/issues/5666). Darüber hinaus ergab die Überprüfung des vom PartitionService in JMX offengelegten Status, dass trotz des scheinbar erfolgreichen Clusterstatus keine Partitionen tatsächlich gefüllt wurden.
Als solche habe ich Hostnamen mit den entsprechenden IPs ersetzt und die Konfiguration funktionierte. Die Partitionen wurden erfolgreich erstellt und es funktionierten keine Knoten.
Das Problem hier ist, dass die Boxen als Teil eines A/B-Bereitstellungsprozesses erstellt werden und ihre IPs automatisch aus einem Bereich von 244 IPs beziehen. Das Hinzufügen all dieser 244 IPs scheint ein bisschen viel zu sein, selbst wenn es programmatisch von Chef und nicht manuell erfolgen würde, wegen des gesamten Netzwerkrauschens, das es mit sich bringen würde. Die Überprüfung bei jeder Bereitstellung mit einem Telnet-basierten Client, welcher Rechner auf dem hazelcast-Port zuhört, erscheint ebenfalls etwas problematisch, da sich die IPs von einer Bereitstellung zu einer anderen unterscheiden und wir in eine Situation geraten würden, in der ein Teil der Knoten liegt Im Cluster wird eine bestimmte Mitgliederliste und ein anderer Teil eine andere Mitgliederliste zur gleichen Zeit haben.
Die Verwendung von Hostnamen wäre meines Erachtens die beste Lösung, da wir uns auf die DNS-Auflösung verlassen würden und unsere IP-Auflösung nicht zur Bereitstellungszeit benötigen würden.
Kennt jemand eine Problemumgehung für das Gruppenkonfigproblem? Oder vielleicht eine Alternative, um dasselbe Verhalten zu erreichen?