Gerenciar nós do cluster do Omnissa Access Control Plane

Este tópico descreve como substituir uma implantação existente do Control Plane adicionando nós de infraestrutura/plataforma da Omnissa e nós do Access, além de explicar o que ocorre quando um nó fica fora de estado e é removido do cluster.

Adicionar um nó do Omnissa Access ao cluster

É possível substituir um nó existente do Control Plane adicionando um nó do Omnissa Access com sistema operacional Linux ao cluster. Os novos nós são integrados usando o comando wso cp deploy do nó de bootstrap.

Pré-requisitos

• O endereço IP do novo nó foi adicionado a cp-cluster.ini ao grupo de hosts apropriado antes de executar o comando de implantação.
• O novo nó pode ser acessado via SSH a partir do nó de bootstrap.

Procedimento:

1. Abra o arquivo /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini e adicione o endereço IP do novo nó ao grupo de hosts apropriado. Por exemplo:

   Opção 1 – Nó do Omnissa Access: Se você estiver adicionando um novo nó do Omnissa Access, adicione-o nestas seções:

   [general_compute_access_linux]
   10.0.0.x
   10.0.0.x  # New node
   [vault_server_linux]
   10.0.0.x  # New node
   [consul_server_linux]
   10.0.0.x  # New node
   [nomad_server_linux]
   10.0.0.x  # New node
   [general_compute_nginx_http]
   10.0.0.x  # New node
   

   Opção 2 – Nó de infraestrutura/plataforma: Se você estiver adicionando um novo nó ao Nó de infraestrutura/plataforma, adicione-o em todas as seções, exceto nas seguintes seções:

   [general_compute_access_linux]
   [general_compute_nginx_http]
   [asset_server_linux]
   
   # If the new node is a candidate for asset-server-linux that will replace existing asset-server, you must add a node IP in asset_server_linux, too.
   

   Importante: não adicione o endereço IP do nó de bootstrap ao inventário. A validação falhará se o IP de bootstrap for detectado.

2. No nó de bootstrap, execute wso cp deploy para integrar o nó.

   • Para integrar um ou mais nós específicos, use o sinalizador -t (--target-hosts):

     # navigate to your cluster working directory
     cd /opt/wss/<cluster_name>
     wso cp deploy -t "10.0.0.x"
     

     Para vários nós:

     cd /opt/wss/<cluster_name>
     wso cp deploy -t "10.0.0.x,10.0.0.x"
     

3. Execute o seguinte comando para verificar se o cluster está íntegro:

   wso healthcheck
   

4. Mova cargas de trabalho (serviços) para o novo nó. Por padrão, nenhuma carga de trabalho será executada no nó recém-adicionado. Você deve fazer login na UI do Nomad usando o token do Nomad e realizar as etapas abaixo:

   1. Faça login na UI do Nomad em https://10.0.0.x:4646/ui/jobs.
   2. Clique em Clientes.
   3. Clique no ID do nó do qual você deseja mover as cargas de trabalho.
   4. Clique em Esvaziar para mover as cargas de trabalho para a nova VM.

   Nota: após a conclusão da operação de esvaziamento, todas as cargas de trabalho serão movidas para a nova VM. Não é possível mover os serviços selecionados para o novo nó.

5. Remova o nó existente do cluster executando o seguinte comando.

   # From the bootstrap VM
   source /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
   server_id = <node_ip> # IP of the node being removed
   
   # API to remove peer
   curl -sk \
   -H "X-Vault-Token: $VAULT_TOKEN" \
   -H "Content-Type: application/json" \
   -X POST \
   -d '{"server_id":"$server_id"}' \
   "$VAULT_ADDRESS/v1/sys/storage/raft/remove-peer"
   

6. Verifique a integridade do cluster e dos serviços.

   wso healthcheck
   wso access check-service-readiness
   

Solução de problemas

Remover um nó do Omnissa Access do cluster

Não há um comando CLI específico para remover um nó do Control Plane. Quando um nó fica indisponível ou em mau estado, o cluster lida com a remoção automaticamente:

