15. Bootstrap de almacenamiento de objetos

Tiempo estimado para completar la actividad: 7 horas

Propietario del componente operable: OBJ

Perfil de habilidad: ingeniero de implementación

15.1. Requisitos de red

Consulta la siguiente imagen para ver un diagrama de cableado de los dispositivos SG1000 y SG6060 para configurar las redes GRID, Admin y Client:

Configuración del soporte de almacenamiento

15.1.1. Nodo de administrador SG1000

Debes tener al menos dos nodos de administrador en el SG1000.

Para cada nodo de administrador, debes tener un total de cuatro direcciones IP, una dirección en cada uno de los siguientes elementos:

  • Red de BMC.
  • Red de administración.
  • Red de cliente.
  • Es la red de cuadrícula.

Debes tener tres subredes para lo siguiente:

  • Red de administración.
  • Red de BMC.

La red de cliente y la red de Grid, y cada subred deben tener una máscara de subred de hasta 30 bits.

15.1.2. Nodos de almacenamiento SG6060 y SG6000

Debes tener al menos tres nodos de almacenamiento para los modelos SG6060 y SG6000.

Para cada nodo de almacenamiento, debes tener un total de cinco direcciones IP, una en cada uno de los siguientes elementos:

  • Red de BMC(administración).
  • Red de administración(mgmt).
  • Es la red de cuadrícula.
  • Es la red del controlador de almacenamiento (mgmt.). Nota: La red del controlador de almacenamiento debe tener dos direcciones IP.

Debes tener dos subredes para cada uno de los siguientes elementos:

  • Red de BMC.
  • Red de administración.
  • Red del controlador de almacenamiento.
  • Es la red de cuadrícula.

En la siguiente tabla, se indica la cantidad de direcciones IP para los nodos de administrador y almacenamiento:

Cantidad de IPs necesarias Red de administración Red de cliente Red de cuadrícula
Nodo de administrador 2 1 1
Nodo de almacenamiento 4 0 1

Debes tener las siguientes tres subredes:

  • Red de administración.
  • Red de cliente.
  • Es la red de cuadrícula.

Cada subred debe tener una máscara de subred de hasta 30 bits.

15.1.3. Detalles de la red

15.1.3.1. Red del plano de administración de Distributed Cloud:

La red de administración fuera de banda (OOB) de Distributed Cloud contiene la red del controlador de administración de la placa base (BMC) de Object Storage y la red de administración. La red se conecta a mgmtsw.

Debes tener la dirección IP del BMC fuera de banda en cada uno de los siguientes elementos:

  • SG1000
  • SG6000

Debes tener la dirección IP de administración fuera de banda en cada uno de los siguientes elementos:

  • SG1000
  • SG6000
  • SG6060

15.1.3.2. Red del plano de datos de Distributed Cloud

La red del plano de datos se compone de la LIF del cliente de StorageGRID (SG1000) externo y la red del cliente en NetApp.

  • Sigue los pasos que se indican a continuación para identificar el SubnetClaim en cada uno de los siguientes elementos:

    • Extremo de API de S3:
    1. En el archivo cellconfig, busca external-objectstorage-client-lif-subnet.
    2. Identifica el SubnetClaim correspondiente que especifica la dirección IP de CIDR/puerta de enlace asignada.

    • Extremos de los dispositivos de red de la cuadrícula SG1000:

      1. En el archivo cellconfig, busca objectstorage-admin-nodes-lif-subnet.
      2. Identifica el SubnetClaim correspondiente que especifica la dirección IP de CIDR o de puerta de enlace asignada.

  • Extremos de dispositivos de red de la cuadrícula SG6060:

    1. En el archivo cellconfig, busca objectstorage-storage-nodes-lif-subnet.
    2. Identifica el SubnetClaim correspondiente que especifica la dirección IP de CIDR/puerta de enlace asignada.

15.2. Preparación

