Pré-requisitos da plataforma Operador Nexus

Artigo
04/22/2024

As operadoras precisam preencher os pré-requisitos antes da implantação do software da plataforma Operator Nexus. Como algumas dessas etapas podem levar muito tempo, é recomendado examinar os pré-requisitos.

Em implantações subsequentes de instâncias do Operator Nexus, você pode pular para a criação do Network Fabric e do Cluster locais.

Pré-requisitos do Azure

Ao implantar o Operator Nexus pela primeira vez ou em uma nova região, primeiro você precisará criar um Network Fabric Controller e, em seguida, um Cluster Manager conforme especificado aqui. Além disso, as seguintes tarefas precisam ser realizadas:

Configurar usuários, políticas, permissões e o RBAC
Configure grupos de recursos para incluir e agrupar de maneira lógica os recursos que serão criados para a plataforma Operator Nexus.
Estabelecer a conectividade do ExpressRoute de sua WAN com uma região do Azure
Para habilitar o Microsoft Defender para Ponto de Extremidade para máquinas bare metal (BMMs) locais, você deve ter selecionado um plano Defender para Servidores em sua assinatura do Operador Nexus antes da implantação. Informações adicionais disponíveis aqui.

Pré-requisitos no local

Ao implantar a instância local do Operator Nexus em seu datacenter, é provável que várias equipes estejam envolvidas para desempenhar diversas funções. As tarefas a seguir devem ser executadas com precisão para garantir uma instalação bem-sucedida do software da plataforma.

Configuração de hardware físico

Uma operadora que desejar aproveitar as vantagens do serviço Operator Nexus precisa adquirir, instalar, configurar e operar recursos de hardware. Essa seção do documento descreve os componentes e esforços necessários para adquirir e implementar os sistemas de hardware apropriados. Essa seção discute a lista de materiais, o diagrama de elevação do rack e o diagrama de cabeamento, bem como as etapas necessárias para montar o hardware.

Usando a lista de materiais (BOM)

Para garantir uma experiência perfeita ao operador, a Operator Nexus desenvolveu uma lista técnica para aquisição de hardware necessária para o serviço. Essa BOM é uma lista abrangente dos componentes e quantidades necessárias para implementar o ambiente para uma implementação e manutenção bem-sucedidas da instância local. A BOM está estruturada para fornecer ao operador uma série de unidades de manutenção de estoque (SKU) que podem ser encomendadas de fornecedores de hardware. Os SKUs serão discutidos posteriormente nesse documento.

Usando o diagrama de elevação

O diagrama de elevação do rack é uma referência gráfica que demonstra como os servidores e outros componentes se encaixam nos racks montados e configurados. O diagrama de elevação do rack é fornecido como parte das instruções gerais de build. Ele ajudará a equipe de operadores a configurar e instalar corretamente todos os componentes de hardware necessários para a operação do serviço.

Diagrama de cabeamento

Os diagramas de cabeamento são representações gráficas das conexões de cabos necessárias para fornecer serviços de rede aos componentes instalados nos racks. Seguir o diagrama de cabeamento garante a implementação adequada dos vários componentes da build.

Como fazer pedidos com base no SKU

Definição de SKU

Um SKU é um método de gerenciamento e rastreamento de estoque que permite agrupar vários componentes em um único designador. Um SKU permite que um operador solicite todos os componentes necessários especificando um número de SKU. O SKU agiliza a interação entre operador e fornecedor, ao mesmo tempo que reduz erros de pedido devido a listas de peças complexas.

Fazendo um pedido baseado em SKU

A Operadora Nexus criou uma série de SKUs com fornecedores como Dell, Pure Storage e Arista que a operadora pode consultar quando fizer um pedido. Assim, um operador simplesmente precisa fazer um pedido com base nas informações de SKU fornecidas pelo Operador Nexus ao fornecedor para receber a lista de peças correta para a build.

Como fazer o build a pegada física do hardware

O build do hardware físico é executada através de uma série de etapas que serão detalhadas nessa seção. Existem três etapas de pré-requisito antes da execução do build. Essa seção também discutirá suposições relativas às habilidades dos funcionários da operadora para executar a build.

