19. Inicio del clúster de administrador raíz

Tiempo estimado para completar la actividad: 7 horas

Propietario del componente operable: KUB/SERV/OBJ/FILE/PNET

Perfil de habilidad: ingeniero de implementación

En esta guía, se crea un clúster de administrador raíz que actúa como plano de control para el clúster interno y los clústeres de infraestructura de la organización.

19.1. Configura el enrutamiento

Confirma que se haya agregado la ruta estática durante la instalación del servidor de arranque. Si falta la ruta estática, agrega una al programa de arranque:

DATA_CIDR=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -o jsonpath={.spec.ipv4Spec.staticCidrBlocks[0]})
DATA_GATEWAY=$(kubectl get subnetclaims -n root control-plane-subnet -o jsonpath={.status.ipv4SubnetStatus.gateway})
ip route replace ${DATA_CIDR} via ${DATA_GATEWAY}

Esta ruta proporciona acceso al servidor de la API del clúster de administración raíz desde la interfaz del plano de datos en el programa de arranque. Para obtener más información sobre los servidores de API en GDC, consulta Servidores de API globales y zonales.

19.2. Crea el clúster de administrador raíz

El siguiente comando crea un clúster de administrador raíz con tres nodos del plano de control. El modo de arrendatario predeterminado es el modo multiusuario.

gdcloud system admin-cluster install -v=3 \
  --tenant-mode=multi \
  --root-admin-node-count=3 \
  --generate-admin-yaml \
  --addon-manager-manifests-set harbor.postgresqlHA.enabled=true \
  --addon-manager-manifests-set harbor.productionEnvironment.enabled=true \
  --addon-manager-manifests-set storage.mode=ontap \
  --addon-manager-manifests-set gpuFeature.enabled=true \
  --addon-manager-manifests-set rootAdmin.controller.adminLBPoolSize=23 \
  --addon-manager-manifests-set rootAdmin.controller.systemLBPoolSize=60 \
  --addon-manager-manifests-set network.noInternalSubnet=false \
  --addon-manager-manifests-set minStage=FEATURE_THRESHOLD

Nota: No se necesita el parámetro --addon-manager-manifests-set minStage=FEATURE_THRESHOLD si el umbral de la función es production. El valor de FEATURE_THRESHOLD debe ser el mismo que el que se estableció para la implementación general.

La creación del clúster de administrador raíz requiere un archivo de configuración para el CR del clúster. La configuración se genera automáticamente de forma predeterminada. También se permite la configuración personalizada del clúster si se establece la marca --generate-admin-yaml en false y se especifica --admin-yaml-path para que apunte a la ruta de acceso de configuración de destino.

Una vez que se completa la instalación del clúster de administrador raíz, el kubeconfig del clúster de administrador raíz se almacena en /root/release/root-admin/root-admin-kubeconfig.

Nota: El Protocolo de Internet versión 6 (IPv6) está disponible para el clúster de administrador raíz de forma predeterminada después de que se completa el proceso de arranque.

La URL de la interfaz de usuario (IU) del administrador de usuarios se imprime después de la instalación del clúster. Recuérdala para usarla en operaciones posteriores. También puedes recuperarlo con el siguiente comando:

gdcloud system admin-cluster describe

19.3. Implementa componentes en el clúster de administrador raíz

El siguiente comando implementa plantillas de ciclo de vida de componentes operables en el clúster de administrador raíz.

gdcloud system component deploy --kubeconfig KUBECONFIG --names=* --pivot-from=/root/.kube/config

19.4. Configura marcas de funciones para el administrador raíz

Advertencia: Sigue las instrucciones de esta sección solo si estableciste un umbral de etapa de la función diferente de production.

Si tienes un umbral de etapa de la función diferente de production, debes actualizar tus marcas de funciones según corresponda para que coincidan con el umbral, siguiendo OOPS-P0072.

19.5. Configura el solucionador de código auxiliar en el programa de arranque

Usa el siguiente comando para configurar el solucionador de stub de DNS en el programa de arranque. Este resolver de stub es necesario para acceder a la consola.

