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.

  • Non è stato ancora testato in un numero sufficiente di implementazioni in produzione e potrebbero esserci dei bug.

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 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

The nature of clustering with etcd makes it more reliable the more nodes there are in the cluster. As explained in the Operational Redundancy section, clusters should ideally have at least 3 nodes to have room to fail, since a 2-node cluster will entirely fail if only one fails.

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.

Cosa viene condiviso tra i nodi

Un cluster di NetHSM significa che la maggior parte dei dati è condivisa tra loro. Qualsiasi aggiunta, modifica o eliminazione di chiavi, utenti o spazi dei nomi su un nodo si riflette su tutti gli altri. In generale, qualsiasi operazione che modifichi lo stato modificherà lo stato di ogni nodo. Ciò include l’operazione di backup restore che funziona normalmente.

Le sezioni seguenti illustrano quali dati sono completamente locali, quali dati sono memorizzati nello store condiviso etcd ma rimangono specifici del nodo e quali dati sono completamente condivisi tra i nodi.

Non memorizzato in etcd

La chiave del dispositivo **** di ogni nodo rimane memorizzata solo localmente e non viene mai condivisa tra i nodi.

Memorizzato in etcd ma specifico del nodo

I seguenti dati sono memorizzati in etcd in ambiti diversi per ogni nodo. È quindi accessibile a ogni nodo, ma non uniforme tra i nodi (ogni nodo può avere un valore diverso per questi dati).

Configuration:

  • TLS certificates

  • Clock configuration

  • Network configuration

  • Logging configuration

  • Unattended boot configuration

  • Unlock salt (so each node has its own unlock passphrase)

  • Locked domain key

Si noti che mentre ogni nodo ha la propria versione della chiave di dominio bloccata (perché ogni nodo la blocca con la propria chiave del dispositivo o passphrase di sblocco), la chiave di dominio sottostante è condivisa tra i nodi (per accedere ai dati HSM condivisi, come le chiavi).

Memorizzato in etcd e condiviso

Tutti i dati seguenti sono memorizzati in etcd nell’ambito globale, in modo da essere uniformi in tutti i nodi di un cluster:

Dati HSM:

  • Keys

  • Utenti

  • Spazi dei nomi

Configuration:

  • Config/domain store version

  • Cluster CA (used to authenticate nodes across cluster)

  • Backup passphrase and backup salt

Note that for now the config/domain store version can only be version 1 (if your software version supports clustering, then that is what you have). Refer to the Software Updates in Clusters section for more details on the safety of installing software updates within a cluster.

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 as described in the section Network.

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.

Per farlo, occorre innanzitutto generare una richiesta di firma del certificato (CSR) dal nodo, come descritto nella sezione TLS Certificate. Con nitropy questa operazione si esegue con nitropy nethsm --host $NETHSM_HOST csr --api.

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" ]

Con nitropia utilizzare l’opzione --san, ad esempio --san "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

Quindi installare il certificato TLS ottenuto new_cert.pem come descritto nella sezione ` <administration.html#tls-certificate>` __ (con nitropia: nitropy nethsm --host $NETHSM_HOST set-certificate --api new_cert.pem).

Finally, the CA (CA.pem) can now be installed. This is only possible once the installed TLS certificate is signed by it. Otherwise, the operation will be rejected.

Argomenti

Argomento

Descrizione

OAEP_MD5

The path of the CA file

Esempio

$ nitropy nethsm --host $NETHSM_HOST set-cluster-ca-certificate CA.pem

È possibile recuperare la CA del cluster installata tramite nitropy nethsm --host $NETHSM_HOST get-cluster-ca-certificate.

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:

  1. Register the addition to the cluster (through any one of its members)

  2. Tell the new node to join

  3. Una volta che avrà recuperato il ritardo, promuovi il nodo da «allievo» a membro a pieno titolo

Configure a Backup Passphrase

First make sure a backup passphrase is configured on the node that will be used to register a new joiner as described in the section Backup.

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.

You can double-check the URL is correct by listing the cluster members on the node that is expected to join. This should list just one member: itself.

Esempio

$ nitropy nethsm --host $NETHSM_HOST list-cluster-members

Then register that expected URL on any existing node of the cluster (if you don’t have a cluster yet, do this on the NetHSM that will serve as the initial node of the cluster).

Opzioni opzionali

Opzione

