Administra los recursos de la organización

Como operador de infraestructura (IO) de Google Distributed Cloud (GDC) aislado, verificas el estado del sistema, configuras usuarios y redes, y administras el ciclo de vida de los sistemas de hardware subyacentes, como el procesamiento, el almacenamiento y las redes.

Antes de comenzar

Para completar este documento, necesitas acceso a los siguientes recursos:

  • La CLI de gcloud o la CLI de kubectl

  • Un entorno de Linux

Para obtener los permisos que necesitas para administrar una organización, pídele a tu administrador de seguridad que te otorgue el rol de administrador de la organización (organization-admin).

Accede a los servidores y supervisa su actividad

Acceder a los servidores de GDC y supervisar sus estados para garantizar que sean seguros, estén actualizados y funcionen correctamente

Consulta la página Consultar y ver métricas para obtener más información sobre cómo supervisar los servidores de una organización.

Administra el ciclo de vida de un servidor

La administración del ciclo de vida del servidor incluye las siguientes funciones:

  • Reinicia el dispositivo.
  • Se está creando una imagen nueva.
  • Actualizaciones de firmware del controlador de administración de la placa base (BMC) y del dispositivo lógico programable complejo (CPLD).
  • Actualizaciones de software o del sistema operativo
  • Configuraciones del sistema operativo, como la configuración de seguridad

Los parches de seguridad del sistema operativo base, las actualizaciones de paquetes para el software del host del servidor y las actualizaciones de firmware del servidor se realizan con regularidad durante los períodos de mantenimiento.

Los períodos de mantenimiento incluyen las siguientes acciones:

  • Instalar actualizaciones de seguridad urgentes en el sistema operativo del servidor
  • Actualiza el paquete de software del host en uno o más servidores.
  • Actualiza el firmware en uno o más servidores.

Agrega y administra servidores de cargas de trabajo