gdcloud system dns install

Esta configuración garantiza que todos los nombres de dominio de las organizaciones se puedan resolver desde el programa de arranque, como se muestra en el siguiente diagrama:

19.6. Cómo establecer direcciones IP de iLO

En los siguientes pasos, se configuran las direcciones IP de ILO en static para los nodos de administrador.

  ADMIN_NODE=NODE NAME
  RACK=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.metadata.labels.system\.private\.gdc\.goog/rack-name}')
  ILO_IP=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.ip}')
  ILO_GATEWAY=$(kubectl --kubeconfig KUBECONFIG get subnetclaims -n root $RACK-mgmtsw01-server-bmc-subnet -o jsonpath='{.status.ipv4SubnetStatus.gateway}')
  BMC_CREDS=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.credentialsRef.name}')
  ILO_USER=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.username}' | base64 --decode)
  ILO_PASS=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.password}' | base64 --decode)

  echo Target Server: $ADMIN_NODE
  echo ILO IP: $ILO_IP
  echo ILO Gateway: $ILO_GATEWAY
  echo ILO Username: $ILO_USER
  echo ILO Password: $ILO_PASS

Verifica que la información anterior sea correcta según la información del clúster. Ejecuta el siguiente comando si la información anterior es correcta.

1. Inhabilita el DHCP.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"DHCPv4": {"DHCPEnabled": false}}' | jq '.'
   

   Resultado esperado:

   MessageId: iLO.2.15.ResetRequired

2. Configura la dirección IP y la puerta de enlace.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"IPv4Addresses":[{"Address":"'${ILO_IP}'","Gateway":"'${ILO_GATEWAY}'","SubnetMask":"255.255.255.0"}],"IPv4StaticAddresses": [{"Address": "'${ILO_IP}'", "Gateway": "'${ILO_GATEWAY}'", "SubnetMask": "255.255.255.0"}]}' | jq .
   

   Resultado esperado:

   MessageId: Base.1.4.Success

3. Restablece el administrador de iLO.

   curl -k -u ${ILO_USER}:${ILO_PASS}  -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq .
   

   Resultado esperado:

   MessageId: iLO.2.15.ResetInProgress

4. Verifica que se haya aplicado la configuración de Ethernet. Si la respuesta se detiene, el restablecimiento no se completó. Cancela el comando curl actual, espera 20 segundos y vuelve a intentarlo.

   curl --insecure -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 -X GET | jq .
   

Para confirmar que la operación se realizó correctamente, verifica que la devolución HTTP de cada paso coincida con el resultado esperado.

Repite los pasos anteriores para todos los nodos de administrador raíz que estén presentes en el clúster.

19.7. Establece la conectividad aislada de la red de OI y Google Distributed Cloud (GDC)

En esta sección, se describe cómo aprovisionar archivos de configuración que las redes de la infraestructura de Operations Suite (OI) y de Distributed Cloud usan para establecer la conectividad.

Estos pasos requieren acceso a algunos archivos de Distributed Cloud, así como conectividad con el clúster de administrador raíz de la instancia de Distributed Cloud para recuperar la información de red del entorno de ejecución.

Importante: Si no trabajaste con el programa de arranque de Distributed Cloud, es posible que necesites la asistencia de un ingeniero de implementación de Distributed Cloud para acceder al programa de arranque y garantizar el acceso a la API de Kubernetes del clúster de administrador raíz.

19.7.1. Antes de comenzar

En esta etapa del proceso de implementación, se deben cumplir los siguientes requisitos:

1. Ambos conmutadores OIR están conectados con cables, encendidos, actualizados a la versión adecuada y tienen aplicada la configuración base y de ACL.

2. Ambos firewalls de OIF están conectados con cables, encendidos, actualizados a la versión adecuada, habilitados para el modo FIPS-CC y tienen aplicada la configuración básica.

3. Para completar el aprovisionamiento de conectividad de Distributed Cloud, la instancia de Distributed Cloud debe haber completado el inicio de red y haber salido del clúster de tipo para pasar al clúster de administrador raíz.

