Partilhar via


Pré-requisitos da plataforma Nexus do operador

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 Nexus do Operador 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 na página Pré-requisitos do Nexo do Operador do Azure . 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 na página do Defender for Cloud Security .

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 BOM é uma lista abrangente dos componentes e quantidades necessárias para implementar o ambiente necessário para uma implantação e manutenção bem-sucedidas da instância on-premises local. A BOM está estruturada para fornecer ao operador uma série de unidades de manutenção de estoque (SKU) que podem ser ordenadas a fornecedores de equipamento. 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. Antes do processo de build, existem três etapas de pré-requisito. Esta seção também discutirá as suposições relativas às habilidades dos funcionários do operador para executar o desenvolvimento.

Encomenda e recebimento do SKU da infraestrutura específica de hardware

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 construção seja realizada em tempo hábil, recomendamos o agendamento dos membros da equipa com antecedência de acordo com o 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:

  1. 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.
  2. Depois que os racks forem montados, instale os dispositivos de tecido nos racks de acordo com o diagrama de elevação.
  3. Conecte os dispositivos de rede, ligando as interfaces de rede conforme o diagrama de cabeamento.
  4. Monte e instale os servidores de acordo com o diagrama de disposição dos racks.
  5. Monte e instale o dispositivo de armazenamento conforme o diagrama de elevação de rack.
  6. Conecte o servidor e os dispositivos de armazenamento conectando as interfaces de rede de acordo com o diagrama de cabeamento.
  7. Cabo de alimentação de cada dispositivo.
  8. 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 todos os cabos seguindo os padrões ANSI/TIA 606, ou os padrões do operador, durante o processo de montagem. O processo de compilação também deve criar um mapeamento reverso para o cabeamento a partir de uma porta de 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 configuração das configurações padrão necessárias antes da instalação do software da plataforma.

Configurar o Terminal Server

Observação

Este guia foi validado com o firmware Opengear versão 24.11.2, que foi atualizado da versão 22.06.0 e é suportado com o tempo de execução do Nexus Network Fabric versão 5.0.0.

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
  • Para atualizar o servidor de terminal para a versão 24.11.2 do SO, consulte
  • Para configurar uma única sessão e o tempo limite da sessão para o console serial , consulte:

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

Observação

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:

  1. 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
  1. Remova a interface se ela existir:
ogcli delete conn "<TS_NET3_CONN_NAME>"

Observação

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:

  1. 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"
password="<SUPPORT_PWD>"
username="<SUPPORT_USER>"
END

Parâmetros:

Nome do parâmetro Description
SUPPORT_USER Usuário administrador de suporte
SUPPORT_PWD Senha do utilizador administrador

Observação

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:

  1. Abra o arquivo de configuração do sudoers:
sudo vi /etc/sudoers.d/opengear
  1. Adicione as seguintes linhas para conceder acesso sudo:
%netgrp ALL=(ALL) ALL
%admin ALL=(ALL) NOPASSWD: ALL

Observação

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

Observação

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 e hora atual no formato hh:mm MMM DD, AAAA

Observação

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

