Se usó la API de Cloud Translation para traducir esta página.

Realiza una expansión dinámica

En esta página, se describe el proceso de expansión dinámica de tu sistema mediante la incorporación de más recursos de almacenamiento y procesamiento. Se proporcionan instrucciones para los siguientes tipos de expansión:

Expansión horizontal del rack del servidor: Agrega un rack nuevo a la zona. Este rack incluye nodos de procesamiento, una consola, switches top-of-rack (ToR) y switches de administración (MGMT).
Expansión vertical del servidor: Agrega bloques de expansión del servidor a los racks que tienen ranuras de expansión vacías.
Expansión vertical del almacenamiento de archivos y bloques: Agrega nodos de almacenamiento a los racks que tienen ranuras de expansión vacías en un clúster de almacenamiento existente. Los nodos de almacenamiento conectados al mismo conmutador de almacenamiento forman parte del mismo clúster.

Para obtener más información sobre los diferentes tipos de expansión dinámica, consulta Descripción general de la expansión dinámica.

Antes de comenzar

Antes de realizar cambios en la zona, debes tener lo siguiente:

Realiza una inspección de hardware y firma con el OEM . Sigue las instrucciones en Rack Inspection.
Sigue las instrucciones para la generación de KUBECONFIG y genera el archivo KUBECONFIG para el clúster de administrador del nodo del plano de control. Usa el archivo de configuración KUBECONFIG generado para todos los pasos de kubectl en esta guía.
Verifica que la versión actual de Google Distributed Cloud (GDC) aislado en el clúster raíz sea al menos la versión 1.13.1:
```
kubectl --kubeconfig $KUBECONFIG get org root -n gpc-system
```
Descarga el archivo .tar de GDC. Para obtener más información, consulta Descarga archivos.
Prepara el firmware de los electrodomésticos nuevos:
1. Son los dispositivos de conmutación de paquetes en el hardware de la GDC. Para obtener más información, consulta Interruptores.
2. Actualiza el almacenamiento de archivos y bloques de ONTAP siguiendo las instrucciones en Actualización manual de ONTAP.
Valida que el sistema de GDCH esté en buen estado con gdcloud system doctor. Si el comando gdcloud system doctor no está disponible, usa el método alternativo en Verificación de la instalación de red.

Realiza la expansión horizontal del rack del servidor

Agrega un nuevo rack compuesto por nodos de procesamiento, la consola y los conmutadores de ToR y de administración a la zona a través de una expansión horizontal del rack de servidores. Los pasos que se describen en esta sección son para un solo rack. Si tienes varios racks, aplica estos pasos a cada uno de ellos.

Realizar operaciones de restablecimiento

Debes restablecer de forma segura el siguiente equipo:

Realiza un restablecimiento seguro del servidor de la consola en serie. Comunícate con Google para obtener estas instrucciones, ya que cada implementación puede tener diferentes consolas en serie.
Realiza un restablecimiento seguro en la unidad de distribución de alimentación (PDU) de Raritan:
1. Conecta el cable USB-b a la PDU de Raritan desde el controlador del sistema.
2. En la consola en serie local, restablece la PDU a la configuración de fábrica predeterminada con el comando reset factorydefaults.
3. La PDU ahora está configurada en admin/legrand.
Realiza un restablecimiento seguro, actualiza el firmware y restablece los conmutadores ToR y MGMT al aprovisionamiento automático al encender (POAP) siguiendo las instrucciones en Borrado seguro.
Conéctate a cada servidor y realiza el borrado seguro de forma manual.

Prepara los artefactos

Sigue estos pasos para aplicar los archivos de configuración y los recursos personalizados necesarios:

Genera el archivo YAML ZonalExpansion, el hardware CustomResources y los recursos de hardware SubcomponentOverride con el comando gdcloud system assets add:
```
gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af
```
Reemplaza FILE_PATH para cada uno de los archivos que se usaron. Ten en cuenta que esta ruta puede ser diferente si cada archivo se encuentra en una ubicación distinta.

El recurso personalizado ZonalExpansion hace un seguimiento de todos los objetos que se agregan y registra el estado de todos los objetos.

