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.
Aún no se ha probado en un número suficiente de implementaciones en entorno de producción, y puede que haya errores.

NetHSM 4.0 en adelante admite la agrupación en clústeres para sincronizar datos entre varios NetHSM directamente. Esto permite una alta frecuencia de generación de claves, alta disponibilidad y equilibrio de carga. Un clúster NetHSM se basa en etcd que utiliza el algoritmo de consenso Raft para una fuerte consistencia. Esto garantiza que los datos (por ejemplo, las claves) sean correctos en todas las NetHSM en todo momento.

Antes de configurar un clúster NetHSM, familiarícese con esta tecnología y sus limitaciones para evitar interrupciones accidentales y pérdidas de datos. Además de este documento, puede consultar la documentación de etcd.

Operational Redundancy¶

Llamaremos «nodo» a una NetHSM que se espera que forme parte de un clúster. Un clúster de nodos N seguirá funcionando mientras al menos (N/2)+1 nodos estén sanos y accesibles. Esa cantidad mínima de nodos sanos y accesibles se denomina quórum **** .

En un clúster que caiga por debajo de este umbral (por ejemplo, debido a un problema de red), no se puede elegir ningún líder y la instancia local de etcd en cada nodo deja de poder realizar operaciones de lectura y escritura. Esto da lugar a los siguientes escenarios.

Un nodo se cae y sigue habiendo quórum¶

En un clúster de 3 nodos, si uno de ellos falla (se bloquea o se vuelve inalcanzable debido a las condiciones de la red), los otros dos nodos seguirán funcionando y sirviendo peticiones.

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.

Si no se recupera nunca, habrá que eliminarlo ` <clustering.html#removing-a-node-cleanly>` __ del clúster y, o bien someterlo a un proceso de recuperación ` <clustering.html#recovering-a-failed-node>` __ para poder acceder a sus datos (aunque ya no formará parte del clúster), o bien restablecerlo a los valores de fábrica y volver a realizar el proceso de incorporación desde cero.

Se produce una partición de la red y sigue habiendo quórum¶

Esto no es más que una generalización del escenario anterior. En un clúster de 5 nodos en el que, por ejemplo, 3 nodos están en una ubicación física A y 2 nodos están en otra ubicación B, un problema de red que aísle A y B significaría lo siguiente:

Los 3 nodos de la ubicación A cumplen el quórum (3 en este caso), por lo que siguen funcionando.
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).
Si se resuelve el problema de la red, los 2 nodos volverán a unirse limpiamente a los otros 3.

En otras palabras, en el peor de los casos, una partición de red (en un clúster con un número impar de nodos) dejará a la mitad más grande del clúster en buen estado, y a la mitad más pequeña inoperativa hasta que se resuelva la partición.

El Quórum se pierde de forma duradera¶

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.

Esto puede ocurrir, por ejemplo, si falla un único nodo en un clúster de 2 nodos (donde el quórum es 2). En esta situación, el nodo que ha fallado no puede eliminarse limpiamente del clúster a posteriori, porque el nodo sano restante ya está inoperativo al haber perdido el quórum.

De ahí que se aconseje tener siempre un número impar de nodos en un clúster y realizar copias de seguridad con frecuencia.

Para ser claros, temporalmente perder el quórum (por ejemplo, si está reiniciando todos los nodos de un clúster juntos, o un fallo de red temporal aísla los nodos) no es un problema: una vez que suficientes nodos se reconectan (sin tener que volver a unirse manualmente) para alcanzar el quórum, el clúster reanudará su funcionamiento normal. Sólo los fallos permanentes, como particiones de red, desconfiguraciones de red, problemas de autenticación o fallos de hardware, requerirán una acción manual.

Para más información, consulte las PREGUNTAS FRECUENTES de etcd.

Clúster de 2 nodos¶

Un cluster activo/pasivo de dos nodos no está soportado todavía y será añadido en una versión futura. Recomendamos introducir un tercer nodo, ya sea un tercer NetHSM o un «testigo» etcd que podría funcionar en cualquier host. Consulte la siguiente sección «Testigo».

Testigo¶

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.

