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.

• Ainda não foi comprovado num número suficiente de implementações em ambiente de produção, e poderá haver erros.

O NetHSM 4.0 em diante suporta o agrupamento para sincronizar dados entre vários NetHSMs diretamente. Isto suporta uma elevada frequência de gerações de chaves, permite uma elevada disponibilidade e um equilíbrio de carga. Um cluster NetHSM baseia-se em etcd que utiliza o algoritmo de consenso Raft para uma consistência forte. Isto garante que os dados (por exemplo, chaves) estão sempre corretos em todos os NetHSMs.

Antes de configurar um cluster NetHSM, familiarize-se com esta tecnologia e com as suas restrições para evitar interrupções acidentais e perda de dados. Para além deste documento, poderá querer consultar também a documentação do etcd.

Operational Redundancy

Chamaremos «nó» a um NetHSM que se espera que faça parte de um cluster. Um cluster de N nós continuará a operar desde que pelo menos (N/2)+1 nós estejam saudáveis e acessíveis. Essa quantidade mínima de nós saudáveis e acessíveis é chamada de quorum.

Num cluster que fique abaixo deste limiar (por exemplo, devido a um problema de rede), não é possível eleger um líder e a instância local de etcd em cada nó fica incapaz de realizar leituras e gravações. Isto implica os seguintes cenários.

Um nó fica inoperante e o quorum ainda é alcançado

Num cluster de 3 nós, se um nó falhar (avariar ou ficar inacessível devido a condições de rede), os outros dois nós continuarão a trabalhar e a servir pedidos.

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 nunca recuperar, terá de ser removido ` <clustering.html#removing-a-node-cleanly>` __ do cluster e, ou ser submetido a um processo de recuperação ` <clustering.html#recovering-a-failed-node>` __ para aceder aos seus dados (mas deixará de fazer parte do cluster), ou ser reposto nas configurações de fábrica e passar pelo processo de integração novamente do zero.

Ocorre uma partição de rede e o quorum ainda é atingido

Esta é apenas uma generalização do cenário anterior. Num cluster de 5 nós em que, por exemplo, 3 nós estão numa localização física A e 2 nós estão noutra localização B, um problema de rede que isole A e B significaria o seguinte:

• Os 3 nós da localização A estão a cumprir o quórum (3, neste caso), pelo que continuam a funcionar.

• 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 o problema da rede for resolvido, os 2 nós voltarão a juntar-se aos outros 3.

Por outras palavras, uma partição de rede no pior dos casos (num cluster com um número ímpar de nós) deixará a metade maior do cluster em bom estado e a metade menor inoperacional até que a partição seja resolvida.

O Quorum está perdido de forma duradoura

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.

Isso pode acontecer, por exemplo, se um único nó falhar em um cluster de 2 nós (onde o quorum é 2). Nesta situação, o nó falhado não pode ser removido do cluster após o facto, porque o nó saudável restante já está inoperacional uma vez que perdeu o quórum.

Por isso, é aconselhável ter sempre um número ímpar de nós num cluster e fazer cópias de segurança com frequência.

Para ser claro, temporariamente perder o quorum (por exemplo, se estiver a reiniciar todos os nós de um cluster em conjunto, ou se uma falha de rede temporária isolar os nós) não é um problema: assim que um número suficiente de nós for reconectado (sem ter de se voltar a juntar manualmente) para atingir o quorum, o cluster retomará o seu funcionamento normal. Apenas as falhas permanentes, como partições de rede, configurações incorrectas de rede, problemas de autenticação ou falhas de hardware, exigirão uma ação manual.

Para mais informações, consulte etcd’s FAQ.

Cluster de 2 nós

Um cluster ativo/passivo de dois nós ainda não é suportado e será adicionado numa versão futura. Recomendamos a introdução de um terceiro nó, seja um terceiro NetHSM ou uma «testemunha» etcd que pode ser operada em qualquer hospedeiro. Veja a próxima secção «Testemunha».

