Pré-requisitos da plataforma Nexus do operador

Artigo
04/19/2024

Os operadores precisam completar os pré-requisitos antes da implantação do software da plataforma Operator Nexus. Algumas destas medidas podem demorar muito tempo, pelo que uma revisão destes pré-requisitos pode revelar-se benéfica.

Em implantações subsequentes de instâncias do Operator Nexus, você pode pular para a criação da malha de rede local e do cluster.

Pré-requisitos do Azure

Ao implantar o Operator Nexus pela primeira vez ou em uma nova região, você precisará primeiro criar um controlador de malha de rede e, em seguida, um gerenciador de cluster, conforme especificado aqui. Além disso, as seguintes tarefas precisam ser realizadas:

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

Pré-requisitos nas suas instalações

Ao implantar a instância local do Operator Nexus em seu datacenter, várias equipes provavelmente estão envolvidas no desempenho de várias 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

Um operador que deseja tirar proveito do serviço Operator Nexus precisa comprar, instalar, configurar e operar recursos de hardware. Esta seção do documento descreve os componentes e esforços necessários para comprar e implementar os sistemas de hardware apropriados. Esta seção discute a lista de materiais, o diagrama de elevações do rack e o diagrama de cabeamento, e as etapas necessárias para montar o hardware.

Usando a lista de materiais (BOM)

Para garantir uma experiência perfeita do operador, a Operator Nexus desenvolveu uma lista técnica para a aquisição de hardware necessária para o serviço. Esta lista técnica é 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 lista técnica está estruturada para fornecer ao operador uma série de unidades de manutenção de estoque (SKU) que podem ser encomendadas a fornecedores de hardware. SKUs é discutido mais adiante no documento.

Usando o diagrama de elevação

O diagrama de elevação de 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 construção. Ele ajudará a equipe de operadores a configurar e instalar corretamente todos os componentes de hardware necessários para a operação de serviço.

Diagrama de cabeamento

Os diagramas de cabeamento são representações gráficas das conexões de cabo 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 na construção.

Como encomendar com base em 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 encomende todos os componentes necessários especificando um número de SKU. O SKU agiliza a interação entre operador e fornecedor, reduzindo erros de pedidos devido a listas de peças complexas.

Fazer um pedido baseado em SKU

O operador Nexus criou uma série de SKUs com fornecedores como Dell, Pure Storage e Arista que o operador pode referenciar quando faz 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 construção.

Como criar a pegada de hardware físico

A compilação de hardware físico é executada através de uma série de etapas, que serão detalhadas nesta seção. Há três etapas de pré-requisito antes da execução da compilação. Esta seção também discutirá as suposições relativas às habilidades dos funcionários do operador para executar a compilação.

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

A encomenda do SKU apropriado e a entrega do hardware no site devem ocorrer antes do início da construção. Deve ser concedido tempo suficiente para esta etapa. Recomendamos que o operador se comunique com o fornecedor do hardware no início do processo para garantir e entender os prazos de entrega.

Preparação do local

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

Agendamento de recursos

O processo de construção requer vários membros diferentes da equipe para executar a construção, 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 compilação seja realizada em tempo hábil, recomendamos agendar esses membros da equipe com antecedência com base no cronograma de entrega.

Pressupostos sobre o desenvolvimento de competências do pessoal

A equipe que executa a compilação 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, enquanto fazem referência a elevações de rack e diagramas de cabeamento.

Visão geral do processo de compilação

Se a preparação do site estiver completa e validada para suportar a SKU ordenada, o processo de compilação ocorrerá nas seguintes etapas:

Monte os racks com base nas elevações de rack do SKU. Instruções específicas de montagem do rack serão fornecidas pelo fabricante do rack.
Depois que os racks forem montados, instale os dispositivos de tecido nos racks de acordo com o diagrama de elevação.
Conecte os dispositivos de malha conectando as interfaces de rede de acordo com o diagrama de cabeamento.
Monte e instale os servidores por diagrama de elevação de rack.
Monte e instale o dispositivo de armazenamento por diagrama de elevação de rack.
Conecte o servidor e os dispositivos de armazenamento conectando as interfaces de rede de acordo com o diagrama de cabeamento.
Alimentação do cabo de cada dispositivo.
Revise/valide a compilação através das listas de verificação fornecidas pelo Operator Nexus e outros fornecedores.