Sin embargo, el diseño de la función es tal que no es necesario añadir un dispositivo NetHSM completo y real a su clúster para alcanzar un número estable de nodos. En su lugar, puede desplegar y añadir un nodo «testigo» usted mismo. Este nodo no es más que una instancia de etcd ejecutándose en la máquina de su elección (o en un contenedor), y conectado al clúster. Los dispositivos reales del clúster lo reconocerán como un nodo normal, y recibirá todos los datos y actualizaciones de los dispositivos (pero, por supuesto, no podrás realizar ninguna operación HSM con él: sólo almacena datos).

Security Considerations¶

El nodo testigo (o cualquiera con acceso a él) tiene acceso directo al backend de almacenamiento de todos los nodos del clúster (por ejemplo, puede volcar todas las entradas y los valores correspondientes con etcdctl get "/" "0").

Sin embargo, con la excepción de la versión de configuración (/config/version, que siempre debe ser «1»), estrictamente todos los valores están encriptados (con una clave de dispositivo para los valores específicos del nodo o las claves de dominio para los demás), lo que garantiza la confidencialidad de los datos sensibles.

Tenga en cuenta, sin embargo, que un nodo malicioso puede:

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.

Qué se comparte entre nodos¶

Tener un clúster de NetHSM significa que la mayoría de los datos se comparten entre ellos. Cualquier adición, modificación o eliminación de claves, usuarios o espacios de nombres en un nodo se refleja finalmente en todos los demás. En general, cualquier operación que modifique el estado modificará el estado de todos los nodos. Esto incluye la operación de copia de seguridad restore, que funciona con normalidad.

Las siguientes secciones detallan qué datos son totalmente locales, qué datos se almacenan en el almacén compartido etcd pero siguen siendo específicos de cada nodo, y qué datos son totalmente compartidos entre nodos.

No almacenado en etcd¶

La clave del dispositivo **** de cada nodo sólo se almacena localmente y nunca se comparte entre nodos.

Almacenado en etcd pero específico de nodo¶

Los siguientes datos se almacenan en etcd en diferentes ámbitos para cada nodo. Por lo tanto, es accesible a cada nodo pero no uniforme entre nodos (cada nodo puede tener un valor diferente para estos datos).

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

Ten en cuenta que aunque cada nodo tiene su propia versión de la clave de dominio bloqueada (porque cada nodo la bloquea con su propia clave de dispositivo o frase de contraseña de desbloqueo), la clave de dominio subyacente es compartida entre nodos (para acceder a sus datos HSM compartidos, como las claves).

Almacenado en etcd y compartido¶

Todos los datos siguientes se almacenan en etcd en el ámbito global, por lo que son uniformes en todos los nodos de un clúster:

Datos de HSM:

Keys
Usuarios
Espacios de nombres

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¶

Cualquier clúster partirá inicialmente de un único nodo. Los nuevos nodos se unirán al clúster uno a uno.

Preparing Nodes¶

El tráfico de red entre nodos se cifra y autentica mediante su certificado TLS.

Todos los nodos que vayan a formar parte del mismo clúster deben instalar primero una Autoridad de Certificación (CA) común que les permita verificar que los demás nodos son legítimos.

A continuación, supondremos que todos los nodos están recién aprovisionados y operativos.

Networking¶

Nodes must first be reconfigured with their expected final network configuration as described in the section Network.

Creación e instalación de una CA¶

Los usuarios deben crear una CA por sus propios medios y de acuerdo con sus propias limitaciones operativas, asegurándose de que permite al menos el uso de la clave keyCertSign.

Por ejemplo, se puede crear una CA mínima 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

Esta CA debe instalarse ahora en cada nodo.

Para ello, primero genera una solicitud de firma de certificado (CSR) desde el nodo tal y como se describe en la sección TLS Certificate. Con nitropy, esto se hace 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 nitropy, utiliza la opción --san, por ejemplo: --san "IP:192.168.1.1".

Si deseas utilizar una CA pública para firmar tus certificados, tus nodos deben utilizar direcciones IP públicas. Esto se debe a un requisito de seguridad que prohíbe a una CA pública emitir certificados con una dirección IP privada en el campo SAN de IP.

Dado el CSR obtenido (llamémoslo nethsm.csr), podemos entonces generar un certificado para él, listo para ser instalado. Por ejemplo 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