Testemunha

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.

No entanto, o design do recurso é tal que não é necessário adicionar um dispositivo NetHSM completo e real ao cluster para atingir um número estável de nós. Em vez disso, pode implementar e adicionar um nó «testemunha». Tal nó é apenas uma instância do etcd rodando na máquina de sua escolha (ou em um container), e conectado ao cluster. Ele será reconhecido como um nó normal dos dispositivos reais no cluster e receberá todos os dados e atualizações dos dispositivos (mas é claro que não será possível executar nenhuma operação do HSM com ele - ele apenas armazena dados).

Security Considerations

O nó testemunha (ou qualquer pessoa com acesso a ele) tem acesso direto ao backend de armazenamento de todos os nós do cluster (por exemplo, pode descarregar todas as entradas e valores correspondentes com etcdctl get "/" "0").

No entanto, com exceção da versão de configuração (/config/version, que deve ser sempre «1»), todos os valores são estritamente encriptados (com uma chave de dispositivo para valores específicos de nós ou com as chaves de domínio para outros), garantindo a confidencialidade de dados sensíveis.

Note-se, no entanto, que um nó malicioso pode:

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

O que é partilhado entre nós

Ter um cluster de NetHSMs significa que a maioria dos dados é partilhada entre eles. Qualquer adição, modificação ou eliminação de chaves, utilizadores ou espaços de nomes num nó acaba por se refletir em todos os outros. Em geral, qualquer operação que modifique o estado modificará o estado de todos os nós. Isso inclui a operação de backup restore que funciona normalmente.

As seções a seguir detalham quais dados são totalmente locais, quais dados são armazenados no armazenamento compartilhado etcd mas permanecem específicos do nó, e quais dados são totalmente compartilhados entre os nós.

Não armazenado no etcd

A chave do dispositivo **** de cada nó é armazenada apenas localmente e nunca é partilhada entre nós.

Armazenado no etcd mas específico do nó

Os dados seguintes são armazenados em etcd em âmbitos diferentes para cada nó. Por conseguinte, é acessível a todos os nós, mas não uniforme entre nós (cada nó pode ter um valor diferente para estes dados).

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

Note-se que, embora cada nó tenha a sua própria versão da chave de domínio bloqueada (porque cada nó a bloqueia com a sua própria chave de dispositivo ou frase-chave de desbloqueio), a chave de domínio subjacente é partilhada entre nós (para aceder aos seus dados HSM partilhados, tais como chaves).

Armazenado no etcd e partilhado

Todos os dados seguintes são armazenados em etcd no âmbito global, pelo que são uniformes em todos os nós de um cluster:

Dados HSM:

• Keys

• Users

• Namespaces

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

Qualquer cluster começará inicialmente com um único nó. Os novos nós juntar-se-ão ao cluster um a um.

Preparing Nodes

O tráfego de rede entre os nós é encriptado e autenticado utilizando o seu certificado TLS.

Todos os nós que se espera que façam parte do mesmo cluster devem primeiro instalar uma Autoridade de Certificação (CA) comum que lhes permita verificar se os outros nós são legítimos.

A seguir, partimos do princípio de que todos os nós estão recém-provisionados e operacionais.

Networking

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

Criação e instalação de uma CA

Os utilizadores devem criar uma AC pelos seus próprios meios e de acordo com as suas próprias restrições operacionais, certificando-se de que permite, pelo menos, a utilização da chave keyCertSign.

Por exemplo, uma CA mínima pode ser criada com 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 tem agora de ser instalada em todos os nós.

Para tal, comece por gerar um Pedido de Assinatura de Certificado (CSR) a partir do nó, conforme descrito na secção Certificado TLS. Com o nitropia, isto é feito com 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" ]

Com o nitropia, utilize a opção --san, por exemplo, --san "IP:192.168.1.1".

Se pretender utilizar uma CA pública para assinar os seus certificados, os seus nós têm de utilizar endereços IP públicos. Isto deve-se a um requisito de segurança que proíbe uma CA pública de emitir certificados com um endereço IP privado no campo IP da SAN.

