Esta página se ha traducido con Cloud Translation API.

Realizar una expansión dinámica

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

Ampliación horizontal de la estantería de servidores: añade una nueva estantería a la zona. Este rack incluye nodos de computación, una consola, conmutadores Top-of-Rack (ToR) y conmutadores de gestión (MGMT).
Expansión vertical de servidores: añade bloques de expansión de servidores a los racks que tienen ranuras de expansión vacías.
Expansión vertical del almacenamiento de archivos y en bloques: añade nodos de almacenamiento a bastidores que tienen ranuras de expansión vacías en un clúster de almacenamiento. Los nodos de almacenamiento conectados al mismo switch de almacenamiento forman parte del mismo clúster.

Para obtener más información sobre los distintos tipos de expansión dinámica, consulta el artículo Descripción general de la expansión dinámica.

Antes de empezar

Antes de hacer cambios en la zona, debe tener lo siguiente:

Realiza una inspección del hardware y pide al fabricante que dé su conformidad . Sigue las instrucciones de Inspección de bastidores.
Sigue los pasos para generar el archivo KUBECONFIG para el clúster de administradores del nodo de plano de control.KUBECONFIG Utilice el archivo de configuración KUBECONFIG generado para todos los pasos de kubectl de esta guía.
Verifica que la versión actual de Google Distributed Cloud (GDC) con air gap del 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 el artículo Descargar archivos.
Prepara el firmware de los nuevos electrodomésticos:
1. Los dispositivos de conmutación de paquetes del hardware de GDC. Para obtener más información, consulta Interruptores.
2. Actualiza el almacenamiento de archivos y en bloques de ONTAP siguiendo las instrucciones de 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 que se describe en Verificación de la instalación de la red.

Realizar una ampliación horizontal del rack de servidores

Añade un nuevo rack compuesto por nodos de computación, la consola y los conmutadores ToR y de gestión a la zona mediante una ampliación horizontal del rack de servidores. Los pasos que se describen en esta sección son para un solo rack. Si tienes varios racks, sigue estos pasos con cada uno.

Realizar operaciones de restablecimiento

Debes restablecer de forma segura el siguiente equipo:

Realiza un reinicio seguro del servidor de consola serie. Ponte en contacto con Google para obtener estas instrucciones, ya que cada implementación puede tener consolas serie diferentes.
Realiza un restablecimiento seguro en la unidad de distribución de energía (PDU) de Raritan:
1. Conecta el cable USB-B a la PDU de Raritan desde el controlador del sistema.
2. En la consola serie local, restablece los ajustes predeterminados de fábrica de la PDU con el comando reset factorydefaults.
3. La PDU ahora está configurada en admin/legrand.
Realiza un restablecimiento seguro, actualiza el firmware y restablece los interruptores ToR y MGMT a PowerOn Auto Provisioning (POAP) siguiendo las instrucciones de Borrado seguro.
Conéctate a cada servidor y realiza el borrado seguro manualmente.

Preparar artefactos

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

Genera el archivo ZonalExpansion YAML, 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

Sustituye FILE_PATH por cada uno de los archivos utilizados. Ten en cuenta que esta ruta puede ser diferente si cada archivo está en una ubicación distinta.

El recurso personalizado ZonalExpansion hace un seguimiento de todos los objetos que se añaden e informa del estado de todos los objetos.

Sigue estas directrices al revisar el archivo ZonalExpansion YAML:

El campo name debe ser descriptivo, como az-ae-expansion.
El campo assets debe incluir todos los dispositivos nuevos del nuevo rack de expansión.

A continuación, se muestra un ejemplo de 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. También puedes seguir el manual de instrucciones IAM-R0004 y usar kubectl para hacerlo.
Verifica que se hayan creado los recursos ZonalExpansion y NonCompliantDeviceSet:
1. Comprueba el estado del recurso ZonalExpansion:
```
kubectl --kubeconfig $KUBECONFIG get -A zonalexpansion -o yaml
```
  La comprobación previa debería fallar en esta fase con el motivo ReasonAssetsNotExisted.
2. El recurso NonCompliantDeviceSet debe existir con un nombre que empiece por noncompliantassets-.
3. La lista de recursos debe ser la misma que la del campo assets del recurso personalizado ZonalExpansion.
Sigue las instrucciones de OLT-R0003 para actualizar los recursos.
Conecta los interruptores ToR y MGMT del nuevo rack al interruptor de agregación del rack actual.
Conecta físicamente los interruptores a los bastidores de base.

Bootstrap del servidor completo

Esta fase está automatizada en su mayor parte, pero se requieren algunos pasos. Debes monitorizar el progreso del arranque y gestionar los casos de error:

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.
Comprueba que los interruptores se hayan quitado de la lista NonCompliantDeviceSet:
```
kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A -o yaml
```
Sustituye EXPANSION_NAME por el nombre del recurso personalizado de expansión zonal.

Verifica que los interruptores no estén en el campo Spec.Assets del archivo YAML devuelto. Esta eliminación permite que GDC actualice las ACLs de red para permitir otros procedimientos de arranque de dispositivos. Las dos listas de control de acceso de red actualizadas son quarantine-mgmt-switch-acl y quarantine-data-switch-acl.

