Compartir a través de


Requisitos previos de la plataforma Nexus del operador

Los operadores deben completar los requisitos previos antes de implementar el software de la plataforma Operator Nexus. Algunos de estos pasos pueden tardar mucho tiempo, por lo que una revisión de estos requisitos previos puede resultar beneficioso.

En implementaciones posteriores de instancias de Operator Nexus, puede pasar directamente a crear el Fabric de Red en local y el Clúster.

Requisitos previos de Azure

Al implementar Operator Nexus por primera vez o en una nueva región, primero deberá crear un Controlador de Red Fabric y luego un Administrador de Clústeres, como se especifica en la página Requisitos previos para Azure Operator Nexus. Además, es necesario realizar las siguientes tareas:

  • Configuración de usuarios, directivas, permisos y RBAC
  • Configure grupos de recursos para colocar y agrupar recursos de una manera lógica que se creará para la plataforma Operator Nexus.
  • Establecimiento de la conectividad de ExpressRoute desde la WAN a una región de Azure
  • Para habilitar Microsoft Defender para Endpoint en máquinas bare metal (BMM) locales, debe haber seleccionado un plan de Defender para servidores en la suscripción de Operator Nexus antes de la implementación. Información adicional disponible en la página Defender for Cloud Security .

Requisitos previos en sus instalaciones

Al implementar la instancia local de Operator Nexus en el centro de datos, es probable que varios equipos realicen varios roles. Las siguientes tareas deben realizarse con precisión para garantizar una correcta instalación de software de plataforma.

Configuración de hardware físico

Un operador que desee aprovechar las ventajas del servicio Operator Nexus debe comprar, instalar, configurar y operar recursos de hardware. En esta sección del documento se describen los componentes y esfuerzos necesarios para comprar e implementar los sistemas de hardware adecuados. En esta sección se describe la lista de materiales, el diagrama de elevaciones del bastidor y el diagrama de cableado, y los pasos necesarios para ensamblar el hardware.

Uso de la lista de materiales (BOM)

Para garantizar una experiencia fluida para el operador, Operator Nexus ha desarrollado una BOM (lista de materiales) para la adquisición de hardware necesaria para el servicio. Esta lista de materiales es un compendio completo de los componentes y cantidades necesarios para establecer el entorno adecuado para la correcta implementación y mantenimiento de la instancia local. La lista de materiales (BOM) está estructurada para proporcionar al operador una serie de unidades de mantenimiento de existencias (SKU) que pueden ser pedidas a proveedores de hardware. Las SKU se describen más adelante en el documento.

Uso del diagrama de elevación

El diagrama de elevación del bastidor es una referencia gráfica que muestra cómo encajan los servidores y otros componentes en los bastidores ensamblados y configurados. El diagrama de elevación del bastidor se proporciona como parte de las instrucciones generales de construcción. Ayudará al personal de los operadores a configurar e instalar correctamente todos los componentes de hardware necesarios para la operación del servicio.

Diagrama de cableado

Los diagramas de cableado son representaciones gráficas de las conexiones de cable necesarias para proporcionar servicios de red a los componentes instalados dentro de los bastidores. Si sigue el diagrama de cableado, se garantiza la implementación adecuada de los distintos componentes de la compilación.

Cómo ordenar en función de la SKU

Definición de SKU

Una SKU es un método de seguimiento y administración de inventario que permite agrupar varios componentes en un único designador. Una SKU permite a un operador ordenar todos los componentes necesarios con mediante la especificación de un número de SKU. La SKU acelera la interacción del operador y del proveedor al tiempo que reduce los errores de ordenación debido a listas de partes complejas.

Realizar un pedido basado en SKU

Operator Nexus ha creado una serie de SKU con proveedores como Dell, Pure Storage y Arista a los que el operador puede hacer referencia cuando realizan un pedido. Por lo tanto, un operador simplemente necesita realizar un pedido en función de la información de SKU proporcionada por Operator Nexus al proveedor para recibir la lista de piezas correcta para el ensamblaje.

Cómo construir la huella de hardware físico

La compilación de hardware físico se ejecuta a través de una serie de pasos, que se detallarán en esta sección. Hay tres pasos prerrequisitos antes de la ejecución de la construcción. En esta sección también se describen las suposiciones relativas a las aptitudes de los empleados del operador para ejecutar el desarrollo.

