15. Bootstrap de almacenamiento de objetos

Tiempo estimado para completarlo: 7 horas

Propietario del componente operable: OBJ

Perfil de habilidades: ingeniero de implementaciones

15.1. Requisitos de red

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

Configuración del contenedor

15.1.1. Nodo de administrador SG1000

Debes tener al menos dos nodos de administrador en SG1000.

En cada nodo de administrador, debes tener un total de cuatro direcciones IP, una en cada uno de los siguientes elementos:

  • Red de BMC.
  • Red de administradores.
  • Red de clientes.
  • Grid Network.

Debes tener tres subredes para lo siguiente:

  • Red de administradores.
  • Red de BMC.

La red de clientes y la red de la cuadrícula, así como cada subred, deben tener una máscara de subred de 30 bits como máximo.

15.1.2. Nodos de almacenamiento SG6060 y SG6000

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

En cada nodo de almacenamiento, debes tener un total de cinco direcciones IP, una dirección en cada uno de los siguientes elementos:

  • BMC Network(mgmt).
  • Red de administración(mgmt).
  • Grid Network.
  • Red de controladores de almacenamiento (gestión). 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 administradores.
  • Red de controladores de almacenamiento.
  • Grid Network.

En la siguiente tabla se indica el número de direcciones IP de los nodos de administrador y de almacenamiento:

Número de IPs necesarias Red de administradores Red de clientes Red de cuadrícula
Nodo de administrador 2 1 1
Nodo de almacenamiento 4 0 1

Debes tener las tres subredes siguientes:

  • Red de administradores.
  • Red de clientes.
  • Grid Network.

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

15.1.3. Detalles de red

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

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

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

  • SG1000
  • SG6000

Debes tener la dirección IP de gestión OOB 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 de cliente de StorageGRID (SG1000) del objeto externo y de la red de cliente de NetApp.

  • Sigue estos pasos para identificar el SubnetClaim en cada uno de ellos:

    • Endpoint de la 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 o de pasarela asignada.

    • Endpoints de 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 pasarela asignada.

  • Endpoints de los 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 o de pasarela asignada.

15.2. Preparación

15.2.1. Recoger información

Tiempo estimado: entre 5 y 10 minutos

Antes de continuar con esta sección, asegúrate de que el bootstrap 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 más reciente disponible, o bien al bootstrap.

15.2.1.1. Recoger información sobre dispositivos de hardware de almacenamiento

Las instancias de Distributed Cloud siguen una convención de nomenclatura fija para identificar los dispositivos de hardware en los racks. En concreto, 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 de controlador de computación de almacenamiento (SG6000-CN): <cell>-<rack>-objs[node-number]. Por ejemplo: af-ae-objs01.
  • Estante de la controladora 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. Recoger información de red del plano de gestión

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

  1. Subred de gestión.
  2. Dirección IP de la pasarela de gestión.
  3. 16 direcciones IP reservadas en la subred de gestió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 pasarela de gestión en SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet. <cell> y <rack> son los mismos que los identificados en el paso "Recopilar 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. Recoger información de red del plano de datos

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

Comprueba 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 que se incluyan los siguientes campos:

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

15.2.1.4. Recoger información de las dependencias

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

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

15.2.1.5. Actualizar los campos POR_RELLENAR

Comprueba si hay algún valor TO-BE-FILLED en el archivo obj-cellobj.yaml y actualízalo.

Ejecuta lo siguiente para asegurarte de que el valor no existe en el archivo YAML:

cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"

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

Tiempo estimado: entre 30 y 45 minutos

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

Sigue estos pasos en todos los dispositivos ObjectStorage:

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