• O nó deixa de receber novas alocações de carga de trabalho após aproximadamente dois heartbeats perdidos.
• As cargas de trabalho existentes no nó são reprogramadas para nós em bom estado.
• Não é necessário nenhum comando de remoção manual.

1. Remova o IP do nó antigo do arquivo cp-cluster.ini em todas as seções relevantes.
2. Desligue o nó removido.

Nota: a limpeza da lista de membros do cluster ocorre em um intervalo de tempo diferente da detecção de falhas:

• O Consul remove automaticamente os nós inativos de sua lista de membros em um período que varia de 24 a 72 horas.
• O Nomad remove nós obsoletos durante seu próximo ciclo de coleta de lixo.
• Por isso, um nó removido pode permanecer visível na UI do Nomad ou do Consul por algum tempo após parar de receber tráfego, mesmo que não seja mais utilizado para agendamento.

Gerenciamento de senhas para nós do Control Plane

A expiração-padrão da senha para as contas configuser e root é de 60 dias. É necessário alterar a senha em todos os nós do cluster do Control Plane antes que ela expire.

A senha de raiz e a senha de configuser não precisam corresponder entre si, mas cada uma deve ser idêntica em todos os nós do cluster. Por exemplo, a senha de raiz deve ser a mesma em todos os nós, e a senha de configuser deve ser a mesma em cada nó.

Redefina o configuser ou a senha de raiz

Nó único, conectado como raiz ou via sudo:

passwd configuser
passwd root

Em todos os nós de uma só vez, pelo nó de bootstrap:

export TARGETS='general_compute_linux:general_compute_access_linux'
wso control-plane ansible -- -b -m shell -a "echo 'configuser:NEW_PASSWORD' | chpasswd" "${TARGETS}"
wso control-plane ansible -- -b -m shell -a "echo 'root:NEW_PASSWORD' | chpasswd" "${TARGETS}"

Substitua NEW_PASSWORD pela senha real antes de executar e ${TARGETS} pelo grupo de inventário Ansible ou padrão de host para atualização dos nós: não deixe o espaço reservado literal em um script salvo ou no histórico do shell.

Importante: depois de alterar a senha de configuser, atualize a mesma senha em cp-cluster.ini no nó de bootstrap ou as operações da interface de linha de comando wso em relação ao cluster começarão a falhar na autenticação. As sessões ativas configuser não precisam ser invalidadas após uma redefinição.

Alterar o período de expiração da senha

A expiração de 60 dias é controlada por campos de expiração de senha em cada conta.

Nota: se estiver executando como configuser, use sudona frente dos comandos.

Verifique a configuração atual com:

chage -l configuser
chage -l root

Alterá-lo por conta (nó único):

chage -M <days> configuser
chage -M <days> root

-M define o número máximo de dias que uma senha permanece válida; -1 desativa a expiração (geralmente não recomendado para root ou contas de serviço).

Recuperar uma senha de raiz completamente esquecida

Isso requer acesso de console (hypervisor) à VM afetada: ela não pode ser feita por SSH e só recupera um nó de cada vez.

1. Reinicialize a VM e interrompa no menu GRUB.

2. Realce a entrada de inicialização e pressione e para editá-la.

3. Localize a linha que começa com linux (ou linux16), vá para o final dela e acrescente:

   rd.break enforcing=0
   

4. Pressione Ctrl+X (ou F10) para inicializar com os parâmetros modificados. Isso o coloca no shell de emergência Dracut.

5. Remonte o sistema de arquivos raiz em modo leitura-gravação e execute o chroot nele:

   mount -o remount,rw /sysroot
   chroot /sysroot
   

6. Defina a nova senha:

   passwd root
   

7. Marque o sistema de arquivos para que o SELinux o reclassifique na próxima inicialização, já que o SELinux estava no modo permissivo nesta sessão:

   touch /.autorelabel
   

8. Saia da chroot e reinicialize:

   exit
   reboot
   

   A primeira inicialização após isso demora mais do que o normal devido à reclassificação do SELinux.