Ordenación y recepción de la SKU de infraestructura de hardware específica

El pedido de la SKU adecuada y la entrega de hardware al sitio deben producirse antes del inicio de la construcción. Se debe permitir un tiempo adecuado para este paso. Se recomienda que el operador se comunique con el proveedor del hardware al principio del proceso para garantizar y comprender los períodos de tiempo de entrega.

Preparación del sitio

El sitio de instalación puede soportar la infraestructura de hardware en términos de espacio, energía eléctrica y red. La SKU comprada para el sitio definirá los requisitos de sitio específicos. Este paso se puede realizar después de realizar el pedido y antes de la recepción de la SKU.

Programación de recursos

El proceso de compilación requiere que varios miembros del personal diferentes realicen la compilación, como ingenieros para proporcionar energía, acceso a la red y cableado, personal de sistemas para ensamblar los bastidores, conmutadores y servidores, por nombrar algunos. Para asegurarse de que la compilación se realiza de forma oportuna, se recomienda programar con antelación a estos miembros del equipo en función de la programación de entrega.

Suposiciones sobre las aptitudes del personal de desarrollo

El personal que realiza la instalación debe tener experiencia en el montaje de hardware de sistemas como bastidores, conmutadores, PDUs y servidores. En las instrucciones proporcionadas se describen los pasos del proceso, al tiempo que se hace referencia a elevaciones de bastidor y diagramas de cableado.

Descripción general del proceso de construcción

Si la preparación del sitio está completa y validada para admitir la SKU ordenada, el proceso de compilación se produce en los pasos siguientes:

  1. Ensamblar los bastidores en función de las elevaciones del bastidor de la SKU. El fabricante del bastidor proporcionará instrucciones de montaje de bastidor específicas.
  2. Después de ensamblar los bastidores, instale los dispositivos de tejido en los bastidores según el diagrama de elevación.
  3. Conecte los dispositivos de red conectando las interfaces de red según el diagrama de cableado.
  4. Ensamblar e instalar los servidores según el diagrama de elevación del bastidor.
  5. Ensamble e instale el dispositivo de almacenamiento según el diagrama de elevación del bastidor.
  6. Conecte los dispositivos de servidor y almacenamiento mediante la conexión de las interfaces de red según el diagrama de cableado.
  7. Alimentación por cable de cada dispositivo.
  8. Revise o valide la compilación a través de las listas de comprobación proporcionadas por Operator Nexus y otros proveedores.

Inspección visual de la instalación de hardware físico

Se recomienda etiquetar todos los cables siguiendo los estándares ANSI/TIA 606, o los estándares del operador, durante el proceso de construcción. El proceso de compilación también debe crear una asignación inversa para el cableado desde un puerto de conmutador a una conexión de extremo lejano. El mapeo inverso se puede comparar con el diagrama de cableado para verificar la instalación.

Configuración del Servidor de Terminal y de la matriz de almacenamiento

Ahora que se ha completado la instalación física y la validación, los pasos siguientes implican configurar la configuración predeterminada necesaria antes de la instalación de software de plataforma.

Configuración de Terminal Server

Nota:

Esta guía se ha validado con la versión 24.11.2 del firmware de Opengear, que se actualizó desde la versión 22.06.0 y se admite con nexus Network Fabric runtime versión 5.0.0.

Terminal Server se ha implementado y configurado de la siguiente manera:

  • Terminal Server está configurado para la administración fuera de banda
    • Se han configurado las credenciales de autenticación
    • El cliente DHCP está habilitado en el puerto de administración fuera de banda
    • El acceso HTTP está habilitado
  • La interfaz de Terminal Server está conectada a los enrutadores perimetrales locales del proveedor (PE) de los operadores, y configurada con las direcciones IP y las credenciales.
  • Terminal Server es accesible desde la VPN de administración
  • Para actualizar el servidor de terminal a la versión 24.11.2 del sistema operativo , consulte
  • Para configurar la sesión única y el tiempo de espera de sesión para la consola serie , consulte

Paso 1: Configuración del nombre de host

Para configurar el nombre de host para el servidor de terminal, siga estos pasos:

Use el siguiente comando en la CLI:

sudo ogcli update system/hostname hostname=\"<TS_HOSTNAME>\"

Parámetros:

Nombre de parámetro Description
TS_HOSTNAME Nombre de host del servidor de terminal