Para inicializar los dispositivos StorageGRID, conéctate a cada dispositivo, incluidos dos nodos de administración 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 administración en la red de gestión.

  1. Conecta un carro de asistencia directamente al puerto RJ-45 situado más a la derecha del dispositivo de servicios mediante 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 emergencia.

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

  4. En la barra de menú del instalador del dispositivo StorageGRID, haga clic en Configure Networking > Link Configuration (Configurar red > Configuración de enlace). Comprueba si la red de administrador está habilitada.

    Habilitar la red de administrador

  5. Para configurar la dirección IP de la red de administración, selecciona Configurar > Red > Configuración de IP.

  6. Desplázate hacia abajo hasta la sección Red de administración y, en Asignación de IP, selecciona Estática e introduce las direcciones IP de gestión correspondientes managementIP del nodo. Puedes encontrar la IP de gestión de cada nodo en el archivo obj-cellobj.yaml. Por ejemplo:

    • ObjectStorageAdminNode (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

    Define la pasarela 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 gestión asignada en el archivo obj-cellobj.yaml:

    Configurar la red de administración

  7. Haz clic en Guardar y comprueba si se actualiza la dirección IP.

  8. Haz ping a la dirección IP de gestión desde el bootstrapper para asegurarte de que se puede acceder a ella.

    1. Haz ping a la dirección IP de gestión desde el bootstrapper para asegurarte de que se puede acceder a ella.
    2. Una vez que todos los nodos tengan una dirección IP en la red de administración, acceda a la GUI de instalación del nodo de StorageGRID mediante su dirección IP de gestión.

Solución de problemas:

Si no se puede hacer ping a un nodo:

  1. Accede a la interfaz de usuario de instalación del nodo de StorageGRID desde el paso 3 anterior y comprueba si se muestra algún error en un banner de diálogo. Intenta resolver los errores. Ponte en contacto con los ingenieros si es necesario.
  2. Vaya a Configurar red > Configuración de IP. Verifica que la sección Red de administración correcta esté configurada con la IP estática y la puerta de enlace correctas. A veces, el nodo de StorageGRID no registra completamente la configuración de la red de gestió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.

Para continuar con la instalación del sistema de almacenamiento de objetos, es necesario acceder a la GUI de instalación de nodos de StorageGRID en cada nodo.

15.2.3. Actualizar StorageGRID

Tiempo estimado: de 1 a 1,5 horas

Antes de actualizar StorageGRID, comprueba la versión del software de StorageGRID. Ve a Avanzado > Cargar software de StorageGRID. Verás la versión actual de StorageGRID.

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

gdcloud artifacts tree oci | grep object-storage/os

La salida de ejemplo es similar a la siguiente:

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

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

Almacena el valor de la versión en SG_INSTALL_VERSION.

Comprueba la versión de firmware de StorageGRID incluida:

gdcloud artifacts tree oci | grep object-storage/firmware

La salida de ejemplo es similar a la siguiente:

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

La versión se etiqueta en el artefacto, en este ejemplo, 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 cambiar a una versión anterior de StorageGRID. Si la versión actual es SG_INSTALL_VERSION, ve a la sección Actualizar SANtricity.

Comprobar la versión de StorageGRID

15.2.3.1. Actualizar el firmware

Sigue estos pasos en todos los nodos de StorageGRID:

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

  1. Obtén 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. Ve al instalador del dispositivo StorageGRID en el nodo de StorageGRID. Elige Avanzado > Actualizar firmware. Sube la imagen de firmware storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2 y la suma de comprobación storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1 de la versión de firmware seleccionada. Después de la subida, StorageGRID empieza a validar los archivos automáticamente. La validación suele tardar entre cinco y diez minutos.

    Subir imagen de firmware

  3. Cuando aparezcan dos marcas de verificación verdes, haz clic en Actualizar partición inactiva.

    Actualizar partición inactiva

    Después de recibir el mensaje Successfully updated the firmware on the inactive partition, comprueba que la partición inactiva sea la versión correcta consultando la sección Firmware actual.

    Haz clic en Reiniciar y Intercambiar particiones 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.

    Actualizar otra partición inactiva

15.2.3.2. Actualizar el software de StorageGRID

Una vez que se haya completado la actualización del firmware de 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 administración.

Sigue estas instrucciones en los nodos de administración de SG1000:

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

  1. Obtén 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. Ve a Advanced -> Upload StorageGRID Software (Avanzado -> Subir software de StorageGRID). Haz clic en Quitar para eliminar el software actual y sube el nuevo paquete de software storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb y la suma de comprobación correspondiente storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5, tal como se muestra a continuación:

    Subir paquete de StorageGRID

  3. Una vez que se haya terminado de subir el software, comprueba que el software del nodo se haya actualizado a la versión seleccionada:

    Comprobar la versión de StorageGRID

15.2.4. Actualizar SANtricity

Tiempo estimado: de 1 a 1,5 horas

Antes de actualizar SANtricity, comprueba la versión del software SANtricity. Vaya a la interfaz de usuario de SANtricity y haga clic en Support > UPGRADE CENTER > Begin Upgrade (Soporte > CENTRO DE ACTUALIZACIONES > Iniciar actualización). Se muestra la versión actual de SANtricity.

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

gdcloud artifacts tree oci | grep object-storage/santricity

La salida de ejemplo es similar a la siguiente:

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

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

Almacena el valor de la versión en SANTRICITY_OS_VERSION.

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

Comprobar la versión de SANtricity

15.2.4.1. Actualizar el SO de SANtricity

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

  1. Obtén 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 estará disponible a las santricity/SANTRICITY_OS_VERSION/.

  2. Vaya a Asistencia > CENTRO DE ACTUALIZACIONES. En Actualización del software del SO SANtricity, haz clic en Iniciar actualización. Seleccione el archivo de software del SO de SANtricity haciendo clic en Examinar. Sube el nuevo paquete de software RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp como se muestra a continuación:

    Subir paquete de SANtricity

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

  4. Una vez que se haya completado la actualización, comprueba que la versión se haya actualizado:

    Comprobar la versión de SANtricity

15.3. Instalación

15.3.1. Crear secretos

Tiempo estimado: entre 15 y 30 minutos

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

  1. Obtén los nombres de los 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}'

    Ejemplo de salida:

    # 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. Obtén 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. Inicia sesión en el gestor del sistema SANtricity desde el enlace de la salida del comando anterior. Si no has configurado la contraseña anteriormente, crea una e inicia sesión:

    Inicia sesión en el gestor del sistema SANtricity.

    1. Si se ha perdido la contraseña de SANtricity, cámbiala a través de la consola serie de StorageGRID E2860. Para conectarse al puerto serie de la matriz de discos E2860, los ajustes del terminal son 115200 8N1.

  4. Configure las direcciones del servidor NTP en el gestor del sistema SANtricity para ambos controladores:

    Configurar direcciones de servidor NTP

    1. Obtener 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 el gestor de sistemas SANtricity.

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

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

    5. Selecciona Configurar servidor NTP. Se abrirá el cuadro de diálogo Configurar servidor de protocolo de hora de red (NTP).

    6. Selecciona Quiero habilitar NTP en el mando (A o B). Aparecerán más selecciones en el cuadro de diálogo.

    7. Seleccione Especificar manualmente las direcciones del servidor NTP. Introduce la dirección del servidor NTP principal con una de las IPs obtenidas con el comando anterior.

    8. Haz clic en Guardar.

  5. Actualiza los secretos que contienen las credenciales de SANtricity de cada uno de los nodos de almacenamiento del archivo cell.yaml. Si los secretos no existen, añádelos siguiendo 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 de 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 haya indicado en el paso anterior. Imprime el nombre de usuario de Santricity definido 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 haya indicado en el paso anterior. Muestra 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 interfaz de usuario de gestión de Santricity. Inicia sesión en 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 al ejecutar los pasos 1 o 2 de la validación, vuelve a ejecutar el kubectl create secret.