Para agregar servidores de cargas de trabajo adicionales o administrar los existentes, actualiza tu recurso personalizado OrganizationZonalConfig almacenado en el repositorio iac:

  1. Genera la lista de servidores y tipos de servidores disponibles:

    kubectl get servers -n gpc-system -o \
        jsonpath='{range .items[?(@.status.bareMetalHostStatus.provisionState=="available")]}{.metadata.name}{"\t"}{.spec.serverHardware.machineClassName}{"\t"}{.status.bareMetalHostStatus.provisionState}{"\n"}{end}'
    

    El resultado es similar al siguiente:

    ag-aa-bm04   o1-standard1-64-gdc-metal   available
    ag-ab-bm07   o1-standard1-64-gdc-metal   available
    ag-ab-bm11   o1-highmem1-96-gdc-metal    available
    ag-ab-bm12   o1-highmem1-96-gdc-metal    available
    ag-ab-bm13   o1-highmem1-96-gdc-metal    available
    ag-ab-bm14   o1-highgpu1-48-gdc-metal    available
    ag-ab-bm15   o1-highgpu1-48-gdc-metal    available
    ag-ab-bm16   o1-highgpu1-48-gdc-metal    available
    

    Ten en cuenta qué servidores están disponibles y asegúrate de asignar solo los que están disponibles cuando modifiques los servidores de carga de trabajo de tu organización.

  2. Abre el archivo YAML del recurso personalizado OrganizationZonalConfig en el repositorio iac:

    vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml
    

    Reemplaza lo siguiente:

    • IAC_REPO_PATH: Es la ruta de acceso a la carpeta del repositorio iac.
    • ORG_NAME: Es el nombre de la organización.
    • ZONE: Es el nombre de la zona en el universo. El nombre de la zona se deriva con el siguiente formato: {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Por ejemplo, us-central1-b. Consulta la sección Zona del Cuestionario de admisión de clientes para obtener descripciones de los valores del atributo de zona.
  3. Actualiza la sección workloadServers del archivo YAML. Agrega servidores de carga de trabajo nuevos o administra la cantidad de servidores existentes para cada tipo:

    ...
    workloadServers:
      o1-highmem1-40-gdc-metal: 1
      o1-standard1-64-gdc-metal: 2
      o1-highmem1-96-gdc-metal: 3
      o1-highmem1-104-gdc-metal: 4
      o1-highmem1-448-gdc-metal: 5
      o1-highgpu1-48-gdc-metal: 6
    ...
    
  4. Guarda y cierra el editor interactivo.

  5. Confirma y organiza los cambios en el archivo YAML de configuración zonal de tu organización:

    git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
    git commit
    
  6. Envía la actualización a GitLab:

    git -c http.sslVerify=false push
    
  7. Espera la revisión de código y la combinación.

  8. Repite estos pasos con el mismo contenido y la misma estructura de directorios para todos los repositorios de GitLab de todas las zonas de Distributed Cloud en la implementación de Distributed Cloud.

    En la implementación de Distributed Cloud, cada zona contiene instancias individuales desconectadas de GitLab. Para cada recurso global creado, actualizado o borrado en GitLab, debes confirmar el mismo contenido exacto en los repositorios de GitLab de cada zona. El pod del reconciliador raíz global se ejecuta en la zona principal de Distributed Cloud, que se define en el campo primary del recurso personalizado zoneselectionresult en la API global. El reconciliador sincroniza los datos del GitLab de la zona principal con la API global.

  9. Verifica que los servidores de carga de trabajo que asignaste estén disponibles para su uso:

    kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig get servers -n gpc-system -o \
        jsonpath='{range .items[?(@.spec.nodePoolClaimRef.namespace=="org-1")]}{.metadata.name}{"\t"}{.status.provisionReady}{"\n"}{end}'
    

    Si el servidor de carga de trabajo está configurado como true, está disponible. La salida es similar a lo siguiente:

    zi-aa-bm04      true
    zi-aa-bm05      true
    zi-aa-bm06      true
    

Aumentar la capacidad de almacenamiento

La cantidad de almacenamiento disponible para cada organización en una zona se define en el campo capacities del recurso OrganizationZonalConfig.

Para aumentar la cuota de estas clases de almacenamiento, actualiza el recurso OrganizationZonalConfig en cada zona.

  1. Abre el archivo YAML del recurso personalizado OrganizationZonalConfig en el repositorio iac:

    vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml
    

    Reemplaza lo siguiente:

    • IAC_REPO_PATH: Es la ruta de acceso a la carpeta del repositorio iac.
    • ORG_NAME: Es el nombre de la organización.
    • ZONE: Es el nombre de la zona en el universo, como us-central1-b. Para obtener más información sobre los valores de los atributos de zona, consulta la sección Zona del cuestionario de admisión del cliente.
  2. Actualiza la sección capacities del archivo YAML con los nuevos valores de cuota para tus tipos de almacenamiento. Por ejemplo:

    # Several lines of code are omitted here.
    spec:
      capacities:
        storage:
          file-standard: FILE_QUOTA
          block-standard: BLOCK_QUOTA
          object-standard: OBJECT_QUOTA
    

    Reemplaza lo siguiente:

    • FILE_QUOTA: Es el nuevo valor de la cuota para el almacenamiento de archivos en la zona, como 10Ti.
    • BLOCK_QUOTA: Es el nuevo valor de la cuota para el almacenamiento en bloque en la zona, como 10Ti.
    • OBJECT_QUOTA: Es el nuevo valor de la cuota para el almacenamiento de objetos en la zona, como 10Ti.

    Para obtener más información sobre cómo definir tu capacidad de almacenamiento dentro del recurso OrganizationZonalConfig, consulta la documentación de referencia de TypedResourceCapacities.

  3. Guarda y cierra el editor interactivo.

  4. Confirma y organiza los cambios en el archivo YAML de configuración zonal de tu organización:

    git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
    git commit
    
  5. Envía la actualización a GitLab:

    git -c http.sslVerify=false push
    
  6. Espera la revisión de código y la combinación.

  7. Repite estos pasos con el mismo contenido y la misma estructura de directorios para todos los repositorios de GitLab de todas las zonas de GDC en la implementación de GDC.