A continuación, instala el archivo obtenido new_cert.pem tal y como se describe en la sección Certificado TLS (con nitropy: 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.

Argumentos

Argumento	Descripción
`FILENAME`	The path of the CA file

Ejemplo

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

La CA del clúster instalada se puede consultar mediante nitropy nethsm --host $NETHSM_HOST get-cluster-ca-certificate.

Nota

Este proceso debe repetirse para cada nodo.

Sincronización del reloj¶

Asegúrate de que todos los nodos hayan sido configurados con una hora del sistema precisa, a ser posible utilizando NTP/NTS en lugar de la configuración manual de la hora. Esto se puede hacer mediante Time y 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 vez que se haya puesto al día, asciende al nodo de «aprendiz» a «miembro de pleno derecho».

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.

Registrar un nuevo nodo¶

Tenga a mano la IP del nodo que se unirá. La URL completa ** (también llamada peer URL en etcd terminología) de ese nodo será https://<IP_of_node>:2380 (por ejemplo https://192.168.1.1:2380). El puerto debe ser 2380, así que asegúrate de que cualquier cortafuegos entre los nodos permita el tráfico TCP en ese puerto.

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.

Ejemplo

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

Call GET /cluster/members (refer to the API documentation).

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

Opciones

Opción	Descripción
`--url` `TEXT`	La URL de par del nuevo nodo (se puede configurar varias veces)

Argumentos

Argumento	Descripción
`JOIN_DATA_PATH`	La ruta del archivo en el que se escriben los datos de unión

Ejemplo

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

El comando muestra una lista de los miembros del clúster y escribe en el archivo los datos que necesita el nuevo nodo para incorporarse al clúster (incluido el kit de incorporación). Guarda este archivo para el siguiente paso.

Call the POST /cluster/members endpoint (refer to the API documentation), passing it a JSON body containing the URL.

A successful call returns a JSON body of the form:

{
  "members": [
    {
      "name": "",
      "urls": [
        "https://172.22.1.3:2380"
      ],
      "learner": true
    },
    {
      "name": "9ZVNM2MNWP",
      "urls": [
        "https://172.22.1.2:2380"
      ],
      "learner": false
    }
  ],
  "joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}

que contiene la información necesaria para que el nuevo nodo se una al clúster. En particular, enumera todos los miembros del clúster (donde el miembro con un nombre vacío es el nuevo miembro). También contiene la clave de dominio encriptada tanto por la contraseña de desbloqueo como por la de respaldo, por lo que es necesario haber configurado antes una contraseña de respaldo.

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.

Aunque este concepto de «nodo en formación» añade un paso adicional (la promoción), permite un funcionamiento más seguro del clúster, ya que cualquier problema que surja con el nuevo nodo no puede provocar inestabilidad en todo el clúster antes de su promoción.

Guarda el archivo de datos de unión para el siguiente paso (o la respuesta, si has utilizado la API REST).

Joining the Cluster as a Learner¶

Únete al clúster en el nodo que se espera que se incorpore, utilizando los datos del último paso y la frase de contraseña de seguridad del nodo en el que se registró el nuevo nodo.

Opciones requeridas

Opción	Descripción
`--backup-passphrase` `TEXT`	La frase de contraseña de seguridad del nodo en el que se registró el nuevo usuario

Argumentos

Argumento	Descripción
`JOIN_DATA_PATH`	La ruta del archivo de datos de unión del último paso

Ejemplo

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

Take the response from the last step and append to it a backupPassphrase field containing the backup passphrase, and pass that data to a call to POST /cluster/join (refer to the API documentation).

Advertencia

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.

En esta fase, el nuevo nodo se ha incorporado como nodo « » ( ): se está sincronizando con el clúster, pero aún no está operativo. Por otra parte, cualquier problema que surja con el nodo en esta fase no afectará al clúster, por lo que esta operación es segura.

El último paso para completar la incorporación consiste en convertir al nuevo nodo en miembro de pleno derecho.

Promoting the New Learner¶

Dependiendo de las condiciones de la red y del clúster, es posible que el nuevo miembro tarde un rato en ponerse al día con el clúster. Una vez hecho esto, se le puede ascender de «aprendiz» a «miembro de pleno derecho».

Advertencia

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.

Puedes intentar ascender al nuevo miembro de la siguiente manera. El ID del miembro se puede encontrar al mostrar la lista de miembros del clúster.

Argumentos

Argumento	Descripción
`MEMBER_ID`	The ID of the learner to be promoted

Ejemplo

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

Call POST /cluster/members/{MemberID}/promote (refer to the API documentation).

Si el alumno aún no se ha puesto al día, la operación fallará (código HTTP 412 en la API REST) y habrá que volver a intentar la promoción más adelante.

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¶

Necesitará un entorno con etcd v3.6 disponible, con una dirección IPv4 (al menos) alcanzable por los otros miembros de su cluster. Es necesario permitir el tráfico TCP hacia y desde el puerto 2380.

Crea un directorio vacío donde etcd almacenará sus datos, y escribe su ruta (nosotros usaremos /var/etcd/data). Asegúrate de que el usuario que lanzará el proceso tiene permiso para leer y escribir en el directorio.

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.

A continuación, tendrá que crear un certificado para el testigo, y firmarlo con la CA para que pueda comunicarse con sus pares. Esto puede hacerse, por ejemplo, a través de 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

Guarde también los resultados witness.key y witness.pem en /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 diferencia de los NetHSM que eligen automáticamente un nombre de nodo para sí mismos (utilizando el ID de dispositivo), debe elegir un nombre para cada testigo que añada, asegurándose de que los nombres son únicos. Utilizaremos «witness1» en los siguientes ejemplos.

Con la respuesta de la NetHSM al registro del testigo, preparar las variables del formulario:

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"

Por último, cree un archivo etcd.conf.yml utilizando el archivo de plantilla proporcionado en docs/etcd_witness.conf.template:

$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml

Esto debería darle un archivo del formulario:

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¶

Inicie etcd de la forma que prefiera (manualmente, systemd servicio, contenedor, etc.), apuntando al archivo de configuración creado en el paso anterior:

$ cd /var/etcd
$ etcd --config-file witness.conf.yml

Deberías ver cómo se inicia, cómo se une al clúster como «aprendiz» y cómo se pone al día con los datos.

Promote the Witness¶

Por último, y tras un tiempo, sigue las instrucciones habituales que aparecen en la sección « » (Promoción del nuevo alumno) para ascender al testigo. Si esto no funciona, vuelve a intentarlo más tarde.

After a successful promotion, you should be able to check that it is healthy with the etcdctl client:

etcdctl get /config/version

Esta clave debe existir y contener «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¶

Copia de seguridad y restauración¶

La operación de copia de seguridad funciona igual que sin clúster y puede solicitarse desde cualquier nodo del clúster. Realizará una copia de seguridad de los datos de todo el clúster, incluidos los campos específicos del nodo (aunque estos se ignorarán a menos que se restaure la copia de seguridad en un nodo no aprovisionado).

Una copia de seguridad realizada en un clúster puede restaurarse en el mismo clúster, incluso si desde entonces se han añadido o eliminado algunos nodos. Estas restauraciones realizadas en clústeres operativos no afectarán a los valores de configuración (solo claves, usuarios, espacios de nombres), como cualquier otra restauración parcial.

La restauración de una copia de seguridad en un nodo no aprovisionado restaurará los campos específicos del nodo (como la configuración de red, certificados, etc.) del nodo que se utilizó para crear la copia de seguridad.

La restauración de una copia de seguridad de gran tamaño puede saturar el clúster durante algún tiempo, mientras el nodo que aplica la restauración reenvía los cambios a los demás.

Esta operación sigue siendo compatible con las copias de seguridad realizadas en versiones anteriores de NetHSM.

Nota

Al restaurar en un nodo A una copia de seguridad realizada en otro nodo Z con una clave de dominio diferente, se reescribirá correctamente la clave de dominio de A, como antes. Sin embargo, si A estaba en un clúster con el nodo B, B quedará inoperativo, ya que la clave de dominio de Z no se restaurará en B.

En otras palabras, sólo realice una restauración en un clúster con copias de seguridad realizadas en el mismo clúster (aunque de nuevo los nodos pueden haber sido eliminados o añadidos desde entonces). Si quieres restaurar una copia de seguridad ajena en un nodo, primero elimínalo de forma segura de su clúster, luego restablécelo de fábrica y restaura la copia de seguridad.

Eliminar un nodo limpiamente¶

Mientras alguna parte del clúster siga reuniendo quórum, cualquiera de sus miembros puede utilizarse para eliminar otro nodo del clúster, tanto si este nodo ya es inalcanzable como si se espera que lo sea.

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.

Argumentos

Argumento	Descripción
`MEMBER_ID`	The ID of the node to be removed

Ejemplo

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

Muestra los nodos con GET /cluster/members y elimina uno llamando a DELETE /cluster/members/<id>.

Nota

Un nodo que se haya incorporado al clúster pero que aún no haya sido ascendido también puede eliminarse de forma segura de esta manera.

Recovering a Failed Node¶

Un nodo que muestre el estado « » (Fallo de ) no responderá a la mayoría de las operaciones normales. No obstante, aún es posible apagarlo, reiniciarlo, restablecerlo, diagnosticarlo o aislarlo.

Advertencia

La existencia de las operaciones Failed state, diagnose y force-new solo es aplicable a la versión 5.0 y posteriores. En la versión 4.0, un nodo que haya perdido el quórum dejará de responder a todas las solicitudes. debe restablecerse a los valores de fábrica.

Entre las causas habituales por las que un nodo puede encontrarse en el estado « » (Fallo de ) se incluyen:

Un quórum perdido de forma dur ` <clustering.html#the-quorum-is-durably-lost>` __.
Una pérdida temporal del quórum (por ejemplo, al añadir un segundo nodo al clúster y este aún no se haya incorporado).
etcd se está reiniciando en estos momentos (por ejemplo, porque se han cambiado los certificados o se ha reconfigurado la red).
El clúster está sometido a una carga muy elevada (por ejemplo, durante la restauración de una copia de seguridad de gran tamaño).

Sea cual sea la causa, el NetHSM solo pasará al estado « » (Fallo ) tras al menos un minuto completo de intentos fallidos de interactuar con su base de datos. El objetivo es evitar transiciones espurias provocadas por inestabilidades muy breves.

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.

Ejemplo

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

Nota

Si la base de datos vuelve a estar disponible (por ejemplo, si se restablece el quórum porque se ha resuelto el problema de red), el NetHSM pasará automáticamente del estado « » (Fallo de HSM) al estado en el que se encontraba anteriormente (o reanudará la secuencia de arranque normal si se estaba iniciando), sin que sea necesaria ninguna acción manual. El clúster tardará hasta un minuto, una vez resuelto el problema, en estabilizarse, en que el HSM detecte la resolución y en cambiar de estado.

Si llegas a la conclusión de que la situación de fallo es duradera (por ejemplo, pérdida del quórum sin esperanza de resolver la causa subyacente), puedes optar por:

Restablece los ajustes de fábrica del dispositivo, lo que borrará todos los datos, y restaura una copia de seguridad.
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

Advertencia

Tras una actualización desde una versión inferior a la 5.0, el punto final force-new siempre mostrará el estado «Sin autorización» hasta que se desbloquee el HSM o se cambie la frase de contraseña de desbloqueo al menos una vez.

Software Updates in Clusters¶

Las futuras actualizaciones se marcarán como «cluster-safe» (debería ser la mayoría) o «cluster-unsafe».

Las actualizaciones a prueba de clústeres pueden aplicarse a nodos que forman parte de un clúster sin eliminarlos primero del clúster. Sin embargo, como con todas las operaciones, debe asegurarse de hacerlo en un nodo a la vez, y en un clúster donde la eliminación de un nodo no vaya por debajo del quórum (por ejemplo, si la actualización falla).

Las actualizaciones no seguras para clústeres deben aplicarse a nodos aislados. Debe desmantelar el clúster (eliminando los nodos uno a uno), restablecer de fábrica todos los nodos menos uno, aplicar la actualización a todos los nodos y, a continuación, hacer que todos los nodos restablecidos se unan al nodo restante.

Asegúrese de realizar una copia de seguridad antes de este tipo de operaciones.

Reconfiguración de un clúster existente¶

Changing the Cluster CA¶

Un clúster existente (con dos o más nodos) no puede cambiar su CA de clúster mientras está en funcionamiento. Si necesita cambiar este certificado: elija un nodo, elimine todos los demás nodos, actualice la CA y, a continuación, haga que los demás miembros vuelvan a unirse.

Changing the Network Configuration of Nodes¶

La modificación de la configuración de red de un nodo (por ejemplo, cambiando su IP) informará automáticamente a los demás nodos de la actualización. Sin embargo, debes asegurarte de que sólo realizas este tipo de actualizaciones en un único nodo cada vez, y en un clúster en el que la pérdida de ese nodo no suponga la pérdida de quórum.