Importante: Los pasos que requieren el uso de los archivos cellcfg deben completarse incluso si el paso 3 aún no está completamente terminado, pero el cellcfg está disponible. Esto permite que los conmutadores se configuren y estén listos para la conectividad de Distributed Cloud. Una vez que el clúster esté en funcionamiento y completamente listo, se requiere un paso adicional para generar y aplicar las políticas de seguridad del firewall.

19.7.2. Prepare el entorno

Prepara el entorno para los siguientes pasos. Para ello, recopila la siguiente información y configura las variables de entorno.

La OI se puede conectar de dos maneras: de forma local o remota. Una conexión local conecta OI a Distributed Cloud directamente a través de conexiones de fibra entre racks en el mismo centro de datos. Una conexión remota se conecta a una ubicación diferente a través de transporte de larga distancia. Esta especificación se puede proporcionar en el archivo interconnect.yaml, que es necesario para aprovisionar las configuraciones de interconexión de Distributed Cloud. Este archivo contiene toda la información necesaria para configurar las interconexiones de GDC.

19.7.2.1. Especificación de YAML de interconexión

Atributo	Descripción	Ejemplo
Mapa de zones [ ]	Es la información sobre la celda de Distributed Cloud a la que se debe conectar la implementación de OI. Para conectarse a una lista de celdas de Distributed Cloud, especifica una lista de zones con información de cada celda de Distributed Cloud en cada zona. Opciones de zona	Ejemplo: zones: - zoneName: kb - uplinkSpeed: 10 localInstanceIDs: 2 remoteInstanceIDs: - 1 - cellCfg: path/to/cellcfg - zoneName: ah - uplinkSpeed: 100 localInstanceIDs: 3 - cellCfg: path/to/cellcfg

19.7.2.2. Opciones de zona

Contiene información sobre una celda de Distributed Cloud en el archivo interconnect.yaml:

Atributo	Descripción	Uso
zoneName string	Abreviatura de la celda de Distributed Cloud a la que se debe conectar la implementación de OI.	zones: - zoneName: kb
uplinkSpeed uint32	(Opcional) Proporciona la velocidad de carga de la conexión: (10 o 100).	Valores:10, 100 Valor predeterminado: 10 uplinkSpeed: 100
localInstance int	El InstanceID del sitio de implementación de OI del archivo ocit.yaml. Una conexión local conecta el sitio del rack principal de la infraestructura de Operations Suite (OIR) a Distributed Cloud directamente a través de conexiones de fibra entre los racks del mismo centro de datos.	zones: - zoneName: kb localInstanceIDs: 1
remoteInstance [ ] int	InstanceID(s) del sitio de implementación de OI desde el archivo ocit.yaml Una conexión remota se conecta a una o varias ubicaciones diferentes a través de transporte de larga distancia. Se puede proporcionar una lista de valores de remoteInstance, de modo que se generen configuraciones para todos los sitios de OIR para conectarse a las celdas de Distributed Cloud determinadas.	zones: - zoneName: kb remoteInstanceIDs: - 1 zones: - zoneName: kb remoteInstanceIDs: - 1 - 2 - 3

Si se trata de una conexión local, configura el archivo interconnect.yaml de la siguiente manera:

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    cellCfg: /path/to/cellcfg

Si se trata de una conexión remota, configura el archivo interconnect.yaml de la siguiente manera:

zones:
  - zoneName: ah
    uplinkSpeed: 100
      remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Para las implementaciones de OI en varios sitios, especifica el archivo interconnect.yaml de la siguiente manera:

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Advertencia: Completa estos pasos y usa las rutas de acceso completas adecuadas o el comando no se ejecutará correctamente.

19.7.3. Genera configuraciones de conmutadores

Estos pasos generan configuraciones de parches para aplicar a los dispositivos de red y, así, aprovisionar la conectividad a Distributed Cloud.