Consulte la referencia CLI para obtener más detalles.

Paso 2: Configuración de la red

Para configurar las opciones de red, siga estos pasos:

Ejecute los siguientes comandos en la 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:

Nombre de parámetro Description
TS_NET1_IP Terminal Server PE1 con TS NET1 IP
TS_NET1_NETMASK Máscara de red de Terminal Server PE1 a TS NET1
TS_NET1_GW Terminal Server PE1 a la puerta de enlace de TS NET1
TS_NET2_IP Terminal Server PE2 a la dirección IP de TS NET2
TS_NET2_NETMASK Máscara de red pe2 de Terminal Server a TS NET2
TS_NET2_GW Terminal Server PE2 a la puerta de enlace de TS NET2

Nota:

Asegúrese de reemplazar estos parámetros por los valores adecuados.

Paso 3: Borrar la interfaz net3 (si existe)

Para borrar la interfaz net3, siga estos pasos:

  1. Compruebe si hay alguna interfaz configurada en la interfaz física net3 y "Dirección estática IPv4 predeterminada" con el comando siguiente:
ogcli get conns
  description="Default IPv4 Static Address"
  name="<TS_NET3_CONN_NAME>"
  physif="net3"

Parámetros:

Nombre de parámetro Description
TS_NET3_CONN_NAME Nombre de la conexión del Terminal Server NET3
  1. Elimine la interfaz si existe.
ogcli delete conn "<TS_NET3_CONN_NAME>"

Nota:

Asegúrese de reemplazar estos parámetros por los valores adecuados.

Paso 4: Configuración del usuario administrador de soporte técnico

Para configurar el usuario administrador de soporte técnico, siga estos pasos:

  1. Para cada usuario, ejecute el siguiente comando en la 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:

Nombre de parámetro Description
USUARIO_DE_SOPORTE Usuario administrador de soporte técnico
SUPPORT_PWD Soporte de la contraseña del usuario administrador

Nota:

Asegúrese de reemplazar estos parámetros por los valores adecuados.

Paso 5: Agregar compatibilidad con sudo para usuarios administradores

Para agregar compatibilidad con sudo para los usuarios administradores, siga estos pasos:

  1. Abra el archivo de configuración de sudoers:
sudo vi /etc/sudoers.d/opengear
  1. Agregue las líneas siguientes para conceder acceso a sudo:
%netgrp ALL=(ALL) ALL
%admin ALL=(ALL) NOPASSWD: ALL

Nota:

Asegúrese de guardar los cambios después de editar el archivo.

Esta configuración permite a los miembros del grupo "netgrp" ejecutar cualquier comando como cualquier usuario y miembro del grupo "admin" para ejecutar cualquier comando como cualquier usuario sin necesidad de una contraseña.

Paso 6: Garantizar la disponibilidad del servicio LLDP

Para asegurarse de que el servicio LLDP está disponible en el servidor de terminal, siga estos pasos:

Compruebe si el servicio LLDP se está ejecutando:

sudo systemctl status lldpd

Debería ver una salida similar a la siguiente si el servicio se está ejecutando:

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.

Si el servicio no está activo (en ejecución), inicie el servicio:

sudo systemctl start lldpd

Habilite el servicio para que se inicie al reiniciar:

sudo systemctl enable lldpd

Nota:

Asegúrese de realizar estos pasos para asegurarse de que el servicio LLDP siempre está disponible y se inicia automáticamente tras el reinicio.

Paso 7: Comprobación de la fecha y hora del sistema

Asegúrese de que la fecha y hora del sistema esté configurada correctamente y la zona horaria del servidor de terminal esté en UTC.

Compruebe la configuración de zona horaria:

Para comprobar la configuración de zona horaria actual:

ogcli get system/timezone

Establezca la zona horaria en UTC:

Si la zona horaria no está establecida en UTC, puede establecerla mediante:

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

Compruebe la fecha y hora actuales:

Compruebe la fecha y hora actuales:

date

Corrija la fecha y hora si es incorrecta:

Si la fecha y hora son incorrectas, puede corregirla mediante:

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

Parámetros:

Nombre de parámetro Description
CURRENT_DATE_TIME Fecha y hora actual en formato hh:mm MMM DD, YYYY

Nota:

Asegúrese de que la fecha y hora del sistema es precisa para evitar problemas con aplicaciones o servicios que dependen de él.

