Requisitos previos de la plataforma Operator Nexus

Artikulua
04/20/2024

Los operadores deben completar los requisitos previos antes de implementar el software de la plataforma Operator Nexus. Algunos de estos pasos pueden tardar grandes períodos de tiempo y, por lo tanto, una revisión de estos requisitos previos puede resultar beneficiosa.

En implementaciones posteriores de instancias de Operator Nexus, puede pasar a crear la estructura de red 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 estructura de red y, a continuación, un administrador de clústeres tal y como se especifica aquí. Además, es necesario realizar las siguientes tareas:

Configuración de usuarios, directivas, permisos y RBAC
Configuración de grupos de recursos para colocar y agrupar de forma lógica los recursos que se crearán para la plataforma Operator Nexus.
Establecer la conectividad de ExpressRoute desde la WAN a una región de Azure
Para habilitar Microsoft Defender para punto de conexión para máquinas sin sistema operativo (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 aquí.

Requisitos previos en el entorno local

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 de operador sin problemas, Operator Nexus ha desarrollado una lista de materiales para la adquisición de hardware necesaria para el servicio. Esta lista de materiales es una lista completa de los componentes y cantidades necesarios para implementar el entorno para una implementación y mantenimiento correctos de la instancia local. La lista de materiales está estructurada para proporcionar al operador una serie de unidades de almacenamiento de existencias (SKU) que se pueden pedir de 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 compilació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.

Colocación de 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 la compilación.

Creación de la superficie 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 previos antes de la ejecución de la compilación. En esta sección también se describen las suposiciones relativas a las aptitudes de los empleados del operador para ejecutar la compilación.

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

La ordenación de la SKU adecuada y la entrega de hardware al sitio deben producirse antes del inicio de la compilació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 admitir la infraestructura de hardware desde una perspectiva de espacio, energía 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 creación

El personal que realiza la compilación debe experimentarse en el montaje de hardware de sistemas como bastidores, conmutadores, PTU 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 compilació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:

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.
Después de ensamblar los bastidores, instale los dispositivos de tejido en los bastidores según el diagrama de elevación.
Conecte los dispositivos de tejido mediante la conexión de las interfaces de red según el diagrama de cableado.
Ensamblar e instalar los servidores por diagrama de elevación del bastidor.
Ensamblar e instalar el dispositivo de almacenamiento por diagrama de elevación del bastidor.
Conecte los dispositivos de servidor y almacenamiento mediante la conexión de las interfaces de red según el diagrama de cableado.
Alimentación por cable de cada dispositivo.
Revise o valide la compilación a través de las listas de comprobación proporcionadas por Operator Nexus y otros proveedores.

Cómo inspeccionar visualmente la instalación física del hardware

Se recomienda etiquetar en todos los cables siguiendo los estándares ANSI/TIA 606, o los estándares del operador, durante el proceso de compilació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. La asignación inversa se puede comparar con el diagrama de cableado para validar la instalación.

Configuración de la matriz de almacenamiento y Terminal Server

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

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 operadores enrutadores perimetrales del proveedor (PE) locales y configurados con las direcciones IP y las credenciales
Terminal Server es accesible desde la VPN de administración.

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	Descripción
TS_HOSTNAME	Nombre de host de Terminal Server

Consulte la referencia de la CLI para más detalles.

Paso 2: configuración de red

Para configurar la configuración de red, siga estos pasos:

Ejecute los comandos siguientes 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	Descripción
TS_NET1_IP	PE1 de Terminal Server para la dirección IP de NET1 de TS
TS_NET1_NETMASK	PE1 de Terminal Server para la máscara de red de NET1 de TS
TS_NET1_GW	PE1 de Terminal Server para la puerta de enlace de NET1 de TS
TS_NET2_IP	PE2 de Terminal Server para la dirección IP de NET2 de TS
TS_NET2_NETMASK	PE2 de Terminal Server para la máscara de red de NET2 de TS
TS_NET2_GW	PE2 de Terminal Server para la puerta de enlace de NET2 de TS

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:

Busque cualquier interfaz configurada en la interfaz física net3 y "Dirección estática IPv4 predeterminada" con el siguiente comando:

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

Parámetros:

Nombre de parámetro	Descripción
TS_NET3_CONN_NAME	Nombre de la conexión NET3 del servidor de terminal Server

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

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

Nombre de parámetro	Descripción
SUPPORT_USER	Usuario administrador de soporte técnico
HASHED_SUPPORT_PWD	Contraseña de usuario administrador codificada

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:

Abra el archivo de configuración de sudoers:

sudo vi /etc/sudoers.d/opengear

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 al reiniciar.

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

Establecer la zona horaria en UTC:

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

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

Comprobar la fecha y hora actuales:

date

Corregir la fecha y hora si es incorrecta:

Si la fecha y hora son incorrectas, puede corregirlas 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	Descripción
CURRENT_DATE_TIME	Fecha y hora actual en formato hh:mm MMM DD, AAAA

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	Descripción
NEW_NAME	Nombre de la etiqueta de puerto
PORT_#	Número de puerto de Terminal Server

Paso 9:configuraciones requeridas para las conexiones seriales de PURE Array

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

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

Los dispositivos de Pure Storage más recientes y los sistemas actualizados de R3 a R4 Pure Storage usarán cables de consola de conexión directa con la siguiente configuración actualizada:

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	Descripción
PORT_#	Número de puerto de Terminal Server

Estos comandos establecen la velocidad en 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 de conexión directa.

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 son los esperados, lo que indica que las conexiones correctas 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.

Configuración de la matriz de almacenamiento

El operador debe instalar la matriz de almacenamiento tal y como especifica la marca BOM y la elevación del bastidor dentro del bastidor de agregación.
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.
Datos específicos de la ubicación necesarios que se comparten con el técnico de la matriz de almacenamiento:
- Nombre del cliente:
- Fecha de inspección física:
- Número de serie del chasis:
- Nombre de host de la matriz de almacenamiento:
- Código CLLI (Identificador de ubicación de lenguaje común):
- Dirección de la instalación:
- Ubicación del FIC/bastidor/cuadrícula:
Datos proporcionados al operador y compartidos con el técnico de la matriz de almacenamiento, que serán comunes a todas las instalaciones:
- Nivel del código de Purity: consulte las versiones de Purity admitidas
- Modo seguro: Deshabilitado
- Zona horaria de la matriz: UTC
- Dirección IP del servidor DNS (Sistema de nombres de dominio): 172.27.255.201
- 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: 172.27.255.212
- Syslog primario: 172.27.255.210
- Syslog secundario: 172.27.255.211
- 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: 172.27.255.1
  - 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: 172.27.255.1
  - 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: 172.27.255.1
  - Máscara de subred: 255.255.255.0
  - MTU: 1500
  - Bond: no establecido por el operador durante la instalación
- Número de VLAN/Prefijo: 43
- ct0.eth10: no establecido por el operador durante la instalación
- ct0.eth11: no establecido por el operador durante la instalación
- ct0.eth18: no establecido por el 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 el 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
- Sintonización pura que debe aplicarse:
  - 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 direcciones 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:

Asigna direcciones IP en función de cada posición del servidor dentro del bastidor.
Usa el cuarto bloque de /24 de la subred /19 asignada para Fabric.
Empieza a asignar direcciones IP desde el servidor inferior hacia arriba en cada bastidor, empezando por 0.11.
Continúa asignando direcciones IP en secuencia al primer servidor en la parte inferior del siguiente bastidor.

Ejemplo

Intervalo de Fabric: 10.1.0.0-10.1.31.255 – La subred de iDRAC en el cuarto /24 es 10.1.3.0/24.

Bastidor	Server	IP de iDRAC
Bastidor 1	Trabajo 1	10.1.3.11/24
Bastidor 1	Trabajo 2	10.1.3.12/24
Bastidor 1	Trabajo 3	10.1.3.13/24
Bastidor 1	Trabajo 4	10.1.3.14/24
Bastidor 1	Trabajo 5	10.1.3.15/24
Bastidor 1	Trabajo 6	10.1.3.16/24
Bastidor 1	Trabajo 7	10.1.3.17/24
Bastidor 1	Trabajo 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	Trabajo 1	10.1.3.21/24
Bastidor 2	Trabajo 2	10.1.3.22/24
Bastidor 2	Trabajo 3	10.1.3.23/24
Bastidor 2	Trabajo 4	10.1.3.24/24
Bastidor 2	Trabajo 5	10.1.3.25/24
Bastidor 2	Trabajo 6	10.1.3.26/24
Bastidor 2	Trabajo 7	10.1.3.27/24
Bastidor 2	Trabajo 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	Trabajo 1	10.1.3.31/24
Bastidor 3	Trabajo 2	10.1.3.32/24
Bastidor 3	Trabajo 3	10.1.3.33/24
Bastidor 3	Trabajo 4	10.1.3.34/24
Bastidor 3	Trabajo 5	10.1.3.35/24
Bastidor 3	Trabajo 6	10.1.3.36/24
Bastidor 3	Trabajo 7	10.1.3.37/24
Bastidor 3	Trabajo 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	Trabajo 1	10.1.3.41/24
Bastidor 4	Trabajo 2	10.1.3.42/24
Bastidor 4	Trabajo 3	10.1.3.43/24
Bastidor 4	Trabajo 4	10.1.3.44/24
Bastidor 4	Trabajo 5	10.1.3.45/24
Bastidor 4	Trabajo 6	10.1.3.46/24
Bastidor 4	Trabajo 7	10.1.3.47/24
Bastidor 4	Trabajo 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	Intervalo de Fabric	Subred de 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 tejido de red (excepto Terminal Server) se establecen en modo ZTP
Los servidores tienen la configuración predeterminada de fábrica

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

Para establecer reglas de firewall entre Azure y el clúster de Nexus, 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	Origen	Destination	Puerto (TCP/UDP)	Bidireccional	Propósito de la regla
1	red virtual de Azure	Clúster	22 TCP	No	Para que SSH se use en servidores undercloud desde la subred de CM.
2	red virtual de Azure	Clúster	443 TCP	No	Para acceder al iDRAC de los nodos undercloud
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 de K8S de undercloud
6	Clúster	red virtual de Azure	8080 TCP	Sí	Para montar la imagen ISO en iDRAC, actualización en runtime 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 undercloud desde el Administrador de clústeres

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

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

Nota:

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

Partekatu honen bidez:

Requisitos previos de la plataforma Operator Nexus

Requisitos previos de Azure

Requisitos previos en el entorno local

Configuración de hardware físico

Uso de la lista de materiales (BOM)

Uso del diagrama de elevación

Diagrama de cableado

Cómo ordenar en función de la SKU

Definición de SKU

Colocación de un pedido basado en SKU

Creación de la superficie de hardware físico

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

Preparación del sitio

Programación de recursos

Suposiciones sobre las aptitudes del personal de creación

Descripción general del proceso de compilación

Cómo inspeccionar visualmente la instalación física del hardware

Configuración de la matriz de almacenamiento y Terminal Server

Configuración de Terminal Server

Paso 1: configuración del nombre de host

Paso 2: configuración de red

Paso 3: borrar la interfaz net3 (si existe)

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

Paso 5: agregar compatibilidad con sudo para usuarios administradores

Paso 6: garantizar la disponibilidad del servicio LLDP

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

Compruebe la configuración de zona horaria:

Establecer la zona horaria en UTC:

Comprobar la fecha y hora actuales:

Corregir la fecha y hora si es incorrecta:

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

Paso 9:configuraciones requeridas para las conexiones seriales de PURE Array

Paso 10: comprobación de la configuración

Configuración de la matriz de almacenamiento

Asignación de direcciones IP de iDRAC

Ejemplo

Configuración predeterminada para otros dispositivos instalados

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

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

Inicio de sesión en la suscripción de Azure

Oharrak

Baliabide gehigarriak