15.2.1. Recopila información

Tiempo estimado: 5 a 10 minutos

Antes de continuar con esta sección, asegúrate de que el inicio y la configuración de la red completen la instancia de Distributed Cloud y de que el operador tenga acceso al archivo cellconfig más preciso o reciente disponible, o bien al inicio.

15.2.1.1. Recopila información de los dispositivos de hardware de almacenamiento

Las instancias de Distributed Cloud siguen una convención de nombres fija para identificar los dispositivos de hardware en los racks. Específicamente, a los siguientes dispositivos de almacenamiento de objetos:

  • Nodo de administrador(SG1000): <cell>-<rack>-objsadm[node-number]. Por ejemplo, af-ae-objsadm01 representa un nodo de administrador.
  • Nodo del controlador de procesamiento y almacenamiento (SG6000-CN): <cell>-<rack>-objs[node-number]. Por ejemplo: af-ae-objs01.
  • Biblioteca del controlador de almacenamiento(E2860): <cell>-<rack>-objs[node-number]-s1. Por ejemplo: af-ae-objs01-s1
  • Controladores de nodos de almacenamiento(SG6060): <cell>-<rack>-objs[node-number]-s1-[controller number]. Por ejemplo, af-ae-objs01-s1-01 y af-ae-objs01-s1-02.

15.2.1.2. Recopila información de la red del plano de administración

Durante el inicio y la configuración de la red, el operador debe crear una subred para el plano de administración. El sistema de almacenamiento de objetos requiere la siguiente información durante el proceso de inicio:

  1. Subred de administración.
  2. Dirección IP de la puerta de enlace de administración.
  3. 16 direcciones IP reservadas en la subred de administración, dos direcciones IP para cada nodo de administrador y cuatro direcciones IP para cada nodo de almacenamiento

Busca la dirección IP de la puerta de enlace de administración en SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet. Los campos <cell> y <rack> son los mismos que los identificados en el paso "Recopila información de los dispositivos de hardware de almacenamiento". Por ejemplo: af-ae-mgmtsw01-objs-os-subnet

kubectl get subnetclaim -n root <cell>-<rack>-mgmtsw01-objs-os-subnet -o jsonpath='{.status.ipv4SubnetStatus.reservedIpRanges[?(.type == "GatewayReservation")].ipRange.startIPAddress}'

Almacena el valor del comando en MANAGEMENT_SWITCH_GATEWAY.

15.2.1.3. Recopila información de la red del plano de datos

Antes de continuar, asegúrate de haber aprovisionado tres subredes para el sistema de almacenamiento de objetos durante el inicio y la configuración de la red.

Verifica si existen las siguientes subredes:

  • objectstorage-admin-nodes-lif-subnet
  • objectstorage-storage-nodes-lif-subnet
  • external-objectstorage-client-lif-subnet

Ejecuta el siguiente comando con los nombres de los SubnetClaim:

kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME

Verás el siguiente resultado:

NAME                                    CIDRCLAIM                             OVERLAY-NETWORK   IPV4-CIDR     IPV6-CIDR   VLAN   READY   VLANREADY
objectstorage-admin-nodes-lif-subnet   objectstorage-admin-nodes-lif-cidr   ObjectStorage     10.7.7.0/24                  7      True    True

Comprueba si están presentes los siguientes campos:

  1. VLAN
  2. READY: True
  3. VLANREADY: True

15.2.1.4. Recopila información de dependencia

El sistema de almacenamiento de objetos se basa en los siguientes servicios principales y la infraestructura de Distributed Cloud:

  • NTP
  • Módulos de seguridad de hardware (HSM)
  • DNS

15.2.1.5. Actualiza los campos POR COMPLETAR

Verifica si hay valores de TO-BE-FILLED en el archivo obj-cellobj.yaml y actualízalos.

Ejecuta el siguiente comando para asegurarte de que el valor no exista en el archivo YAML:

cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"

15.2.2. Red de administración de configuración a través de la conexión local

Tiempo estimado: 30 a 45 minutos

En esta subsección, se configura la red de administración para cada nodo del dispositivo StorageGRID. Una vez que se configura la red de administración, se accede a los nodos de StorageGRID desde el programa de arranque con la IP de la red de administración.

Sigue estos pasos para todos los dispositivos ObjectStorage:

  • af-ae-objsadm01
  • af-ae-objsadm02
  • af-ae-objs01
  • af-ae-objs02
  • af-ae-objs03

Para iniciar los dispositivos de StorageGRID, conéctate a cada dispositivo, incluidos dos nodos de administrador y tres nodos de almacenamiento, con un carro de asistencia en el puerto 6 de la red de administración y visita https://169.254.0.1:8443 para configurar las direcciones IP de administrador en la red de administración.

  1. Conecta un carro de asistencia directamente al puerto RJ-45 ubicado más a la derecha del dispositivo de servicios con un cable Ethernet. En los siguientes diagramas, se muestra el puerto 6 para los nodos de administrador y de almacenamiento como ejemplo:

    Puerto 6 para nodos de administrador

    Puerto 6 para nodos de almacenamiento

  2. Abre un navegador web en el carro de paro.

  3. Navega a https://169.254.0.1:8443 en cada máquina.

  4. En la barra de menú del instalador de dispositivos StorageGRID, haz clic en Configure Networking > Link Configuration. Verifica si la red de administración está habilitada.

    Habilita la red de administrador

  5. Para configurar la dirección IP de la red de administración, selecciona Configure Networking > IP Configuration.

  6. Desplázate hacia abajo hasta la sección Admin Network y, en IP Assignment, selecciona Static y, luego, ingresa las direcciones IP de administración correspondientes, managementIP, para el nodo. Puedes encontrar la IP de administración de cada nodo en el archivo obj-cellobj.yaml. Por ejemplo:

    • Nodo ObjectStorageAdmin (SG1000):

      apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
kind: ObjectStorageAdminNode
metadata:
  creationTimestamp: null
  name: af-ae-objsadm01
spec:
  network:
    bmcIP: 10.251.188.11/24
    clientIP: 10.251.113.2/28
    dataIP: 10.1.0.66/26
    managementIP: 10.251.188.10/24
  siteName: objectstorage-site

    • ObjectStorageStorageNode (SG6000):

      apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
kind: ObjectStorageStorageNode
metadata:
  creationTimestamp: null
  name: af-ae-objs01
spec:
  network:
    bmcIP: 10.251.243.34/24
    controllerAManagementIP: 10.251.243.35/24
    controllerBManagementIP: 10.251.243.36/24
    dataIP: 10.1.0.132/26
    managementIP: 10.251.243.33/24
  siteName: objectstorage-site

    Establece la puerta de enlace como MANAGEMENT_SWITCH_GATEWAY.

    En la siguiente imagen de ejemplo, se muestra la configuración de af-ae-objs01 con la dirección IP de administración asignada en el archivo obj-cellobj.yaml:

    Configura la red de administrador

  7. Haz clic en Guardar y verifica si se actualizó la dirección IP.

  8. Haz ping en la dirección IP de administración desde el programa de arranque para asegurarte de que sea accesible.

    1. Haz ping en la dirección IP de administración desde el programa de arranque para asegurarte de que se pueda acceder a ella.
    2. Una vez que todos los nodos tengan una dirección IP en la red de administración, accede a la GUI de instalación del nodo de StorageGRID con su dirección IP de administración.

Solución de problemas:

Si no se puede hacer ping a un nodo, haz lo siguiente:

  1. Accede a la IU de instalación del nodo de StorageGRID desde el paso 3 anterior y verifica si se muestran errores en un banner de diálogo. Intenta resolver los errores. Comunícate con los ingenieros si es necesario.
  2. Ve a Configure Networking > IP Configuration. Verifica que la sección de red de administrador correcta esté configurada con la IP estática y la puerta de enlace correctas. A veces, el nodo de StorageGRID no registra por completo la configuración de la red de administración después de la confirmación.
  3. Vuelve a realizar los pasos del 5 al 8 y verifica la red del nodo de administrador.

Se requiere acceso a la GUI de instalación del nodo de StorageGRID en cada nodo para continuar con la instalación del sistema de almacenamiento de objetos.

15.2.3. Actualiza StorageGRID

Tiempo estimado: 1 a 1.5 horas

Antes de actualizar StorageGRID, verifica la versión del software de StorageGRID. Navega a Advanced > Upload StorageGRID Software. Verás la versión actual de StorageGRID.

Verifica la versión de instalación de StorageGRID incluida:

gdcloud artifacts tree oci | grep object-storage/os

El resultado de muestra es similar al siguiente:

│   │   │       └── gpc-system-object-storage/os:11.8.0
    ├── gpc-system-object-storage/os:sha256-d4cb75f91f43a92cb580db98faae12e87ec49d2b27c7db8a056d6411ac3b6044.sig

En este ejemplo, la versión se etiqueta en el artefacto como 11.8.0:

Almacena el valor de la versión en SG_INSTALL_VERSION.

Verifica la versión de firmware de StorageGRID incluida:

gdcloud artifacts tree oci | grep object-storage/firmware

El resultado de muestra es similar al siguiente:

│   │   │       ├── gpc-system-object-storage/firmware:3.8.1
    ├── gpc-system-object-storage/firmware:sha256-20a664504c342b5f14188114fad7a1e7d40abc042690bb0f776aa67cecff52e1.sig

En este ejemplo, la versión se etiqueta en el artefacto como 3.8.1:

Almacena el valor de la versión en SG_FIRMWARE_VERSION.

Si la versión del nodo no es SG_INSTALL_VERSION, continúa con los pasos siguientes para actualizar o degradar la versión de instalación de StorageGRID. Si la versión actual es SG_INSTALL_VERSION, ve a la sección Actualiza SANtricity.

Cómo verificar la versión de StorageGRID

15.2.3.1. Actualizar firmware

Sigue estos pasos para todos los nodos de StorageGRID:

  • af-ae-objsadm01
  • af-ae-objsadm02
  • af-ae-objs01
  • af-ae-objs02
  • af-ae-objs03

  1. Recupera la imagen de firmware del paquete:

    gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/firmware:SG_FIRMWARE_VERSION

tar -xvzf storage/gpc-system-object-storage/firmware.tar.gz

    El archivo está disponible en storagegrid_firmware_install/.

  2. Navega al instalador de dispositivos de StorageGRID en el nodo de StorageGRID. Elige Advanced > Upgrade Firmware. Sube la imagen de firmware storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2 y la suma de verificación storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1 para la versión de firmware seleccionada. Después de la carga, StorageGRID comienza automáticamente a validar los archivos. La validación suele tardar entre cinco y diez minutos.

    Cómo subir la imagen de firmware

  3. Después de que aparezcan dos marcas de verificación verdes, haz clic en Upgrade Inactive Partition.

    Actualiza la partición inactiva

    Después de recibir el mensaje Successfully updated the firmware on the inactive partition, asegúrate de que la partición inactiva sea la versión correcta. Para ello, consulta la sección Firmware actual.

    Haz clic en Reboot y Swap Partitions dos veces.

  4. Cuando el nodo termine de reiniciarse, repite los pasos uno y dos para actualizar el firmware de la otra partición. La partición activa es la versión elegida, mientras que la partición inactiva contiene la versión anterior.

    Actualiza otra partición inactiva

15.2.3.2. Actualiza el software de StorageGRID

