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 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 <clustering.html#recovering-a-failed-node> 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¶
La naturaleza del clustering con etcd hace que sea más fiable cuantos más nodos haya en el cluster. Como se explica en la sección Redundancia operativa, lo ideal es que los clústeres tengan al menos 3 nodos para tener espacio para fallar, ya que un clúster de 2 nodos fallará por completo si sólo falla uno.
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.
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 using the /config/network endpoint (refer to the API documentation).
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.
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" ]
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
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
Por último, la CA (CA.pem) ya puede instalarse con el endpoint /config/tls/cluster-ca.pem (consulte la documentación de la API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Esto sólo es posible una vez que el certificado TLS instalado esté firmado por ella. En caso contrario, la operación será rechazada.
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¶
En primer lugar, asegúrese de que se ha configurado una frase de contraseña de seguridad en el nodo que se utilizará para registrar un nuevo carpintero (consulte la documentación de la API del punto final /config/backup-passphrase).
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.
Puede comprobar que la URL es correcta llamando a GET /cluster/members en el nodo que se espera que se una. Esto debería listar sólo un miembro: él mismo.
A continuación, registre esa URL esperada en cualquier nodo existente del clúster (si aún no tiene un clúster, hágalo en la NetHSM que servirá como nodo inicial del clúster). Para ello, utilice el punto final POST /cluster/members (consulte la documentación de la API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), pasándole un cuerpo JSON que contenga la URL.
Si tiene éxito, devuelve un cuerpo JSON del formulario:
{
"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
Fíjate en la respuesta anterior en que el nuevo nodo es un «aprendiz»: ahora puede conectarse al clúster y recibir datos del mismo, pero no puede participar hasta que sea ascendido, lo cual se explicará más adelante.
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 esa respuesta para el siguiente paso.
Joining the Cluster as a Learner¶
Tome la respuesta del último paso y añádale un campo backupPassphrase que contenga la frase de contraseña de respaldo del nodo en el que se registró el nuevo miembro, y pase esos datos a una llamada a POST /cluster/join (consulte la documentación de la API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) en el nodo que se espera que se una.
Advertencia
La llamada a POST /cluster/join se quedará bloqueada hasta que el nuevo nodo se promueva manualmente (véase más abajo). Esto es normal. Cuando la llamada devuelve un resultado satisfactorio, significa que la incorporación y la promoción se han realizado correctamente.
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
Al ascender un nodo, aumenta el umbral de quórum del clúster (consulte la documentación de la API de « » y la sección «Redundancia operativa de » de este documento). Asegúrese de que este nuevo nodo tenga una conexión estable con el clúster antes de ascenderlo.
Puedes intentar ascender al nuevo miembro mediante una llamada a POST /cluster/members/{MemberID}/promote (consulta la documentación de la API de ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Si el alumno aún no se ha puesto al día, la operación fallará con el código HTTP 412 y deberás volver a intentar el ascenso más tarde.
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).
Anota la respuesta del clúster: debe contener la lista de miembros del clúster y un kit de unión (no necesitarás esta parte).
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,..."
Suponiendo que la respuesta NetHSM se almacena en un archivo response.json, puede generar estas dos últimas variables automáticamente con las siguientes expresiones 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"
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.
Primero tienes que saber el ID del nodo que quieres eliminar, listando todos los nodos a través de GET /cluster/members y buscando el correcto.
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
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).
etcdse 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.
Para ayudarte a saber en qué estado se encuentra tu nodo, el punto final GET /health/diagnose sigue estando disponible y devuelve información sobre el estado actual de etcd y su base de datos, incluidos los registros (consulta la documentación de la API).
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.
Aísla el nodo con el punto final
POST /cluster/force-new, lo que hará que olvide de forma irreversible a todos los demás miembros del clúster, recupere los datosetcdpresentes en el disco y se reinicie. Si el fallo subyacente estaba relacionado con el clúster, el nodo seguirá la secuencia de arranque normal y acabará en el estado «Locked» o «Operational», dependiendo de la configuración de arranque desatendido.
Nota
Si un nodo queda aislado con el comando « ` » force-new`, quedará desincronizado con el clúster: no será posible conciliar ninguna nueva escritura realizada en él o en el clúster. El nodo podrá volver a unirse al clúster, pero perderá todas sus modificaciones locales.
El punto final POST /cluster/force-new, que solo está disponible en el estado «Failed» ( ), requiere autenticación, ya que puede provocar daños. Sin embargo, dado que los usuarios y roles de HSM no están disponibles en ese estado, el punto final espera que los clientes HTTPS se autentiquen siempre con el usuario ficticio unlock y con la última frase de contraseña de desbloqueo conocida como contraseña.
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.