19. Bootstrap de clúster de administrador raíz

Tiempo estimado para completarlo: 7 horas

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

Perfil de habilidades: ingeniero de implementaciones

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

19.1. Configurar el enrutamiento

Confirma que la ruta estática se ha añadido durante la instalación del servidor Bootstrapper. Si falta la ruta estática, añade una ruta estática al bootstrapper:

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 administrador raíz desde la interfaz del plano de datos del bootstrapper. Para obtener más información sobre los servidores de APIs en GDC, consulta el artículo Servidores de APIs globales y zonales.

19.2. Crear un 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 cliente predeterminado es el modo multicliente.

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: El parámetro --addon-manager-manifests-set minStage=FEATURE_THRESHOLD no es necesario si el umbral de la función es production. El valor de FEATURE_THRESHOLD debe ser el mismo que el establecido para la implementación general.

Para crear un clúster de administrador raíz, se necesita 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 personalizar la configuración del clúster definiendo la marca --generate-admin-yaml en false y especificando --admin-yaml-path para que apunte a la ruta de configuración de destino.

Una vez completada 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 una vez que se ha completado el proceso de arranque.

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

gdcloud system admin-cluster describe

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

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

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

19.4. Configurar feature gates para el administrador raíz

Advertencia: Sigue las instrucciones de esta sección solo si has definido un umbral de fase de la función distinto de production.

Si tienes un umbral de fase de función diferente de production, debes actualizar tus feature gates para que coincidan con el umbral, siguiendo OOPS-P0072.

19.5. Configurar el resolvedor stub en el bootstrapper

Usa el siguiente comando para configurar el resolver stub de DNS en el bootstrapper. Se necesita este stub resolver para acceder a la consola.

gdcloud system dns install

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

19.6. Definir direcciones IP de iLO

En los siguientes pasos se definen 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 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 pasarela.

   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 gestor 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. Comprueba que se ha aplicado la configuración de Ethernet. Si la respuesta se queda colgada, el restablecimiento no se habrá completado. 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 se ha completado correctamente, comprueba que el valor de retorno HTTP de cada paso coincide con el resultado esperado.

Repite los pasos anteriores con todos los nodos de administrador raíz que haya en el clúster.

19.7. Establecer la conectividad con air gap de la red de OI y Google Distributed Cloud (GDC)

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

Para seguir estos pasos, se necesita 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 obtener información de la red en tiempo de ejecución.

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

19.7.1. Antes de empezar

En esta fase del proceso de implementación, se deben cumplir todas las condiciones siguientes:

1. Ambos conmutadores OIR están cableados, encendidos, actualizados a la versión adecuada y tienen aplicadas las configuraciones de base y de LCA.

2. Ambos cortafuegos OIF están cableados, encendidos, actualizados a la versión adecuada, habilitados para el modo FIPS-CC y tienen aplicada la configuración base.

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

Importante: Los pasos que requieren el uso de los archivos cellcfg se deben completar aunque el paso 3 no se haya completado del todo, pero el archivo cellcfg esté disponible. De esta forma, los interruptores se pueden configurar y estarán listos para la conectividad de Distributed Cloud. Una vez que el clúster esté activo y totalmente listo, será necesario realizar un paso adicional para generar y aplicar las políticas de seguridad del firewall.

19.7.2. Preparar el entorno

Prepara el entorno para los pasos siguientes. Para ello, reúne la siguiente información y define las variables de entorno.

OI se puede conectar de dos formas: localmente o de forma remota. Una conexión local conecta OI a Distributed Cloud directamente mediante conexiones de fibra entre racks del mismo centro de datos. Una conexión remota se conecta a una ubicación diferente mediante un 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 YAML de interconexión

Atributo	Descripción	Ejemplo
zones [ ] mapa	Información sobre la celda de Distributed Cloud a la que debe conectarse la implementación de OI. Para conectarte 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 debe conectarse la implementación de OI.	zones: - zoneName: kb
uplinkSpeed uint32	(Opcional) Proporciona la velocidad de subida 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 de Operations Suite Infrastructure Core Rack (OIR) a Distributed Cloud directamente mediante conexiones de fibra entre racks del mismo centro de datos.	zones: - zoneName: kb localInstanceIDs: 1
remoteInstance [ ] int	InstanceID(s) del sitio de implementación de OI del archivo ocit.yaml Una conexión remota se conecta a una o varias ubicaciones diferentes mediante un transporte de larga distancia. Se puede proporcionar una lista de valores de remoteInstance para que se generen configuraciones de todos los sitios de OIR con el fin de conectarse a las celdas de Distributed Cloud indicadas.	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

En las implementaciones de OI multisitio, 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 completas adecuadas o no se ejecutarán correctamente.

19.7.3. Generar configuraciones de interruptores

