Clustering¶
Notitie
Deze functie is momenteel een technische preview met de volgende tijdelijke beperkingen:
Als een cluster verloren gaat (quorum gaat verloren), is de enige manier van herstel een fabrieksreset + restore. Zorg ervoor dat je vaak een back-up maakt. Toekomstige versies zullen middelen bevatten om gegevens op schijf te herstellen.
Een actieve/passieve opstelling om clusters met twee knooppunten te ondersteunen, door gebruik te maken van etcd Learner of Mirror, is nog niet beschikbaar.
Systeemtijd tussen nodes moet voorlopig handmatig gesynchroniseerd worden. Een toekomstige versie zal automatische kloksynchronisatie bevatten.
Vanaf NetHSM 4.0 wordt clustering ondersteund om gegevens tussen verschillende NetHSM’s direct te synchroniseren. Dit ondersteunt een hoge frequentie van sleutelgeneraties, realiseert hoge beschikbaarheid en load balancing. Een NetHSM cluster is gebaseerd op etcd die het Raft consensus algoritme gebruikt voor sterke consistentie. Dit zorgt ervoor dat de gegevens (bijv. sleutels) altijd correct zijn in alle NetHSM’s.
Maak jezelf vertrouwd met deze technologie en de beperkingen ervan voordat je een NetHSM cluster opzet om onbedoelde uitval en gegevensverlies te voorkomen. In aanvulling op dit document kun je ook etcd’s documentatie raadplegen.
Operational Redundancy¶
We noemen een “knooppunt” een NetHSM waarvan verwacht wordt dat het deel uitmaakt van een cluster. Een cluster van N nodes zal blijven werken zolang tenminste (N/2)+1 nodes gezond en bereikbaar zijn. Dat minimale aantal gezonde, bereikbare knooppunten wordt het quorum genoemd.
Dit impliceert de volgende scenario’s.
Eén node valt uit en het quorum is nog steeds bereikt¶
In een cluster met 3 knooppunten zullen, als er één knooppunt uitvalt (crasht of onbereikbaar wordt door netwerkomstandigheden), de twee andere knooppunten blijven werken en verzoeken bedienen.
Als het defecte knooppunt nog steeds gezond is (het was bijvoorbeeld gewoon een netwerkprobleem), dan zal het tijdens de isolatie onbruikbaar zijn (zelfs niet alleen-lezen).
Als het knooppunt echter herstelt, zal het netjes hersynchroniseren met de rest van het cluster en weer operabel worden, zonder gegevens te verliezen.
Als het zich niet herstelt, moet het uit de cluster worden verwijderd (zie volgende sectie), in de fabriek worden gereset en het verbindingsproces helemaal opnieuw worden doorlopen.
Er vindt een netwerkscheiding plaats en het quorum is nog steeds bereikt¶
Dit is slechts een veralgemening van het vorige scenario. In een cluster van 5 knooppunten waar zich bijvoorbeeld 3 knooppunten op een fysieke locatie A bevinden en 2 knooppunten op een andere locatie B, zou een netwerkprobleem dat A en B isoleert het volgende betekenen:
De 3 knooppunten op locatie A voldoen aan het quorum (3 in dit geval), dus ze blijven werken.
De 2 knooppunten op locatie B zijn niet het quorum halen (nog steeds 3), dus ze zullen stoppen met werken (zelfs alleen-lezen).
Als het netwerkprobleem is opgelost, zullen de 2 knooppunten netjes terug aansluiten bij de 3 anderen.
Het Quorum is duurzaam verloren¶
Een storing waardoor alle subsets van het cluster het quorum verliezen, zorgt ervoor dat het cluster en zijn gegevens volledig verloren gaan, tenzij de storing wordt opgelost. In dit geval moeten de knooppunten in de fabriek worden gereset en moet een back-up worden hersteld.
Dit kan bijvoorbeeld gebeuren als een enkel knooppunt faalt in een cluster met 2 knooppunten (waar het quorum 2 is). In deze situatie kan het defecte knooppunt achteraf niet netjes uit het cluster verwijderd worden, omdat het overgebleven gezonde knooppunt al onbruikbaar is omdat het quorum verloren is gegaan.
Daarom wordt geadviseerd om altijd een oneven aantal nodes in een cluster te hebben en om vaak een back-up te maken.
Om duidelijk te zijn, tijdelijk quorum verliezen (bijvoorbeeld als je alle nodes van een cluster samen herstart, of een tijdelijke netwerkstoring nodes isoleert) is geen probleem: zodra genoeg nodes opnieuw verbonden zijn (zonder handmatig opnieuw te moeten verbinden) om quorum te bereiken, zal het cluster zijn normale werking hervatten. Alleen permanente storingen zoals netwerkpartities, netwerkfoutconfiguraties, authenticatieproblemen of hardwarestoringen vereisen handmatige actie.
Zie voor meer informatie etcd’s FAQ.
2-node cluster¶
Een actief/passief cluster met twee knooppunten wordt nog niet ondersteund en zal in een toekomstige versie worden toegevoegd. We raden aan om een 3de node te introduceren, ofwel een 3de NetHSM of een etcd “getuige” die op elke host kan draaien. Zie de volgende sectie “Getuige”.
Getuige¶
De aard van clusteren met etcd maakt het betrouwbaarder naarmate er meer nodes in het cluster zijn. Zoals uitgelegd in de Operationele redundantie sectie, zouden clusters idealiter minstens 3 nodes moeten hebben om ruimte te hebben om te falen, aangezien een cluster met 2 nodes volledig zal falen als er maar één faalt.
De functie is echter zo ontworpen dat je geen volledig, echt NetHSM-apparaat aan je cluster hoeft toe te voegen om een stabiel aantal knooppunten te bereiken. In plaats daarvan kun je zelf een “getuige” knooppunt implementeren en toevoegen. Zo’n knooppunt is gewoon een instantie van etcd die op een machine naar keuze (of in een container) draait en verbonden is met het cluster. Het wordt herkend als een normaal knooppunt van de echte apparaten in het cluster en ontvangt alle gegevens en updates van apparaten (maar natuurlijk kun je er geen HSM-bewerkingen mee uitvoeren - het slaat alleen gegevens op).
Security Considerations¶
Het witness knooppunt (of iedereen die daar toegang toe heeft) heeft direct toegang tot de opslag backend van alle knooppunten in het cluster (je kunt bijvoorbeeld alle entries en bijbehorende waarden dumpen met etcdctl get "/" "0").
Echter, met uitzondering van de config versie (/config/version, die altijd “1” moet zijn), worden strikt alle waarden versleuteld (met ofwel een apparaatsleutel voor knooppuntspecifieke waarden of de domeinsleutels voor andere waarden), waardoor de vertrouwelijkheid van gevoelige gegevens wordt gegarandeerd.
Merk echter op dat een kwaadwillende node:
schrijf rotzooi als de waarde voor elk item in de winkel, waardoor knooppunten niet kunnen decoderen (wat kan leiden tot crashes voor sommige systeemregels).
lijstnamen zoals gebruikers, namespaces en sleutels, die je misschien als gevoelig beschouwt.
Creating a Cluster¶
Elk cluster zal initieel starten met een enkel knooppunt. Nieuwe knooppunten voegen zich één voor één bij het cluster.
Preparing Nodes¶
Netwerkverkeer tussen nodes wordt versleuteld en geverifieerd met behulp van hun TLS-certificaat.
Alle nodes waarvan verwacht wordt dat ze deel uitmaken van hetzelfde cluster moeten eerst een gemeenschappelijke Certificate Authority (CA) installeren waarmee ze kunnen verifiëren dat andere nodes legitiem zijn.
In het volgende gaan we ervan uit dat alle knooppunten pas beschikbaar en operationeel zijn.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
Een CA aanmaken en installeren¶
Gebruikers moeten op hun eigen manier en volgens hun eigen operationele beperkingen een CA aanmaken, en ervoor zorgen dat deze op zijn minst het gebruik van de sleutel keyCertSign toestaat.
Een minimale CA kan bijvoorbeeld aangemaakt worden met openssl:
$ openssl genrsa -out CA.key 2048 # create a key
$ openssl req -x509 -new -nodes -key CA.key -sha256 -days 1825 -out CA.pem -addext keyUsage=critical,keyCertSign
Deze CA moet nu op elk knooppunt geïnstalleerd worden.
To do this, first generate a Certificate Signing Request (CSR) from the node with the /config/tls/csr.pem endpoint (refer to the API documentation).
Notitie
Om knooppunten goed te authenticeren verwacht de clustering backend (etcd) dat elk knooppunt een certificaat heeft met een goed gevuld Subject Alt Names (SAN) veld. In het bijzonder knooppunten waarvan verwacht wordt dat ze alleen via hun IP bereikt kunnen worden, moeten een goed IP SAN in hun certificaat hebben. IP SAN’s kunnen worden aangevraagd voor het CSR door “IP:” voor de namen te zetten, zoals in openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Gegeven het verkregen CSR (laten we het nethsm.csr noemen), kunnen we er een certificaat voor genereren, klaar om geïnstalleerd te worden. Bijvoorbeeld met openssl:
$ openssl x509 -req -days 1825 -in nethsm.csr -CA CA.pem -copy_extensions copy \
-CAkey CA.key -out new_cert.pem -set_serial 01 -sha256
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
Tenslotte kan de CA (CA.pem) nu geïnstalleerd worden met het /config/tls/cluster-ca.pem eindpunt (raadpleeg de API documentatie). Dit is alleen mogelijk als het geïnstalleerde TLS-certificaat door de CA is ondertekend. Anders wordt de bewerking geweigerd.
Notitie
Dit proces moet voor elk knooppunt herhaald worden.
Klok Synchronisatie¶
Zorg ervoor dat elke node voorzien is van een nauwkeurige systeemtijd. Als dat niet het geval is, pas dan hun klokken aan met het /config/time eindpunt.
Adding a New Node¶
Het toevoegen van een knooppunt aan een cluster gebeurt in twee stappen:
de toevoeging aan het cluster registreren (via een van de leden)
vertel het nieuwe knooppunt om zich aan te sluiten
Configure a Backup Passphrase¶
Zorg er eerst voor dat er een reservewachtzin is geconfigureerd op het knooppunt dat zal worden gebruikt om een nieuwe joiner te registreren (zie de API-documentatie van het /config/backup-passphrase eindpunt).
Een nieuwe node registreren¶
Waarschuwing
Het registreren van een knooppunt introduceert onmiddellijk een nieuw knooppunt in het cluster en wijzigt de quorumdrempel, zelfs als het knooppunt zich nog niet daadwerkelijk heeft aangesloten. Dit kan de bestaande knooppunten onbruikbaar maken totdat het nieuwe knooppunt zich daadwerkelijk heeft aangesloten. Raadpleeg de API documentatie en de Operationele redundantie sectie van dit document.
Houd het IP-adres bij de hand van het knooppunt dat zich zal aansluiten. De volledige URL (ook wel peer URL genoemd in etcd terminologie) van dat knooppunt zal https://<IP_of_node>:2380 zijn (bijvoorbeeld https://192.168.1.1:2380).** De poort **moet 2380 zijn, dus zorg ervoor dat een firewall tussen de knooppunten TCP-verkeer op die poort toestaat.
Je kunt dubbel controleren of de URL correct is door GET /cluster/members aan te roepen op het knooppunt waarvan verwacht wordt dat het lid wordt. Dit zou slechts één lid moeten tonen: zichzelf.
Registreer vervolgens die verwachte URL op een bestaand knooppunt van het cluster (als je nog geen cluster hebt, doe dit dan op de NetHSM die als eerste knooppunt van het cluster zal dienen). Dit wordt gedaan met behulp van het POST /cluster/members eindpunt (raadpleeg de API documentatie), waarbij een JSON body met de URL wordt doorgegeven.
Als het lukt, retourneert dit een JSON-tekst van het formulier:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
die informatie bevat die nodig is voor het nieuwe knooppunt om zich bij het cluster aan te sluiten. Het bevat in het bijzonder een lijst met alle leden van het cluster (waarbij het lid met een lege naam de nieuwe toetreder is). Het bevat ook de domeinsleutel die versleuteld is door zowel de ontgrendel- als de back-uppasphrase - er moet dus eerder een back-uppasphrase zijn geconfigureerd.
Bewaar die reactie voor de volgende stap.
Daadwerkelijk lid worden van de cluster¶
Neem het antwoord van de laatste stap en voeg er een backupPassphrase veld aan toe dat de reservewachtzin bevat van het knooppunt waarop de nieuwe toetreder is geregistreerd, en geef die gegevens door aan een aanroep naar POST /cluster/join (raadpleeg de API documentatie) op het knooppunt waarvan verwacht wordt dat het toetreedt.
Ervan uitgaande dat zowel het cluster als het knooppunt elkaar kunnen bereiken, zal dit de daadwerkelijke join uitvoeren, waarbij de gegevens van de nieuwe joiner worden gewist om in plaats daarvan zijn status te synchroniseren met die van het cluster.
Afhankelijk van de netwerk- en clustercondities kan deze operatie enkele tientallen seconden duren. Als deze bewerking onmiddellijk mislukt (bijv. het cluster was niet bereikbaar of de authenticatie is mislukt), dan wordt de toestand van dit knooppunt niet gewist en wordt de join teruggedraaid. Maar zodra een eerste join succesvol is, is deze operatie definitief en kan alleen ongedaan worden gemaakt door een fabrieksreset.
Als deze join succesvol is, komt het knooppunt in een Locked status terecht en moet het ontgrendeld worden met de unlock passphrase van het knooppunt dat gebruikt werd voor de registratie. Daarna kan de ontgrendelingswachtzin gewijzigd worden (ontgrendelingswachtzinnen blijven knooppuntspecifiek en worden niet gedeeld tussen knooppunten).
Notitie
Zelfs nadat de join geslaagd is, als de databank van het cluster groot is of als het cluster druk is, kan het enige tijd duren voordat de nieuwe joiner zijn toestand volledig gesynchroniseerd heeft. Gedurende die tijd kunnen alle knooppunten (inclusief in het bijzonder de nieuwe joiner) minder of niet reageren. Vooral de nieuwe joiner kan in het begin fouten teruggeven wanneer hij bijvoorbeeld probeert te ontgrendelen. Geef het in dat geval wat tijd en probeer het opnieuw.
Adding a Witness Node¶
Prepare a Witness¶
Je hebt een omgeving nodig met etcd v3.6 beschikbaar, met (minstens) een IPv4-adres dat bereikbaar is voor de andere leden van je cluster. TCP-verkeer van en naar poort 2380 moet worden toegestaan.
Maak een lege map aan waar etcd zijn gegevens zal opslaan en schrijf het pad op (we gebruiken /var/etcd/data). Zorg ervoor dat de gebruiker die het proces zal starten lees- en schrijfrechten heeft in de map.
Breng het CA-certificaat dat gebruikt wordt om knooppunten in het cluster te authenticeren over naar de machine. Je zou er een aangemaakt moeten hebben in de Een CA aanmaken en installeren sectie. We slaan het op in /var/etcd/CA.pem.
Je moet dan een certificaat aanmaken voor de getuige en het ondertekenen met de CA zodat het kan communiceren met zijn peers. Dit kan bijvoorbeeld via openssl:
# Create a key
$ openssl genrsa -out witness.key 2048
# Create a CSR with a SAN that corresponds to the witness's IP or hostname
$ openssl req -new -sha256 -key own.key -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=witness" \
-addext "subjectAltName=IP:172.22.1.3" --out witness.csr
# Sign it
$ openssl x509 -req -days 1825 -in witness.csr -CA CA.pem -copy_extensions copy \
-CAkey CA.key -out witness.pem -set_serial 01 -sha256
Sla de resulterende witness.key en witness.pem ook op in /var/etcd.
Register Witness to Cluster¶
Volg de normale instructies van de sectie Een nieuwe node registreren om het bestaande cluster te informeren over de toevoeging van een nieuw lid met de opgegeven URL(‘s).
Schrijf het antwoord van het cluster op: het zou de lijst van clusterleden en een joiner kit moeten bevatten (je hebt dit deel niet nodig).
Configure etcd¶
In tegenstelling tot NetHSM’s die automatisch een knooppuntnaam voor zichzelf kiezen (met behulp van het apparaat-ID), moet je een naam kiezen voor elke getuige die je toevoegt, zorg ervoor dat de namen uniek zijn. We zullen “witness1” gebruiken in de volgende voorbeelden.
Met het antwoord van de NetHSM op de registratie van de getuige, maak je variabelen van het formulier:
export ETCD_NAME="witness1"
export ETCD_DATA_DIR="/var/etcd/data"
export ETCD_INITIAL_CLUSTER="peer1=url1,peer1=url2,peer2=url1,peer2=url2,..."
export ETCD_INITIAL_ADVERTISE_PEER_URLS="my_url1,my_url2,..."
Ervan uitgaande dat het NetHSM antwoord is opgeslagen in een response.json bestand, kun je deze laatste twee variabelen automatisch genereren met de volgende jq expressies:
export ETCD_INITIAL_CLUSTER=$(jq --raw-output '[.members[] | ["\(if .name == "" then "witness1" else .name end)=\(.urls[])"]] | flatten | join(",")' < response.json)
export ETCD_INITIAL_ADVERTISE_PEER_URLS=$(jq --raw-output '.members[] | select(.name=="") | .urls | join(",")' < response.json)
Bijvoorbeeld met het voorbeeldantwoord in het gedeelte Een nieuwe Node registreren:
ETCD_NAME="witness1"
ETCD_DATA_DIR="/var/etcd/data"
ETCD_INITIAL_CLUSTER="witness1=https://172.22.1.3:2380,9ZVNM2MNWP=https://172.22.1.2:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://172.22.1.3:2380"
Maak tenslotte een etcd.conf.yml bestand aan door het sjabloonbestand te gebruiken dat is geleverd in docs/etcd_witness.conf.template:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
Dit zou je een bestand van het formulier moeten geven:
name: witness1
data-dir: /var/etcd/data
log-level: warn
log-format: console
listen-peer-urls: https://0.0.0.0:2380
listen-client-urls: http://localhost:2379
initial-advertise-peer-urls: https://172.22.1.3:2380
advertise-client-urls: http://localhost:2379
initial-cluster: witness1=https://172.22.1.3:2380,9ZVNM2MNWP=https://172.22.1.2:2380
initial-cluster-state: 'existing'
peer-transport-security:
cert-file: witness.pem
key-file: witness.key
client-cert-auth: true
trusted-ca-file: CA.pem
skip-client-san-verification: true
Start etcd¶
Start etcd op de gewenste manier (handmatig, systemd service, container, etc.) en wijs het naar het configuratiebestand dat in de vorige stap is gemaakt:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Je zou moeten zien dat het opstart, zich bij het cluster aansluit en de gegevens inhaalt. Na enige tijd zou je moeten kunnen controleren of het gezond is met de etcdctl client:
etcdctl get /config/version
Deze sleutel moet bestaan en “1” bevatten.
Zorg ervoor dat dit proces blijft draaien, want het is nu een goed lid van je cluster. Als je het buiten gebruik moet stellen, verwijder het dan eerst op de juiste manier uit het cluster (zie de specifieke sectie). Als het bereikbare IP-adres verandert, werk dan de URL van het cluster bij.
Operating a Cluster¶
Back-up en herstel¶
De back-upbewerking werkt hetzelfde als zonder cluster en kan vanaf elk knooppunt van het cluster worden aangevraagd. Er wordt een back-up gemaakt van gegevens voor het hele cluster, inclusief node-specifieke velden (deze worden echter genegeerd tenzij de back-up op een niet geprovisioneerd knooppunt wordt teruggezet).
Een back-up die op een cluster is gemaakt, kan op hetzelfde cluster worden teruggezet, zelfs als er sindsdien enkele nodes zijn toegevoegd of verwijderd. Zulke terugzettingen op operationele clusters hebben geen invloed op de configuratiewaarden (alleen sleutels, gebruikers, naamruimten), net als alle andere gedeeltelijke terugzettingen.
Als je een back-up herstelt op een knooppunt zonder voorzieningen, worden de knooppuntspecifieke velden (zoals netwerkconfiguratie, certificaten, enzovoort) hersteld van het knooppunt dat werd gebruikt om de back-up te maken.
Het terugzetten van een grote back-up kan het cluster enige tijd overspoelen, terwijl het knooppunt dat de restore uitvoert wijzigingen doorstuurt naar de anderen.
Deze bewerking blijft compatibel met back-ups die op eerdere versies van de NetHSM zijn gemaakt.
Notitie
Het terugzetten op een knooppunt A van een back-up gemaakt op een ander knooppunt Z met een andere domeinsleutel zal de domeinsleutel van A correct herschrijven, zoals voorheen. Maar als A in een cluster met node B zat, zal B onbruikbaar worden omdat de domeinsleutel van Z niet hersteld zal worden op B.
Met andere woorden, voer alleen een restore uit in een cluster met back-ups die in hetzelfde cluster zijn gemaakt (hoewel er sindsdien nodes verwijderd of toegevoegd kunnen zijn). Als je een buitenlandse back-up op een node wilt terugzetten, verwijder deze dan eerst veilig uit zijn cluster, reset hem dan in de fabriek en zet de back-up terug.
Een node netjes verwijderen¶
Zolang een deel van het cluster nog aan het quorum voldoet, kan elk van zijn leden gebruikt worden om een ander knooppunt uit het cluster te verwijderen, ongeacht of dit knooppunt al onbereikbaar is of naar verwachting zal zijn.
Je moet eerst de ID weten van de node die je wilt verwijderen, door alle nodes op te sommen via GET /cluster/members en de juiste te zoeken.
Daarna kan het worden verwijderd door DELETE /cluster/members/<id> aan te roepen. Als het betreffende knooppunt nog gezond was, zal dit het isoleren van de rest van het cluster en het onbruikbaar maken.
Software Updates in Clusters¶
Toekomstige updates zullen gemarkeerd worden als “cluster-veilig” (dit zou de meerderheid moeten zijn) of “cluster-onveilig”.
Cluster-veilige updates kunnen worden toegepast op knooppunten die deel uitmaken van een cluster zonder ze eerst uit het cluster te verwijderen. Maar zoals met alle operaties, moet je ervoor zorgen dat je dit op één node per keer doet, en in een cluster waar het verwijderen van een node het quorum niet onderschrijdt (bijvoorbeeld als de update mislukt).
Cluster-onveilige updates moeten worden toegepast op geïsoleerde nodes. Je moet het cluster ontmantelen (knooppunten één voor één verwijderen), alle knooppunten op één na in de fabriek resetten, de update op elk knooppunt toepassen en vervolgens alle geresette knooppunten laten aansluiten op het overgebleven knooppunt.
Zorg ervoor dat u een back-up maakt voordat u dergelijke bewerkingen uitvoert.
Een bestaand cluster herconfigureren¶
Changing the Cluster CA¶
Een bestaand cluster (met twee of meer nodes) kan zijn cluster-CA niet wijzigen terwijl het in werking is. Als je dit certificaat moet wijzigen: kies een knooppunt, verwijder alle andere knooppunten, werk de CA bij en laat de andere leden zich weer aansluiten.
Changing the Network Configuration of Nodes¶
Het wijzigen van de netwerkconfiguratie van een knooppunt (bijvoorbeeld het wijzigen van het IP-adres) zal automatisch de andere knooppunten informeren over de update. Je moet er echter voor zorgen dat je zulke updates alleen uitvoert op een enkel knooppunt tegelijk en in een cluster waar het verlies van dat knooppunt het quorum niet zou verliezen.