occonfigtool generate cell config -c /path/to/interconnect.yaml -o path/to/ocit.yaml

Esto genera los siguientes archivos de configuración para cada sitio:

Archivos de configuración	Dispositivo	Función
occoresw101.incremental	occoresw101	Configuración para aplicar parches al dispositivo para la conectividad a la instancia de Distributed Cloud
occoresw101.acl	occoresw101	Es la configuración para aplicar parches a las LCA para la aplicación del tráfico con las redes de Distributed Cloud.
occoresw102.incremental	occoresw102	Configuración para aplicar parches al dispositivo para la conectividad a la instancia de Distributed Cloud
occoresw102.acl	occoresw102	Es la configuración para aplicar parches a las LCA para la aplicación del tráfico con las redes de Distributed Cloud.
ocsw101.incremental	ocs1w01	Configuración para aplicar parches al dispositivo para la conectividad a la instancia de Distributed Cloud
ocsw101.acl	ocsw101	Es la configuración para aplicar parches a las LCA para la aplicación del tráfico con las redes de Distributed Cloud.
ocsw102.incremental	ocsw102	Configuración para aplicar parches al dispositivo para la conectividad a la instancia de Distributed Cloud
ocsw102.acl	ocsw102	Es la configuración para aplicar parches a las LCA para la aplicación del tráfico con las redes de Distributed Cloud.

Nota: Para las implementaciones de la infraestructura de Operations Suite (OI) en varios sitios, se genera una configuración para cada sitio que se menciona en el archivo interconnect.yaml. Identifica los archivos generados para cada sitio con InstanceID. Los archivos que se generan tienen un prefijo con el siguiente formato: <segment_type><device_type><InstanceID><device_id>

19.7.4. Genera políticas de firewall

Para generar las reglas de firewall, occonfigtool debe acceder a la API de Kubernetes del clúster de administrador raíz. Asegúrate de que la variable de entorno KUBECONFIG esté configurada en root-admin-kubeconfig:

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export OCIT_CONFIG_FILE=/path/to/ocit.yaml

Para generar las reglas de firewall, ejecuta el siguiente comando:

occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}

Archivos de configuración	Dispositivo	Función
firewall-rules.base	occorefw01	Configuración para aplicar parches al dispositivo para la conectividad a la instancia de Distributed Cloud

19.7.5. Aplica configuraciones

Con los archivos de salida, aplica la configuración a los dispositivos de red respectivos con el mismo procedimiento que en el paso anterior para los conmutadores y los firewalls.

19.8. Actualiza los recursos de RoutePolicy de Distributed Cloud

Distributed Cloud usa la política de rutas para aplicar qué redes pueden anunciarse en la tabla de enrutamiento.

Cuando agregamos OI como una red externa, debemos actualizar los CR de RoutePolicy para que esperen las redes nuevas.

Esto requiere acceder a root-admin-cluster con kubectl. Asegúrate de que la variable KUBECONFIG adecuada esté configurada:

export KUBECONFIG=/root/deploy/root-admin/root-admin-kubeconfig

Para confirmar, haz lo siguiente:

kubectl get routepolicy -n gpc-system

Deberías ver el siguiente resultado o uno similar:

NAME                                     AGE
customerpeering-routepolicy              19d
datacenter-routepolicy                   19d
mgmtnetworkoperationcenter-routepolicy   19d
networkoperationcenter-routepolicy       19d

En estos pasos, nos enfocaremos en networkoperationcenter-routepolicy y mgmtnetworkoperationcenter-routepolicy.

19.8.1.1. Aplica parches a las políticas de rutas de la red de datos

Desde ocinfo.opscenter.local.txt, recupera las siguientes subredes (incluida la red y la longitud del prefijo).

Nota: Para la implementación de OI en varios sitios, repite este paso para todos los sitios. Usa las subredes del archivo ocinfo.opscenter.local.txt de los sitios que se indican.

• OCCORE-SERVERS, que se usa en el siguiente ejemplo como $OCCORE_SERVERS_NET
• OC-WORKSTATIONS, que se usa en el siguiente ejemplo como $OC_WORKSTATIONS_NET