Estos pasos generan configuraciones de parches que se aplican a los dispositivos de red para aprovisionar la conectividad a Distributed Cloud.

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

De esta forma, se generan los siguientes archivos de configuración para cada sitio:

Archivo(s) de configuración	Dispositivo	Función
occoresw101.incremental	occoresw101	Configuración para parchear el dispositivo para la conectividad a la instancia de Distributed Cloud
occoresw101.acl	occoresw101	Configuración para parchear las ACLs para la aplicación del tráfico con las redes de Distributed Cloud.
occoresw102.incremental	occoresw102	Configuración para parchear el dispositivo para la conectividad a la instancia de Distributed Cloud
occoresw102.acl	occoresw102	Configuración para parchear las ACLs para la aplicación del tráfico con las redes de Distributed Cloud.
ocsw101.incremental	ocs1w01	Configuración para parchear el dispositivo para la conectividad a la instancia de Distributed Cloud
ocsw101.acl	ocsw101	Configuración para parchear las ACLs para la aplicación del tráfico con las redes de Distributed Cloud.
ocsw102.incremental	ocsw102	Configuración para parchear el dispositivo para la conectividad a la instancia de Distributed Cloud
ocsw102.acl	ocsw102	Configuración para parchear las ACLs para la aplicación del tráfico con las redes de Distributed Cloud.

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

19.7.4. Generar políticas de cortafuegos

Para generar las reglas de cortafuegos, el occonfigtool debe acceder a la API de Kubernetes del clúster de administrador raíz. Comprueba que la variable de entorno KUBECONFIG tenga asignado el valor 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 cortafuegos, ejecuta lo siguiente:

occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}

Archivo(s) de configuración	Dispositivo	Función
firewall-rules.base	occorefw01	Configuración para parchear el dispositivo para la conectividad a la instancia de Distributed Cloud

19.7.5. Aplicar configuraciones

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

19.8. Actualizar recursos de Distributed Cloud RoutePolicy

Distributed Cloud usa la política de rutas para determinar qué redes se pueden anunciar en la tabla de enrutamiento.

Cuando añadimos OI como red externa, tenemos que actualizar los RoutePolicy CRs para que esperen las nuevas redes.

Para ello, debes acceder a root-admin-cluster mediante kubectl. Asegúrate de que se ha definido la variable KUBECONFIG adecuada:

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

Para confirmarlo, haz lo siguiente:

kubectl get routepolicy -n gpc-system

Debería ver un resultado como el siguiente:

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

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

19.8.1.1. Parchear políticas de ruta de red de datos

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

Nota: Para implementar la OI en varios sitios, repite este paso en 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 en el siguiente ejemplo se usa como $OC_WORKSTATIONS_NET

Usa estos valores para ajustar las políticas de ruta rellenando 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

Una vez definidas 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
                }
            ]
        }
    }
]"

Ejemplo:

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

19.8.1.2. Políticas de ruta de red de gestión de parches

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

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

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

Usa estos valores para ajustar las políticas de ruta rellenando 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

Una vez definidas 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
                }
            ]
        }
    }
]"

Ejemplo:

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

19.9. Validar la conectividad de red de OI Distributed Cloud

Importante: Completa los pasos de validación que se indican en Establecer la red de OI y la conectividad de Distributed Cloud antes de validar las conexiones de Distributed Cloud. Tenga en cuenta que, si ya se han aplicado las configuraciones de incremental que ha realizado en el paso anterior, es posible que las validaciones de ese paso no coincidan exactamente.

En este punto de la implementación, se deben cumplir las siguientes condiciones:

• Tanto occoresw101 como occoresw102 se vuelven a configurar 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.
• Los enlaces ascendentes entre el centro de datos y el centro de operaciones están conectados y operativos.
• Se verifican los enlaces ascendentes físicos entre Distributed Cloud.

Nota: En las implementaciones de infraestructura de Operations Suite (OI) multisitio, se generan y se aplican archivos de configuración para cada sitio.

Si no se cumple alguna de las condiciones anteriores, el resultado puede variar considerablemente en función del estado actual y es probable que no se produzca el comportamiento esperado en producción.

19.9.1. Resultado esperado

En los siguientes fragmentos se muestra la salida 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: Añade | 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 que use 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 superior a 0.
• Todas las sesiones de BGP muestran un temporizador Up/Down que aumenta continuamente.
• El prefijo de Distributed Cloud externalCIDR (que se encuentra en el CIQ) está presente en las tablas de enrutamiento y BGP de las VRFs GDCH-DATA, GDCH-DATA-TRANSIT, OC-WORKSTATIONS y OCCORE-SERVERS.
• La nube distribuida oobManagementCIDRs (que se encuentra en el CIQ) está presente en las tablas de enrutamiento y las tablas BGP de las VRFs 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. Antes de completar este paso, debes realizar todas las validaciones de red. Los vecinos y las rutas de BGP que se describen aquí deben estar presentes junto con los vecinos y las rutas de BGP mencionados anteriormente. Valida la salida en todos los interruptores.