Sigue estos lineamientos cuando revises el archivo YAML de ZonalExpansion:
- El campo name debe ser descriptivo, como az-ae-expansion.
- El campo assets debe incluir todos los electrodomésticos nuevos en el nuevo estante de expansión.
A continuación, se muestra un ejemplo de un recurso ZonalExpansion:
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01
```
Usa herramientas de infraestructura como código (IaC) para aplicar el recurso personalizado ZonalExpansion. Para obtener más información, consulta Configuración de la infraestructura como código. Como alternativa, sigue el manual de ejecución IAM-R0004 y usa kubectl para hacerlo.
Verifica que se hayan creado los recursos ZonalExpansion y NonCompliantDeviceSet:
1. Verifica el estado del recurso ZonalExpansion:
```
kubectl --kubeconfig $KUBECONFIG get -A zonalexpansion -o yaml
```
  La verificación previa debería fallar en esta etapa con el motivo ReasonAssetsNotExisted.
2. El recurso NonCompliantDeviceSet debe existir con el nombre que tenga el prefijo noncompliantassets-.
3. La lista de recursos debe ser la misma que el campo assets en el recurso personalizado ZonalExpansion.
Sigue las instrucciones que se indican en OLT-R0003 para actualizar los recursos.
Conecta los conmutadores ToR y MGMT del rack nuevo al conmutador de agregación del rack existente.
Conecta físicamente los interruptores a los soportes base.

Arranque completo del servidor

Esta fase es mayormente automática, pero se requieren algunos pasos. Debes supervisar el progreso del arranque y controlar cualquier caso de falla:

El controlador inicia automáticamente el procedimiento de arranque una vez que se cumple la condición PreflightCheck=True.
Verifica que la condición NetworkBootstrapSucceed=True se haya publicado en el recurso personalizado ZonalExpansion. Esta condición se encuentra en la ubicación ZonalExpansion.Status.PNETBootstrapStatus.
Verifica que los parámetros de configuración se hayan quitado de la lista NonCompliantDeviceSet:
```
kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A -o yaml
```
Reemplaza EXPANSION_NAME por el nombre del recurso personalizado de expansión zonal.

Verifica que los parámetros de configuración no estén en el campo Spec.Assets del archivo YAML devuelto. Esta eliminación permite que GDC actualice las ACL de la red para permitir otros procedimientos de arranque de dispositivos. Las dos LCA de red actualizadas son quarantine-mgmt-switch-acl y quarantine-data-switch-acl.

Enumera todas las direcciones IP del controlador de administración de la placa base (BMC) del servidor y verifica que las direcciones IP de iLO estén asignadas a la nueva máquina física y que se pueda iniciar el arranque:

kubectl --kubeconfig $KUBECONFIG get servers -n gpc-system -o=custom-columns=SERVER:.metadata.name,BMC_IP:.spec.bmc.ip

Resultado de ejemplo:

 SERVER       BMC_IP
 yz-aa-bm01   10.128.136.2
 yz-aa-bm02   10.128.136.3
 yz-aa-bm03   10.128.136.4
 yz-ab-bm01   10.128.136.66
 yz-ab-bm02   10.128.136.67
 yz-ab-bm03   10.128.136.68
 yz-ac-bm01   10.128.136.130
 yz-ac-bm02   10.128.136.131
 yz-ac-bm03   10.128.136.132
 yz-ac-bm04   10.128.136.133
 yz-ac-bm05   10.128.136.134
 yz-ac-bm06   10.128.136.135
 yz-ac-bm07   10.128.136.136
 yz-ac-bm08   10.128.136.137
 yz-ac-bm09   10.128.136.138
 yz-ac-bm10   10.128.136.139
 yz-ac-bm11   10.128.136.140
 yz-ac-bm12   10.128.136.141
 yz-ac-bm13   10.128.136.142
 yz-ac-bm14   10.128.136.143
 yz-ac-bm15   10.128.136.144
 yz-ac-bm16   10.128.136.145
 yz-ac-bm17   10.128.136.146
 yz-ac-bm18   10.128.136.147

GDC inicia los servidores de forma paralela para realizar el borrado seguro, la verificación, la actualización de la configuración del BIOS y otros procedimientos de inicio.

Verifica que la condición ServerBootstrapSucceeded=True se haya publicado en el recurso personalizado ZonalExpansion. Esta condición se encuentra en la ubicación ZonalExpansion.Status.SERVBootstrapStatus:
- El estado del host de metal desnudo del servidor ingresa en un estado de Available o Provisioned después de que el arranque se realiza correctamente.
- Con un nivel de detalle de la CLI de cuatro, verás registros como "Not all servers in the ZonalExpansion are bootstrapped" con una lista de servidores que aún no están listos.

Verifica que los servidores se hayan quitado de la lista NonCompliantDeviceSet:

kubectl --kubeconfig $KUBECONFIG get noncompliantdevicesets -n gpc-system "noncompliantassets-EXPANSION_NAME" -o yaml

Verifica que la condición ExpansionSucceeded=True se haya publicado en el recurso personalizado ZonalExpansion. Esta condición se encuentra en la ubicación ZonalExpansion.Status.Conditions.

Verifica que se haya borrado la lista NonCompliantDeviceSet:

kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A

Resultado esperado:

`Error from server (NotFound): noncompliantdevicesets.system.private.gdc.goog "noncompliantassets-EXPANSION_NAME" not found`

Realiza la expansión vertical del servidor

Agrega bloques de expansión del servidor en los racks que tienen ranuras de expansión vacías a través de una expansión vertical del servidor. Muchas de las instrucciones para esta expansión son similares a las de la expansión horizontal de procesamiento. Sigue estos pasos para expandir un rack de servidores vertical:

Instala físicamente el bloque de servidor estándar que ocupa seis nodos de capacidad o el bloque de servidor de GPU que consume tres nodos de capacidad. Puedes agregar varios bloques por bastidor. Advertencia: No enchufes cables en los interruptores mgmtsw o aggsw. Para obtener más información, consulta Interruptores.
No realices ningún cableado, excepto el de la fuente de alimentación. Este paso permite que el proceso de encendido del servidor verifique que el servidor no esté sin conexión cuando llegue.

Genera el archivo YAML de ZonalExpansion y el recurso de hardware SubcomponentOverride con el comando gdcloud system assets add:

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af

Reemplaza FILE_PATH para cada uno de los archivos que se usaron. Ten en cuenta que esta ruta puede ser diferente si cada archivo se encuentra en una ubicación distinta.

Sigue estos lineamientos cuando revises el archivo YAML de ZonalExpansion:

El campo name debe ser descriptivo, como az-ae-expansion.
El campo assets debe incluir todos los electrodomésticos nuevos en el nuevo estante de expansión.

A continuación, se muestra un ejemplo de un recurso ZonalExpansion:

apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01

Aplica el recurso personalizado ZonalExpansion que acabas de crear al clúster.
Verifica que se hayan creado los recursos ZonalExpansion y NonCompliantDeviceSet:
1. Verifica el estado del recurso ZonalExpansion. La verificación previa debería fallar en esta etapa con el motivo ReasonAssetsNotExisted.
2. El recurso NonCompliantDeviceSet debe existir con el nombre que tenga el prefijo noncompliantassets-.
3. La lista de recursos debe ser la misma que el campo assets en el recurso personalizado ZonalExpansion.
Sigue las instrucciones que se indican en OLT-R0003 para actualizar los recursos.
Sigue el manual de ejecución OLT-R0001 para verificar que la ACL del interruptor de cuarentena esté en ejecución.
Conecta el cableado de los servidores si aún no lo hiciste. Sigue el archivo de cableado proporcionado por Hewlett Packard Enterprise (HPE).
Verifica que el proceso de inicio del servidor comience y se complete correctamente. Para obtener más información, consulta Arranque completo del servidor.

Realiza la expansión vertical del almacenamiento de archivos y bloques

Estas instrucciones incluyen los pasos necesarios para realizar una expansión vertical o de un solo rack del nodo de almacenamiento. La expansión del nodo de almacenamiento se realiza cuando se agregan nodos de almacenamiento ONTAP nuevos para expandir las capacidades de almacenamiento de un rack existente. Aquí no se proporcionan instrucciones de cableado para los nuevos dispositivos de almacenamiento, solo los procedimientos para borrar, actualizar y agregar nodos de almacenamiento nuevos a un clúster existente.

Realiza la configuración para la expansión del nodo de almacenamiento

Sigue estos pasos para preparar el clúster para la expansión del nodo de almacenamiento:

Sigue las instrucciones para la generación de KUBECONFIG y genera el archivo KUBECONFIG para el clúster de administrador del nodo del plano de control. Usa el archivo de configuración KUBECONFIG generado para todos los pasos de kubectl en esta guía:

Aplica un recurso SubcomponentOverride para inhabilitar los reconciliadores de almacenamiento mientras realizas la configuración inicial para la expansión del nodo:

kubectl --kubeconfig $KUBECONFIG apply -f - <<EOF
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
    name: file-storage-sub-override
    namespace: root
spec:
    subComponentRef: "file-storage"
    backend:
        operableParameters:
            controller:
                enableReconcilers: ""
                disableReconcilers: "*"
EOF

Verifica que la anulación haya funcionado y que los reconciliadores de file-storage se hayan inhabilitado:
```
kubectl --kubeconfig $KUBECONFIG describe deployment file-storage -n
file-system | grep reconcilers
```
Debes ver lo siguiente:
```
--enable-reconcilers=
--disable-reconcilers=*
```
Si no ves este estado, espera varios minutos para que se aplique el recurso SubcomponentOverride y vuelve a realizar esta verificación. Si el SubcomponentOverride aún no se aplicó después de unos minutos, comunícate con el equipo de asistencia técnica de GDC.

Genera el archivo YAML de ZonalExpansion y el recurso de hardware SubcomponentOverride con el comando gdcloud system assets add:

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af
```
Replace FILE_PATH for each of the files used. Note, this path might be different if each file is in a different location.