Enumera todas las direcciones IP del controlador de gestión de la placa base (BMC) del servidor y comprueba que las direcciones IP de iLO se han asignado a la nueva máquina física y que se puede iniciar el bootstrap:

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

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 en paralelo para realizar el borrado seguro, la verificación, la actualización de la configuración del BIOS y otros procedimientos de arranque.

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 pasa a ser Available o Provisioned después de que el arranque se haya realizado correctamente.
- Con un nivel de detalle de cuatro en la CLI, verás registros como "Not all servers in the ZonalExpansion are bootstrapped" con una lista de servidores que aún no están listos.

Comprueba que los servidores se hayan eliminado de la lista NonCompliantDeviceSet:

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

Comprueba 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.

Comprueba que la lista NonCompliantDeviceSet se ha eliminado:

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`

Realizar una ampliación vertical del servidor

Añade bloques de expansión de servidores a los racks que tengan ranuras de expansión vacías mediante una expansión vertical de servidores. Muchas de las instrucciones de esta ampliación son similares a las de la ampliación de computación horizontal. Sigue estos pasos para ampliar un rack de servidores vertical:

Instala físicamente el bloque de servidores estándar, que ocupa seis nodos de capacidad, o el bloque de servidores de GPU, que consume tres nodos de capacidad. Puedes añadir varios bloques por estante. Advertencia: No conectes cables a los interruptores mgmtsw o aggsw. Para obtener más información, consulta Interruptores.
No conectes ningún cable, excepto el de alimentación. Este paso permite que el proceso de encendido del servidor verifique que el servidor no esté sin conexión al llegar.

Genera el archivo ZonalExpansion YAML 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

Sustituye FILE_PATH por cada uno de los archivos utilizados. Ten en cuenta que esta ruta puede ser diferente si cada archivo está en una ubicación distinta.

Sigue estas directrices al revisar el archivo ZonalExpansion YAML:

El campo name debe ser descriptivo, como az-ae-expansion.
El campo assets debe incluir todos los dispositivos nuevos del nuevo rack de expansión.

A continuación, se muestra un ejemplo de 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. Comprueba el estado del recurso ZonalExpansion. La comprobación previa debería fallar en esta fase con el motivo ReasonAssetsNotExisted.
2. El recurso NonCompliantDeviceSet debe existir con un nombre que empiece por noncompliantassets-.
3. La lista de recursos debe ser la misma que la del campo assets del recurso personalizado ZonalExpansion.
Sigue las instrucciones de OLT-R0003 para actualizar los recursos.
Verifica que la ACL del interruptor de cuarentena se está ejecutando siguiendo el manual de instrucciones OLT-R0001.
Conecta el cableado de los servidores si aún no lo has hecho. Sigue las instrucciones del archivo de cableado proporcionado por Hewlett Packard Enterprise (HPE).
Verifica que el proceso de arranque del servidor se inicia y se completa correctamente. Para obtener más información, consulta Completar el arranque del servidor.

Realizar una ampliación vertical del almacenamiento de archivos y en bloques

Estas instrucciones incluyen los pasos necesarios para llevar a cabo una ampliación vertical o de un solo rack de un nodo de almacenamiento. La ampliación de nodos de almacenamiento se lleva a cabo cuando se añaden nuevos nodos de almacenamiento de ONTAP para ampliar las capacidades de almacenamiento de un rack. Aquí no se proporcionan instrucciones de cableado para los nuevos dispositivos de almacenamiento, solo los procedimientos para borrar, actualizar y añadir nuevos nodos de almacenamiento a un clúster.

Configurar la expansión de nodos de almacenamiento

Sigue estos pasos para preparar el clúster para la ampliación de nodos de almacenamiento:

Sigue los pasos para generar el archivo KUBECONFIG para el clúster de administradores del nodo de plano de control.KUBECONFIG Usa el archivo de configuración KUBECONFIG generado para todos los pasos de kubectl de esta guía:

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

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

Comprueba que la anulación ha funcionado y que los reconciliadores file-storage se han inhabilitado:
```
kubectl --kubeconfig $KUBECONFIG describe deployment file-storage -n
file-system | grep reconcilers
```
Debe 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 comprobación. Si el SubcomponentOverride sigue sin aplicarse después de un par de minutos, ponte en contacto con el equipo de Asistencia de Ingeniería de GDC.

Genera el archivo ZonalExpansion YAML 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. Comprueba el estado del recurso ZonalExpansion. La comprobación previa debería fallar en esta fase con el motivo ReasonAssetsNotExisted.
2. El recurso NonCompliantDeviceSet debe existir con un nombre que empiece por noncompliantassets-.
3. La lista de recursos debe ser la misma que el campo "assets" del recurso personalizado ZonalExpansion.
Aplica los siguientes recursos de SubcomponentOverride 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 ninguna anulación que ya se haya aplicado al clúster. Captura los SubcomponentOverride actuales y añádelos a los SubcomponentOverride generados correspondientes para asegurarte de que no se pierda ninguna sustitución.

Confirma que los nuevos nodos se han añadido al clúster:

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

Deberías ver los nuevos recursos personalizados de nodo añadidos 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

Sustituye NODE_NAME por el nombre de cada nodo creado.