Si no puedes iniciar sesión en la interfaz de usuario de gestión de Santricity, haz lo siguiente:

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

  3. Elimina el secreto de Santricity de cada nodo:

    kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity

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

15.3.2. Bootstrap Object Storage

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

IMPORTANTE: Antes de continuar, comprueba que la zona de anclaje haya completado el bootstrapping de la API global.

15.3.2.1. Inicializar el almacenamiento de objetos en la primera zona

Ejecuta el siguiente comando para inicializar el almacenamiento de objetos:

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

15.3.2.2. Inicializar 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 devuelvan errores, solucione los problemas que se hayan devuelto.
  2. Consulta el pod gpc-system/obj-infra-cluster-cm-backend-controller de inicio de sesión para obtener más información sobre el error.

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

Tiempo estimado: entre 30 y 60 minutos

Para inicializar Object Storage en una zona que se va a unir, es necesario coordinar los reconciliadores de Object Storage de la zona de anclaje y de la zona que se va a unir. Como no existe un canal de comunicación seguro y controlado entre dos zonas para los reconciliadores durante el tiempo de arranque, la entrada/salida debe facilitar manualmente la comunicación segura de los reconciliadores de almacenamiento de objetos entre dos zonas.

  1. Asigna el rol predefinido Administrador de clústeres en el clúster zonal y global de administrador raíz de la zona de anclaje. Para obtener más información, consulta el manual de operaciones de gestión de identidades y accesos.

También puedes aplicar estos dos enlaces de rol en la zona de anclaje:

En la API global:

  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 resolver stub de DNS de la zona de unión para que se vincule con la zona de anclaje:

    1. Inhabilitar y detener systemd-resolved sh systemctl disable systemd-resolved.service --now

    2. Elimina 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 Contenido de ejemplo del archivo /etc/resolv.conf: sh nameserver 10.200.40.0

  3. Crea un archivo TokenRequest YAML 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

    Sustituye JOINING_ZONE_NAME por el nombre de la zona del cuestionario de información del cliente, tal como se describe en la nota al final de la sección.

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

    scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH

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

    kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH

  6. Crea un archivo YAML de 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 que se va a unir.

    scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH

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

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH

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

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

  10. Transfiere el archivo YAML ObjectStorageBootstrap a la zona que se va a unir.

    scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH

  11. Aplica el archivo YAML ObjectStorageBootstrap al clúster de KIND de la zona que se va a unir.

    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