Una vez que se complete la actualización del firmware en todos los nodos a la versión correcta, actualiza el software a la versión seleccionada en los dos nodos de administrador. No es necesario actualizar los nodos de almacenamiento, ya que imitan y extraen el software de los nodos de administrador.

Sigue estas instrucciones en los nodos de administrador del SG1000:

  • af-ae-objsadm01
  • af-ae-objsadm02

  1. Recupera la imagen de instalación del paquete:

    gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/os:SG_INSTALL_VERSION

tar -xvzf storage/gpc-system-object-storage/os.tar.gz

    Los archivos están disponibles en storagegrid_os_install/.

  2. Navega a Advanced -> Upload StorageGRID Software. Haz clic en Quitar para quitar el software actual y subir el nuevo paquete de software storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb y la suma de verificación correspondiente storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5, como se muestra a continuación:

    Cómo subir el paquete de StorageGRID

  3. Una vez que finalice la carga del software, asegúrate de que el software del nodo se haya actualizado a la versión seleccionada:

    Cómo verificar la versión de StorageGRID

15.2.4. Actualiza SANtricity

Tiempo estimado: 1 a 1.5 horas

Antes de actualizar SANtricity, verifica la versión del software de SANtricity. Navega a la IU de SANtricity y haz clic en Support > UPGRADE CENTER > Begin Upgrade. Aparecerá la versión actual de SANtricity.

Verifica la versión de instalación de SANtricity incluida:

gdcloud artifacts tree oci | grep object-storage/santricity

El resultado de muestra es similar al siguiente:

│   │   │       └── gpc-system-object-storage/santricity:11.70.5R1
    ├── gpc-system-object-storage/santricity:sha256-b145edeb8b24cac420862e7ef09224009aa51da6c6508f5a113753cc07db6ec5.sig

En este ejemplo, la versión se etiqueta en el artefacto como 11.70.5R1.

Almacena el valor de la versión en SANTRICITY_OS_VERSION.

Si la versión de SANtricity es anterior a SANTRICITY_OS_VERSION, continúa con los siguientes pasos para actualizar la versión del SO de SANtricity. De lo contrario, ve a Instalación.

Cómo verificar la versión de SANtricity

15.2.4.1. Actualiza el SO de SANtricity

Sigue estas instrucciones en la IU de SANtricity para cada nodo de almacenamiento:

  1. Recupera la imagen de instalación del paquete:

    gdcloud artifacts extract oci santricity \
    --image-name=gpc-system-object-storage/santricity:SANTRICITY_OS_VERSION

tar -xvzf santricity/gpc-system-object-storage/santricity.tar.gz

    El archivo de actualización está disponible en santricity/SANTRICITY_OS_VERSION/.

  2. Navega a Support > UPGRADE CENTER. Haz clic en Begin Upgrade en SANtricity OS Software upgrade. Haz clic en Explorar para seleccionar el archivo de software del SO de SANtricity. Sube el nuevo paquete de software RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp como se muestra a continuación:

    Cómo subir el paquete de SANtricity

  3. Haz clic en Iniciar y confirma que deseas realizar la operación.

  4. Una vez que finalice la actualización, verifica que la versión se haya actualizado:

    Cómo verificar la versión de SANtricity

15.3. Instalación

15.3.1. Crea objetos Secret

Tiempo estimado: 15 a 30 minutos

Para obtener valores para crear secretos, usa el directorio cellcfg:

  1. Obtén los nombres de objectstoragestoragenodes:

    $ CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
$ sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' CELLCFG_PATH/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'

    Resultado de muestra:

    # CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
# sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' ./cellcfg/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
ah-ac-objs01
ah-ac-objs02
ah-ac-objs03

  2. Recupera la dirección IP de la BMC del nodo de almacenamiento:

    echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /bmcIP/p" $CELL_ID-obj-cellobj.yaml | grep bmcIP | awk '{print $2}' | cut -d'/' -f1):8443

  3. Accede al administrador del sistema SANtricity desde el vínculo que se encuentra en el resultado del comando anterior. Si no configuraste la contraseña anteriormente, crea una y accede:

    Accede al administrador del sistema SANtricity

    1. Si se perdió la contraseña de SANtricity, restablécela a través de la consola en serie de StorageGRID E2860. Para conectarse al puerto en serie del array de discos E2860, la configuración de la terminal es 115200 8N1.

  4. Configura las direcciones del servidor NTP en el administrador del sistema SANtricity para ambos controladores:

    Configura las direcciones del servidor NTP

    1. Recupera las direcciones del servidor NTP

       kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP
 ```

    2. Selecciona Hardware en SANtricity System Manager.

    3. Si el gráfico muestra las unidades, haz clic en Mostrar la parte posterior de la biblioteca. El gráfico cambia para mostrar los controladores en lugar de las unidades.

    4. Haz clic en el control que quieras configurar. Aparecerá el menú contextual del controlador.

    5. Selecciona Configurar servidor NTP. Se abrirá el diálogo Configure Network Time Protocol (NTP) Server.

    6. Selecciona I want to enable NTP on Controller (A or B). En el diálogo, aparecerán selecciones adicionales.

    7. Selecciona Especificar manualmente las direcciones del servidor NTP. Ingresa la dirección del servidor NTP principal con una de las IPs que recuperó el comando anterior.

    8. Haz clic en Guardar.

  5. Actualiza los secretos que contienen credenciales de SANtricity para cada uno de los nodos de almacenamiento en el archivo cell.yaml. Si los secretos no existen, agrégalos según esta plantilla:

    apiVersion: v1
kind: Secret
metadata:
  creationTimestamp: null
  name: <STORAGE_NODE_NAME>-santricity
  namespace: gpc-system
stringData:
  password: 'PASSWORD'
  username: 'admin'
type: Opaque

  6. Crea los secretos para cada uno de los nodos de almacenamiento que se indican en el paso anterior:

    kubectl create secret generic \
   --namespace=gpc-system STORAGE_NODE_NAME-santricity \
   --from-literal=username=admin \
   --from-literal=password=PASSWORD

Validación:

  1. Ejecuta el siguiente comando con cada nodo de almacenamiento que se enumeró en el paso anterior. Imprime el nombre de usuario de Santricity establecido en el paso anterior. Valida el administrador:

    kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo

  2. Ejecuta el siguiente comando con cada nodo de almacenamiento que se enumeró en el paso anterior. Se imprimirá la contraseña de Santricity:

    kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo

  3. Ejecuta el siguiente comando para obtener la URL de la IU de Santricity Management. Accede a Santricity con el nombre de usuario y la contraseña:

    echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /controllerAManagementIP/p" $CELL_ID-obj-cellobj.yaml | grep controllerAManagementIP | awk '{print $2}' | cut -d'/' -f1):8443

Solución de problemas:

Si no se encuentran los secretos cuando ejecutas el paso de validación 1 o 2, vuelve a ejecutar el paso kubectl create secret.

Si no puedes acceder a la IU de Santricity Management, haz lo siguiente:

  1. Restablece la credencial de administrador a través de la consola serial de StorageGRID E2860.
  2. Realiza todos los pasos anteriores, excepto el último.

  3. Borra el secreto de Santricity existente de cada nodo:

    kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity

  4. Realiza el último paso para volver a crear el secreto de Santricity.

15.3.2. Bootstrap Object Storage

El proceso de bootstrapping de Object Storage varía entre la primera zona y las zonas que se unen. Consulta la sección pertinente según tu situación específica.

IMPORTANTE: Antes de continuar, verifica que la zona de anclaje haya terminado el proceso de arranque de la API global.

15.3.2.1. Inicializa el almacenamiento de objetos en la primera zona

Ejecuta el siguiente comando para iniciar el almacenamiento de objetos:

gdcloud system objectstorage install --config /CELLCFG_PATH  --first-zone --enable-objectstorage-hsm -v 5

15.3.2.2. Inicializa el almacenamiento de objetos en la zona de unión

Solución de problemas:

  1. Cuando los comandos de Google Cloud CLI agoten el tiempo de espera o muestren errores, resuelve los problemas que se hayan devuelto.
  2. Consulta el pod de gpc-system/obj-infra-cluster-cm-backend-controller de acceso para obtener más detalles sobre el error.

15.3.2.3. Inicializa el almacenamiento de objetos en la zona de unión

Tiempo estimado: 30 a 60 minutos

El proceso de bootstrapping de Object Storage en una zona de unión requiere coordinación entre los reconciliadores de Object Storage en la zona de anclaje y la zona de unión. Dado que no existe un canal de comunicación seguro y controlado entre dos zonas para los reconciliadores durante el tiempo de arranque, la IO debe facilitar manualmente la comunicación segura para los reconciliadores de Object Storage entre dos zonas.

  1. Otórgate el rol predefinido Cluster Admin en el clúster zonal de administrador raíz y en el clúster global de la zona de anclaje. Consulta el manual de IAM para obtener más detalles.

Como alternativa, aplica estas dos vinculaciones de roles en la zona de anclaje:

En la API global, haz lo siguiente:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: mz-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: mz-bootstrap-global-backend-controllers-role
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: fop-cluster-admin@example.com

En el clúster de administrador raíz:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: cluster-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: cluster-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: fop-cluster-admin@example.com

  1. Ejecuta el comando en la zona de anclaje para obtener la IP del servidor DNS y anótala para usarla más adelante: sh kubectl --kubeconfig /ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH get service gpc-coredns-external-udp -n dns-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

  2. Configura el solucionador de DNS auxiliar de la zona de unión para que se vincule con la zona de anclaje:

    1. Inhabilita y detén systemd-resolved sh systemctl disable systemd-resolved.service --now

    2. Borra el archivo resolv.conf si existe. sh rm -f /etc/resolv.conf

    3. Escribe la IP del servidor DNS de la zona de anclaje en el archivo resolv.conf de la zona de unión. sh vim /etc/resolv.conf Ejemplo de contenido del archivo /etc/resolv.conf: sh nameserver 10.200.40.0

  3. Crea el archivo YAML TokenRequest en la zona de unión.

    gdcloud system multi-zone create-token-request --zone JOINING_ZONE_NAME --client-type obj-join --cluster kind --namespace gpc-system --output-file TOKEN_REQUEST_YAML_PATH

    Reemplaza JOINING_ZONE_NAME por el nombre de la zona del Cuestionario de admisión del cliente, como se describe en la nota al final de la sección.

  4. Transfiere el archivo YAML de TokenRequest a la zona de anclaje.

    scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH

  5. Aplica el YAML de TokenRequest al clúster global root-admin en la zona de anclaje.

    kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH

  6. Crea el archivo YAML del token en la zona de anclaje.

    gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH

  7. Transfiere el archivo YAML del token a la zona de unión.

    scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH

  8. Aplica el YAML del token al clúster de KIND en la zona de unión.

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH

  9. Crea el archivo YAML de ObjectStorageBootstrap en la zona de anclaje.

    gdcloud system objectstorage create-bootstrap --output-file  OBJECT_STORAGE_BOOTSTRAP_YAML_PATH

  10. Transfiere el archivo YAML de ObjectStorageBootstrap a la zona de unión.

    scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH

  11. Aplica el archivo YAML de ObjectStorageBootstrap al clúster de KIND en la zona de unión.

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH

  12. Inicializa el almacenamiento de objetos en la zona de unión.

    gdcloud system objectstorage install --config /CELLCFG_PATH  --add-zone --enable-objectstorage-hsm -v 5