Paso 8: Etiquetado de puertos de Terminal Server (si faltan o son incorrectos)

Para etiquetar los puertos de Terminal Server, use el siguiente comando:

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

Parámetros:

Nombre de parámetro Description
NEW_NAME Nombre de la etiqueta de puerto
PUERTO_# Número de puerto de Terminal Server

Paso 9: Configuración requerida para las conexiones serie PURE Array

Las matrices de Pure Storage adquiridas antes de 2024 tienen controladores de revisión R3 que usan cables de consola de inversión y requieren los comandos de conexión de puerto serie personalizados a continuación:

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

Los equipos de Pure Storage más recientes y los sistemas actualizados de controladores de Pure Storage de R3 a R4 utilizarán cables de consola de paso directo con la configuración actualizada que se detalla a continuación:

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:

Nombre de parámetro Description
PUERTO_# Número de puerto de Terminal Server

Estos comandos establecen la velocidad de baudios y el pinout para conectarse a la consola del controlador de Pure Storage.

Nota:

Todas las demás configuraciones de puerto de Terminal Server deben permanecer iguales y funcionar de forma predeterminada con un cable de consola RJ45 directo.

Paso 10: Comprobación de la configuración

Para comprobar los valores de configuración, ejecute los siguientes 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:

Asegúrese de que los vecinos LLDP sean los correctos, indicando conexiones exitosas a PE1 y PE2.

salida de vecinos LLDP de ejemplo:

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

Compruebe que la salida coincide con las expectativas y que todas las configuraciones son correctas.

Determinar si se debe habilitar SafeMode en matrices de almacenamiento

Las matrices pure Storage admiten una característica denominada SafeMode, diseñada para protegerse contra ataques de ransomware y otras actividades malintencionadas. Cuando está habilitada, las instantáneas de volúmenes se crean periódicamente que no se pueden eliminar ni modificar por completo durante un período de retención configurable. Habilitar SafeMode proporciona protección contra la pérdida de datos, pero también usa más capacidad de almacenamiento en la matriz.

La plataforma Operator Nexus admite la habilitación de SafeMode en matrices de almacenamiento. Los volúmenes están sujetos a su protección siempre que los grupos de protección predeterminados incluyan al menos uno con SafeMode habilitado. Sin embargo, no interactúa directamente con las instantáneas generadas y necesita trabajar con su representante de soporte técnico puro si necesita recuperar datos de una instantánea.

De forma predeterminada, SafeMode está habilitado en matrices de Pure Storage a través de un grupo de protección predeterminado. Si desea deshabilitarlo, puede hacerlo eliminando este grupo de protección predeterminado. Si desea habilitar SafeMode con diferentes frecuencia de instantáneas o configuraciones de retención, puede reemplazarlo por un nuevo Grupo de Protección habilitado para SafeMode con la configuración deseada.

Para obtener más información sobre SafeMode y sus implicaciones, consulte la documentación de Pure Storage (se requiere inicio de sesión). Póngase en contacto con su representante de soporte técnico de Pure para obtener más preguntas sobre SafeMode y su configuración.