Pedido e recebimento do SKU específico da infraestrutura de hardware

O pedido do SKU apropriado e a entrega do hardware no local devem ocorrer antes do início da build. Deve ser concedido tempo adequado para essa etapa. Recomendamos que o operador comunique-se com o fornecedor do hardware no início do processo para garantir e compreender os prazos de entrega.

Preparação do local

O local de instalação pode suportar a infraestrutura de hardware do ponto de vista de espaço, energia e rede. Os requisitos específicos do site serão definidos pelo SKU adquirido para o site. Essa etapa pode ser realizada após a realização do pedido e antes do recebimento do SKU.

Agendamento de recursos

O processo de build exige vários membros diferentes da equipe para realizar a build, como engenheiros para fornecer energia, acesso à rede e cabeamento, equipe de sistemas para montar os racks, switches e servidores, para citar alguns. Para garantir que a build seja realizada em tempo hábil, recomendamos agendar esses membros da equipe com antecedência com base no cronograma de entrega.

Suposições sobre o desenvolvimento de habilidades da equipe

A equipe que executa a build deve ter experiência na montagem de hardware de sistemas, como racks, switches, PDUs e servidores. As instruções fornecidas discutirão as etapas do processo, ao mesmo tempo em que farão referência às elevações do rack e aos diagramas de cabeamento.

Visão geral do processo de build

Se a preparação do site estiver concluída e validada para suportar o SKU solicitado, o processo de build ocorrerá nas seguintes etapas:

Monte os racks com base nas elevações do rack do SKU. Instruções específicas de montagem do rack serão fornecidas pelo fabricante do rack.
Após a montagem dos racks, instale os dispositivos de tecido nos racks de acordo com o diagrama de elevação.
Cabeie os dispositivos de malha conectando as interfaces de rede de acordo com o diagrama de cabeamento.
Monte e instale os servidores de acordo com o diagrama de elevação do rack.
Monte e instale o dispositivo de armazenamento de acordo com o diagrama de elevação do rack.
Cabeie o servidor e os dispositivos de armazenamento conectando as interfaces de rede de acordo com o diagrama de cabeamento.
Cabo de alimentação de cada dispositivo.
Revise/valide a build por meio das listas de verificação fornecidas pelo Operador Nexus e outros fornecedores.

Como inspecionar visualmente a instalação física do hardware

Recomenda-se etiquetar todos os cabos seguindo os padrões ANSI/TIA 606, ou os padrões do operador, durante o processo de build. O processo de build também deve criar mapeamento reverso para o cabeamento de uma porta do switch até a conexão remota. O mapeamento reverso pode ser comparado ao diagrama de cabeamento para validar a instalação.

Configuração do Terminal Server e da matriz de armazenamento

Agora que a instalação física e a validação foram concluídas, as próximas etapas envolveram a definição das configurações padrão necessárias antes da instalação do software da plataforma.

Configurar o servidor de terminal

O Terminal Server foi implantado e configurado da seguinte forma:

O Terminal Server está configurado para gerenciamento fora de banda
- As credenciais de autenticação foram configuradas
- O cliente DHCP está habilitado na porta de gerenciamento fora de banda
- o acesso HTTP está habilitado
A interface do Terminal Server é conectada aos roteadores do provedor Edge (PEs) locais da operadora e configurada com os endereços IP e credenciais
O Terminal Server é acessível por meio da VPN de gerenciamento

Etapa 1: configuração do nome do host

Para configurar o nome do host do seu servidor de terminal, siga estas etapas:

Use o comando a seguir na CLI:

sudo ogcli update system/hostname hostname=\"$TS_HOSTNAME\"

Parâmetros:

Nome do Parâmetro	Descrição
TS_HOSTNAME	Nome do host do servidor de terminal

Confira a Referência da CLI para mais informações.

Etapa 2: configuração da rede

Para configurar a rede, siga estas etapas:

Execute os seguintes comandos na CLI:

sudo ogcli create conn << 'END'
  description="PE1 to TS NET1"
  mode="static"
  ipv4_static_settings.address="$TS_NET1_IP"
  ipv4_static_settings.netmask="$TS_NET1_NETMASK"
  ipv4_static_settings.gateway="$TS_NET1_GW"
  physif="net1"
  END
sudo ogcli create conn << 'END'
  description="PE2 to TS NET2"
  mode="static"
  ipv4_static_settings.address="$TS_NET2_IP"
  ipv4_static_settings.netmask="$TS_NET2_NETMASK"
  ipv4_static_settings.gateway="$TS_NET2_GW"
  physif="net2"
  END

Parâmetros:

Nome do Parâmetro	Descrição
TS_NET1_IP	IP do servidor de terminal PE1 para TS NET1
TS_NET1_NETMASK	Máscara de rede do servidor de terminal PE1 para TS NET1
TS_NET1_GW	Gateway do servidor de terminal PE1 para TS NET1
TS_NET2_IP	IP do servidor de terminal PE2 para TS NET2
TS_NET2_NETMASK	Máscara de rede do servidor de terminal PE2 para TS NET2
TS_NET2_GW	Gateway de servidor de terminal PE2 para TS NET2

Observação

Substitua esses parâmetros pelos valores adequados.

Etapa 3: Limpeza da interface net3 (se existente)

Para limpar a interface net3, siga estas etapas:

Verifique se existe alguma interface configurada na interface física net3 e no "Endereço estático IPv4 padrão" usando o comando a seguir:

ogcli get conns 
**description="Default IPv4 Static Address"**
**name="$TS_NET3_CONN_NAME"**
**physif="net3"**

Parâmetros:

Nome do Parâmetro	Descrição
TS_NET3_CONN_NAME	Nome da conexão NET3 do servidor de terminal

Remova a interface se ela existir:

ogcli delete conn "$TS_NET3_CONN_NAME"

Observação

Substitua esses parâmetros pelos valores adequados.

Etapa 4: Configuração do usuário administrador de suporte

Para configurar o usuário administrador de suporte, siga estas etapas:

Para cada usuário, execute o comando a seguir na CLI:

ogcli create user << 'END'
description="Support Admin User"
enabled=true
groups[0]="admin"
groups[1]="netgrp"
hashed_password="$HASHED_SUPPORT_PWD"
username="$SUPPORT_USER"
END

Parâmetros:

Nome do Parâmetro	Descrição
SUPPORT_USER	Suporte ao usuário administrador
HASHED_SUPPORT_PWD	Senha codificada do usuário administrador de suporte

Observação

Substitua esses parâmetros pelos valores adequados.

Etapa 5: Adição de suporte sudo para usuários administradores

Para adicionar suporte sudo para usuários administradores, siga estas etapas:

Abra o arquivo de configuração sudoers:

sudo vi /etc/sudoers.d/opengear

Inclua as linhas a seguir para conceder acesso ao sudo:

%netgrp ALL=(ALL) ALL
%admin ALL=(ALL) NOPASSWD: ALL

Observação

Salve as alterações depois de editar o arquivo.

Essa configuração permite que os membros do grupo "netgrp" executem qualquer comando como qualquer usuário e membro do grupo "administrador" para executar comandos como qualquer usuário sem a necessidade de uma senha.

Etapa 6: Garantia da disponibilidade do serviço LLDP

Para garantir que o serviço LLDP esteja disponível no seu servidor de terminal, siga estes passos:

Verifique se o serviço LLDP está em execução:

sudo systemctl status lldpd

Você deve ver uma saída semelhante à seguinte se o serviço estiver em execução:

lldpd.service - LLDP daemon
   Loaded: loaded (/lib/systemd/system/lldpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2023-09-14 19:10:40 UTC; 3 months 25 days ago
     Docs: man:lldpd(8)
 Main PID: 926 (lldpd)
    Tasks: 2 (limit: 9495)
   Memory: 1.2M
   CGroup: /system.slice/lldpd.service
           ├─926 lldpd: monitor.
           └─992 lldpd: 3 neighbors.
Notice: journal has been rotated since unit was started, output may be incomplete.

Se o serviço não estiver ativo (em execução), inicie o serviço:

sudo systemctl start lldpd

Habilite o serviço para começar na reinicialização:

sudo systemctl enable lldpd

Observação

Realize estas etapas para garantir que o serviço LLDP fique sempre disponível e inicie automaticamente após a reinicialização.

Etapa 7: Verificação da data/hora do sistema

Verifique se a data/hora do sistema está configurada corretamente e se o fuso horário do servidor de terminal está em UTC.

Verificar a configuração do fuso horário:

Para verificar a configuração atual do fuso horário:

ogcli get system/timezone

Definir o fuso horário como UTC:

Se o fuso horário não estiver definido como UTC, você poderá configurá-lo usando:

ogcli update system/timezone timezone=\"UTC\"

Verificar a data/hora atual:

Verifique a data e hora atuais:

date

Corrigir data/hora se estiverem incorretas:

Se a data e hora estiverem incorretas, você poderá corrigi-las usando:

ogcli replace system/time
Reading information from stdin. Press Ctrl-D to submit and Ctrl-C to cancel.
time="$CURRENT_DATE_TIME"

Parâmetros:

Nome do Parâmetro	Descrição
CURRENT_DATE_TIME	Data e hora atual no formato hh:mm MMM DD, YYYY

Observação

Garanta que a data/hora do sistema estejam precisas para evitar problemas com aplicativos ou serviços que dependam disso.

Etapa 8: Rotulação das portas do Servidor de Terminal (se ausentes/incorretas)

Para rotular portas do Servidor de Terminal, use o comando a seguir:

ogcli update port "port-<PORT_#>"  label=\"<NEW_NAME>\"	<PORT_#>

Parâmetros:

Nome do Parâmetro	Descrição
NEW_NAME	Nome do rótulo da porta
PORTA_#	Número da porta do Terminal Server

Etapa 9: configurações necessárias para conexões seriais do PURE Array

As matrizes do Armazenamento Pura adquiridas antes de 2024 têm controladores R3 de revisão que usam cabos de console de substituição e exigem os comandos de conexão de porta serial personalizados abaixo:

Controladores R3 do Armazenamento Pura:

ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X1"' <PORT_#>	Pure Storage Controller console

Os dispositivos mais recentes do Armazenamento Pura e dos sistemas atualizados dos controladores do Armazenamento Pura R3 para R4 usarão cabos de console de passagem direta com as configurações atualizadas abaixo:

Controladores R4 do Armazenamento Pura:

ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X2"' <PORT_#>	Pure Storage Controller console

Parâmetros:

Nome do Parâmetro	Descrição
PORTA_#	Número da porta do Terminal Server

Esses comandos definem a taxa de transmissão e a pinagem da conexão com o console do Controlador do Armazenamento Pura.

Observação

Todas as outras definições de configuração da porta do Terminal Server devem permanecer as mesmas e funcionar por padrão com um cabo de console RJ45 de passagem direta.

Etapa 10: Verificação das configurações

Para verificar as configurações, execute os comandos a seguir:

ping $PE1_IP -c 3  # Ping test to PE1 //TS subnet +2
ping $PE2_IP -c 3  # Ping test to PE2 //TS subnet +2
ogcli get conns     # Verify NET1, NET2, NET3 Removed
ogcli get users     # Verify support admin user
ogcli get static_routes  # Ensure there are no static routes
ip r                # Verify only interface routes
ip a                # Verify loopback, NET1, NET2
date                # Check current date/time
pmshell             # Check ports labelled

sudo lldpctl
sudo lldpcli show neighbors  # Check LLDP neighbors - should show data from NET1 and NET2

Observação

Verifique se os vizinhos do LLDP estão conforme o esperado, indicando conexões bem-sucedidas com PE1 e PE2.

Exemplo de saída de vizinhos LLDP:

-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    net2, via: LLDP, RID: 2, Time: 0 day, 20:28:36
  Chassis:     
    ChassisID:    mac 12:00:00:00:00:85
    SysName:      austx502xh1.els-an.att.net
    SysDescr:     7.7.2, S9700-53DX-R8
    Capability:   Router, on
  Port:         
    PortID:       ifname TenGigE0/0/0/0/3
    PortDescr:    GE10_Bundle-Ether83_austx4511ts1_net2_net2_CircuitID__austxm1-AUSTX45_[CBB][MCGW][AODS]
    TTL:          120
-------------------------------------------------------------------------------
Interface:    net1, via: LLDP, RID: 1, Time: 0 day, 20:28:36
  Chassis:     
    ChassisID:    mac 12:00:00:00:00:05
    SysName:      austx501xh1.els-an.att.net
    SysDescr:     7.7.2, S9700-53DX-R8
    Capability:   Router, on
  Port:         
    PortID:       ifname TenGigE0/0/0/0/3
    PortDescr:    GE10_Bundle-Ether83_austx4511ts1_net1_net1_CircuitID__austxm1-AUSTX45_[CBB][MCGW][AODS]
    TTL:          120
-------------------------------------------------------------------------------

Observação

Verifique se a saída corresponde às suas expectativas e se todas as configurações estão corretas.

Configurar uma matriz de armazenamento

O operador precisa instalar o hardware da matriz de armazenamento conforme especificado pela BOM e de acordo com a elevação do Rack de Agregação.
Ele também precisa fornecer informações ao técnico da matriz de armazenamento para que ele chegue ao local a fim de configurar o dispositivo.
Dados específicos do local que são compartilhados com o técnico da matriz de armazenamento:
- Nome do cliente:
- Data da inspeção física:
- Número de série do chassi:
- Nome do host da matriz de armazenamento:
- Código do CLLI (identificador de local de linguagem comum):
- Endereço da instalação:
- Local do FIC/rack/grade:
Dados fornecidos ao operador e compartilhados com o técnico da matriz de armazenamento, que serão comuns a todas as instalações:
- Nível do código de pureza: consulte as versões com suporte para Pureza
- Modo de Segurança: desabilitado
- Fuso horário da matriz: UTC
- Endereço IP do servidor DNS (Sistema de Nomes de Domínio): 172.27.255.201
- Sufixo do domínio de DNS: não é definido pelo operador durante a configuração
- Endereço IP do servidor NTP (Protocolo de Tempo de Rede) ou FQDN: 172.27.255.212
- Syslog primário: 172.27.255.210
- Syslog secundário: 172.27.255.211
- Endereço IP do gateway SMTP ou FQDN: não definido pela operadora durante a configuração
- Nome de domínio do remetente do email: nome de domínio do remetente do email (exemplo.com)
- Endereços de email a serem alertados: não definidos pelo operador durante a configuração
- Servidor proxy e porta: não definidos pelo operador durante a configuração
- Gerenciamento: interface virtual
  - Endereço IP: 172.27.255.200
  - Gateway: 172.27.255.1
  - Máscara de sub-rede: 255.255.255.0
  - MTU: 1500
  - Bond: não definido pelo operador durante a configuração
- Gerenciamento: controlador 0
  - Endereço IP: 172.27.255.254
  - Gateway: 172.27.255.1
  - Máscara de sub-rede: 255.255.255.0
  - MTU: 1500
  - Bond: não definido pelo operador durante a configuração
- Gerenciamento: controlador 1
  - Endereço IP: 172.27.255.253
  - Gateway: 172.27.255.1
  - Máscara de sub-rede: 255.255.255.0
  - MTU: 1500
  - Bond: não definido pelo operador durante a configuração
- Número/prefixo da VLAN: 43
- ct0.eth10: não definido pelo operador durante a configuração
- ct0.eth11: não definido pelo operador durante a configuração
- ct0.eth18: não definido pelo operador durante a configuração
- ct0.eth19: não definido pelo operador durante a configuração
- ct1.eth10: não definido pelo operador durante a configuração
- ct1.eth11: não definido pelo operador durante a configuração
- ct1.eth18: não definido pelo operador durante a configuração
- ct1.eth19: não definido pelo operador durante a configuração
- Pure Tunable a ser aplicado:
  - puretune -set PS_ENFORCE_IO_ORDERING 1 "PURE-209441";
  - puretune -set PS_STALE_IO_THRESH_SEC 4 "PURE-209441";
  - puretune -set PS_LANDLORD_QUORUM_LOSS_TIME_LIMIT_MS 0 "PURE-209441";
  - puretune -set PS_RDMA_STALE_OP_THRESH_MS 5000 "PURE-209441";
  - puretune -set PS_BDRV_REQ_MAXBUFS 128 "PURE-209441";

Atribuição de IP do iDRAC

Antes de implantar o Cluster Nexus, é melhor que o operador defina os IPs iDRAC, enquanto organiza os racks de hardware. Veja como mapear os servidores para IPs:

Atribua os IPs com base na posição de cada servidor no rack.
Use o quarto bloco /24 da sub-rede /19 alocada para Fabric.
Comece a atribuir os IPs do servidor inferior para cima em cada rack, começando com 0,11.
Continue atribuindo os IPs sequencialmente ao primeiro servidor na parte inferior do próximo rack.

Exemplo

Intervalo de malha: 10.1.0.0-10.1.31.255 – a sub-rede iDRAC no quarto bloco /24 é 10.1.3.0/24.

Rack	Servidor	IP do iDRAC
Rack 1	Trabalhador 1	10.1.3.11/24
Rack 1	Função de trabalho 2	10.1.3.12/24
Rack 1	Função de trabalho 3	10.1.3.13/24
Rack 1	Função de trabalho 4	10.1.3.14/24
Rack 1	Função de trabalho 5	10.1.3.15/24
Rack 1	Função de trabalho 6	10.1.3.16/24
Rack 1	Função de trabalho 7	10.1.3.17/24
Rack 1	Função de trabalho 8	10.1.3.18/24
Rack 1	Controlador 1	10.1.3.19/24
Rack 1	Controlador 2	10.1.3.20/24
Rack 2	Trabalhador 1	10.1.3.21/24
Rack 2	Função de trabalho 2	10.1.3.22/24
Rack 2	Função de trabalho 3	10.1.3.23/24
Rack 2	Função de trabalho 4	10.1.3.24/24
Rack 2	Função de trabalho 5	10.1.3.25/24
Rack 2	Função de trabalho 6	10.1.3.26/24
Rack 2	Função de trabalho 7	10.1.3.27/24
Rack 2	Função de trabalho 8	10.1.3.28/24
Rack 2	Controlador 1	10.1.3.29/24
Rack 2	Controlador 2	10.1.3.30/24
Rack 3	Trabalhador 1	10.1.3.31/24
Rack 3	Função de trabalho 2	10.1.3.32/24
Rack 3	Função de trabalho 3	10.1.3.33/24
Rack 3	Função de trabalho 4	10.1.3.34/24
Rack 3	Função de trabalho 5	10.1.3.35/24
Rack 3	Função de trabalho 6	10.1.3.36/24
Rack 3	Função de trabalho 7	10.1.3.37/24
Rack 3	Função de trabalho 8	10.1.3.38/24
Rack 3	Controlador 1	10.1.3.39/24
Rack 3	Controlador 2	10.1.3.40/24
Rack 4	Trabalhador 1	10.1.3.41/24
Rack 4	Função de trabalho 2	10.1.3.42/24
Rack 4	Função de trabalho 3	10.1.3.43/24
Rack 4	Função de trabalho 4	10.1.3.44/24
Rack 4	Função de trabalho 5	10.1.3.45/24
Rack 4	Função de trabalho 6	10.1.3.46/24
Rack 4	Função de trabalho 7	10.1.3.47/24
Rack 4	Função de trabalho 8	10.1.3.48/24
Rack 4	Controlador 1	10.1.3.49/24
Rack 4	Controlador 2	10.1.3.50/24

Um design de exemplo de três instâncias locais do mesmo par NFC/CM, usando redes sequenciais /19 em um /16:

Instância	Intervalo de Malha	Sub-rede do iDRAC
Instância 1	10.1.0.0-10.1.31.255	10.1.3.0/24
Instância 2	10.1.32.0-10.1.63.255	10.1.35.0/24
Instância 3	10.1.64.0-10.1.95.255	10.1.67.0/24

Configuração padrão para outros dispositivos instalados

Todos os dispositivos de malha de rede (exceto o Terminal Server) estão configurados para o modo ZTP
Os servidores têm configurações padrão de fábrica

Regras de firewall entre o Azure e o Cluster Nexus.

Para estabelecer as regras de firewall entre o Azure e o Cluster Nexus, o operador deve abrir as portas especificadas. Isso garante a comunicação e a conectividade adequadas para os serviços necessários usando os protocolos TCP e UDP.

N. de série	Origem	Destino	Porta (TCP/UDP)	Bidirecional	Objetivo da Regra
1	rede virtual do Azure	Cluster	22 TCP	Não	Para SSH para os servidores undercloud da sub-rede CM.
2	rede virtual do Azure	Cluster	443 TCP	Não	Para acessar os nós undercloud do iDRAC
3	rede virtual do Azure	Cluster	5900 TCP	Não	Gnmi
4	rede virtual do Azure	Cluster	6030 TCP	Não	Gnmi Certs
5	rede virtual do Azure	Cluster	6443 TCP	Não	Para acessar o cluster K8S undercloud
6	Cluster	rede virtual do Azure	8080 TCP	Yes	Para montar a imagem ISO no iDRAC, atualização de runtime do NNF
7	Cluster	rede virtual do Azure	3128 TCP	Não	Proxy para se conectar aos pontos de extremidade globais do Azure
8	Cluster	rede virtual do Azure	53 TCP e UDP	Não	DNS
9	Cluster	rede virtual do Azure	123 UDP	Não	NTP
10	Cluster	rede virtual do Azure	8888 TCP	Não	Conectando-se ao serviço Web do Gerenciador de Clusters
11	Cluster	rede virtual do Azure	514 TCP e UDP	Não	Para acessar logs undercloud no Gerenciador de Clusters

Instale a versão mais recente das extensões necessárias da CLI.

  az login
  az account set --subscription $SUBSCRIPTION_ID
  az account show

Observação

A conta deve ter permissões para ler/gravar/publicar na assinatura

Compartilhar via

Pré-requisitos da plataforma Operador Nexus

Pré-requisitos do Azure

Pré-requisitos no local

Configuração de hardware físico

Usando a lista de materiais (BOM)

Usando o diagrama de elevação

Diagrama de cabeamento

Como fazer pedidos com base no SKU

Definição de SKU

Fazendo um pedido baseado em SKU

Como fazer o build a pegada física do hardware

Pedido e recebimento do SKU específico da infraestrutura de hardware

Preparação do local

Agendamento de recursos

Suposições sobre o desenvolvimento de habilidades da equipe

Visão geral do processo de build

Como inspecionar visualmente a instalação física do hardware

Configuração do Terminal Server e da matriz de armazenamento

Configurar o servidor de terminal

Etapa 1: configuração do nome do host

Etapa 2: configuração da rede

Etapa 3: Limpeza da interface net3 (se existente)

Etapa 4: Configuração do usuário administrador de suporte

Etapa 5: Adição de suporte sudo para usuários administradores

Etapa 6: Garantia da disponibilidade do serviço LLDP

Etapa 7: Verificação da data/hora do sistema

Verificar a configuração do fuso horário:

Definir o fuso horário como UTC:

Verificar a data/hora atual:

Corrigir data/hora se estiverem incorretas:

Etapa 8: Rotulação das portas do Servidor de Terminal (se ausentes/incorretas)

Etapa 9: configurações necessárias para conexões seriais do PURE Array

Etapa 10: Verificação das configurações

Configurar uma matriz de armazenamento

Atribuição de IP do iDRAC

Exemplo

Configuração padrão para outros dispositivos instalados

Regras de firewall entre o Azure e o Cluster Nexus.

Instale extensões CLI e entre na sua assinatura do Azure

Entrada de assinatura do Azure

Comentários

Recursos adicionais