Como inspecionar visualmente a instalação de hardware físico

Recomenda-se etiquetar em todos os cabos seguindo os padrões ANSI/TIA 606, ou os padrões do operador, durante o processo de construção. O processo de compilação também deve criar mapeamento reverso para cabeamento de uma porta de switch para conexão de extremidade. 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 configuração das configurações padrão necessárias antes da instalação do software da plataforma.

Configurar o Terminal Server

O Terminal Server foi implantado e configurado da seguinte maneira:

O Terminal Server está configurado para gerenciamento fora da 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 PEs (Provider Edge Routers) locais dos operadores e configurada com os endereços IP e credenciais
O Terminal Server pode ser acessado a partir da VPN de gerenciamento

Etapa 1: Configurando o nome do host

Para configurar o nome do host para o servidor de terminal, execute estas etapas:

Use o seguinte comando na CLI:

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

Parâmetros:

Nome do Parâmetro	Description
TS_HOSTNAME	Nome do host do servidor de terminal

Consulte Referência da CLI para obter mais detalhes.

Etapa 2: Configurando a rede

Para definir as definições de rede, siga estes passos:

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	Description
TS_NET1_IP	Terminal server PE1 para TS NET1 IP
TS_NET1_NETMASK	Máscara de rede do servidor de terminal PE1 para TS NET1
TS_NET1_GW	Servidor de terminal PE1 para gateway TS NET1
TS_NET2_IP	Terminal server PE2 para TS NET2 IP
TS_NET2_NETMASK	Servidor de terminal PE2 para máscara de rede TS NET2
TS_NET2_GW	Servidor de terminal PE2 para gateway TS NET2

Nota

Certifique-se de substituir esses parâmetros por valores apropriados.

Etapa 3: Limpar a interface net3 (se existir)

Para limpar a interface net3, siga estes passos:

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

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

Parâmetros:

Nome do Parâmetro	Description
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"

Nota

Certifique-se de substituir esses parâmetros por valores apropriados.

Etapa 4: Configurando o usuário administrador de suporte

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

Para cada usuário, execute o seguinte comando 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	Description
SUPPORT_USER	Usuário administrador de suporte
HASHED_SUPPORT_PWD	Senha de usuário admin de suporte codificado

Nota

Certifique-se de substituir esses parâmetros por valores apropriados.

Etapa 5: Adicionando 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

Adicione as seguintes linhas para conceder acesso sudo:

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

Nota

Certifique-se de salvar as alterações depois de editar o arquivo.

Esta configuração permite que os membros do grupo "netgrp" executem qualquer comando como qualquer usuário e os membros do grupo "admin" executem qualquer comando como qualquer usuário sem exigir uma senha.

Etapa 6: Garantir a disponibilidade do serviço LLDP

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

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

sudo systemctl status lldpd

Você 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 iniciar na reinicialização:

sudo systemctl enable lldpd

Nota

Certifique-se de executar estas etapas para garantir que o serviço LLDP esteja sempre disponível e seja iniciado automaticamente após a reinicialização.

Passo 7: Verificar a data/hora do sistema

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

Verifique a configuração de fuso horário:

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

ogcli get system/timezone

Defina o fuso horário como UTC:

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

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

Verifique a data/hora atual:

Verifique a data e hora atuais:

date

Corrigir data/hora se estiver incorreto:

Se a data/hora estiver incorreta, você pode corrigi-la 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	Description
CURRENT_DATE_TIME	Data atual hora no formato hh:mm MMM DD, AAAA

Nota

Certifique-se de que a data/hora do sistema é precisa para evitar quaisquer problemas com aplicativos ou serviços que dependem dele.

Etapa 8: Rotulando portas do Terminal Server (se ausente/incorretas)

Para rotular portas do Terminal Server, use o seguinte comando:

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

Parâmetros:

Nome do Parâmetro	Description
NEW_NAME	Nome da etiqueta da porta
PORT_ #	Número da porta do Terminal Server

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

Os arrays Pure Storage adquiridos antes de 2024 têm controladores R3 de revisão que usam cabos de console de rolagem e exigem os comandos personalizados de conexão de porta serial abaixo:

Controladores Pure Stoarge R3:

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 Pure Storage mais recentes e os sistemas atualizados dos controladores R3 para R4 Pure Storage usarão cabos de console diretos com as configurações atualizadas abaixo:

Controladores Pure Storage R4:

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	Description
PORT_ #	Número da porta do Terminal Server

Esses comandos definem a taxa de transmissão e a pinagem para conexão com o console do Pure Storage Controller.

Nota

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

Etapa 10: Verificando as configurações

Para verificar as definições de configuração, execute os seguintes comandos:

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

Nota

Certifique-se de que os vizinhos 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
-------------------------------------------------------------------------------

Nota

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

Configurar matriz de armazenamento

O operador precisa instalar o hardware do storage array conforme especificado pela lista técnica e a elevação do rack dentro do rack de agregação.
O operador precisa fornecer informações ao técnico do storage array para que o técnico do storage array chegue ao local para configurar o aparelho.
Dados específicos do local necessários que são compartilhados com o técnico do storage array:
- Nome do Cliente:
- Data da Inspeção Física:
- Número de série do chassis:
- Nome do host da matriz de armazenamento:
- Código CLLI (Common Language Location Identifier):
- Endereço de instalação:
- Localização FIC/Rack/Grid:
Dados fornecidos ao operador e partilhados com o técnico do storage array, que serão comuns a todas as instalações:
- Nível de código de pureza: Consulte as versões de pureza suportadas
- Modo de Segurança: Desativado
- Fuso horário da matriz: UTC
- Endereço IP do servidor DNS (Sistema de Nomes de Domínio): 172.27.255.201
- Sufixo de domínio DNS: não definido pelo operador durante a configuração
- Endereço IP do servidor NTP (Network Time Protocol) ou FQDN: 172.27.255.212
- Syslog Primário: 172.27.255.210
- Syslog Secundário: 172.27.255.211
- Endereço IP ou FQDN do Gateway SMTP: não definido pelo operador durante a configuração
- Nome de domínio do remetente do e-mail: nome de domínio do remetente do e-mail (example.com)
- Endereços de e-mail a serem alertados: não definidos pelo operador durante a configuração
- Servidor proxy e porta: não definido pelo operador durante a configuração
- Gestão: Interface Virtual
  - Endereço IP: 172.27.255.200
  - Porta de entrada: 172.27.255.1
  - Máscara de sub-rede: 255.255.255.0
  - MTU: 1500
  - Ligação: não definida pelo operador durante a configuração
- Gestão: Controller 0
  - Endereço IP: 172.27.255.254
  - Porta de entrada: 172.27.255.1
  - Máscara de sub-rede: 255.255.255.0
  - MTU: 1500
  - Ligação: não definida pelo operador durante a configuração
- Gestão: Controller 1
  - Endereço IP: 172.27.255.253
  - Porta de entrada: 172.27.255.1
  - Máscara de sub-rede: 255.255.255.0
  - MTU: 1500
  - Ligação: não definida pelo operador durante a configuração
- Número de VLAN / Prefixo: 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
- Puro ajustável 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 iDRAC

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

Atribua IPs com base na posição de cada servidor dentro do rack.
Use o quarto bloco /24 da sub-rede /19 alocado para Fabric.
Comece a atribuir IPs do servidor inferior para cima em cada rack, começando com 0.11.
Continue a atribuir IPs em sequência ao primeiro servidor na parte inferior do próximo rack.

Exemplo

Intervalo de tecido: 10.1.0.0-10.1.31.255 – sub-rede iDRAC na quarta /24 é 10.1.3.0/24.