Configuración de la primera matriz de almacenamiento

  1. El operador debe instalar el hardware de la matriz de almacenamiento según lo especificado por la BOM y el diagrama de instalación dentro del bastidor de agregación.
  2. El operador debe proporcionar al técnico de matriz de almacenamiento información para que el técnico de la matriz de almacenamiento llegue al sitio para configurar el dispositivo.
  3. Datos específicos de ubicación necesarios para compartir con el técnico de la matriz de almacenamiento.
    • Nombre del cliente:
    • Fecha de inspección física:
    • Número de serie del chasis:
    • Hostname del array de almacenamiento:
    • Código CLLI (identificador de ubicación de Common Language):
    • Dirección de instalación:
    • FIC/Rack/Grid Ubicación
  4. Datos proporcionados al operador y compartidos con el técnico de matriz de almacenamiento, que serán comunes a todas las instalaciones:
    • Nivel de código de pureza: consulte las versiones de puridad admitidas.
    • Modo seguro: consulte Determinar si se debe habilitar SafeMode en matrices de almacenamiento.
    • Zona horaria de matriz: UTC
    • Dirección IP del servidor DNS (sistema de nombres de dominio): no establecido por el operador durante la instalación
    • Sufijo de dominio DNS: no establecido por el operador durante la instalación
    • Dirección IP del servidor NTP (Protocolo de tiempo de red) o FQDN: no establecido por el operador durante la instalación
    • Syslog Primary: no establecido por el operador durante la instalación
    • Syslog Secondary: no establecido por operador durante la instalación
    • Dirección IP de puerta de enlace SMTP o FQDN: no establecido por el operador durante la instalación
    • Nombre de dominio del remitente de correo electrónico: nombre de dominio del remitente del correo electrónico (example.com)
    • Direcciones de correo electrónico que se van a alertar: no establecidas por el operador durante la instalación
    • Servidor proxy y puerto: no establecido por el operador durante la instalación
    • Administración: interfaz virtual
      • Dirección IP: 172.27.255.200
      • Puerta de enlace: no establecida por el operador durante la instalación
      • Máscara de subred: 255.255.255.0
      • MTU: 1500
      • Bond: no establecido por el operador durante la instalación
    • Administración: Controlador 0
      • Dirección IP: 172.27.255.254
      • Puerta de enlace: no establecida por el operador durante la instalación
      • Máscara de subred: 255.255.255.0
      • MTU: 1500
      • Bond: no establecido por el operador durante la instalación
    • Administración: Controlador 1
      • Dirección IP: 172.27.255.253
      • Puerta de enlace: no establecida por el operador durante la instalación
      • Máscara de subred: 255.255.255.0
      • MTU: 1500
      • Bond: no establecido por el operador durante la instalación
    • ct0.eth10: no establecido por el operador durante la instalación
    • ct0.eth11: no establecido por operador durante la instalación
    • ct0.eth18: no establecido por operador durante la instalación
    • ct0.eth19: no establecido por el operador durante la instalación
    • ct1.eth10: no establecido por el operador durante la instalación
    • ct1.eth11: no establecido por operador durante la instalación
    • ct1.eth18: no establecido por el operador durante la instalación
    • ct1.eth19: no establecido por el operador durante la instalación
    • Ajustable puro que se va a aplicar:
      • 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) Configuración de la segunda matriz de almacenamiento

Nota:

Esta sección es opcional. Solo tiene que ejecutarla si va a implementar una instancia de Azure Operator Nexus con dos dispositivos de almacenamiento. Para más información, incluidas las restricciones en el hardware admitido, consulte Azure Operator Nexus multiple storage appliances (Varios dispositivos de almacenamiento de Azure Operator Nexus).

  1. El operador debe instalar el hardware de la matriz de almacenamiento según lo especificado por la BOM y el diagrama de instalación dentro del bastidor de agregación.
  2. El operador debe proporcionar al técnico de matriz de almacenamiento información para que el técnico de la matriz de almacenamiento llegue al sitio para configurar el dispositivo.
  3. Datos específicos de ubicación necesarios para compartir con el técnico de la matriz de almacenamiento.
    • Nombre del cliente:
    • Fecha de inspección física:
    • Número de serie del chasis:
    • Hostname del array de almacenamiento:
    • Código CLLI (identificador de ubicación de Common Language):
    • Dirección de instalación:
    • FIC/Rack/Grid Ubicación
  4. Datos proporcionados al operador y compartidos con el técnico de matriz de almacenamiento, que serán comunes a todas las instalaciones:
    • Nivel de código de pureza: consulte las versiones de puridad admitidas.
    • Modo seguro: consulte Determinar si se debe habilitar SafeMode en matrices de almacenamiento.
    • Zona horaria de matriz: UTC
    • Dirección IP del servidor DNS (sistema de nombres de dominio): no establecido por el operador durante la instalación
    • Sufijo de dominio DNS: no establecido por el operador durante la instalación
    • Dirección IP del servidor NTP (Protocolo de tiempo de red) o FQDN: no establecido por el operador durante la instalación
    • Syslog Primary: no establecido por el operador durante la instalación
    • Syslog Secondary: no establecido por operador durante la instalación
    • Dirección IP de puerta de enlace SMTP o FQDN: no establecido por el operador durante la instalación
    • Nombre de dominio del remitente de correo electrónico: nombre de dominio del remitente del correo electrónico (example.com)
    • Direcciones de correo electrónico que se van a alertar: no establecidas por el operador durante la instalación
    • Servidor proxy y puerto: no establecido por el operador durante la instalación
    • Administración: interfaz virtual
      • Dirección IP: 172.27.255.201
      • Puerta de enlace: no establecida por el operador durante la instalación
      • Máscara de subred: 255.255.255.0
      • MTU: 1500
      • Bond: no establecido por el operador durante la instalación
    • Administración: Controlador 0
      • Dirección IP: 172.27.255.251
      • Puerta de enlace: no establecida por el operador durante la instalación
      • Máscara de subred: 255.255.255.0
      • MTU: 1500
      • Bond: no establecido por el operador durante la instalación
    • Administración: Controlador 1
      • Dirección IP: 172.27.255.252
      • Puerta de enlace: no establecida por el operador durante la instalación
      • Máscara de subred: 255.255.255.0
      • MTU: 1500
      • Bond: no establecido por el operador durante la instalación
    • ct0.eth10: no establecido por el operador durante la instalación
    • ct0.eth11: no establecido por operador durante la instalación
    • ct0.eth18: no establecido por operador durante la instalación
    • ct0.eth19: no establecido por el operador durante la instalación
    • ct1.eth10: no establecido por el operador durante la instalación
    • ct1.eth11: no establecido por operador durante la instalación
    • ct1.eth18: no establecido por el operador durante la instalación
    • ct1.eth19: no establecido por el operador durante la instalación
    • Ajustable puro que se va a aplicar:
      • 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";