Etapa 8: Etiquetar as portas do Terminal Server (se estiverem em falta ou 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 de revisão R3 que usam cabos de consola rollover e exigem os comandos personalizados de conexão de porta série abaixo:

Controladores Pure Storage 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.

Observação

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

Observação

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
-------------------------------------------------------------------------------

Observação

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

Determinar se o Modo de Segurança deve ser ativado em storage arrays

Os arrays Pure Storage suportam um recurso chamado SafeMode, que é projetado para proteger contra ataques de ransomware e outras atividades maliciosas. Quando habilitado, instantâneos de volumes são criados periodicamente que não podem ser totalmente excluídos ou modificados por um período de retenção configurável. A ativação do SafeMode fornece proteção contra perda de dados, mas também usa mais capacidade de armazenamento no array.

A plataforma Operator Nexus suporta o SafeMode ativado em matrizes de armazenamento. Os volumes estão sujeitos à sua proteção, desde que os Grupos de Proteção padrão incluam pelo menos um com o Modo de Segurança ativado. No entanto, ele não interage diretamente com os snapshots gerados, e você precisa trabalhar com seu representante de suporte Pure se precisar recuperar dados de um snapshot.

Por padrão, o SafeMode é ativado em matrizes Pure Storage por meio de um Grupo de Proteção padrão. Se desejar desativá-lo, você pode fazê-lo excluindo este Grupo de Proteção padrão. Se deseja ativar o SafeMode com diferentes configurações de frequência e retenção de instantâneos, podes substituí-las por um novo Grupo de Proteção ativado com SafeMode com as configurações desejadas.

Para obter mais informações sobre o SafeMode e suas implicações, consulte a documentação do Pure Storage (é necessário entrar). Entre em contato com seu representante de suporte Pure para mais perguntas sobre o SafeMode e sua configuração.

Configurar a primeira matriz de armazenamento

  1. O operador precisa instalar o hardware do array de armazenamento conforme especificado pelo BOM e pela altura do rack dentro do rack de agregação.
  2. O operador deve fornecer informações ao técnico responsável pelo sistema de armazenamento, de modo que ele possa chegar ao local para configurar o dispositivo.
  3. Dados específicos da localização necessários a serem partilhados com o técnico da matriz de armazenamento.
    • 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:
  4. 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: Consulte Determinar se o Modo de Segurança deve ser ativado em matrizes de armazenamento
    • Fuso horário da matriz: UTC
    • Endereço IP do servidor DNS (Domain Name System): não definido pelo operador durante a configuração
    • 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: não definido pelo operador durante a configuração
    • Syslog Primary: não definido pelo operador durante a configuração
    • Syslog Secundário: não definido pelo operador durante a configuração
    • 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
      • Gateway: não definido pelo operador durante a configuração
      • 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
      • Gateway: não definido pelo operador durante a configuração
      • 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
      • Gateway: não definido pelo operador durante a configuração
      • Máscara de sub-rede: 255.255.255.0
      • MTU: 1500
      • Ligação: não definida pelo operador durante a configuração
    • 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";

(Opcional) Configurar o segundo array de armazenamento

Observação

Esta secção é opcional. Você só precisará executá-lo se estiver implantando uma instância do Azure Operator Nexus com dois dispositivos de armazenamento. Para obter mais informações, incluindo restrições de hardware suportado, consulte Azure Operator Nexus multiple storage appliances.

  1. O operador precisa instalar o hardware do array de armazenamento conforme especificado pelo BOM e pela altura do rack dentro do rack de agregação.
  2. O operador deve fornecer informações ao técnico responsável pelo sistema de armazenamento, de modo que ele possa chegar ao local para configurar o dispositivo.
  3. Dados específicos da localização necessários a serem partilhados com o técnico da matriz de armazenamento.
    • 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:
  4. 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: Consulte Determinar se o Modo de Segurança deve ser ativado em matrizes de armazenamento
    • Fuso horário da matriz: UTC
    • Endereço IP do servidor DNS (Domain Name System): não definido pelo operador durante a configuração
    • 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: não definido pelo operador durante a configuração
    • Syslog Primary: não definido pelo operador durante a configuração
    • Syslog Secundário: não definido pelo operador durante a configuração
    • 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.201
      • Gateway: não definido pelo operador durante a configuração
      • 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.251
      • Gateway: não definido pelo operador durante a configuração
      • 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.252
      • Gateway: não definido pelo operador durante a configuração
      • Máscara de sub-rede: 255.255.255.0
      • MTU: 1500
      • Ligação: não definida pelo operador durante a configuração
    • 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 do 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.

Example

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

Rack Server 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 no modo ZTP
  • Os servidores têm configurações de fábrica padrão, incluindo configurações mínimas do BIOS.

Como prática recomendada, as seguintes versões de BIOS e firmware precisam ser instaladas nos servidores antes da implantação, com base na versão de tempo de execução selecionada e na BOM. Para referência, a versão N é a versão de tempo de execução mais recente disponível. N-1 e N-2 são as versões de tempo de execução suportadas anteriormente.

Observação

As versões do iDRAC anteriores à 7.20.30.50 tinham limitações conhecidas com suporte a downgrade de firmware. Como resultado, se um sistema alvo estivesse a correr firmware mais recente em qualquer componente (BIOS, PERC, Broadcom, Mellanox, CPLD), o iDRAC não assinalaria a incompatibilidade e saltaria o downgrade. Este comportamento foi corrigido a partir do iDRAC 7.20.30.50. Embora as versões mais recentes do iDRAC façam um esforço máximo para tentar alinhar o firmware dos componentes com o catálogo para o tempo de execução especificado, certos cenários de downgrade podem provocar retrocessos de atributos que podem levar à corrupção do BIOS, conforme documentado pela Dell. Por esta razão, a prática recomendada é garantir que todas as versões de firmware dos componentes sejam iguais ou inferiores às versões listadas para a versão de execução correspondente.

Versão do ambiente de execução do Nexus Cluster N

BOM 1.7.3
Componente Versão
BIOS 1.18.1
Controlador de Storage Array (PERC H755) 52.30.0-6115
iDRAC 7.20.30.55
Firmware SEP passivo do backplane de armazenamento sem expansor (15G sem expansor) 7.10
CPLD (Dispositivo Lógico Programável Complexo) 1.1.1
Adaptador Mellanox ConnectX-6 DX 22.47.10.88
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Adaptador de BASE-T Broadcom 5720 Quad Port 1GbE 23.21.6
BOM 2.0.0
Componente Versão
BIOS 2.7.5
Controlador de Storage Array (PERC H755) 52.30.0-6115
iDRAC 7.20.30.55
Firmware do backplane do expansor SAS (R760) 1.61
Firmware do backplane de armazenamento não expansor (R660) 7.10
CPLD (Dispositivo Lógico Programável Complexo) 1.2.6
Adaptador Mellanox ConnectX-6 DX 22.47.10.88
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Adaptador de BASE-T Broadcom 5720 Quad Port 1GbE 23.21.6

Versão de runtime do Nexus Cluster N-1

BOM 1.7.3
Componente Versão
BIOS 1.17.2
Controlador de Storage Array (PERC H755) 52.26.0-5179
iDRAC 7.20.30.00
Firmware SEP passivo do backplane de armazenamento sem expansor (15G sem expansor) 7.10
CPLD (Dispositivo Lógico Programável Complexo) 1.1.1
Adaptador Mellanox ConnectX-6 DX 22.47.10.88
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Adaptador de BASE-T Broadcom 5720 Quad Port 1GbE 23.21.6
BOM 2.0.0
Componente Versão
BIOS 2.6.3
Controlador de Storage Array (PERC H755) 52.26.0-5179
iDRAC 7.20.30.00
Firmware do backplane do expansor SAS (R760) 1.61
Firmware do backplane de armazenamento não expansor (R660) 7.10
CPLD (Dispositivo Lógico Programável Complexo) 1.2.6
Adaptador Mellanox ConnectX-6 DX 22.47.10.88
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Adaptador de BASE-T Broadcom 5720 Quad Port 1GbE 23.21.6

Versão em execução do Nexus Cluster N-2

BOM 1.7.3
Componente Versão
BIOS 1.15.2
Controlador de Storage Array (PERC H755) 52.26.0-5179
iDRAC 7.10.90.00
Firmware SEP passivo do backplane de armazenamento sem expansor (15G sem expansor) 7.10
CPLD (Dispositivo Lógico Programável Complexo) 1.1.1
Adaptador Mellanox ConnectX-6 DX 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Adaptador de BASE-T Broadcom 5720 Quad Port 1GbE 22.91.5
BOM 2.0.0
Componente Versão
BIOS 2.4.4
Controlador de Storage Array (PERC H755) 52.26.0-5179
iDRAC 7.10.90.00
Firmware do backplane do expansor SAS (R760) 1.61
Firmware do backplane de armazenamento não expansor (R660) 7.10
CPLD (Dispositivo Lógico Programável Complexo) 1.2.6
Adaptador Mellanox ConnectX-6 DX 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Adaptador de BASE-T Broadcom 5720 Quad Port 1GbE 22.91.5

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).

S.No Fonte Destino Porta (TCP/UDP) Bidirecional Finalidade da regra
1 Rede virtual do Azure Cluster 22 TCP Não Para efetuar o SSH para os servidores undercloud da sub-rede CM
2 Rede virtual do Azure Cluster 443 TCP Não Para aceder aos nós subnuvem 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 Yes Para montar uma imagem ISO no iDRAC, é necessário atualizar o runtime 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 aceder aos logs do Undercloud a partir do Gestor de Cluster

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

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

Iniciar sessão na subscrição do Azure

  az login
  az account set --subscription <SUBSCRIPTION_ID>
  az account show

Observação

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