Descrizione

--url TEXT

L’URL del peer del nuovo nodo (può essere impostato più volte)

Argomenti

Argomento

Descrizione

JOIN_DATA_PATH

Il percorso del file in cui vengono scritti i dati di unione

Esempio

$ nitropy nethsm --host $NETHSM_HOST add-cluster-member --url https://192.168.1.1:2380 join-data.json

Il comando elenca i membri del cluster e scrive nel file i dati necessari al nuovo nodo per entrare a far parte del cluster (compreso il joiner kit). Conservare questo file per il passaggio successivo.

Nota

Notice in the list of members (learner: True in the nitropy output, "learner": true in the REST API response) that the new joiner is a «learner»: it can now connect to the cluster and receive data from it, but cannot participate until it is promoted, which will be covered below.

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.

Conserva il file dei dati di join per il passaggio successivo (o la risposta, se hai utilizzato l’API REST).

Joining the Cluster as a Learner

Entra a far parte del cluster dal nodo che deve unirsi, utilizzando i dati dell’ultimo passaggio e la passphrase di backup del nodo su cui è stato registrato il nuovo nodo.

Opzioni richieste

Opzione

Descrizione

--backup-passphrase TEXT

La passphrase di backup del nodo su cui è stato registrato il nuovo utente

Argomenti

Argomento

Descrizione

JOIN_DATA_PATH

Percorso del file di dati di unione dell’ultimo passaggio

Esempio

$ nitropy nethsm --host $NETHSM_HOST join-cluster --backup-passphrase $BACKUP_PASSPHRASE join-data.json

Avvertimento

The join call (nitropy nethsm join-cluster or POST /cluster/join) will hang until the new node is manually promoted (see below). This is normal. When the call returns successfully, it indicates that join and promotion have been successful. Don’t cancel this join call.

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

Promoting a node increases the cluster’s quorum threshold (refer to the API documentation and the Operational Redundancy section of this document). Ensure this new node has a stable connection to the cluster before promoting it.

Puoi provare a promuovere il nuovo membro come segue. L’ID del membro può essere individuato visualizzando l’elenco dei membri del cluster.

Argomenti

Argomento

Descrizione

MEMBER_ID

The ID of the learner to be promoted

Esempio

$ nitropy nethsm --host $NETHSM_HOST promote-cluster-member $MEMBER_ID

Se lo studente non ha ancora recuperato il ritardo, l’operazione fallirà (codice HTTP 412 nell’API REST) e si dovrà riprovare a effettuare 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).

Keep the join data file written by nitropy nethsm add-cluster-member (or the response from the cluster, if you used the REST API): it contains the list of cluster members and a joiner kit (you won’t need this part).

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,..."

Assuming the join data file written by nitropy (or the NetHSM REST API response) is stored in a response.json file, you can generate these last two variables automatically with the following jq expressions:

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à.

You first have to know the ID of the node you want to remove, by listing all nodes and looking for the right one. Then it can be removed. 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.

Argomenti

Argomento

Descrizione

MEMBER_ID

The ID of the node to be removed

Esempio

$ nitropy nethsm --host $NETHSM_HOST remove-cluster-member $MEMBER_ID

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.

To help you understand which case your node is in, the diagnose function remains available and returns information about the current status of etcd and its database, including logs.

Esempio

$ nitropy nethsm --host $NETHSM_HOST get-cluster-diagnostics

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.

  • Isolate the node with nitropy nethsm force-new-cluster (REST API: POST /cluster/force-new), which will irreversibly forget all other cluster members, recover the etcd data present on disk and reboot. If the underlying failure was cluster-related, the node will follow the normal boot sequence and end up in either the Locked or Operational state depending on the unattended boot setting.

Nota

If a node is isolated with force-new, it will desynchronized with the cluster: any new writes on it or the cluster cannot be reconciled. The node can still rejoin the cluster but will lose all its local modifications.

The force-new operation, which is only available in the Failed state, requires authentication as it is potentially destructive. However since HSM users and roles are not available in that state, the endpoint expects HTTPS clients to always authenticate with the unlock fake user, and the latest known unlock passphrase as the password. With nitropy, pass them as --username unlock --password $UNLOCK_PASSPHRASE:

$ nitropy nethsm --host $NETHSM_HOST --username unlock --password $UNLOCK_PASSPHRASE force-new-cluster

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.