VRF	Vecino de BGP	Rutas esperadas recibidas del vecino BGP	Rutas esperadas anunciadas al vecino BGP
GDCH-DATA-TRANSIT	AGGSW01	Dirección de resumen agregada con la subred /19 de la celda de Distributed Cloud	Prefijo OCCORE-SERVERS Prefijo OC-WORKSTATION
GDCH-DATA-TRANSIT	AGGSW02	Dirección de resumen agregada con la subred /19 de la celda de Distributed Cloud	Prefijo OCCORE-SERVERS Prefijo OC-WORKSTATION
GDCH-DATA-TRANSIT	Sesión de BGP con bucle de retorno mediante OCCOREFW a VRF de OC-DATA	Dirección de resumen agregada (con subred /19) de la celda de Distributed Cloud
OC-DATA	Sesión de BGP de OCSW01	Dirección de resumen agregada (con subred /19) de la celda de Distributed Cloud
OC-DATA	Sesión de BGP de OCSW02	Dirección de resumen agregada (con subred /19) de la celda de Distributed Cloud
OC-DATA	Sesión de BGP de OCCORESW	Dirección de resumen agregada (con subred /19) de la celda de Distributed Cloud
GDCH-MGMT-TRANSIT	MGMTAGGSW01	Direcciones de resumen agregadas (con subred /24) de toda la red de gestión OOB de GDCH	Prefijo OCCORE-JUMPHOSTS Prefijo OCCORE-ILOS
GDCH-MGMT-TRANSIT	MGMTAGGSW02	Direcciones de resumen agregadas (con subred /24) de toda la red de gestión OOB de Distributed Cloud	Prefijo OCCORE-JUMPHOSTS Prefijo OCCORE-ILOS
GDCH-MGMT-TRANSIT	Sesión de BGP con bucle de retorno mediante OCCOREFW a HW-INFRA VRF	Direcciones de resumen agregadas (con subred /24) de toda la red de gestión OOB 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. Antes de completar este paso, debes realizar todas las validaciones de red. Los vecinos y las rutas de BGP que se describen aquí deben estar presentes junto con los vecinos y las rutas de BGP mencionados anteriormente. Valida la salida en todos los interruptores.

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

El fragmento de comando de salida se puede encontrar en Distributed Cloud validations show command.

Nota: En la siguiente sección se explica cómo validar las implementaciones multisitio. Puedes ignorar esta sección si tu implementación no es multisitio.

19.9.5. Validaciones de implementación de OI multisitio

En la siguiente sección se explica cómo validar implementaciones multisitio con varias celdas de Distributed Cloud interconectadas. En esta fase, la topología con dos sitios tiene este aspecto:

• 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 entre el sitio 1 y el sitio 2.

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

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

19.10. Completar los pasos finales de la red de OI

En esta fase, todas las configuraciones deben haberse generado y aplicado a todos los dispositivos.

Las listas de acceso a la red ahora permiten flujos específicos, pero también tienen 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. Por lo tanto, tiene requisitos de tráfico variables.

Una vez que el equipo de operaciones haya aceptado la implementación, deberá revisar las ACLs y proteger por completo los flujos de tráfico de la red.

Se proporcionan manuales de operaciones para llevar a cabo estas tareas.

19.11. Actualizar el almacenamiento de objetos

Durante el arranque del almacenamiento de objetos, los nodos se instalaron con la última versión secundaria compatible de StorageGRID. Sin embargo, es posible que la versión de destino deba actualizarse a la versión de parche de revisió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 de destino, realiza una actualización del almacenamiento de objetos con la versión de destino.

19.12. Posibles problemas

Importante: Es posible que te encuentres con estos problemas al instalar la versión 1.9.x de Distributed Cloud.

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

Resumen: La máquina virtual de almacenamiento no se prepara 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 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 impida el uso de SSL por motivos de seguridad.

Solución:

Conéctate a la consola serie o al clúster de almacenamiento mediante SSH y ejecuta el siguiente comando:

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

Una vez conectada, la máquina virtual de almacenamiento puede conciliarse.

19.12.2. Bootstrap ha fallado al instalar el certificado TLS del servidor del cortafuegos

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

Solución:

Para volver a intentar instalar el certificado del servidor del cortafuegos, consulta las instrucciones que se indican en el manual de servicio de E/S FW-R1008. Una vez que hayas completado la instalación correctamente, usa el comando gdcloud con el comando --start-phase para continuar con el arranque del administrador raíz.