Use the following guidance when reviewing the `ZonalExpansion` YAML file:

The `name` field must be descriptive, such as aj-ad-expansion.
The `assets` field must include all new appliances in the new expansion rack.
Here is an example of a `ZonalExpansion` resource:

```sh
apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
name: file
namespace: gpc-system
spec:
assets:
- kind: StorageNode
    name: aj-ad-stge03-01
- kind: StorageNode
    name: aj-ad-stge03-02
```

Aplica el recurso personalizado ZonalExpansion que acabas de crear al clúster.
Verifica que se hayan creado los recursos ZonalExpansion y NonCompliantDeviceSet:
1. Verifica el estado del recurso ZonalExpansion. La verificación previa debería fallar en esta etapa con el motivo ReasonAssetsNotExisted.
2. El recurso NonCompliantDeviceSet debe existir con el nombre que tenga el prefijo noncompliantassets-.
3. La lista de recursos debe ser la misma que el campo de recursos en el recurso personalizado ZonalExpansion.
Aplica los siguientes recursos SubcomponentOverride de activos de hardware al clúster de administrador raíz con herramientas de IaC.
- file/file-storage.yaml
- inv/inv-core.yaml
Nota: El SubcomponentOverride generado no incluye ningún reemplazo que ya se haya aplicado al clúster. Captura los SubcomponentOverride actuales y agrégalos a los SubcomponentOverride generados correspondientes para garantizar que no se pierdan anulaciones.

Confirma que los nodos nuevos se hayan agregado al clúster:

kubectl --kubeconfig $KUBECONFIG get storagenodes -n gpc-system

Ahora deberías ver los recursos personalizados del nodo nuevo agregados con un valor de antigüedad más reciente:

  NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
  aj-ad-stge01-01   172.22.243.129   169.254.0.1      AFF-A250   37d
  aj-ad-stge01-02   172.22.243.130   169.254.0.3      AFF-A250   37d
  aj-ad-stge03-01   172.22.243.133   169.254.0.9      AFF-A400   20d
  aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d

Usa el comando describe para obtener información sobre ambos nodos, ya que contienen información necesaria para los pasos posteriores.

kubectl --kubeconfig $KUBECONFIG describe storagenode NODE_NAME -n gpc-system

Reemplaza NODE_NAME por el nombre de cada nodo creado.