Introduction
Este documento descreve o procedimento para solucionar problemas de Alta Disponibilidade (HA) no gerenciador de cluster da Plataforma de Implantação Nativa na Nuvem (CNDP).
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Infraestrutura Cisco Subscriber Microservices (SMI)
- Arquitetura 5G CNDP ou SMI-Bare-metal (BM)
- DRBD (Distributed Replicated Block Device, dispositivo de bloco replicado distribuído)
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- SMI 2020.2.2.35
- Kubernetes v1.21.0
- DRBD 8 9 10
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
O que é SMI?
O Cisco SMI é uma pilha em camadas de tecnologias e padrões de nuvem que permitem aplicativos baseados em microsserviços das unidades de negócios Cisco Mobility, Cable e Broadband Network Gateway (BNG) - todas com funções semelhantes de gerenciamento de assinantes e requisitos semelhantes de armazenamento de dados.
Atributos:
- Pilha de nuvem em camadas (tecnologias e padrões) para fornecer implantações de cima para baixo e também acomodar a infraestrutura atual de nuvem do usuário.
- Ambiente de execução comum compartilhado por todos os aplicativos para funções que não sejam de aplicativos (armazenamento de dados, implantação, configuração, telemetria, alarme). Isso fornece interação e experiência consistentes para todos os pontos de contato e pontos de integração do usuário.
- Aplicativos e Common Execution Environments são implantados em contêineres de microsserviço e conectados com uma Intelligent Service Mesh.
- API exposta para implantação, configuração e gerenciamento, a fim de permitir a automação.
O que é SMI-BM ou CNDP?
O Cisco SMI-BM ou CNDP é uma plataforma bare-metal com curadoria que fornece a infraestrutura para implantar Funções de Rede Virtual (VNF - Virtual Network Functions) e Funções Nativas de Nuvem (CNFs - Cloud-Native Functions), que possibilita a mobilidade, o cabo e as unidades de negócios BNG da Cisco.
Atributos:
- BM que elimina a sobrecarga relacionada ao Virtualized Infrastructure Manager (VIM).
- Melhor desempenho:
- Mais núcleos para aplicativos
- Execução mais rápida de aplicativos
- Fluxo de trabalho de implantação automatizado, integrado com o Pacote de Função Central (CFP - Core Function Packet) do Network Services Orchestrator (NSO)
- Pilha com curadoria para implantar funções de rede (NFs) Cisco 5G
- Guia simplificado de pedidos e implantação
O que é um gerenciador de cluster SMI?
Um gerenciador de cluster é um keepalived cluster usado como o ponto inicial para implantação de cluster de plano de controle e plano de usuário. Ele executa um cluster Kubernetes de nó único e um conjunto de PODs que são responsáveis por toda a configuração do cluster. Somente o gerenciador de cluster primário está ativo e o secundário assume somente em caso de falha ou é desativado manualmente para manutenção.
O que é DRBD?
O DRBD é usado para aumentar a disponibilidade dos dados. É um componente de software de código aberto baseado em Linux que facilita a substituição de sistemas de armazenamento compartilhado por um espelho de rede. Resumindo, você pode dizer que este é um "espelho RAID 1 baseado em rede para os dados".
Problema
O gerenciador de cluster é hospedado em um cluster de 2 nós com DRBD e keepalived. O HA pode se quebrar e também pode entrar em um estado split-brain. Este procedimento ajuda a recuperar o cluster quebrado. O estado desejado de HA do gerenciador de cluster é que cluster manager1 (CM1) é principal e cluster manager2 (CM2) é secundário. Aqui, o CM1 é a vítima do split-brain.
Procedimento de manutenção
Faça login no gerenciador de cluster e verifique o status do cluster DRBD.
cloud-user@pod-name-cm-1:~$ drbd-overview
0:data/0 WFConnection Secondary/Unknown UpToDate/DUnknown
cloud-user@pod-name-cm-2:~$ drbd-overview
0:data/0 StandAlone Primary/Unknown UpToDate/DUnknown /mnt/stateful_partition ext4 568G 147G 392G 28%
Neste cenário, o CM2 é primário e o cluster está no modo autônomo. CM1 é atualmente secundário e está em wait for connection estado.
Este é o estado correto do cluster:
cloud-user@pod-name-deployer-cm-1:~$ drbd-overview
0:data/0 Connected Primary/Secondary UpToDate/UpToDate /mnt/stateful_partition ext4 568G 364G 176G 68%
cloud-user@pod-name-deployer-cm-2:~$ drbd-overview
0:data/0 Connected Secondary/Primary UpToDate/UpToDate Move the CM VIP to CM-1 from CM-2 and make CM-1 as primary –
Mova o CM VIP de CM-2 para CM-1 e torne CM-1 primário (o VIP do gerenciador de cluster é 10.x.x.65
On CM-2 issue below command
cloud-user@pod-name-cm-2:~$sudo systemctl restart keepalived
On CM-1 issue below command (Make sure that the VIP is now switched over to CM-1)
cloud-user@pod-name-cm-1:~$ip a s | grep 10.x.x
inet 10.x.x.70/26 brd 10.x.x.127 scope global vlan1xx ----> here is the server IP
inet 10.x.x.65/26 scope global secondary vlan1xx. ----> here is the VIP
Identificar o recurso DRBD (compartilhado pela rede):
cloud-user@pod-name-deployer-cm-1:/$ cat /etc/fstab
#/mnt/stateful_partition/data /data none defaults,bind 0 0 ---> /data is the resource
#/mnt/stateful_partition/home /home none defaults,bind 0 0
cloud-user@pod-name-deployer-cm-1:/$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 189G 0 189G 0% /dev
tmpfs 38G 22M 38G 1% /run
/dev/sda1 9.8G 3.5G 5.9G 37% /
tmpfs 189G 0 189G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 189G 0 189G 0% /sys/fs/cgroup
/dev/sda4 71G 1.5G 66G 3% /tmp
/dev/sda3 71G 11G 57G 16% /var/log
/dev/drbd0 568G 365G 175G 68% /mnt/stateful_partition -->/dev/drbd0 is the device name
tmpfs 38G 0 38G 0% /run/user/1000
cloud-user@pod-name-deployer-cm-1:/$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 744.1G 0 disk
├─sda1 8:1 0 10G 0 part /
├─sda2 8:2 0 10G 0 part
├─sda3 8:3 0 72.2G 0 part /var/log
├─sda4 8:4 0 72.2G 0 part /tmp
├─sda5 8:5 0 577.6G 0 part
│ └─drbd0 147:0 0 577.5G 0 disk /mnt/stateful_partition ---> /dev/sda5 is used to create drbd0
Verifique o arquivo de configuração DRBD para obter os detalhes do recurso:
cloud-user@pod-name-deployer-cm-1:/$ cat /etc/drbd.d/data.res
resource data {
protocol C; --->Synchronous replication protocol. Local write operations on the primary node are considered completed only after both the local and the remote disk write have been confirmed. As a result, loss of a single node is guaranteed not to lead to any data loss
....
....
device /dev/drbd0;
disk /dev/disk/by-partlabel/smi-state; --> This translates to /dev/sda5
meta-disk internal;
floating 10.192.1.2:7789;
floating 10.192.1.3:7789;
Agora, execute a recuperação DRBD:
On CM-2
cloud-user@pod-name-cm-2:~$ sudo systemctl stop keepalived ---> stop to avoid VRRP VIP switchover
cloud-user@pod-name-cm-2:~$ sudo drbdadm disconnect data ---> data is the cluster resource
cloud-user@pod-name-cm-2:~$ sudo drbdadm secondary data ---> Make it secondary manually
cloud-user@pod-name-cm-2:~$ sudo drbdadm connect --discard-my-data data ---> Force discard of all modifications on the split brain victim
cloud-user@pod-name-cm-2:~$ drbd-overview status
On CM-1:
cloud-user@pod-name-cm-1:~$ sudo systemctl stop keepalived ---> stop to avoid VRRP VIP switchover
cloud-user@pod-name-cm-1:~$ sudo drbdadm connect data ---> Data will be connected as primary
cloud-user@pod-name-cm-1:~$ drbd-overview status
Iniciar keepalived processo em ambos os CMs. VRRP com a ajuda de keepalived seleciona CM-1 como principal, com base no recurso principal conectado /data:
cloud-user@pod-name-cm-1:~$ sudo systemctl start keepalived
cloud-user@pod-name-cm-1:~$ sudo systemctl status keepalived
cloud-user@pod-name-cm-2:~$ sudo systemctl start keepalived
cloud-user@pod-name-cm-2:~$ sudo systemctl status keepalived
Verifique o status DRBD em CM-1 e CM-2. Ele deve ser transformado para o estado de cluster correto agora.
cloud-user@pod-name-deployer-cm-1:~$ drbd-overview
0:data/0 Connected Primary/Secondary UpToDate/UpToDate /mnt/stateful_partition ext4 568G 364G 176G 68%
cloud-user@pod-name-deployer-cm-2:~$ drbd-overview
0:data/0 Connected Secondary/Primary UpToDate/UpToDate Move the CM VIP to CM-1 from CM-2 and make CM-1 as primary
/data é montado somente no nó primário.
cloud-user@pod-name-deployer-cm-1:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 189G 0 189G 0% /dev
tmpfs 38G 22M 38G 1% /run
/dev/sda1 9.8G 3.5G 5.9G 37% /
tmpfs 189G 0 189G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 189G 0 189G 0% /sys/fs/cgroup
/dev/sda4 71G 1.5G 66G 3% /tmp
/dev/sda3 71G 11G 57G 16% /var/log
/dev/drbd0 568G 364G 175G 68% /mnt/stateful_partition
tmpfs 38G 0 38G 0% /run/user/1000
cloud-user@pod-name-deployer-cm-secondary:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 189G 0 189G 0% /dev
tmpfs 38G 2.3M 38G 1% /run
/dev/sda1 9.8G 2.0G 7.3G 22% /
tmpfs 189G 0 189G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 189G 0 189G 0% /sys/fs/cgroup
/dev/sda3 71G 9.3G 58G 14% /var/log
/dev/sda4 71G 53M 67G 1% /tmp
tmpfs 38G 0 38G 0% /run/user/1000
Feedback