Dado o CSR obtido (vamos chamá-lo de nethsm.csr), podemos então gerar um certificado para ele, pronto para ser instalado. Por exemplo, com 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

Em seguida, instale o ficheiro obtido new_cert.pem, conforme descrito na secção Certificado TLS (com 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.

nitropyREST API

Argumentos*

Argumento	Descrição
FILENAME``	The path of the CA file

Exemplo*

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

É possível aceder à CA do cluster instalada através de nitropy nethsm --host $NETHSM_HOST get-cluster-ca-certificate.

Nota

Este processo tem de ser repetido para cada nó.

Sincronização do relógio

Certifique-se de que todos os nós foram configurados com uma hora de sistema precisa, de preferência utilizando NTP/NTS em vez da configuração manual da hora. Isto pode ser feito através da configuração 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. Assim que tiver recuperado o atraso, promova o nó de «aprendiz» a «membro de pleno direito»

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.

Registar um novo nó

Ter em mãos o IP do nó que irá aderir. O URL completo ** (também chamado peer URL na terminologia etcd) desse nó será https://<IP_of_node>:2380 (por exemplo, https://192.168.1.1:2380). A porta deve ser 2380, portanto, certifique-se de que qualquer firewall entre os nós permita o tráfego TCP nessa 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.

nitropyREST API

Exemplo*

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

nitropyREST API

Opções opcionais*

Opção	Descrição
--url TEXT	O URL de par do novo nó (pode ser definido várias vezes)

Argumentos*

Argumento	Descrição
JOIN_DATA_PATH	O caminho do ficheiro onde os dados da junção são gravados

Exemplo*

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

O comando apresenta uma lista dos membros do cluster e grava no ficheiro os dados necessários para que o novo nó se junte ao cluster (incluindo o kit de integração). Guarde este ficheiro para o próximo passo.

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.

Embora este conceito de «aprendiz» acrescente uma etapa adicional (promoção), permite um funcionamento mais seguro do cluster, uma vez que qualquer problema com o novo nó não pode causar instabilidade em todo o cluster antes da sua promoção.

Guarde o ficheiro de dados de junção para o próximo passo (ou a resposta, caso tenha utilizado a API REST).

Joining the Cluster as a Learner

Junte-se ao cluster no nó que se pretende que adira, utilizando os dados do último passo e a frase-passe de segurança do nó no qual o novo membro foi registado.

nitropyREST API

Opções requeridas*

Opção	Descrição
--backup-passphrase TEXT	A frase-passe de segurança do nó no qual o novo participante foi registado

Argumentos*

Argumento	Descrição
JOIN_DATA_PATH	O caminho do ficheiro de dados de junção da última etapa

Exemplo*

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

Aviso

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.

Nesta fase, o novo nó juntou-se como um nó « » ( ): está a sincronizar-se com o cluster, mas ainda não está operacional. Por outro lado, qualquer problema com o nó nesta fase não causará problemas ao cluster, tornando esta operação segura.

O passo final para concluir a adesão consiste em promover o novo nó a membro de pleno direito.

Promoting the New Learner

Dependendo das condições da rede e do cluster, pode demorar algum tempo até que o novo membro se sincronize com o cluster. Assim que isso acontecer, pode ser promovido de membro aprendiz a membro de pleno direito.

Aviso

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.

Pode tentar promover o novo membro da seguinte forma. O ID do membro pode ser encontrado ao listar os membros do cluster.

nitropyREST API

Argumentos*

Argumento	Descrição
MEMBER_ID	The ID of the learner to be promoted

Exemplo*

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

Se o aluno ainda não tiver recuperado o atraso, esta operação falhará (código HTTP 412 na API REST) e a promoção deverá ser tentada novamente mais 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

Você precisará de um ambiente com etcd v3.6 disponível, com um endereço IPv4 (pelo menos) acessível aos outros membros do seu cluster. O tráfego TCP de e para a porta 2380 precisa ser permitido.

Crie um diretório vazio onde etcd irá armazenar os seus dados, e escreva o seu caminho (utilizaremos /var/etcd/data). Certifique-se de que o utilizador que irá lançar o processo tem permissão para ler e escrever no diretório.

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.

Em seguida, será necessário criar um certificado para a testemunha e assiná-lo com a CA para que ela possa se comunicar com seus pares. Isto pode ser feito, por exemplo, atravé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

Armazene os resultados witness.key e witness.pem em /var/etcd também.

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

Ao contrário dos NetHSMs que escolhem automaticamente um nome de nó para si próprios (utilizando o ID do dispositivo), é necessário escolher um nome para cada testemunha que adicionar, certificando-se de que os nomes são únicos. Usaremos «witness1» nos exemplos a seguir.

Com a resposta do NetHSM ao registo da testemunha, preparar variáveis do formulário:

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"

Finalmente, crie um ficheiro etcd.conf.yml utilizando o ficheiro modelo fornecido em docs/etcd_witness.conf.template:

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

Isto deve fornecer-lhe um ficheiro do formulário:

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 da forma que preferir (manualmente, systemd serviço, contentor, etc.), apontando-o para o ficheiro de configuração criado no passo anterior:

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

Deve ver o processo a iniciar, juntar-se ao cluster como «aprendiz» e sincronizar-se com os dados.

Promote the Witness

Por fim, e após algum tempo, siga as instruções habituais da secção « : Promover o Novo Aluno» para promover o testemunho. Se isto não funcionar, tente novamente mais tarde.

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

etcdctl get /config/version

Esta chave deve existir e conter «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

Cópia de Segurança e Restauração

A operação de backup funciona da mesma forma que sem um cluster e pode ser solicitada a partir de qualquer nó do cluster. Fará o backup dos dados de todo o cluster, incluindo os campos específicos do nó (embora estes sejam ignorados, a menos que o backup seja restaurado num nó não provisionado).

Um backup feito num cluster pode ser restaurado no mesmo cluster, mesmo que alguns nós tenham sido adicionados ou removidos desde então. Esses restauros efectuados em clusters operacionais não afectarão os valores de configuração (apenas chaves, utilizadores, espaços de nomes), como qualquer outro restauro parcial.

O restauro de uma cópia de segurança num nó não provisionado irá restaurar os campos específicos do nó (como a configuração de rede, certificados, etc.) do nó que foi utilizado para criar a cópia de segurança.

O restauro de uma cópia de segurança grande pode sobrecarregar o cluster durante algum tempo, enquanto o nó que aplica o restauro encaminha as alterações para os outros.

Esta operação permanece compatível com as cópias de segurança efectuadas em versões anteriores do NetHSM.

Nota

Restaurar num nó A uma cópia de segurança efectuada noutro nó Z com uma chave de domínio diferente reescreverá corretamente a chave de domínio de A, como anteriormente. No entanto, se A estiver num cluster com o nó B, B ficará inoperacional, uma vez que a chave de domínio de Z não será restaurada em B.

Por outras palavras, apenas execute um restauro num cluster com backups efectuados no mesmo cluster (embora, mais uma vez, os nós possam ter sido removidos ou adicionados desde então). Se pretender restaurar uma cópia de segurança externa num nó, primeiro remova-o com segurança do respetivo cluster e, em seguida, proceda à reposição de fábrica e restaure a cópia de segurança.

Removendo um nó de forma limpa

Desde que alguma parte do cluster ainda esteja a cumprir o quórum, qualquer um dos seus membros pode ser utilizado para remover outro nó do cluster, quer este nó já esteja inacessível ou se espere que esteja.

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.

nitropyREST API

Argumentos*

Argumento	Descrição
MEMBER_ID	The ID of the node to be removed

Exemplo*

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

Nota

Um nó que tenha entrado a fazer parte do cluster, mas que ainda não tenha sido promovido, também pode ser removido com segurança desta forma.

Recovering a Failed Node

Um nó que indique o estado « » com falha recusar-se-á a responder à maioria das operações normais. Ainda assim, pode ser desligado, reiniciado, reinicializado, diagnosticado ou isolado.

Aviso

A existência do estado « » (Falha na verificação de quórum), bem como das operações diagnose e force-new, aplica-se apenas à versão 5.0 e seguintes. Na versão 4.0, um nó que tenha perdido o quórum deixará de responder a todas as solicitações. Este deve ser reposto às definições de fábrica.

Entre as causas mais comuns para que um nó se encontre no estado « Failed» incluem-se:

• Uma perda duradoura de quórum.

• Uma perda temporária do quórum (por exemplo, quando se adiciona um segundo nó ao cluster e este ainda não se integrou).

• O `etcd` está neste momento a ser reiniciado (por exemplo, porque os certificados foram alterados ou porque a rede foi reconfigurada).

• O cluster está a sofrer uma carga muito elevada (por exemplo, durante a restauração de uma cópia de segurança de grande dimensão).

Independentemente da causa, o NetHSM só passará para o estado « Failed» ( ) após, pelo menos, um minuto completo de tentativas infrutíferas de interagir com a sua base de dados. Isto tem como objetivo evitar transições espúrias causadas por instabilidades de curta duração.

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.

nitropyREST API

Exemplo*

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

Nota

Se e quando a base de dados voltar a estar disponível (por exemplo, se o quórum for restaurado porque o problema de rede foi resolvido), o NetHSM passará automaticamente do estado « Failed» para o estado em que se encontrava anteriormente (ou retomará a sequência normal de arranque, caso estivesse a arrancar), sem que seja necessária qualquer ação manual. Demorará até um minuto após a resolução do problema para que o cluster se estabilize, o HSM detecte a resolução e altere o seu estado.

Se concluir que a falha é duradoura (por exemplo, perda de quórum sem qualquer esperança de resolver a situação subjacente), pode:

• Reinicie o dispositivo para as predefinições de fábrica, o que apagará todos os dados, e restaure uma cópia de segurança.

• 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

Aviso

Após uma atualização a partir de uma versão < 5.0, o ponto final « ` » force-new` apresentará sempre o erro «Unauthorized» até que o HSM seja desbloqueado ou a frase-passe de desbloqueio seja alterada pelo menos uma vez.

Software Updates in Clusters

As futuras actualizações serão marcadas como «cluster-safe» (deve ser a maioria) ou «cluster-unsafe».

As actualizações à prova de cluster podem ser aplicadas a nós que fazem parte de um cluster sem removê-los do cluster primeiro. No entanto, tal como acontece com todas as operações, deve certificar-se de que o faz num nó de cada vez e num cluster em que a remoção de um nó não fique abaixo do quórum (por exemplo, se a atualização falhar).

As actualizações não seguras para o cluster devem ser aplicadas a nós isolados. Deve desmantelar o cluster (removendo os nós um a um), fazer a reposição de fábrica de todos os nós exceto um, aplicar a atualização a todos os nós e, em seguida, fazer com que todos os nós repostos se juntem ao nó restante.

Certifique-se de que efectua uma cópia de segurança antes destas operações.

Reconfiguração de um cluster existente

Changing the Cluster CA

Um cluster existente (com dois ou mais nós) não pode alterar sua CA de cluster enquanto estiver em operação. Se precisar de alterar este certificado: escolha um nó, remova todos os outros nós, actualize a CA e, em seguida, faça com que os outros membros se juntem novamente.

Changing the Network Configuration of Nodes

Modificar a configuração de rede de um nó (por exemplo, alterar o seu IP) informará automaticamente os outros nós sobre a atualização. No entanto, deve certificar-se de que apenas efectua essas actualizações num único nó de cada vez e num cluster em que a perda desse nó não perca o quórum.