documentation.suse.com / Documentação do SUSE Edge / Documentação do produto / Requisitos e suposições

39 Requisitos e suposições

 

39.1 Hardware

 

Veja a seguir os requisitos de hardware para o SUSE Edge for Telco:

  • Cluster de gerenciamento: contém componentes, como SUSE Linux Micro, RKE2, SUSE Rancher Prime e Metal3, e é usado para gerenciar vários clusters downstream. Dependendo do número de clusters downstream que será gerenciado, os requisitos de hardware para o servidor podem variar.

    • Os requisitos mínimos para o servidor (VM ou bare metal) são:

      • RAM: mínimo de 8 GB (recomendamos pelo menos 16 GB)

      • CPU: mínimo de 2 (recomendamos pelo menos 4)

  • Clusters downstream: trata-se dos clusters implantados para executar as cargas de trabalho de telecomunicações. Requisitos específicos são necessários para habilitar determinados recursos de telecomunicações, como SR-IOV, otimização de desempenho da CPU etc.

    • SR-IOV: para anexar funções virtuais (VFs, Virtual Functions) no modo de passagem a CNFs/VNFs, a NIC deve permitir que SR-IOV e VT-d/AMD-Vi sejam habilitados no BIOS.

    • Processadores de CPU: para executar cargas de trabalho de telecomunicações, o modelo de processador da CPU deve ser adaptado para disponibilizar a maior parte dos recursos nesta tabela de referência (Capítulo 41, Configuração dos recursos de telecomunicações).

    • Requisitos de firmware para instalação com mídia virtual:

Hardware de servidor

Modelo de BMC

Gerenciamento

Hardware Dell

15ª geração

iDRAC9

Hardware Supermicro

01.00.25

Supermicro SMC – redfish

Hardware HPE

1.50

iLO6

39.2 Rede

 

Como referência à arquitetura de rede, o seguinte diagrama mostra uma arquitetura de rede típica para um ambiente de telecomunicações:

requisitos1 produto atip

A arquitetura de rede baseia-se nos seguintes componentes:

  • Rede de gerenciamento: essa rede é usada para gerenciamento de nós do cluster downstream. Ela é usada para gerenciamento fora da banda. Em geral, essa rede também é conectada a um comutador de gerenciamento separado, mas pode ser conectada ao mesmo comutador de serviço usando VLANs para isolar o tráfego.

  • Rede do plano de controle: essa rede é usada para comunicação entre os nós do cluster downstream e os serviços executados neles. Ela também é usada para comunicação entre os nós e os serviços externos, como servidores DHCP ou DNS. Em alguns casos, o comutador/roteador processa o tráfego pela Internet nos ambientes conectados.

  • Outras redes: em alguns casos, os nós podem se conectar a outras redes para finalidades específicas.

Nota
Nota

Para usar o fluxo de trabalho de provisionamento de rede direcionado, o cluster de gerenciamento deve ter conectividade de rede com o Baseboard Management Controller (BMC) do servidor de cluster downstream para que seja possível automatizar a preparação e o provisionamento do host.

39.3 Serviços (DHCP, DNS etc.)

 

Alguns serviços externos, como DHCP, DNS etc., podem ser necessários, dependendo do tipo de ambiente em que estão implantados:

  • Ambiente conectado: nesse caso, os nós são conectados à Internet (por protocolos de roteamento L3), e o cliente providencia os serviços externos.

  • Ambiente desconectado/air-gapped: nesse caso, os nós não têm conectividade IP de Internet e são exigidos serviços adicionais para espelhar localmente o conteúdo necessário pelo fluxo de trabalho de provisionamento de rede direcionado.

  • Servidor de arquivos: usado para armazenar as imagens de sistema operacional que são provisionadas nos nós do cluster downstream durante o fluxo de trabalho de provisionamento de rede direcionado. O gráfico Helm do Metal3 pode implantar um servidor de mídia para armazenar as imagens de sistema operacional. Consulte a seguinte seção (Nota), mas também é possível usar um servidor web local existente.

39.4 Desabilitando os serviços systemd

 

Para cargas de trabalho de telecomunicações, é importante desabilitar ou configurar apropriadamente alguns dos serviços executados nos nós para evitar qualquer impacto no desempenho das cargas de trabalho em execução nos nós (latência).

  • rebootmgr é um serviço que permite configurar uma estratégia de reinicialização quando o sistema tem atualizações pendentes. Para cargas de trabalho de telecomunicações, é realmente importante desabilitar ou configurar apropriadamente o serviço rebootmgr para evitar a reinicialização dos nós em caso de atualizações programadas pelo sistema, a fim de evitar qualquer impacto nos serviços executados nos nós.

Nota
Nota

Para obter mais informações sobre o rebootmgr, consulte o repositório rebootmgr do GitHub.

Verifique a estratégia usada executando este comando:

cat /etc/rebootmgr.conf
[rebootmgr]
window-start=03:30
window-duration=1h30m
strategy=best-effort
lock-group=default

e você pode desabilitá-la executando:

sed -i 's/strategy=best-effort/strategy=off/g' /etc/rebootmgr.conf

ou usando o comando rebootmgrctl:

rebootmgrctl strategy off
Nota
Nota

É possível automatizar essa configuração para definir a estratégia rebootmgr usando o fluxo de trabalho de provisionamento de rede direcionado. Para obter mais informações, consulte a documentação sobre provisionamento automatizado (Capítulo 42, Provisionamento de rede direcionado totalmente automatizado).

  • transactional-update é um serviço que permite que o sistema controle as atualizações automáticas. Para cargas de trabalho de telecomunicações, é importante desabilitar as atualizações automáticas para evitar qualquer impacto nos serviços executados nos nós.

Para desabilitar as atualizações automáticas, execute:

systemctl --now disable transactional-update.timer
systemctl --now disable transactional-update-cleanup.timer

  • fstrim é um serviço que permite cortar os sistemas de arquivos automaticamente toda semana. Para cargas de trabalho de telecomunicações, é importante desabilitar o corte automático para evitar qualquer impacto nos serviços executados nos nós.

Para desabilitar o corte automático, execute:

systemctl --now disable fstrim.timer
Documentation survey