Rack	Servidor	IP iDRAC
Rack 1	Trabalhador 1	10.1.3.11/24
Rack 1	Trabalhador 2	10.1.3.12/24
Rack 1	Trabalhador 3	10.1.3.13/24
Rack 1	Trabalhador 4	10.1.3.14/24
Rack 1	Trabalhador 5	10.1.3.15/24
Rack 1	Trabalhador 6	10.1.3.16/24
Rack 1	Trabalhador 7	10.1.3.17/24
Rack 1	Trabalhador 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	Trabalhador 2	10.1.3.22/24
Rack 2	Trabalhador 3	10.1.3.23/24
Rack 2	Trabalhador 4	10.1.3.24/24
Rack 2	Trabalhador 5	10.1.3.25/24
Rack 2	Trabalhador 6	10.1.3.26/24
Rack 2	Trabalhador 7	10.1.3.27/24
Rack 2	Trabalhador 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	Trabalhador 2	10.1.3.32/24
Rack 3	Trabalhador 3	10.1.3.33/24
Rack 3	Trabalhador 4	10.1.3.34/24
Rack 3	Trabalhador 5	10.1.3.35/24
Rack 3	Trabalhador 6	10.1.3.36/24
Rack 3	Trabalhador 7	10.1.3.37/24
Rack 3	Trabalhador 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	Trabalhador 2	10.1.3.42/24
Rack 4	Trabalhador 3	10.1.3.43/24
Rack 4	Trabalhador 4	10.1.3.44/24
Rack 4	Trabalhador 5	10.1.3.45/24
Rack 4	Trabalhador 6	10.1.3.46/24
Rack 4	Trabalhador 7	10.1.3.47/24
Rack 4	Trabalhador 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 exemplo de design de três instâncias locais do mesmo par NFC/CM, usando redes sequenciais /19 em um /16:

Instância	Gama de Tecidos	Sub-rede 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) são definidos para ZTP o modo
Os servidores têm configurações de fábrica padrão

Regras de firewall entre o Azure e o Nexus Cluster.

Para estabelecer regras de firewall entre o Azure e o Nexus Cluster, o operador deve abrir as portas especificadas. Isso garante comunicação e conectividade adequadas para os serviços necessários usando TCP (Transmission Control Protocol) e UDP (User Datagram Protocol).

N.º S.	Origem	Destino	Porta (TCP/UDP)	Bidirecional	Finalidade da regra
1	Rede virtual do Azure	Cluster	22 TCP	Não	Para SSH para servidores undercloud da sub-rede CM.
2	Rede virtual do Azure	Cluster	443 TCP	Não	Para acessar nós sob a nuvem iDRAC
3	Rede virtual do Azure	Cluster	5900 TCP	Não	Gnmi
4	Rede virtual do Azure	Cluster	6030 TCP	Não	Certificados Gnmi
5	Rede virtual do Azure	Cluster	6443 TCP	Não	Para acessar o cluster K8S sob a nuvem
6	Cluster	Rede virtual do Azure	TCP 8080	Sim	Para montagem de imagem ISO no iDRAC, atualização de tempo de execução NNF
7	Cluster	Rede virtual do Azure	3128 TCP	Não	Proxy para se conectar a 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	TCP 8888	Não	Conectando-se ao serviço Web do Gerenciador de Cluster
11	Cluster	Rede virtual do Azure	514 TCP e UDP	Não	Para acessar logs abaixo da nuvem a partir do Gerenciador de Cluster

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

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

Nota

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

Partilhar via

Pré-requisitos da plataforma Nexus do operador

Pré-requisitos do Azure

Pré-requisitos nas suas instalações

Configuração de hardware físico

Usando a lista de materiais (BOM)

Usando o diagrama de elevação

Diagrama de cabeamento

Como encomendar com base em SKU

Definição de SKU

Fazer um pedido baseado em SKU

Como criar a pegada de hardware físico

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

Preparação do local

Agendamento de recursos

Pressupostos sobre o desenvolvimento de competências do pessoal

Visão geral do processo de compilação

Como inspecionar visualmente a instalação de hardware físico

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

Configurar o Terminal Server

Etapa 1: Configurando o nome do host

Etapa 2: Configurando a rede

Etapa 3: Limpar a interface net3 (se existir)

Etapa 4: Configurando o usuário administrador de suporte

Etapa 5: Adicionando suporte sudo para usuários administradores

Etapa 6: Garantir a disponibilidade do serviço LLDP

Passo 7: Verificar a data/hora do sistema

Verifique a configuração de fuso horário:

Defina o fuso horário como UTC:

Verifique a data/hora atual:

Corrigir data/hora se estiver incorreto:

Etapa 8: Rotulando portas do Terminal Server (se ausente/incorretas)

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

Etapa 10: Verificando as configurações

Configurar matriz de armazenamento

Atribuição de IP iDRAC

Exemplo

Configuração padrão para outros dispositivos instalados

Regras de firewall entre o Azure e o Nexus Cluster.

Instalar extensões de CLI e iniciar sessão na sua subscrição do Azure

Início de sessão da subscrição do Azure

Comentários

Recursos adicionais