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.
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 <clustering.html#recovering-a-failed-node> 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¶
A natureza do clustering com etcd torna-o mais confiável quanto mais nós houver no cluster. Como explicado na secção Redundância Operacional, os clusters devem idealmente ter pelo menos 3 nós para ter espaço para falhar, uma vez que um cluster de 2 nós irá falhar completamente se apenas um falhar.
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.
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 using the /config/network endpoint (refer to the API documentation).
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.
To do this, first generate a Certificate Signing Request (CSR) from the node with the /config/tls/csr.pem endpoint (refer to the API documentation).
Nota
To properly authenticate nodes, the clustering backend (etcd) expects that each node has a certificate with a properly filled Subject Alt Names (SAN) field.
Nodes are expected to be reached only via their IP and need to have a proper IP SAN in their certificate.
IP SANs can be requested for the CSR by prefixing «IP:» to the names, as in openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Se 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
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
Finalmente, a CA (CA.pem) pode agora ser instalada com o ponto de extremidade /config/tls/cluster-ca.pem (consulte a documentação da API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Isto só é possível quando o certificado TLS instalado é assinado por ela. Caso contrário, a operação será rejeitada.
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:
Register the addition to the cluster (through any one of its members)
Tell the new node to join
Assim que tiver recuperado o atraso, promova o nó de «aprendiz» a «membro de pleno direito»
Configure a Backup Passphrase¶
Primeiro, certifique-se de que está configurada uma frase-chave de backup no nó que será utilizado para registar um novo membro (consulte a documentação da API do ponto de extremidade /config/backup-passphrase).
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.
Você pode verificar se a URL está correta chamando GET /cluster/members no nó que se espera juntar. Isso deve listar apenas um membro: ele mesmo.
Em seguida, registe esse URL esperado em qualquer nó existente do cluster (se ainda não tiver um cluster, faça isso no NetHSM que servirá como o nó inicial do cluster). Isso é feito usando o endpoint POST /cluster/members (consulte a documentação da API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), passando-lhe um corpo JSON contendo o URL.
Se for bem sucedido, devolve um corpo JSON do formulário:
{
"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 contém a informação necessária para que o novo nó se junte ao cluster. Em particular, lista todos os membros do cluster (onde o membro com um nome vazio é o novo membro). Também contém a chave de domínio encriptada pelas frases-chave de desbloqueio e de backup - portanto, uma frase-chave de backup deve ter sido configurada anteriormente.
Nota
Repare que, na resposta acima, o novo membro é um «aprendiz»: já pode ligar-se ao cluster e receber dados do mesmo, mas não pode participar até ser promovido, o que será abordado mais adiante.
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 essa resposta para o passo seguinte.
Joining the Cluster as a Learner¶
Pegue na resposta do último passo e acrescente-lhe um campo backupPassphrase que contém a frase-chave de backup do nó no qual o novo membro foi registado, e passe esses dados para uma chamada a POST /cluster/join (consulte a documentação da API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) no nó que se espera que se junte.
Aviso
A chamada a POST /cluster/join ficará em espera até que o novo nó seja promovido manualmente (ver abaixo). Isto é normal. Quando a chamada é devolvida com sucesso, significa que a adesão e a promoção foram bem-sucedidas.
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
A promoção de um nó aumenta o limiar de quórum do cluster (consulte a documentação da API « » e a secção «Redundância Operacional» ` <clustering.html#operational-redundancy>` __ deste documento). Certifique-se de que este novo nó tem uma ligação estável ao cluster antes de o promover.
Pode tentar promover o novo membro através da chamada à função ` `` POST /cluster/members/{MemberID}/promote` (consulte a documentação da API do ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Se o aluno ainda não tiver atualizado os dados, esta operação falhará com o código HTTP 412 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).
Anote a resposta do cluster: deve conter a lista dos membros do cluster e um kit de aderente (não vai precisar desta parte).
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,..."
Assumindo que a resposta do NetHSM está armazenada num ficheiro response.json, é possível gerar estas duas últimas variáveis automaticamente com as seguintes expressões 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"
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.
Em primeiro lugar, é necessário saber o ID do nó que se pretende remover, listando todos os nós através de GET /cluster/members e procurando o nó correto.
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
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.
Para o ajudar a compreender em que situação se encontra o seu nó, o ponto final GET /health/diagnose continua disponível e devolve informações sobre o estado atual de etcd e da sua base de dados, incluindo registos (consulte a documentação da API).
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.
Isolar o nó com o ponto final
POST /cluster/force-new, o que fará com que este esqueça irreversivelmente todos os outros membros do cluster, recupere os dadosetcdpresentes no disco e reinicie. Se a falha subjacente estiver relacionada com o cluster, o nó seguirá a sequência normal de arranque e ficará no estado «Locked» ou «Operational», dependendo da configuração de arranque não supervisionado.
Nota
Se um nó for isolado com force-new, ficará agora dessincronizado com o cluster: quaisquer novas gravações nesse nó ou no cluster não poderão ser reconciliadas. O nó ainda poderá voltar a integrar-se no cluster, mas perderá todas as suas modificações locais.
O ponto final ` `` POST /cluster/force-new`, que só está disponível no estado «Failed» (Falha) ** , requer autenticação, uma vez que é potencialmente destrutivo. No entanto, dado que os utilizadores e funções do HSM não estão disponíveis nesse estado, o ponto final espera que os clientes HTTPS se autentiquem sempre com o utilizador fictício ` `` unlock` e com a mais recente frase de passagem de desbloqueio conhecida como palavra-passe.
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.