Clustering¶
Nota
This feature is currently a technical preview with the following temporary limitation:
Active/passive setup to support two-node clusters, either by utilizing etcd Learner or Mirror, is not yet available. Use a Witness node instead.
NetHSM 4.0 supporta il clustering per sincronizzare direttamente i dati tra diversi NetHSM. Questo supporta l’alta frequenza di generazione delle chiavi, realizza l’alta disponibilità e il bilanciamento del carico. Un cluster NetHSM è basato su etcd che utilizza l’algoritmo di consenso Raft per una forte coerenza. Questo garantisce che i dati (ad esempio le chiavi) siano sempre corretti in tutti i NetHSM.
Prima di configurare un cluster NetHSM, è necessario familiarizzare con questa tecnologia e con i suoi vincoli per evitare interruzioni accidentali e perdite di dati. Oltre a questo documento, si consiglia di consultare anche la documentazione di etcd.
Operational Redundancy¶
Chiameremo «nodo» un NetHSM che dovrebbe far parte di un cluster. Un cluster di N nodi continuerà a funzionare finché almeno (N/2)+1 nodi sono sani e raggiungibili. Questo numero minimo di nodi sani e raggiungibili è chiamato quorum.
In un cluster che scende al di sotto di questa soglia (ad esempio a causa di un problema di rete), non è possibile eleggere alcun leader e l’istanza locale di etcd su ciascun nodo non è più in grado di eseguire operazioni di lettura e scrittura. Ciò comporta i seguenti scenari.
Un nodo si guasta e il quorum è ancora raggiunto¶
In un cluster a tre nodi, se un nodo si guasta (si blocca o diventa irraggiungibile a causa delle condizioni della rete), gli altri due nodi continueranno a lavorare e a servire le richieste.
If the failed node is still healthy (e.g. it was just a network problem), it will be in the Failed state while isolated, refusing normal operations (not even read-only).
However if the node recovers, it will cleanly resynchronize with the rest of the cluster and exit the Failed state, resuming normal operation without losing data.
Se non si ripristina, deve essere rimosso dal cluster e, a quel punto, o viene sottoposto a un’operazione di recupero per accedere ai propri dati (ma non farà più parte del cluster), oppure viene ripristinato alle impostazioni di fabbrica e deve ripetere la procedura di aggiunta al cluster da zero.
Si verifica una partizione della rete e il quorum è ancora raggiunto¶
Questa è solo una generalizzazione dello scenario precedente. In un cluster di 5 nodi in cui, ad esempio, 3 nodi si trovano in una posizione fisica A e 2 nodi in un’altra posizione B, un problema di rete che isola A e B significherebbe quanto segue:
I 3 nodi della posizione A rispettano il quorum (3 in questo caso), quindi continuano a operare.
The 2 nodes in location B are not meeting the quorum (still 3), so they will enter the Failed state and stop operating (even read-only).
Se il problema di rete viene risolto, i 2 nodi si uniranno nuovamente agli altri 3 in modo pulito.
In altre parole, nel caso peggiore di partizione di rete (in un cluster con un numero dispari di nodi), la metà più grande del cluster rimarrà operativa, mentre quella più piccola sarà inoperativa fino a quando la partizione non sarà risolta.
Il quorum è perso in modo duraturo¶
A failure causing all subsets of the cluster to lose quorum will render the cluster completely inoperable (all remaining nodes will be in the Failed state), unless the failure is resolved. In this case, manual recovery <clustering.html#recovering-a-failed-node> must be performed.
Questo può accadere, ad esempio, se un singolo nodo si guasta in un cluster di 2 nodi (dove il quorum è 2). In questa situazione, il nodo guasto non può essere rimosso dal cluster in modo pulito, perché il nodo sano rimanente è già inutilizzabile in quanto ha perso il quorum.
Per questo motivo si consiglia di avere sempre un numero dispari di nodi in un cluster e di eseguire spesso il backup.
Per essere chiari, temporaneamente perdere il quorum (ad esempio, se si riavviano tutti i nodi di un cluster insieme, o se un guasto temporaneo della rete isola i nodi) non è un problema: una volta che un numero sufficiente di nodi è stato ricollegato (senza doversi ricongiungere manualmente) per raggiungere il quorum, il cluster riprenderà il suo normale funzionamento. Solo i guasti permanenti, come partizioni di rete, errate configurazioni di rete, problemi di autenticazione o guasti hardware, richiedono un’azione manuale.
Per ulteriori informazioni, consultare le FAQ di etcd.
Cluster a 2 nodi¶
Un cluster attivo/passivo a due nodi non è ancora supportato e sarà aggiunto in una versione futura. Si consiglia di introdurre un terzo nodo, o un terzo NetHSM o un «testimone» etcd che potrebbe essere gestito su qualsiasi host. Vedere la sezione successiva «Witness».
Testimone¶
La natura del clustering con etcd rende più affidabile il numero di nodi presenti nel cluster. Come spiegato nella sezione Ridondanza operativa, i cluster dovrebbero idealmente avere almeno 3 nodi per avere spazio per i guasti, dato che un cluster di 2 nodi fallirà completamente se solo uno si guasta.
Tuttavia, il design della funzione è tale che non è necessario aggiungere un dispositivo NetHSM completo e reale al cluster per raggiungere un numero stabile di nodi. Si può invece distribuire e aggiungere un nodo «testimone». Tale nodo è solo un’istanza di etcd in esecuzione sulla macchina di vostra scelta (o in un container) e connessa al cluster. Verrà riconosciuto come un normale nodo dai dispositivi reali del cluster e riceverà tutti i dati e gli aggiornamenti dai dispositivi (ma naturalmente non sarà in grado di eseguire alcuna operazione HSM con esso - memorizza solo i dati).
Security Considerations¶
Il nodo testimone (o chiunque vi abbia accesso) ha accesso diretto al backend di memorizzazione di tutti i nodi del cluster (ad esempio, è possibile scaricare tutte le voci e i valori corrispondenti con etcdctl get "/" "0").
Tuttavia, con l’eccezione della versione di configurazione (/config/version, che dovrebbe essere sempre «1»), tutti i valori sono rigorosamente criptati (con una chiave di dispositivo per i valori specifici del nodo o con le chiavi di dominio per gli altri), garantendo la riservatezza dei dati sensibili.
Si noti tuttavia che un nodo maligno può:
Write garbage as the value for any entry in the store, which will cause nodes to fail decrypting it (which may lead to crashes for some system entries).
List entry names such as users, namespaces and keys, which you may consider sensitive.
Creating a Cluster¶
Ogni cluster partirà inizialmente da un singolo nodo. I nuovi nodi si uniranno al cluster uno alla volta.
Preparing Nodes¶
Il traffico di rete tra i nodi viene crittografato e autenticato utilizzando il loro certificato TLS.
Tutti i nodi che si prevede facciano parte dello stesso cluster devono prima installare un’autorità di certificazione (CA) comune che consenta loro di verificare che gli altri nodi siano legittimi.
Di seguito, si ipotizza che tutti i nodi siano appena forniti e operativi.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
Creazione e installazione di una CA¶
Gli utenti devono creare una CA con i propri mezzi e in base ai propri vincoli operativi, assicurandosi che consenta almeno l’uso della chiave keyCertSign.
Ad esempio, una CA minima può essere creata con 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
Questa CA deve essere installata su ogni nodo.
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).
Nota
To properly authenticate nodes, the clustering backend (etcd) expects that each node has a certificate with a properly filled Subject Alt Names (SAN) field.
Nodes are expected to be reached only via their IP and need to have a proper IP SAN in their certificate.
IP SANs can be requested for the CSR by prefixing «IP:» to the names, as in openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Se desideri utilizzare un’autorità di certificazione pubblica per firmare i tuoi certificati, i tuoi nodi devono utilizzare indirizzi IP pubblici. Ciò è dovuto a un requisito di sicurezza che vieta a un’autorità di certificazione pubblica di emettere certificati con un indirizzo IP privato nel campo IP SAN.
Dato il CSR ottenuto (chiamiamolo nethsm.csr), possiamo generare un certificato per esso, pronto per essere installato. Ad esempio con 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).
Infine, la CA (CA.pem) può ora essere installata con l’endpoint /config/tls/cluster-ca.pem (fare riferimento alla documentazione dell’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Questo è possibile solo quando il certificato TLS installato è firmato dalla CA. In caso contrario, l’operazione verrà rifiutata.
Nota
Questo processo deve essere ripetuto per ogni nodo.
Sincronizzazione dell’orologio¶
Assicurarsi che ogni nodo sia stato configurato con un’ora di sistema corretta, preferibilmente utilizzando NTP/NTS anziché l’impostazione manuale dell’ora. Ciò può essere effettuato tramite Time e NTS/NTP.
Adding a New Node¶
Adding a node to a cluster is done in three steps:
Register the addition to the cluster (through any one of its members)
Tell the new node to join
Una volta che avrà recuperato il ritardo, promuovi il nodo da «allievo» a membro a pieno titolo
Configure a Backup Passphrase¶
Per prima cosa, assicurarsi che una passphrase di backup sia configurata sul nodo che sarà usato per registrare un nuovo joiner (vedere la documentazione API dell’endpoint /config/backup-passphrase).
Registrazione di un nuovo nodo¶
Tenere a portata di mano l’IP del nodo che si unirà. L’URL completo (chiamato anche peer URL nella terminologia etcd) di tale nodo sarà https://<IP_of_node>:2380 (ad esempio https://192.168.1.1:2380). La porta deve essere 2380, quindi assicurarsi che qualsiasi firewall tra i nodi permetta il traffico TCP su tale porta.
Si può verificare che l’URL sia corretto chiamando GET /cluster/members sul nodo che ci si aspetta si unisca. Questo dovrebbe elencare un solo membro: se stesso.
Quindi registrare l’URL atteso su qualsiasi nodo esistente del cluster (se non si ha ancora un cluster, farlo sul NetHSM che servirà come nodo iniziale del cluster). Questo viene fatto usando l’endpoint POST /cluster/members (fare riferimento alla documentazione dell’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), passandogli un corpo JSON contenente l’URL.
In caso di successo, restituisce un corpo JSON del modulo:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
],
"learner": true
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
],
"learner": false
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
che contiene le informazioni necessarie al nuovo nodo per unirsi al cluster. In particolare, elenca tutti i membri del cluster (dove il membro con un nome vuoto è il nuovo membro). Contiene anche la chiave di dominio criptata sia dalla passphrase di sblocco che da quella di backup, per cui deve essere stata configurata una passphrase di backup.
Nota
Si noti nella risposta sopra riportata che il nuovo nodo è un «learner»: ora può connettersi al cluster e ricevere dati da esso, ma non può partecipare finché non verrà promosso, come verrà spiegato di seguito.
Sebbene questo concetto di «learner» comporti un passaggio aggiuntivo (la promozione), consente un funzionamento più sicuro del cluster, poiché eventuali problemi relativi al nuovo nodo non possono causare instabilità all’intero cluster prima della sua promozione.
Conservate la risposta per la fase successiva.
Joining the Cluster as a Learner¶
Prendere la risposta dell’ultimo passo e aggiungervi un campo backupPassphrase contenente la passphrase di backup del nodo su cui è stato registrato il nuovo joiner, e passare questi dati a una chiamata a POST /cluster/join (fare riferimento alla documentazione dell’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) sul nodo che ci si aspetta si unisca.
Avvertimento
La chiamata a POST /cluster/join rimarrà in sospeso fino a quando il nuovo nodo non verrà promosso manualmente (vedi sotto). Si tratta di un comportamento normale. Quando la chiamata restituisce un esito positivo, significa che l’aggiunta e la promozione sono andate a buon fine.
Assuming both the cluster and the node can reach each other, this will enact the actual join, wiping the data on the new joiner to instead synchronize its state with that of the cluster. If this operation fails immediately (e.g. the cluster was not reachable or authentication failed), this node’s state will not be wiped and the join will be reverted. However as soon as a first join is successful, this operation is final and can only be reverted by a factory reset.
In questa fase il nuovo nodo è stato aggiunto come nodo “ ”: si sta sincronizzando con il cluster ma non è ancora operativo. D’altra parte, eventuali problemi relativi al nodo in questa fase non causeranno problemi al cluster, rendendo questa operazione sicura.
L’ultimo passo per completare l’adesione consiste nel promuovere il nuovo nodo a membro a pieno titolo.
Promoting the New Learner¶
A seconda delle condizioni della rete e del cluster, potrebbe volerci un po” di tempo prima che il nuovo membro si allinei con il cluster. Una volta completata questa operazione, potrà essere promosso da membro in fase di apprendimento a membro a pieno titolo.
Avvertimento
La promozione di un nodo aumenta la soglia di quorum del cluster (fare riferimento alla documentazione dell’API “ ” e alla sezione “ Operational Redundancy” del presente documento). Assicurarsi che il nuovo nodo disponga di una connessione stabile al cluster prima di promuoverlo.
È possibile tentare di promuovere il nuovo membro tramite una chiamata a POST /cluster/members/{MemberID}/promote (fare riferimento alla documentazione dell’API di ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Se lo studente non è ancora in regola, l’operazione fallirà con il codice HTTP 412 e sarà necessario riprovare la promozione in un secondo momento.
If this promotion is successful, the node will now have fully joined the cluster and the earlier call to /cluster/join will have returned. The node ends up in a Locked state and has to be unlocked with the unlock passphrase of the node that was used for registration. Afterwards the unlock passphrase can be changed (unlock passphrases remain node-specific and are not shared across nodes).
Adding a Witness Node¶
Prepare a Witness¶
È necessario un ambiente con etcd v3.6 disponibile, con un indirizzo IPv4 (almeno) raggiungibile dagli altri membri del cluster. Il traffico TCP da e verso la porta 2380 deve essere consentito.
Creare una directory vuota in cui etcd memorizzerà i suoi dati e scrivere il suo percorso (noi useremo /var/etcd/data). Assicurarsi che l’utente che avvierà il processo abbia i permessi di lettura e scrittura sulla directory.
Transfer to the machine the CA certificate that is being used to authenticate
nodes in the cluster. You should have created one in the
Creating and Installing a CA section. We’ll
store it in /var/etcd/CA.pem.
Sarà quindi necessario creare un certificato per il testimone e firmarlo con la CA in modo che possa comunicare con i suoi pari. Questo può essere fatto, ad esempio, tramite 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
Memorizzare i risultati di witness.key e witness.pem anche in /var/etcd.
Register Witness to Cluster¶
Follow the normal instructions from the Registering a New Node section to signal the existing cluster the addition of a new member with the given URL(s).
Scrivete la risposta del cluster: dovrebbe contenere l’elenco dei membri del cluster e un kit di adesione (questa parte non vi servirà).
Configure etcd¶
A differenza dei NetHSM che scelgono automaticamente il nome del nodo (utilizzando l’ID del dispositivo), è necessario scegliere un nome per ogni testimone aggiunto, assicurandosi che i nomi siano unici. Negli esempi che seguono utilizzeremo «witness1».
Con la risposta del NetHSM alla registrazione del testimone, preparare le variabili del modulo:
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,..."
Assumendo che la risposta di NetHSM sia memorizzata in un file response.json, è possibile generare automaticamente queste ultime due variabili con le seguenti espressioni jq:
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)
For example with the example response provided in the Registering a New Node section, you will have:
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"
Infine, creare un file etcd.conf.yml utilizzando il file modello fornito in docs/etcd_witness.conf.template:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
In questo modo si ottiene un file del modulo:
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¶
Avviare etcd nel modo preferito (manualmente, systemd servizio, container, ecc.), puntando al file di configurazione creato nel passo precedente:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Dovresti vederlo avviarsi, entrare a far parte del cluster come learner e mettersi al passo con i dati.
Promote the Witness¶
Infine, dopo un po” di tempo, segui le normali istruzioni riportate nella sezione « « (Promozione del nuovo studente) per promuovere il testimone. Se l’operazione non va a buon fine, riprova più tardi.
After a successful promotion, you should be able to check that it is healthy with the etcdctl client:
etcdctl get /config/version
Questa chiave deve esistere e contenere «1».
Make sure this process keeps running, as it is now a proper member of your cluster. If you need to decommission it, first properly remove it from the cluster. If its reachable IP changes, update its URL from the cluster.
Operating a Cluster¶
Backup e ripristino¶
L’operazione di backup funziona come senza cluster e può essere richiesta da qualsiasi nodo del cluster. Verrà eseguito il backup dei dati dell’intero cluster, compresi i campi specifici del nodo (anche se questi verranno ignorati a meno che non si ripristini il backup su un nodo non approvato).
Un backup eseguito su un cluster può essere ripristinato sullo stesso cluster, anche se alcuni nodi sono stati aggiunti o rimossi da allora. Tali ripristini eseguiti su cluster operativi non influiscono sui valori di configurazione (solo chiavi, utenti, spazi dei nomi), come qualsiasi altro ripristino parziale.
Il ripristino di un backup su un nodo non provvisto ripristinerà i campi specifici del nodo (come la configurazione di rete, i certificati, ecc.) del nodo utilizzato per creare il backup.
Il ripristino di un backup di grandi dimensioni può sovraccaricare il cluster per qualche tempo, mentre il nodo che applica il ripristino inoltra le modifiche agli altri.
Questa operazione rimane compatibile con i backup effettuati su versioni precedenti di NetHSM.
Nota
Il ripristino su un nodo A di un backup eseguito su un altro nodo Z con una chiave di dominio diversa riscriverà correttamente la chiave di dominio di A, come prima. Tuttavia, se A si trovava in un cluster con il nodo B, B diventerà inutilizzabile, poiché la chiave di dominio di Z non verrà ripristinata su B.
In altre parole, eseguire un ripristino solo in un cluster con backup eseguiti nello stesso cluster (anche se i nodi potrebbero essere stati rimossi o aggiunti da allora). Se si desidera ripristinare un backup estraneo su un nodo, occorre prima rimuoverlo in modo sicuro dal suo cluster, quindi ripristinarlo e ripristinare il backup.
Rimuovere un nodo in modo pulito¶
Finché una parte del cluster soddisfa ancora il quorum, uno qualsiasi dei suoi membri può essere usato per rimuovere un altro nodo dal cluster, sia che questo nodo sia già irraggiungibile sia che si preveda che lo sarà.
Per prima cosa è necessario conoscere l’ID del nodo che si vuole rimuovere, elencando tutti i nodi attraverso GET /cluster/members e cercando quello giusto.
Then it can be removed by calling DELETE /cluster/members/<id>. If the node in question was still healthy, this will isolate it from the rest of the cluster and transition it to the Failed state.
Nota
Anche un nodo che è stato aggiunto al cluster ma che non è ancora stato promosso può essere rimosso in tutta sicurezza in questo modo.
Recovering a Failed Node¶
Un nodo che segnala uno stato “ ” con errore “ ” rifiuterà di rispondere alla maggior parte delle operazioni normali. È comunque possibile spegnerlo, riavviarlo, resettarlo, eseguire una diagnosi o isolarlo.
Avvertimento
L’esistenza delle operazioni Failed state, diagnose e force-new è valida solo a partire dalla versione 5.0. Nella versione 4.0, un nodo che ha perso il quorum smetterà di rispondere a tutte le richieste all. Deve essere ripristinato alle impostazioni di fabbrica.
Tra le cause più comuni che determinano lo stato “ ” (Errore) di un nodo figurano:
Un quorum perso in modo irreversibile ` <clustering.html#the-quorum-is-durably-lost>` __.
Una perdita temporanea del quorum (ad esempio, quando si aggiunge un secondo nodo al cluster e il secondo nodo non si è ancora unito al cluster).
etcdè attualmente in fase di riavvio (ad esempio perché i certificati sono stati modificati o la rete è stata riconfigurata).Il cluster è sottoposto a un carico molto elevato (ad esempio, durante il ripristino di un backup di grandi dimensioni).
A prescindere dalla causa, il NetHSM passerà allo stato “ Failed” ( ) solo dopo che siano trascorsi almeno un minuto intero di tentativi infruttuosi di interagire con il proprio database. Ciò al fine di evitare transizioni errate causate da instabilità di brevissima durata.
Per aiutarti a capire in quale stato si trova il tuo nodo, l’endpoint GET /health/diagnose rimane disponibile e restituisce informazioni sullo stato attuale di etcd e del relativo database, inclusi i log (consulta la documentazione dell’API).
Nota
Se e quando il database tornerà disponibile (ad esempio, se il quorum verrà ripristinato in seguito alla risoluzione del problema di rete), il NetHSM passerà automaticamente dallo stato “ ” (“Failed” ) allo stato in cui si trovava in precedenza (o riprenderà la normale sequenza di avvio se era in fase di avvio), senza che sia necessaria alcuna azione manuale. Ci vorrà al massimo un minuto dopo la risoluzione del problema affinché il cluster si stabilizzi, l’HSM rilevi la risoluzione e cambi stato.
Se ritieni che l’interruzione sia di natura permanente (ad esempio, perdita del quorum senza alcuna speranza di risolvere la situazione alla base), puoi:
Esegui il ripristino delle impostazioni di fabbrica ( ) del nodo, operazione che cancellerà tutti i dati, quindi ripristina un backup.
Isolare il nodo tramite l’endpoint
POST /cluster/force-new, che farà dimenticare in modo irreversibile tutti gli altri membri del cluster, recupererà i dati presenti su discoetcde riavvierà il sistema. Se il guasto sottostante era correlato al cluster, il nodo seguirà la normale sequenza di avvio e raggiungerà lo stato Locked oppure Operational a seconda dell’impostazione di avvio automatico.
Nota
Se un nodo viene isolato con l’opzione force-new, verrà desincronizzato dal cluster: eventuali nuove operazioni di scrittura effettuate su di esso o sul cluster non potranno essere riconciliate. Il nodo potrà comunque rientrare nel cluster, ma perderà tutte le modifiche locali.
L’endpoint POST /cluster/force-new` di , disponibile solo nello stato «Failed» ( *) di*, richiede l’autenticazione in quanto potenzialmente distruttivo. Tuttavia, poiché in tale stato gli utenti e i ruoli HSM non sono disponibili, l’endpoint si aspetta che i client HTTPS si autenticino sempre utilizzando l’utente fittizio `unlock` di ` e l’ultima passphrase di sblocco nota come password.
Avvertimento
Dopo un aggiornamento da una versione precedente alla 5.0, l’endpoint force-new risulterà sempre «Non autorizzato» finché l’HSM non verrà sbloccato o la passphrase di sblocco non verrà modificata almeno una volta.
Software Updates in Clusters¶
Gli aggiornamenti futuri saranno contrassegnati come «cluster-safe» (dovrebbe essere la maggioranza) o «cluster-unsafe».
Gli aggiornamenti sicuri per il cluster possono essere applicati ai nodi che fanno parte di un cluster senza rimuoverli prima dal cluster. Tuttavia, come per tutte le operazioni, è necessario assicurarsi di eseguire l’operazione su un nodo alla volta e in un cluster in cui la rimozione di un nodo non faccia scendere il quorum (ad esempio, se l’aggiornamento fallisce).
Gli aggiornamenti non sicuri per il cluster devono essere applicati a nodi isolati. È necessario smantellare il cluster (rimuovendo i nodi uno per uno), ripristinare tutti i nodi tranne uno, applicare l’aggiornamento a tutti i nodi, quindi fare in modo che tutti i nodi ripristinati si uniscano al nodo rimanente.
Assicuratevi di eseguire il backup prima di tali operazioni.
Riconfigurazione di un cluster esistente¶
Changing the Cluster CA¶
Un cluster esistente (con due o più nodi) non può cambiare la CA del cluster mentre è in funzione. Se è necessario modificare questo certificato: scegliere un nodo, rimuovere tutti gli altri nodi, aggiornare la CA, quindi far rientrare gli altri membri.
Changing the Network Configuration of Nodes¶
La modifica della configurazione di rete di un nodo (ad esempio, la modifica del suo IP) informerà automaticamente gli altri nodi dell’aggiornamento. Tuttavia, è necessario assicurarsi di eseguire tali aggiornamenti solo su un singolo nodo alla volta e in un cluster in cui la perdita di tale nodo non comporti la perdita del quorum.