Usa estos valores para ajustar las políticas de rutas completando las siguientes variables:

export OCCORE_SERVERS_NET=$OCCORE_SERVERS_NET
export OC_WORKSTATIONS_NET=$OC_WORKSTATIONS_NET

Por ejemplo:

export OCCORE_SERVERS_NET=172.21.0.0/24
export OC_WORKSTATIONS_NET=172.21.32.0/24

Después de configurar las variables de entorno, ejecuta los siguientes comandos de kubectl:

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_SERVERS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OC_WORKSTATIONS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Resultado de ejemplo:

routepolicy.system.private.gdc.goog/networkoperationcenter-routepolicy patched

19.8.1.2. Políticas de rutas de red de administración de parches

Desde ocinfo.opscenter.local.txt, recupera las siguientes subredes (incluida la red y la longitud del prefijo).

Nota: Para las implementaciones de OI en varios sitios, repite este paso para todos los sitios. Usa las subredes de los archivos ocinfo.opscenter.local.txt de la lista de sitios.

• OCCORE-JUMPHOSTS, que se usa en el siguiente ejemplo como $OCCORE_JUMPHOSTS_NET
• OCCORE-ILOS, que se usa en el siguiente ejemplo como $OCCORE_ILOS_NET

Usa estos valores para ajustar las políticas de rutas completando las siguientes variables:

export OCCORE_JUMPHOSTS_NET=$OCCORE_JUMPHOSTS_NET
export OCCORE_ILOS_NET=$OCCORE_ILOS_NET

Por ejemplo:

export OCCORE_JUMPHOSTS_NET=172.21.2.0/27
export OCCORE_ILOS_NET=172.21.2.32/27

Después de configurar las variables de entorno, ejecuta los siguientes comandos de kubectl:

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_JUMPHOSTS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_ILOS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Resultado de ejemplo:

routepolicy.system.private.gdc.goog/mgmtnetworkoperationcenter-routepolicy patched

19.9. Valida la conectividad de red de OI Distributed Cloud

Importante: Completa los pasos de validación en Establece la conectividad de la red de OI y de Distributed Cloud antes de validar las conexiones de Distributed Cloud. Ten en cuenta que, si ya se aplicaron las configuraciones de incremental que se realizaron en el paso anterior, es posible que las validaciones de ese paso no coincidan con exactitud.

En este punto de la implementación, se deben cumplir los siguientes requisitos:

• occoresw101 y occoresw102 se configuran con los archivos de configuración base, acl, incremental y incremental-acl.
• Tanto ocsw101 como ocsw102 se configuran con los archivos de configuración base, acl, incremental y incremental-acl.
• Tanto occorefw101 como occoref102 se configuran con los archivos de configuración base y firewall-rules.base.
• Las conexiones ascendentes entre el centro de datos y el centro de operaciones están conectadas y en funcionamiento.
• Se verifican las conexiones ascendentes físicas entre Distributed Cloud.

Nota: En el caso de las implementaciones de la infraestructura de Operations Suite (OI) en varios sitios, se generan y aplican archivos de configuración para cada sitio.

Si no se cumple ninguna de las condiciones anteriores, es posible que el siguiente resultado difiera considerablemente según el estado actual y es probable que no produzca el comportamiento esperado en producción.

19.9.1. Resultado esperado

En los siguientes fragmentos, se muestra el resultado de un entorno correcto conocido de los siguientes comandos:

• show ip bgp summary vrf all
• show ip bgp vrf all
• show ip route vrf all
• show lldp neighbors

Nota: Agrega | no-more al final de cada comando para evitar la paginación, por ejemplo, show ip bgp vrf all | no-more.

Estos fragmentos pueden servir como comparación con un entorno de producción usando los mismos comandos.

19.9.2. Validaciones de claves

A continuación, se indican los aspectos clave que debes buscar en los siguientes resultados:

• Ninguna sesión de BGP está en estado Idle, Active o Closing.
• Todas las sesiones de BGP muestran un valor de State/PrxRcd mayor que 0.
• Todas las sesiones de BGP muestran un temporizador Up/Down que aumenta de forma continua.
• El prefijo de Distributed Cloud externalCIDR (que se encuentra en CIQ) está presente en las tablas de enrutamiento y las tablas de BGP de las VRF GDCH-DATA, GDCH-DATA-TRANSIT, OC-WORKSTATIONS y OCCORE-SERVERS.
• El oobManagementCIDRs de Distributed Cloud (que se encuentra en CIQ) está presente en las tablas de enrutamiento y las tablas de BGP de las VRF GDCH-MGMT, GDCH-MGMT-TRANSIT y HW-INFRA.

19.9.3. OCCORESW

En la siguiente tabla, se muestra el resultado esperado en cada occore switch para las interconexiones de Distributed Cloud. Debes completar todas las validaciones de red antes de este paso. Los vecinos y las rutas de BGP que se analizan aquí deben estar presentes junto con los vecinos y las rutas de BGP que se mencionaron anteriormente. Valida la salida en todos los conmutadores.

VRF	Vecino de BGP	Rutas esperadas recibidas del vecino de BGP	Rutas esperadas anunciadas al vecino de BGP
GDCH-DATA-TRANSIT	AGGSW01	Dirección de resumen agregada con la subred /19 para la celda de Distributed Cloud	Prefijo OCCORE-SERVERS Prefijo OC-WORKSTATION
GDCH-DATA-TRANSIT	AGGSW02	Dirección de resumen agregada con la subred /19 para la celda de Distributed Cloud	Prefijo OCCORE-SERVERS Prefijo OC-WORKSTATION
GDCH-DATA-TRANSIT	Sesión de BGP con Hairpinning que usa OCCOREFW para la VRF de OC-DATA	Dirección de resumen agregada (con subred /19) para la celda de Distributed Cloud
OC-DATA	Sesión de BGP de OCSW01	Dirección de resumen agregada (con subred /19) para la celda de Distributed Cloud
OC-DATA	Sesión de BGP de OCSW02	Dirección de resumen agregada (con subred /19) para la celda de Distributed Cloud
OC-DATA	Sesión de BGP de OCCORESW	Dirección de resumen agregada (con subred /19) para la celda de Distributed Cloud
GDCH-MGMT-TRANSIT	MGMTAGGSW01	Direcciones de resumen agregadas (con subred /24) de toda la red de administración fuera de banda de GDCH	Prefijo de OCCORE-JUMPHOSTS Prefijo OCCORE-ILOS
GDCH-MGMT-TRANSIT	MGMTAGGSW02	Direcciones de resumen agregadas (con subred /24) de toda la red de administración fuera de banda de Distributed Cloud	Prefijo de OCCORE-JUMPHOSTS Prefijo OCCORE-ILOS
GDCH-MGMT-TRANSIT	Sesión de BGP con Hairpinning que usa OCCOREFW para la VRF de HW-INFRA	Direcciones de resumen agregadas (con subred /24) de toda la red de administración fuera de banda de Distributed Cloud

19.9.4. OCSW

En la siguiente tabla, se muestra el resultado esperado en cada oc switch después de realizar el procedimiento de interconexión de Distributed Cloud. Debes completar todas las validaciones de red antes de este paso. Los vecinos y las rutas de BGP que se analizan aquí deben estar presentes junto con los vecinos y las rutas de BGP que se mencionaron anteriormente. Valida la salida en todos los conmutadores.

VRF	Vecino de BGP	Rutas esperadas recibidas del vecino de BGP
OC-DATA	Sesión de BGP de OCCORESW01	Dirección de resumen agregada (con subred /19) para la celda de GDCH
OC-DATA	Sesión de BGP de OCCORESW02	Dirección de resumen agregada (con subred /19) para la celda de GDCH

El fragmento de comando de salida se puede encontrar en Comando para mostrar las validaciones de Distributed Cloud.