Asignación de IP de iDRAC

Antes de implementar el clúster nexus, es mejor que el operador establezca las direcciones IP de iDRAC al organizar los bastidores de hardware. Aquí se muestra cómo asignar servidores a direcciones IP:

  • Asigne direcciones IP en función de la posición de cada servidor dentro del rack.
  • Use el cuarto bloque /24 de la subred /19 asignada para Fabric.
  • Empiece a asignar direcciones IP desde el servidor más bajo hacia arriba en cada bastidor, empezando por 0.11.
  • Continúe asignando direcciones IP en secuencia al primer servidor en la parte inferior del siguiente bastidor.

Example

Rango de red: 10.1.0.0-10.1.31.255 – subred iDRAC en el cuarto /24 es 10.1.3.0/24.

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

Un diseño de ejemplo de tres instancias locales del mismo par NFC/CM, mediante redes /19 secuenciales en /16.

Instancia Rango de tejido Subred iDRAC
Instancia 1 10.1.0.0-10.1.31.255 10.1.3.0/24
Instancia 2 10.1.32.0-10.1.63.255 10.1.35.0/24
Instancia 3 10.1.64.0-10.1.95.255 10.1.67.0/24

Configuración predeterminada para otros dispositivos instalados

  • Todos los dispositivos de la fábrica de red (excepto el Terminal Server) están establecidos en modo ZTP
  • Los servidores tienen la configuración de fábrica predeterminada, incluida la configuración mínima del BIOS.

Como procedimiento recomendado, las siguientes versiones de BIOS y firmware deben instalarse en los servidores antes de la implementación, en función de la versión en tiempo de ejecución y boM seleccionada. Como referencia, la versión N es la versión más reciente disponible en tiempo de ejecución. N-1 y N-2 son las versiones en tiempo de ejecución admitidas anteriores.

Nota:

Las versiones de iDRAC anteriores a la 7.20.30.50 tenían limitaciones conocidas con la compatibilidad con la degradación del firmware. Como resultado, si un sistema de destino ejecutaba firmware más reciente en cualquier componente (BIOS, PERC, Broadcom, Mellanox, CPLD), iDRAC no marcaría la falta de coincidencia y omitiría la degradación. Este comportamiento se corrigió a partir de iDRAC 7.20.30.50. Aunque las versiones más recientes de iDRAC hacen un mejor intento de alinear el firmware del componente con el catálogo para el tiempo de ejecución determinado, ciertos escenarios de degradación pueden desencadenar reversiones de atributos que pueden provocar daños en el BIOS, tal como se documenta en Dell. Por este motivo, la práctica recomendada es asegurarse de que todas las versiones de firmware del componente sean iguales o inferiores a las versiones enumeradas para la versión en tiempo de ejecución correspondiente.

Versión N del entorno de ejecución del clúster nexus