Nota: En la siguiente sección, se aborda la validación en implementaciones en varios sitios. Puedes ignorar esta sección de forma segura si tu implementación no es de varios sitios.

19.9.5. Validaciones de la implementación de OI en varios sitios

En la siguiente sección, se detalla cómo validar las implementaciones en varios sitios con varias celdas de Distributed Cloud interconectadas. En esta etapa, la topología con dos sitios se ve de la siguiente manera:

• Las conexiones azules muestran el sitio 1 conectado a las celdas 01 y 02 de Distributed Cloud.
• Las conexiones rojas muestran el sitio 2 conectado a las celdas 01 y 02 de Distributed Cloud.
• Las conexiones verdes muestran la interconexión del sitio 1 y el sitio 2.

Para todos los sitios en todos los conmutadores, debes completar los pasos que se indican en estas secciones.

1. Validaciones de red
2. Validaciones multisitio de la red.
3. Validaciones de red de Distributed Cloud.

19.10. Realiza los pasos finales de la red de OI

En esta etapa, se deben haber generado todos los parámetros de configuración y se deben haber aplicado a todos los dispositivos.

Las listas de acceso a la red ahora se encuentran en un estado que permite flujos específicos esperados, pero también tiene una regla predeterminada que permite todo el tráfico.

Ahora debes transferir la implementación a Operaciones. La Suite Operacional varía en función, implementación y servicios proporcionados entre los clientes. Como resultado, tiene requisitos de tráfico variables.

Una vez que Operaciones aceptó la implementación, es su tarea trabajar en las ACL y proteger por completo los flujos de tráfico de la red.

Se proporcionan manuales de operaciones para realizar estas tareas.

19.11. Actualiza el almacenamiento de objetos

Durante el inicio del almacenamiento de objetos, los nodos se instalaron con la versión secundaria compatible más reciente de StorageGRID. Sin embargo, es posible que la versión de destino deba actualizarse a la versión de parche de corrección más reciente.

Determina la versión de StorageGRID de destino a partir de los metadatos de la versión con el siguiente comando:

kubectl get releasemetadata -o jsonpath='{.items[0].spec.infraComponents.objectStorage.storageGridOSImageVersion}'

Si la versión actual de StorageGRID no es la versión de destino, realiza una actualización del almacenamiento de objetos con la versión de destino.

19.12. Posibles problemas

Importante: Es posible que tengas estos problemas cuando instales la versión 1.9.x de Distributed Cloud.

19.12.1. La máquina virtual de almacenamiento no se reconcilia

TLDR: La máquina virtual de almacenamiento no está lista durante la creación del clúster de administrador raíz.

Problema: Después de crear el clúster de administrador raíz, el recurso de la máquina virtual de almacenamiento no se reconcilia y muestra un evento de advertencia como el siguiente:

StorageVirtualMachine Reconcile error, retrying: SVM status update failed,
error: failed to get network interface info: Get
"https://172.22.147.128/api/network/ip/interfaces?fields=%2A%2A&max_records=4096&svm.name=root-admin":
EOF

Este problema puede deberse a una configuración incorrecta en el clúster de almacenamiento que impide el uso de SSL por motivos de seguridad.

Solución alternativa:

Conéctate al clúster de almacenamiento o a la consola en serie con SSH y ejecuta lo siguiente:

security ssl modify -server-enabled true -client-enabled true -vserver
CELL_ID-stge-clus-01

Después de la conexión, el recurso de la máquina virtual de almacenamiento puede conciliarse.

19.12.2. No se pudo iniciar el servidor de arranque en la instalación del certificado del servidor TLS del firewall

Es posible que se produzca un error de TLSServerCertification cuando realices la tarea de arranque del plano de control del administrador raíz que se describe en el paso 20.

Solución alternativa:

Para volver a intentar la instalación del certificado del servidor del firewall, consulta las instrucciones que se indican en el manual de servicio de IO FW-R1008. Después de completar una instalación exitosa, usa el comando gdcloud con el comando --start-phase para continuar con el arranque del administrador raíz.