BOM 1.7.3
Componente Versión
BIOS 1.18.1
Controlador de matriz de almacenamiento (PERC H755) 52.30.0-6115
iDRAC 7.20.30.55
Firmware SEP pasivo para placa posterior de almacenamiento sin expander (15G sin expander) 7.10
CPLD 1.1.1
Adaptador DX de Mellanox ConnectX-6 22.47.10.88
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 23.21.6
BOM 2.0.0
Componente Versión
BIOS 2.7.5
Controlador de matriz de almacenamiento (PERC H755) 52.30.0-6115
iDRAC 7.20.30.55
Firmware del Expansor de Backplane SAS (R760) 1.61
Firmware de backplane de almacenamiento sin expansión (R660) 7.10
CPLD 1.2.6
Adaptador DX de Mellanox ConnectX-6 22.47.10.88
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 23.21.6

Versión N-1 del entorno de ejecución del clúster nexus

BOM 1.7.3
Componente Versión
BIOS 1.17.2
Controlador de matriz de almacenamiento (PERC H755) 52.26.0-5179
iDRAC 7.20.30.00
Firmware SEP pasivo para placa posterior de almacenamiento sin expander (15G sin expander) 7.10
CPLD 1.1.1
Adaptador DX de Mellanox ConnectX-6 22.47.10.88
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 23.21.6
BOM 2.0.0
Componente Versión
BIOS 2.6.3
Controlador de matriz de almacenamiento (PERC H755) 52.26.0-5179
iDRAC 7.20.30.00
Firmware del Expansor de Backplane SAS (R760) 1.61
Firmware de backplane de almacenamiento sin expansión (R660) 7.10
CPLD 1.2.6
Adaptador DX de Mellanox ConnectX-6 22.47.10.88
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 23.21.6

Versión N-2 del entorno de ejecución del clúster nexus

BOM 1.7.3
Componente Versión
BIOS 1.15.2
Controlador de matriz de almacenamiento (PERC H755) 52.26.0-5179
iDRAC 7.10.90.00
Firmware SEP pasivo para placa posterior de almacenamiento sin expander (15G sin expander) 7.10
CPLD 1.1.1
Adaptador DX de Mellanox ConnectX-6 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 22.91.5
BOM 2.0.0
Componente Versión
BIOS 2.4.4
Controlador de matriz de almacenamiento (PERC H755) 52.26.0-5179
iDRAC 7.10.90.00
Firmware del Expansor de Backplane SAS (R760) 1.61
Firmware de backplane de almacenamiento sin expansión (R660) 7.10
CPLD 1.2.6
Adaptador DX de Mellanox ConnectX-6 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 22.91.5

Reglas de firewall entre Azure y el clúster Nexus.

Para establecer reglas de firewall entre Azure y nexus Cluster, el operador debe abrir los puertos especificados. Esto garantiza una comunicación y conectividad adecuadas para los servicios necesarios mediante TCP (protocolo de control de transmisión) y UDP (protocolo de datagramas de usuario).

S.No Fuente Destino Puerto (TCP/UDP) Bidireccional Propósito de regla
1 Red virtual de Azure Clúster 22 TCP No Para que SSH se use en servidores en la nube desde la subred de CM
2 Red virtual de Azure Clúster 443 TCP No Para acceder a los nodos undercloud iDRAC
3 Red virtual de Azure Clúster 5900 TCP No Gnmi
4 Red virtual de Azure Clúster 6030 TCP No Certificados de Gnmi
5 Red virtual de Azure Clúster 6443 TCP No Para acceder al clúster K8S en la nube
6 Clúster Red virtual de Azure 8080 TCP Para montar la imagen ISO en iDRAC, actualización del entorno de ejecución de NNF
7 Clúster Red virtual de Azure 3128 TCP No Proxy para conectarse a puntos de conexión globales de Azure
8 Clúster Red virtual de Azure 53 TCP y UDP No DNS
9 Clúster Red virtual de Azure 123 UDP No NTP
10 Clúster Red virtual de Azure 8888 TCP No Conexión al servicio web administrador de clústeres
11 Clúster Red virtual de Azure 514 TCP y UDP No Para acceder a los registros de la infraestructura de nube subyacente a través del Administrador de clústeres

Instalación de extensiones de la CLI e inicio de sesión en la suscripción de Azure

Instale la versión más reciente de las extensiones de la CLI necesarias.

Inicio de sesión de suscripción de Azure

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

Nota:

La cuenta debe tener permisos para leer, escribir o publicar en la suscripción.